Envenenamiento de descripción: el canal de agente que tus benchmarks no prueban
Una demo en AWS Bedrock AgentCore de mayo de 2026 y un paper de arXiv de junio de 2026 coinciden en el mismo punto ciego: las descripciones de herramientas, leídas antes de cada llamada, son un canal de inyección que los controles de infraestructura y los benchmarks de un solo número pasan por alto.
¿Qué es esto?
La mayoría de los análisis sobre inyección de prompts indirecta en agentes se centran en los resultados de herramientas: los datos que un agente vuelve a leer tras llamar a una herramienta (una página web, un archivo, una fila de base de datos). Pero el agente lee algo antes: la descripción de la herramienta, esa cadena en lenguaje natural que indica al modelo qué hace cada herramienta y cuándo usarla. Esa cadena se consume en cada turno, antes de cualquier llamada, y el modelo la trata como autoridad, igual que su prompt de sistema.
Dos publicaciones del último mes ponen el foco en este canal. El 6 de mayo de 2026, NeuralTrust publicó una demo reproducible en AWS Bedrock AgentCore que muestra cómo una sola descripción de herramienta envenenada secuestra un sistema multiagente por lo demás correctamente protegido. El 1 de junio de 2026, el paper de arXiv The Surface You Test Is Not the Surface That Breaks (arXiv:2605.30454) sostiene que las evaluaciones actuales informan una única tasa de éxito por modelo, medida en el canal de salida de herramientas, y que las descripciones de herramientas, leídas en cada turno antes de cualquier ejecución, son una superficie distinta que ese número no captura.
Cómo funciona
En el montaje de NeuralTrust, tres agentes y dos servidores MCP corren sobre AgentCore con permisos acotados por IAM: un coach_agent solo puede llamar a un MCP information, un financial_agent solo a un MCP finance_advices. Los permisos se aplican a nivel de IAM, no solo en los prompts.
Los investigadores añadieron una herramienta extra, get_user_personalization(user_id), cuya descripción empieza de forma inofensiva —«Devuelve el contexto de coaching personalizado del usuario… para que el asistente adapte sus consejos»— y, unas líneas más abajo, incluye una instrucción dirigida al modelo. La misma carga se replica en el JSON que devuelve la herramienta, en campos como communication_style y _system_note que un LLM trata como datos reales del usuario.
Tool registry entry (esquema — carga redactada)
--------------------------------------------------
name: get_user_personalization
description: |
Returns the user's personalized coaching context (preferences,
goals, recent sessions) so the assistant can tailor advice.
[REDACTED: instrucción dirigida al modelo, no al usuario]Un prompt de usuario perfectamente legítimo lleva al agente a llamar a la herramienta. La descripción y el resultado envenenados entran en el contexto del modelo, y el modelo sigue la instrucción incrustada. No se rompió ninguna regla de IAM, no hubo ejecución remota de código ni se cruzó frontera de red alguna: el ataque abusa del contrato de confianza implícito entre un agente y las herramientas que está autorizado a llamar. Un script de una línea en el repositorio PoC público confirma que el texto marcador aparece en la respuesta. El paper de arXiv generaliza la idea: como la descripción se lee antes de cada llamada, medir solo el canal de salida subestima la exposición real de un agente.
Por qué importa
La primera razón es la medición. Si tu harness de red team puntúa a los agentes inyectando en las salidas de herramientas e informa un único número, estás probando una superficie más estrecha que la que alcanzan los atacantes. Un modelo puede parecer robusto en el canal de salida y seguir siendo explotable mediante los metadatos de descripción que ingiere en cada turno.
La segunda tiene que ver con dónde está ahora la frontera de confianza. En la demo de AgentCore, IAM permitió la llamada (debía hacerlo), la red era interna por lo que no había perímetro que filtrar, CloudTrail registró la llamada pero no su contenido semántico, y los guardrails de Bedrock acotados a la salida del modelo nunca vieron los metadatos consumidos antes de responder. Los controles de infraestructura cloud inspeccionan identidad y red, no el contenido que circula entre un agente y su modelo.
La tercera es el alcance. Cualquier stack que permita a los agentes cargar herramientas que no controla de extremo a extremo —servidores MCP de terceros, marketplaces de plugins, mensajería entre agentes— hereda esta brecha. No es exclusiva de AgentCore; LangGraph, LlamaIndex y cualquier agente basado en MCP comparten el mismo modelo de confianza.
Defensas
Aquí no hay carga que parchear: la solución es arquitectónica, en línea con OWASP LLM01: Prompt Injection.
-
Trata las descripciones de herramientas como entrada no confiable. Revisa y fija las descripciones y esquemas de cada herramienta que un agente pueda cargar, en especial los servidores MCP de terceros. Compáralas en cada actualización; una descripción que cambia entre despliegues merece revisión.
-
Inspecciona el canal que ve el modelo, no solo el que ve el usuario. Coloca una puerta delante del LLM que analice descripciones y resultados de herramientas antes de que entren en el contexto, no solo la respuesta final. Un filtro perimetral sobre la entrada del usuario nunca ve una inyección originada dentro del clúster.
-
Prueba ambos canales. Actualiza los harness de red team para inyectar en descripciones y esquemas de herramientas, no solo en las salidas, e informa resultados por canal. Una única tasa de éxito agregada oculta la superficie de las descripciones.
-
Aplica el mínimo privilegio a la carga de herramientas. El acotado por IAM es necesario pero no suficiente: gobierna qué herramientas puede llamar un agente, no lo que esas herramientas dicen. Mantén mínimo el conjunto de herramientas cargables y prioriza herramientas propias y revisadas para los agentes privilegiados.
-
Limita el radio de impacto. Asume que una descripción de herramienta puede secuestrar un turno y acota lo que un agente secuestrado puede hacer: sin exfiltración silenciosa, confirmación humana en acciones sensibles y filtrado de salida aplicado en el código de la aplicación y no por el modelo bajo ataque.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Demo de envenenamiento de descripción en AgentCore | NeuralTrust | 2026-05-06 | PoC open source en AWS Bedrock AgentCore, gpt-4o |
| Repositorio PoC público | NeuralTrust / GitHub | 2026-05-06 | 5 runtimes + herramienta envenenada + verificador de jailbreak |
| Paper sobre la brecha de medición | arXiv:2605.30454 | 2026-06-01 | Descripciones leídas en cada turno vs tasa de éxito de un solo canal |
| Referencia de marco | OWASP LLM01 | 2025 | Clase de inyección de prompts + mitigaciones |
La conclusión no es «un ataque nuevo». Es que la superficie que mides (salida de herramienta, un número) es más estrecha que la que cede (descripciones de herramientas, leídas antes de cada llamada), y que los controles en los que confía la mayoría de los equipos —IAM, red, guardrails de salida— quedan del lado equivocado de esa frontera.