Govern de l'eina d'agent mitjançant una passarel·la d'API AI: àmbits, aprovacions, pressupostos i pistes d'auditoria

El risc de l'agent ja no es limita a la sol·licitud del model. Un agent de producció pot cercar fitxers interns, consultar registres de clients, trucar a un servidor MCP, executar codi, obrir un navegador, enviar correu electrònic, actualitzar un CRM o activar un flux de treball de facturació. La pregunta de govern és: quin usuari, clau, model, agent i eina es va permetre fer quina acció, amb quin pressupost, pista d'auditoria i camí de retrocés?

Si cada equip gestiona l'accés a les eines dins del seu propi codi SDK, la política s'escampa entre les variables d'entorn, els taulers de control de proveïdors, el programari intermedi d'aplicacions i els servidors MCP no documentats. Un patró més segur és tractar l'execució de l'eina de l'agent com un problema del pla de control i fer-lo complir mitjançant una passarel·la API d'IA o un embolcall estàndard d'execució d'eines que tots els agents han d'utilitzar.

Aquest article separa fets, recomanacions i prediccions. Els fets s'extreuen de l'orientació pública actual: el Top 10 de l'aplicació LLM d'OWASP inclou riscos com la divulgació d'informació sensible, les vulnerabilitats de la cadena de subministrament i l'excés d'agència; El perfil d'IA generativa del NIST per al marc de gestió de riscos d'IA posa èmfasi en el mapeig, el mesurament i la gestió dels riscos generatius d'IA; La guia d'agents d'OpenAI recomana avaluar el risc de l'eina mitjançant l'accés de lectura/escriptura, la reversibilitat, els permisos i l'impacte financer; i la guia d'autorització MCP utilitza conceptes d'autorització d'abast per a recursos i operacions sensibles. Les recomanacions següents són patrons d'implementació, no requisits universals.

El problema del lector: l'accés al model i l'accés a les eines es confonen

En moltes aplicacions primerenques de LLM, una clau d'API va respondre a una pregunta bàsica: aquest servei pot trucar a un model? Els agents ho fan massa groller. Una clau que pugui enviar finalitzacions de xat no hauria de poder exportar automàticament les dades dels clients, executar ordres de shell, publicar a Slack, modificar entrades, navegar per llocs web arbitraris o enviar canvis de pagament.

La capa de govern ha de respondre a preguntes més específiques:

• Quin inquilí, espai de treball, usuari, compte de servei o client distribuïdor va iniciar l'execució?
• Quin model, plantilla de sol·licitud, versió de l'agent i esquema d'eina s'han utilitzat?
• L'eina sol·licitada era només de lectura, reversible, irreversible, externa, financera o privilegiada?
• El sol·licitant tenia l'abast requerit?
• La política d'emergència va requerir, concedir, denegar, caducar o ignorar l'aprovació?
• Què va costar l'eina, quantes vegades es va anomenar i quin pressupost acumulat quedava?
• Quines evidències hi ha per a la depuració, la revisió del compliment i la recuperació?

L'arquitectura següent suposa que la passarel·la ja rep trucades de model. Aleshores, l'execució de l'eina es pot encaminar a través de la mateixa passarel·la, a través d'un servei sidecar o a través d'una biblioteca estàndard que informa a la passarel·la abans i després de cada trucada a l'eina.

Arquitectura de referència: una capa de govern d'eines a nivell de passarel·la

Un sistema pràctic de govern d'agents té set components:

1. Registre d'eines: la llista autoritzada d'eines aprovades, servidors MCP, funcions allotjades, eines d'execució local i API internes.
2. Capa d'identitat i clau: claus de passarel·la, usuaris, inquilins, comptes de servei, equips i clients distribuïdors.
3. Motor d'abast: comprovacions de polítiques que decideixen si una clau o un usuari pot invocar una capacitat d'eina específica.
4. Classificador de riscos: metadades que descriuen el radi de l'explosió, la sensibilitat de les dades, la reversibilitat, l'impacte extern i l'exposició al cost.
5. Flux de treball d'aprovació: aprovació humana o del sistema per a accions d'alt risc abans de l'execució.
6. Llibre de límits de pressupost i tarifes: límits per eina i per agent, no només límits de testimonis per model.
7. Magatzem d'auditoria i traça: registres units per a trucades de models, trucades d'eines, aprovacions, errors i resultats.

La decisió de disseny important és fer de la passarel·la el punt de decisió de la política encara que l'eina real s'executi en un altre lloc. Per exemple, una eina de navegador pot executar-se en un treballador amb zona de sorra i una escriptura de CRM es pot executar dins d'un servei intern. La passarel·la encara avalua si la trucada està permesa, registra la decisió, fa un seguiment del cost i retorna una decisió d'autorització o una denegació signada.

Pas 1: creeu un registre d'eines central

Un registre d'eines és l'inventari que impedeix que la "capacitat de l'agent desconegut" esdevingui la predeterminada. Cada eina hauria de tenir un propietari, un nivell de risc i metadades operatives. Un registre de registre mínim pot tenir aquest aspecte:

{
  "tool_id": "crm.create_ticket",
  "display_name": "Crea un bitllet d'assistència CRM",
  "owner_team": "suport-automatització",
  "execution_type": "internal_api",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["empresa", "suport"],"allowed_models": ["general-gran", "general-ràpid"],
  "risk_tier": "escriptura_reversible",
  "data_classification": "metadades_client",
  "required_scopes": ["eina: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"
}

Per als servidors MCP, el registre també hauria d'incloure l'URL del servidor, les eines anunciades, la versió de l'esquema, el mètode d'autorització, la data de la darrera revisió i si les eines noves estan desactivades de manera predeterminada. MCP millora la interoperabilitat, però la compatibilitat del protocol no és el mateix que l'autorització de producció. Els recursos i les operacions sensibles encara necessiten àmbits explícits, comprovacions de rutes i aïllament dels inquilins.

Camps de registre recomanats

• Nom de l'eina, identificador canònic, propietari i contacte de guàrdia.
• Ubicació d'execució: eina del proveïdor allotjat, servidor MCP, API interna, treballador del navegador, ejecutor de codi, treball de cua o eina SDK local.
• Inquilins, equips, usuaris, versions d'agent i perfils de models permesos.
• Classificació de les dades: públic, intern, metadades del client, contingut del client, secrets, dades de pagament, credencials, dades regulades.
• Nivell de risc i reversibilitat.
• Àmbits i política d'aprovació necessaris.
• Temps d'espera, límits de tarifes, trucades màximes per tirada, pressupost d'execució acumulat i cost màxim per trucada.
• Mode de registre: la càrrega útil completa està prohibida, redactada, resumida, mostrada o conservada explícitament.
• Instruccions de retrocés i camí d'escalada.

Pas 2: separeu els àmbits del model dels àmbits de l'eina

Una clau de passarel·la de producció hauria d'expressar el que pot fer la persona que truca. L'accés al model i l'accés a les eines han de ser independents. Per exemple:

model:xat
model: incrustacions
tool:docs.search_readonly
tool:crm.create_ticket
tool:email.send_requires_approval
tool:billing.refund_blocked
tool:code.execute_blocked

Això evita que un chatbot de baix risc es converteixi en un agent d'automatització accidental. També admet plantilles de rol:

• Assistent de desenvolupadors: xat de models, cerca de documentació, explicació del codi, sense eines d'escriptura de producció.
• Bot d'assistència: cerca de clients, creació de bitllets, redacció de respostes, aprovació necessària per als enviaments externs.
• Agent d'analista: consultes de magatzem de dades només de lectura amb límits de files, sense exportacions de clients per defecte.
• Agent d'administració: operacions amb privilegis restringits, aprovació forta, claus de curta durada, auditoria completa.
• Agent d'inquilí del distribuïdor: accés al model d'abast de l'inquilí, eines d'abast de l'inquilí, límits pressupostaris per client.

La recomanació és que no es tanqui: les eines desconegudes es deneguen, els àmbits que falten deneguen l'execució, les eines MCP recentment anunciades estan inactives fins que s'aprovin i les eines locals han d'utilitzar el mateix embolcall de polítiques que les eines allotjades.

Pas 3: classifica les eines per radi d'explosió

No totes les trucades d'eines necessiten l'aprovació humana. El govern ha de ser proporcional al risc. Un model de classificació útil és:

Aquesta classificació hauria de ser visible a la revisió del codi i a la interfície d'usuari d'administració. Les descripcions d'eines per si soles no són suficients perquè els agents poden tractar les descripcions com a instruccions. El motor de polítiques hauria de basar-se en metadades i àmbits del registre, no només en noms d'eines en llenguatge natural.

Pas 4: afegiu portes d'aprovació per a accions d'alt risc

L'aprovació s'ha d'orientar. Si cada trucada d'eina requereix una persona, l'agent es torna inutilitzable. Si cap trucada d'eina requereix aprovació, el sistema pot concedir una agència excessiva.

Un flux d'aprovació comú:

1. L'agent sol·licita una crida a l'eina amb arguments estructurats.
2. La passarel·la avalua la identitat, l'abast, el nivell de risc, el pressupost i la política.
3. Si cal l'aprovació, la passarel·la retorna un esdeveniment d'aprovació pendent en lloc d'executar l'eina.
4. L'aplicació mostra una vista prèvia a l'usuari o envia una notificació d'operacions a un canal d'aprovació.
5. L'aprovador pot aprovar, denegar, editar arguments si la política ho permet o sol·licitar aclariments.
6. La passarel·la registra la decisió i executa només la versió aprovada.

La càrrega útil d'aprovació hauria de mostrar l'acció en termes humans, no només JSON en brut:

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "usuari_789",
  "tool_id": "email.send",
  "risk_tier": "comunicació_externa",
  "summary": "Envia una resposta a [email protected] sobre el bitllet #4812",
  "redacted_arguments": {
    "a": "[email protected]",
    "subject": "Actualització del bitllet #4812",
    "body_hash": "sha256:..."
  },
  "expires_at": "2026-08-09T12:30:00Z"
}

L'aprovació és molt útil per a la comunicació externa, les accions financeres, les escriptures irreversibles, l'administració privilegiada i les exportacions de dades àmplies. Normalment no és necessari per a la cerca de documentació pública de baix volum.

Pas 5: feu un seguiment dels pressupostos per eina i dels límits de tarifes

Els pressupostos de testimoni no són suficients. Un model barat pot desencadenar cerques cares, sessions de navegador, execucions de codi, trucades d'API de tercers o bucles d'eines llargs. La passarel·la hauria de fer un seguiment d'almenys quatre comptadors:

• Recompte de trucades per eina: màxim de trucades per execució, usuari, inquilí i període de temps.
• Cost per eina: càrrecs directes de tercers, cost del navegador/temps d'execució, cost de cerca o estimació interna de devolució.
• Cost acumulat d'execució de l'agent: fitxes de model més costos d'eines.
• Profunditat del bucle: nombre màxim d'iteracions model-eina-model.

Quan s'arriba a un límit, la passarel·la hauria d'evitar un error dur silenciós quan sigui possible. Els patrons de degradació més segurs inclouen retornar un resum del progrés, demanar aprovació per continuar, reduir la profunditat de recuperació, posar a la cua una tasca en segon pla o canviar a un mode de només lectura. La denegació contundent encara és adequada per a eines bloquejades, àmbits que falten, capacitats MCP desconegudes i accions perilloses.

Pas 6: uneix la telemetria del model i de l'eina en un sol registre d'auditoria

La depuració de l'agent falla quan els registres del model es troben en un lloc i els registres d'eines en un altre lloc. El registre d'auditoria hauria de connectar tota la cadena:

• Inquilí, espai de treball, usuari, compte de servei i clau de passarel·la.
• Identificador de l'agent, versió de l'agent, versió de la plantilla de sol·licitud i identificador del model.
• Nom de l'eina, versió del registre, URL del servidor o entorn d'execució i hash d'esquema.
• Hash d'entrada d'eina o entrada redactada, mai càrregues útils sensibles en brut per defecte.
• Estat d'aprovació, identitat de l'aprovador, marca de temps d'aprovació i hash d'argument aprovat.
• Latència, reintents, errors del proveïdor, errors de l'eina, cost del testimoni, cost de l'eina i resultat final.
• Referència de retrocés, si l'acció ha canviat d'estat.

La documentació de seguiment de l'SDK d'Agents d'OpenAI inclou rastres per a generacions de LLM, trucades d'eines, lliuraments, baranes i esdeveniments personalitzats, que admet un principi d'observabilitat més ampli: els rastres d'agents haurien d'incloure l'activitat de l'eina, no només l'ús de testimonis i la latència. Tanmateix, és possible que un sol canal d'SDK no cobreixi totes les eines allotjades, les rutes d'execució local o les API internes. L'auditoria a nivell de passarel·la ajuda a normalitzar els registres entre proveïdors i marcs.

La privadesa és important. Els registres detallats milloren la depuració i la revisió del compliment, però la retenció de la càrrega útil de l'eina i l'avís en brut poden crear una nova responsabilitat de seguretat. Redacte o hash entrades que continguin secrets, credencials, dades de pagament, dades personals o documents propietaris. Emmagatzemeu les càrregues útils en brut només sota una política de retenció explícita, controls d'accés i regles de supressió.

Pas 7: tracteu els servidors MCP i les eines de tercers com a dependències de la cadena de subministrament

Els servidors MCP i les eines de tercers haurien de passar pel mateix procés de revisió que les biblioteques, els webhooks i les dependències d'infraestructura. Els controls recomanats inclouen:

• Manteniu una llista permesa de servidors MCP aprovats i orígens d'eines.
• Fija les versions quan sigui possible i enregistreu els hash d'esquema.
• Requereix un propietari per a cada servidor i eina d'alt risc.
• Reviseu els noms d'eines, les descripcions, els esquemes i les reclamacions de permisos abans d'activar-los.
• Desactiva les eines afegides fins que no es revisin.
• Verifiqueu els àmbits necessaris per ruta o capacitat.
• Separeu les credencials de l'inquilí i eviteu els testimonis compartits entre els clients.
• Executeu eines no fiables o d'alt risc en caixes de proves amb restriccions de xarxa i de sistemes de fitxers.

El fet que una eina estigui exposada mitjançant un protocol estàndard no la fa segura. La capa de govern encara necessita menys privilegis, autorització explícita, control de versions i auditabilitat.

Llista de verificació d'implementació

Disseny de polítiques

• Definiu plantilles de rol per als usuaris d'agents comuns i comptes de servei.
• Creeu àmbits separats per a les trucades de models i les d'eines.
• Classifica les eines per sensibilitat de les dades, reversibilitat, impacte extern, impacte financer i nivell de privilegis.
• Estableix el comportament de denegació per defecte per a eines desconegudes i àmbits que falten.
• Definiu regles d'aprovació només per a accions d'alt risc.

Aplicació de la passarel·la

• Exigir que tots els agents cridin a les eines mitjançant la passarel·la o un embolcall de polítiques signats.
• Comproveu l'inquilí, l'usuari, la clau, l'agent, el model, l'eina, l'abast, el pressupost i l'estat d'aprovació abans de l'execució.
• Aplica la profunditat màxima de la trucada d'eines i el cost d'execució acumulat.
• Enregistreu la versió del registre de l'eina i l'esquema hash per a cada trucada.
• Error tancat quan el motor de polítiques no pot prendre una decisió.

Auditoria i operacions

• Uniu les trucades de models i les trucades d'eines amb un identificador d'execució de traça o agent.
• Per defecte, redacteu les entrades d'eines sensibles al hash.
• Conserveu les proves d'aprovació amb el registre d'execució final.
• Exposa als administradors els costos per eina i les anàlisis dels límits de velocitat.
• Propietaris de la recuperació de documents per a eines que modifiquen l'estat.

Intercanvis esperables

Coherència versus esforç d'integració. El govern a nivell de passarel·la ofereix una aplicació coherent entre models, SDK i equips. El cost és l'adopció: els desenvolupadors han d'encaminar l'execució de l'eina a través del camí aprovat en lloc de trucar a les eines directament des del codi de l'aplicació.

Privilegis mínims enfront de la complexitat de les polítiques. Els àmbits detallats redueixen el radi de l'explosió, però requereixen plantilles, convencions de denominació i neteja regular. Sense plantilles, els equips poden concedir en excés els permisos per moure's més ràpidament.

Aprovació versus autonomia. L'aprovació humana redueix el risc d'accions irreversibles, però afegeix latència. Utilitzeu aprovacions per a eines d'alt risc, no totes les cerques o cerques.

Auditabilitat versus exposició de dades. Els registres rics ajuden amb la resposta a incidents i la depuració. El registre de càrrega útil en brut pot exposar secrets i dades personals. La redacció, el resum, la retenció configurable i la revisió d'accés no són detalls opcionals.

Límits durs en comparació amb la realització de tasques. Els límits de cost per eina impedeixen els agents fugitius. També poden interrompre el treball legítim de llarga durada. Proporcioneu camins de continuació, com ara l'aprovació per continuar, les cues de fons o els resultats parcials resumits.

Prediccions: cap a on es dirigeix aquest patró

Predicció: el govern de l'agent es centrarà més en la identitat. Els equips preguntaran amb menys freqüència "quin model va utilitzar això?" i més sovint "quina persona o servei autenticat va permetre l'acció d'aquesta eina?"

Predicció: els registres d'eines seran tan normals com els registres de models. A mesura que es multipliquen els servidors MCP, les API internes i les eines allotjades, els equips de producció necessitaran un inventari de capacitats, propietaris, esquemes i nivells de risc permesos.

Predicció: la governança de costos passarà dels informes només de testimoni als informes a nivell d'acció. La part més cara de l'execució d'un agent pot ser la recuperació, l'automatització del navegador, l'execució de codi o les API de tercers en lloc de la pròpia trucada del model.

Conclusió accionable

Comenceu amb una regla: una clau de model no és una clau d'eina. A continuació, construïu cap a l'exterior. Creeu un registre d'eines aprovades, assigneu propietaris i nivells de risc, requeriu àmbits explícits, afegiu aprovacions només quan l'acció tingui un radi d'explosió significatiu, feu complir els pressupostos per eina i uniu els esdeveniments del model i de l'eina en una pista d'auditoria.

L'objectiu no és deixar els agents impotents. L'objectiu és fer que el seu poder sigui llegible, abast, reversible quan sigui possible i responsable. Aquesta és la base pràctica per al govern de l'API d'equip a mesura que els agents passen de respondre preguntes a prendre accions.

Lectura relacionada

• aïllament-resposta-4/">teu de rotació d'equips
href="https://model-gate.com/ca/blog/llm-observability-multi-model-api-gateway-traces-token-ledgers-safe-prompt-logging-9/">traces unides, registres de testimonis i registre d'indicadors segur
• sortides estructurades i patrons de validació de trucades d'eines