Bir yapay zeka ajanı MCP üzerinden bir araç çağırdığında ne loglanmalı — ve loglar neyi kanıtlayabilir

Model Context Protocol (MCP), yapay zeka ajanlarının dış araçlara erişimi için standart yol olarak yerleşti ve bu kolaylık bir kör noktayla geliyor: protokol bir çağrının nasıl yapıldığını tanımlarken nasıl kaydedilmesi gerektiği konusunda neredeyse hiçbir şey söylemiyor. dev.to'da yayımlanan güncel bir analiz mevcut spesifikasyonu adım adım inceliyor, araç çağrılarının bugün fiilen nereye yazıldığını haritalıyor ve bu kayıtların çoğunun şüpheci bir denetimciyle karşılaşmayı aşamayacağını savunuyor.

Onay, kanıt değildir

dev.to yazısına göre MCP spesifikasyonunun 2025-11-25 sürümü risk konusunda net: araçlar keyfi kod çalıştırmak anlamına gelir, host'lar herhangi bir aracı çağırmadan önce açık kullanıcı onayı almalıdır ve client'lar hassas işlemleri doğrulamalı, araç girdilerini göndermeden önce kullanıcıya göstermelidir. Bunların tümü kanıttan çok izni düzenler. Bir onay iletişim kutusu, bir kişinin bir araç adı ve argüman listesi gördüğünü ve evet'e tıkladığını gösterir; sunucunun bu argümanlarla ne yaptığı veya dönen sonucun gerçek değişiklikle eşleşip eşleşmediği konusunda hiçbir şey söylemez. Onay kararları ayrıca tipik olarak modelin ürettiği her şeyin bulunduğu aynı transkriptte saklanır — incelenen runtime tarafından yazılan ve onu yöneten herkesin düzenleyebileceği bir depo.

Resmi belgeler ne diyor

Protokol belgeleri araç çağrıları için hiçbir loglama gerekliliği içermiyor. Loglama yalnızca eşlik eden güvenlik en iyi uygulamaları kılavuzunda, üç yerde görünüyor:

• Token geçişi (token passthrough): bir MCP sunucusu bir client'ın token'ını körü körüne bir aşağı akış API'sine ilettiğinde, aşağı akış logları eylemleri yanlış kimliğe atfedebilir; spesifikasyon bunun olay incelemesini ve denetimi zorlaştırdığını kabul ediyor — bu, yanlış tarafın tuttuğu bir logun aktif biçimde yanıltıcı olabileceğinin örtük bir itirafı.
• Kapsam küçültme (scope minimisation): geniş, her şeyi kapsayan scope'lar işlem başına kullanıcı niyetini gizler; bu yüzden sunuculara, correlation ID'lerle istenen scope ile verilen alt küme kaydedilerek yükseltme olaylarını (elevation events) loglamaları söyleniyor.
• Proxy rehberi: stdio üzerinden yerel sunucular başlatan proxy'ler bu tür tüm taşıma kullanımlarını loglamalıdır — yalnızca bu mimariye uygulanan bir öneri.

Kaynağa göre kümülatif konum şudur: kimliği logla, kapsam değişikliklerini logla ve süreç başlatmalarını logla. Makul ama zayıf: hiçbir şey bir kaydın ne içermesi gerektiğini, kimin yazacağını veya birinin bunu daha sonra nasıl doğrulayacağını tanımlamıyor.

Anotasyonlar niyetleri tarif eder, davranışı değil

Araçlar readOnlyHint ve destructiveHint gibi davranışsal anotasyonlar taşıyabilir ve hangi çağrıların insan onayına ihtiyaç duyduğuna veya ayrıntılı kaydedileceğine karar veren bir host doğal olarak bunlara yaslanır. Ancak şema bunların davranışı sadakatle tarif etmeyebilecek ipuçları olduğunu, client'ların güvenilmeyen sunuculardan gelen anotasyonlara güvenilmemiş gibi davlanması gerektiğini belirtir. Bu nedenle salt-okunur bir aracın onay olmadan çalıştığını iddia eden bir log satırı, gözlemlenen etkiyi değil araç yazarının iddiasını kaydeder. Bir sunucu değiştirilir, güncellenir veya sunduğu içerik üzerinden ele geçirilirse, anotasyon bir saldırganın tam olarak ayarlayacağı alandır.

Dört iz, hiçbiri bağımsız değil

Tek bir çağrıyı tipik bir dağıtım üzerinden takip eden dev.to yazarı dört kayıt tespit ediyor: host'un transkripti (eksiksiz ama kendi kendine yazılmış), MCP sunucusunun kendi logu (sizin kontrolünüzde ya da yalnızca kendi insiyatifinde paylaşabilecek bir satıcıda), aşağı akış sisteminin logu (gerçekten neyin değiştiğinin mevcut en iyi hesabı ama token geçişi veya paylaşılan servis hesapları yoluyla yanlış atfete açık) ve kullanıcının onayı (host'ta saklandığından ilk kovaya devrediyor). Hiçbiri imzalı değil ve hiçbiri çalışılan koda bağlı değil, çünkü araç adlarının yalnızca bir sunucu içinde benzersiz olması gerekiyor ve aynı ad yarın farklı bir kodu gösterebilir. Önerilen test şudur: her kayıt için kimin yazdığını ve o kişinin başka bir şey yazma yetkisi ile herhangi bir nedeninin olup olmadığını sorun. Yazan ajan veya araçsa, kayıt çıkar sahibi bir tarafın iddiasıdır.

Kalıcı bir kayıt ne içermeli

Çözümün biçimi egzotik değil. Çağrı başına şunu yakalayın: sunucunun kimliğini görünen adı değil kodunun veya manifestinin hash'i olarak, araç adını hash'lenmiş argümanlarla, sonucun bir hash'ini, yetkilendiren kimliği ve bunun mekanizmasını (etkileşimli onay, izin listesi veya correlation ID'li kapsam yükseltmesi) ve çağrının altında çalıştığı sandbox profilini. Sonra bütününü ajan sürecinin erişemeyeceği bir anahtarla imzalayın ve üçüncü bir tarafın denetleyebileceği yalnızca-eklenebilir bir yerde saklayın. Kaynak, bunun Traceseal'in execution receipt'lerine benzediğini belirtiyor: bunlar bir skill manifest hash'i, sandbox profil hash'i, girdi ve çıktı hash'leri, çıkış kodu ve zamanlamasını, sandbox'a asla girmeyen bir operatör anahtarından ed25519 imzasıyla bağlar ve tek komutluk bir doğrulayıcı sunar.

Neden önemli

MCP artık ajanların üretim sistemlerine — depolara, veritabanlarına, bilet API'lerine — dokunduğu varsayılan entegrasyon katmanı. Bu sistemlere uygulanan her uyum rejimi, onlar üzerinde işlem yapan ajanlara da örtük olarak uygulanır ve olay müdahalesi, runtime'ınızın dışındaki insanların güvenebileceği kayıtlara bağlıdır. Protokol bir loglama öyküsü geliştirene kadar, gerçek araçlara ajan bağlayan ekipler kanıt üretmeden etkinlik üretiyor olur ve bu fark yalnızca bir şeyler ters gittiğinde görünür hale gelir.