AGrail: Pasarelas de Seguridad Adaptativas para Agentes de LLM que Aprenden a través de Tareas

He estado siguiendo de cerca la carrera armamentista de las pasarelas de seguridad (guardrails) para agentes de LLM — GuardAgent en 2024, ShieldAgent en ICML 2025 — y AGrail (Luo et al., ACL 2025) es el siguiente paso que necesitaba leer. Aborda la brecha de escalabilidad que ninguno de sus predecesores resolvió: ¿qué sucede cuando un solo sistema de pasarela debe proteger agentes en muchas tareas diferentes, cada una con su propio vocabulario de políticas y superficie de riesgo, sin estar preprogramado para cada una?

El artículo

Weidi Luo, Shenghong Dai, Xiaogeng Liu, Suman Banerjee, Huan Sun, Muhao Chen y Chaowei Xiao presentan AGrail — "A Lifelong Agent Guardrail with Effective and Adaptive Safety Detection" — publicado en la sección de artículos largos de ACL 2025. El problema central es dual: los agentes de LLM enfrentan riesgos específicos de la tarea definidos por el administrador (p. ej., "no borrar archivos en este directorio") y riesgos sistémicos por vulnerabilidades de diseño (inyección de prompts, ataques al entorno), y las pasarelas existentes manejan como máximo una de estas categorías correctamente y requieren la especificación manual de políticas por tarea. La respuesta de AGrail es un sistema cooperativo de dos LLM — un Analizador y un Ejecutor — que genera, prueba y refina iterativamente las comprobaciones de seguridad en el momento de la inferencia a través de la adaptación en tiempo de prueba (TTA), almacenando las comprobaciones refinadas en un módulo de memoria que transfiere el aprendizaje a tareas futuras.

Ideas clave

• Cooperación de dos LLM: El Analizador recupera comprobaciones de seguridad relevantes de la memoria, las revisa y propone conjuntos de comprobaciones actualizados. El Ejecutor evalúa cada comprobación propuesta, decidiendo si invoca una herramienta externa, confía en el autorrazonamiento o descarta una comprobación redundante. Este bucle se ejecuta de forma iterativa hasta que el conjunto de comprobaciones converge.
• Memoria con prompts de retroceso (step-back prompting): Las acciones se almacenan tanto en lenguaje natural como en representaciones de comandos de herramientas utilizando prompts de retroceso. Durante la inferencia, solo se muestra la forma en lenguaje natural (para evitar interferencias de la sintaxis de comandos brutos), pero ambas se utilizan para la recuperación. La memoria converge alrededor de la cuarta iteración de TTA, con una similitud de coseno del 98%+ entre semillas aleatorias.
• Benchmark Safe-OS: Los autores introducen un nuevo conjunto de datos de 100 escenarios que simulan interacciones reales de agentes de SO a través de Docker — 23 de inyección de prompts, 30 de sabotaje del sistema, 20 de ataques al entorno y 27 casos normales — porque ningún benchmark existente combinaba los tres tipos de riesgo sistémico.
• 96% de preservación benigna con 0% de ASR en inyección de prompts: En Safe-OS con Claude-3.5-Sonnet, AGrail bloquea solo el 4.4% de las acciones benignas (95.6% de preservación) mientras logra una tasa de éxito de ataque (ASR) del 0% contra la inyección de prompts. Las líneas base de la competencia bloquean hasta el 49.2% de las acciones benignas.
• Resultados de riesgos específicos de la tarea: En Mind2Web-SC (agente web), AGrail logra F1=94.1 con un 95.8% de acuerdo. En EICU-AC (privacidad en salud), F1=98.5 con un 100% de acuerdo.
• Inestabilidad de modelos débiles: GPT-4o-mini como base muestra inestabilidad en las secuencias de entrada; se requiere Claude-3.5-Sonnet para un rendimiento fiable, lo cual es un prerrequisito de cómputo implícito que el artículo minimiza.

Qué se sostiene — y qué no

El resultado que más me impresiona es la comparación de falsos positivos: GuardAgent y LLaMA-Guard bloquean hasta el 49.2% de las acciones legítimas de Safe-OS. Eso es una catástrofe de usabilidad — una pasarela que marca la mitad del trabajo normal es una pasarela que nadie dejará activada. La tasa de bloqueo del 4.4% de AGrail en acciones benignas es genuinamente mejor.

Dicho esto, vale la pena mencionar varias brechas. Primero, las cifras de ataques de inyección ambiental (EIA) son más crudas que las afirmaciones de los titulares: el ASR de generación de acciones es del 28% — más de uno de cada cuatro ataques logra pasar. El artículo oculta esto en relación con el resultado del 0% de inyección de prompts. Segundo, el modelo de amenazas es estrecho: Safe-OS cubre tres tipos de ataques, pero el artículo no evalúa cadenas de razonamiento adversarias que eludan por completo al Analizador, ni casos donde un contexto suficientemente largo empuje al módulo de memoria hacia comprobaciones previas incorrectas. Tercero, la historia del aprendizaje permanente requiere que el agente encuentre acciones similares repetidamente para que la memoria converja — el resultado de convergencia por iteración cuatro se mantiene en la configuración controlada del artículo, pero no es obvio qué tan rápido se estabiliza la memoria cuando las distribuciones de acciones son muy variadas. Cuarto, la sobrecarga computacional de ejecutar dos LLM más las iteraciones de TTA por paso del agente nunca se cuantifica. En aplicaciones sensibles a la latencia, ese coste importa.

Los autores reconocen honestamente que dependen de LLM generales en lugar de modelos de pasarela especializados, y que la invocación de herramientas es mínima. Lo que no discuten es cómo las propuestas de comprobación de políticas del Analizador podrían ser envenenadas por un adversario que comprenda el flujo de trabajo de los prompts de retroceso.

Por qué esto es importante para la IA financiera

La taxonomía de riesgo específico de la tarea + riesgo sistémico se aplica directamente a los agentes contables. Un agente de escritura de Beancount enfrenta riesgos específicos de la tarea (reglas del administrador: "nunca contabilizar en un periodo cerrado", "siempre requerir aprobación de dos partes para transacciones superiores a $10,000") junto con riesgos sistémicos (una nota maliciosa en un concepto de transacción que inyecta instrucciones). El enfoque de AGrail es más natural para este caso de uso que los circuitos de reglas formales de ShieldAgent, porque los contadores articulan las políticas en lenguaje sencillo, no en lógica de primer orden.

El ángulo del aprendizaje permanente es especialmente relevante. Una sola implementación podría proteger docenas de libros mayores distintos, cada uno con diferentes políticas de plan de cuentas, diferentes límites de año fiscal y diferentes jerarquías de aprobación. La capacidad de transferir comprobaciones de seguridad de un libro mayor a otro, refinándolas mediante TTA en lugar de empezar de cero, podría reducir significativamente la carga de configuración por libro mayor. Si la implementación actual realmente logra esto a la escala de una plataforma contable multi-inquilino real es una pregunta que el artículo no responde — sus evaluaciones cubren tres tareas de agentes distintas, no docenas.

La tasa de fallo del 28% en la generación de acciones EIA es la cifra a la que sigo volviendo. Para un agente contable, un ataque exitoso de generación de acciones adversarias significa que se confirma un asiento contable incorrecto. Eso no es recuperable sin una auditoría manual. Una pasarela que falla en el 28% de los ataques EIA requeriría una capa de verificación secundaria — lo que nos devuelve al debate multi-agente y a los diseños de verificación formal de lecturas anteriores en esta lista.

Qué leer a continuación

• M3MAD-Bench (arXiv:2601.02854) — la auditoría más exhaustiva sobre si el debate multi-agente realmente ayuda a través de modalidades y tareas; directamente relevante si se considera el diseño de LLM cooperativo de AGrail para flujos de trabajo financieros.
• ShieldAgent (arXiv:2503.22738, ICML 2025) — el enfoque de verificación formal contra el que se compara AGrail implícitamente; leer ambos en paralelo aclara el compromiso entre adaptabilidad y garantías formales.
• Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — combina el análisis de procesos STPA con MCP para producir especificaciones de seguridad ejecutables para agentes que llaman a herramientas, el complemento más sistemático existente para la comprobación en tiempo de ejecución de AGrail.