TRUSTDESC: derivar las descripciones de herramientas del código para desactivar el tool poisoning

¿Qué es esto?

Una herramienta que un LLM puede invocar tiene dos partes: el código ejecutable que realiza el trabajo y una descripción en lenguaje natural que indica al modelo qué hace la herramienta y cuándo usarla. El modelo nunca ve el código, solo la descripción, cargada en su contexto. Esa descripción es, por tanto, una frontera de confianza, y es la que casi nadie verifica.

Los ataques de envenenamiento de herramientas (tool poisoning attacks, TPA) abusan precisamente de esa brecha. La clase fue divulgada públicamente por Invariant Labs en abril de 2025 para el Model Context Protocol, y se ha estudiado desde entonces a nivel del descriptor (p. ej. arXiv 2512.06556, diciembre de 2025). TRUSTDESC: Preventing Tool Poisoning in LLM Applications via Trusted Description Generation (Ye, Zhang, Jia y Hu, The Pennsylvania State University; arXiv 2604.07536, abril de 2026) propone una defensa que elimina la brecha en lugar de vigilarla: generar la descripción a partir de la implementación, para que el texto que lee el LLM sea fiel al código que realmente se ejecutará.

Cómo funciona

El artículo distingue dos tipos de TPA.

Los TPA explícitos insertan instrucciones maliciosas directamente en la descripción de una herramienta: por ejemplo, un texto oculto que ordena al modelo leer un archivo de configuración y pasar su contenido a otra herramienta. Parecen anómalos y son el objetivo de la mayoría de las defensas contra la inyección de prompts existentes.

Los TPA implícitos no contienen ninguna instrucción. El atacante redacta una descripción de apariencia inocente pero exagerada —deslizando palabras como «la mejor», «la más eficiente», «preferir siempre»— para sesgar el paso de selección de herramienta del modelo hacia una herramienta controlada por el atacante. No hay nada que un detector de instrucciones pueda señalar y, aun así, el modelo queda orientado. Como escriben los autores, decidir si una descripción es honesta exige razonar si coincide con la implementación, algo difícil incluso para un humano sin inspeccionar el código.

La premisa de TRUSTDESC es que el código fuente constituye una verdad de referencia confiable (los atacantes rara vez distribuyen código malicioso, porque la detección de malware funciona; atacan en cambio la capa descriptiva, barata y sin verificar). Reconstruye cada descripción en tres etapas:

base de código
   │
   ▼
[ SliceMin ]   un análisis estático sensible a la alcanzabilidad construye
   │           un grafo de llamadas por herramienta; un LLM poda la lógica
   │           inalcanzable/irrelevante hasta un fragmento de código mínimo
   │           y propio de la herramienta
   ▼
[ DescGen ]    sintetiza una descripción a partir del fragmento; elimina
   │           comentarios y docstrings, trunca los identificadores
   │           engañosos, mitiga los artefactos de código adversarios
   ▼
[ DynVer ]     descompone el borrador en afirmaciones verificables, las
   │           ejecuta, y usa un LLM juez sobre los registros para descartar
   │           toda afirmación que la ejecución no confirme
   ▼
descripción de confianza

Eliminar comentarios, docstrings y nombres de identificadores largos en DescGen se debe a que estos son, a su vez, canales controlables por el atacante; DynVer conserva luego solo el comportamiento que el código demuestra de verdad, lo que desactiva las afirmaciones alucinadas o exageradas.

Por qué importa

Las descripciones de herramientas son el tejido conectivo de los ecosistemas de agentes, y MCP las ha convertido en una cadena de suministro compartida y de terceros: instalas un servidor y sus descripciones autoredactadas entran en el contexto de tu modelo con confianza total. Los TPA implícitos son la mitad preocupante porque la primera línea de defensa de toda la industria —buscar instrucciones de aspecto malicioso— no los ve. Una descripción gramatical, halagadora y sin imperativos pasa sin problemas.

Re-derivar las descripciones a partir del código tiene un segundo efecto que el artículo mide: mejora el uso honesto de las herramientas. En 208 tareas sobre 52 herramientas de 12 servidores MCP, las descripciones generadas por TRUSTDESC elevaron la tasa de éxito de las tareas un 4,3 % de media frente a las descripciones originales, y cuando variantes de herramientas de baja calidad (con controles de seguridad o funciones eliminados) competían por la selección, las descripciones de confianza reducían la frecuencia con que el modelo elegía la herramienta más débil. Una descripción fiel es a la vez un control de seguridad y un control de calidad.

Los límites, con honestidad: frente a ataques adaptativos que plantan identificadores engañosos para sesgar la generación, la tasa de éxito del ataque fluctuó entre el 44,7 % y el 67,4 % en 15 iteraciones, sin una tendencia ascendente estable, pero lejos de cero. Se trata de mitigación, no de eliminación, y depende de tener acceso a un código fuente legible (el prototipo cubre servidores MCP en Python y TypeScript).

Defensas

Conclusiones concretas, adoptes o no este framework en particular:

1. Trata las descripciones de herramientas suministradas por el autor como entrada no confiable. Se cargan en el contexto del modelo con la misma autoridad que las instrucciones del sistema, pero sin ninguna revisión. Fija y revisa el texto exacto de las descripciones igual que fijarías la versión de una dependencia.

2. Defiende la selección de herramienta, no solo la ejecución. Los TPA implícitos nunca disparan directamente una acción insegura; sesgan qué herramienta elige el planificador. Registrar y restringir la selección —listas de permitidos, enrutamiento determinista para capacidades sensibles— cierra una puerta que los filtros de instrucciones dejan abierta.

3. Compara la descripción con la implementación. La causa raíz es la brecha entre la afirmación y el comportamiento. Generar o validar descripciones a partir del código (el enfoque de TRUSTDESC) atrapa la exageración que ningún escáner de palabras clave verá. Cuando no hay código fuente, la verificación dinámica de las afirmaciones de comportamiento es el recurso alternativo.

4. Presupuesta para adversarios adaptativos. Una tasa de éxito residual del ~45–67 % bajo ataque adaptativo significa que la fidelidad de las descripciones es una sola capa. Mantén debajo un alcance de herramientas de mínimo privilegio, validación humana para las llamadas de alto impacto y controles de exfiltración.

Estado

Elemento	Referencia	Fecha	Notas
Framework TRUSTDESC	arXiv:2604.07536	2026-04	SliceMin / DescGen / DynVer; 52 herramientas, 12 servidores MCP
Ataques semánticos a nivel de descriptor	arXiv:2512.06556	2025-12	Estudio previo de la manipulación de descriptores MCP
Tool Poisoning Attacks (origen)	Invariant Labs	2025-04	Primera divulgación pública de la clase TPA para MCP

El marco que conviene retener es el más simple: en un agente con herramientas, la descripción es la carta de presentación del código, y hoy cualquiera puede falsificarla. Reducir la brecha entre lo que una herramienta dice hacer y lo que hace convierte la descripción, de eslabón más débil, en uno verificable.