sistema: OPERATIVO
← volver a todos los hacks
AGENTS MEDIUM NEW

STAC: encadenar llamadas de herramientas inofensivas para secuestrar un agente IA

Un marco de investigación demuestra que una secuencia de llamadas de herramientas inofensivas por separado puede llevar a un agente a una acción final dañina, burlando la seguridad de los modelos punteros con más del 90 % de éxito.

2026-07-06 // 6 min affects: ai-agents, tool-use, function-calling, gpt-4.1, llm-agent-frameworks

¿Qué es esto?

El Sequential Tool Attack Chaining (STAC) es una clase de ataque multiturno contra agentes LLM con herramientas, presentada en un artículo publicado en arXiv en septiembre de 2025 y revisado en febrero de 2026 (arXiv:2509.25624). La idea es sencilla de enunciar y difícil de contrarrestar: en lugar de una petición abiertamente maliciosa, el atacante conduce al agente a través de una cadena de llamadas de herramientas que, por separado, parecen todas inofensivas, pero que, en conjunto, logran un objetivo dañino. La intención maliciosa solo se hace visible en el último paso.

El ejemplo emblemático del artículo es una destrucción de datos armada a partir de tareas de mantenimiento rutinarias: se hace ejecutar al agente una copia de seguridad de archivos, luego la eliminación de archivos «duplicados» y después una «limpieza de archivos»; una secuencia en la que cada acción es razonable por separado, pero cuyo efecto neto es borrar datos críticos. Como ningún turno activa por sí solo un control de seguridad, las barreras clásicas a nivel de contenido no encuentran nada que rechazar.

Cómo funciona

STAC se distingue de un jailbreak clásico por su objetivo. Un jailbreak habitual busca hacer que el modelo diga algo prohibido; STAC busca hacer que ejecute algo prohibido mediante sus herramientas, produciendo cambios reales en un entorno externo —un sistema de archivos, una API bancaria, un espacio de trabajo— que pueden ser irreversibles. Ese salto del texto generado a la acción ejecutada convierte a STAC en un problema propio de la seguridad de agentes, y no en un problema de chatbot.

Los investigadores construyeron una tubería automatizada para generar estos ataques a escala, y comprender sus cuatro roles basta para ver por qué la técnica es sigilosa, sin necesidad de ningún código de ataque operativo:

Primero, un generador planifica una cadena de dos a seis llamadas de herramientas objetivo que alcanzan de forma acumulativa un fin malicioso, procurando que todos los pasos salvo el último sean inocuos por separado. Después, un verificador ejecuta realmente cada llamada planificada en el entorno objetivo y corrige cualquier llamada que falle, garantizando que la cadena sea efectivamente ejecutable. Luego, un redactor de prompts compone una conversación multiturno sintética, de apariencia inofensiva, que llevaría de forma plausible a un agente hasta esas llamadas intermedias, construyendo el contexto sin tocar aún a un agente real. Por último, un planificador retoma ese historial sintético y guía interactivamente a un agente real hasta la acción final, adaptándose en tiempo real a sus respuestas.

# Forma ilustrativa únicamente — sin payload operativo
Turno 1  -> llamada de herramienta de preparación inocua   (parece rutinaria)
Turno 2  -> llamada de herramienta de contextualización     (parece rutinaria)
...
Turno T  -> llamada de herramienta final                    (el daño solo aparece aquí)

La estructura distribuida es toda la clave: el objetivo malicioso se reparte entre los turnos de modo que solo puede reconocerse razonando sobre la secuencia completa. El artículo se abstiene deliberadamente de ofrecer un exploit llave en mano y documenta en su lugar el patrón de ataque y un banco de pruebas para estudiarlo.

Por qué importa

Es la evaluación lo que hace que STAC merezca atención. En 483 casos generados, que abarcan 1352 conjuntos de interacciones usuario-agente-entorno —construidos sobre los entornos SHADE-Arena (banca, viajes, espacio de trabajo, gestión de un filtro antispam, que extienden AgentDojo) más varias decenas muestreadas de Agent-SafetyBench, y organizados en torno a diez modos de fallo propios de los agentes—, las tasas de éxito superaron el 90 % para la mayoría de los agentes probados, incluido un modelo puntero muy capaz. El éxito aumentaba a lo largo de los turnos, y la vulnerabilidad se mantenía en distintas familias y tamaños de modelo, sin estar ligada a una arquitectura concreta.

Si esto se generaliza, es por una razón estructural. Los agentes actuales ejecutan las herramientas paso a paso y juzgan cada petición más o menos por separado; rara vez razonan de forma global sobre el efecto acumulado de una secuencia de acciones completa. Un modelo que rechaza con fiabilidad una instrucción peligrosa aislada puede aun así ser conducido al mismo destino un paso inocuo cada vez. El artículo también muestra que un método de jailbreak multiturno diseñado para chatbots se transfiere mal a este contexto, lo que corrobora otros trabajos que sostienen que la seguridad a nivel de texto no se convierte automáticamente en seguridad a nivel de llamadas de herramientas (arXiv:2602.16943). Defender las palabras que el modelo emite no equivale a defender las acciones que emprende.

Defensas

  • Razonar sobre toda la trayectoria, no sobre el último turno. La mejor mitigación del artículo es un prompt de defensa que hace que el agente sopese los perjuicios y beneficios de una acción a la luz de la interacción completa antes de ejecutarla. Un prompt complementario hace que el agente resuma la intención acumulada del usuario a lo largo de todos los turnos. Estos enfoques redujeron el éxito de los ataques hasta en un 28,8 %: notable, pero lejos de una solución completa, ya que el éxito se mantuvo en o por encima del 58,6 %.
  • No confíe en las defensas antiinyección para esto. Técnicas como el spotlighting o el datamarking, diseñadas para separar instrucciones y datos, ofrecen aquí una protección limitada, porque STAC no usa ninguna instrucción inyectada: cada petición es un turno de usuario legítimo. Trate la intención a nivel de secuencia como un control distinto del filtrado de inyecciones.
  • Ponga barreras a las llamadas de herramientas irreversibles y de alto impacto. Exija confirmación, doble control o un periodo de enfriamiento para las acciones que borran datos, mueven dinero, cambian permisos o envían mensajes al exterior. Es en el paso final donde el daño se cristaliza, y por tanto donde más rinde un control humano.
  • Restrinja las combinaciones de herramientas peligrosas. Cartografíe qué herramientas, usadas juntas, pueden producir efectos irreversibles, y aplique el mínimo privilegio para que una misma sesión de agente no pueda, por ejemplo, enumerar y borrar en masa a la vez, o leer secretos y exfiltrarlos.
  • Vigile a nivel de secuencia. Una telemetría de comportamiento que reconstruya el arco de una sesión —y no solo un allow/deny por llamada— es lo que hace aflorar una cadena cuya intención solo es legible de principio a fin. Registre los historiales completos de llamadas de herramientas y alerte sobre los patrones que se ensamblan en efectos de alto impacto.
  • Pruebe con red teaming multiturno y consciente de las herramientas. Las baterías de jailbreak de prompt único o solo textuales subestimarán esta exposición. Evalúe a los agentes frente a trayectorias de herramientas de varios pasos en entornos realistas antes de cualquier despliegue.

Estado

ElementoValor
TécnicaSequential Tool Attack Chaining (STAC), ataque multiturno sobre el uso de herramientas
Primera divulgaciónPreprint de arXiv, septiembre de 2025 (revisado en febrero de 2026)
Alcance483 casos / 1352 conjuntos de interacciones; SHADE-Arena + Agent-SafetyBench; 10 modos de fallo
Impacto medidoÉxito > 90 % para la mayoría de los agentes probados, incluido un modelo puntero
Mejor defensa documentadaPrompt de defensa por razonamiento / resumen de intención — hasta 28,8 % de reducción (éxito residual ≥ 58,6 %)
NaturalezaResultado de investigación, enfoque defensivo; sin exploit operativo difundido

Fechas clave: septiembre de 2025 — primera publicación de STAC en arXiv. Febrero de 2026 — versión revisada. Se trata de un estudio de banco de pruebas y defensa, no de un incidente real contra un producto concreto.

Este artículo resume trabajos de investigación en seguridad de acceso público con fines defensivos y omite deliberadamente todo código de ataque funcional.

Sources