Inyección de prompts: la vulnerabilidad que nadie corrige de raíz

Pasé dos décadas construyendo búsqueda enterprise. En ese tiempo aprendí una lección que la industria de agentes está reaprendiendo ahora, por las malas: todo sistema que procesa texto de fuentes no confiables y luego actúa en el mundo real es, por definición, una superficie de ataque. La búsqueda lee documentos y devuelve resultados. Un agente lee documentos, correos, páginas web — y ejecuta acciones. Esa diferencia es exactamente el tamaño del problema que estamos viviendo.

La inyección de prompts no es un bug que se resuelve con un parche. Es una consecuencia estructural de cómo funcionan los LLM: instrucción y dato viajan por el mismo canal, el texto. Un agente que lee un PDF malicioso, un correo envenenado o una página web comprometida puede recibir comandos escondidos ahí dentro y obedecerlos como si vinieran del usuario. No es teoría. Las cifras de 2026 muestran la escala real.

Lo que muestran las cifras de 2026

Los ataques de inyección de prompts crecieron +340% interanual, según OWASP en 2026. No es ruido estadístico — es el reflejo directo de cuántos agentes autónomos pasaron a operar en producción, con acceso a herramientas, correo, sistemas internos y credenciales.

El catálogo de incidentes reales es todavía más concreto: 520 casos de mal uso de herramientas y 450 de inyección de prompts registrados en 2026. Dentro de esa lista está un caso que debería estar en la agenda de todo comité de riesgo: el robo de 150GB de datos del gobierno mexicano, resultado directo de un agente manipulado mediante inyección de prompts. No fue una falla de contraseña débil. Fue un agente haciendo exactamente lo que un atacante pidió, a través de un canal que nadie vigilaba.

La infraestructura debajo del agente también es vulnerable

Mientras la capa de aplicación sufre inyección de prompts, la capa de infraestructura tiene sus propios boletines de guerra. Dos vulnerabilidades críticas relacionadas con agentes y el Model Context Protocol (MCP) llegaron al tope de la escala CVSS en 2026: la CVE-2026-25592, con CVSS 10.0, y la CVE-2025-6514, con CVSS 9.6, esta última permitiendo ejecución remota de código a través de servidores MCP comprometidos.

CVSS 10.0 es el techo de la escala. No existe “más crítico” que eso. Cuando dos fallas de este calibre aparecen en el mismo año, en la misma categoría de tecnología — infraestructura de agentes — el mensaje es claro: la carrera por poner agentes en producción está dejando la seguridad para después. Y “después” está costando 150GB de datos de un gobierno entero.

Por qué esto no se resuelve con otro firewall

El error común es tratar la inyección de prompts como un ítem más en una lista de seguridad perimetral. No lo es. Es un problema de arquitectura del propio agente: quién puede instruirlo, qué tiene permitido hacer sin confirmación humana, cómo se separa el comando del dato, y qué pasa cuando una herramienta MCP de terceros queda comprometida. Eso se diseña antes de que el agente vaya a producción, no después del incidente.

En Arvor, cada agente que construimos — para clientes o para nuestros propios productos, como AMIGO — nace con esta pregunta sobre la mesa: ¿qué hace este agente si el texto que está leyendo es hostil? La seguridad no es una capa que se agrega al final. Es un requisito de diseño, igual que lo era en búsqueda enterprise cuando un índice mal configurado exponía los datos de toda una base de clientes.

Si tu empresa está poniendo agentes a redactar contenido, leer correo, tocar sistemas internos o tomar decisiones — y todavía no se hizo esa pregunta — vale la pena conversar. Es exactamente el tipo de arquitectura que diseñamos en la consultoría de Arvor. Y si el problema real es conocimiento disperso que necesita gobernanza y trazabilidad en vez de un agente suelto sin control, el camino es BRAIN MAKER.

La pregunta correcta no es si tu agente va a encontrar un prompt malicioso. Es qué hace cuando lo encuentre. Habla con nosotros.