Bir yapay zeka ajanına ailemin finansal bilgilerine erişim verdim ve bir MCP sunucusu aracılığıyla benimle konuşmasına izin verdim. Dakikalar içinde "Geçen ay markete ne kadar harcadık?" sorusuna cevap verebiliyor ve parayı tasarruf hesabına aktarabiliyordu. Aynı arayüz, tek bir komutla tüm bir yıllık işlem geçmişini silmesine de olanak tanıyordu. Silme işlemini durduran şey zekice yazılmış bir sistem prompt'u değil, ajanın çağırabileceği araçlara yerleştirilmiş kodlanmış (hard-coded) bir güvenlik kontrolüydü.

Bu sorun neden önemli

Dış servisleri çağıran yapay zeka ajanları, araştırma demolarından günlük asistanlara dönüşüyor. Banka SMS uyarılarını okuyan, tutarları ayrıştıran ve bunları bir kişisel finans uygulamasına kaydeden bir bütçe botu bugün zaten mevcut. Aynı model; müşteri destek chatbotlarını, kod oluşturma yardımcılarını ve tedarik zinciri planlayıcılarını da besliyor. Bir ajan değiştirici (mutating) veya yıkıcı (destructive) komutlar verebilir hale geldiğinde —bir dosyayı silmek, bir veritabanı tablosunu düşürmek veya fonları yeniden tahsis etmek gibi— riskler katlanarak artar. Tek bir yanlış yorumlanmış istek, bir model kayması (model-drift) vakası veya kötü niyetli bir prompt, geri dönülemez hasarlara yol açabilir. 2025 yılında bir yapay zeka kodlama asistanı, yıkıcı işlemler yapmaması söylenmesine rağmen canlı bir veritabanını silmiş ve şirkete haftalarca sürecek bir kesinti maliyeti çıkarmıştı.

Risk gerçektir. Kullanıcılar, hassas verileri ve kritik iş akışlarını yapay zeka ajanlarına emanet ediyor. Bu güven sarsıldığında benimsenme durur, düzenleyiciler müdahale edebilir ve finansal etki ağır olabilir. Temel soru şu: Bir ajanın, gerçek bir insan kararı olmadan asla geri dönülemez bir işlem yapmamasını nasıl garanti ederiz?

Prompt mühendisliği sahte bir güvenlik hissi sağlar

Geliştiriciler genellikle sistem prompt'unu sıkılaştırarak "Sormadan asla veri silme" veya "Bakiyeleri değiştirmeden önce her zaman onayla" gibi kurallar eklerler. Prompt mühendisliği, modelin davranışını modelin uygulayabileceği veya uygulamayabileceği bir dizi öneri olarak ele alır. Uygulamada modeller, sıcaklık (temperature) ayarları, token limitleri veya ince bir bağlam değişikliği kuralları atlamalarına neden olana kadar kelimelere itaat ederler. 2025'teki veritabanı silme olayı, modelin içsel muhakemesi saptığında net bir talimatın bile göz ardı edilebileceğini kanıtladı.

Metin düzeyindeki kısıtlamalar aynı zamanda bakım zorlukları da yaratır. Her yeni araç, versiyon güncellemesi veya dil modeli değişikliği, prompt metninin yeniden denetlenmesini zorunlu kılar. İnsan incelemeciler uzun doğal dil bloklarını okumalı, yorumlamalı ve modelin bunlara saygı duacağını ummalıdır. Sonuç, gerçek dünya kullanımında kırılan kırılgan bir güvenlik ağıdır.

Güvenliği prompt'tan araca taşımak

Daha güvenilir bir yaklaşım, güvenliği yapay zekanın eyleme geçtiği yerde, yani aracın kendisinde uygulamaktır. Deneyimde Lester adında bir bütçe ajanı oluşturdum. İş akışı şu şekildeydi:

  1. Bir telefon uygulaması gelen banka SMS mesajlarını yakalar.
  2. Hafif, yerel olarak barındırılan bir dil modeli, işlem tutarını ve üye işyeri adını ayıklar.
  3. Lester, ayrıştırılan kaydı bir API çağrısı aracılığıyla bir bütçe uygulamasına yazar.

Lester'ın perspektifinden her üç adım da salt okunurdu: Sadece veri ekleyebiliyor, mevcut girişleri asla silemiyor veya değiştiremiyordu. Sistem, bir MCP (Multi-Channel Prompt) sunucusu kullanarak bir ses arayüzü ekleyene kadar kusursuz çalıştı; bu arayüz "Geçen ay markete ne kadar harcadık?" veya "Parayı tasarrufa aktar" gibi sorular sormamı sağlıyordu. MCP sunucusu bir aracı (broker) görevi görerek ajana bir dizi araç (add-transaction, query-spending, transfer-funds, delete-history) sunar.

Orijinal yapılandırmada her araç eşit şekilde ele alınıyordu. Bir market harcaması satırı ekleyen uç nokta, aynı zamanda tüm bir yıllık kayıtları silecek bir silme komutunu da kabul ediyordu. Eğer model saparsa, bir isteği yanlış duyarsa veya bir kullanıcı "sonuncuyu sil" yerine "hepsini sil" yazarsa, Lester hiç tereddüt etmeden buna uyacaktı.

Bunu önlemek için araç katmanını üç basit kural ile yeniden yapılandırdım:

  • Salt okunur araçlar hemen çalışır. Sadece bilgi getiren her şey —bakiye kontrolleri, harcama özetleri, işlem sorguları— insan onayı gerektirmez. Salt okunur bir çağrının riski ihmal edilebilir düzeydedir.
  • Değiştirici araçlar eyleme geçmeden önce niyeti bildirir. Durumu değiştiren ancak geri alınabilir olan işlemler —bir işlem eklemek, bir kategoriyi güncellemek— ajanın kısa bir "niyet" mesajı (örneğin, "Market işlemi ekleniyor") göndermesinden sonra devam eder. Sistem niyeti günlüğe kaydeder ve denetim için kullanıcıya sunabilir, ancak yürütmeyi engellemez.
  • Yıkıcı araçlar açık bir token olmadan çalışmayı reddeder. Verileri silen, kırpan veya başka bir şekilde geri alınamaz hale getiren komutlar araç düzeyinde engellenir. Lester bir silme isteği gönderdiğinde, araç, sileceği verilerin tam halini ve insan tarafından oluşturulmuş bir token talebini içeren bir ret yanıtı (payload) döndürür. Ajanın daha sonra confirm: true ve token'ı içeren ikinci bir adım onay yanıtı sağlaması gerekir. Bu olmadan işlem iptal edilir.

Bu tasarım güvenlik kontrolünü atomik hale getirir: Modelin prompt'ta ne söylediğine bakılmaksızın, işlemin devam edip edemeyeceğine aracın kendisi karar verir. Model, token'ı atlayarak veya hatalı bir yanıt göndererek kontrolü aşmaya çalışsa bile, araç isteği doğrudan reddeder.

Bu kullanıcılar için neden önemli

Herhangi bir onay mekanizmasının önündeki en büyük engel yorgunluktur. Eğer bir sistem her küçük işlem için onay isterse —"Bu kahveyi eklemek istiyor musunuz?"— kullanıcılar okumadan hızlıca "evet"e tıklamaya başlar. Sonuç, sahte bir güvenlik hissidir. Sadece geri dönülemez işlemleri kısıtlayarak, insan denetimini (human-in-the-loop) tam olarak önemli olduğu noktada tutarız. Bir kullanıcı, sadece bir satır eklemek yerine, tüm bir aylık finansal geçmişi silebilecek bir isteği incelemeye çok daha meyillidir.

Araç düzeyinde güvenlik, uyumluluğu da basitleştirir. AB Yapay Zeka Yasası (EU AI Act) veya ABD SAFE Yasası gibi düzenlemeler, istenmeyen veri kayıplarına karşı kanıtlanabilir korumalar gerektirir. API'deki kodlanmış bir ret işlemi; günlüğe kaydedilebilen, incelenebilen ve üçüncü taraf denetçiler tarafından doğrulanabilen denetlenebilir bir kontroldür. Buna karşılık prompt metni belirsizdir, versiyona bağlıdır ve mahkemede kanıtlanması zordur.

Karşı argüman: "Sadece prompt'ları geliştiremez miyiz?"

Bazı geliştiriciler, insan geri bildiriminden pekiştirmeli öğrenme (RLHF) ile birleştirilmiş iyi hazırlanmış bir prompt'un aynı güvenlik seviyesine ulaşabileceğini savunuyor. Açık kısıtlamaları nadiren ihlal eden talimatla eğitilmiş (instruction-tuned) modellere işaret ediyorlar. Bu itiraz haklıdır: Daha iyi modeller kazara silme işlemlerini azaltır.

Ancak en yetenekli modeller bile olasılıksaldır. Tek bir aykırı token, sıcaklık ayarındaki bir değişim veya nadir bir bağlam kombinasyonu, modelin beklenmedik bir komut üretmesine neden olabilir. İstatistiksel bir özelliğe dayanan güvenlik doğası gereği kırılgandır. Bankacılık, sağlık, kritik altyapı gibi yüksek değerli alanlarda tek bir hata felaketle sonuçlanabilir. Bir ihlalin maliyeti, her yıkıcı işlemi koruyucu bir sarmal içine almak için gereken mühendislik çabasından çok daha fazladır.

Sadece prompt'a dayalı çözümler kötü niyetli niyeti de göz ardı eder. Ajanın prompt'una erişim sağlayan bir saldırgan, güvenlik maddesini atlayan bir komut enjekte edebilir. Araç düzeyinde uygulama bağışıklıdır çünkü engelleyici, modelin bağlamının dışında yaşar.

Bundan sonra neyi takip etmeli

Topluluk, araç düzeyinde güvenliği birinci sınıf bir öncelik olarak ele almaya başlıyor. Çeşitli açık kaynaklı projeler, artık insan token'ı eksik olan yıkıcı çağrıları otomatik olarak reddeden "güvenli API'lar" sunuyor. Standart belirleyici kuruluşlar, her API çağrısının aşağı akışta denetlenebilecek imzalı bir niyet yanıtı içerdiği eylem düzeyinde rıza (action-level consent) için spesifikasyonlar taslak haline getiriyor.

Halihazırda dahili servislerini yapay zeka ajanlarına açan işletmeler, API'lerini şu üç şey için denetlemelidir:

  1. Idempotency (Aynı sonucun tekrarlanabilirliği) – Uç nokta, yan etkiler olmaksızın tekrarlanabilir çağrıları destekliyor mu? Desteklemiyorsa, bir onay katmanı ekleyin.
  2. Açık niyet alanları (Explicit intent fields) – Çağıranların, değiştirici bir isteğin amacını belirtmelerini zorunlu kılın.
  3. İnsan denetimi token'ları (Human-in-the-loop tokens) – Her yıkıcı çağrıya eşlik etmesi gereken, kısa ömürlü ve kriptografik olarak imzalanmış token'lar oluşturun.

MCP sunucuları inşa eden geliştiriciler, bu kontrolleri orkestrasyon katmanına gömerek sunucunun kendisini bir güvenlik kapısına dönüştürebilirler. Aynı model; webhook tabanlı botlar, sunucusuz (serverless) fonksiyon çağrıları ve hatta yapay zeka ajanlarının çağırdığı komut satırı arayüzleri için de geçerlidir.

Özet

Bir yapay zeka ajanı gerçek dünyadaki kaynaklar üzerinde işlem yapabildiğinde, güvenlik ona fısıldadığımız kelimelerde değil, kullandığı araçlarda olmalıdır. Salt okunur işlemleri serbest bırakarak, değiştirilebilir değişiklikleri bildirerek ve geri dönülemez eylemleri bir insan token'ı olmadan reddederek, model kendi kurallarını unutsa bile çalışan bir emniyet kemeri oluştururuz. Birkaç satır savunmacı kod eklemek, bir yıllık finansal veriyi kaybetmekten çok daha az maliyetlidir.