Inyección indirecta de prompts en agentes de IA: riesgos reales en la web y plan de mitigación para equipos DevSecOps

Un nuevo análisis de Unit 42 confirma que la inyección indirecta de prompts ya se observa en ataques reales. Qué cambia para equipos de infraestructura, seguridad y plataforma, y cómo reducir riesgo sin frenar adopción de IA agente.

La conversación sobre seguridad en IA ya no está en fase teórica. En los últimos meses, muchas organizaciones empezaron a integrar agentes de IA en tareas operativas: resumir tickets, clasificar correos, analizar logs, validar contenido, apoyar soporte o automatizar acciones en navegadores. Ese avance trae productividad, pero también abre una superficie nueva: la inyección indirecta de prompts (Indirect Prompt Injection, IDPI).

Un reporte reciente de Unit 42 muestra señales claras de uso “in the wild”: actores que insertan instrucciones maliciosas ocultas dentro de páginas o contenidos que luego son procesados por modelos y agentes. La diferencia clave es que el atacante no necesita hablarle directamente al modelo: le alcanza con contaminar la fuente que el agente consume.

Qué es la inyección indirecta y por qué importa ahora

En una inyección directa, el atacante escribe un prompt malicioso en la interfaz del sistema. En la inyección indirecta, la orden está escondida en un HTML, un documento, un comentario, metadatos o incluso en elementos visuales diseñados para no ser evidentes para humanos. Cuando el agente ingiere ese contenido para resumir, clasificar o decidir, puede interpretar esas instrucciones como válidas.

Esto crece en paralelo con la adopción de agentes con mayor capacidad de acción: navegar, hacer clic, completar formularios, consultar APIs internas, ejecutar workflows o disparar integraciones. A mayor “agency”, mayor impacto potencial si un prompt inyectado logra alterar el comportamiento.

Lo más relevante del análisis de Unit 42

La investigación reporta múltiples técnicas observadas en escenarios reales para ocultar instrucciones, entre ellas:

• Texto invisible por CSS (opacidad, tamaño de fuente en cero, posiciones fuera de pantalla).
• Ofuscación en atributos HTML, fragmentos estructurados o contenido generado dinámicamente.
• Técnicas de ensamblado en runtime para evadir análisis estático.

Más importante que el “cómo” es el “para qué”. El informe categoriza intenciones de ataque que van desde manipulación de salida y sesgo de decisiones hasta casos de mayor impacto: desvío de transacciones, fuga de información sensible, filtrado de prompts de sistema y escenarios de denegación de servicio en cadenas automatizadas.

En términos operativos, esto confirma una transición: de pruebas de concepto académicas a intentos de explotación con objetivos económicos y de evasión de controles.

Por qué el problema afecta a SysAdmin, DevOps y Seguridad

En muchos entornos, los agentes ya están conectados a sistemas críticos: repositorios, CI/CD, tableros de observabilidad, correo corporativo, bases documentales y herramientas de gestión. Aunque la integración sea parcial, una orden maliciosa puede:

• alterar prioridades de triage o clasificación de incidentes;
• inducir respuestas equivocadas en soporte y operaciones;
• forzar acciones no previstas en sistemas conectados;
• exponer datos internos por “resumen” o “extracción” fuera de política.

OWASP lo viene destacando en su Top 10 para LLM Applications: la inyección de prompts se mantiene como riesgo principal porque rompe supuestos de confianza entre instrucciones de sistema, entradas de usuario y contenido externo.

Qué cambia en el diseño de arquitectura

El aprendizaje central para equipos de plataforma es simple: el contenido externo debe tratarse como no confiable por defecto, incluso cuando el origen parece legítimo. No alcanza con “prompt engineering”; hace falta arquitectura defensiva.

Un enfoque útil es separar en capas:

• Capa de ingestión: etiquetar contexto confiable/no confiable y aplicar sanitización.
• Capa de razonamiento: reforzar instrucciones de sistema, limitar herramientas y validar salidas.
• Capa de ejecución: requerir confirmación humana para acciones de alto impacto.

Este patrón coincide con recomendaciones de OWASP y con marcos de gestión de riesgo como NIST AI RMF: gobernar capacidad, contexto y consecuencias, no solo precisión del modelo.

Controles técnicos recomendados (prioridad 30-60 días)

Para equipos que ya usan agentes en procesos reales, este plan mínimo reduce exposición de forma tangible:

1. Separación de contexto: marcar todo dato web/documental como untrusted y evitar mezclarlo sin delimitación con instrucciones de sistema.
2. Menor privilegio efectivo: tokens dedicados por herramienta, permisos acotados por tarea y caducidad corta de credenciales.
3. Validación determinística de salida: reglas fuera del modelo para aceptar/rechazar acciones (allowlists, esquemas, políticas).
4. Human-in-the-loop para acciones críticas: pagos, cambios de configuración, envío de correos externos, modificaciones en producción.
5. Monitoreo específico de IA agente: telemetría de prompts, herramientas invocadas, decisiones y desvíos respecto de baseline.
6. Red teaming continuo: pruebas de inyección indirecta en escenarios reales de negocio, no solo tests de laboratorio.

Indicadores de madurez para dirección técnica

Una organización puede considerar que está avanzando bien cuando logra responder “sí” a estas preguntas:

• ¿Tenemos inventario de agentes, conectores y permisos por entorno?
• ¿Podemos bloquear automáticamente salidas que no cumplen políticas?
• ¿Existe trazabilidad completa entre entrada no confiable y acción ejecutada?
• ¿Contamos con playbooks de incidente específicos para abuso de agentes?

Si la respuesta es “no” en dos o más puntos, el riesgo de impacto operativo es alto aun con modelos de última generación.

Conclusión

La inyección indirecta de prompts dejó de ser una curiosidad de laboratorio. Con agentes cada vez más integrados al trabajo diario, la seguridad debe moverse desde el “modelo correcto” hacia el “sistema seguro”.

El mensaje para equipos SysAdmin/DevOps/Seguridad es sobrio: seguir adoptando IA, pero con controles de ejecución, segmentación de contexto, menor privilegio y verificación humana en acciones sensibles. La productividad no necesita frenarse; necesita guardrails medibles.

Acciones recomendadas para esta semana: mapear agentes y permisos, activar validación de salida en workflows críticos, y correr una prueba de inyección indirecta sobre un caso de uso real de alto impacto.

---

Fuentes consultadas: Unit 42 (detecciones en campo de IDPI), OWASP GenAI Security Project (LLM01 Prompt Injection y Top 10), Anthropic Research (mitigaciones en uso de navegador), NIST AI RMF (gobernanza y gestión de riesgo en IA).