İçeriğe atla

Kapatmak için ESC tuşuna basın

Agent Baseline: yapay zekâ agent’ları için 35 açık güvenlik kontrolü

Agent Baseline, AI agent'lar için altı hedef ve 35 sürümlenmiş kontrol tanımlıyor. Platform ekipleri envanter ve kill switch testiyle başlayabilir.

Yazar
Sezer Şanlıkan
Yayın
2 Kasım 2026,
Okuma
4 dakika
Agent Baseline kontrolleri ve Blueprint Alliance referans mimarisi
Bu haberde
  1. Model Context Protocol nedir, ne işe yarar?
  2. Agent Baseline’ın altı hedefi
  3. Ödünç alınan kimlik sorunu
  4. Politikadan önce envanter
  5. Kill switch’i ihtiyaç doğmadan deneyin
  6. Taslağı okurken dikkat edin

Docker, Snyk ve Keycard’ın hazırladığı Agent Baseline, yapay zekâ agent’ları için altı hedef ve 35 açık, sürümlenmiş kontrol tanımlıyor; güncel sürüm v1.0-draft. Docker, Okta, AWS, CrowdStrike, Google Cloud ve Wiz’in de aralarında bulunduğu Blueprint Alliance’ın kurucu üyeleri arasında yer alıyor.

Model Context Protocol nedir, ne işe yarar?

Model Context Protocol (MCP), yapay zekâ modellerinin ve agent’ların harici araçlara, veri kaynaklarına ve servislere standart bir arayüzle bağlanması için tanımlanmış açık bir protokoldür. Bir MCP server, bir aracı ya da veri kaynağını agent’a açar; agent bu server üzerinden komut çalıştırır veya veri okur. IDE eklentileri, kodlama agent’ları ve kurumsal entegrasyonlarda yaygın olarak kullanılıyor.

Agent’lar için bugüne kadar elde tehdit listeleri vardı. Neyin ters gidebileceğini anlatıyorlardı, ama denetimde neyi kontrol edeceğinizi söylemiyorlardı. Agent Baseline bu boşluğu doldurmaya çalışıyor. Her kontrolün kalıcı bir kimliği var; bir audit bulgusunda ya da RFP (Request for Proposal) yanıtında doğrudan atıf yapabiliyorsunuz.

Platform ve güvenlik ekipleri için pratik sonuç şu: “agent governance” herkesin farklı anladığı bir kavram olmaktan çıkıp madde madde kontrol edilebilir bir listeye dönüşüyor. Liste henüz taslak, ama yön belli.

Agent Baseline’ın altı hedefi

Kontroller altı başlıkta toplanıyor. Bunları elinizdeki araçlarla şöyle eşleyebilirsiniz:

  • Discover: hangi agent’ın hangi makinede, hangi MCP (Model Context Protocol) server’a bağlı çalıştığı
  • Constrain: agent’ın çalıştığı ortamın sınırları; CON-03 izole ve kısıtlı execution istiyor
  • Authorize: identity provider’daki yetkiler ve token kapsamları
  • Observe: SIEM (Security Information and Event Management) sistemine akan log’lar
  • Validate ve Respond: kontrollerin gerçekten çalıştığını kanıtlamak ve olay anında müdahale

Kaynağın altını çizdiği tasarım kararı işinizi kolaylaştırıyor. Kontroller yeni bir ürüne taşınmıyor, bugün durdukları yerde kalıyor: identity provider, sandbox ve SIEM. Yani yeni araç almadan önce elinizdeki yapıyı taslağa karşı puanlayabilirsiniz.

Ödünç alınan kimlik sorunu

Yazıda sayılan yeni risklerden operasyon ekibine en yakın olanı bu. Agent genelde kullanıcının kimliğini üstleniyor. Kullanıcı neyi okuyup silebiliyorsa agent da onu yapabiliyor. Log’lar ise işlemi çoğunlukla kullanıcı yapmış gibi kaydediyor.

Bir geliştiricinin makinesindeki agent’ı düşünün. Önce birkaç komuta izin veriliyor, sonra dosya sistemi erişimi genişliyor. Ardından GitHub, bir bulut aracı ve bir MCP server bağlanıyor. Her adım tek başına makul. Toplamda ise bulut credential’ı ile dışarıya veri gönderebilen bir araç aynı oturumda buluşuyor. Kaynağın “risky combinations” dediği durum tam bu: araçların hiçbirinde bilinen güvenlik açığı yokken bile güvenilmeyen girdiden hassas veriye, oradan dış iletişime giden yol tamamlanabiliyor.

Politikadan önce envanter

Blueprint Alliance ve Agent Baseline aynı sırayı öneriyor: önce discovery, sonra policy. Göremediğiniz agent’a politika yazamazsınız. İlk hafta için makul bir iş listesi:

  1. Geliştirici makinelerinde ve CI (Continuous Integration) runner’larında hangi agent araçlarının çalıştığını çıkarın.
  2. Her agent’ın bağlandığı MCP server’ları ve kullandığı token’ları listeleyin.
  3. Token kapsamlarını kullanıcının kendi yetkisiyle karşılaştırın. Agent’a kullanıcının tam yetkisini vermek varsayılan olmasın.
  4. Agent işlemlerinin log’larda kullanıcı işlemlerinden ayırt edilip edilemediğine bakın.

Alliance’ın dört sorusu bu listeyi denetimde savunmak için iyi bir iskelet: agent’larım nerede, ne yapabilirler, ne yapıyorlar, nasıl müdahale ederim.

Kill switch’i ihtiyaç doğmadan deneyin

Containment için process’i öldürmek yetmiyor; credential’ların ve oturumların da iptal edilmesi gerekiyor. Agent’lar sub-agent başlatıp yetkiyi zincir boyunca aşağı aktarabiliyor. Tek bir process’i durdurmak açık kalan oturumları kapatmıyor. Alliance whitepaper’ı da runtime desteği olmadan yalnızca API üzerinden yapılan containment için “provides a false sense of security” diyor.

Bir tatbikat planlayın. Test ortamında bir agent’ı yan etki yaratmadan durdurun, kullandığı token’ları iptal edin, sonra bu token’ların gerçekten geçersiz olduğunu doğrulayın. Geçen süreyi ölçün. Agent’lar asenkron çalıştığı için hatalı bir talimat, biri müdahale etmeden eyleme dönüşebiliyor.

Taslağı okurken dikkat edin

Metin Docker’ın kendi blogundan. Docker Sandboxes, MCP Gateway ve Hardened Images’ı Agent Baseline kontrolleriyle eşleştiriyor. Bu eşleme satıcının kendi değerlendirmesi. CON-03’ü hangi araçla karşılayacağınıza kontrol metnini agentbaseline.org üzerinden okuyup siz karar verin; kontrollerin açık yayımlanması tam olarak buna yarıyor.

Sürümün v1.0-draft olması, kontrol kimliklerinin ve içeriğinin değişebileceği anlamına geliyor. Audit belgelerinde kontrol kimliğine atıf yaparken sürümü de not edin. Alliance’ın OCSF (Open Cybersecurity Schema Framework), SSF (Shared Signals Framework) ve CAEP (Continuous Access Evaluation Profile) üzerindeki birlikte çalışabilirlik testleri ve referans entegrasyonları yayımlandığında, SIEM ve identity provider entegrasyonunuzu bunlarla karşılaştırmak ucuz ve hızlı bir başlangıç noktası olur.

İlgili haberler

Tüm haberler

Yeni yazılardan haberdar olun

Sunucu, Kubernetes, DevOps ve güvenlik üzerine yeni yazılar ve site duyuruları e-postanıza gelsin. Reklam yok, adresiniz kimseyle paylaşılmaz.

© 2021–2026 Sezer Şanlıkan