Revisada el 2026-10-09
La inyección de prompts es un ataque en el que un texto, escrito por el usuario o escondido en contenido externo, cambia lo que hace un modelo de lenguaje.1
Es el primer riesgo de la lista OWASP para aplicaciones con LLM (LLM01:2025) y no se conoce una defensa infalible.1 El motivo: el modelo no distingue con fiabilidad tus instrucciones de las que vienen dentro de una web o un correo.2 En un chat, el daño se queda en una respuesta mala; en un agente con herramientas, puede borrar, enviar o filtrar datos.
Cómo funciona
- Directa: el propio usuario escribe la orden que altera el comportamiento, a propósito o sin querer.1
- Indirecta: la orden viaja escondida en contenido que el modelo lee por ti, como una web, un archivo, un correo o el resultado de una herramienta. Puede ser invisible para una persona.13
- Jailbreak: inyección que busca saltarse las protecciones de seguridad del modelo. OWASP lo trata casi como sinónimo.1 Simon Willison, que dice haber acuñado «prompt injection» en 2022, insiste en que son problemas distintos y que confundirlos hace que se infravalore el riesgo.2
- RAG y fine-tuning no la eliminan.1
- Ejemplos de OWASP: una web con instrucciones ocultas que hacen que el modelo inserte una imagen cuya URL filtra la conversación, o un currículum con órdenes troceadas que fuerzan una recomendación positiva.1
- Ejemplo de Anthropic: en pruebas de Claude en Chrome, un correo que se hacía pasar por aviso de seguridad pidió borrar correos, y antes de las nuevas defensas Claude los borró sin pedir confirmación.4
La tríada letal
Willison resume cuándo un agente puede usarse para robar datos: cuando reúne a la vez tres capacidades.2
- Acceso a datos privados.
- Exposición a contenido no fiable, es decir, texto o imágenes que puede controlar un atacante.
- Una vía para comunicarse hacia fuera que sirva para sacar datos.
- Con las tres, basta un texto ajeno para que el agente lea tus datos y los envíe.2
- La defensa principal es no juntarlas nunca: quitar una de las tres.2
- MCP lo agrava, porque anima a mezclar herramientas de orígenes distintos, y a veces una sola herramienta reúne las tres.2
- Un filtro que detecta el 95 % de los ataques no basta: en seguridad, eso es suspender.2
Cómo se mitiga
OWASP propone:1
- Acotar el comportamiento del modelo con instrucciones de sistema y un alcance estrecho.
- Validar el formato de la salida con código determinista.
- Mínimo privilegio: que las funciones sensibles las controle el código, no el modelo.
- Aprobación humana para las acciones de alto riesgo.
- Separar y marcar como no fiable el contenido externo.
- Pruebas adversarias que traten al modelo como un usuario no fiable.
Anthropic añade, para quien construye con su API:3
- Meter el contenido de terceros solo en bloques
tool_result, nunca en el prompt de sistema. Claude está entrenado para desconfiar de las instrucciones que aparecen ahí. - Decir en el prompt de sistema que lo que devuelven las herramientas son datos, no órdenes, y envolverlo en JSON para que no pueda «escaparse».
- Filtrar las entradas y las salidas de herramientas con un modelo ligero antes de actuar.
- Mínimo privilegio, sandbox y pruebas con documentos y correos trampa.
En Claude Code, en modo manual, las acciones sensibles piden aprobación; curl y wget no se aprueban solos, y los comandos que no encajan en ninguna regla piden permiso. Al abrir una carpeta nueva aparece un diálogo de confianza, y los servidores de .mcp.json necesitan su propia aprobación.5 La propia documentación avisa de que ningún sistema es inmune.5
En Claude en Chrome, las mitigaciones bajaron la tasa de éxito de los ataques del 23,6 % al 11,2 % en modo autónomo, sobre 123 casos de prueba. Además, pide confirmación antes de publicar, comprar o compartir datos personales, y bloquea categorías de sitios de alto riesgo.4
Por qué importa
- Cuanto más puede hacer el agente (correo, navegador, archivos), más daño hace un texto ajeno. OWASP cita como impactos la filtración de datos sensibles, el acceso no autorizado a funciones y la ejecución de comandos en sistemas conectados.1
- La responsabilidad de revisar lo que propone el agente sigue siendo tuya.5
Cómo lo uso
- Según mi inventario de IA (2026-09-19), tengo operativos conectores de Gmail, Calendar, Drive, Notion y Chrome, entre otros (ver MCP).
- A mi entender, el conector de Gmail reúne por sí solo la tríada: lee datos privados, recibe correo de cualquiera y, tal como aparece en Claude Code, incluye herramientas para enviar y reenviar.
- Chrome suma navegar por webs arbitrarias: contenido no fiable con capacidad de actuar.
- Mis permisos globales de Claude Code llevan reglas de denegación para leer secretos y para algunos comandos destructivos o de red. Limitan el daño local, pero no lo que hagan los conectores.
- Pendiente, a mi entender: no combinar en una misma tarea leer correo entrante y enviar, y confirmar a mano cualquier envío.
Véase también
Referencias
Footnotes
-
LLM01:2025 Prompt Injection. OWASP Top 10 for LLM Applications 2025. Consultado el 2026-10-09. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
The lethal trifecta for AI agents: private data, untrusted content, and external communication. Simon Willison, 2025-06-16. Consultado el 2026-10-09. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Mitigate jailbreaks and prompt injections. Anthropic, documentación de la API. Consultado el 2026-10-09. ↩ ↩2
-
Piloting Claude in Chrome. Anthropic, 2025-08-25 (actualizado después). Consultado el 2026-10-09. ↩ ↩2
-
Security. Anthropic, documentación de Claude Code. Consultado el 2026-10-09. ↩ ↩2 ↩3