Edera OCAP: Yapay zeka ajanlarına ham kimlik bilgileri yerine dar kapsamlı yetenekler

Edera, bounded authority (sınırlı yetki) adını verdiği, object-capability güvenliğinin (OCAP) yapay zeka ajanlarına ve Kubernetes workload'larına ürün düzeyinde uygulanmış hali olan güvenlik modelini ortaya koydu. Hacker News ana sayfasına kadar yükselen bir yazıda şirket, ajan güvenliğine standart yaklaşımın — önce bir kimlik bilgisi vermek, sonra ortamı politikalarla sarmalamak — mantığını tersine çevirdiğini savunuyor. Modelinde bir workload, kendisine bir yetenek verilene kadar hiçbir yetkiye sahip değildir ve bu yetenek tek bir kaynak üzerindeki tek bir işlemle sınırlanabilir.

Ortamdan gelen yetki sorunu

Edera'ya göre temel sorun, kimlik bilgilerinin kaba araçlar olması. Bir programa dosya sistemi erişimi verirseniz, o dosya sisteminden erişilebilen her sır, yapılandırma dosyasında ve kaynak kodunda ona emanet edilmiş olabilir. Bir MCP sunucusuna bulut kimlik bilgisi verirseniz, o sunucunun ele geçirilmesi dar kapsamlı bir entegrasyonu çok daha geniş bir olaya dönüştürebilir.

Edera'ya göre geleneksel yanıtı, ortamın çevresine katmanlar halinde denetimler yerleştirmektir: güvenlik duvarları, sandbox, kimlik sistemleri, secrets manager'lar, admission control, network policy, prompt denetimi ve giderek karmaşıklaşan izin listeleri. Bunlar yararlıdır ama hepsi aynı varsayımı paylaşır: workload zaten yetkiye sahiptir ve güvenliğin işi bu yetkinin nasıl kullanılacağını kısıtlamaktır.

Ortamdan gelen yetkiden yeteneklere

Ortamdan gelen yetki (ambient authority), bir programın yalnızca nerede ya da nasıl çalıştığı için kullanabildiği yetkidir: bir süreç Unix kullanıcısı olduğu için bir dizini okur, bir pod'a bulut kimliği bağlı olduğu için bir API'yi çağırır, bir ajan ortamında bir token bulunduğu için bir GitHub deposuna erişir. Edera'nın anlatımındaki tehlike şudur: workload ele geçirilirse, yetkisi de onunla birlikte ele geçirilir.

Object capability'ler bu ilişkiyi tersine çevirir. Yetki, belirli bir nesneye ya da hizmete yapılan taklit edilemez bir referansla taşınır ve bir nesne, elindeki referansların izin verdiği kadarını kullanabilir. Edera bunun ajanlar için geleneksel güvenilir uygulamalardan daha önemli olduğunu savunuyor; çünkü bir LLM'nin davranışı dinamik olarak üretilir, güvenilmeyen bağlamı işleyebilir ve prompt injection ile yönlendirilebilir. Bir ajanın tek bir depoyu değiştirme yetkisi varsa, ajanın ele geçirilmesi geliştiricinin erişebildiği her depoyu açığa çıkarmaz; bir MCP sunucusu yalnızca açıkça verilmiş üç komutu çağırabiliyorsa, bir ihlal keyfi komut çalıştırmaya dönüşmez. Sınır, modelin davranışı değil, yetkinin kendisidir.

Bounded authority ne ekliyor

Bir object capability, geleneksel erişim denetiminin ayrı tuttuğu iki şeyi birleştirir: atıf (designation), yani hangi nesneye ya da hizmete erişildiği ve yetki (authority), yani onunla ne yapılabileceği. Geleneksel kurulumda ajan bir kimlik olarak kimlik doğrular ve harici bir politika sistemi her isteği karara bağlar. Bir capability sisteminde ise yetkinin kanıtı verilen yeteneğin kendisidir — Edera bunu write(project-a) olarak özetliyor; burada sahibinin genel amaçlı bir GitHub token'ına ihtiyacı yoktur, bir kimlik bilgisinin başka hangi depolara erişebileceğini bilmez ve yeniden kullanılabilir bir sır taşımaz.

Edera'nın bounded authority'si, belirli bir kaynak, işlem, kimlik ya da üçünün birleşimi etrafında bilinçli olarak kısıtlanmış bir object capability'dir. Yazı github.write(repository="acme/payments") ifadesini sıradan GitHub kullanımıyla, command.execute("git diff") ifadesini de shell.execute(anything) ile karşılaştırıyor. Her iki durumda da izin açıktır ve o ajana bağlıdır; ajanın yapabileceği başka bir şey yoktur. Edera bunu, güvenlik ekiplerinin gerçekten sorduğu soruyu yanıtlamak olarak çerçeveliyor — bu ajan üretimde tam olarak ne yapabilir — bir pod'un doğru rolle ilişkilendirilip ilişkilendirilmediği sorusunun değil.

capcurl: Kimlik bilgisi olmadan HTTP

En somut parça, HTTP'yi bir bounded authority olarak ele alan Edera'nın capcurl aracı. Bir broker kimlik bilgisini — örneğin bir GitHub token'ını — tutar ve yalnızca ajanın gerçekleştirebileceği işlemi temsil eden bir yetenek sunar; örneğin tek bir belirli deponun pulls endpoint'ine yapılan bir POST isteği. Edera, yeteneğin hız, yollar, kimlik, başlıklar, hedef, HTTP yöntemi ve istek biçimi üzerinde ek kısıtlamalar taşıyabileceğini söylüyor. Ajan yalnızca yeteneği çağırır ve broker isteği kimlik doğrulamalı API çağrısına çevirir. Codex veya Claude Code gibi kodlama ajanları bu nedenle token'ı hiç görmez; dolayısıyla bir prompt injection, bağımlılık ihlali ya da kötü niyetli araç çağrısı, en fazla yeteneğin tanımladığı dar kapsamı kullanabilir.

Neden önemli

Ajan güvenliği tartışmaları genellikle model davranışı etrafında döner — daha iyi filtreleme, daha iyi prompt'lar. Edera'nın önerisi sorunu altyapıya kaydırıyor: bir ajan hiçbir zaman kimlik bilgisi elinde tutmuyorsa, injection ve ele geçirme, politikayla dayatılan bir tavana değil, yapısal ve sert bir tavana çarpar. Bu, bugün rutin olarak uzun ömürlü token'larla çalışan MCP sunucuları ve kodlama ajanları için anlamlı bir yeniden çerçeveleme. İki uyarıya dikkat çekmek gerek. Bu, kendi tasarımını anlatan tek kaynaklı bir satıcı yazısı ve dolaşımdaki metin, yetenek broker'larının nasıl dağıtılacağı, denetleneceği ve iptal edileceği gibi operasyonel sorulara değinilmeden kesiliyor. Bu ayrıntılar, capability sistemlerinin pratikte başarılı olup olmayacağını genellikle belirler.