Yapay Zeka API Ağ Geçidi Aracılığıyla Aracı Aracı Yönetişimi: Kapsamlar, Onaylar, Bütçeler ve Denetim Yolları
Aracı araçlarını bir AI API ağ geçidi aracılığıyla yönetmek için pratik bir referans mimarisi: araç kayıtları, kapsamlı anahtarlar, onay kapıları, araç başına bütçeler, MCP izin verilenler listeleri ve birleştirilmiş model/araç denetim izleri.
Ajan riski artık model istemiyle sınırlı değil. Bir üretim temsilcisi dahili dosyaları arayabilir, müşteri kayıtlarını sorgulayabilir, bir MCP sunucusunu arayabilir, kod çalıştırabilir, bir tarayıcı açabilir, e-posta gönderebilir, bir CRM'yi güncelleyebilir veya bir faturalandırma iş akışını tetikleyebilir. Yönetişim sorusu şu şekilde ortaya çıkıyor: Hangi kullanıcıya, anahtara, modele, aracıya ve araca hangi eylemi, hangi bütçeyle, denetim takibiyle ve geri alma yoluyla gerçekleştirme izni verildi?
Her ekip araca erişimi kendi SDK kodu içinden yönetirse politika, ortam değişkenleri, sağlayıcı kontrol panelleri, uygulama ara yazılımı ve belgelenmemiş MCP sunucuları arasında dağılır. Daha güvenli bir model, aracı aracının yürütülmesini bir kontrol düzlemi sorunu olarak ele almak ve bunu bir AI API ağ geçidi veya her aracının kullanması gereken standart bir araç yürütme sarmalayıcısı aracılığıyla uygulamaktır.
Bu makalede gerçekler, öneriler ve tahminler birbirinden ayrılmıştır. Gerçekler mevcut kamu rehberlerinden alınmıştır: OWASP'nin LLM Başvurusu İlk 10'u hassas bilgilerin ifşa edilmesi, tedarik zinciri zayıflıkları ve aşırı acentelik gibi riskleri içerir; NIST'in Yapay Zeka Risk Yönetimi Çerçevesi için Üretken Yapay Zeka Profili, üretken yapay zeka risklerinin haritalandırılmasını, ölçülmesini ve yönetilmesini vurgular; OpenAI'nin aracı kılavuzu, araç riskinin okuma/yazma erişimi, geri döndürülebilirlik, izinler ve finansal etki ile değerlendirilmesini önerir; ve MCP yetkilendirme kılavuzu, hassas kaynaklar ve işlemler için kapsamlı yetkilendirme kavramlarını kullanır. Aşağıdaki öneriler evrensel gereksinimler değil, uygulama kalıplarıdır.
Okuyucu sorunu: Model erişimi ile araç erişimi birbirine karıştırılıyor
İlk dönem LLM uygulamalarının çoğunda, bir API anahtarı bir temel soruyu yanıtladı: Bu hizmet bir modeli çağırabilir mi? Ajanlar bunu çok kaba bir şekilde yapıyorlar. Sohbet tamamlamaları gönderebilen bir anahtar, otomatik olarak müşteri verilerini dışa aktaramamalı, kabuk komutlarını çalıştıramamalı, Slack'te gönderi paylaşamamalı, biletleri değiştirememeli, rastgele web sitelerine göz atamamalı veya ödeme değişiklikleri gönderememelidir.
Yönetim katmanının daha spesifik soruları yanıtlaması gerekir:
- Çalıştırmayı hangi kiracı, çalışma alanı, kullanıcı, hizmet hesabı veya bayi müşterisi başlattı?
- Hangi model, bilgi istemi şablonu, aracı sürümü ve araç şeması kullanıldı?
- İstenen araç salt okunur muydu, geri döndürülebilir miydi, geri alınamaz mıydı, dışarıya yönelik miydi, mali miydi yoksa ayrıcalıklı mıydı?
- İstek sahibi gerekli kapsama sahip miydi?
- Onay gerekli miydi, verildi mi, reddedildi mi, süresi doldu mu veya acil durum politikası tarafından atlandı mı?
- Aracın maliyeti ne kadardı, kaç kez çağrıldı ve geriye kalan kümülatif bütçe ne kadardı?
- Hata ayıklama, uyumluluk incelemesi ve geri alma için hangi kanıtlar mevcut?
Aşağıdaki mimari, ağ geçidinin zaten model çağrıları aldığını varsayar. Aracın yürütülmesi daha sonra aynı ağ geçidi üzerinden, bir sepet hizmeti aracılığıyla veya her araç çağrısından önce ve sonra ağ geçidine rapor veren standart bir kitaplık aracılığıyla yönlendirilebilir.
Referans mimarisi: ağ geçidi düzeyinde bir araç yönetim katmanı
Pratik bir aracı yönetişim sisteminin yedi bileşeni vardır:
- Araç kaydı: Onaylanmış araçların, MCP sunucularının, barındırılan işlevlerin, yerel yürütme araçlarının ve dahili API'lerin yetkili listesi.
- Kimlik ve anahtar katmanı: ağ geçidi anahtarları, kullanıcılar, kiracılar, hizmet hesapları, ekipler ve bayi müşterileri.
- Kapsam motoru: Bir anahtarın veya kullanıcının belirli bir araç özelliğini çağırıp çalıştıramayacağına karar veren politika kontrolleri.
- Risk sınıflandırıcı: Patlama yarıçapını, veri hassasiyetini, tersine çevrilebilirliği, dış etkiyi ve maruz kalınan maliyeti açıklayan meta veriler.
- Onay iş akışı: yüksek riskli eylemler için yürütme öncesinde insan veya sistem onayı.
- Bütçe ve oran sınırı defteri: yalnızca model başına belirteç sınırları değil, araç başına ve aracı başına sınırlar.
- Denetim ve izleme deposu: Model çağrıları, araç çağrıları, onaylar, hatalar ve sonuçlar için birleştirilmiş kayıtlar.
Önemli tasarım kararı, asıl araç başka bir yerde çalışıyor olsa bile ağ geçidini politika karar noktası haline getirmektir. Örneğin, bir tarayıcı aracı korumalı alanda çalışan bir çalışanda yürütülebilir ve bir CRM yazma işlemi dahili bir hizmetin içinde yürütülebilir. Ağ geçidi yine de çağrıya izin verilip verilmediğini değerlendirir, kararı kaydeder, maliyeti takip eder ve imzalı bir yetkilendirme kararı veya reddi döndürür.
1. Adım: Merkezi bir araç kaydı oluşturun
Araç kaydı, "bilinmeyen aracı özelliğinin" varsayılan hale gelmesini engelleyen envanterdir. Her aracın bir sahibi, bir risk katmanı ve operasyonel meta verileri olmalıdır. Minimum kayıt defteri kaydı şu şekilde görünebilir:
<ön>MCP sunucuları için kayıt defteri ayrıca sunucu URL'sini, tanıtılan araçları, şema sürümünü, yetkilendirme yöntemini, son inceleme tarihini ve yeni araçların varsayılan olarak devre dışı bırakılıp bırakılmadığını da içermelidir. MCP birlikte çalışabilirliği artırır ancak protokol uyumluluğu üretim yetkilendirmesiyle aynı şey değildir. Hassas kaynaklar ve operasyonlar hâlâ açık kapsamlara, rota kontrollerine ve kiracı yalıtımına ihtiyaç duyuyor.
Önerilen kayıt defteri alanları
- Araç adı, standart kimlik, sahibi ve çağrı sırasında iletişim kurulacak kişi.
- Yürütme konumu: Barındırılan sağlayıcı aracı, MCP sunucusu, dahili API, tarayıcı çalışanı, kod çalıştırıcı, kuyruk işi veya yerel SDK aracı.
- İzin verilen kiracılar, ekipler, kullanıcılar, aracı sürümleri ve model profilleri.
- Veri sınıflandırması: genel, dahili, müşteri meta verileri, müşteri içeriği, sırlar, ödeme verileri, kimlik bilgileri, düzenlemeye tabi veriler.
- Risk katmanı ve geri döndürülebilirlik.
- Gerekli kapsamlar ve onay politikası.
- Zaman aşımları, ücret sınırları, çalıştırma başına maksimum çağrı, kümülatif çalıştırma bütçesi ve çağrı başına maksimum maliyet.
- Günlüğe kaydetme modu: yükün tamamı yasaktır, üzerinde değişiklik yapılır, karma işlemi uygulanır, örneklenir veya açıkça saklanır.
- Geri alma talimatları ve yükseltme yolu.
2. Adım: Model kapsamlarını araç kapsamlarından ayırın
Bir üretim ağ geçidi anahtarı arayanın neler yapabileceğini ifade etmelidir. Model erişimi ve araç erişimi bağımsız olmalıdır. Örneğin:
model:sohbet
model:gömmeler
araç:docs.search_readonly
araç:crm.create_ticket
araç:email.send_requires_approval
araç:billing.refund_blocked
araç:code.execute_blockedBu, düşük riskli bir sohbet robotunun kazara bir otomasyon aracısına dönüşmesini önler. Ayrıca rol şablonlarını da destekler:
- Geliştirici asistanı: model sohbeti, dokümantasyon arama, kod açıklaması, üretim yazma araçları yok.
- Destek botu: müşteri arama, destek bildirimi oluşturma, yanıt taslağı oluşturma, harici gönderimler için onay gerekir.
- Analist aracısı: satır sınırlamalı salt okunur veri ambarı sorguları, varsayılan olarak müşteri aktarımı yapılmaz.
- Yönetici aracısı: dar ayrıcalıklı işlemler, güçlü onay, kısa ömürlü anahtarlar, tam denetim.
- Bayi kiracı temsilcisi: kiracı kapsamlı model erişimi, kiracı kapsamlı araçlar, müşteri başına bütçe tavanları.
Öneri başarısızlıkla kapatılmadır: Bilinmeyen araçlar reddedilir, eksik kapsamlar yürütmeyi reddeder, yeni tanıtılan MCP araçları onaylanana kadar devre dışı kalır ve yerel araçlar, barındırılan araçlarla aynı politika paketleyiciyi kullanmalıdır.
3. Adım: Araçları patlama yarıçapına göre sınıflandırın
Her araç çağrısının insan onayına ihtiyacı yoktur. Yönetişim riskle orantılı olmalıdır. Yararlı bir sınıflandırma modeli şudur:
Bu sınıflandırma, kod incelemesinde ve yönetici arayüzünde görünür olmalıdır. Araç açıklamaları tek başına yeterli değildir çünkü aracılar açıklamaları talimat olarak değerlendirebilir. Politika motoru yalnızca doğal dildeki araç adlarına değil, kayıt defteri meta verilerine ve kapsamlarına da dayanmalıdır.
4. Adım: Yüksek riskli işlemler için onay kapılarını ekleyin
Onay hedeflenmelidir. Her araç çağrısı bir kişiye ihtiyaç duyarsa aracı kullanılamaz hale gelir. Hiçbir araç çağrısı onay gerektirmiyorsa sistem aşırı acentelik izni verebilir.
Ortak bir onay akışı:
- Aracı, yapılandırılmış bağımsız değişkenler içeren bir araç çağrısı ister.
- Ağ geçidi kimliği, kapsamı, risk katmanını, bütçeyi ve politikayı değerlendirir.
- Onay gerekiyorsa ağ geçidi, aracı yürütmek yerine bekleyen bir onay olayı döndürür.
- Uygulama kullanıcıya bir önizleme gösterir veya bir onay kanalına bir işlem bildirimi gönderir.
- Onaylayan, politika izin veriyorsa bağımsız değişkenleri onaylayabilir, reddedebilir, düzenleyebilir veya açıklama isteyebilir.
- Ağ geçidi kararı kaydeder ve yalnızca onaylanan sürümü yürütür.
Onay yükü, eylemi yalnızca ham JSON olarak değil, insan açısından da göstermelidir:
<ön>Onay, en çok dış iletişim, mali işlemler, geri alınamaz yazma işlemleri, ayrıcalıklı yönetim ve geniş veri aktarımları için faydalıdır. Düşük hacimli kamuya açık doküman araması için genellikle gereksizdir.
5. Adım: Araç başına bütçeleri ve ücret sınırlarını izleyin
Jeton bütçeleri yeterli değil. Ucuz bir model pahalı aramaları, tarayıcı oturumlarını, kod çalıştırmaları, üçüncü taraf API çağrılarını veya uzun araç döngülerini tetikleyebilir. Ağ geçidinin en az dört sayacı izlemesi gerekir:
- Araç başına çağrı sayısı: çalıştırma, kullanıcı, kiracı ve zaman aralığı başına maksimum çağrı.
- Araç başına maliyet: doğrudan üçüncü taraf ücretleri, tarayıcı/çalışma zamanı maliyeti, arama maliyeti veya dahili ters ibraz tahmini.
- Kümülatif aracı çalıştırma maliyeti: model jetonları artı araç maliyetleri.
- Döngü derinliği: maksimum model-araç-model yineleme sayısı.
Bir sınıra ulaşıldığında, ağ geçidinin mümkün olduğunca sessiz bir donanım arızasından kaçınması gerekir. Daha güvenli bozulma modelleri arasında ilerleme özetinin döndürülmesi, devam etmek için onay istenmesi, alma derinliğinin azaltılması, bir arka plan işinin kuyruğa alınması veya salt okunur moda geçiş yer alır. Engellenen araçlar, eksik kapsamlar, bilinmeyen MCP özellikleri ve tehlikeli eylemler için kesin reddetme hâlâ uygundur.
6. Adım: Model ve araç telemetrisini tek bir denetim kaydında birleştirin
Model günlükleri bir yerde, araç günlükleri ise başka bir yerde olduğunda, aracı hata ayıklaması başarısız olur. Denetim kaydı tüm zinciri birbirine bağlamalıdır:
- Kiracı, çalışma alanı, kullanıcı, hizmet hesabı ve ağ geçidi anahtarı.
- Ajan kimliği, aracı sürümü, bilgi istemi şablonu sürümü ve model kimliği.
- Araç adı, kayıt defteri sürümü, sunucu URL'si veya yürütme ortamı ve şema karması.
- Araç girişi karması veya düzeltilmiş giriş; varsayılan olarak hiçbir zaman ham hassas yükler.
- Onay durumu, onaylayanın kimliği, onay zaman damgası ve onaylanmış bağımsız değişken karması.
- Gecikme, yeniden denemeler, sağlayıcı hataları, araç hataları, jeton maliyeti, araç maliyeti ve nihai sonuç.
- Eylemin durumu değiştiyse geri alma referansı.
OpenAI'nin Agents SDK izleme belgeleri, LLM nesilleri, araç çağrıları, aktarımlar, korumalar ve özel olaylar için izlemeler içerir; bu da daha geniş bir gözlemlenebilirlik ilkesini destekler: aracı izlemeleri yalnızca belirteç kullanımı ve gecikmeyi değil, araç etkinliğini de içermelidir. Ancak tek bir SDK işlem hattı, barındırılan her aracı, yerel yürütme yolunu veya dahili API'yi kapsamayabilir. Ağ geçidi düzeyinde denetim, sağlayıcılar ve çerçeveler genelinde kayıtların normalleştirilmesine yardımcı olur.
Gizlilik önemlidir. Ayrıntılı günlükler, hata ayıklamayı ve uyumluluk incelemesini iyileştirir, ancak ham istem ve araç yükünün saklanması, yeni bir güvenlik yükümlülüğü oluşturabilir. Sırları, kimlik bilgilerini, ödeme verilerini, kişisel verileri veya özel belgeleri içeren girişleri düzeltin veya karma yapın. Ham verileri yalnızca açık saklama politikası, erişim denetimleri ve silme kuralları kapsamında depolayın.
7. Adım: MCP sunucularını ve üçüncü taraf araçlarını tedarik zinciri bağımlılıkları olarak değerlendirin
MCP sunucuları ve üçüncü taraf araçları, kitaplıklar, web kancaları ve altyapı bağımlılıklarıyla aynı inceleme sürecinden geçmelidir. Önerilen kontroller şunları içerir:
- Onaylı MCP sunucularının ve araç kaynaklarının izin verilenler listesini tutun.
- Mümkün olduğunda sürümleri sabitleyin ve şema karmalarını kaydedin.
- Her sunucunun ve yüksek riskli aracın bir sahibi olmasını zorunlu kılın.
- Araç adlarını, açıklamalarını, şemalarını ve izin taleplerini etkinleştirmeden önce inceleyin.
- İncelenene kadar yeni eklenen araçları devre dışı bırakın.
- Yol veya yetenek başına gerekli kapsamları doğrulayın.
- Kiracı kimlik bilgilerini ayırın ve jetonların müşteriler arasında paylaşılmasını önleyin.
- Güvenilmeyen veya yüksek riskli araçları, ağ ve dosya sistemi kısıtlamalarına sahip korumalı alanlarda çalıştırın.
Bir aracın standart bir protokol aracılığıyla kullanıma sunulması onu güvenli kılmaz. Yönetim katmanı hâlâ en az ayrıcalığa, açık yetkilendirmeye, sürüm kontrolüne ve denetlenebilirliğe ihtiyaç duyuyor.
Uygulama kontrol listesi
Politika tasarımı
- Ortak aracı kullanıcıları ve hizmet hesapları için rol şablonlarını tanımlayın.
- Model çağrıları ve araç çağrıları için ayrı kapsamlar oluşturun.
- Araçları veri duyarlılığına, geri döndürülebilirliğe, dış etkiye, finansal etkiye ve ayrıcalık düzeyine göre sınıflandırın.
- Bilinmeyen araçlar ve eksik kapsamlar için varsayılan olarak reddetme davranışını ayarlayın.
- Onay kurallarını yalnızca yüksek riskli işlemler için tanımlayın.
Ağ geçidi yaptırımı
- Her aracının, ağ geçidi veya imzalı bir politika sarmalayıcı aracılığıyla araçları aramasını zorunlu kılın.
- Yürütmeden önce kiracıyı, kullanıcıyı, anahtarı, aracıyı, modeli, aracı, kapsamı, bütçeyi ve onay durumunu kontrol edin.
- Maksimum araç çağırma derinliğini ve kümülatif çalıştırma maliyetini uygulayın.
- Her çağrı için araç kayıt defteri sürümünü ve şema karmasını kaydedin.
- Politika motoru bir karara varamadığında başarısız kapatılır.
Denetim ve operasyonlar
- Model çağrılarını ve araç çağrılarını tek bir izleme veya aracı çalıştırma kimliği altında birleştirin.
- Varsayılan olarak hassas araç girişlerini düzenleyin veya karma yapın.
- Onay kanıtlarını nihai yürütme kaydıyla birlikte saklayın.
- Araç başına maliyet ve hız sınırı analizlerini yöneticilere gösterin.
- Durumu değiştiren araçlar için belgeyi geri alma sahipleri.
Beklenecek ödünler
Tutarlılık ve entegrasyon çabası. Ağ geçidi düzeyinde yönetim, modeller, SDK'lar ve ekipler arasında tutarlı uygulama sağlar. Maliyeti benimsemedir: geliştiricilerin, araçları doğrudan uygulama kodundan çağırmak yerine, araç yürütmeyi onaylanmış yol üzerinden yönlendirmesi gerekir.
Politika karmaşıklığına karşı en az ayrıcalık. İnce taneli kapsamlar patlama yarıçapını azaltır ancak şablonlar, adlandırma kuralları ve düzenli temizlik gerektirir. Şablonlar olmadan ekipler daha hızlı ilerlemek için izinleri gereğinden fazla verebilir.
Otonomiye karşı onay. İnsanların onayı, geri dönüşü olmayan eylemlere ilişkin riski azaltır ancak gecikmeyi artırır. Onayları her arama veya arama için değil, yüksek riskli araçlar için kullanın.
Denetlenebilirlik ve veri açığa çıkması. Zengin günlükler, olaylara müdahale ve hata ayıklamaya yardımcı olur. Ham yük kaydı, sırları ve kişisel verileri açığa çıkarabilir. Düzenleme, karma oluşturma, yapılandırılabilir saklama ve erişim incelemesi isteğe bağlı ayrıntılar değildir.
Görevi tamamlamaya karşı katı sınırlar. Araç başına maliyet sınırları, aracıların kaçmasını önler. Ayrıca uzun süredir devam eden yasal çalışmaları da kesintiye uğratabilirler. Devam onayı, arka plan kuyrukları veya özetlenmiş kısmi sonuçlar gibi devam yolları sağlayın.
Tahminler: Bu model nereye gidiyor
Tahmin: Aracı yönetişimi daha kimlik merkezli hale gelecek. Takımlar daha az sıklıkla "bunda hangi model kullanıldı?" sorusunu soracaktır. ve daha sık olarak "kimliği doğrulanmış hangi kişi veya hizmet bu araç işlemine izin verdi?"
Tahmin: Araç kayıtları, model kayıtları kadar normal hale gelecek. MCP sunucuları, dahili API'ler ve barındırılan araçlar çoğaldıkça üretim ekiplerinin izin verilen yetenekler, sahipler, şemalar ve risk katmanlarından oluşan bir envantere ihtiyacı olacak.
Tahmin: Maliyet yönetimi, yalnızca belirteç raporlamasından eylem düzeyinde raporlamaya geçecektir. Bir aracı çalıştırmanın en pahalı kısmı, model çağrısı yerine alma, tarayıcı otomasyonu, kod yürütme veya üçüncü taraf API'ler olabilir.
Harekete geçirilebilir sonuç
Tek bir kuralla başlayın: Model anahtarı, araç anahtarı değildir. Daha sonra dışarıya doğru inşa edin. Onaylanmış araçlardan oluşan bir kayıt oluşturun, sahipler ve risk katmanları atayın, açık kapsamlar zorunlu kılın, yalnızca eylemin anlamlı patlama yarıçapına sahip olduğu durumlarda onaylar ekleyin, araç başına bütçeleri zorunlu kılın ve model ile araç etkinliklerini tek bir denetim takibinde birleştirin.
Amaç aracıları güçsüz bırakmak değil. Amaç, yetkilerini okunaklı, kapsamlı, mümkün olduğunda geri döndürülebilir ve hesap verebilir hale getirmektir. Temsilciler soruları yanıtlamaktan eyleme geçmeye geçerken ekip API yönetiminin pratik temeli budur.