Resumen Técnico: Piense dos veces antes de actuar

Declaración del Problema

La integración de herramientas externas ha expandido significativamente las capacidades de los agentes de Modelos de Lenguaje Extensos (LLM), pero introduce nuevas superficies de ataque más allá de la inyección de prompts tradicional. Este artículo identifica y formaliza el envenenamiento de descripciones entre herramientas (cross-tool description poisoning), un vector de ataque sofisticado donde los adversarios manipulan los metadatos (descripciones) de herramientas no críticas o débilmente reguladas para desviar la trayectoria de planificación de un agente.

A diferencia de los ataques previos de "preferencia de herramienta" que sesgan a un agente para seleccionar una herramienta envenenada específica, el envenenamiento de descripciones entre herramientas permite a un adversario inducir acciones maliciosas que involucran otras herramientas, incluso si la herramienta envenenada nunca es seleccionada. Por ejemplo, envenenar la descripción de una herramienta benigna de "Respaldo de Cuenta" puede causar que el planificador inserte un paso malicioso de "Enviador de Correo Electrónico" (por ejemplo, enviar detalles de la cuenta a un atacante) en la trayectoria de una tarea legítima de "Transferencia Bancaria". El desafío central es que las descripciones envenenadas persisten en el contexto de planificación a través de múltiples pasos, permitiendo una influencia continua sobre las elecciones de herramientas subsecuentes.

Se determinó que las defensas existentes, como el filtrado estático de herramientas, la repetición de prompts o las restricciones a nivel de sistema (por ejemplo, Drift, Progent), son ineficaces contra esta amenaza específica. Estos métodos o bien no tienen en cuenta el contexto de la tarea, o dependen de estados internos del modelo (que a menudo son inaccesibles vía API), o no pueden distinguir entre el uso benigno de una herramienta y el uso influenciado por metadatos envenenados.

Metodología: Tool-Guard

Para abordar estas limitaciones, los autores proponen Tool-Guard, un nuevo sistema de defensa a nivel de sistema basado en el concepto de planificación aislada. La filosofía central es aplicar el principio de seguridad de aislamiento a la planificación de agentes, rompiendo la conexión entre las descripciones envenenadas y el objetivo pretendido de la influencia sin deshabilitar las herramientas de forma permanente.

Mecanismo Central

Tool-Guard opera a través de un bucle dinámico e iterativo que involucra tres etapas principales:

1. Partición Dinámica del Conjunto de Herramientas:
   El sistema mantiene una partición dinámica del conjunto de herramientas disponibles $K$ en dos listas disjuntas:

   • Lista de Influenciadas ($K_{inf}$): Contiene herramientas sospechosas de estar influenciadas por descripciones envenenadas (inicialmente vacía).
   • Lista de Otras ($K_{others}$): Contiene las herramientas restantes.
     Las herramientas no se asumen maliciosas; más bien, se mueven a $K_{inf}$ si su invocación parece desalineada con la intención del usuario o pobremente fundamentada en el contexto.

2. Planificación Aislada:
   En lugar de consultar al planificador con el conjunto completo de herramientas, Tool-Guard consulta al planificador dos veces bajo un estricto aislamiento:

   • Una vez solo con las descripciones en $K_{inf}$.
   • Una vez solo con las descripciones en $K_{others}$.
     Esto evita que una descripción envenenada en un subconjunto dirija la selección o parametrización de las herramientas en el otro subconjunto. El sistema luego selecciona una acción candidata de los dos planes resultantes; si ambos subconjuntos producen acciones válidas, se aplica un desempate; si ninguno lo hace, la trayectoria termina.

3. Validación Previa a la Ejecución y Actualización de la Lista:
   Antes de ejecutar una llamada a una herramienta, Tool-Guard realiza dos verificaciones semánticas utilizando un validador basado en LLM:

   • Verificación de Alineación: Verifica si la acción es consistente con la intención del usuario y el progreso validado.
   • Verificación de Sospecha: Verifica si los argumentos están fundamentados en la solicitud del usuario o en salidas de herramientas previas, señalando entidades sensibles (por ejemplo, direcciones de destinatarios) que carecen de procedencia clara.

   Si la validación falla, la herramienta se mueve a la Lista de Influenciadas, y se activa el proceso de replanificación al planificador bajo la partición actualizada. Este proceso iterativo aísla progresivamente las rutas de influencia perjudiciales mientras preserva la utilidad de las herramientas legítimas.

Extensión a MCP

La metodología se extiende al Protocolo de Contexto de Modelo (MCP) aplicando la misma lógica de aislamiento a nivel de servidor, particionando los servidores en grupos influenciados y no influenciados para prevenir el envenenamiento entre servidores.

Contribuciones Clave

1. Caracterización del Envenenamiento de Descripciones entre Herramientas: El artículo demuestra que los adversarios pueden inyectar pasos maliciosos en invocaciones de herramientas de seguridad crítica mediante el envenenamiento de descripciones de herramientas no críticas, incluso cuando la herramienta envenenada nunca es llamada. Muestra que las defensas existentes arrojan Altas Tasas de Éxito de Ataque (ASR) contra esta influencia continua.
2. Defensa Tool-Guard: Los autores proponen una defensa que particiona dinámicamente el conjunto de herramientas y emplea planificación aislada. Al validar las acciones antes de la ejecución y aislar las herramientas sospechosas, corta las rutas de dirección entre herramientas maliciosas mientras mantiene la disponibilidad total de las herramientas.
3. Evaluación Exhaustiva: Experimentos extensos en los benchmarks AgentDojo y ASB (Agent Security Bench) demuestran que Tool-Guard reduce el ASR a niveles insignificantes mientras preserva una alta utilidad de la tarea. El artículo también cuantifica la eficiencia y la robustez contra variantes de ataque adaptativas.

Resultados Experimentales

Los autores evaluaron Tool-Guard contra cinco mecanismos de defensa existentes (System Prompt, Tool Filtering, Repeat Prompt, Drift, Progent) a través de múltiples LLMs (GPT-4o, GPT-4o-mini, Gemini-2.5, Claude-3.5) en dos benchmarks.

• Tasa de Éxito de Ataque (ASR): Tool-Guard redujo el ASR a niveles insignificantes (por ejemplo, de ~43% a ~2% o 0% en AgentDojo, y de ~72-96% a 0% en ASB para la mayoría de los modelos). En contraste, las defensas existentes a menudo fallaron en reducir el ASR significativamente (por ejemplo, Drift y Progent mostraron ASRs de 24.7% y 19.6% respectivamente en AgentDojo).
• Preservación de la Utilidad: Tool-Guard mantuvo una alta utilidad de la tarea tanto en condiciones benignas como de ataque. A diferencia de las defensas de "exceso de control" (over-kill) que bloquean herramientas indiscriminadamente, Tool-Guard preservó la capacidad de completar tareas, con puntuaciones de utilidad comparables o mejores que las de los baselines bajo ataque.
• Eficiencia:
  • Sobrecarga de Tokens: Tool-Guard incurrió en un aumento de aproximadamente 1.5× en el uso de tokens en comparación con el baseline sin defensa, significativamente menor que otras defensas a nivel de sistema como Drift o Progent.
  • Latencia: El método introdujo una sobrecarga de tiempo de ejecución de aproximadamente 3.7× en comparación con el baseline (mayor que el 1.2× de Progent pero menor que el 7.3× de Drift), atribuida al mecanismo de replanificación.
• Robustez:
  • Estabilidad: La defensa se mantuvo estable a través de múltiples ejecuciones con bajas desviaciones estándar.
  • Ataques Adaptativos: Tool-Guard se mantuvo robusto contra ataques semánticos-adaptativos (que intentan evadir las verificaciones mediante justificaciones fabricadas) y ataques basados en optimización (PAIR, TAP). Aunque los ataques basados en optimización aumentaron ligeramente el ASR, este se mantuvo muy bajo (por ejemplo, 2.06% bajo PAIR), resaltando el compromiso inherente que enfrenta el atacante entre ser lo suficientemente explícito para influir en la planificación y lo suficientemente sutil para evadir la validación.
  • Pruebas de Estrés: Incluso cuando se envenenaron herramientas críticas de alta frecuencia, Tool-Guard mantuvo el ASR en un nivel de un solo dígito bajo.

Significancia y Reivindicaciones

El artículo afirma que las descripciones de las herramientas representan una superficie de ataque crítica y previamente poco explorada en los agentes de LLM. La importancia de este trabajo radica en:

1. Identificación de un Nuevo Vector de Ataque: Formalizar el envenenamiento de descripciones entre herramientas, que evade las defensas tradicionales explotando la naturaleza persistente de los metadatos de las herramientas en el contexto de planificación.
2. Demostración de las Limitaciones de las Defensas: Mostrar que las defensas actuales de vanguardia son insuficientes contra la influencia continua entre herramientas.
3. Propuesta de una Solución a Nivel de Sistema: Introducir Tool-Guard, que mitiga eficazmente estos ataques mediante el aislamiento de la influencia en lugar de depender únicamente de salvaguardas en el momento de la ejecución o escaneos estáticos.
4. Equilibrio entre Seguridad y Utilidad: Demostrar que una defensa efectiva no requiere sacrificar la utilidad del agente; Tool-Guard logra una seguridad robusta con una sobrecarga mínima de tokens y sin un comportamiento de "exceso de control".

Los autores concluyen que las defensas efectivas para los agentes de LLM aumentados con herramientas deben abordar explícitamente la influencia entre herramientas mediante mecanismos como la planificación aislada, en lugar de confiar únicamente en las defensas contra la inyección de prompts o el filtrado estático de herramientas.