Threat modeling para AI generativa y agentic
Resumen
Microsoft explica que el threat modeling para IA generativa y sistemas agentic debe evolucionar porque estos modelos no son deterministas, son vulnerables a la manipulación mediante prompt injection y amplían la superficie de ataque al usar herramientas, memoria y APIs. Esto importa porque los equipos de seguridad ya no pueden evaluar solo fallos tradicionales: deben anticipar comportamientos probabilísticos y daños de alto impacto que pueden propagarse rápidamente entre componentes y afectar directamente a las personas.
Introducción: por qué esto importa
El threat modeling ayuda a los equipos a identificar lo que puede salir mal de forma temprana—antes de que ocurran fallos en el mundo real o exploits adversariales. Microsoft señala que las aplicaciones de AI (especialmente los sistemas generativos y agentic) rompen muchas suposiciones del software tradicional y determinista, por lo que los equipos de seguridad deben adaptar su enfoque de threat modeling para contemplar salidas probabilísticas, superficies de ataque ampliadas y daños centrados en las personas.
Qué hay de nuevo: cómo la AI cambia el panorama de amenazas
Microsoft destaca tres características que cambian fundamentalmente el threat modeling para AI:
- No determinismo: la misma entrada puede producir salidas diferentes entre ejecuciones, lo que exige analizar rangos de comportamiento probable—incluidos resultados raros pero de alto impacto.
- Sesgo de seguimiento de instrucciones: los modelos están optimizados para ser útiles, lo que los hace más susceptibles a prompt injection, coerción y manipulación—especialmente cuando los datos y las instrucciones comparten el mismo canal de entrada.
- Expansión del sistema mediante tools y memory: los sistemas agentic pueden llamar APIs, conservar estado y activar workflows de forma autónoma. Cuando algo sale mal, los fallos pueden acumularse rápidamente entre componentes.
Estas propiedades transforman riesgos conocidos en nuevas formas, incluidas:
- Prompt injection directo e indirecto (incluido a través de contenido externo que el modelo recupera)
- Uso indebido de tools y escalada de privilegios mediante chaining
- Exfiltración silenciosa de datos (salidas o llamadas a tools que filtran información sensible)
- Salidas con errores pero expresadas con confianza que se tratan como hechos
- Daños centrados en las personas como erosión de la confianza, dependencia excesiva, refuerzo de sesgos y desinformación persuasiva
Threat model a partir de los assets, no de los ataques
Una recomendación clave es comenzar definiendo explícitamente qué estás protegiendo—porque los assets de AI van más allá de bases de datos y credenciales. Los assets comunes específicos de AI incluyen:
- Seguridad del usuario (especialmente cuando la guía de la AI influye en acciones)
- Confianza del usuario en las salidas y el comportamiento
- Privacidad/seguridad de datos sensibles del negocio y de los usuarios
- Integridad de prompts, instrucciones y datos contextuales
- Integridad de las acciones del agent y de los efectos downstream
Este enfoque primero en assets también obliga a tomar decisiones de política desde el inicio: ¿Qué acciones no debería tomar nunca el sistema? Algunos resultados pueden ser inaceptables independientemente del beneficio.
Modela el sistema que realmente construiste
Microsoft subraya que el threat modeling para AI debe reflejar la operación real, no diagramas idealizados. Presta especial atención a:
- Cómo interactúan realmente los usuarios con el sistema
- Cómo se ensamblan y transforman los prompts, la memory y el contexto
- Qué fuentes externas se ingieren y qué suposiciones de confianza existen
- Qué tools/APIs puede invocar el sistema (y con qué permisos)
- Si las acciones son reactivas o autónomas, y dónde se aplica la aprobación humana
En los sistemas de AI, el prompt assembly pipeline se convierte en un boundary de seguridad de primera clase—la recuperación de contexto, la transformación, la persistencia y la reutilización son donde se acumulan suposiciones de confianza “silenciosas”.
Impacto en administradores de IT y responsables de plataforma
Para administradores que despliegan soluciones de AI (aplicaciones personalizadas, Copilots o workflows agentic), esta guía refuerza que los controles deben cubrir:
- Todo el recorrido data-to-prompt-to-action (no solo el hosting del modelo)
- Permisos y guardrails para el acceso a tools y automatizaciones downstream
- Monitorización operativa de salidas inesperadas, llamadas inusuales a tools y patrones de exfiltración
Acciones / próximos pasos
- Inventaria los assets de AI: incluye confianza, seguridad e integridad de instrucciones/contexto.
- Mapea el prompt pipeline de extremo a extremo: fuentes, recuperación, transformación, memory y reutilización.
- Restringe permisos de tools y exige aprobación humana para acciones de alto impacto.
- Prueba inyección y mal uso: incluye prompt injection indirecto a través de contenido recuperado.
- Planifica para accidentes: mitiga la dependencia excesiva con señales de UX, pasos de validación y rutas de escalamiento.
¿Necesita ayuda con Security?
Nuestros expertos pueden ayudarle a implementar y optimizar sus soluciones Microsoft.
Hablar con un expertoManténgase actualizado sobre tecnologías Microsoft