Guvernarea instrumentului agent printr-un gateway AI API: domenii, aprobări, bugete și piste de audit

Riscul agentului nu se mai limitează la solicitarea modelului. Un agent de producție poate căuta fișiere interne, interoga înregistrările clienților, poate apela un server MCP, poate executa cod, deschide un browser, trimite e-mail, actualiza un CRM sau declanșează un flux de lucru de facturare. Întrebarea de guvernare devine: care utilizator, cheie, model, agent și instrument i-a fost permis să întreprindă ce acțiune, cu ce buget, cu ce pistă de audit și cu ce cale de derulare?

Dacă fiecare echipă gestionează accesul la instrumente în cadrul propriului cod SDK, politica devine împrăștiată în variabilele de mediu, tablourile de bord ale furnizorilor, middleware-ul aplicațiilor și serverele MCP nedocumentate. Un model mai sigur este tratarea execuției instrumentului agent ca pe o problemă a planului de control și aplicarea acesteia printr-un gateway AI API sau un wrapper standard de execuție a instrumentului pe care fiecare agent trebuie să-l folosească.

Acest articol separă fapte, recomandări și predicții. Faptele sunt extrase din îndrumările publice actuale: Top 10 al aplicației LLM de la OWASP include riscuri precum divulgarea de informații sensibile, vulnerabilitățile lanțului de aprovizionare și agenție excesivă; Profilul AI generativ al NIST pentru cadrul de management al riscului AI pune accent pe cartografierea, măsurarea și gestionarea riscurilor AI generative; Îndrumarea agenților OpenAI recomandă evaluarea riscului instrumentului prin acces de citire/scriere, reversibilitate, permisiuni și impact financiar; iar ghidul de autorizare MCP utilizează concepte de autorizare definite pentru resurse și operațiuni sensibile. Recomandările de mai jos sunt modele de implementare, nu cerințe universale.

Problema cititorului: accesul la model și accesul la instrument sunt confundate

În multe aplicații LLM timpurii, o cheie API a răspuns la o întrebare de bază: poate acest serviciu să apeleze un model? Agenții fac asta prea grosier. O cheie care poate trimite completări de chat nu ar trebui să poată exporta automat datele clienților, să ruleze comenzi shell, să posteze pe Slack, să modifice bilete, să răsfoiască site-uri web arbitrare sau să trimită modificări de plată.

Stratul de guvernare trebuie să răspundă la întrebări mai specifice:

• Ce locatar, spațiu de lucru, utilizator, cont de serviciu sau client reseller a inițiat rularea?
• Ce model, șablon prompt, versiune de agent și schemă de instrumente au fost folosite?
• Instrumentul solicitat a fost doar în citire, reversibil, ireversibil, orientat spre exterior, financiar sau privilegiat?
• Solicitantul a avut domeniul necesar?
• A fost solicitată, acordată, refuzată, expirată sau ignorată aprobarea de către politica de urgență?
• Cât a costat instrumentul, de câte ori a fost numit și ce buget cumulat a rămas?
• Ce dovezi există pentru remedierea erorilor, examinarea conformității și derularea înapoi?

Arhitectura de mai jos presupune că gateway-ul primește deja apeluri model. Execuția uneltelor poate fi apoi direcționată prin același gateway, printr-un serviciu sidecar sau printr-o bibliotecă standard care raportează către gateway înainte și după fiecare apel de instrument.

Arhitectură de referință: un strat de guvernare a instrumentului la nivel de gateway

Un sistem practic de guvernare a agenților are șapte componente:

1. Registrul de instrumente: lista autorizată de instrumente aprobate, servere MCP, funcții găzduite, instrumente de execuție locale și API-uri interne.
2. Identitate și strat de cheie: chei de gateway, utilizatori, chiriași, conturi de servicii, echipe și clienți reseller.
3. Motor de acțiune: verificări ale politicii care decid dacă o cheie sau un utilizator poate invoca o anumită capacitate a instrumentului.
4. Clasificator de risc: metadate care descriu raza exploziei, sensibilitatea datelor, reversibilitatea, impactul extern și expunerea la costuri.
5. Flux de lucru de aprobare: aprobarea umană sau a sistemului pentru acțiuni cu risc ridicat înainte de execuție.
6. Registrul contabil al bugetului și al limitelor de rată: limitele per instrument și per agent, nu doar limitele de simboluri pentru fiecare model.
7. Magazin de auditare și urmărire: înregistrările asociate pentru apeluri de model, apeluri de instrumente, aprobări, erori și rezultate.

Decizia importantă de proiectare este de a face din gateway punctul de decizie politică, chiar dacă instrumentul real rulează în altă parte. De exemplu, un instrument de browser se poate executa într-un lucrător cu nisip, iar o scriere CRM se poate executa într-un serviciu intern. Gateway-ul evaluează în continuare dacă apelul este permis, înregistrează decizia, urmărește costul și returnează o decizie de autorizare sau o refuz semnată.

Pasul 1: creați un registru central de instrumente

Un registru de instrumente este inventarul care împiedică „capacitatea agentului necunoscut” să devină implicită. Fiecare instrument ar trebui să aibă un proprietar, un nivel de risc și metadate operaționale. O înregistrare minimă de registry poate arăta astfel:

{
  "tool_id": "crm.create_ticket",
  "display_name": "Creați biletul de asistență CRM",
  "owner_team": "suport-automatizare",
  "execution_type": "internal_api",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["întreprindere", "asistență"],"allowed_models": ["general-mare", "general-rapid"],
  "risk_tier": "scriere_reversibilă",
  "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": "suport-ops-oncall",
  "retention_policy": "redacted_30_days"
}

Pentru serverele MCP, registrul ar trebui să includă, de asemenea, adresa URL a serverului, instrumentele promovate, versiunea schemei, metoda de autorizare, data ultimei revizuiri și dacă instrumentele noi sunt dezactivate în mod prestabilit. MCP îmbunătățește interoperabilitatea, dar compatibilitatea protocolului nu este aceeași cu autorizarea de producție. Resursele și operațiunile sensibile au nevoie în continuare de domenii explicite, verificări ale rutei și izolarea chiriașilor.

Câmpuri de registru recomandate

• Numele instrumentului, ID-ul canonic, proprietarul și persoana de contact de gardă.
• Locația de execuție: instrumentul furnizorului găzduit, serverul MCP, API-ul intern, browser worker, runner de cod, sarcină de coadă sau instrument SDK local.
• Chiriași, echipe, utilizatori, versiuni de agenți și profiluri de model permise.
• Clasificarea datelor: publice, interne, metadatele clienților, conținutul clienților, secrete, date de plată, acreditări, date reglementate.
• Nivel de risc și reversibilitate.
• Domeniile și politica de aprobare obligatorii.
• Timp de expirare, limitele ratei, apelurile maxime pe rulare, bugetul de rulare cumulat și costul maxim pe apel.
• Modul de înregistrare: sarcină utilă completă interzisă, redactată, analizată, eșantionată sau reținută în mod explicit.
• Instrucțiuni de retragere și cale de escaladare.

Pasul 2: Separați domeniile modelului de domeniile instrumentului

O cheie gateway de producție ar trebui să exprime ceea ce poate face apelantul. Accesul la model și accesul la instrumente ar trebui să fie independente. De exemplu:

model:chat
model: înglobare
instrument:docs.search_readonly
instrument:crm.create_ticket
instrument:email.send_requires_approval
instrument:billing.refund_blocked
instrument:code.execute_blocked

Acest lucru împiedică un chatbot cu risc scăzut să devină un agent de automatizare accidental. De asemenea, acceptă șabloanele de rol:

• Asistent pentru dezvoltatori: model de chat, căutare de documentație, explicație de cod, fără instrumente de scriere de producție.
• Bot de asistență: căutarea clienților, crearea de bilete, redactarea răspunsurilor, aprobarea necesară pentru trimiterile externe.
• Agent analist: interogări de depozit de date numai în citire cu limite de rânduri, fără exporturi de clienți în mod prestabilit.
• Agent de administrare: operațiuni cu privilegii restrânse, aprobare puternică, chei de scurtă durată, audit complet.
• Agent chiriaș revânzător: acces la model în funcție de chiriaș, instrumente stabilite de chiriaș, plafoane bugetare pentru fiecare client.

Recomandarea este să nu se închidă: instrumentele necunoscute sunt refuzate, domeniile lipsă împiedică execuția, instrumentele MCP recent promovate sunt inactive până la aprobare, iar instrumentele locale trebuie să utilizeze același pachet de politici ca instrumentele găzduite.

Pasul 3: Clasificați instrumentele în funcție de raza de explozie

Nu orice apel de instrument are nevoie de aprobare umană. Guvernarea ar trebui să fie proporțională cu riscul. Un model de clasificare util este:

Această clasificare ar trebui să fie vizibilă în examinarea codului și în interfața de utilizare a administratorului. Descrierile instrumentelor nu sunt suficiente, deoarece agenții pot trata descrierile ca instrucțiuni. Motorul de politici ar trebui să se bazeze pe metadatele și domeniile de registru, nu numai pe nume de instrumente în limbaj natural.

Pasul 4: adăugați porți de aprobare pentru acțiuni cu risc ridicat

Aprobarea ar trebui să fie vizată. Dacă fiecare apel de instrument necesită o persoană, agentul devine inutilizabil. Dacă niciun apel de instrument nu necesită aprobare, sistemul poate acorda o agenție excesivă.

Un flux comun de aprobare:

1. Agentul solicită un apel de instrument cu argumente structurate.
2. Poarta de acces evaluează identitatea, domeniul de aplicare, nivelul de risc, bugetul și politica.
3. Dacă este necesară aprobarea, gateway-ul returnează un eveniment de aprobare în așteptare în loc să execute instrumentul.
4. Aplicația arată utilizatorului o previzualizare sau trimite o notificare operațională către un canal de aprobare.
5. Aprobatorul poate aproba, respinge, edita argumente dacă politica o permite sau poate solicita clarificări.
6. Gateway-ul înregistrează decizia și execută numai versiunea aprobată.

Sarca utilă de aprobare ar trebui să arate acțiunea în termeni umani, nu doar JSON brut:

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "user_789",
  "tool_id": "email.send",
  "risk_tier": "comunicare_externa",
  "summary": "Trimiteți un răspuns la [email protected] despre biletul #4812",
  „redacted_arguments”: {
    „către”: „[email protected]”,
    "subject": "Actualizare pentru biletul #4812",
    "body_hash": "sha256:..."
  },
  "expires_at": "2026-08-09T12:30:00Z"
}

Aprobarea este cea mai utilă pentru comunicare externă, acțiuni financiare, scrieri ireversibile, administrare privilegiată și exporturi ample de date. De obicei, nu este necesar pentru căutarea de documentație publică cu volum redus.

Pasul 5: Urmăriți bugetele pentru fiecare instrument și limitele ratelor

Bugetele indicative nu sunt suficiente. Un model ieftin poate declanșa căutări costisitoare, sesiuni de browser, rulări de cod, apeluri API terță parte sau bucle lungi de instrumente. Gateway-ul ar trebui să urmărească cel puțin patru contoare:

• Număr de apeluri pentru fiecare instrument: apeluri maxime pe rulare, utilizator, chiriaș și fereastră de timp.
• Cost per instrument: taxe directe de la terți, costul browser/execuție, costul căutării sau estimarea rambursării interne.
• Costul cumulat de rulare a agentului: jetoane de model plus costurile instrumentului.
• Adâncimea buclei: numărul maxim de iterații model-instrument-model.

Când este atinsă o limită, gateway-ul ar trebui să evite o eroare tare silențioasă atunci când este posibil. Tiparele de degradare mai sigure includ returnarea unui rezumat al progresului, solicitarea aprobării pentru a continua, scăderea adâncimii de recuperare, punerea în coadă a unei lucrări de fundal sau trecerea la un mod numai citire. Negarea puternică este în continuare adecvată pentru instrumentele blocate, domenii lipsă, capabilități MCP necunoscute și acțiuni periculoase.

Pasul 6: Uniți telemetria modelului și a instrumentului într-o singură înregistrare de audit

Depanarea agentului eșuează atunci când jurnalele modelului se află într-un singur loc, iar jurnalele instrumentelor se află în altă parte. Înregistrarea de audit ar trebui să conecteze întregul lanț:

• Chiriaș, spațiu de lucru, utilizator, cont de serviciu și cheie de gateway.
• ID agent, versiune agent, versiune șablon prompt și ID model.
• Numele instrumentului, versiunea de registru, adresa URL a serverului sau mediul de execuție și hash de schemă.
• Introducerea instrumentului hash sau redactată, niciodată încărcături utile sensibile brute în mod prestabilit.
• Starea aprobării, identitatea aprobatorului, marcajul de timp al aprobării și hashul argumentului aprobat.
• Latența, reîncercări, erori ale furnizorului, erori ale instrumentului, costul simbolului, costul instrumentului și rezultatul final.
• Referință de restituire, dacă starea acțiunii și-a schimbat.

Documentația de urmărire a SDK-ului pentru agenți OpenAI include urme pentru generații LLM, apeluri de instrumente, transferuri, bare de protecție și evenimente personalizate, care acceptă un principiu mai larg de observabilitate: urmele agenților ar trebui să includă activitatea instrumentului, nu numai utilizarea simbolurilor și latența. Cu toate acestea, este posibil ca o singură conductă SDK să nu acopere fiecare instrument găzduit, calea de execuție locală sau API-ul intern. Auditul la nivel de gateway ajută la normalizarea înregistrărilor între furnizori și cadre.

Confidențialitatea contează. Jurnalele detaliate îmbunătățesc depanarea și verificarea conformității, dar promptul brut și păstrarea sarcinii utile a instrumentului pot crea o nouă răspundere de securitate. Redact sau hash intrări care conțin secrete, acreditări, date de plată, date personale sau documente de proprietate. Stocați încărcăturile utile brute numai în conformitate cu politica explicită de păstrare, controale de acces și reguli de ștergere.

Pasul 7: tratați serverele MCP și instrumentele terță parte ca dependențe ale lanțului de aprovizionare

Serverele MCP și instrumentele terțe trebuie să treacă prin același proces de examinare ca bibliotecile, webhook-urile și dependențele de infrastructură. Comenzile recomandate includ:

• Păstrați o listă permisă a serverelor MCP aprobate și a originilor instrumentelor.
• Fixați versiunile acolo unde este posibil și înregistrați hashurile de schemă.
• Solicitați un proprietar pentru fiecare server și instrument cu risc ridicat.
• Examinați numele instrumentelor, descrierile, schemele și revendicările de permisiuni înainte de a le activa.
• Dezactivați instrumentele nou adăugate până la examinare.
• Verificați domeniile necesare pe rută sau capacitate.
• Separați datele de conectare ale chiriașului și evitați tokenurile partajate între clienți.
• Rulați instrumente care nu sunt de încredere sau cu risc ridicat în sandbox-uri cu restricții de rețea și sisteme de fișiere.

Faptul că un instrument este expus printr-un protocol standard nu îl face sigur. Nivelul de guvernare mai are nevoie de cel mai mic privilegiu, autorizare explicită, control al versiunilor și auditabilitate.

Lista de verificare a implementării

Designul politicii

• Definiți șabloanele de rol pentru utilizatorii agenți obișnuiți și pentru conturile de serviciu.
• Creați domenii separate pentru apelurile de model și apelurile de instrumente.
• Clasificați instrumentele în funcție de sensibilitatea datelor, reversibilitate, impact extern, impact financiar și nivel de privilegii.
• Setați comportamentul de respingere implicit pentru instrumentele necunoscute și domeniile lipsă.
• Definiți regulile de aprobare numai pentru acțiunile cu risc ridicat.

Aplicarea gateway

• Solicitați fiecărui agent să apeleze instrumente prin gateway sau printr-un pachet de politici semnat.
• Verificați locatarul, utilizatorul, cheia, agentul, modelul, instrumentul, domeniul de aplicare, bugetul și starea de aprobare înainte de execuție.
• Implementați adâncimea maximă a apelului de instrument și costul de rulare cumulat.
• Înregistrați versiunea de registru a instrumentului și hash-ul schemei pentru fiecare apel.
• Eșuare închisă atunci când motorul de politici nu poate ajunge la o decizie.

Audit și operațiuni

• Alăturați apelurilor de model și apelurilor de instrumente sub un singur ID de urmărire sau de rulare a agentului.
• Redactați sau introducerea instrumentelor sensibile la hash în mod prestabilit.
• Păstrați dovezile de aprobare împreună cu înregistrarea finală a execuției.
• Expuneți administratorilor costul per instrument și analiza limitelor ratei.
• Deținătorii de derulare a documentelor pentru instrumentele care modifică starea.

Compromisuri la care se așteaptă

Consecvență versus efort de integrare. Guvernarea la nivel de gateway oferă o aplicare consecventă între modele, SDK-uri și echipe. Costul este adoptarea: dezvoltatorii trebuie să direcționeze execuția instrumentului prin calea aprobată în loc să apeleze instrumentele direct din codul aplicației.

Privilegiul minim versus complexitatea politicii. Scopurile cu granulație fină reduc raza exploziei, dar necesită șabloane, convenții de denumire și curățare regulată. Fără șabloane, echipele pot supraacorda permisiunile pentru a se deplasa mai rapid.

Aprobare versus autonomie. Aprobarea umană reduce riscul pentru acțiuni ireversibile, dar adaugă latență. Folosiți aprobări pentru instrumente cu risc ridicat, nu pentru fiecare căutare sau căutare.

Auditabilitate versus expunerea datelor. Jurnalele bogate ajută la răspunsul la incident și la depanare. Înregistrarea încărcăturii brute poate expune secrete și date personale. Redactarea, hashingul, păstrarea configurabilă și examinarea accesului nu sunt detalii opționale.

Limite stricte versus finalizarea sarcinilor. Limitele de cost pentru fiecare instrument împiedică agenții evadați. De asemenea, pot întrerupe munca legitimă de lungă durată. Furnizați căi de continuare, cum ar fi aprobare pentru a continua, cozi de așteptare sau rezultate parțiale rezumate.

Predicții: încotro se îndreaptă acest model

Predicție: guvernarea agentului va deveni mai centrată pe identitate. Echipele vor întreba mai rar „ce model a folosit acest lucru?” și mai des „care persoană sau serviciu autentificat a permis această acțiune a instrumentului?”

Predicție: registrele de instrumente vor deveni la fel de normale ca registrele model. Pe măsură ce serverele MCP, API-urile interne și instrumentele găzduite se multiplică, echipele de producție vor avea nevoie de un inventar al capabilităților, proprietarilor, schemelor și nivelurilor de risc permise.

Predicție: guvernarea costurilor se va trece de la raportarea numai cu simboluri la raportarea la nivel de acțiune. Cea mai costisitoare parte a rulării unui agent poate fi regăsirea, automatizarea browserului, executarea codului sau API-urile terță parte, mai degrabă decât apelul modelului în sine.

Concluzie acționabilă

Începeți cu o singură regulă: o cheie de model nu este o cheie de instrument. Apoi construiește în exterior. Creați un registru de instrumente aprobate, atribuiți proprietari și niveluri de risc, solicitați domenii explicite, adăugați aprobări numai acolo unde acțiunea are o rază semnificativă de explozie, impuneți bugete pentru fiecare instrument și uniți evenimentele de model și instrument într-o singură pistă de audit.

Scopul nu este de a face agenții neputincioși. Scopul este de a face puterea lor lizibilă, acoperită, reversibilă acolo unde este posibil și responsabilă. Acesta este fundamentul practic pentru guvernarea API-ului echipei, pe măsură ce agenții trec de la răspunsul la întrebări la luarea de acțiuni.

Lectură similară

• echipă chei de rotație>
• href="https://model-gate.com/en/blog/llm-observability-multi-model-api-gateway-traces-token-ledgers-safe-prompt-logging-9/">urme unite, registre de jetoane și înregistrare sigură promptă
• ieșiri structurate și modele de validare a apelurilor de instrumente