Prompt Injection: la vulnerabilidad no resuelta en el núcleo de toda aplicación LLM

Todo ingeniero conoce la SQL injection: una entrada no confiable se interpreta como un comando. Lo resolvimos hace décadas con consultas parametrizadas — un límite duro entre código y datos. Prompt injection es la misma idea aplicada a los LLM, con una diferencia brutal: no existe una consulta parametrizada para el lenguaje natural. Para un modelo, todo son tokens. El system prompt, la pregunta del usuario y el contenido de un PDF que se le pidió resumir llegan todos por el mismo canal — y el modelo no tiene una forma confiable de saber qué partes son instrucciones y cuáles son datos. Eso no es un fallo de ningún modelo en particular. Es una propiedad estructural de la arquitectura, y por eso OpenAI, Anthropic y todos los proveedores de seguridad siguen clasificando el prompt injection como un problema de frontera sin resolver.

Injection directa vs. indirecta

La injection directa es el clásico truco de "ignora las instrucciones anteriores" escrito directamente en un chatbot. Molesto, pero contenido — el atacante suele comprometer únicamente su propia sesión. La injection indirecta es donde reside el riesgo real. Las instrucciones maliciosas llegan a través de contenido que el modelo procesa en nombre de otra persona: una página web que un agente navega, un documento en tu pipeline de RAG, un correo electrónico, un issue de GitHub, una invitación de calendario. La víctima nunca escribe nada malicioso — simplemente le pide a su asistente que "resuma este ticket", y el ticket contiene instrucciones ocultas que el modelo obedece diligentemente. Entre 2024 y 2026 esto pasó de demostraciones de investigación a incidentes en producción: ataques documentados contra Slack AI, Microsoft 365 Copilot, Cursor y las integraciones MCP de GitHub siguieron todos este patrón. Para 2026, los informes de exploits de OWASP muestran herramientas organizadas — decenas de familias de payloads y técnicas de entrega distintas en uso activo — en lugar de experimentos aislados.

La trifecta letal

Simon Willison acuñó la forma más clara de razonar sobre este riesgo. Un sistema de IA se vuelve peligrosamente explotable cuando combina tres elementos:

1. Acceso a datos privados — tus documentos, base de datos, código fuente, bandeja de entrada
2. Exposición a contenido no confiable — cualquier cosa que un atacante pueda influenciar: páginas web, correos, tickets, READMEs de paquetes
3. La capacidad de comunicarse externamente — enviar solicitudes, correos, commits o llamadas a herramientas que salen del perímetro

Dos cualesquiera de estos son sobrevivibles. Los tres juntos significan que un atacante que controle un solo fragmento de contenido que tu agente lea puede potencialmente exfiltrar todo lo que el agente pueda ver. Casi todos los incidentes importantes de los últimos dos años encajan exactamente en esta combinación. Esto también explica por qué la era agéntica empeoró las cosas. Un chatbot de 2023 que cae en una injection dice algo vergonzoso. Un agente de 2026 con acceso a bases de datos, una shell y una herramienta de correo hace algo irreversible. Lo que está en juego pasó de las palabras a las acciones — por eso, en mayo de 2026, las agencias del Five Eyes (CISA, la NSA y sus homólogas del Reino Unido, Canadá, Australia y Nueva Zelanda) emitieron una guía conjunta sobre IA agéntica, señalando al prompt injection como un vector de manipulación central y afirmando claramente que ninguna salvaguarda por sí sola es suficiente.

Por qué no basta con filtrarlo

La solución instintiva — "detectar y bloquear prompts maliciosos" — no se sostiene. Las injections se pueden parafrasear infinitamente, codificar, dividir entre documentos, ocultar en texto blanco sobre fondo blanco o en metadatos de imágenes. Incluso los enfoques de detección publicados más sólidos pasan por alto una fracción considerable de los ataques basados en optimización, y un atacante solo necesita un éxito. Los modelos guardrail ayudan como una capa; fallan como fundamento. La postura de ingeniería honesta es: asumir que la injection tendrá éxito y diseñar de forma que una injection exitosa no pueda causar un daño serio.

Defensa en profundidad que realmente funciona

• Romper la trifecta. La medida individual de mayor impacto. Si un agente lee contenido no confiable, córtale la salida (egress) o el acceso a secretos. Diseña cada agente para que tenga como máximo dos de las tres propiedades.
• Herramientas de mínimo privilegio. Limita cada herramienta al conjunto de acciones más estrecho posible. Solo lectura cuando sea posible. Sin credenciales de producción al alcance del agente.
• Tratar la salida del modelo como entrada no confiable. Nunca la envíes directamente a una shell, SQL o una llamada a una API sin validación — la injection convierte al modelo en el proxy del atacante.
• Confirmación humana para acciones irreversibles. Pagos, eliminaciones, correos a direcciones externas, despliegues a producción.
• Sandboxing y aislamiento. Ejecución de código en contenedores con egress restringido; aislamiento por sesión para que un documento envenenado no contamine a otros usuarios.
• Registrar todo. Telemetría completa de prompts y llamadas a herramientas en tu SIEM. Los intentos de injection son una señal de ataque sobre la que deberías generar alertas, no algo que descubras semanas después.

Si ejecutas modelos en tu propia infraestructura, estos controles se suman a la línea base de hardening que cubrimos en Seguridad de los LLM autoalojados — la injection es la amenaza a nivel de comportamiento que persiste incluso cuando tu red y tu cadena de suministro están limpias.

Conclusión

Prompt injection no es una vulnerabilidad que se parchea; es una propiedad en torno a la cual se diseña la arquitectura. Los equipos que están acertando en esto en 2026 no son los que tienen el filtro más inteligente — son los que asumieron el compromiso y redujeron el radio de impacto: privilegios mínimos, trifectas rotas, salidas validadas y un humano en el bucle donde realmente importa. En NextVector aplicamos a los sistemas de IA la misma ingeniería centrada en la seguridad que aportamos a la infraestructura de pagos y blockchain. ¿Estás construyendo una función con LLM que toca datos reales? Contáctanos.