AI ajanı güvenliği tek bir kuralla başlar: AI ajanınız asla kimlik bilgilerinizi tutmamalı. Bunu sağlayan 38 yıllık aracı desenini burada bulabilirsiniz.
AI ajanları kafası karışık vekillerdir. Bu, 38 yıllık bir güvenlik desenidir ve çözümü de en az o kadar eskidir: aracı — güvenilir, gözlemlenebilir, deterministik, denetlenebilir, taklit edilemez, kapsamı daraltılmış, politika odaklı, AI olmayan bir ara katman — ajan ile çağırması gereken SaaS API'leri arasına yerleştirilir ve ajanınızın sahip olmaması gereken kimlik bilgilerini tutar.
1988 yılında Norm Hardy, Tymshare'daki zamanından gerçek bir olayı anlatan kısa bir makale yayımladı. FORT adında bir Fortran derleyicisi, SYSX adlı bir sistem dizininde bulunuyordu. Kullanım istatistiklerini toplamak için derleyicinin (SYSX)STAT'ya yazması gerekiyordu, bu yüzden işletim sistemi FORT'a SYSX içindeki herhangi bir dosyaya yazma yetkisi veren bir "ev dosyaları lisansı" vermişti. Sistemin faturalama dosyası (SYSX)BILL da oradaydı. Derleyiciyi çağıran bir kullanıcı, isteğe bağlı hata ayıklama çıktısı almak için bir dosya adı belirtebiliyordu. Bir gün bir kullanıcı (SYSX)BILL girdi. Derleyici, işletim sisteminden bu dosyayı yazmak için açmasını istedi; işletim sistemi, ev dosyaları lisansını göz önünde bulundurarak izin verdi. Faturalama verileri üzerine yazıldı. Derleyici tam olarak tasarlandığı gibi çalıştı. Hata mimarideydi.
Hardy buna kafası karışık vekil problemi adını verdi: ayrıcalıklı bir program (vekil) kendi yetkisine sahiptir; daha az ayrıcalıklı bir çağıran ondan bir şey yapmasını ister; vekil, kimin yetkisiyle hareket ettiğini karıştırır ve kendi yetkisini kullanır. Çözüm, bu yetkiyi tamamen vekilden almak ve çağrıyı isteğe bağlı olarak arka planda yöneten ayrı bir katmanın arkasına koymaktır. O katman aracıdır.
Otuz sekiz yıl sonra, şirketinizin çalıştırdığı her AI ajanı bir kafası karışık vekildir. Ve çoğu, aracı olmadan çalışıyor.
Neden AI ajanları güvenlik sorununu daha da kötüleştiriyor
Hardy'nin FORT'u tek bir giriş kanalına sahipti: komut satırı. Modern bir AI ajanının ise onlarcası var: e-posta gövdeleri, getirilen web sayfaları, yüklenen PDF'ler, MCP sunucularından gelen araç çıktıları, çoklu ajan sistemlerinde diğer ajanlardan gelen mesajlar. Bağlam penceresine düşen her şey talimat verebilir ve tasarım gereği ajan bunların hepsini meşru olarak kabul eder.
Bu, geleneksel erişim kontrolünün dayandığı bir varsayımı bozar: çağıran, girdiyi kontrol eder. Bir web uygulamasında, çağıran (kimliği doğrulanmış oturum) ve girdi (HTTP istek gövdesi) aynı kaynaktan gelir. Bir ajan için çağıran, istemi şekillendiren herkestir; yani bir e-posta yazabilen veya bir arama sonucunu tohumlayabilen bir saldırgan da çağıran olabilir.
Kasım 2025'da, PromptArmor'dan güvenlik araştırmacıları bunun üretimde nasıl göründüğünü gösterdi. Kötü niyetli talimatları bir entegrasyon rehberinde 1 piksel fontla gizlediler. Bir geliştirici Google'ın Antigravity IDE'sini buna yönlendirdiğinde, ajan kendi .gitignore tabanlı dosya korumasını cat'a komut vererek aştı. Sonra .env dosyalarının içeriğini, Antigravity'nin kendi tarayıcı alt ajanı üzerinden saldırganın kontrolündeki bir webhook.site URL'sine sızdırdı. Kullanıcı her şeyi doğru kurmuştu. Sandbox çalıştı. Ajan, kullanıcının ne istediğiyle girdinin ne talep ettiğini ayırt edemedi.
Aynı FORT şekli, onlarca yıl sonra: geniş yetki, güvenilmeyen girdi, ikisini ayırmanın yolu yok.
Topluluğun cevapları var. Sadece dağınık durumdalar.
Bu yeni bir sorun değil. Güvenlik topluluğu onlarca yıldır cevaplar yazıyor:
Yetenek tabanlı güvenlik (Dennis & Van Horn, 1966; daha sonra E dili ve Mark Miller'ın Google'daki Caja çalışması). İlke: kimlik veya konuma dayalı genel yetki vermeyin; programın erişebileceği her kaynak için açık, taklit edilemez yetenekler iletin. Bir yetenek, ne yapabileceğinizi ve neye yapabileceğinizi birleştirir ve başka bir şeyle karıştırılamaz.
Aracılı Kimlik Bilgileri (OWASP LLM Top 10 tarafından kodlanmıştır). API jetonlarını LLM'in bağlamına koymayın. Güvenilir bir ara katman, çağrıyı ajan adına yapar; model ne yapılacağına karar verir, aracı nasıl yapılacağını yönetir. Modelden kimlik bilgilerini yazdırmasını isteyen bir istem, işe yarar hiçbir şey elde edemez. Kimlik bilgileri orada değildir.
Phantom Token Pattern (Curity, ilk olarak mikroservislerde OAuth için). Ajan gerçek taşıyıcı jetonu değil, opak bir oturum tanıtıcısı tutar. Bir proxy, tanıtıcıyı doğrular, gerçek kimlik bilgisini ağ kenarında ekler ve yukarıya iletir. Ajan ortamını sızdırırsa, saldırgan oturum sona erdiğinde süresi dolan bir dize elde eder.
Tam zamanında kimlik bilgisi ekleme (Aembit gibi iş yükü kimliği sistemleri). Uzun ömürlü jetonlar vermek yerine, her çağrı için kısa ömürlü, kapsamı daraltılmış bir kimlik bilgisi oluşturun.
Bunların hiçbiri literatürde eksik değil. Varsayılanlarda eksik. Çoğu ajan platformu hâlâ modele bir OAuth jetonu veriyor, arada aracı olmadan, ve en iyisini umuyor.
Zero'nun aracı nasıl çalışır
Yukarıdaki desenlerin hiçbirini biz icat etmedik. Hepsini, Zero'daki her ajan için varsayılan olarak çalışan tek bir aracıda birleştirdik. Bu, o desenlerin tarif ettiği güvenilir ara katmandır ve bir AI ajan platformu için inşa edilmiştir. Bir ajanın bir bağlayıcıya yaptığı her çağrı aracıdan geçer. Her bağlayıcı bir dış SaaS'tır (Slack, GitHub, Notion vb.).
Aracı, her ajan ile her bağlayıcı arasında yer alır. Gerçek kimlik bilgileri yalnızca kesikli çizginin aracı tarafında bulunur.
Bunu üç katman olarak düşünün.
1. Kimlik bilgisi izolasyonu
Ajanın sandbox'u asla gerçek bir bağlayıcı kimlik bilgisi tutmaz. Bir SaaS'ı Zero'ya bağladığınızda, OAuth jetonu veya API anahtarı aracı tarafında saklanır. Sandbox, mevcut araçların çalışmaya devam etmesi için bir ortam sırrı gibi görünen bir yer tutucu dize alır, ancak hiçbir SaaS bunu kabul etmez.
Ajan, kayıtlı bir bağlayıcı ana bilgisayarına istek yaptığında, aracı isteği eşleştirir, bağlayıcının kimlik doğrulama şablonunu çözer ve gerçek kimlik bilgisini ağ kenarında ekler. İstek, geçerli kimlik doğrulama ile yukarıya gider; ajan işe yarar hiçbir şey tutmamıştır. Ortam değişkenlerini döken istemlemiş bir ajan, saldırgana SaaS jetonu yerine bir yer tutucu verir.
Bu, phantom token deseninin AI ajanlarına uygulanmış halidir.
2. Bağlayıcı politika kapısı
Zero'daki bir bağlayıcı, aç/kapa anahtarından fazlası olmalıdır. Her bağlayıcı, kapsadığı API tabanlarını ve kimlik doğrulamanın nasıl eklenmesi gerektiğini tanımlar. Yukarı hizmet, kararlı bir kapsam-ucu eşlemesi yayınlıyorsa, her yöntem ve yol için hangi adlandırılmış iznin geçerli olduğunu da tanımlayabilir. Slack'in slack-api-ref örneği iyidir.
Yani Slack'e bağlı bir ajan chat.postMessage çağrısı yaptığında, aracı bu isteği chat:write ile eşleyebilir. Denetim günlüklerini okuduğunda, bu admin.analytics:read olur. Her ajan için, permission_policies bu adlandırılmış izinlerin nasıl davranacağını tanımlar: izin ver, reddet veya sor. Politika, kimlik doğrulama eklenmeden önce aracıda uygulanır, modele bir ipucu olarak değil. Ajan, reddedilmiş bir izinle kapsanan bir çağrı yapmaya çalışırsa — belki istem enjeksiyonu nedeniyle — çağrı asla yukarıya ulaşmaz.
Bugün her bağlayıcıda bu çözüm yok. Bazı yukarı API'ler kararlı bir kapsam-ucu eşlemesi yayınlamaz. GitHub'ın GraphQL yüzeyi bunun tipik örneğidir: REST tarafı eşlenebilir, ancak GraphQL tarafı henüz eşlenemez. Bu bağlayıcılarda, aracı yine de kimlik bilgisi eklemesini ve ağ yolunu kontrol eder, izin kapısı ise platformun gerçekten uygulayabildiği daha kaba bağlayıcı veya ana bilgisayar düzeyindeki politikaya geri döner. Yukarıdan veri geldikçe bunları dolduruyoruz. Kapsamadığımız alanlar için iddiada bulunmuyoruz.
Jetonlar genel yetki taşımaz. Yetki, yukarıda desteklenen çözünürlükte, ajan başına aracılıdır. Bu, cevabın yetenek tabanlı yarısıdır.
3. Operasyonel döngü ve denetim
En az ayrıcalık, yalnızca hata modu kullanılabilir olursa işe yarar. Ajanlar büyür. Altı hafta sonra, Notion'dan okuma yapan bir araştırma ajanı, özetini geri yazmak isteyebilir. Diğer yerlerdeki yaygın hata modları: ajan yeni izinsiz sessizce çalışmaz ve bozulur ya da operatör panikle fazla yetki verir ve asla geri almaz.
Reddedilen bir bağlayıcı isteği, yapılandırılmış bir 403 döndürür: bağlayıcı, yöntem, yol, temel URL ve aracı tanımlayabildiğinde eşleşen izin adları. Ajanın sistem istemi, reddin nasıl teşhis edileceğini ve tam olarak hangi izne takıldığını nasıl isteyeceğini anlatır, kullanıcı veya yönetici için tek tıkla onay URL'si üretir. Böylece yetki yükseltme yolu, istenen izne bağlı kalır ve "her şeye izin ver"e dönüşmez.
İzin değişikliği istekleri bir kuyruğa alınır. Sahipler ve yöneticiler bunları panelden onaylayabilir veya reddedebilir; onaylanan istekler ajanın politikasını günceller ve sonraki deneme başarılı olur. Çoğu platform bu döngüyü atlar. Onsuz, "en az ayrıcalık" sunumda kalır, üretime geçmez.
Aynı aracı yolu denetimi de besler. Çalıştırma başına ağ günlükleri, HTTP, TCP, DNS ve TCP dışı trafik için daha alt düzey paket gözlemleri dahil olmak üzere sandbox ağ etkinliğini kaydeder. Bağlayıcıyla eşleşen istekler, yapılandırılmış aracı meta verisi içerir: bağlayıcı, mevcutsa eşleşen izin, izin ver/ret sonucu, kimlik doğrulama çözümleme meta verisi ve faturalandırılabilir bayrak. Sonradan biri "bu ajan Salı günü saat 15:00'te ne yaptı?" diye sorarsa, cevabı bu kayıtlardan yeniden oluşturursunuz. Önleme her şeyi yakalayamaz. Denetim izi, ne olduğunu bulmanın yoludur.
Çözmediğimiz noktalar
Yukarıdakilerin hepsine rağmen, meşru bir chat:write iznine sahip bir ajan, zaten erişimi olan bir kanala utanç verici bir mesaj göndermeye ikna edilebilir. Aracı, etki alanını daraltır; tamamen ortadan kaldırmaz.
Cevabın diğer yarısı, yüksek riskli eylemler için onay, çıktı doğrulama ve araç dönüşlerini varsayılan olarak güvensiz kabul etmektir. Bu çalışmalar yol haritasında, üründe henüz yok. Kafası karışık vekil sorununu uçtan uca çözdüğünü iddia eden biri size bir şey satmaya çalışıyordur.
Bu taban olmalı, özellik değil
Yetenek tabanlı güvenlik 1970'lerden beri var. Aracılı kimlik bilgileri OWASP LLM Top 10'da. Phantom token'lar LLM çağından önceye dayanır. Bunların hiçbiri cevabı kimsenin bilmemesinden dolayı eksik değil. Eksik çünkü erken ajan platformları "demoyu çalıştır" için optimize etti ve güvenliği sonraki sürüme bıraktı, ki çoğu zaman o sürüm hiç gelmedi.
Bir sonraki nesil platformlar daha yükseği hedeflemeli. Jetonlar model bağlamına girmemeli. Yetki ajan başına ayrı ayrı tanımlanmalı. Yetki yükseltme bir insan üzerinden geçmeli. Her işlem baştan sona denetlenebilir olmalı. Bunların hiçbiri yeni değil. Hepsi taban olmalı.
Bir ajan platformu seçerken, "güvenli mi?" sorusu sizi bir yere götürmez. Her satıcı evet der. Daha iyi bir soru: bana aracını göster ve bir ajan sahip olmadığı bir kapsam istediğinde ne olduğunu adım adım anlat.
Aracı, Zero'daki her ajanın önünde varsayılan olarak yer alır. Bağlayıcı envanteri, kapsam eşlemeleri, izin politikaları ve aracı mantığının tamamı Zero'nun kaynak deposunda bulunur. Kapsamadığımız bir bağlayıcı mı buldunuz? Bir sorun bildirin.
Kaynaklar
Temel
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (yetenek sistemlerinin kurucu makalesi)
- Mark Miller ve diğerleri, Caja: web için yetenek tabanlı güvenlik, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Atıf yapılan gerçek dünya olayları
- PromptArmor, Google Antigravity Exfiltrates Data, Kasım 2025
- Simon Willison, kapsam ve analiz, 25 Kasım 2025
