Bölüm 2: Mimari ve Çalışma Modeli¶

Yüksek Seviyeli Mimari¶

Arceris, istemciler ile yapay zeka sağlayıcıları arasına yerleşen çok katmanlı bir kontrol mimarisiyle çalışır. İstemci tarafında tarayıcılar, coding agent'lar, API istemcileri ve Arceris'in kendi kullanıcı paneli yer alırken; arka tarafta OpenAI, Anthropic, Google ve kurum içi modeller gibi upstream AI servisleri bulunur. Arceris bu iki katmanın arasında durarak istekleri karşılar, değerlendirir, gerektiğinde değiştirir ve uygun hedefe iletir.

Bu mimaride ürünün ana görevi yalnızca trafik iletmek değildir. Kimlik doğrulama, erişim kontrolü, içerik denetimi, politika uygulama, maliyet limitleri, loglama ve gözlemlenebilirlik işlevleri tek bir akış içinde yerine getirilir. Bu yaklaşım, kurumların dağınık AI kullanımını merkezi bir yönetişim modeli altında toplamasını sağlar.

Tüm giriş yolları ortak bir karar çekirdeğini paylaşır:

  Tarayıcılar               Coding agent'lar / CLI          API istemcileri · Panel Chat
      │                           │                                │
      │ :443 şeffaf proxy         │ :3128 explicit proxy           │ /gateway/v1
      │ (MITM)                    │ (CONNECT + TLS-bump)           │ (gateway key)
      │                           │ + yerel kanal (/local/)        │
      ▼                           ▼                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                     Arceris Gateway — :8443                           │
│                                                                      │
│  Kimlik → Kiracı → Erişim kontrolü → Maliyet limiti → Kontroller     │
│  (dosya kontrolleri → üç katmanlı istem denetimi → yanıt denetimi)   │
│                                                                      │
│       Karar motorları ORTAKTIR; blok sunumu düzleme özgüdür          │
├──────────────────────────────────────────────────────────────────────┤
│ Veri katmanı (kalıcı ürün verisi: kurallar, atamalar, denetim        │
│ kayıtları) · Tarama servisleri (dosya metni, konu, moderasyon)       │
└──────────────────────────────────────────────────────────────────────┘
      │
      ▼
  OpenAI · Anthropic · Google · OpenRouter · kurum içi modeller · …

Bileşen Haritası (v1.3.1)¶

Bileşen	Tür	Rol
Arceris Gateway	Ana kontrol servisi	Ana kontrol düzlemi. Yönetim/API yüzeyi `:8443`, şeffaf proxy `:443`, explicit proxy `:3128` portlarını dinler.
web-frontend	Yönetim/kullanıcı arayüzü	Yönetici paneli ve kullanıcı panelini içeren tek arayüz paketi; gateway ile birlikte tek pakette dağıtılır.
arceris-agent	Windows makine servisi	Uç noktada makine kapsamındaki katman: kayıt (check-in), politika çekme, PAC sunumu, güncelleme.
arceris-dev	Kullanıcı helper'ı	Uç noktada kullanıcı oturumunda çalışan yerel broker; explicit proxy ve yerel kanal trafiğini taşır.
Tarama servisleri	Yardımcı denetim servisleri	Görsel/PDF metin çıkarımı, konu sınıflandırma ve içerik moderasyonu; dağıtımla birlikte gelir, istenirse devre dışı bırakılabilir.
Veritabanı	Kalıcı veri	Kurallar, atamalar, kullanıcılar ve denetim kayıtları için ana kalıcı depo.
Önbellek	Geçici durum	Hız limiting, sayaçlar ve oturum tehdit motorunun çalışma durumu.
Opsiyonel izleme profili	Opsiyonel	İzleme profili açıldığında log toplama, metrik ve pano sunar.

Dört Giriş Düzlemi¶

Arceris'e trafik dört farklı düzlemden girer. Hangi düzlemden gelirse gelsin istek, aynı karar motorlarından geçer; her düzlem yalnızca kendi blok sunumunu (kullanıcıya gösterilen engelleme iletisini) ve kendi kimlik çözümlemesini çizer.

Düzlem	Giriş	Kimlik	Tipik trafik
Şeffaf proxy	`:443` (MITM)	Cihaz/kullanıcı oturumu, captive portal	Tarayıcı tabanlı AI arayüzleri
Explicit proxy	`:3128` (CONNECT + TLS-bump)	Kayıtlı cihazın geliştirici araçları token'ı	Claude Code, Codex, IDE'ler, SDK'lar
Yerel kanal	`/local/` (broker üzerinden)	Kayıtlı cihaz kullanıcısı	Coding agent yerel trafiği ve kurum içi model çağrıları
Birleşik gateway	`/gateway/v1`	Gateway key (`arceris_gw_*`)	API istemcileri; kullanıcı panelinin Chat'i

Şeffaf proxy yönetimi Bölüm 22'de, explicit proxy Bölüm 23'te, aracı ve yerel kanalın kurulumu Bölüm 24'te anlatılır. Bu ayrımın operasyonel anlamı şudur: bir kuralın hangi düzlemde geçerli olduğu Access Management'teki kapsamına bağlıdır; panel her atama için gerçek kapsamı (tüm trafik, tarayıcı + agent'lar vb.) bilgi rozetiyle gösterir.

API Proxy Akışı: Birleşik Gateway¶

API istemcileri için tek giriş noktası birleşik gateway'dir (/gateway/v1). Bu modelde istemci uygulama veya servis, isteğini Arceris'in API yüzeyine bir gateway key ile gönderir. Arceris isteği aldıktan sonra kimlik doğrulama, kiracı bağlamı, erişim kontrolü, maliyet limitleri ve tüm istem/yanıt kontrollerini sırayla uygular; ardından isteği, sağlayıcı formatına çevirerek uygun upstream'e iletir. Kullanıcı panelindeki Chat de v1.2.0'dan beri aynı yoldan geçer ve aynı kontrollere tabidir.

Transparent Proxy Akışı¶

Transparent Proxy, istemci tarafında doğrudan API adresi değiştirilmeden veya görünür bir uygulama ayarı yapılmadan AI trafiğinin denetlenmesini sağlar. Bu model özellikle tarayıcı tabanlı AI servisleri ve kullanıcı davranışını ağ seviyesinde görünür kılmak isteyen kurumlar için önemlidir.

Bu akışta istemcinin ilgili AI alan adlarına yaptığı bağlantılar Arceris'e gelir. Arceris, uygun kurulum ve güven ilişkisi sağlandığında trafiği inceleyebilir, gerekli güvenlik kontrollerini uygulayabilir ve sonrasında gerçek upstream servise iletebilir. Böylece son kullanıcı deneyimi korunurken; kurum tarafında görünürlük, erişim denetimi ve içerik güvenliği merkezi olarak uygulanmış olur.

Prompt Kontrollerinin Katmanlı İşleyişi¶

v1.3.1'de istem kontrolleri her giriş düzleminde (şeffaf, explicit, birleşik gateway ve yerel kanal) üç katmanda çalışır ve ilk engelleme kararında durur:

Süreç içi motorlar — Prompt Guard desenleri, PII kararı, konu sınıflandırıcı ve bu yolda çalışıyorsa oturum tehdidi. En hızlı katmandır; en yaygın bloklar ("hassas veri tespit edildi" gibi) uzak servisler beklenmeden burada verilir.
Dağıtımın kendi tarama servisleri — konu sınıflandırma, içerik moderasyonu ve Kurumsal Veri Denetçisi (kurumun kendi LLM'iyle değerlendirme).
Uzaktan kurumsal kontroller — ICAP DLP ve içerik moderasyonu.

Bu düzenlemenin iki sonucu vardır. Birincisi, yerel bir kontrol engelleme kararı verdiğinde istek artık uzak kontrolleri beklemez ve engellenen içerik önce kurumdan çıkmaz. İkincisi, aynı istemi birden fazla kontrol engelliyorsa kayıtlarda en erken katman adlandırılır; bu yüzden kural bazlı rapor sayımları sürüm yükseltmelerinde kontroller arasında kayabilir. Ekli dosya taşıyan isteklerde dosya kontrolleri (MIME, dosya meta verisi, OCR, dosya metninde PII; şeffaf yolda ayrıca ICAP dosya taraması) bu üç katmandan önce çalışır — katman sıralaması istem metni için geçerlidir.

Kontrol zincirinin ince sıralaması (enjeksiyon koruması → şeffaf yolunda oturum tehdidi → DLP → içerik moderasyonu → PII taraması → ilet) ve PII maskesinin DLP ile moderasyondan sonra, ham değerler denetlensin diye uygulandığı Bölüm 20'de anlatılır. Denetim kayıtları her kararı, istek/yanıt aşaması ve kontrol bazlı süre bilgisiyle birlikte kaydeder (Bölüm 25).

Zaman Davranışı: Model Süresini Gateway Değil İstemci Belirler¶

AI taşıyan yollarda gateway artık bütün-istek veya bütün-yanıt süre sınırı tutmaz. Eski sürümlerdeki explicit proxy istemci zaman aşımı (60 saniye) ve API sunucu yazma sınırı (10 saniye) kaldırıldı; ikisi de gerçek trafiği kesiyordu — uzun bir "extended thinking" turu veya yavaş bir kurum içi model, süresi dolunca yanıtın ortasında kesiliyordu. Dinleyiciler yalnızca başlık okuma ve boşta bekleme sınırları taşır; bir turun süresi konusunda tek belirleyici istemcidir. İstemci bağlantıyı bıraktığında upstream çağrı da iptal edilir; model, yanıtı kimse almayacaksa tamamlanmaya çalışmaz.

Uç Nokta Ajanı Mimarisi¶

Windows uç noktasında ajan iki katmana ayrılmıştır:

Katman	Bileşen	Kapsam	Sorumluluk
1	arceris-agent (Windows hizmeti)	Makine (LocalSystem)	Check-in, politika çekme, envanter, log yükleme, komut kuyruğu, PAC sunumu, CA yaşam döngüsü, kendi güncelleyicisi
2	arceris-dev (kullanıcı helper'ı)	Kullanıcı oturumu	Yerel broker, PAC'in işletim sistemine uygulanması, editör hook'ları, kullanıcı token'ı

Bu ayrımın dört mimari kararı vardır. Kimlik sınırı: makine kapsamındaki katman, yapısal olarak kullanıcı kimlik bilgilerine dokunamaz; servisten helper'a iletişim doğrudan kod içi paylaşım değil, disk üzerinden kurulur. PAC sahipliği: PAC betiği serviste sunulur — kullanıcı helper'ı yeniden başlasa da makinenin tüm web trafiği doğrudan internet çıkışına düşmez. Fail-open kararı: uç nokta zorlamaz; zorlayan kurumsal güvenlik duvarıdır. PAC "proxy; doğrudan bağlan" biçiminde yayınlanır ve hook'lar varsayılan olarak geçişe izin verir, böylece ajan bir sorunda kullanıcıyı ağdan koparmaz. Meta veri kuyruğu: gateway erişilemezken olaylar kuyruklanır; kuyruk yalnızca meta veri taşır — istem veya tamamlama içeriği asla diske yazılmaz.

Politika değişiklikleri long-poll mekanizmasıyla ajanlara saniyeler içinde ulaşır; eskiden bu iletim dakikalar sürebiliyordu. Kurulum, onaylı sürüm dağıtımı ve güncelleme akışının tamamı Bölüm 24'tedir.

Admin Arayüzü ve Kullanıcı Arayüzü¶

Arceris'te yönetim ve kullanım yüzeyleri birbirinden ayrılmıştır. Admin Arayüzü, kuralların, ayarların, kullanıcı hedeflerinin, entegrasyonların ve sistem davranışlarının yönetildiği operasyon yüzeyidir. Bu arayüz, güvenlik ve operasyon ekiplerinin ürün davranışını yönettiği ana merkezdir.

Kullanıcı tarafı yüzeyler ise ürünün kullanım bağlamına göre değişebilir. Kullanıcı paneli; Chat'i, gateway key'lerini ve sağlayıcı bağlantılarını tek yerden yönetir. Paneldeki Chat, birleşik gateway üzerinden geçer ve API istemcileriyle aynı kontrolleri paylaşır. Bu ayrım sayesinde kurumlar, yönetimsel kontrol ile son kullanıcı deneyimini birbirinden bağımsız ama tutarlı biçimde yürütebilir.

Veri Katmanı ve Destek Bileşenler¶

Arceris'in çalışma modelinde veri katmanı önemli rol oynar. Kalıcı veri — yönetim verileri, kurallar, atamalar, kullanıcılar ve denetim kayıtları — veritabanında saklanır. Operasyonel açıdan bu, ürünün tek bir makinenin belleğine bağımlı olmadan sürdürülebilir şekilde çalışmasını sağlar.

Hız ve geçici durum yönetimi gerektiren alanlar — hız limiting, bazı sayaçlar ve oturum tehdit motorunun oturum durumu — önbellek katmanındadır. Bu katman, performans ve kontrol davranışının önemli parçasıdır; geçici olarak kullanılamazsa ürün çalışmaya devam eder ve geçici durum yeniden kurulur.

Dosya güvenliği senaryolarında görsel veya PDF içeriklerinde metin çıkarımı gerektiğinde OCR tabanlı denetimler dağıtımla gelen tarama servisleri aracılığıyla yapılır. Konu sınıflandırma ve içerik moderasyonu da bu tarama servislerinde çalışır; üretim sınıflandırıcısı ModernBERT-TR'dir ve paketle birlikte gelir. Tarama servisleri istenirse devre dışı bırakılabilir.

Oturum Tehdit Motoru¶

Ayrı bir korelasyon motoru, tek bir isteğe bakıldığında görünmeyen örüntüleri oturum ölçeğinde birleştirir: aynı oturumda art arda gelen şüpheli istekler, exfiltration denemeleri ve davranışsal sinyaller tek bir tehdit skoruna dönüşür. Motorun çalışma durumu önbellek katmanında tutulur; şeffaf ve explicit yollarında çalışır. Sinyal tanımları ve panel etkisi Bölüm 21'de anlatılır.

Gözlemlenebilirlik Zinciri¶

Her istek için verilen kararlar denetim kayıtlarına işlenir; gizli değerler (anahtarlar, token'lar) kayıtlara düşmeden maskelenir. Opsiyonel izleme profili açıldığında log toplama, metrik ve pano sunumu dağıtıma eşlik eder. Denetim kayıtları, SIEM akışı ve uyarılar Bölüm 25'tedir.

Kaynak Kullanımı ve Boyutlandırma Notları¶

Kaynak kullanımını esas belirleyen, eşzamanlı büyük dosya trafiğidir; kapasite ve boyutlandırma planlaması için destek ekibiyle birlikte çalışın (bkz. Bölüm 3).

Harici AI Sağlayıcıları ile Entegrasyon Modeli¶

Arceris, farklı AI sağlayıcılarıyla çalışacak şekilde tasarlanmıştır. Ürün bir yandan upstream servislerle teknik bağlantıyı sürdürürken, diğer yandan kurumun güvenlik ve yönetişim kararlarını bu bağlantının önüne yerleştirir. Sağlayıcı kayıt defteri yerleşik sağlayıcılarla gelir, kurum kendi sağlayıcısını ekleyebilir; istek ve yanıt formatları sağlayıcılar arasında otomatik çevrilir. Bu sayede kurumlar sağlayıcı bağımsız bir kontrol mantığı elde eder. Sağlayıcı ve model kataloğu yönetimi Bölüm 8'dedir.

Bu modelde önemli olan nokta şudur: Arceris, sağlayıcıları doğrudan değiştirmeyi değil; sağlayıcı kullanımını yönetim altına almayı hedefler. Kurum hangi modeli veya hangi sağlayıcıyı kullanırsa kullansın, Arceris o kullanımın önüne ortak bir politika katmanı koyar. Gateway'in upstream bağlantıları host'un DNS çözümlemesini kullanır; bu çözümlemenin yönetimi Bölüm 29'daki Host Network ayarlarından yapılır.

Transparent Proxy İçin Sağlayıcı Farkları ve Sınırlar¶

Her AI sağlayıcısının trafik yapısı ve istemci davranışı aynı değildir. Bu nedenle Transparent Proxy kullanımında tüm sağlayıcılarda aynı davranışı beklemek doğru değildir. Bazı sağlayıcılarda tarayıcı akışları daha doğrudan ve öngörülebilirken, bazılarında farklı uç noktalar, yardımcı domain'ler, dosya akışları veya istemci davranışları devreye girer. Somut bir örnek: Gemini'nin yeni web istemcisi yazılan istemi, sohbet sunucusundan ayrı bir origin'e göndermeye başlamıştı; bu origin ilk başta hiçbir kapsamın dışındaydı ve istemler tüm kontrolleri atlıyordu — v1.3.1 bu hostu kapsama aldı. Benzer biçimde, bir AI arayüzünü dinlemek dosya yüklemelerini otomatik kapsamaz; tarayıcılar ekleri sohbet sunucusundan bağımsız CDN origin'lerine gönderir.

Bu yüzden kurumlar transparent denetim senaryolarında yalnızca teorik destek bilgisine değil, kendi hedef kullanım şekline göre doğrulama ve kabul testlerine de önem vermelidir. Operasyonel açıdan en doğru yaklaşım, Transparent Proxy kullanımını kurumun hedeflediği sağlayıcılar, istemci tipleri ve kullanım senaryoları üzerinden değerlendirmek; ardından ilgili trafiği test ederek canlı kullanıma almaktır. Yakalama listesinin ve eşlik eden hostların yönetimi Bölüm 22'dedir.