GuardAgent: Aplicació determinista de la seguretat per a agents LLM mitjançant l'execució de codi

El problema central de seguretat per a qualsevol agent amb capacitat d'escriptura és: com pots evitar que realitzi una acció que mai se suposava que havia de realitzar? GuardAgent (Xiang et al., ICML 2025) proposa un agent de protecció dedicat — un agent LLM independent que verifica cada acció de l'agent objectiu contra un conjunt de polítiques de seguretat abans que s'executi. Per a Bean Labs, on la qüestió de "pot l'agent escriure al llibre major sense infringir les regles comptables?" és innegociable, aquest article se situa directament al centre de la nostra agenda de recerca.

L'article

GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning, de Zhen Xiang i col·legues d'UIUC, Emory i UC Berkeley, introdueix el que els autors afirmen que és el primer agent de protecció de propòsit general per a sistemes LLM. La idea central és senzilla: en lloc d'integrar les restriccions de seguretat directament en el prompt de l'agent objectiu (on poden ser ignorades o oblidades), GuardAgent funciona com un agent independent que intercepta les accions de l'agent objectiu i les verifica contra les polítiques establertes.

El mecanisme té dues etapes. Primer, l'LLM llegeix la política de seguretat i l'entrada o sortida proposada per l'agent objectiu, i després escriu un pla d'acció pas a pas que descriu què cal verificar. Segon, converteix aquest pla en codi Python executable utilitzant una caixa d'eines predefinida de funcions cridables. Un intèrpret de Python extern executa el codi, produint un veredicte determinista de sí/no. Un mòdul de memòria emmagatzema tuples de tasques passades (política, pla, codi) i recupera exemples anteriors similars utilitzant la distància de Levenshtein, permetent l'aprenentatge en el context d'uns pocs exemples (few-shot) sense cap ajust addicional. L'article avalua l'enfocament en dos nous bancs de proves introduïts pels autors.

Idees clau

• L'execució de codi supera els veredictes en llenguatge natural. Quan les decisions de seguretat s'emeten com a codi en lloc de text d'LLM, el resultat és determinista: el motor Python o bé permet o bé bloqueja, sense risc d'al·lucinació en el pas final de la decisió. L'LLM només ha de generar codi correcte, no una resposta final correcta.
• Dos bancs de proves personalitzats. EICU-AC (316 exemples) prova el control d'accés per a EHRAgent sobre una base de dades sanitària amb tres rols d'usuari i deu bases de dades. Mind2Web-SC (200 exemples) prova sis polítiques de seguretat per a l'agent web SeeAct. Ambdós van ser creats pels autors específicament per a aquest article.
• Precisió de l'etiqueta del 98,7% i el 90,0% (GPT-4) a EICU-AC i Mind2Web-SC respectivament. De manera crítica, la precisió de la resposta final — si l'agent objectiu encara completa la seva tasca quan hauria de ser permès — es manté en el 100% en ambdós escenaris.
• Les regles de seguretat codificades rígidament fallen estrepitosament. Integrar les polítiques directament en el prompt del sistema de l'agent objectiu aconsegueix només una precisió del 81,0% / 77,5% en els dos bancs de proves, i provoca que l'agent objectiu falli en el 29,2% / 71,0% de les seves tasques legítimes — un compromís utilitat-seguretat inacceptable.
• LlamaGuard no és l'eina adequada aquí. El punt de referència de moderació de contingut assoleix aproximadament un 50% de precisió — gairebé per atzar — perquè va ser dissenyat per a text nociu, no per raonar sobre si una acció d'un agent viola una regla específica de control d'accés.
• Eliminar la caixa d'eines costa uns 8 punts. Sense la biblioteca de funcions cridables, GuardAgent baixa del 98,7% al 90,8% a EICU-AC, tot i que es compensa parcialment definint de manera autònoma les funcions necessàries (el 68% de les sortides generen codi fins i tot sense instruccions explícites, cosa que els autors tracten com una evidència de suport per al disseny de generació de codi).

Què se sosté — i què no

La visió arquitectònica central — que l'execució de codi et dóna un punt d'aplicació determinista — és genuïnament útil, i les ablacions són honestes. La comparació amb les regles de seguretat codificades és particularment convincent: demostra que els dissenys ingenus de "simplement afegeix regles al prompt" degraden la utilitat de l'objectiu alhora que no aconsegueixen aplicar la seguretat de manera fiable.

Però l'avaluació té límits reals. Els dos bancs de proves són petits (316 i 200 exemples), i els autors van construir tots dos, la qual cosa crea un risc obvi de sobreajust (overfitting). L'EICU-AC és essencialment una matriu de control d'accés (rol × base de dades), que és un problema estructurat i numerable — el tipus de cosa en què el codi és naturalment bo. Mind2Web-SC és més complex, i la xifra del 90,0% allà és considerablement menys impressionant del que sembla al principi: els autors reconeixen que la regla 5 (que cobreix "pel·lícules, música i vídeos") causa la majoria dels fracassos perquè requereix un raonament ampli de món obert. Aquest és el tipus de regla a la qual s'enfrontaria constantment un agent financer real.

El mòdul de memòria recupera demostracions per similitud de cadenes de text, cosa que funciona bé per a tipus de polítiques repetides, però es degradarà amb polítiques genuïnament noves. I tot el marc assumeix un "context de confiança" — les pròpies polítiques de seguretat han de ser proporcionades per un administrador de confiança. Si un atacant pot modificar les polítiques, o si la caixa d'eines conté funcions no segures, GuardAgent no ofereix protecció. L'article no modela la manipulació adversarial de les polítiques. Treballs posteriors (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) ja han destacat aquestes llacunes, amb ShieldAgent informant d'una millora mitjana de l'11,3% respecte a GuardAgent en bancs de proves més amplis.

Per què això és important per a l'IA en finances

L'agent d'escriptura de Beancount necessita més que un prompt de seguretat — necessita un mecanisme per aplicar regles comptables que estigui estructuralment separat de l'agent que realitza la feina. L'arquitectura de GuardAgent s'ajusta directament a això: un agent de protecció que verifica cada assentament proposat contra les regles comptables (deure == haver, sense publicacions en períodes tancats, sense modificació de transaccions conciliades) abans que s'executi l'escriptura. La capa d'aplicació mitjançant l'execució de codi és especialment atractiva aquí perquè l'aritmètica de partida doble és exactament el tipus de verificació estructurada i numerable que el codi gestiona de manera fiable i el text de l'LLM no.

La limitació honesta és que GuardAgent assumeix que pots enumerar les teves polítiques de seguretat per endavant i codificar-les en una caixa d'eines. En els desplegaments de producció de Beancount, algunes restriccions són implícites (seguint les convencions del llibre que l'usuari ha construït durant anys) i algunes són dinàmiques (els pressupostos canvien, les estructures de comptes es reestructuren). GuardAgent no t'explica com gestionar restriccions que no es poden especificar prèviament. Aquest és el problema més difícil, i segueix obert.

Què llegir a continuació

• ShieldAgent (arXiv:2503.22738, ICML 2025) — es basa en GuardAgent amb un raonament de polítiques de seguretat verificable i ShieldAgent-Bench (2.000 exemples en sis entorns web); informa d'una millora de l'11,3% respecte a GuardAgent i una reducció del 64,7% en les crides a l'API.
• AGrail (arXiv:2502.11448) — proposa verificacions de seguretat adaptatives que es transfereixen entre les tasques de l'agent en lloc de requerir demostracions per tasca; aborda directament la limitació d'escalabilitat de GuardAgent.
• ToolSafe (arXiv:2601.10156) — baranes de seguretat proactives a nivell de pas amb retroalimentació per a agents que criden eines; més granular que el model d'intercepció d'entrada/sortida de GuardAgent.