AI agent'larına root yerine typed tool'lar ve kapsamlı token'larla MCP üzerinden deploy izni vermek

dev.to'da yayımlanan bir yazı, kodlama agent'ları olgunlaştıkça ortaya çıkan bir boşluğa değiniyor: agent'lar kodu güvenli çalıştırmayı öğrenmeden çok önce iyi yazmaya başladılar. Cursor veya Claude'dan bir şeyi deploy etmesini ve log'lara bakmasını istediğinizde en kolay yol, bir config dosyasına atılmış bir SSH anahtarı veya cloud admin token'ıdır. Yazar, bunun tam olarak bir agent'ın yanlış okunan bir stack trace yüzünden production verilerini yok edebilecek kadar ayrıcalıklı hale gelmesinin yolu olduğunu savunuyor ve farklı bir pattern öneriyor: deploy operasyonlarını Model Context Protocol (MCP) üzerinden açmak ve insan ekibi yöneten role-based access control'un aynısını uygulamak.

Açık shell yerine typed tool'lar

MCP, bir AI client'ının bir sunucudaki tool'ları keşfetmesi ve çağırması için standart bir yoldur. Agent shell komutları doğaçlama yapmak yerine typed bir katalog görür — deploy, restart, servis listeleme, log okuma, environment variable ayarlama — burada her tool'un bir schema'sı vardır ve sunucu her çağrının ne yapmasına izin verildiğine karar verir.

Yazıya göre bu değişim üç nedenden dolayı önemli. Yetenek yüzeyi açık olduğundan tool listesini okuyup agent'ın neler yapabileceğini bilebilirsiniz. Yetkilendirme sunucudadır; sunucu client'a güvenmek yerine her çağrıda bir token'ı kontrol eder. Ve tool çağrıları dashboard ile aynı API'den geçtiği için aynı audit log'larına düşer.

Pratikte tehdit modeli

Yazar, herhangi bir şey kurmadan önce neye karşı korunduğunuzu yazmanızı öneriyor. Çoğu küçük ekip için liste şöyle görünür: agent bir talimatı yanlış anlar ve yanlış servise dokunur; bir credential sohbet kaydına veya bir commit'e sızar; bir README, issue veya log satırına gizlenmiş bir prompt injection, agent'ı kimsenin istemediği bir şey yapmaya ikna eder; ya da test için verilmiş bir token hiç iptal edilmez. Bu sorunların hiçbiri daha akıllı bir model ile çözülmez — kapsamlandırmayla (scoping) çözülür.

Bir kapsam kontrol listesi

Yazı, platformdan bağımsız olarak geçerli kurallar sunuyor. Kişi başına, workspace başına token'lar verin; asla bir token'ı ekip içinde paylaşmayın veya tek projelik bir agent için admin token'ını yeniden kullanmayın. Agent'ın rolleri icat etmek yerine mevcut rolleri miras almasına izin verin: token'ı veren insanın izinlerinin aynısına veya daha azına sahip olmalı; staging ile sınırlı bir geliştirici, aynı duvara çarpan bir agent üretmelidir. İnteraktif shell'leri tamamen dışarıda bırakın, çünkü shell erişimi diğer tüm kontrolleri atlatabilir. Token'lara parola gibi davranın; onları MCP client config'inde veya bir secret manager'da tutun ve iptal ederek rotate edin. Ve geri alınabilir eylemleri tercih edin — bir agent deploy edebiliyorsa, kendi deploy'unu tek çağrıyla geri alabilmeli de.

Çalışan bir örnek

Yazar bu pattern'i Peon ile test etmiş; Peon, MCP endpoint'i ayrı bir script olarak değil doğrudan uygulamanın içine gömülü olan, açık kaynaklı, self-hostable bir deploy platformu. Cursor veya Claude Desktop'ta kurulum kısa bir config: bearer token ile kimlik doğrulanan streamable bir HTTP sunucusu. Token'lar dashboard'da Keys and Tokens altında oluşturuluyor, tek bir workspace'e kapsamlı ve oluşturan kişinin rolünü miras alıyor — bir owner veya admin token'ı sunucuları yönetebilirken, bir project member token'ı yalnızca o üyenin projelerine ulaşabiliyor.

Kendi sunucunuzu kursanız bile kopyalamaya değer iki tasarım kararı vurgulanıyor. Birincisi, shell exec tool'ları MCP'ye hiç kaydedilmiyor: agent deploy edebilir, restart edebilir, geri alabilir, log okuyabilir ve environment variable'ları yönetebilir ama bir sunucuda veya bir container içinde shell açamaz. İkincisi, aynı RBAC API'yi, MCP sunucusunu ve uygulama içi asistanı yönetiyor — güvenlik sınırı UI değil, API'dir.

Gerçekçi bir oturum nasıl görünür

Yazı temsili bir döngüyü adım adım anlatıyor: hangi servisin son deploy'unu başarısız kıldığı sorulduğunda agent servisleri listeler, başarısız build'in log'larını çeker, eksik bir DATABASE_URL fark eder, çözümü açıklar ve uygulamadan önce sorar. Onaydan sonra değişkeni ayarlar, bir yeniden deploy tetikler ve durumu izler; health check'ler başarısız olursa geri alır ve raporlar. Bu döngünün hiçbir adımı root gerektirmedi — her adım platformun kaydedebileceği veya reddedebileceği typed bir çağrıydı.

Client tarafı alışkanlıklar ve sınırlar

Sunucu tarafı kapsamlama temeldir, ama yazı client tarafı guardrail'lar da ekliyor: deploy eden, silen veya environment variable değiştiren her tool için onay isteyin; keşif amaçlı oturumlar için salt okunur viewer token'ları bulundurun; log'lar ve issue metinleri enjekte edilmiş komutlar taşıyabileceğinden agent'a tool çıktısının talimat değil veri olduğunu açıkça söyleyin; ve unutulmuş token'ları yakalamak için audit kaydını haftalık gözden geçirin.

Ayrıca agent'lar kapsamlamadan bağımsız olarak bazı işlere uygun değil: ilk kez kurulan altyapı, veri kaybı riski taşıyan veritabanı migration'ları, billing, ana domain için DNS ve yedeklerin silinmesi. Bunlar insanda kalmalı ya da en azından adım adım insan onaylı olmalı.

Neden önemli

Kodlama agent'ları yazılım yazmaktan onu işletmeye doğru ilerlerken, varsayılan entegrasyon — yapıştırılmış SSH anahtarları ve admin token'ları — onlara hiçbir görevin gerektirmediğinden çok daha fazla ayrıcalık veriyor. Mevcut RBAC ile birleşen MCP, bir AI client ile altyapı arasında bir least-privilege sözleşmesi sunuyor: açık bir tool kataloğu, çağrı başına yetkilendirme ve paylaşılan bir audit kaydı. Kendi sunucularını çalıştıran ekipler için yazı, bunun self-hosting'in AI araçlarını riskli değil daha güvenli kıldığı nadir durumlardan biri olduğunu savunuyor; çünkü hem agent'ın neyi çağırabileceğini hem de kimin çağırmasına izin verildiğini siz kontrol ediyorsunuz.