La semana pasada, en Infosecurity Europe 2026, Ariel Fogel de OWASP repitió lo que muchos en el sector ya sospechábamos: la inyección de prompts no es un fallo puntual que se arregle con el próximo parche. Es un problema de arquitectura. Y mientras tanto, las empresas siguen desplegando agentes con acceso a herramientas, repositorios y paneles de administración como si fueran un plugin más de WordPress.
Yo llevo meses viendo cómo clientes y colegas quieren «un agente que gestione la web», «un bot que publique en el CMS» o «un asistente que revise el código del proyecto». Suena bien en una demo. En producción, según los datos que está recogiendo OWASP y varios estudios publicados en junio, suena a incidente esperando a ocurrir.
El informe de Help Net Security sobre el estado de seguridad de la IA agéntica de OWASP (versión 2.01) ya no habla de amenazas teóricas. Habla de CVEs, avisos de fabricantes e incidentes reales. De 53 proyectos agénticos que siguen, 28 son agentes de código. Claude Code, Gemini CLI, Codex, Cline, Aider: todas las herramientas que más crecen son las que más superficie de ataque abren. Y aquí viene lo que me preocupa de verdad: no es que la IA escriba mal un párrafo. Es que un atacante pueda colar instrucciones en una reseña, un ticket de soporte o un README y convertir tu agente en un ejecutor de comandos con permisos reales.
Fogel lo explicó con claridad en Infosecurity Magazine: los modelos procesan todo como una secuencia de tokens. No hay frontera fiable entre lo que tú defines como sistema, lo que escribe el usuario y lo que el agente recupera de fuentes externas. Cuando ese agente tiene herramientas —git, shell, APIs, base de datos— la inyección deja de ser un texto gracioso y pasa a ser compromiso activo.
Los números de un estudio reciente recogido por CSO Online no dejan lugar a optimismo barato. En 3.168 ejecuciones adversariales sobre agentes web con GPT-5 y Gemini, ningún escenario bloqueó de forma consistente todos los ataques. Las inyecciones indirectas —instrucciones ocultas en contenido web normal— tuvieron tasas de éxito del 41,67% al 68,16%. Las directas superaron el 79%. Cambiar de modelo no arregla el problema: empeora o mejora según cómo esté montada la arquitectura del agente, no según la etiqueta del LLM.
¿Y qué hace el mercado? Desplegar más rápido. El propio Fogel lo dijo: «La mayoría de organizaciones despliegan agentes más rápido de lo que pueden gobernarlos». En mi experiencia con pymes y agencias, la frase se traduce así: alguien conecta un agente al hosting, le da acceso FTP o a la API de WordPress, y nadie ha definido qué puede hacer si alguien le inyecta «borra todos los posts» disfrazado de metadatos de una imagen.
WeLiveSecurity resume cinco desafíos de la IA generativa para las empresas, y todos convergen en lo mismo: datos, identidad, cumplimiento normativo y falta de visibilidad. Pero el que más me resuena cuando hablas con equipos técnicos pequeños es el de la cadena de suministro. OWASP documenta casos como CVE-2026-22708 en Cursor, donde un allowlist de comandos «seguros» acabó facilitando el ataque porque el sistema auto-aprobaba justo lo que el atacante necesitaba. O el caso de paquetes en PyPI comprometidos tras robar tokens de CI. No hace falta ser una multinacional para quedar expuesto: basta con un plugin mal configurado, un workflow de GitHub Actions permisivo o un agente con credenciales persistentes.
Lo irónico es que las respuestas que escucho en reuniones comerciales siguen siendo las de siempre: «ponemos guardrails», «usamos un modelo más seguro», «limitamos los prompts del usuario». NIST ya ha demostrado matemáticamente que ningún conjunto finito de guardrails es robusto contra adversarios adaptativos — y en ticweb lo comentamos hace poco. Fogel apunta en otra dirección, y creo que es la única sensata: asumir que la inyección va a ocurrir y limitar el daño. Monitorización en tiempo real, contención automática, credenciales efímeras, aprobación humana en acciones de riesgo, auditoría centralizada. No suena tan vendible como «IA autónoma que trabaja sola», pero es lo que separa una demo de un despliegue responsable.
Si gestionas webs, hosting o desarrollo para clientes, el mensaje práctico es incómodo. No metas un agente con permisos de escritura en producción porque el competidor ya lo hace. Separa entornos. Trata cada agente como una identidad no humana con privilegios mínimos. Y sobre todo, no confundas la productividad de un coding assistant en local con la seguridad de un agente conectado a tu infraestructura. Son categorías distintas en el informe OWASP, pero en la cabeza del cliente se mezclan en un solo «la IA nos ayuda».
El reloj regulatorio tampoco ayuda a pensar con calma. DORA pide notificación en cuatro horas para incidentes graves; NIS2, aviso en 24. Desplegar agentes sin playbook de respuesta no es innovación: es acumular deuda que algún día tendrás que pagar con prisas.
Me gustaría equivocarme. Me gustaría que el próximo modelo «solucione» la inyección de prompts y que todo esto quede en una anécdota de 2026. Pero los datos de junio apuntan otra cosa: el problema es estructural, los agentes amplifican el impacto y el mercado sigue vendiendo velocidad mientras OWASP cataloga brechas reales. Si mañana un cliente te pidiera conectar un agente de IA a tu panel de Plesk con permisos para crear sitios y gestionar DNS, pero sin presupuesto para monitorización ni revisión de cada acción automática, ¿le dirías que sí para no perder el proyecto o le explicarías que está comprando un incidente con descuento?
Fuentes
- Prompt injection still drives most agentic AI security failures in production – Help Net Security
- Prompt Injection Remains Unsolved, OWASP Researcher Warns – Infosecurity Magazine
- Prompt injection breaks today’s AI agents, study warns – CSO Online
- 5 principales desafíos que impone la inteligencia artificial generativa – WeLiveSecurity