Yapay Zeka API Ağ Geçidi Aracılığıyla Aracı Aracı Yönetişimi: Kapsamlar, Onaylar, Bütçeler ve Denetim Yolları

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, kodu ç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çinde 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 onu 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'ın aracı kılavuzu, araç riskinin okuma/yazma erişimi, geri döndürülebilirlik, izinler ve mali etkiye göre 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 başvurularının çoğunda, API tuşu bir temel soruyu yanıtlıyordu: 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'e gönderi gönderememeli, 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 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:

1. Araç kaydı: onaylı araçların, MCP sunucuların, barındırılan işlevlerin, yerel yürütme araçlarının ve dahili API'lerin yetkili listesi.
2. Kimlik ve anahtar katmanı: ağ geçidi anahtarları, kullanıcılar, kiracılar, hizmet hesapları, ekipler ve bayi müşterileri.
3. Scope Engine: Bir anahtarın veya kullanıcının belirli bir araç özelliğini çağırıp çağıramayacağına karar veren politika kontrolleri.
4. Risk sınıflandırıcı: patlama yarıçapını, veri hassasiyetini, tersine çevrilebilirliği, dış etkiyi ve maruz kalma maliyetini açıklayan meta veriler.
5. Onay iş akışı: yüksek riskli işlemler için yürütme öncesinde insan veya sistem onayı.
6. Bütçe ve ücret 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.
7. 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ı, gerçek 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 aramaya izin verilip verilmediğini değerlendirir, kararı kaydeder, maliyeti izler 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:

{
  "tool_id": "crm.create_ticket",
  "display_name": "Create CRM support ticket",
  "owner_team": "support-automation",
  "execution_type": "internal_api",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["enterprise", "support"],
  "allowed_models": ["general-large", "general-fast"],
  "risk_tier": "reversible_write",
  "data_classification": "customer_metadata",
  "required_scopes": ["tool:crm.create_ticket"],
  "approval_policy": "not_required_under_100_tickets_per_day",
  "default_timeout_ms": 8000,
  "max_cost_per_call_usd": 0.05,
  "max_calls_per_run": 3,
  "rollback_owner": "support-ops-oncall",
  "retention_policy": "redacted_30_days"
}

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 işlemler hâlâ açık kapsamlara, rota kontrollerine ve kiracı izolasyonuna 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: tüm yükün yasaklanması, düzenlenmesi, karma hale getirilmesi, örneklenmesi veya açıkça saklanması.
• Geri alma talimatları ve üst kademeye iletme 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:chat
model:embeddings
tool:docs.search_readonly
tool:crm.create_ticket
tool:email.send_requires_approval
tool:billing.refund_blocked
tool:code.execute_blocked

Bu, düşük riskli bir sohbet robotunun kazara 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ğı hazırlama, 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ı.

Önerinin başarısız olarak kapatılmasıdı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:

Bu sınıflandırma, kod incelemesinde ve yönetici arayüzünde görünmelidir. 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ışı:

1. Aracı, yapılandırılmış bağımsız değişkenler içeren bir araç çağrısı ister.
2. Ağ geçidi; kimliği, kapsamı, risk katmanını, bütçeyi ve politikayı değerlendirir.
3. Onay gerekiyorsa ağ geçidi, aracı çalıştırmak yerine bekleyen bir onay etkinliği döndürür.
4. Uygulama kullanıcıya bir önizleme gösterir veya onay kanalına bir işlem bildirimi gönderir.
5. Onaylayan, politika izin veriyorsa bağımsız değişkenleri onaylayabilir, reddedebilir, düzenleyebilir veya açıklama isteyebilir.
6. Ağ geçidi kararı kaydeder ve yalnızca onaylanan sürümü yürütür.

Onay yükü, eylemi yalnızca ham terimlerle değil, insan açısından da göstermelidir JSON:

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "user_789",
  "tool_id": "email.send",
  "risk_tier": "external_communication",
  "summary": "Send a reply to customer@example.com about ticket #4812",
  "redacted_arguments": {
    "to": "customer@example.com",
    "subject": "Update on ticket #4812",
    "body_hash": "sha256:..."
  },
  "expires_at": "2026-08-09T12:30:00Z"
}

Onay en çok harici iletişim, mali işlemler, geri alınamayan yazma işlemleri, ayrıcalıklı yönetim ve geniş veri aktarımları için faydalıdır. Düşük hacimli genel 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çidi en az dört sayacı izlemelidir:

• 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çidi mümkün olduğunca sessiz bir donanım arızasından kaçınmalıdır. 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 tek 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 sürümü 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'in Agent SDK izleme belgeleri, LLM nesilleri, araç çağrıları, aktarmalar, korumalar ve özel olaylar için izlemeler içerir; bu, 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 ardışık düzeni, barındırılan her aracı, yerel yürütme yolunu veya dahili API'i 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 sunucuyu 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 sunucu ve araç kaynaklarının izin verilenler listesini tutun.
• Mümkün olan yerlerde sürümleri sabitleyin ve şema karmalarını kaydedin.
• Her sunucu ve yüksek riskli araç için bir sahip 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 temsilcinin 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 işlemler

• 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ı son 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ştiriciler, araçları doğrudan uygulama kodundan çağırmak yerine, araç yürütmeyi onaylanmış yol üzerinden yönlendirmelidir.

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 gerektirirler. Şablonlar olmadan ekipler daha hızlı ilerlemek için izinleri gereğinden fazla verebilir.

Onay, özerkliğe karşı. İnsan 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 etme ve hata ayıklama konusunda yardımcı olur. Ham yük günlüğü, 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 doğru gidiyor

Tahmin: Aracı yönetimi daha kimlik merkezli hale gelecek. Takımlar daha az sıklıkla "Bu hangi modeli kullandı?" sorusunu soracaktır. ve daha sıklıkla "kimliği doğrulanmış hangi kişi veya hizmet bu aracın 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 jeton 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 defteri 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ç olaylarını 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.

İlgili okumalar

• ekip API temel izolasyon ve rotasyon uygulamaları
• birleştirilmiş izler, jeton defterleri ve güvenli istem logging
• yapılandırılmış çıktılar ve araç çağrısı doğrulama modelleri