AI API Ağ Geçidi Aracılığıyla MCP Bağlayıcısı Yönetişimi: OAuth Belirteçleri, Araç Kapsamları ve Kullanıcı Başına İlişkilendirme

Bir aracı Gmail'i, Drive'ı, Stripe'ı, dahili bir sistemi veya uzak bir MCP sunucusunu aradığında, model isteği güvenlik olayının yalnızca bir parçasıdır. Gerçek operasyonel soru şudur: Bağlayıcıya kim yetki verdi, hangi OAuth kapsamlar verildi, hangi araç çağrıldı, hangi veriler model sağlayıcı sınırlarının dışına çıktı ve bir olay sırasında erişim nasıl iptal edilebilir?

Yalnızca proxy model çağrılarını kullanan bir AI API ağ geçidi bu soruları yanıtlayamaz. Kiracıyı, modeli, API anahtarını, bilgi istemi boyutunu ve maliyetini bilebilir. Modelin, işi bir insan kullanıcının OAuth jetonu altında çalışan bir bağlayıcıya devrettiğini bilmiyor olabilir. Bu boşluk ilişkilendirmeyi, onay politikasını, iptali ve denetim yanıtını zayıflatır.

Pratik model, MCP bağlayıcı yetkilendirmesini birinci sınıf ağ geçidi kontrol düzlemi nesnesi olarak ele almaktır. Bağlayıcı yönetimini araç adlarından oluşan bir izin verilenler listesine indirgemeyin. API anahtar yönetimi, model erişimi, kiracı politikası ve kullanım analizlerini zaten yöneten aynı yönetişim katmanının bir parçası olarak bağlayıcı kaydını, OAuth belirteç kaynağını, araç kapsamı sınıflandırmasını, onay politikasını, iptal durumunu ve denetim günlüğünü yönetin.

Gerçekler, Öneriler ve Tahminler

Gerçekler: OpenAI uzak MCP'yi Yanıtlar API aracı kategorisi olarak belgelendirir ve uygulamaların uzak MCP sunucusu için bir OAuth erişim belirteci sağlamasına olanak tanır. OpenAI ayrıca Gmail, Google Drive, Google Takvim, Dropbox ve Microsoft Teams gibi barındırılan hizmet bağlayıcılarını da tanımlar. OpenAI'ın veri kontrolü belgelerinde, uzak MCP sunucu aracıyla kullanılan MCP sunucularının üçüncü taraf hizmetleri olduğu ve bunlara gönderilen verilerin bu hizmetlerin saklama politikalarına tabi olduğu belirtiliyor. Anthropic'nin bağlayıcı belgeleri, uzak MCP sunucularını kullanan özel bağlayıcıları açıklar ve kullanıcıların daha sonra iptal edilebilecek izinlerle birlikte genellikle OAuth aracılığıyla bağlayıcılara yetki verdiğini not eder. MCP yetkilendirme spesifikasyonu, HTTP tabanlı MCP aktarımları için OAuth tarzı yetkilendirmeyi kullanır. OAuth RFC 9700'deki güvenlik kılavuzu jeton yönetimi, yetkilendirme kodu akışları ve istemci güvenliğiyle ilgilidir.

Öneriler: Bir ağ geçidi, üretimde kullanımdan önce bağlayıcıları kaydetmeli, her bağlayıcı çağrısını kiracıya, anahtara, kullanıcıya, belirteç konusuna ve sunucu kimliğine bağlamalı, araçları okuma/yazma riskine göre sınıflandırmalı, dağıtımdan önce onay politikasını uygulamalı ve iptal durumunu merkezi olarak korumalıdır.

Tahminler: Uzaktan MCP benimsenmesi, AI ağ geçitlerini model yönlendirme ve belirteç ölçümünün ötesine taşıyacaktır. Bağlayıcı kimliğini, OAuth kapsamını, onay kararlarını ve aşağı yönde saklama sınırlarını göremeyen ağ geçitlerinin, düzenlemeye tabi, kurumsal ve iş ortağı tarafından işletilen ortamlarda kullanılması daha zor olacaktır.

Yönetim Sorunu Kimlik Bölünmesinden Kaynaklanıyor

Bağlayıcı çağrıları en az üç kimlik içerir ve günlüklerde veya politika kontrollerinde birleştirilmemelidir.

• Ağ geçidi arayan: model isteğini gönderen API anahtarı, hizmet hesabı, iş yükü veya iş ortağı uygulaması.
• Yetki verilen kullanıcı: Gmail'e, Drive'a, CRM'ye, takvime, ödemelere, dahili verilere veya başka bir korunan kaynağa erişim yetkisi veren insan veya son kullanıcı.
• Bağlayıcı hedefi: araç çağrısını alan ve bunu başka bir sisteme iletebilecek uzak MCP sunucusu veya barındırılan hizmet bağlayıcısı.

Bu kimlikler user adlı tek bir alanda toplanırsa denetim izi belirsiz hale gelir. Bir üretim hizmeti hesabı 20.000 son kullanıcı adına istek gönderebilir. Tek bir insan, farklı kapsamlara sahip birden fazla bağlayıcıya yetki verebilir. Uzak bir MCP sunucusu, birden fazla aşağı akış hizmeti tarafından desteklenen araçları açığa çıkarabilir. Ağ geçidinin üçü için de ayrı alanlara ihtiyacı var.

Faydalı bir etkinlik modeli aşağıdaki gibi alanlarla başlar:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

Bu yapı, güvenlik, finans ve platform ekiplerinin aynı kayıttan farklı soruları yanıtlamasına olanak tanır. Hangi kiracı aracı çağırdı? Hangi uygulama anahtarı bunu yaptı? Hangi son kullanıcıya erişim yetkisi verildi? Hangi bağlayıcı veri aldı? Eylem salt okunur mu yoksa yıkıcı mıydı? Onay gerekli miydi?

Bağlayıcıları Ağ Geçidi Kaynakları Olarak Modelleyin

Bir bağlayıcının üretimde kullanılmadan önce kaydedilmesi gerekir. Kayıt işleminin yavaş olması gerekmez ancak politikanın referans alabileceği dayanıklı bir nesne üretmelidir.

Minimal bir bağlayıcı kaynağı şunları içerebilir:

• tenant_id: bağlayıcıyı kullanmasına izin verilen kiracı veya kuruluş.
• connector_id: sunucunun görünen adlarından bağımsız, sabit bir dahili tanımlayıcı.
• server_url: uzak MCP sunucu URL'si veya barındırılan bağlayıcı tanımlayıcı.
• owner_user_id: onu kaydeden yönetici veya kullanıcı.
• authorization_server: mevcut olduğunda veren veya yetkilendirme sunucusu meta verileri.
• allowed_tools: incelenen araç adları ve sürümleri veya parmak izleri.
• tool_classes: okuma, yazma, dışa aktarma, yönetici, ödeme, mesajlaşma veya bilinmiyor.
• approved_scopes: Bağlayıcı için OAuth kapsam onaylandı.
• retention_class: dahili, model sağlayıcı, üçüncü taraf standart veya hassas iş yükleri için yasaklanmıştır.
• revocation_status: etkin, user_revoked, tenant_disabled, süresi dolmuş, karantinaya alınmış veya reddedildi.

Bu, ruhen bir model profiline veya sağlayıcı kimlik bilgisi kaydına benzer, ancak bağlayıcı yetkilendirmesi, yukarı akış model anahtarıyla aynı nesne değildir. Sağlayıcı çalışma zamanı kimlik bilgileri, ağ geçidinin model API'lerini çağırmasına izin verir. Bağlayıcı belirteçleri, üçüncü taraf veya dahili sistemlere devredilen yetkiyi temsil eder. Ayrı bir kaynağı, depolama kontrollerini ve denetim politikasını hak ediyorlar.

Komisyoncu olun veya OAuth Tokenı Kasıtlı Olarak Doğrulayın

İki yaygın uygulama modeli vardır.

Ağ geçidi aracılı OAuth

Bu modelde, ağ geçidi OAuth akışını başlatır veya koordine eder, yenileme belirteçlerini veya erişim belirteci malzemesini bir kasada saklar, kısa ömürlü bağlayıcı oturumları başlatır ve uzak MCP çağrılarını gönderirken erişim belirteçlerini ekler. Bu, ağ geçidine izin, belirtecin ömrü, iptal ve denetim birleştirmeleri üzerinde güçlü bir kontrol sağlar.

Bunun karşılığı karmaşıklıktır. Ağ geçidinin izin ekranlarını, yetkilendirme kodu akışı güvenliğini, belirteç yenilemeyi, belirteç rotasyonunu, şifrelenmiş depolamayı, yönlendirme URI yönetimini, veren doğrulamayı ve kiracıya özgü OAuth uygulama yapılandırmasını yönetmesi gerekir. RFC 9700 burada önemlidir çünkü bu model, ağ geçidini OAuth istemci sorumluluklarına yakın hale getirir.

Uygulama tarafından yönetilen OAuth

Bu modelde uygulama OAuth jetonunu alır ve uzak bir MCP bağlayıcıyı çağırırken bunu model veya ağ geçidi yolundan geçirir. Mevcut ürünlerde zaten bağlayıcı yetkilendirme akışları olabileceğinden bunun gönderilmesi daha hızlı olabilir.

Bölge parçalanmış yönetimdir. Ağ geçidi yalnızca opak bir belirteç görüyorsa belirtecin konusunu, kapsamlarını, vereni, yeniliğini, iptal durumunu veya izin kaynağını bilmiyor olabilir. Bu modelin daha güvenli bir sürümü, uygulamanın her çağrıyla birlikte imzalı bağlayıcı meta verileri sağlamasını gerektirir ve ağ geçidinin göndermeden önce vereni, kitleyi, geçerlilik süresini, bağlayıcı kaydını, kullanıcı bağlamayı ve onaylanmış kapsamı doğrulaması gerekir.

E-posta, takvim, depolama alanı, CRM ve ödemeler gibi kullanıcı verisi bağlayıcıları için kullanıcı başına OAuth jetonları tercih edin. Paylaşılan uzun ömürlü taşıyıcı jetonlar, kapsamı bir kiracıya ayarlanan ve daha yüksek riskli kaynaklar olarak incelenen açık hizmet hesabı iş akışlarıyla sınırlı olmalıdır.

Göndermeden Önce Araç Kapsamlarını Normalleştirin

MCP sunucuları araç adlarını ve meta verileri açığa çıkarabilir ve bazı ekosistemler salt okunur ek açıklamalar gibi ipuçları sağlar. Bu sinyalleri kullanın ancak sunucu tarafından sağlanan meta verilere tamamen güvenilirmiş gibi davranmayın. Araç meta verileri yanlış, eski, belirsiz veya çelişkili olabilir. OWASP'nin MCP kılavuzu en az ayrıcalık, izin verilenler listesine ekleme, kimlik doğrulama, yetkilendirme ve izlemeyi vurgular; MCP İlk 10 çalışma aynı zamanda alet zehirlenmesi risklerine de dikkat çekiyor.

Bir ağ geçidi kendi normalleştirilmiş eylem sınıflarını korumalıdır:

• Oku: mevcut içeriği arayın, listeleyin, alın, getirin, alın, özetleyin.
• Yaz: oluştur, güncelle, düzenle, etiketle, taşı, yorum yap, planla.
• Gönder: e-posta, sohbet mesajı, web kancası, destek talebi yanıtı, bildirim.
• Sil: kaldır, temizle, arşivle, iptal et.
• Dışa aktarma: toplu indirme, dosya aktarımı, veri kümesi çıkarma.
• Finansal: ücretlendirme, geri ödeme, fatura, ödeme, abonelik değişikliği.
• Yönetici: izin değişikliği, kullanıcı daveti, rol güncellemesi, politika düzenleme.
• Bilinmiyor: incelenmemiş veya güvenli bir şekilde sınıflandırılmamış her şey.

Ardından politikayı ham araç adları yerine normalleştirilmiş sınıflara uygulayın. Örneğin:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

Bu, bir bağlayıcı gmail.search'yı mail.messages.query olarak yeniden adlandırdığında politikanın istikrarlı kalmasını sağlar. Ham aracın hâlâ incelenmesi gerekiyor ancak onay sistemi operasyonel kategorilerde mantık yürütebilir.

Gönderim Öncesi Bağlayıcı Denetimi Çalıştırın

Ağ geçidi, model tarafından başlatılan bir bağlayıcı çağrısına izin vermeden önce, kompakt bir dağıtım öncesi karar vermelidir. Yapay zeka kullanım analizi, güvenlik politikası, onay iş akışı ve saklama politikasının buluştuğu yer burasıdır.

Pratik bir sıra şöyledir:

1. Kiracıyı ve anahtarı çözümleyin: ağ geçidi anahtarını, kiracıyı, iş yükünü, ortamı ve model isteğini tanımlayın.
2. Son kullanıcıyı çözümleyin:, yetki verilen bağlayıcılar için sabit bir son kullanıcı kimliği gerektirir. Açıkça izin verilmediği sürece, anonim olarak yetkilendirilen çağrıları reddedin.
3. Bağlayıcıyı çözümle: sunucu URL'sini veya barındırılan bağlayıcı kimliğini kayıtlı bir bağlayıcı kaynağıyla eşleştirin.
4. Belirteci doğrulayın: vereni, varsa hedef kitleyi, geçerlilik süresini, konuyu, kiracı bağlamayı, iptal durumunu ve gerekli kapsamları kontrol edin.
5. Sınıflandırma eylemi: okunacak, yazılacak, gönderilecek, silinecek, dışa aktarılacak, mali, yönetici veya bilinmeyen araç adını ve meta verilerini eşleyin.
6. Saklama sınırını kontrol edin: iş yükünün üçüncü taraf MCP sunucusunun işlenmesine ve günlüğe kaydedilmesine izin verip vermediğini belirleyin.
7. Onay politikasını uygula: otomatik izin ver, kullanıcı onayı gerektir, yönetici onayı gerektir, engelle veya karantinaya al.
8. Faturalandırılabilirse bütçe ayırın: Bağlayıcının yürütülmesinde doğrudan veya dolaylı masraflar varsa, bütçeyi göndermeden önce ayırın.
9. Kararını yazın: yalnızca başarıdan sonra değil, bağlayıcıyı çağırmadan önce kararda ısrar edin.

Öncelikle kararı yazmak önemlidir. Bağlayıcı zaman aşımına uğrarsa, kısmi çıktı akışı sağlarsa veya bir aşağı akış hatası tetiklerse, denetim günlüğünün yine de ağ geçidinin belirli bir girişim girişimine izin verdiğini veya reddettiğini göstermesi gerekir.

Onay İş Akışına Duyarlı Olmalıdır

Arama başına onayın anlaşılması kolaydır ve pratikte çoğu zaman kullanılamaz. Bir bildirimi okuması, Drive'da arama yapması, bir e-posta taslağı hazırlaması ve bir CRM kaydını güncellemesi gereken bir müşteri destek temsilcisi, her zararsız okuma işlemi için kullanıcıyı bir modal kullanmaya zorlamamalıdır. Aynı zamanda, bir model bir araç seçtiği için e-posta gönderme, bir dosyayı silme, bir ödemeyi iade etme veya bir klasörü dışa aktarma işlemleri sessizce devredilmemelidir.

Çalışabilir bir politika katmanlıdır:

• Düşük riskli kiracılar ve yeni kullanıcı yetkilendirmesi için incelenen salt okunur araçlara otomatik olarak izin ver.
• Gönderme, oluşturma, güncelleme, silme, dışa aktarma, mali ve yönetici işlemleri için onay gerektir.
• Adlandırılmış bir iş akışı, kapsam ve zaman aralığı için gruplandırılmış onaylara izin verin.
• Kapsamlar genişlediğinde, araç tanımları önemli ölçüde değiştiğinde veya bağlayıcı daha yüksek bir risk sınıfına geçtiğinde yeniden onay gerektir.
• İncelenene kadar bilinmeyen araçları engelleyin.

Gruplandırılmış onaylar açık olmalıdır. Bir kullanıcı şunu onaylayabilir: "Önümüzdeki 30 dakika boyunca bu destek iş akışının Drive'da arama yapmasına ve yanıt taslakları oluşturmasına izin verin, ancak göndermeden önce onay gerektirsin." Bu, ikili bağlayıcının izin verme/reddetme anahtarından daha kullanışlıdır.

Saklama Sınırlarının Kendi Alanı Gerekir

Uzaktan MCP çağrıları, verileri model sağlayıcının saklama ve işleme sınırlarının dışına taşıyabilir. Bu otomatik olarak yanlış değildir, ancak görünür olması gerekir. Tek bir veri saklama ayarı kapsamında model uç noktası kullanmasına izin verilen bir iş yükünün, aynı içeriği farklı saklama koşullarıyla üçüncü taraf MCP sunucusuna göndermesi yine de yasaklanmış olabilir.

Hem iş yüklerine hem de bağlayıcılara saklama sınıflandırması ekleyin. Örnek sınıflar:

• internal_only: üçüncü taraf bağlayıcı çağrılarına izin verilmez.
• approved_processors_only: bağlayıcı onaylı satıcı listesinde olmalıdır.
• third_party_standard_allowed: standart SaaS bağlayıcı işlemine izin verilir.
• no_argument_logging: bağlayıcı çağrılarına izin verilir, ancak bağımsız değişkenlerin çıkarılması veya karma hale getirilmesi gerekir.
• export_blocked: okumaya/aramaya izin verildi, toplu dışa aktarma reddedildi.

Bu, ağ geçidinin ekipleri ince bir hatadan koruduğu yerdir: model sağlayıcı veri kontrollerinin, aracının kullandığı her araca otomatik olarak uygulandığını varsayarsak. Veriler uzak bir MCP sunucusuna veya harici hizmet konektörüne gönderildikten sonra bunların geçerli olması gerekmez.

Bağlayıcı Denetim Defteri Oluşturun

Bağlayıcı denetim defteri, model isteklerini, ağ geçidi yetkilendirmesini, bağlayıcı gönderimini ve aşağı yönlü sonuçları birleştirmelidir. Yalnızca ham sağlayıcı izlerine güvenmeyin; çünkü her sağlayıcı, araç olaylarını farklı şekilde ortaya çıkarabilir ve uygulama günlükleri belirteci veya onay bağlamını atlayabilir.

Önerilen defter alanları şunları içerir:

• model_request_id ve izleme kimliği.
• tenant_id, gateway_key_id, iş yükü, ortam ve son kullanıcı kimliği.
• connector_id, sunucu URL karması, barındırılan bağlayıcı tanımlayıcı ve risk sınıfı.
• tool_name, araç sürümü veya meta veri parmak izi ve normalleştirilmiş eylem sınıfı.
• OAuth veren kuruluş, belirteç konusu, kapsam kümesi karması, süre sonu paketi ve belirteç kaynağı.
• Argüman karması, düzeltilmiş bağımsız değişkenler, duyarlılık sınıfı ve saklama sınıfı.
• Onay kararı, onaylayan, onay kapsamı ve onayın sona ermesi.
• Gönderim durumu, yanıt durumu, hata sınıfı, gecikme ve mevcut olduğunda aşağı akış istek kimlikleri.

Tam bağımsız değişken günlüğü, olaylara müdahale edilmesine yardımcı olabilir ancak aynı zamanda gizlilik ve saklama riskini de artırır. Varsayılan olarak yapılandırılmış alanları, karma oluşturmayı, seçici düzenlemeyi ve duyarlılık etiketlerini tercih edin. Yalnızca açık bir olay veya geçerlilik süresi olan hata ayıklama politikası kapsamında tam yakalamaya izin verin.

İptal ve Karantina, Ürün Gereksinimleridir

İptal, manuel olarak yapılan bir veritabanı düzenlemesi olamaz. Kullanıcıların ve yöneticilerin anında politika durumuna dönüşen iş akışlarına ihtiyacı var.

En azından şu işlemleri uygulayın:

• Kullanıcı bağlantısını kes: bir kullanıcının bağlayıcı yetkilendirmesine ilişkin tüm jetonları iptal edin veya devre dışı olarak işaretleyin.
• Kiracının devre dışı bırakılması: ilgisiz model trafiğini devre dışı bırakmadan kiracının tamamı için bir bağlayıcıyı engelleyin.
• Belirteç süre sonu yönetimi: yenileme başarısız olduğunda veya yetkilendirme güncelliği politikayı aştığında kapatılamaz veya yeniden yetkilendirilmez.
• Bağlayıcı karantinası: yapılandırmasını ve günlüklerini inceleme için korurken bir bağlayıcıyı engelleyin.
• Acil durum reddetme listesi: sunucu URL karması, bağlayıcı kimliği, veren kuruluş veya araç parmak izine göre engelleme.
• Kapsamın düşürülmesi: bir iş akışının artık geniş erişime ihtiyacı kalmadığında daha az kapsamla yeniden yetkilendirme.

Uygulamanın önemli detayı, iptal durumunun gönderim sırasında kontrol edilmesi gerektiğidir. Gece senkronizasyonu mutabakat için faydalıdır ancak olaya müdahale için yeterli değildir.

Uzak MCP Bağlayıcı

Bir bağlayıcıyı üretim kiracılarının kullanımına sunmadan önce onu yönetilen bir bağımlılık olarak test edin. Kısa bir araştırma paketi birçok entegrasyon ve politika hatasını yakalar.

• Meta veri keşfi, kararlı sunucu kimliğini ve beklenen araç tanımlarını döndürür.
• Korunan kaynak meta verileri ve yetkilendirme davranışı, uygun olduğu durumlarda belgelenmiş varsayımlarla eşleşir.
• Dinamik istemci kayıt gereksinimleri anlaşıldı, desteklendi veya açıkça devre dışı bırakıldı.
• Belirteç içermeyen istekler güvenli bir şekilde başarısız olur.
• Süresi dolmuş jetonlar tahmin edilebileceği gibi başarısız olur ve kontrolsüz yeniden denemeleri tetiklemez.
• Okuma/yazma sınıflandırması yalnızca açıklamalarla değil, gözlemlenen davranışlarla da eşleşir.
• Kötü biçimlendirilmiş araç meta verileri reddedildi veya bilinmiyor olarak işaretlendi.
• Araç listesi değişiklikleri, adlar, kapsamlar, açıklamalar veya risk sınıfları değiştiğinde incelemeyi tetikler.
• Bağlayıcı hataları, hassas bağımsız değişkenler genel hata alanlarına sızmadan günlüğe kaydedilir.

Bu araştırmalar güvenlik incelemesinin yerini almaz ancak ağ geçidine sapmayı algılamak için tekrarlanabilir bir yöntem sunar. Uzak MCP sunucuları, model sağlayıcısından ve uygulama yayınlama döngünüzden bağımsız olarak değişebilir.

Uygulama Kontrol Listesi

• Kiracı, sunucu, yetkilendirme, kapsam, araç, risk, saklama ve iptal alanlarını içeren bir bağlayıcı kayıt defteri oluşturun.
• Her politika kararında ayrı ağ geçidi anahtarı kimliğini, yetki verilen son kullanıcı kimliğini ve bağlayıcı kimliğini ayırın.
• Bağlayıcı jetonlarını bir kimlik bilgisi kasasında saklayın ancak bunları model sağlayıcı çalışma zamanı kimlik bilgilerinden ayrı tutun.
• Kullanıcı verisi bağlayıcıları için kullanıcı başına OAuth tercih edin; paylaşılan hizmet belirteçlerini açık hizmet hesabı iş akışlarıyla sınırlayın.
• Araç işlemlerini okuma, yazma, gönderme, silme, dışa aktarma, finansal, yönetici ve bilinmeyen şeklinde normalleştirin.
• Bağlayıcı kaydı, belirteç geçerliliği, kapsam eşleşmesi, saklama uyumluluğu, onay durumu ve bütçe rezervasyonu için gönderim öncesi kontrolleri çalıştırın.
• Bağlayıcı kararlarını göndermeden önce günlüğe kaydedin ve yanıt veya hata sonrasında son durumu belirleyin.
• Kullanıcı bağlantısını kesme, kiracıyı devre dışı bırakma, bağlayıcı karantinası ve acil durum reddetme listesi iş akışları oluşturun.
• Üretimde kullanımdan önce bağlayıcı meta verilerini, belirteç davranışını, araç sapmasını ve hatalı biçimlendirilmiş meta verileri inceleyin.

Uygulanabilir Sonuç

MCP ve hizmet bağlayıcıları, modellerin gerçek sistemler üzerinde işlem yapmasına izin verdikleri için aracıları kullanışlı hale getirir. Aynı kullanışlılık, bağlayıcı yetkilendirmesini bir bilgi istemi mühendisliği ayrıntısına değil, bir kontrol düzlemi sorununa dönüştürür.

Ağ geçidi modelden, jeton sayısından ve API anahtarından daha fazlasını bilmelidir. Hangi bağlayıcının çağrıldığını, hangi kullanıcının onu yetkilendirdiğini, hangi kapsamların verildiğini, hangi araç eylem sınıfının talep edildiğini, onayın gerekli olup olmadığını, saklama sınırının uyumlu olup olmadığını ve erişimin nasıl iptal edilebileceğini bilmelidir. Bağlayıcı kayıt defteri, dağıtım öncesi politika kontrolü ve birleştirilmiş denetim defteri ile başlayın. Ardından bağlayıcı kullanımı arttıkça OAuth aracılık, gruplandırılmış onaylar, uygunluk araştırmaları ve acil durum karantinasını ekleyin.

Amaç MCP'ın uzaktan benimsenmesini engellemek değil. Amaç, bağlayıcı erişimini ilişkilendirilebilir, geri alınabilir, incelenebilir ve ekiplerin model erişimine ve OpenAI-uyumlu API ağ geçidine uyguladığı yönetişim beklentileriyle uyumlu hale getirmektir.

İlgili okuma

• daha geniş aracı aracı yönetim kalıpları