Ir al contenido principal

GuardAgent: Cumplimiento de seguridad determinista para agentes de LLM mediante ejecución de código

· 7 min de lectura
Mike Thrift
Mike Thrift
Marketing Manager

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

2026-05-25-guardagent-safeguard-llm-agents-guard-agent-knowledge-enabled-reasoning

"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.

Qué leer a continuación

  • ShieldAgent (arXiv:2503.22738, ICML 2025): se basa en GuardAgent con razonamiento de políticas de seguridad verificables y ShieldAgent-Bench (2,000 ejemplos en seis entornos web); reporta una mejora del 11.3% sobre GuardAgent y una reducción del 64.7% en las llamadas a la API.
  • AGrail (arXiv:2502.11448): propone verificaciones de seguridad adaptativas que se transfieren entre tareas de agentes en lugar de requerir demostraciones por tarea; aborda directamente la limitación de escalabilidad de GuardAgent.
  • ToolSafe (arXiv:2601.10156): barandillas proactivas a nivel de paso con retroalimentación para agentes que realizan llamadas a herramientas; más granular que el modelo de interceptación de entrada/salida de GuardAgent.