MCP Bir Bağlayıcı Değildir — Ajan Çağı İçin Yönetim Yüzeyinizdir

Çerçeveleme sorunu: "bağlayıcı" aslında verdiğiniz kararın altını çiziyor

Anthropic, Kasım 2024'te yapay zeka sistemlerini veri kaynaklarına ve iş araçlarına bağlamak için açık bir standart olarak Model Bağlam Protokolü'nü (MCP) tanıttığında, sektör yeni bir entegrasyon spesifikasyonuyla genellikle yaptığı şeyi yaptı: MCP'i altyapı olarak sınıflandırdı. Adaptörler, taşıma işlemleri, her model ve her araç için tek seferlik kod yazmayı bırakmanın düzenli bir yolu. Hepsi true ve CIO, CTO veya CISO koltuğunda oturuyorsanız hepsi önemsiz.

Bir işletme için önemli olan yeniden çerçeveleme şu şekildedir: Bir temsilcinin müşteri verilerinizi okuyan veya kayıt sistemlerinize yazan bir aracı çağırabildiği an, adlandırıp adlandırmadığınızdan bağımsız olarak yeni bir kontrol noktası oluşturmuş olursunuz. MCP, bu kontrol noktasının açıkça belirtilebileceği yerdir. Bu sadece temsilcinin araçlarınıza nasıl ulaştığıyla ilgili değil; kimin aradığını, kimin kimliğiyle aradığını, hangi araçların görünür olduğunu, her çağrının nasıl kaydedildiğini ve her çağrının maliyetinin ne olabileceğini belirlediğiniz yerdir. Bunlar bağlantı soruları değil, yönetişim sorularıdır.

MCP'ı bir bağlantı özelliği olarak ele alırsanız, yanlış şey için optimizasyon yaparsınız - kapsama alanı, entegrasyon sayısı, ilk arama süresi. Bunu bir yönetim yüzeyi olarak ele alın ve ajanların büyük ölçekte güvenli bir şekilde dağıtılıp dağıtılamayacağını belirleyen şeye odaklanın: politikanın bir kez uygulandığı ve her yerde gözlemlendiği tek, standartlaştırılmış, denetlenebilir bir arayüz.

"Birçok özel entegrasyon" neden sessizce yönetimi N kez yeniden oluşturuyor?

Çoğu işletme, acente çağına temiz bir sayfa ile girmez. Bir dizi entegrasyon noktasıyla geliyorlar: burada özel bir bağlantı, orada bir hizmet hesabı, iki çeyrek önce bir ekip tarafından oluşturulmuş ve kimsenin tam olarak hatırlamadığı bir API sarmalayıcı. Bunların her biri makul bir yerel karardı. Toplu olarak, bunlar bir yönetim sorunudur, çünkü her biri kimlik, yetkilendirme, kayıt tutma ve oran/maliyet kontrolünü kendi dilinde yeniden uyguluyor veya bunlardan bazılarını tamamen atlıyor.

Tahmin edilebileceği gibi üç arıza modu takip ediyor. Birincisi, kimlik kaymaları: Bir entegrasyon paylaşılan bir hizmet hesabı olarak çalışıyor, diğeri son kullanıcının kimliğine bürünüyor, üçüncüsü o zamandan beri ekip değiştiren biri tarafından basılan uzun ömürlü bir anahtarı kullanıyor - peki "bunu kim yaptı?" N farklı cevabı var, hiçbiri tam değil. İkincisi, yetkilendirme parçaları, çünkü bir aracın ne yapabileceğine ilişkin kurallar, N inceleme ritmine sahip N kod tabanında bulunur; Bir yerde sıkılaştırdığınız kontrol başka bir yerde sessizce gevşek kalıyor. Üçüncüsü - finans ve denetimin ilk önce hissettiği şey - iki entegrasyon yoluyla yanıtlanan aynı soru iki yanıt getirdiğinden rakamlar değişiyor. Paydaşlar sayılara güvenmeyi bıraktığında temsilci programının önemi kalmaz.

Standartlaştırılmış alternatif ne sihirli ne de ücretsizdir, ancak işin şeklini değiştirir. N entegrasyonu N kez yönetmek yerine, bir arayüzü bir kez yönetir ve araçları kasıtlı olarak onun aracılığıyla kullanıma sunarsınız. Kimlik tek bir yerde oluşturulur. Yetkilendirme, her bir bağlayıcının alışkanlığı değil, arayüzün bir özelliğidir. Günlük kaydı tekdüzedir, bu nedenle denetim izi aslında bir izdir. Ve sayılar artık kaymaz çünkü onları hesaplamak için tek bir yol vardır.

Kimlik ve kiracı bağlamı: bunu araçta değil, kapıda belirleyin

Bir yönetim yüzeyinin cevaplaması gereken ilk soru, bir çağrının kimin yetkisini taşıdığıdır. Çok kiracılı bir SaaS bağlamında bu inceliklidir, çünkü iki farklı gerçek söz konusudur: arayanın kimliği (hangi temsilci, hangi kullanıcı veya hizmet için hareket ediyor) ve çağrının çalıştığı kiracı bağlamı (hangi müşterinin verileri ve yetkileri geçerlidir). Bunları bir araya getirdiğinizde, bir amaç için meşru olarak kimliği doğrulanmış bir temsilcinin, asla devralmaması gereken ayrıcalıklarla hareket etmeye yönlendirildiği klasik karışık temsilci hatasıyla karşılaşırsınız.

Benimsenmesi gereken disiplin, kiracı bağlamını arayanın oturumunun iddia ettiği her şeyden değil, sunucu tarafındaki kiracı bağlamasından türetmektir. Kendi uygulamamızda, özellik erişimini kısıtlayan müşteri katmanı, arayanın oturumundan asla geri okunmaz, kiracı bağlamından çözülür; böylece bir arayanın daha zengin görünümlü bir oturum sunarak kendi etki alanını genişletmesi engellenir. Kimlik size kimin sorduğunu söyler; kiracı bağlamı size cevabın hangi veri ve yetkilendirme evreninde hesaplanması gerektiğini söyler. Her ikisi de herhangi bir araç çalıştırılmadan önce kapıda kararlaştırılır.

Burası aynı zamanda temsilcilerin kullanıcı olmadığı çağrısını yaptığınız yerdir. Konsoldaki insanın gözleri, tereddütleri ve yöneticisi vardır. Bir temsilcinin bir döngüsü vardır. Ona verdiğiniz kimlik ve bağlam, sağladığınız herhangi bir kişiden daha hızlı ve daha gerçek anlamda hareket edebileceğini yansıtmalıdır.

Araç başına yetkilendirme: maruz kalma bir karardır, varsayılan bir durum değildir

Erken ajan dağıtımlarında en yaygın ve en tehlikeli varsayılan, ya hep ya hiç teşhiridir: ajanı platforma bağlayın ve temel kimlik bilgilerinin erişebileceği her şeye erişmesine izin verin. Demoda kullanışlı, üretimde savunulamaz. Bir yönetim yüzeyi, her bir aracın görünürlüğünü ve iznini kasıtlı, gözden geçirilebilir bir karar olarak ele alır.

Somut olarak yetkilendirme tek bir açma/kapama düğmesi yerine çok eksenli olmalıdır. Belirli bir aracın yalnızca arayanın kapsamı izin verdiğinde ve kiracının katmanı onu içerdiğinde ortaya çıkması için, yukarıda açıklandığı gibi kiracı bağlamından kaynaklanan katmanla birlikte kapsam ve katman olmak üzere üç eksenli bir model kullanıyoruz. İkinci eksenin amacı, yeteneğin yalnızca kimin istediğinin değil aynı zamanda hangi müşterinin yetkilerinin yürürlükte olduğunun da bir fonksiyonu olmasıdır. Bu, maruz kalma yüzeyini dürüst tutar: Kataloğa yeni bir araç eklemek, her kiracıdaki her temsilcinin ona sessizce erişebilmesini sağlamaz.

Mimarlarınıza vereceğiniz zihinsel model bir katalogdur, bir santral değil. Katalogdaki her araç, kimin arayabileceği ve hangi kiracı koşulları altında arayabileceği hakkındaki bir karar yoluyla yerini kazanmıştır. Şu anda hiçbir temsilcinin ihtiyaç duymadığı araçlar katalogda yer almıyor. "Ya hep ya hiç" bir false ekonomisidir; "araç başına bilinçli fiyatlandırma" gerçek bir denetimle temas ettiğinde ayakta kalabilen tek yaklaşımdır.

Başarısızlık durumunda kapatılır: okuma ve eylem arasındaki asimetri

Okuma ve yazma işlemleri ahlaki olarak eşdeğer değildir ve yönetim yüzeyiniz de öyleymiş gibi davranmamalıdır. Hatalı bir okuma işlemi, kurtarılabilir ancak genellikle görünmez olan eski veya boş veriler döndürür. Hatalı bir yazma işlemi, kayıt sistemini değiştirir, gerçek bir müşteriye mesaj gönderir veya para transferi yapar. Yanlış olmanın maliyeti asimetriktir, bu nedenle varsayılan duruş da asimetrik olmalıdır.

Uyduğumuz kural, yazma araçlarının kapatılmamasıdır. Yetkilendirme belirsizse, kiracı bağlamı temiz bir şekilde çözülemezse, koruma değerlendirilemezse yazma gerçekleşmez. Bu, birçok entegrasyonun miras aldığı kolaylık odaklı varsayılanın tam tersidir; burada değerlendirilmemiş bir kontrol "izin ver" olarak çözümlenir ve böylece mutlu yol pürüzsüz kalır. Fail-open, haftalar sonra bir temsilcinin kimsenin onaylamadığı koşullar altında yazdığını keşfetmenin yoludur. Durumu değiştiren veya müşteriye dokunan herhangi bir şey için, güvenli temerrüt reddetmedir ve buna izin verildiğini gösterme yükümlülüğü çağrıdadır.

Burada kültürel bir boyut var. Mühendisler işlerin düzgün çalışması için optimizasyon yapar; güvenlik ise işlerin en kötü şekilde bozulmaması için optimizasyon yapar. Bir yönetişim yüzeyi, en kötü durumun - yetkisiz bir yazma işleminin sessizce yürütülmesi - kabul edilemez olduğunu, hatta bazen sorunsuz olabilecek bir yazma işlemini reddetme pahasına bile olsa, kodladığınız yerdir.

Bütçe defterleri ve acil durdurma düğmesi: maliyeti birinci sınıf bir kontrol olarak yönetmek

Aracılar, geleneksel entegrasyonların çoğunlukla sunmadığı bir risk kategorisini ortaya koyuyor: otonom harcama. Araçları çağıran bir döngü, bir hata veya karşıt bir istem yoluyla, onları herkesin amaçladığından çok daha fazla çağırabilir; API bütçesini yakabilir, alt ödemeleri tetikleyebilir veya müşteri akınına uğrayabilir. Bu nedenle maliyet kontrolü, hasar oluştuğunda devreye giren bir fatura uyarısı olarak sonradan devreye sokulmak yerine, yönetim yüzeyine aittir.

Çalıştırdığımız mekanizma, herhangi bir harcamadan önce değerlendirilen, çalıştırma başına, günlük ve 30 günlük yuvarlanan limitlere sahip bir bütçe defteridir; ayrıca yürütmeden önce kontrol edilen bir kapatma anahtarı da bulunur. Sıralamaya dikkat edin: bütçe ve acil durdurma anahtarı, harcamadan önce değerlendirilir, sonrasında uzlaştırılmaz. Harcamayı aştığınızı bildiren bir uyarı, harcama sonrası bir değerlendirmedir; bütçe aşımı çağrısını reddeden bir defter ise bir kontroldür. Üç zaman ufku önemlidir çünkü arıza modlarının farklı şekilleri vardır — kontrolden çıkmış bir döngü, çalıştırma başına sınırı aşar, yanlış yapılandırılmış bir zamanlama, günlük sınırı aşar ve yavaş ilerleme yalnızca 30 günlük pencereye karşı ortaya çıkar.

Kesme düğmesi tasarımda kendi satırını hak ediyor. Ne olduğunu henüz anlamadığınızda ve etkinliğin hemen durması gerektiğinde başvurduğunuz kontrol mekanizmasıdır. Yürütülmeden önce değerlendirilir, bir devre kesicidir, bir temizleme aracı değildir. Her ajan programı anında şu soruyu yanıtlayabilmelidir: Bunu nasıl durdururuz? Eğer cevap üç ekibi çağırmayı ve anahtarları elle iptal etmeyi içeriyorsa, bir kapatma düğmeniz yok demektir; sadece bir umudunuz var.

Denetim ve düzenleme: kapsamlı, zaman sınırlı ve gözlemlenebilir

Gözlemlenemeyen yönetim, yönetim değildir; niyettir. Yüzeyin son katmanı, üzerindeki her şeyin sonradan kanıtlanabilir olmasını sağlayan katmandır. Ajan anahtarları, gerçekten ihtiyaç duydukları araçlarla sınırlandırılmalı ve zaman sınırlı olmalıdır, böylece bir kimlik bilgisinin etki alanı süresiz olarak kalmak yerine, belirli bir program dahilinde sıfıra iner. Sonsuza dek her şeyi yapabilen bir anahtar, bir olay incelemesinin enkazında bulunan en yaygın kalıntıdır.

Aynı şekilde, denetim izi de kaydettiği verilere saygı duymalıdır. Günlük, ne olduğunu - hangi araç, hangi kimlik ve kiracı bağlamında, hangi sonuçla - yakalayacak şekilde çağrı başına sansür uyguluyoruz; böylece kontrollerin korumak için var olduğu çok hassas verilerin ikincil bir kopyası haline gelmiyor. Sessizce düz metin müşteri kayıtlarını biriktiren bir denetim günlüğü bir kontrol değildir; dostça bir isimle yeni bir yükümlülüktür.

Bu özellikler (kapsamlı anahtarlar, zaman sınırları, çağrı başına karartma, tek tip denetim) bir CISO'nun bir olaydan sonra gerçekten sorulan soruları yanıtlamasına olanak tanır: Bu kimlik bilgisi ne yapabilir, ne kadar süreyle yapabilir, gerçekte ne yaptı ve bunu kanıtlama sürecinde daha fazla bilgi sızdırmadan kanıtlayabilir miyiz?

Sürekli riske bağlamak ve geriye kalanlar konusunda dürüst olmak

Bunların hiçbiri tek seferlik bir kurulum değildir. NIST Yapay Zeka Risk Yönetimi Çerçevesi (AI RMF 1.0), yapay zeka riskini yönetmenin, tamamlayıp rafa kaldırdığınız bir kontrol listesi değil, sürekli bir süreç olduğunu açıkça belirtmektedir. Bir yönetim yüzeyi, sürekli sürece tek bir hareket alanı sağladığı için değerlidir: yeni bir risk ortaya çıktığında, yetkilendirmeyi, bütçeleri, maruziyeti veya denetimi N entegrasyon arasında takip etmek yerine tek bir arayüzde ayarlarsınız. Standardizasyon, sürekli yönetimi arzu edilen bir şey olmaktan ziyade yönetilebilir kılan şeydir. Ayrıca, düşünülmüş bir maruziyet kararının iki kez karşılığını vermesinin nedeni de budur - birincisi kararı verdiğinizde, ikincisi ise her yeniden gözden geçirmeniz gerektiğinde.

Kalan risk konusunda dürüst olun, çünkü yönetim kurulunuz da öyle olacak. Bir yönetişim yüzeyi, saldırı yüzeyini daraltır ve faaliyeti denetlenebilir hale getirir; ancak ajanları hatasız hale getirmez. Hızlı enjeksiyon, meşru olarak yetkilendirilmiş bir ajanı meşru görünümlü kötüye kullanıma yönlendirmeye çalışabilir. Kasıtlı olarak ifşa edilen bir araç, izinleri dahilinde yine de kötüye kullanılabilir. Bütçeler maliyeti sınırlar, ancak yargıyı değil. Deloitte'un "Kurumsal Yapay Zekanın Durumu" araştırması, yapay zeka hırsı ile onu yönetmek için operasyonel olgunluk arasındaki boşluğu defalarca göstermiştir ve bu boşluk tam olarak bu kalan risklerin yaşadığı yerdir. Doğru yanıt, boşluğun kapandığını iddia etmek değil, onu küçük, gözlemlenebilir ve sürekli olarak yönetilebilir hale getirmektir.

Platformumuzu bu inanç üzerine kurduk. SocialHub.AI, MCP üzerinden HTTP akışlı taşıma kullanarak anlamsal katman araçlarını sunar ve Claude, GitHub Copilot ve Microsoft 365 Copilot gibi aracılardan erişilebilir; burada açıklanan kontroller, bağlantı noktalarına dağılmak yerine arayüzde uygulanır: kiracı bağlamından katmanla üç eksenli yetkilendirme, başarısız olursa kapanan yazma işlemleri, ön yürütme kapatma anahtarıyla çalıştırma başına/gün başına/30 günlük bütçe defteri ve çağrı başına gizleme ve denetim ile kapsamlı, zaman sınırlı aracı anahtarları. Bu, McDonald's China üye GMV katkısını yaklaşık %5'ten %85'e çıkarmamıza yardımcı olduğumuz sadakat çalışmasının temelini oluşturan aynı yönetim disiplinidir; bu ölçekteki sonuçlar, veriye erişim arayüzü yapısı gereği güvenilir olduğunda hayatta kalır.

Eğer temsilcilerin kayıt sistemlerinize nasıl erişeceğine karar veriyorsanız, ekibinize sormanız gereken soru "hangi bağlantı elemanı" değil, "kimlik, yetkilendirme, kayıt ve maliyetin nerede belirlendiği ve bunun tek bir yer mi yoksa birden fazla yer mi olduğu"dur. Yönetişim odaklı bir MCP yüzeyinin pratikte nasıl göründüğünü görmek isterseniz, bir demo rezervasyonu yapın veya /platform/ai-frontier'daki yaklaşımımız hakkında daha fazla bilgi edinin.