Prompt injection no es nuevo, el término circula desde los primeros LLM en producción. Lo que cambió es el tamaño del daño. Mientras el modelo solo respondía texto, una instrucción escondida en un prompt malicioso producía, en el peor de los casos, una respuesta incómoda. Ahora que los agentes de IA leen correo, abren archivos, llaman APIs y ejecutan comandos en nombre de un usuario, esa misma instrucción escondida se convierte en una acción real: un comando ejecutado, un dato exfiltrado, una configuración alterada sin que nadie la aprobara conscientemente.
Qué es prompt injection, en la práctica
Es la técnica de insertar una instrucción dentro de contenido que el modelo va a procesar, de forma que el modelo trate esa instrucción como un comando legítimo del operador. Existen dos variantes principales. En la inyección directa, el propio usuario escribe el prompt malicioso, generalmente para eludir el filtro de seguridad del modelo (jailbreak). En la inyección indirecta, la que preocupa en entornos agenticos, el atacante planta la instrucción en un contenido que el agente va a leer después, sin interacción directa con él: un comentario de issue, una página web, un archivo, el cuerpo de un correo. El modelo no distingue de forma confiable 'esto es dato que debo procesar' de 'esto es instrucción que debo seguir', porque ambos llegan por el mismo canal: texto.
De la conversación a la ejecución de comandos: el caso de GitHub Copilot
El ejemplo más concreto de 2025 es el CVE-2025-53773, publicado el 12 de agosto y clasificado como inyección de comandos (CWE-77) en GitHub Copilot y Visual Studio. La National Vulnerability Database y el GitHub Security Advisory (GHSA-3m2x-p87c-pwv6) confirman un CVSS 3.1 de 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), que afecta a Visual Studio 2022 en las versiones 17.14.0 a 17.14.11, corregido en la 17.14.12. Vale la pena registrarlo: varias publicaciones sobre el tema repitieron un CVSS de 9.6, un número que no coincide con lo que consta en las fuentes oficiales, exactamente el tipo de error que evitamos acá.
El mecanismo es lo que importa. Contenido malicioso plantado en algo que Copilot procesa, como un archivo del proyecto o una descripción de issue, instruye al agente a editar el archivo de configuración `.vscode/settings.json` y activar la opción `chat.tools.autoApprove`. Con esa bandera activa, Copilot empieza a ejecutar herramientas y comandos sin pedir confirmación explícita del usuario, el llamado modo YOLO. A partir de ahí, el próximo comando que el agente decida correr (por instrucción del mismo contenido malicioso) se ejecuta localmente sin ninguna barrera. Prompt injection deja de tratarse de engañar al modelo y pasa a tratarse de apagar el único control que quedaba en pie: la confirmación humana.
No es un caso aislado ni exclusivo de un proveedor
En marzo de 2026, el CVE-2026-2256 documentó una falla equivalente en MS-Agent, el framework de agentes de ModelScope: entrada derivada de un prompt, sin sanitizar, permite ejecutar comandos arbitrarios del sistema operativo, CVSS 3.1 de 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), que afecta la versión v1.6.0rc1 y anteriores, también clasificada como CWE-77. Dos proveedores distintos, dos arquitecturas de agente distintas, la misma raíz del problema: un comando derivado de contenido que debería tratarse como dato, ejecutado sin sanitización suficiente. No es casualidad que prompt injection ocupe el primer lugar del OWASP Top 10 para aplicaciones LLM desde que existe la lista.
Por qué es difícil de resolver de una vez por todas
La dificultad es estructural, no es falta de parche. Un LLM recibe instrucciones del sistema, contexto de la conversación y contenido externo por el mismo canal de texto, sin separación criptográfica ni estructural confiable entre 'esto es un comando' y 'esto es un dato a procesar'. Los filtros de palabras y los clasificadores de intención ayudan, pero son heurísticas, no garantías, y cada generación de defensa produce una nueva generación de técnicas de ofuscación para eludirla. Lo que realmente cambia el riesgo no es hacer perfecto al modelo, es limitar lo que una instrucción inyectada puede hacer incluso cuando pasa desapercibida.
Defensa en capas: lo que reduce el riesgo de verdad
- Tratar todo contenido externo (página web, PR, correo, archivo, respuesta de API de terceros) como dato no confiable, nunca como instrucción, incluso dentro del propio prompt de sistema del agente
- Correr las herramientas del agente en un sandbox aislado, sin acceso directo a la shell del host, al sistema de archivos sensible o a la red sin restricciones
- Exigir confirmación humana explícita para acciones de alto riesgo (ejecución de comandos, envío de datos hacia afuera, cambio de configuración), con la aprobación automática apagada por defecto
- Aplicar el mínimo privilegio en las credenciales y alcances otorgados al agente, nunca reutilizar un token de uso amplio
- Registrar y monitorear toda acción tomada por el agente, con alerta ante patrones de uso fuera de lo esperado
- Incluir al agente y sus integraciones en el alcance del pentest, probando prompt injection igual que se prueba cualquier otra superficie de entrada no confiable
Qué cambia esto para quien está evaluando contratar un pentest
Un agente de IA con acceso a una herramienta, un archivo o una API dejó de ser un experimento del equipo de producto y se convirtió en una superficie de ataque con el mismo peso que una API o una red interna. Si la empresa ya puso en producción un copiloto de código, un agente de atención o una automatización guiada por LLM, esa integración necesita entrar en el alcance de la próxima evaluación de seguridad, no como un ítem extra, como un ítem estándar.