Ajan Protokol Yığını 2026: MCP, A2A ve Kurumsal Agent Güvenliği

TL;DR — 2026'da ajan protokol yığını nihayet şekillendi: araçlar için MCP, ajanlar arası iletişim için A2A, web için WebMCP. MCP çoğu kurumun ihtiyacını tek başına karşılıyor — ajanı araçlara ve veriye bağlıyor. A2A ise farklı üreticilerin ajanlarının birbirini keşfedip görev devretmesini sağlıyor. Ama her yeni protokol, standartlaştırdığı saldırı yüzeyini de genişletiyor: araç açıklamaları ve web içeriği prompt injection vektörüne, ajanlar arası devir "confused deputy" riskine, ödeme otonomisi ise her yukarı akış ihlalinin bedelini büyüten bir kaldıraca dönüşüyor. OWASP artık agentic uygulamalar için bir ilk-on listesi yayımlıyor. Bu yazıda protokolleri, mimari kararı ve kurumsal güvenlik kontrollerini sahadan bir gözle anlatıyorum.

Bir yıl önce herkes "hangi ajan protokolü kazanacak?" diye soruyordu. 2026'da cevap netleşti: hiçbiri tek başına kazanmadı, çünkü farklı katmanlara hizmet ediyorlar. Yığını şöyle düşünün: MCP araç erişimi için, A2A ajanlar arası koordinasyon için, WebMCP web tarayıcısı içindeki etkileşimler için. Bunların üzerine anlamsal katman, kimlik, ödeme ve güvenlik protokolleri ekleniyor. Yani "TCP/IP kazandı" demek gibi — tek bir protokol değil, katmanlı bir mimari kazandı.

Bu ayrımı anlamak neden önemli? Çünkü çoğu kurum yanlış soruyu soruyor. "A2A'ya mı geçsek, MCP'ye mi?" diye sormak, "HTTP mi kullansak TCP mi?" diye sormak gibi; ikisi farklı işler yapıyor. Sahada gördüğüm gerçek şu: 2026'da çoğu kurum için tek başına MCP, YZ entegrasyon değerinin büyük kısmını karşılıyor — ajanları araçlara ve veriye bağlamak. Gartner'ın kurumsal uygulamaların önemli bir kısmının çok-tedarikçili YZ ekosistemlerine kayacağı öngörüsü, bu standartlaşmanın neden bu kadar kritik olduğunu gösteriyor.

MCP'yi (Model Context Protocol) bir ajanın dış dünyaya açılan standart soketi olarak düşünün. Daha önce her araç entegrasyonu özel kod gerektiriyordu; MCP ile araçlar, veri kaynakları ve sistemler standart bir arayüz üzerinden ajana sunuluyor. Bir MCP sunucusu bir veritabanını, bir CRM'i veya bir dosya sistemini "araç" olarak ajana açıyor; ajan da bu araçları model bağlamında keşfedip çağırabiliyor.

Kurumsal değerin çoğu burada. Bir müşteri hizmetleri ajanının sipariş sistemine, iade politikasına ve stok verisine erişmesi gerekiyor — bunların hepsi MCP sunucularıyla sağlanabilir. Çok-tedarikçili karmaşıklığa girmeden, ajanınızı kurumsal sistemlerinize bağlamak istiyorsanız başlangıç noktanız MCP olmalı. Fazla mühendislik yapmayın: çoğu kullanım senaryosu A2A'nın çok-ajanlı orkestrasyonuna henüz ihtiyaç duymuyor.

A2A (Agent-to-Agent) protokolü, farklı ajanların — muhtemelen farklı üreticilerden — birbirinin yeteneklerini keşfetmesini ve görev devretmesini sağlıyor. Örneğin bir seyahat planlama ajanı, uçuş arama ajanına ve otel rezervasyon ajanına görev devredebilir. Her ajan yeteneklerini bir "Agent Card" ile ilan eder; diğer ajanlar bu kartı okuyup uygun görevi delege eder.

A2A'nın gerçek değeri, birden fazla uzman ajanın koordineli çalışması gereken senaryolarda ortaya çıkıyor. Ama dikkat: A2A'yı erken benimsemek, çözmediğiniz bir problem için karmaşıklık eklemek olabilir. Pratik kural şu: tek bir ajan + MCP ile başlayın, sadece gerçekten bağımsız, uzmanlaşmış ajanların koordinasyonuna ihtiyaç duyduğunuzda A2A'ya geçin. Çoğu kurum, A2A'ya geçmeden önce MCP ile aylarca değer üretebilir.

Protokolleri karşılaştırma

Protokol	Ne için	Ne zaman gerekir
MCP	Ajan-araç bağlantısı	Neredeyse her kurumsal ajan
A2A	Ajanlar arası koordinasyon	Çok-ajanlı, çok-tedarikçili senaryolar
WebMCP	Web içi etkileşim	Tarayıcı-tabanlı ajan görevleri
Kimlik/ödeme katmanı	Doğrulama, hesap verebilirlik	Otonom işlem yetkisi olan ajanlar

İşte kimsenin yeterince konuşmadığı kısım. Her protokol standartlaştırdığı yüzeyi güvenlik açısından da genişletiyor. Somut örnekler: araç açıklamaları ve web içeriği birer prompt injection vektörü haline geliyor — kötü niyetli bir araç açıklaması, ajanı istenmeyen bir eyleme yönlendirebilir. Ajandan ajana görev devri, "confused deputy" (kafası karışmış vekil) riskini makine hızında büyütüyor — bir ajan, yetkisini kötüye kullanacak bir isteği farkında olmadan yerine getirebilir. Ödeme otonomisi ise her yukarı akış ihlalinin bedelini artırıyor; ajanın harcama yetkisi varsa, onu ele geçiren saldırgan da o yetkiyi kullanır.

Bu yüzden OWASP artık agentic uygulamalar için özel bir ilk-on listesi yayımlıyor. Klasik uygulama güvenliği listelerinden farklı olarak burada aşırı yetkilendirme (excessive agency), bellek ve bağlam zehirlenmesi, araç kötüye kullanımı ve ajanlar arası güven istismarı gibi ajana özgü riskler var. Ajan mimarisi kuran her ekibin bu listeyi bir kontrol listesi olarak masasında tutması gerekiyor.

Peki bu riskleri nasıl yönetirsiniz? Üç temel prensip var. Birincisi kimlik ve doğrulama: A2A'da imzalı Agent Card'lar ajanlara doğrulanabilir kimlik veriyor; web tarafında Web Bot Auth benzer bir yön gösteriyor; ödeme yetkileri kriptografik hesap verebilirlik taşıyor. Her ajanın "kim olduğu" ve "ne yapmaya yetkili olduğu" doğrulanabilir olmalı.

İkincisi en az yetki (least privilege): bir ajana, görevini yapması için gereken minimum erişimi verin. Sipariş sorgulayan bir ajanın veritabanında yazma yetkisi olmamalı. Araç erişimlerini kapsamlandırın (scope), her aracın ne yapabileceğini net sınırlayın. Üçüncüsü denetim izi ve gözlemlenebilirlik: kurumsal MCP yönetişim ürünleri, uyumun talep ettiği denetim izlerini sağlıyor. Her araç çağrısı, her ajan devri, her ödeme kararı loglanmalı ve geriye dönük incelenebilmeli.

Ajanları "tam otonom" veya "hiç otonom değil" ikilisine sıkıştırmayın. Gerçek dünyada bir otonomi merdiveni tasarlarsınız: düşük riskli eylemler otomatik, orta riskli eylemler bildirimli, yüksek riskli eylemler insan onaylı. Bir ajanın 100 TL'lik bir iadeyi otomatik onaylaması makul olabilir; 100.000 TL'lik bir işlem için insan onayı şart. Bu eşikleri açıkça tanımlamak, hem güvenlik hem de regülasyon (EU AI Act'in "insan gözetimi" ilkesi, BDDK'nın "insan kontrolü" beklentisi) açısından kritik.

Sahadan bir gözlem: en başarılı ajan projeleri, otonomiyi zamanla artırıyor. Önce her eylemi insan onayına sokup güven inşa ediyor, metrikler iyileştikçe düşük riskli eylemleri otomatikleştiriyor. "Önce güven kazan, sonra yetki ver" prensibi hem insanlar hem ajanlar için geçerli.

Türkiye'de ajan mimarisi kurarken ek katmanlar var. Bir ajan MCP üzerinden kişisel veriye erişiyorsa, KVKK'nın veri işleme ilkeleri devreye giriyor: amaçla sınırlılık, veri minimizasyonu, açık rıza veya başka bir hukuki dayanak. Ajanın hangi kişisel veriye eriştiğini ve neden eriştiğini denetim izinde göstermeniz gerekebilir. Bankacılık ve sağlık gibi düzenlenmiş sektörlerde, verinin yurt dışına çıkmaması gereken senaryolarda, MCP sunucularınızı ve modellerinizi yerel altyapıda barındırmak bir gereklilik olabilir.

Tedarikçi güveni de önemli: kullandığınız üçüncü taraf MCP sunucuları ve ajan hizmetleri, sizin güven zincirinizin parçası. Bir üçüncü taraf MCP sunucusu zehirlenmiş bir araç açıklaması sunarsa, bu sizin ajanınızın problemi olur. Bu yüzden tedarikçi MCP sunucularını da güvenlik değerlendirmesinden geçirin.

Ajan mimarisine yeni giriyorsanız pratik yol haritam şu: Önce tek bir yüksek-değerli, düşük-riskli kullanım senaryosu seçin — örneğin dahili bir bilgi-tabanı sorgu ajanı. Bunu MCP ile kurumsal sistemlerinize bağlayın. Her araç erişimini en az yetkiyle kapsamlandırın ve tam denetim izi ekleyin. Bir otonomi eşiği tanımlayın: hangi eylemler otomatik, hangileri insan onaylı? OWASP agentic ilk-on listesini bir kontrol listesi olarak uygulayın. Metrikler olgunlaştıkça ve gerçekten çok-ajanlı koordinasyona ihtiyaç duyduğunuzda A2A'yı ekleyin.

Bu yaklaşımın güzelliği, karmaşıklığı ihtiyaç duydukça eklemesi. 2026'da ajan protokol yığını olgunlaştı; ama olgun bir yığın, her katmanı aynı anda benimsemeniz gerektiği anlamına gelmiyor. En sağlam ajan sistemleri, güvenliği baştan gömen ve otonomiyi kazanılmış güvenle artıran sistemler. Protokoller araçtır; asıl mühendislik, o araçları hangi güvenlik ve yönetişim çerçevesinde kullandığınızda gizli.