Bir agent ilk destek görevini doğru tamamladı, ardından gerçek güvenlik sorununu gösterdi. Siparişi okumasını sağlayan credential aynı zamanda iade başlatabiliyor, müşteriyi değiştirebiliyor ve kaydı silebiliyordu. Prompt bunları yapmamasını söylüyordu. Sistem açısından bu cümleyi güvenlik sınırı kabul etmek için hiçbir neden yoktu.
Geniş API key taşıyan agent, iyi muhakemeli bir asistan değildir. Fazla yetkili bir entegrasyonun olasılıksal bir kontrolcüyle birleşmesidir.
Hesaptan değil yetenekten başlayın
Agent hangi çalışan hesabını kullansın diye sormayın. Workflow'un ihtiyaç duyduğu işlemleri tek tek yazın. Sipariş durumunu okumak, iç not eklemek ve yanıt taslağı hazırlamak ayrı yeteneklerdir. Yanıt göndermek, iade yapmak ve adres değiştirmek de öyle.
Bunları typed input ve açık output kullanan dar tool'lar olarak sunun. manage_order adlı bir tool çok fazla şeyi saklar. get_order_status, draft_support_note ve request_refund_approval gibi araçlar yetkiyi kodda ve logda görünür yapar. Kimlikleri, izin verilen state'leri ve tutarları modelin dışında doğrulayın. Agent aracı seçebilir, aracın ne yapmaya yetkili olduğunu tanımlamamalıdır.
Tool arkasındaki credential'ı daraltın
Model context içinde yeniden kullanılabilir secret bulunmamalı. Credential sunucu tarafındaki tool katmanında yaşar ve işleme göre seçilir. Ayrı workflow'lar için ayrı service identity kullanın. Sağlayıcı destekliyorsa kısa ömürlü token üretin. Audience, resource ve action kapsamını kısıtlayın.
Bu AI'a özel yeni bir fikir değil, klasik least privilege yaklaşımıdır. OAuth güncel güvenlik uygulaması, access token yetkilerinin gereken asgari kapsamla sınırlandırılmasını, token'ın hedef kaynak ve aksiyona bağlanmasını önerir. Güvenliği sağlayan system prompt değil, resource server üzerindeki uygulamadır.
Development, test ve production ortamlarında aynı entegrasyon anahtarını paylaşmayın. Anahtar rotasyonu prompt değiştirmeden veya ilgisiz agent'ları deploy etmeden yapılabilmeli.
Read-only doğru başlangıçtır
Retrieval ile başlayın. Agent context toplasın, işi sınıflandırsın ve aksiyon önersin. Yazma işlemini önce kişi veya deterministik servis yapsın. Bunun nedeni her write işleminin tehlikeli olması değil. Read yolu, eksik veriyi, belirsiz kimlikleri ve edge case'leri iş durumunu değiştirmeden görünür kılar.
Write erişimini işlem işlem ekleyin. Dar etkili ve idempotent işlemler daha erken otomatikleşebilir. Geri alınamaz aksiyonlar, para hareketi, dış iletişim ve yetki değişimi daha güçlü kapı ister. Onay, önerilen kesin payload'a bağlanmalıdır. Genel bir onaydan sonra yeniden üretilen farklı aksiyon, onaylanmış sayılmaz.
Neden sorusunu yanıtlayan audit trail tutun
Her tool call için agent run, doğrulanmış principal, tool adı, validate edilmiş argümanlar, policy kararı, sonuç referansı ve zamanı kaydedin. Log içine ham secret veya gereksiz kişisel veri koymayın. Ne değiştiğini ve agent'ın hangi kanıtı kullandığını yeniden kurmaya yetecek bilgi bulunsun.
Log, model önerisini, policy reddini, insan onayını ve tamamlanmış side effect'i ayırmalı. Olay anında bu ayrım gerekir. Evals için de değerlidir. Hatanın retrieval, reasoning, policy veya downstream sistemden geldiği görülebilir.
Bu hafta bir workflow'u sıkılaştırın
En geniş credential'a sahip agent'ı seçin. Mevcut bütün izinleri ve başarılı son çalışmalarda gerçekten kullanılan tool'ları çıkarın. Yalnızca kesişimi taşıyan yeni bir service identity oluşturun. Yıkıcı veya dışarıdan görünen işlemleri açık onaya bağlayın. Policy kararsızsa retrieval güvenli fallback olsun.
Ardından reddedilmesi gereken yolları özellikle test edin: başka tenant kaydı, fazla tutar, tekrarlanan istek, süresi dolmuş token ve bilinmeyen alan içeren tool çağrısı. Güvenli agent hiç yanlış aksiyon istemeyen değildir. Çevresindeki sistem bu aksiyonu temiz biçimde reddedebiliyor, reddi kaydedebiliyor ve güvenle devam edebiliyorsa güvenlidir.