Anthropic’in Claude Code ürünü, geliştirici makinelerinde çalışan yerel ajanlar için yeni denetim araçlarıyla gündeme geldi. Şirketin compliance API’sine eklenen yerel oturum uç noktaları, endpoint üzerinde çalışan bu ajanların ne yaptığını daha net görünür kılarken, güvenlik ekiplerinin hâlâ hangi boşluklarla uğraşması gerektiğini de ortaya koyuyor.
Konunun merkezinde, Claude Code’un klasik bir sohbet botu değil, komut çalıştıran ve üçüncü taraf servislerle bağlantı kuran bir “harness” olarak tasarlanması var. Araç, kullanıcının girdisini alıp büyük dil modeline tam oturum bağlamıyla iletiyor; asıl işlem ise geliştiricinin bilgisayarında gerçekleşiyor. Bash komutları, MCP sunucuları, skills ve eklentiler üzerinden çalışan bu yapı, kimlik ve izinlerin uç noktada yaşadığı bir model oluşturuyor.
Yapılan incelemelerde yerel ajanların müşteri ortamlarında yaygın olduğu da vurgulanıyor. Token Security’nin tespitine göre yerel ajanlar, müşteri ortamlarındaki AI ajanlarının yüzde 68,6’sını oluşturuyor. Bu ajanlar çoğu zaman çalışanın mevcut kimlik bilgilerini, ağ konumunu ve yetkilerini devralıyor.
Yerel oturumlar için yeni görünürlük
Anthropic, 11 Ağustos 2026 tarihinde compliance API’ye yerel oturumlar için yeni uç noktalar ekledi. Yeni yapı, GET /v1/compliance/apps/sessions/local ile oturum meta verilerinin listesini, GET /v1/compliance/apps/sessions/local/{session_id} ile tek bir oturumun meta verilerini ve GET /v1/compliance/apps/sessions/local/{session_id}/messages ile oturum dökümünü döndürüyor.
Bu kayıtlar, modelle kurulan etkileşimi üç blok türünde saklıyor: text, tool_use ve tool_result. Böylece kullanıcı istemleri, bash komutları, okuma-yazma işlemleri ve MCP komutları tek bir oturum akışı içinde izlenebiliyor. Şirketin notuna göre model sunucu tarafında durum tutmuyor; skills ve plugins’e ait .md dosyaları yalnızca endpoint üzerinde bulunduğu için, harness her turda tam bağlamı yeniden modele gönderiyor. Modele ulaşan her şey compliance API’ye de düşüyor.
Bu görünürlük, oturum dökümlerinin doğru ayrıştırılması halinde ajan envanteri çıkarmayı da mümkün kılıyor. Hangi ajan hangi skills’i kullanıyor, hangi MCP sunucularına bağlanıyor, hangi eklentileri çağırıyor gibi ayrıntılar bu kayıtlardan okunabiliyor. Compliance API’nin şimdilik daha çok kurumsal düzeydeki yönetim işlemlerini kapsadığı, bireysel kullanıcıların yapılandırma değişikliklerinde ise kapsamın daha sınırlı kaldığı belirtiliyor.
Yapılan karşılaştırmalarda Anthropic’in kendi araçlarının tek başına yeterli olmadığı da ifade ediliyor. Özellikle destructive sonuçlar doğurabilecek ama teknik olarak meşru görünen işlemler bakımından, yalnızca model tarafındaki kayıtlarla tam bir yönetişim kurulamadığı aktarılıyor. Bu nedenle güvenlik ekipleri için üç ayrı veri katmanı öne çıkıyor: managed settings, compliance API ve endpoint kaynaklı toplama.
Managed settings ve OTel arasındaki çizgi
Claude Code kurulu her uç noktada bir managed-settings kaydı bulunuyor. Mac ve Linux sistemlerde bu kayıt bir JSON dosyası olarak tutuluyor, Windows tarafında ise registry girdileri kullanılıyor. Kurallar, global, proje ve kullanıcı ayarlarının önüne geçerek kurum genelinde bir taban politika oluşturuyor. Enterprise planda bu politikalar arayüz üzerinden uygulanabiliyor; bu plan yoksa MDM sistemleri managed-settings kaydını uç noktalar arasında yazabiliyor.
Desteklenen kontroller arasında belirli MCP sunucuları için izin ve engel listeleri, bash komutları üzerinde regex tabanlı kurallar ve skills’in komut çalıştırmasının kapatılması yer alıyor. Ancak bu mekanizma dinamik bağlamı ve niyeti göremiyor. Geliştiricilerin hareket alanını ciddi biçimde daraltırken, modern AI akışının hızına da her zaman yetişemiyor.
Compliance API’nin yanında OpenTelemetry, yani OTel de tabloya giriyor. Açık standart olan OTel, trace, metric ve event log üretmek için kullanılıyor ve çoğu harness’e yerleşik olarak geliyor. Bazı eylemler model katmanına hiç ulaşmadığı için compliance API tarafından görülmüyor. En net örnek, modelin kararından sonra ama aracın çalışmasından önce yerel olarak devreye giren hooks.
Bu hooks, bir aracın çalışmasını ya da bir istemin modele gitmesini engelleyebiliyor. OTel ayrıca hangi izin kararının kim tarafından verildiğini, bunun bir politika mı, hook mu yoksa kullanıcının onayıyla mı geçtiğini kaydediyor. bypassPermissions ve auto moduna alınan izin değişiklikleri de OTel’de yer alıyor; compliance API ise bunları her zaman görmüyor.
İki kayıt türü arasında önemli bir fark daha var. OTel atomik eylemleri günlüklemek için tasarlanmışken, oturum dökümleri uzun ve ayrıntılı JSON blokları olarak geliyor; ayrıca ayrıntı seviyesi üzerinde bir kontrol bulunmuyor. Anthropic dışı bir model kullanıldığında compliance API kapsamı tamamen kayboluyor. Bedrock, Foundry ya da Google Cloud üzerinde çalışan oturumlar bu yüzden kayda girmiyor.
Yerel oturum dökümlerinin kendi içinde hassas veri taşıyabildiği de not ediliyor. PII, secret ve müşteri verisi bu kayıtların içine girebiliyor. Bu nedenle dökümler, kendi başına hassas veri kaynağı olarak ele alınması gereken bir alan haline geliyor.
Cloud Security Alliance ile birlikte yapılan 418 kişilik IT ve güvenlik profesyoneli anketi de aynı tabloyu destekliyor. Ankete göre katılımcıların yüzde 68’i AI ajanlarına görünürlüğünü yüksek olarak değerlendirirken, yüzde 82’si son bir yıl içinde güvenlik, BT ya da yönetişim ekiplerinin varlığından haberdar olmadığı bir ajan keşfettiklerini söyledi.
Uç nokta verisi, kimlik ve izin olmadan eksik kalıyor
Endpoint telemetrisi, bulut servislerinin göremediği süreçleri, dosyaları ve yapılandırmaları açığa çıkarabiliyor. Buna karşın EDR’nin sağladığı şey bir kanıt seti; doğrudan bir yönetişim modeli değil. Araştırmada bu nedenle, ajan faaliyetinin sahibi, amacı, kimlikleri, kredileri ve izinleriyle ilişkilendirilmesinin zorunlu olduğu aktarılıyor.
Endpoint üzerinde yer alan dosyalar arasında yapılandırmalar, skills ve plugins’e ait .md içerikleri ile oturum dökümleri bulunuyor. Claude Code’un yerel geçmişi varsayılan olarak 30 gün sakladığı belirtiliyor. Bu tarihçenin hızlıca önceki çalışmaları sürdürmek için kullanıldığı, fakat yetkisiz erişim durumunda saldırganın da aynı dosyalara ulaşabileceği ifade ediliyor.
Token Security’nin analizine göre yerel bir ajanda ortalama 10’dan fazla yapılandırma dosyası bulunuyor ve bunlar endpoint’e dağılmış halde duruyor. Aynı inceleme, MCP sunucularının yüzde 35,1’inin topluluk tarafından geliştirildiğini ya da kökeninin net olmadığını gösteriyor. MCP sunucuları, endpoint üzerinde kalıcı bir kimlik bilgisi gibi çalıştığı için her bağlantı ayrı bir güven ilişkisi yaratıyor.
Oturum dökümlerini ayrıştıran ekipler için bash komutları en kolay kısım olarak öne çıkıyor. Her komut, name alanı Bash olan bir tool_use kaydı olarak görünüyor ve tam komut satırı input değerinin içinde yer alıyor. MCP tarafında ise isimler çoğu kez mcp__<server>__<command> biçiminde geliyor; Jira, Slack ve Notion gibi ilk taraf sunucular okunabilir adlarla görünürken, kullanıcı bağlantılı sunucular UUID olarak çıkıyor.
Skills daha dolaylı biçimde iz bırakıyor. Bir skill tetiklendiğinde harness, ilgili SKILL.md içeriğini modele taşımak için ya dosya içeriğini doğrudan ekliyor ya da dosya yoluna Read işlemi yapıyor. Böylece hem skill adı hem de konumu ortaya çıkıyor. Plugins ise tek bir dosya olmaktan çok, skills ve script’leri bir araya getiren bir paket olduğu için daha zor ayrıştırılıyor; yine de script ya da .md dosyalarından biri Read edildiğinde adın izi sürülebiliyor.
Tüm bu tablonun ortasında, yönetişimin yalnızca ne olduğuna değil kimin yaptığına ve neden yaptığına da bağlanması gerektiği vurgulanıyor. Savunma tarafı için asıl ayrım, meşru bir eklentiyi kullanan mühendis ile internette dolaşan zararlı bir eklentiyi çağıran ajanı aynı kayıtlar üzerinden ayırt edebilmekte yatıyor. Kimlik katmanı bu noktada endpoint ve oturum verisini uygulanabilir güvenlik kararlarına dönüştüren kontrol düzeyi olarak konumlanıyor.
Anthropic’in compliance API’ye eklediği yerel oturum uç noktaları, Claude Code gibi endpoint üzerinde çalışan AI ajanlarına daha fazla görünürlük getiriyor. Ancak managed settings, OTel ve endpoint toplaması birlikte kullanılsa bile, erişimi sahibine, amacıyla ve yetki zinciriyle ilişkilendiren kimlik bağlamı olmadan tam bir yönetişim kurulamadığı belirtiliyor.