Del prompt injection al movimiento lateral entre agentes

El prompt injection es, probablemente, el riesgo más malinterpretado de la seguridad de IA. Muchos equipos aún lo tratan como un bug que se corrige con un filtro. La realidad, reconocida cada vez más por la industria, es que se trata de una propiedad estructural de los modelos de lenguaje: dado que procesan las instrucciones del sistema y el contenido no confiable dentro de la misma ventana de contexto, no pueden distinguir de forma fiable una orden legítima de una maliciosa inyectada a través de un correo, un documento o una página web.

Por qué no se "parchea"

El cambio de mentalidad es claro: el problema no está solo en el modelo, sino también en la arquitectura de los frameworks de agentes. Los análisis de la industria documentan fallos en la "plomería" de frameworks populares (deserialización insegura, path traversal, SSRF) que amplifican el impacto de una inyección. Es decir: aunque se filtrara perfectamente la entrada, la superficie de riesgo seguiría existiendo en la infraestructura que rodea al modelo. El propio NIST plantea repensar la ciberseguridad para la era de la IA en sus directrices preliminares, que abordan tanto la protección de los sistemas de IA como la resiliencia ante ataques habilitados por IA.

De un agente comprometido al movimiento lateral

El salto peligroso ocurre cuando varios agentes colaboran. Si un agente A procesa contenido no confiable y pasa su salida a un agente B con más privilegios, una instrucción inyectada puede propagarse entre agentes, de forma análoga al movimiento lateral clásico dentro de una red. El Model Context Protocol (MCP), que estandariza cómo los agentes se conectan a herramientas y datos, facilitó enormemente la integración, pero sus primeras versiones adolecían de modelos de confianza implícita y falta de autenticación obligatoria. Las actualizaciones de la especificación en 2026 introducen consentimiento incremental de alcance, aunque muchos despliegues siguen expuestos.

El enfoque que funciona: contención, no prevención perfecta

Como la inyección no se puede eliminar por completo, el consenso de 2026 es diseñar para contener el daño. Las prácticas con mayor evidencia de efectividad son:

Mínimo privilegio por herramienta. Es la defensa más determinante. Acotar qué puede hacer cada agente reduce drásticamente el "radio de explosión" de un agente comprometido.

Human-in-the-loop. Las acciones de alto riesgo requieren aprobación humana antes de ejecutarse.

Sandboxing. Aislar los entornos de ejecución de herramientas limita hasta dónde puede llegar un abuso.

Patrón de doble LLM. Un modelo "en cuarentena" procesa la entrada no confiable y otro, privilegiado, solo actúa sobre datos ya saneados.

Validación de salida. Escanear las respuestas del agente en busca de datos sensibles o patrones anómalos antes de enviarlas a un destino externo.

El componente regulatorio

La entrada en vigor de obligaciones del Reglamento de IA de la Unión Europea (AI Act) en agosto de 2026 añade presión: su Artículo 15 exige que los sistemas de alto riesgo demuestren, con evidencia documentada, resistencia a la manipulación no autorizada. Registrar cada acción del agente y mantener una bitácora de invocaciones deja de ser una buena práctica para volverse un requisito de cumplimiento con sanciones significativas.

Qué recomendamos

Antes de escalar el uso de agentes, conviene mapear la "lethal trifecta" en cada flujo: ¿este agente tiene acceso a datos privados, recibe contenido no confiable y puede comunicarse hacia afuera a la vez? Donde coincidan las tres condiciones, hay que aplicar contención. En Ingenio 360 evaluamos estos escenarios usando marcos como OWASP GenAI y NIST AI RMF como referencia, siempre con autorización y alcance definido. La meta no es asustar, sino permitir que la IA se use con red de seguridad.