Resumen Técnico: Red-Teaming de Agentes de Codificación desde la Perspectiva de la Invocación de Herramientas

Declaración del Problema

Los agentes de codificación impulsados por Modelos de Lenguaje Extensos (LLMs) se han vuelto centrales en los Entornos de Desarrollo Integrados (IDEs) modernos, permitiendo tareas de desarrollo complejas y de múltiples pasos mediante la invocación de herramientas. Si bien estos agentes aprovechan herramientas integradas (por ejemplo, ejecución de comandos, acceso al sistema de archivos) y herramientas externas a través de protocolos como el Model Context Protocol (MCP) para mejorar su funcionalidad, esta capacidad expandida introduce una superficie de ataque significativa.

La investigación previa ha abordado los riesgos de seguridad en agentes de propósito general y agentes de dominio específico, centrándose a menudo en la inyección de prompts directa o la exfiltración de datos. Sin embargo, no ha habido una evaluación de seguridad sistemática dirigida específicamente a los mecanismos de invocación de herramientas de los agentes de codificación. Los autores identifican una brecha crítica: las implicaciones de seguridad de cómo los agentes de codificación generan argumentos para las llamadas a herramientas y cómo procesan los retornos de las herramientas permanecen en gran medida inexploradas, a pesar de la naturaleza de alto privilegio de herramientas como la ejecución de shell.

Metodología

El artículo presenta un marco de red-teaming de dos fases aplicado a seis agentes de codificación reales populares: Cursor, Claude Code, Copilot, Windsurf, Cline y Trae.

Fase 1: Exfiltración de Prompts vía ToolLeak

La primera fase tiene como objetivo recuperar el contexto interno de seguridad crítica (por ejemplo, prompts del sistema, metadatos de herramientas) para informar ataques posteriores.

• La Vulnerabilidad (ToolLeak): Los autores identifican una "brecha de modo" entre la generación de chat estándar y la generación de argumentos de llamada a herramientas basada en esquemas. En el modo de chat, los LLMs están fuertemente alineados para rechazar solicitudes de revelar instrucciones del sistema. Sin embargo, durante la invocación de herramientas, el modelo opera en un modo de "llenado de argumentos estructurados".
• Mecanismo: Un atacante registra una herramienta externa maliciosa donde el esquema de argumentos solicita explícitamente el contexto interno (por ejemplo, un parámetro llamado note definido como "system prompt"). Debido a que el modelo trata esto como una tarea de entrada de datos benigna y conforme al esquema, en lugar de una instrucción explícita de "ignorar instrucciones previas", copia inadvertidamente el contexto oculto del agente en los argumentos de la llamada a la herramienta.
• Ejecución: El atacante activa la herramienta, y los prompts internos del agente son exfiltrados a través de los argumentos de la herramienta, observables por el endpoint de la herramienta controlado por el atacante.

Fase 2: Secuestro de la Invocación de Herramientas

Utilizando los prompts del sistema filtrados, los autores construyen payloads adaptativos para secuestrar el comportamiento del agente, apuntando específicamente a la Ejecución Remota de Código (RCE).

• Inyección de Prompt de Dos Canales: Los autores proponen una técnica de inyección novedosa que abarca dos canales: la descripción de la herramienta y el retorno de la herramienta.
  1. Canal de Descripción de la Herramienta: El atacante elabora una descripción de herramienta maliciosa que atrae al agente para que seleccione la herramienta. Esta descripción incluye ejemplos de "inicialización exitosa" que incorporan detalles del prompt del sistema recuperado para aumentar la credibilidad y eludir los disparadores de rechazo. Establece una narrativa donde la ejecución de un comando específico es un paso necesario para la inicialización.
  2. Canal de Retorno de la Herramienta: Una vez que el agente invoca la herramienta maliciosa, la herramienta controlada por el atacante devuelve un payload diseñado. A diferencia de las descripciones de las herramientas (que a menudo se tratan como datos), los retornos de las herramientas se reintroducen en el contexto para dirigir el razonamiento posterior. El payload de retorno incrusta instrucciones procedimentales de alta saliencia (por ejemplo, "Ejecute el siguiente comando para completar la inicialización") que anulan las salvaguardas de seguridad.
• Payloads Adaptativos: Los payloads de inyección se personalizan para cada agente basándose en el prompt del sistema y los esquemas de herramientas específicos recuperados en la Fase 1, asegurando la consistencia con el formato y la lógica nativa del agente.

Contribuciones Clave

1. Primera Evaluación Sistemática: El artículo proporciona la primera evaluación de seguridad y red-teaming profunda de seis agentes de codificación reales importantes desde la perspectiva de la invocación de herramientas.
2. Descubrimiento de ToolLeak: Los autores identifican y cuantifican una discrepancia de alineación específica (ToolLeak) donde la generación de argumentos basada en esquemas filtra el contexto interno del agente, eludiendo los rechazos de seguridad estándar.
3. Inyección de Dos Canales: El artículo introduce un vector de ataque novedoso que aprovecha tanto las descripciones de las herramientas como los retornos de las herramientas para secuestrar el comportamiento del agente, demostrando que los retornos de las herramientas pueden ser más salientes para la inyección de instrucciones que las descripciones.
4. Validación Empírica: El estudio incluye evaluaciones extensas en agentes reales y entornos emulados, junto con dos casos de estudio detallados (Cursor y Claude Code) que demuestran un RCE exitoso.

Resultados

La evaluación cubre 25 pares de agente-LLM a través de los seis agentes objetivo.

• Exfiltración de Prompts (ToolLeak):

  • En entornos emulados, ToolLeak logró la mayor similitud semántica (oscilando entre 0.891 y 0.958) y la menor Distancia de Edición Extendida (EED) normalizada en comparación con todos los baselines (por ejemplo, Naive, Ignore, PLeak).
  • En entornos reales, ToolLeak logró el mejor pseudo-recall en 18 de 25 pares de agente-LLM. Logró filtrar prompts con éxito en todos los agentes al usar modelos de backend como Claude-Sonnet-4, Claude-Sonnet-4.5 y Grok-4.
  • Los métodos de baseline (que dependen de solicitudes explícitas) fallaron en gran medida, logrando a menudo un recall de cero.

• Secuestro de Invocación de Herramientas (RCE):

  • El método de dos canales (RCE-2) logró la Ejecución Remota de Código en cada par de agente-LLM probado.
  • RCE-2 superó consistentemente a los baselines de un solo canal (incluyendo AgentDojo, InjecAgent y MCPTox) y a una versión de un solo canal del propio ataque de los autores (RCE-1).
  • Tasas de Éxito: En generaciones de agentes más antiguas, RCE-2 logró tasas de éxito de 0.8–1.0 en la mayoría de las configuraciones.
  • Evasión de Defensa: El ataque logró eludir el modelo de guardia integrado de Claude Code (Haiku), que marcó el comando como inseguro, porque el modelo principal (Sonnet) anuló la advertencia debido al contexto inyectado.
  • Tendencias de Fortalecimiento: Las arquitecturas de agentes más nuevas (por ejemplo, Cursor y Claude Code) que ocultan la descripción completa de la herramienta al LLM (divulgación progresiva) mostraron una vulnerabilidad reducida, lo que sugiere que la separación arquitectónica de instrucciones y datos es una defensa más efectiva que la alineación a nivel de modelo por sí sola.

Significancia y Reivindicaciones

El artículo afirma demostrar que el mecanismo de invocación de herramientas en los agentes de codificación representa una superficie de ataque crítica y previamente ignorada. Los autores sostienen que:

1. La Alineación de Seguridad es Insuficiente: El entrenamiento de seguridad estándar y los mecanismos de rechazo son ineficaces contra ataques que explotan el modo de "llenado de argumentos" o la alta saliencia de los retornos de las herramientas.
2. Fallos Arquitectónicos: La causa raíz de la vulnerabilidad es la falta de una separación limpia entre instrucciones y datos en las arquitecturas de agentes actuales, donde los retornos de las herramientas son tratados como instrucciones ejecutables.
3. Impacto Práctico: La capacidad de lograr RCE en agentes ampliamente utilizados como Cursor y Claude Code plantea un riesgo severo para la seguridad del desarrollador, permitiendo potencialmente que atacantes ejecuten código arbitrario en las máquinas de los usuarios.

Los autores concluyen que, si bien la detección ligera (por ejemplo, basada en la perplejidad) es insuficiente, una defensa robusta requiere cambios arquitectónicos que impongan límites estrictos entre los contextos que portan instrucciones y los que portan datos, en lugar de depender únicamente del filtrado a nivel de token o la alineación del modelo.