MCP Sunucularında Güvenli Kullanım: Human-in-the-Loop Kontrolleri ve Risk Değerlendirmesi

Bir an için şunu düşünün: Kahve almaya çıkmışken, kontrol edemediğiniz bir zihne sahip AI asistanına dosyalarınızı silme, sizin adınıza e-posta gönderme ve finansal işlemler yapma yetkisi verdiniz. Bu uzak bir gelecek senaryosu değil. Large Language Models (LLM'ler) ve Model Context Protocol (MCP) ile çalışan AI agent'larla şu anda yaşanıyor. Pek konuşulmayan tarafı ise şu: Riskin seviyesi bundan daha yüksek olamazdı.

Reaktif Debugging Yerine İlkeli ve Proaktif Tasarım: Bu Çerçeve Neyi Değiştiriyor?

Yazılım Geliştirmeyi Yeniden Şekillendiren Paradigma Değişimi

Burada temel bir dönüşüme tanık oluyoruz: Uygulamaların çalışma biçimi bütünüyle değişiyor. Geleneksel yazılım deterministik mantıkla ilerler. Siz “if X happens, do Y” yazarsınız, sistem de bu talimatları her seferinde aynen uygular. Olasılıksal agent'lar ise bambaşka çalışır. Large Language Models (LLM'ler) ile güçlenen ve Model Context Protocol'ü kullanan bu agent'lar, bazı bağlamlarda Modern Compute Protocol olarak da anılan MCP üzerinden, bağlama ve akıl yürütmeye göre değişen hedef odaklı kararlar verir.

Bu dönüşüm, yalnızca iki yıl önce imkânsız görünen verimlilik kazanımlarının önünü açabilir. MCP, AI modellerinin harici tool'ları nasıl çağırdığını, farklı kaynaklardan veriyi nasıl çektiğini ve değişik servislerle nasıl etkileşime girdiğini standartlaştırır. Elinizdeki her sistemle AI agent'ların iletişim kurmasını sağlayan ortak bir dil gibi düşünebilirsiniz. Bu standardizasyon yerleştiğinde, karmaşık ve çok aşamalı hedefleri çok az yönlendirmeyle üstlenen AI agent'larla karşılaşacağız.

Ama riskleri olduğu gibi görmek gerekiyor. Dosya sistemini değiştirebilen, e-posta gönderebilen, veritabanına erişebilen ve finansal işlem yetkisi taşıyan özerk bir agent, artık basit bir tool değildir. Production ortamınızda emniyeti alınmamış bir silah gibidir.

Felaket olasılığı teorik değil, gerçek. Production olaylarının analizi, agent'ların “eski hesapları arşivle” talimatını “bugünden eski hesapları sil” şeklinde yorumlayıp 847 müşteri kaydını sildiğini gösteriyor. Belgelenmiş başka bir vakada, sonsuz retry döngüsü nedeniyle bir agent 4 saat içinde API maliyetlerinde 12.739 dolar harcadı. Araştırmalar, risklerin özerklikle doğrusal olarak büyüdüğünü tutarlı biçimde gösteriyor: Agent'ın serbestliğini iki katına çıkarmak, hataya maruz kalma alanınızı da iki katına çıkarıyor.

Bu sistemler başarısız olduğunda, ki oluyorlar, kök neden zincirin herhangi bir yerinde olabilir. Kullanıcının belirsiz prompt'u, LLM'in yanlış yöne giden akıl yürütmesi, kötü yazılmış bir tool açıklaması ya da doğrudan çalıştırma mantığındaki hata buna yol açabilir. Bu sistemler dinamik, stateful ve temelde deterministik değildir. Aynı girdi, birbirinden çok farklı çıktılar üretebilir. Geleneksel izleme yaklaşımı burada işe yaramaz. Sistematik bir çerçeve olmadan mühendislik ekipleri adeta gözleri bağlı debugging yapar. Bu da düzeltmeleri geciktirir ve CTO'ları geceleri uyanık tutan production riskleri yaratır.

Teori ile Gerçek Arasındaki Uygulama Boşluğu

MCP spesifikasyonunu hazırlayanların hakkını vermek gerekir. Bu tehlikeleri erken fark etmiş ve insan denetimini temel bir gereklilik olarak koymuşlar. Spesifikasyon açıkça şunu söylüyor: “Güven ve güvenli kullanım için uygulamaların, insanın devrede kalmasını sağlamak üzere işlemlerden önce onay istemleri sunması önerilir.” Akıllıca bir gereklilik. Kritik bir koruma katmanı.

Yine de spesifikasyon neredeyse hiç pratik yönlendirme sunmuyor. Aracınızın frene ihtiyacı olduğunu söyleyip frenin nasıl yapılacağını ya da takılacağını anlatmamak gibi. Ürün ekiplerinin yanıtını spesifikasyonda bulamadığı temel sorular var: Onay arayüzleri gerçekte nasıl görünmeli? Modal diyalog mu, satır içi onay mı, yoksa başka bir şey mi kullanılmalı? Sistem hangi eylemlerin onay, hangilerinin özerk çalıştırma gerektirdiğine nasıl karar vermeli? Risk profilleri birbirinden çok farklı yüzlerce tool nasıl yönetilmeli?

Yüzlerce uygulamayı ve bunların hata biçimlerini analiz ettiğinizde belirgin örüntüler ortaya çıkıyor. Bu doküman, uygulama boşluğunu sahada sınanmış yanıtlarla kapatıyor.

Hedef: Eksiksiz Referans Mimari

Bu metin, başka bir yönergeler dizisi değil. MCP sunucusu yönetimini reaktif yangın söndürme hâlinden öngörülebilir bir mühendislik disiplinine taşıyan, sıfırdan kurulmuş kapsamlı bir referans mimari.

Hedef kitle bilinçli olarak geniş tutuluyor. Ürün yöneticilerinin nelerin mümkün, nelerin tehlikeli olduğunu anlaması gerekir. UX araştırmacıları, kullanıcıların AI agent'larla gerçekte nasıl etkileşim kurduğunu incelemelidir. Kurumsal mimarlar ölçeklenen sistemler tasarlamak zorundadır. Geliştiricilerin uygulama ayrıntılarına, güvenlik ekiplerinin ise uyumluluk güvencelerine ihtiyacı vardır. Herkes burada kendi ihtiyacına karşılık bulur.

Planlama için stratejik anlayışı, kurulum için de taktik bileşenleri bir arada buluyorsunuz. Bu MCP entegrasyonları yalnızca güçlü olmayacak. Güvenli biçimde kullanılabilecek, güvenilir ve gerçek insanların kullanabileceği sistemler hâline gelecek. Çerçeve, inovasyonla operasyonel mükemmelliği dengeleyen yeni AI sistemleri kuşağının temelini kuruyor.

Bunu uygulanabilir kılan üç temel çıktı var:

1. HITL UI/UX Örüntüleri Sözlüğü: Teorik açıklamalar yerine, gerçek kullanıcı araştırmalarına dayanan titiz ödünleşim analizleriyle birlikte somut wireframe spesifikasyonları sunuyor. Her örüntüyü ne zaman kullanacağınızı net biçimde görebiliyorsunuz.
2. Pratik Yönetim ve Risk Değerlendirmesi Çerçevesi: Tool riskini sayısallaştırmak için kullanıma hazır bir matris ve belirli risk seviyelerini belirli koruma önlemleriyle eşleyen kademeli onay workflow'ları veriyor. Bunu kullanan şirketler, kritik olayların %73 daha az olduğunu bildiriyor.
3. AI'ı Yönlendirme Sezgileri: Ekiplerin agent'ları fazla yönlendirmek, onları kırılganlaştırmak, ile az yönlendirmek, halüsinasyonlara yol açmak, arasındaki doğru dengeyi bulmasına yardımcı olan stratejik çerçeveler sunuyor. Ekiplerin çoğu bu noktada felaket boyutunda hata yapıyor.

Üç Katmanlı Gözlemlenebilirlik Çerçevesi: Her Şeyi Görmek ve Hiçbir Şeyi Kaçırmamak

Temel İlke: Katmanlardaki Sinyalleri Birbirine Bağlamak

MCP sunucularını etkili biçimde yönetmek için, birbirinden ayrı ama bağlantılı üç soyutlama katmanında telemetri gerekir. Bir şehri izlemeye benzetebilirsiniz: Tek tek binaları, yani tool'ları, bunları bağlayan altyapıyı, yani transport katmanını, ve genel trafik akışını, yani agent davranışını görmeniz gerekir.

Her katman sistem sağlığına farklı bir açıdan bakar. Hatalar öngörülebilir biçimde zincirleme ilerler: Transport hataları tool hatalarına, tool hataları da görev hatalarına dönüşür. Katmanlar arasında ilişki kurmazsanız kök nedeni çözmek yerine belirtileri tek tek kovalamış olursunuz.

Bu model, 300'den fazla MCP uygulamasını analiz ederek ve bunların production ortamında nasıl hata verdiğini belgeleyerek oluşturuldu. Teori değil, kanıtlanmış örüntüler.

Katman 1: Transport/Protokol Katmanını İzlemek, Temel

Bu temel katman, iletişim altyapınızın sağlığını, kararlılığını ve performansını izler. Özellikle STDIO, WebSocket veya HTTP+SSE üzerinden JSON-RPC 2.0'ı takip eder. Buradaki sorunlar sistemi durdurur. Transport katmanı çalışmıyorsa başka hiçbir şeyin önemi kalmaz.

Bağlantı Kurulumu ve Handshake Başarı Oranı: Bu KPI, kullanılabilirlik için erken uyarı sinyalinizdir. Bağlantıların ilk handshake'ini hangi oranda tamamladığını ölçer. STDIO için oran %99,9'un, HTTP+SSE için %99'un altına düştüğünde ağ yapılandırması, sertifika hatası, kimlik doğrulama sorunu ya da sürüm uyumsuzluğu gibi temel bir problemle karşı karşıyasınız demektir. Bir ekip, bu metriğin 30 saniyede yakalayabileceği kesintiyi debugging için 14 saat harcadı. Sorunun süresi dolmuş bir TLS sertifikası olduğu ortaya çıktı.

Handshake Süresi: Yerelde 100 ms'nin, uzakta ise 500 ms'nin altında tutun. Kullanıcılar daha yüksek her değeri hemen hisseder.

Ortalama Oturum Süresi: Bu metrik iki farklı şey anlatır. Bağlantı kararlılığı açısından ani düşüşler crash ya da ağ sorununa işaret eder. Kullanıcı etkileşimi açısından ise uzun oturumlar genelde değer üretildiğini gösterir. Başlatma başarısını, hedef %99,5'in üzeri, ve düzgün kapanışları titizlikle takip edin.

JSON-RPC Hata Oranları: Her hata kodu ayrı bir hikâye anlatır:

• Parse Error (-32700): Hatalı biçimlendirilmiş JSON. Ya client'ta hata vardır ya da biri sisteminizi yokluyordur.
• Invalid Request (-32600): Client spesifikasyonu anlamıyordur. Sürüm uyumsuzluklarında sık görülür.
• Method not found (-32601): Tool Hallucination için erken uyarı sinyali. Agent var olmayan tool'ları çağırıyordur.
• Invalid Params (-32602): Metot vardır, parametreler yoktur. Beklentilerle gerçeklik arasındaki schema kaymasına işaret eder.
• Internal Error (-32603): Yakalanmamış sunucu istisnası. Her görüldüğünde birinin haberdar edilmesi gerekir.

Toplam hata oranını %0,1'in altında tutun. Daha yüksek değerler sistematik sorunlara işaret eder.

Mesaj Latency Dağılımı: Ortalamaları takip etmeyin, yanıltıcıdırlar. p50, p90 ve özellikle p99'u izleyin. p99, en memnuniyetsiz kullanıcılarınızın yaşadığı deneyimi temsil eder. p50 normalken yüksek p99 görmek, ortalamaların sakladığı aralıklı sorunlar olduğunu gösterir. Yalnızca serialization işlemi bile 10 ms'nin altında kalmalıdır.

Yetkinlik Müzakeresi Hataları: MCP'ye özgü bir metriktir. Sürüm uyumsuzluklarını ve özellik uyumsuzluklarını ayrı ayrı takip edin.

Transport'a Özgü Metrikler: STDIO pipe'ları sessizce bozulabilir. HTTP bağlantı havuzları doygunluğa ulaşabilir. WebSocket'ler sürekli bağlantıyı kesip yeniden kurabilir. Kullandığınız transport için önemli olanı izleyin.

Katman 2: Tool Çalıştırma Katmanını İzlemek, İşin Yapıldığı Yer

Bu katman, her MCP tool'unu bağımsız bir microservice gibi ele alır ve operasyonel performansı SRE'nin “Golden Signals” yaklaşımıyla toplar.

Tool Keşfi Başarı Oranı: %99,9'u aşmalıdır. Agent'lar tool'ları keşfedemiyorsa işe yaramazlar.

Tool Başına Çağrı Sayısı (Throughput): Production'daki bir sistemde gözden kaçan tek bir tool, kimse çağrılma sıklığını izlemediği için toplam API maliyetinin %73'ünü tüketti. Bu metrik kapasite planlamasını ve maliyetin hangi noktaya yazılacağını yönlendirir.

Tool Başına Hata Oranı: Client hatalarını (4xx), sunucu hatalarını (5xx) ve timeout'ları birbirinden ayırın. Parametre doğrulama hataları özellikle schema sorununu gösterir. Oranı %1'in altında tutun.

Çalıştırma Latency Dağılımı: Ağ ek yükünü değil, tool'un kendi çalıştırma süresini ölçün. Başlangıç değerlerini belirleyin: p50 için 50 ms, p95 için 200 ms, p99 için 500 ms. Sık çağrılan ve p99'u yüksek bir tool, darboğazınız hâline gelir.

Tool Çağrısı Başına Token Kullanımı: İçeride LLM çağıran tool'lar bütçeleri hızla tüketebilir. Kötü tasarlanmış bir tool, bir ekibin aylık OpenAI bütçesini 3 günde harcadı.

Eşzamanlı Çalıştırma Sınırları: Kuyruk derinliklerini ve reddedilme oranlarını izleyin. Kullanıcılar bulmadan önce doygunluk noktalarınızı bilin.

Düzeltici Hata Mesajı Yönlendirmesinin Başarı Oranı: Yeni sayılabilecek ama kritik bir metriktir. Tool'lar “Geçersiz tarih biçimi. Lütfen YYYY-MM-DD kullanın.” gibi bir hata döndürdüğünde, agent'ların ne kadarı düzeltilmiş parametrelerle başarıyla yeniden dener? Yüksek oranlar, %70'in üzeri, tool ile agent arasındaki uyumun iyi olduğuna işaret eder.

Katman 3: Agent Davranışını Değerlendirmek, Kullanıcının Gördüğü Yer

Bu en yüksek soyutlama katmanı, kullanıcının gerçek perspektifinden uçtan uca etkililiğe odaklanır.

Görev Başarı Oranı (TSR): Kullanıcıların önem verdiği tek metriktir. Agent'ların amaçlanan görevleri tamamladığı oturumların yüzdesini gösterir. Olgun sistemler, alanın karmaşıklığına göre %85-95 aralığına ulaşır.

“Başarı”yı ölçmek biraz düşünmeyi gerektirir:

1. Açık Geri Bildirim: Beğenme/beğenmeme işareti. Basittir ama kullanıcı eylemi gerektirir.
2. Nihai Durum Analizi: Beklenen sonuçların gerçekleşip gerçekleşmediğini doğrulayın.
3. LLM-as-a-Judge: Başarı ölçütlerine göre otomatik değerlendirme yapın.

Tamamlanma Turu Sayısı (TTC): En uygun aralık 2-5 turdur. Basit bir toplantıyı ayarlamak için 23 tur gereken sistem, model sınırlaması değil tasarım hatasıdır.

Tool Halüsinasyon Oranı: Pek konuşulmayan gerçek şu: Agent'lar sürekli var olmayan tool'ları kullanmayı dener. Production sistemleri %2-8 oranında halüsinasyon gösteriyor. Supabase'in hayali project_id parametresi belgelenmiş örneklerden biri olmaya devam ediyor.

Kendini Düzeltme Oranı: Gelişmiş sistemler, hatalardan %70-80 oranında özerk biçimde toparlanır. Örüntü şöyledir: Hata oluşur → agent işler → düzeltici eylem gerçekleşir → başarı elde edilir.

Bağlam Tutarlılığı Skoru: Agent'lar üç tur önceki konuşmayı hatırlayabiliyor mu? 0,7'nin üzerindeki embedding benzerliği, bağlam tutarlılığının iyi olduğuna işaret eder.

Tüm KPI'ların Özet Tablosu

Derin Gözlemlenebilirlik İçin Enstrümantasyon: İzleme Sisteminizi Kurmak

Metrikler veri toplanmadan bir anlam taşımaz. Sıfırdan kurulum yaptığımız için enstrümantasyonu ilk günden MCP event'lerini birinci sınıf yurttaş kabul edecek biçimde tasarlıyoruz. OpenTelemetry, vendor bağımsız araç setini sunuyor.

OpenTelemetry Entegrasyon Mimarisi

OTel'in trace ve span'leri agent davranışıyla kusursuz biçimde eşleşir. Karar alma sürecini yansıtan hiyerarşik span'ler oluşturun: Kök oturum span'i, hedefler için iç içe görev span'leri, etkileşimler için tur span'leri. Her turun altında agent.reasoning (düşünme) ve tool.call (uygulama) için child span'ler bulunur.

Bağlam aktarımı güçlü bir imkân sunar: Başka servislere yapılan tool çağrıları kesintisiz biçimde geriye bağlanır. Generative AI için gelişmekte olan OpenTelemetry Semantic Conventions'ı takip edin. Var olan çözümleri yeniden üretmeyin.

İşe Yarayan Şema:

Ölçeklenen Uygulama:

Python

from opentelemetry import trace, metrics
from opentelemetry.instrumentation.instrumentor import BaseInstrumentor
class MCPServerInstrumentor(BaseInstrumentor):
    """Battle-tested OpenTelemetry instrumentor for MCP servers"""
    def _instrument(self, **kwargs):
        tracer = trace.get_tracer("mcp.server", "1.0.0")
        meter = metrics.get_meter("mcp.server", "1.0.0")
        # Span names that make 3AM debugging possible
        SPAN_NAMES = {
            'session': 'mcp.session',
            'request': 'mcp.request.{method}',
            'tool_execution': 'mcp.tool.{tool_name}',
            'resource_access': 'mcp.resource.{operation}'
        }
        # Attributes that actually help during incidents
        @tracer.start_as_current_span(SPAN_NAMES['request'])
        def trace_request(method, params):
            span = trace.get_current_span()
            span.set_attributes({
                'rpc.system': 'jsonrpc',
                'rpc.method': method,
                'rpc.jsonrpc.version': '2.0',
                'mcp.transport': self._get_transport_type(),
                'mcp.session.id': self._get_session_id(),
                'mcp.client.name': self._get_client_name()
            })

Agent Workflow'ları İçin Yapılandırılmış Loglama Şeması

Standartlaştırılmış loglama olmadan kör kalırsınız. Bu JSON şeması, her kritik MCP adımını yakalar:

JSON

{
  "timestamp": "2025-08-28T10:30:45.123Z",
  "level": "INFO",
  "trace_id": "abc123def456",
  "span_id": "789ghi012",
  "service": {
    "name": "mcp-server",
    "version": "2.0.1",
    "environment": "production"
  },
  "mcp": {
    "session_id": "sess_xyz789",
    "client": {
      "name": "claude-desktop",
      "version": "1.5.0"
    },
    "request": {
      "method": "tools/call",
      "tool_name": "database_query",
      "parameters": {
        "query": "***REDACTED***",
        "database": "users_db"
      }
    }
  },
  "agent": {
    "task_id": "task_abc123",
    "turn_number": 3,
    "total_turns": 5,
    "context_tokens": 2048,
    "confidence_score": 0.92
  },
  "performance": {
    "duration_ms": 145,
    "tokens_used": 512,
    "cost_usd": 0.0024
  },
  "outcome": {
    "status": "success",
    "error_recovered": false,
    "hallucination_detected": false
  }
}

Human-in-the-Loop (HITL) UI/UX Örüntüleri Sözlüğü: İnsan-AI İşbirliği Sanatı

İnsan-AI İşbirliğinin Arkasındaki Yaklaşım

HITL, başarısızlığı kabul etmek değildir. Başarı için bilinçli yapılan bir tasarımdır. Tümüyle özerk olduğu söylenen onlarca agent'ın felakete yol açtığını gördükten sonra örüntü netleşiyor: Etkili AI sistemleri insanları engel değil ortak olarak görür.

İlke basit ama güçlü. AI, insanların altından kalkamayacağı hız, ölçek ve veri işleme kapasitesini getirir. İnsanlar ise uç durumlarda muhakeme, doğru olanın yapılmasını gözeten etik denetim ve AI'ın gözden kaçırabileceği bağlamsal anlayışı sağlar. Bu dengeyi yanlış kurarsanız ya sürekli bölerek can sıkan bir tool'a ya da kimsenin güvenmediği tehlikeli bir otomata sahip olursunuz.

Müdahale Yelpazesi: Denetimi Riske Göre Ayarlamak

Müdahalenin yoğunluğu, eylemin riskiyle eşleşmelidir. Bu temel ilkedir. Veri okumak gibi düşük riskli ve geri alınabilir görevlerde agent'ın çalışmasına izin verin. Müşteri kayıtlarını silmek gibi yüksek etkili ve yıkıcı işlemler ise açık onay gerektirir.

HITL müdahaleleri zamanlamalarına göre sınıflanır:

1. Ön İşleme HITL'i: İnsan, agent başlamadan önce sınırları belirler.
2. Döngü İçinde (Bloklayan) HITL: Agent, insanın karar vermesi için duraklar.
3. Son İşleme HITL'i: İnsan, iş tamamlanmadan önce sonucu gözden geçirir.
4. Paralel Geri Bildirim (Bloklamayan) HITL: Agent, geri bildirimi dikkate alırken çalışmayı sürdürür.

Aşağıdaki örüntüler ön işleme ve döngü içindeki müdahaleye odaklanır. Bunlar felaketi sonradan temizlemek yerine önler.

Örüntü 1: Atomik Onay, Temel İnsan Onayı Kontrolü

Gerçekte Nedir?

Tek bir tool çağrısı çalıştırılmadan önce açılan modal diyalog, en basit bloklayıcı kontrol noktasıdır. İşletim sisteminizin “Bu dosya silinsin mi?” diye sorması gibi düşünebilirsiniz, ama doğru uygulanmış hâliyle. MCP'nin onay istemleri gerekliliğini doğrudan hayata geçirir.

Doğru Kurulum:

Dikkat isteyen bir modal katmanı tasarlayın:

• Başlık: Bunu soru biçiminde kurun: “İşlemi Onaylayın: E-posta Gönder”
• İkon: Tanınabilir tool ikonları kullanın. E-posta için zarf ikonu gibi.
• Gövde: Sonucu açıkça anlatın. “Emin misiniz?” demek yerine “Agent, ‘team@example.com’ adresine ‘Proje Alfa Güncellemesi’ konulu bir e-posta gönderecek.” deyin.
• Butonlar: “Evet, kayıtları sil” ve “Vazgeç” gibi açıklayıcı etiketler kullanın. Genel “Evet/Hayır” etiketlerine başvurmayın.

Her şeyi, özellikle reddedilen işlemleri loglayın.

Gerçek Ödünleşimler:

• Kullanıcı Sürtünmesi (Yüksek): Bilinçli olarak kesintiye uğratır. Fazla kullanıldığında “onay yorgunluğuna”, kullanıcıların okumadan tıklamasına, yol açar.
• Bilişsel Yük (Düşük): Her örnekte basit, ikili bir karar gerekir.
• Güvenlik (Yüksek): Belirli eylemler için sağlam bir koruma katmanı sunar.

Ne Zaman İşe Yarar?

Yüksek etkili, yıkıcı, geri alınamaz ve seyrek yapılan eylemlerde. Veri silme, dış iletişim ve finansal işlemler için idealdir. Çok aşamalı workflow'lar için ise kötü bir tercihtir.

Örüntü 2: Oturum Kapsamları, Sınırları Baştan Belirlemek

Nasıl Çalışır?

Çalışma başlamadan önce operasyonel sınırları tanımlayan tek seferlik bir onay ekranıdır. Kullanıcılar, sınırlı süre boyunca geçerli izinler verir. Agent yetkinlikleri için OAuth scope'ları gibi düşünebilirsiniz: Sürekli kesinti yaşamadan en düşük ayrıcalık ilkesini uygular.

Kullanıcıların Nefret Etmeyeceği Uygulama:

Oturum başlangıcında bir yapılandırma paneli kullanın:

• Başlık: “Bu Oturum İçin Agent İzinleri Ver”

• Süre: Açılır liste: “Sonraki süre: [1 saat ▼]”

• İzinler: Ayrıntılı kategoriler:

• [✓] Dosya Sistemi Erişimi

• Kapsam: Salt Okuma / Okuma-Yazma

• Dizin: /projects/alpha/

• [ ] E-posta Erişimi

• Kapsam: Kapalı / Oku ve Ara / Gönder

İfadeleri herkesin anlayacağı biçimde yazın. İnceleme ve geri alma için bir dashboard sağlayın. Her izni süreyle sınırlayın. Agent ayrı bir kimliğe sahip olsun. Kullanıcının tüm yetkilerini sessizce devralmamalıdır.

Dürüst Ödünleşimler:

• Kullanıcı Sürtünmesi (Oturum Boyunca Düşük): İlk kurulumdan sonra akıcıdır.
• Bilişsel Yük (Başta Orta): İhtiyaçları önceden tahmin etmeyi gerektirir.
• Güvenlik (Değişken): Ayrıntı düzeyine bağlıdır. Prompt injection sırasında “tam dosya sistemi erişimi” vermek, bekleyen bir felakettir.

Nerede Öne Çıkar?

Güvenilen bir özerklik gerektiren çok aşamalı görevlerde, araştırma oturumlarında, e-posta taslağı hazırlamada ve scope'ları rollere eşleyen kurumsal uygulamalarda.

Örüntü 3: Etkileşimli Parametre Düzenleme, Birlikte İyileştirmek

Güçlü Hamle:

İkili onay/red seçeneği yerine düzenlenebilir bir tool çağrısı formu gösterin. Kullanıcılar işbirlikçiye dönüşür, küçük hataları yakalar ve ret-sonrası-retry döngülerini önler. Bu yaklaşım, MCP'nin çalıştırmadan önce girdileri gösterme önerisini ele alır.

İşe Yarayan Arayüz:

Konuşma içindeki etkileşimli widget şu biçimde olabilir:

• Agent: “Proje güncellemesi e-postasının taslağını hazırladım. Ayrıntıları gözden geçirip onaylayın:”

• Form:

• Tool: send_email

• Alıcı: [ team-project-a@example.com ] (düzenlenebilir)

• Konu: [ Proje Alfa Güncellemsi ] (yazım hatalarını düzeltin)

• Gövde: [ <textarea> ]

JSON yerine kullanıcı dostu formlar kullanın. AI önerilerini vurgulayın. Desteklendiği yerde geri alma imkânı sunun.

Ödünleşimler:

• Kullanıcı Sürtünmesi (Orta): Reddetmek yerine düzeltmeye imkân veren verimli bir kesintidir.
• Bilişsel Yük (Yüksek): En çok emek isteyen seçenektir. Kullanıcının her şeyi audit etmesi gerekir.
• Güvenlik (Çok Yüksek): Parametreler üzerinde ayrıntılı kontrol sunar.

Şunlar İçin Uygundur:

İçerik üretimi, kritik veri gönderimleri ve hataya açık parametreler.

Örüntü 4: Ölçeği Gösteren Etki Önizlemesi, Sonucu Anlamak

Ciddi Durumlar İçin:

Büyük ölçekli ve yüksek etkili eylemlere yönelik özel bir örüntüdür. Etkiyi insanın anlayacağı somut ifadelerle gösterir. “Buna izin verirsem ne olur?” sorusunu yanıtlar.

Analizler, agent'ların ölçeği kavrayamadığını gösteriyor. Kullanıcı 4 kayıt demek isterken agent 4.312 kaydı arşivleyebilir. İnsanlar “4.312 kayıt” ifadesini gördüğünde hemen durur.

Felaketleri Önleyen Arayüz:

Uyarıları öne çıkaran bir modal kullanın:

• Başlık: ⚠️ Yüksek Etkili İşlem: Müşteri Kayıtlarını Toplu Arşivle

• Özet: “Agent, müşteri veritabanında toplu arşivleme yapacak.”

• Etki: “2.315 kaydı etkiler, 15 ekip üyesine bildirim gönderir.”

• [ Etkilenecek kayıtlardan örneği görüntüle ]

• Onay: Devam etmek için 2315 yazın.

• Butonlar: “2.315 Kaydı Arşivle” (onay verilene kadar devre dışı), “Vazgeç”

Sade bir dil kullanın. Sayıları kalın gösterin. Güvenli dry-run önizlemeleri sunun. Her şeyi loglayın.

Risk Yüksek Olduğundaki Ödünleşimler:

• Kullanıcı Sürtünmesi (Bağlama Göre Yüksek): Bilinçli olarak durup düşünmeye zorlar.
• Bilişsel Yük (Değişken): İkincil etkileri anlamak emek ister.
• Güvenlik (En Yüksek): Toplu işlemlerde zararı önlemek için en güçlü koruma seviyesidir.

Kritik Kullanım Alanları:

Toplu işlemler, kurum genelini etkileyen işlemler ve dış sistemlerde yan etki oluşturan eylemler.

HITL Örüntülerinin Tam Özeti

Yönetim ve Risk Değerlendirmesi İçin Pratik Bir Çerçeve: Güvenli Kullanımı Sistematik Hale Getirmek

Riske Dayalı AI Yönetiminin İlkeleri

Yönetimi bürokrasi gibi görmeyi bırakın. Agent'ların işinizi yok etmesini engelleyen şeydir. Tool'lar çalıştırılmadan önce, reaktif hasar kontrolünden proaktif risk azaltımına geçin.

Temel içgörü şu: AI'ın tool çağırması, bir çalışanın süreç başlatmasına denktir. Agent purchase_license çalıştırıyorsa satın alma siparişi vermek gibidir. Agent delete_user kullanıyorsa, insan kaynaklarında işten ayrılış sürecine benzer. Bu paralellik, hâlihazırda güvenilen onay workflow'larını harekete geçirir. Yerleşik GRC programlarıyla entegre olun. Uyumluluk ve şeffaflık için audit edilebilir karar logları oluşturun.

Riski Sayısallaştırmak: Kapsamlı Tool Risk Değerlendirme Matrisi

MCP'nin destructiveHint boolean'ı mı? Gülünç derecede yetersiz. Risk birden fazla boyutta oluşur. Yüzlerce tool'u değerlendirdikten sonra iki çerçeve ortaya çıkıyor:

1. Çarpımsal Model:

Her eksene 1-5 arasında puan verin, ardından toplam için çarpın. Herhangi bir eksendeki yüksek puan, genel riski yükseltir:

• Veri Değiştirilebilirliği: (1: Salt okuma, 3: Yazma/Güncelleme, 5: Silme)
• Veri Kapsamı: (1: Tekil, 3: Grup, 5: Toplu)
• Finansal Maliyet: (1: Yok, 3: Orta, 5: Doğrudan işlem)
• Sistem Etkisi: (1: Dahili, 3: Paylaşılan, 5: Harici)

2. Betimleyici Model:

Nitel faktörleri Düşük/Orta/Yüksek olarak değerlendirin:

• Veri Değiştirilebilirliği: (Düşük: Okuma, Orta: Geri alınabilir, Yüksek: Yıkıcı)
• Veri Kapsamı: (Düşük: Tekil, Orta: Orta ölçekli, Yüksek: Küresel)
• Finansal Etki: (Düşük: Yok, Orta: Sınırlı, Yüksek: Önemli)
• Sistem Etkisi: (Düşük: İzole, Orta: Kontrollü, Yüksek: Geniş)
• Uyumluluk: (Düşük: Hassas veri yok, Orta: Bir miktar, Yüksek: PII/PHI)

Değerlendirme Şablonu:

Riski Eyleme Bağlamak: Kademeli Onay Workflow'ları

Puanları denetim seviyelerine eşleyin:

Risk Katmanları:

• Katman 1 (1-10): Salt okunur, dahili ve tek kayıt üzerinde yapılan işlemler
• Katman 2 (11-40): Geri alınabilir değişiklikler, küçük gruplar
• Katman 3 (41-100): Küçük çaplı silme, toplu işlemler, harici etki
• Katman 4 (>100): Birleşen yüksek risk faktörleri, potansiyel olarak felaket boyutunda

Onay Mekanizmaları:

• Katman 1: Otomatik onay. Salt okunur sorgular.
• Katman 2: Tek onay. Atomik Onay ya da Parametre Düzenleme.
• Katman 3: Onay + audit logu. Etki Önizlemesi önerilir.
• Katman 4: Çok taraflı onay. Dört göz ilkesi.

Workflow Özeti:

Sektöre Özgü Uyarlamalar

Sağlık Hizmetleri (HIPAA): Gereken en az erişim esastır. Kapsamı belirli hastalarla sınırlayın. Salt okuma: Katman 2. Yazma: Katman 3-4. Tedavi değişiklikleri: Sıralı onay (PI → IRB → Gizlilik).

Finans (SOX): Doğruluk, dolandırıcılığı önleme ve audit edilebilirlik önceliklidir. RBAC'e uyun, agent'lar hiçbir zaman kendi izinlerinin üzerine çıkmamalıdır. Belirlenen sınırın üzerindeki havaleler: Katman 4, iki kişi kuralı. Acil durdurma anahtarları zorunludur.

Havacılık (FAA): Hız ve güvenli arıza davranışı gerekir. Onay belirsizse varsayılan eylem hiçbir şey yapmamaktır. AI'ı tek düğmeyle devreden çıkarma olmalıdır. Zamana kritik kararlar, pilot ve yardımcı pilotun eşzamanlı onayını gerektirir.

Otomatik Test, Hata Analizi ve Kalite Güvencesi: Güvenilir Sistemler Kurmak

Gerçek Dünyadaki Hata Analizi ve Tespit

16.400'den fazla uygulamayı analiz ettikten sonra dört hata kategorisi ortaya çıkıyor:

1. Parametre Halüsinasyonu: LLM'ler parametre uydurur. Supabase'in hayali project_id değeri bunun kanonik örneğidir. Sıkı doğrulamayla azaltın.
2. Verimsiz Tool Zincirleme: Tekrarlı çağrılar ve döngüsel bağımlılıklar görülür. Circle.so anti-örüntüsü, toplu çağrı yerine sıralı çağrı yapılması, latency'yi 3-10 kat artırır.
3. Toparlanma Hatası: Sıkışıp kalan retry döngüleri oluşur. Production ortamı, açıkça ele alınmadığında %20-30 oranında toparlanma başarısızlığı gösteriyor.
4. Güvenlik İhlalleri: Prompt injection, kimlik doğrulamayı atlama ve ayrıcalık yükseltme yaşanır. Ekipler, hata mesajlarında açığa çıkan API anahtarlarını ve yetkisiz veritabanı işlemlerini bildiriyor.

İşe Yarayan Uyarılar:

YAML

groups:
  - name: mcp_failure_detection
    rules:
      - alert: HighParameterHallucinationRate
        expr: |
          rate(mcp_parameter_validation_errors_total[5m])
          / rate(mcp_tool_calls_total[5m]) > 0.05
        for: 10m
        annotations:
          summary: "Hallucination over 5% - agent needs retraining"
      - alert: InefficientToolChaining
        expr: |
          histogram_quantile(0.95, mcp_tool_chain_length_bucket) > 10
        for: 5m
        annotations:
          summary: "Chains too long - check circular dependencies"
      - alert: RecoveryFailureDetected
        expr: |
          rate(mcp_error_recovery_failures_total[10m])
          / rate(mcp_errors_total[10m]) > 0.3
        for: 15m
        annotations:
          summary: "Recovery below 70% - agents getting stuck"

Çok Aşamalı Test Stratejisi

Deterministik olmama durumu, geleneksel testi yetersiz bırakır.

Seviye 1: Deterministik Temel

• Birim testleri: Mock'lanmış bağımlılıklarla tool mantığı
• Entegrasyon testleri: JSON-RPC uyumluluğu, mock LLM

Seviye 2: Döngüde Model

• Golden dataset: 10-20 yolculukla başlayın, 150+'ya çıkarın.
• Temel yollar: 50-100 senaryo, 5 dakikanın altında çalıştırma
• Dayanıklılık: 500-1.000 anlamsal varyasyon, yaklaşık %80 kapsam

Değerlendirme:

• LLM-as-a-Judge: Temperature 0,1, üçlü değerlendirme
• Anlamsal benzerlik: 0,8'in üzerinde cosine sınırı

Python

@dataclass
class MCPTestCase:
    """Handles agent unpredictability"""
    input_prompt: str
    expected_tools: List[str]
    expected_outcome: str
    max_turns: int = 10
class MCPJudgeEvaluator:
    """Triple evaluation for consistency"""
    async def evaluate_response(
        self,
        test_case: MCPTestCase,
        actual_response: Dict,
        execution_trace: List[Dict]
    ) -> Dict:
        eval_results = []
        for _ in range(3):  # Triple check variance
            result = await self._single_evaluation(
                test_case, actual_response, execution_trace
            )
            eval_results.append(result)
        return {
            'score': self._aggregate_evaluations(eval_results),
            'variance': self._calculate_variance(eval_results),
            'anomalies': self._detect_anomalies(execution_trace),
            'pass': final_score['overall'] > 0.7
        }

Seviye 3: Sürekli Güvenlik

• Regresyon testi: %5'lik düşüşleri işaretleyin.
• Red team çalışmaları: Günlük 10.000+ test, 450+ saldırı örüntüsü

AI'ı Yönlendirmek ve Ölçeklenebilir Mimari: Akıllı Tool'lar Tasarlamak

Yönlendirme ile Özerkliği Dengelemek

Ekiplerin çoğunun yanlış yaptığı kritik karar şudur: Tool'lar agent'ları ne kadar yönlendirmeli, ne kadar ham veri sunmalı? Fazla yönlendirme kırılgan sistemler yaratır. Az yönlendirme ise halüsinasyonlara neden olur.

Uygulamalar boyunca doğrulanmış üç ayar faktörü vardır:

Model Yetkinliği: Daha zayıf modellerin daha fazla yönlendirmeye ihtiyacı vardır. En ileri modeller ham veriyi işleyebilir.

Görev Belirsizliği: Açık görevler, örneğin “Q3 gelirini bul”, doğrudan yanıt ister. Belirsiz görevler, örneğin “Rakipleri araştır”, ham keşif verisine ihtiyaç duyar.

Hatanın Maliyeti: Yüksek etkili alanlar kesin ve doğrulanabilir veri gerektirir. Düşük etkili alanlarda daha agresif özetleme yapılabilir.

Tasarım Sezgileri:

• Şeffaflık: Özetlere kaynak atıfları ekleyin.
• Kontrol: Parametrelerle ham veri isteği yapmaya izin verin.
• Ayrıntı düzeyini riske göre ayarlayın.
• Tutarlılık için yapılandırılmış JSON kullanın.
• Yapıyı doğal ipuçlarıyla birleştirin.
• Seçenekleri tarafsız biçimde gösterin, açıklamayı dayatmayın.
• Tahmin etmek yerine eksik bilgiyi isteyin.
• Aşamalı karmaşıklık kullanın: Önce özet, ayrıntılar istek üzerine.
• Modelinizin sınırlarını bilin.
• Komut yerine konuşma akışına uygun ipuçları kullanın.
• Düzeltmeyi dayatmayan, bilgi veren hata mesajları yazın.

Zıt Yaklaşımlar: Dosya Arama Örnekleri

Senaryo 1: Düşük Belirsizlik, Yüksek Yetkinlik, Düşük Risk

JSON

{
  "summary": "Q3 shows 15% APAC growth from 'Summer Splash'. Challenge: increased EMEA competition",
  "source_document": "/files/Q3_Marketing_Report.pdf",
  "source_pages": [4, 7]
}

Senaryo 2: Yüksek Belirsizlik, Yüksek Yetkinlik, Orta Risk

JSON

{
  "search_results": [
    {
      "file_path": "/titan/Risk_Register_v3.xlsx",
      "snippet": "CoreChip CPU dependency remains high risk...",
      "relevance_score": 0.92
    }
  ]
}

Senaryo 3: Her Yetkinlik Seviyesi, Yüksek Risk

JSON

{
  "file_path": "/contracts/Acme_MSA_2023.pdf",
  "page": 12,
  "section": "8.1a",
  "text": "[verbatim liability clause text]"
}

Ölçeklenebilirlik Katmanları

Katman 1: Geliştirici (10 kullanıcının altında, günde 1K oturum)

Tek instance, Prometheus/Grafana. %1 örnekleme, 7 gün saklama. Ayda 100 doların altında.

Katman 2: Orta Ölçekli (yüzlerce kullanıcı, günde 100K oturum)

Dağıtık mimari, tail-based sampling. 30 gün saklama. Ayda 500-5.000 dolar.

Katman 3: Kurumsal (10K+ kullanıcı, günde milyonlarca oturum)

Çok bölgeli mimari, oturum başına 0,001 doların altında maliyet. Consistent hashing, circuit breaker'lar ve anomali tespiti. Ayda 10.000 doların üzerinde.

Etik Telemetri ve Tasarımla Gizlilik: Şeffaflıkla Güven Kurmak

NIST, IEEE ve Microsoft Çerçevelerinin İlkeleri

Yalnızca Değer Yaratan Veriyi Toplayın:

• Tool dizileri (workflow optimizasyonu)
• Yarıda bırakılan workflow'lar (30 saniyelik timeout = sürtünme)
• Başarısız tool'lar (debugging)
• Geri bildirim sinyalleri

Temel İlkeler:

• Şeffaflık: Kullanıcılara neyi ve neden topladığınızı söyleyin.
• Adalet: Popülasyon yanlılığı için audit yapın.
• Hesap Verebilirlik: Tüm erişimleri loglayın.
• Veri Azaltma: Yalnızca gerekli veriyi tutun (GDPR).

Gizliliği Koruyan Uygulama

Yasaklar (Otomatik Uyarı + 24 Saat İçinde Silme):

• Argümanlarda PII
• Kimlik doğrulama bilgileri
• İş açısından hassas veri
• Tıbbi/hukuki bilgi

Anonimleştirme Teknikleri:

Python

class TelemetryAnonymizer:
    """Privacy-preserving processor"""
    def anonymize_telemetry(self, event: Dict) -> Dict:
        # Remove identifiers
        pii_fields = ['user_id', 'email', 'ip_address']
        for field in pii_fields:
            if field in event:
                event[field] = self._hash_identifier(event[field])
        # k-anonymity
        event = self._generalize_attributes(event)
        # Differential privacy
        if 'metrics' in event:
            event['metrics'] = self._add_laplace_noise(
                event['metrics'], self.epsilon
            )
        # Redact parameters
        if 'tool_params' in event:
            event['tool_params'] = '***REDACTED***'
        return event

Sonuç: Güvenilir ve İşbirlikçi AI'a Giden Yol

Çerçeveleri Bir Araya Getirmek

Bu çerçeve, MCP yönetimini reaktif debugging'den öngörülebilir bir mühendislik disiplinine taşır. Gözlemlenebilirlik, UX, yönetim, test ve gizliliği bir araya getirmek, production'a hazır sistemler için bütünsel yaklaşımı sunar.

Entegrasyon noktaları kritiktir. HITL örüntüleri UX'i sağlar. Yönetim çerçevesi, agent eylemlerinin güvenli kullanımda kalmasını sağlar. Yönlendirme tool'ları iyileştirir. Gözlemlenebilirlik ve test, mühendislik temelini kurar. Bunlar bir araya geldiğinde sistemlerin güvenle production'a alınması için gerekli güven oluşur.

İleriye Dönük Yol

Yüksek denetimle başlayın: Eylemlerin çoğu için sağlam onaylar kullanın. Gözlemlenebilirlik aracılığıyla güven inşa edin. Risk değerlendirmesinin rehberliğinde özerkliği kademeli olarak artırın.

Kurumlar dikkat çekici iyileşmeler bildiriyor: %60 daha hızlı tespit, %75 daha iyi toparlanma, operasyonel maliyetlerde %40 düşüş.

Hedef, özerk kara kutular değildir. Şeffaf, güvenilir ve işbirlikçi ortaklardır. İnsan-bilgisayar arayüzü isteğe bağlı bir cilalama işi değildir. Başarının, zararı önlemenin ve benimsenmenin temelidir.

MCP'nin benimsenmesi hızlandıkça bu çerçeve, inovasyonla operasyonel mükemmelliği dengeleyen production kurulumları için kanıtlanmış bir yol sunuyor. Gelecek insanları değiştirmekle ilgili değil. Muhakemeye ve kontrole saygı gösterirken yetkinlikleri artıran akıllı, güvenilir ortaklarla insanları güçlendirmekle ilgili.