Kayıtlı olmak yetkili olmak değildir: araç eklerken yetkiyi büyütmeyin

Bir ajana yeni bir araç bağlamak birkaç dakika sürer: yapılandırma dosyasına bir sunucu eklenir, bir klasöre beceri bırakılır, bir bağlayıcı formuna token yapıştırılır. Ajan bir sonraki çalıştırmada yeni aracı görür ve kullanmaya başlar. Bu hız işin cazip yanıdır; sorun da tam buradadır. Her bağlantı, kimsenin yüksek sesle sormadığı bir soruyu sessizce yanıtlar: bu ajan artık hangi veride, hangi görev için, neyi yapabilir?

Kurulu, kayıtlı, yetkili

Çoğu kurulum üç ayrı durumu tek bir duruma indirger. Disiplinin büyük kısmı bunları ayrı tutmaktır.

En sık görülen hata, kaydı yetkinin yerine koymaktır. Sunucu yapılandırmaya girdiği anda, o istemcide çalışan her görev, sunucunun sunduğu her işlemi, kurulumda kullanılan kimlik bilgisiyle çağırabilir hâle gelir. Bir öğleden sonralık talep ayıklama işi için eklenen araç, aylar sonra biri ajandan "iş listesini toparlamasını" istediğinde hâlâ oradadır ve hâlâ yazma yetkili bir token taşır.

Yetki nereden sızar

Güç nadiren tek ve göze batan bir izinle gelir. Küçük varsayılanlarla birikir:

• Sunucunun tamamının açılması. Bir talep takip sistemi için yazılmış MCP sunucusu genellikle okuma, yorum yazma, kapatma ve silme işlemlerini bir arada sunar. Filtrelemezseniz sunucuyu kaydetmek hepsini kaydetmek demektir.
• Geniş kimlik bilgileri. Bağlayıcının arkasındaki token, kolaylık olsun diye bir yönetici tarafından, kurum genelini kapsayacak şekilde oluşturulmuştur. Ajan artık yöneticinin erişimiyle hareket eder.
• Komut taşıyan beceriler. Beceri, talimatlardan ve bazen betiklerden oluşur. "Sürüm betiğini çalıştır" diyen bir beceri kimseye sürüm çıkarma hakkı vermez; ama ortam betiğe izin veriyorsa talimat kazara bir izne dönüşür.
• Talimat gibi okunan araç çıktısı. "Şimdi bunu şuraya ilet" diyen bir web sayfası, e-posta ya da talep metni veridir. Erişiminde gönderme aracı bulunan bir ajan bunu bir istek gibi algılayabilir.
• Zincirlenen araçlar. Başka araçları çağırabilen ya da başka bir ajanı başlatabilen bir araç, kendisine verilen yetkiyi aşağı akıştaki her şeye taşır.

İzni kuruluma değil, göreve verin

Çözüm, izin kararını "bu araç bağlı mı?" sorusundan "bu görevin bu işleme ihtiyacı var mı?" sorusuna taşımaktır. Pratikte her iş ihtiyaç duyduğu araçları ve işlemleri beyan eder; beyan edilmeyen her şey o çalıştırma için erişilemez olur. Yalnızca okuma yapan varsayımsal bir ayıklama görevi için beyan şöyle görünebilir:

task: summarize-open-issues
scope: repo example-org/web
tools:
  allow: [issues.list, issues.read, labels.list]
  deny:  [issues.comment, issues.close, issues.delete]
credential: read-only token for example-org/web
on_write_attempt: refuse and record

Biçimin önemi yok. Önemli olan, iznin yazılı olması, aracın kendisinden dar tutulması, göreve bağlanması ve bu sınırın dışındaki bir denemenin sessiz bir başarı yerine görünür bir ret üretmesidir. Bir sonraki görev talepler üzerine yorum yazmak zorundaysa kendi iznini alır ve bu izin kendi gerekçesiyle değerlendirilir.

Yeni bağlantıları salt okuma ile başlatın; yazma işlemlerini, her biri bir insanın onayına bağlı olacak şekilde birer birer ekleyin. Bu sıralamayı ajanlara salt okumayla başlayın yazısında ayrıntılı anlattık.

Beceriler talimattır, izin değil

Beceriler zararsız göründükleri için ayrıca ele alınmayı hak ediyor. Bir beceri bilgi birikimini paketler: bir test takımı nasıl çalıştırılır, bir rapor nasıl biçimlendirilir, hangi CLI bayrakları kullanılır. Bu yararlıdır; aynı zamanda ajanın uygulayacağı bir metindir. Topluluktan bir beceri kurmadan önce onu, tanımadığınız birinden gelen bir kabuk betiğini okur gibi okuyun: ajana neyi çalıştırmasını söylüyor, neye izin verildiğini varsayıyor, çalışma anında dışarıdan bir şey çekiyor mu? Bu incelemeyi topluluk becerilerini kurmadan önce gözden geçirmek yazısında, hangi mekanizmanın ne zaman uygun olduğunu ise MCP mi, beceri mi, CLI aracı mı yazısında bulabilirsiniz.

İlke basit: yeniden kullanılabilir bir talimat bir eylemi tarif edebilir ama o eyleme izin veremez. İzin, görevin kapsamından ve sonuç doğuran adımları onaylayan kişiden gelir; beceri dosyasından asla gelmez.

GoCux çizgiyi nereye çekiyor

GoCux bağlantıyı ve izni iki ayrı karar olarak ele alır. MCP araçları sizin uyumlu yerel istemcinizde çalışır; müşteri CLI'ı da kendi yerel araçlarının ve izinlerinin sahibidir. Yani yerel bir aracın neye dokunabileceğine bir listeden çıkarım yapılarak değil, sizin tarafınızda karar verilir. GoCux barındırılan bir MCP uç noktası yayınlamaz. Bir sunucunun yapılandırılmış olması onu her göreve açmaz; çalışma alanına kaydedilmiş bir bağlayıcı da tek başına bir iş emrine onu kullanma hakkı vermez.

Kimlik bilgileri tarayıcıda durmaz, sunucu tarafında referans olarak tutulur. Bir kimlik bilgisini tanımlamak, ajanın onunla gözetimsiz yazmasına izin vermek anlamına gelmez. Dışarıya göndermek, silmek, dışa aktarmak ya da başka bir ajanı işe koşmak gibi sonuç doğuran adımlar, onları hangi araç yürütecek olursa olsun ekipten birinin kararını bekler. Kurulum için MCP hızlı başlangıç ve ajan becerileri kılavuzu sayfalarına bakabilirsiniz.

Bir sonraki aracı bağlamadan önce

• Aracın sunduğu işlemleri listeleyin ve mevcut görevin gerçekten hangilerine ihtiyaç duyduğunu işaretleyin.
• O görevin verisiyle sınırlı bir kimlik bilgisi oluşturun; amaç yazmak değilse salt okuma olsun.
• Aracı kaydedin ama izni görev başına verin; izni olmayan bir görevin onu çağıramadığını doğrulayın.
• Herhangi bir beceriyi kurmadan önce baştan sona okuyun ve çalıştıracağı her komutu not edin.
• Araçlardan dönen içeriği veri olarak ele alın; içindeki talimatlar ekibinizden gelen istekler değildir.
• İzin dışındaki bir çağrının sessizce yeniden denenmek yerine görünür biçimde reddedilip kayda geçtiğini kontrol edin.
• Yazma, gönderme, silme ve görev devretme adımlarını, her seferinde bir eylem sınıfı olmak üzere onaya bağlayın.
• Onlara ihtiyaç duyan iş bittiğinde araçları kaldırın ve kimlik bilgilerini iptal edin.

Protokolün kendisi için MCP nedir yazısına ve modelcontextprotocol.io adresindeki spesifikasyona bakabilirsiniz.