GuardAgent: Cumplimiento de seguridad determinista para agentes de LLM mediante ejecución de código
El problema central de seguridad para cualquier agente con capacidad de escritura es: ¿cómo se le impide realizar una acción que nunca debió tomar? GuardAgent (Xiang et al., ICML 2025) propone un agente de salvaguarda dedicado: un agente de LLM independiente que verifica cada acción del agente objetivo contra un conjunto de políticas de seguridad antes de su ejecución. Para Bean Labs, donde la pregunta de "¿puede el agente escribir en el libro mayor sin violar las reglas contables?" es innegociable, este artículo se sitúa directamente en el centro de nuestra agenda de investigación.
El artículo
"GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning", de Zhen Xiang y colegas de UIUC, Emory y UC Berkeley, presenta lo que los autores afirman es el primer agente de salvaguarda de propósito general para sistemas LLM. La idea central es sencilla: en lugar de integrar restricciones de seguridad directamente en el prompt del agente objetivo (donde pueden ser ignoradas u olvidadas), GuardAgent funciona como un agente independiente que intercepta las acciones del agente objetivo y las verifica frente a políticas establecidas.
El mecanismo consta de dos etapas. Primero, el LLM lee la política de seguridad y la entrada o salida propuesta por el agente objetivo, y luego escribe un plan de acción paso a paso que describe qué verificar. Segundo, convierte ese plan en código Python ejecutable utilizando una caja de herramientas predefinida de funciones invocables. Un intérprete de Python externo ejecuta el código, produciendo un veredicto determinista de sí/no. Un módulo de memoria almacena tuplas de tareas pasadas (política, plan, código) y recupera ejemplos previos similares utilizando la distancia de Levenshtein, lo que permite el aprendizaje en contexto de pocos disparos (few-shot) sin necesidad de un ajuste fino adicional. El artículo evalúa el enfoque en dos nuevos puntos de referencia (benchmarks) introducidos por los autores.
Ideas clave
- La ejecución de código supera a los veredicto en lenguaje natural. Cuando las decisiones de seguridad se emiten como código en lugar de texto de LLM, el resultado es determinista: el motor de Python permite o bloquea, sin riesgo de alucinación en el paso final de la decisión. El LLM solo tiene que generar código correcto, no una respuesta final correcta.
- Dos puntos de referencia personalizados. EICU-AC (316 ejemplos) evalúa el control de acceso para EHRAgent sobre una base de datos de atención médica con tres roles de usuario y diez bases de datos. Mind2Web-SC (200 ejemplos) prueba seis políticas de seguridad para el agente web SeeAct. Ambos fueron creados por los autores específicamente para este artículo.
- Precisión de etiquetas del 98.7% y 90.0% (GPT-4) en EICU-AC y Mind2Web-SC respectivamente. Crucialmente, la precisión de la respuesta final —si el agente objetivo aún completa su tarea cuando debería permitírsele— se mantiene en el 100% en ambos entornos.
- Las reglas de seguridad codificadas rígidamente fallan estrepitosamente. Integrar políticas directamente en el prompt del sistema del agente objetivo logra solo un 81.0% / 77.5% de precisión en los dos puntos de referencia, y provoca que el agente objetivo falle en el 29.2% / 71.0% de sus tareas legítimas; un intercambio utilidad-seguridad inaceptable.
- LlamaGuard no es la herramienta adecuada aquí. El modelo de referencia de moderación de contenido logra aproximadamente un 50% de precisión —cerca del azar— porque fue diseñado para texto dañino, no para razonar sobre si la acción de un agente viola una regla específica de control de acceso.
- Eliminar la caja de herramientas cuesta unos 8 puntos. Sin la biblioteca de funciones invocables, GuardAgent cae del 98.7% al 90.8% en EICU-AC, aunque compensa parcialmente definiendo de forma autónoma las funciones necesarias (el 68% de las salidas generan código incluso sin instrucciones explícitas, lo que los autores consideran evidencia de respaldo para el diseño basado en generación de código).
Lo que se sostiene y lo que no
La visión arquitectónica central —que la ejecución de código proporciona un punto de cumplimiento determinista— es genuinamente útil, y las ablaciones son honestas. La comparación con las reglas de seguridad integradas en el prompt es particularmente convincente: demuestra que los diseños ingenuos de "simplemente añadir reglas al prompt" degradan la utilidad del objetivo mientras siguen fallando en garantizar la seguridad de manera confiable.
Sin embargo, la evaluación tiene límites reales. Los dos puntos de referencia son pequeños (316 y 200 ejemplos) y los autores construyeron ambos, lo que crea un riesgo obvio de sobreajuste. EICU-AC es esencialmente una matriz de control de acceso (rol × base de datos), que es un problema estructurado y numerable, el tipo de cosas para las que el código es naturalmente bueno. Mind2Web-SC es más desordenado, y la cifra del 90.0% allí es considerablemente menos impresionante de lo que parece a primera vista: los autores reconocen que la regla 5 (que cubre "películas, música y videos") causa la mayoría de los fallos porque requiere un razonamiento de mundo abierto muy amplio. Ese es el tipo de regla a la que un agente financiero real se enfrentaría constantemente.
El módulo de memoria recupera demostraciones por similitud de cadenas, lo que funciona bien para tipos de políticas repetitivas pero se degradará con políticas genuinamente novedosas. Además, todo el marco asume un "contexto de confianza": las propias políticas de seguridad deben ser proporcionadas por un administrador de confianza. Si un atacante puede modificar las políticas, o si la caja de herramientas contiene funciones inseguras, GuardAgent no ofrece protección. El artículo no modela la manipulación adversarial de políticas. Trabajos posteriores (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) ya han destacado estas brechas, con ShieldAgent reportando una mejora promedio del 11.3% sobre GuardAgent en puntos de referencia más amplios.
Por qué esto es importante para la IA financiera
El agente de escritura de Beancount necesita algo más que un prompt de seguridad: necesita un mecanismo para hacer cumplir las reglas contables que esté estructuralmente separado del agente que realiza el trabajo. La arquitectura de GuardAgent se ajusta directamente a esto: un agente de guardia que verifica cada asiento contable propuesto contra las reglas contables (debe == haber, no publicar en periodos cerrados, no modificar transacciones conciliadas) antes de que se ejecute la escritura. La capa de cumplimiento mediante ejecución de código es especialmente atractiva aquí porque la aritmética de partida doble es exactamente el tipo de verificación estructurada y numerable que el código maneja de manera confiable y el texto de un LLM no.
La limitación honesta es que GuardAgent asume que puedes enumerar tus políticas de seguridad de antemano y codificarlas en una caja de herramientas. En implementaciones de Beancount en producción, algunas restricciones son implícitas (siguiendo las convenciones del libro mayor que el usuario ha construido durante años) y algunas son dinámicas (los presupuestos cambian, las estructuras de cuentas se refactorizan). GuardAgent no explica cómo manejar restricciones que no pueden pre-especificarse. Ese es el problema más difícil y sigue sin resolverse.