Del prompt a la pull request: threat modeling para código escrito por agentes de IA
Un agente de codificación puede transformar una issue en una pull request creíble: lee el repositorio, propone un plan, modifica archivos, actualiza pruebas y prepara un diff listo para revisión. El riesgo concreto es que el equipo evalúe solo si la funcionalidad funciona, sin preguntarse si el prompt inicial describía realmente los datos, roles, posibles abusos, límites de confianza (trust boundaries) e impacto en producción.
El threat modeling (modelado de amenazas) sirve precisamente en este paso: no como un ejercicio burocrático, sino como un método ligero para entender qué está cambiando, qué puede salir mal, qué controles se necesitan y si la verificación realizada es suficiente antes de hacer merge, deploy o go-live.
Para CTOs, tech leads y security champions, la pregunta no es “¿podemos usar agentes de IA para escribir código?”. La pregunta útil es: ¿cómo transformamos el prompt, el plan del agente y la pull request en una decisión de riesgo trazable?
Por qué el threat modeling cambia con el código escrito por agentes de IA
En el threat modeling de aplicaciones tradicional, se parte de funcionalidades, activos, actores, flujos de datos y límites de confianza. Con el código escrito por agentes de IA, es necesario añadir un nivel: el camino que lleva desde el prompt hasta el diff.
Una solicitud como “añadir invitaciones al equipo” puede generar modelo de datos, API, correos, tokens temporales, roles, páginas de administración, pruebas, variables de entorno y una migración. Cada pieza introduce amenazas diferentes: invitaciones reutilizables, tokens demasiado largos en los logs, roles aplicados solo en el frontend, endpoints no protegidos, aislamiento de inquilinos (tenant isolation) incompleto, suplantación de identidad (spoofing) por correo, dependencias añadidas sin revisión. El prompt rara vez contiene todo esto, porque el agente llena los vacíos con convenciones plausibles. El threat modeling sirve para hacer explícitos esos vacíos antes de que se conviertan en código aceptado.
Las cuatro preguntas a aplicar a cada PR generada por IA
OWASP resume el threat modeling en cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué haremos para gestionarlo y si hemos hecho lo suficiente. En el contexto de codificación con IA, estas preguntas deben aplicarse al prompt, al plan, al diff y al entorno de ejecución.
| Pregunta | En el flujo de trabajo con agentes de IA significa |
|---|---|
| ¿Qué estamos construyendo? | Qué tarea recibió el agente, qué archivos modificó, qué datos y sistemas toca |
| ¿Qué puede salir mal? | Qué abusos se vuelven posibles en roles, datos, API, herramientas, pipelines y superficies expuestas |
| ¿Qué hacemos? | Qué controles entran en el código, pruebas, configuración, revisión, pipeline o proceso |
| ¿Hemos hecho lo suficiente? | Qué evidencias bloquean el merge, qué riesgos se aceptan y quién los gobierna |
Esta estructura evita dos errores frecuentes: tratar el threat modeling como una reunión abstracta o reducirlo a una lista de verificación genérica de vulnerabilidades.
Partir de activos, datos y actores reales
El primer paso no es leer el diff línea por línea, sino entender qué activos entran en el perímetro de la modificación: datos personales, documentos de clientes, pagos, roles administrativos, tokens, API internas, webhooks, repositorios, pipelines, logs, almacenamiento, bases de datos y servicios en la nube.
Luego se necesitan los actores. No basta con distinguir entre “usuario” y “admin”: en una funcionalidad real pueden existir usuario invitado, usuario suspendido, propietario, admin parcial, cuenta de servicio, integración externa, miembro de otro inquilino, cliente desactivado, operador de soporte, trabajo programado y atacante anónimo. Una matriz mínima actor-acción-recurso ayuda mucho más que una revisión genérica. Para cada rol hay que preguntarse: ¿qué recursos puede leer, crear, modificar, borrar o exportar? ¿El backend lo verifica realmente, o el agente implementó el control solo en la interfaz?
Dibujar el flujo de datos, incluso de forma ligera
El modelo de amenazas no tiene por qué producir un diagrama perfecto, pero debe hacer visibles los flujos de datos, almacenes de datos, procesos, entidades externas y límites de confianza. Si una PR atraviesa frontend, rutas de API, base de datos, almacenamiento de objetos, proveedor de correo, webhooks y pipeline de despliegue, el riesgo no está en el mismo punto para todos los componentes.
Con el código generado por IA, el flujo de datos debe incluir también elementos a menudo olvidados: prompt del agente, historial de chat, salida de herramientas, logs de compilación, variables de entorno, gestor de secretos, fixtures de prueba, semillas (seeds), snapshots y artefactos de despliegue. Un secreto copiado en el prompt o en un log no siempre aparece en el diff final, pero puede requerir rotación.
El límite más importante es donde una entrada no confiable entra en un componente confiable. Un valor proveniente de un formulario, ticket, documento, webhook, archivo cargado, salida de LLM o herramienta externa debe ser validado antes de convertirse en consulta, comando, autorización, correo, decisión o acción posterior.
Escribir casos de abuso, no solo historias de usuario
Las historias de usuario describen el uso previsto; los casos de abuso describen qué puede hacer un usuario, un inquilino, una integración o un contenido malicioso cuando el sistema se usa fuera de secuencia. Algunos ejemplos útiles para una PR generada por IA:
- Un usuario cambia el ID en la URL y lee un registro de otro inquilino.
- Una invitación caducada se reutiliza para obtener acceso.
- Un webhook se repite o se firma con una clave incorrecta.
- Un rol de solo lectura llama directamente a la API de modificación.
- Un archivo cargado contiene una carga útil (payload) que termina en HTML, analizadores o almacenamiento.
- Una inyección de prompt en un ticket induce al agente a modificar una política o usar una herramienta.
- Una migración expone datos de prueba o campos sensibles en producción.
STRIDE sigue siendo útil como estímulo —suplantación, manipulación, repudio, divulgación de información, denegación de servicio, elevación de privilegios— pero en el código generado por IA debe vincularse a casos concretos, no usarse como un acrónimo decorativo.
Evaluar el plan del agente antes del diff
Muchos equipos comienzan la revisión cuando la pull request está lista. Con agentes de IA conviene anticiparse: si el agente propone un plan que toca autenticación, roles, datos, nube, CI/CD, secretos o dependencias, el modelo de amenazas debe comenzar antes de que el diff se vuelva grande.
El plan del agente debe leerse con preguntas precisas: ¿está creando nuevos endpoints o exponiendo rutas inexistentes? ¿Está cambiando middleware, políticas, comprobaciones de permisos o roles? ¿Está añadiendo dependencias, scripts, flujos de trabajo o comandos de despliegue? ¿Está modificando pruebas para confirmar su propia implementación? ¿Está asumiendo que un control del lado del cliente es suficiente? ¿Está usando datos reales, logs o secretos para completar la tarea? Si la respuesta es sí a cualquiera de estas preguntas, la PR debe dividirse o marcarse como de alto riesgo, porque una revisión eficaz no puede tratar de la misma manera una corrección de texto y una modificación que atraviesa autorizaciones, bases de datos y pipelines.
Conectar amenazas, controles y pruebas
Un modelo de amenazas útil produce controles verificables. Si la amenaza es “usuario del inquilino A lee datos del inquilino B”, el control no es “gestionar autorizaciones”: es una política del lado del servidor, una consulta filtrada por inquilino, pruebas con dos inquilinos distintos, logs de acceso denegado y revisión del middleware.
Si la amenaza es “token de invitación reutilizable”, los controles pueden incluir caducidad, uso único, vinculación a correo o inquilino, hashing del token en reposo, limitación de tasa (rate limit) y logs de auditoría. Si la amenaza es “inyección de prompt a través de ticket”, los controles son la separación entre datos e instrucciones, confirmación humana para herramientas sensibles, lista blanca de acciones y pruebas con contenido hostil.
Los escáneres y las pruebas automáticas ayudan, pero no demuestran por sí solos que la lógica de negocio, el aislamiento de inquilinos, las autorizaciones y los límites de confianza sean correctos en el contexto real.
Definir qué bloquea el merge y el go-live
El threat modeling no debe concluir con “hemos hablado de los riesgos”: debe producir decisiones. Bloquean el merge o el go-live las evidencias que exponen datos, permiten escalada de privilegios, evaden autorizaciones, revelan secretos, hacen públicos almacenamientos o bases de datos, debilitan pipelines, desactivan controles de seguridad o introducen dependencias críticas no evaluadas.
Otros puntos pueden convertirse en remediación planificada, pero solo con responsables, fechas y riesgo residual claros. Mejorar el registro de logs, añadir alertas, reforzar la documentación o hacer más granular la matriz de roles puede planificarse; aceptar un control de acceso incierto antes del go-live, no.
Checklist de threat modeling para PR generadas por IA
- Identifica el prompt/tarea original, el agente o herramienta utilizada y las partes generadas o modificadas.
- Enumera activos, datos reales, roles, inquilinos, sistemas externos y secretos tocados.
- Dibuja un flujo de datos mínimo con límites de confianza, procesos, almacenes de datos y entidades externas.
- Escribe casos de abuso específicos de la funcionalidad, no solo vulnerabilidades genéricas.
- Verifica las autorizaciones a nivel de objeto y el aislamiento de inquilinos con diferentes usuarios.
- Comprueba si la PR modifica middleware, políticas, roles, callbacks, redirecciones, CORS o sesiones.
- Separa la revisión del código, la revisión del pipeline, la revisión de dependencias y la revisión de pruebas.
- Busca secretos en prompts, logs, repositorios, builds, flujos de trabajo y configuraciones.
- Exige pruebas negativas derivadas de las amenazas, no solo pruebas sobre el camino feliz (happy path).
- Documenta qué bloquea el merge, qué bloquea el go-live y qué queda como riesgo aceptado.
Cómo integrar el método en el ciclo de desarrollo
El threat modeling para codificación con IA debe ser ligero y repetible. No hace falta una sesión larga para cada commit, pero se necesitan umbrales claros: una PR que toca texto o diseño puede seguir el flujo normal, mientras que una PR que toca autenticación, datos, API, pagos, nube, CI/CD, secretos, roles o herramientas de agentes debe activar un control más riguroso.
En el proceso práctico, la tarea debería incluir restricciones de seguridad; el plan del agente debería aprobarse cuando toca áreas sensibles; la PR debería ser pequeña; las pruebas deberían cubrir casos de abuso; la revisión debería tener responsables técnicos; la decisión final debería dejar rastro. Cuando el uso de agentes de IA se vuelve continuo, esto se convierte en un tema de Software Assurance Lifecycle: reglas de desarrollo, protección de ramas, puertas de seguridad, propiedad, evidencias, remediación y controles recurrentes.
Cuándo involucrar una verificación independiente
Una verificación interna puede ser suficiente para modificaciones aisladas, sin datos reales, sin roles, sin API expuestas y con revisores expertos. En cambio, se necesita una verificación independiente cuando el código generado o modificado por IA entra en un producto utilizado por clientes, empleados o socios, o cuando la PR toca autorizaciones, datos, pipelines, nube, pagos, secretos o lógica crítica.
| Escenario | Riesgo principal | Control recomendado |
|---|---|---|
| PR generada por IA sobre auth, roles, API, consultas, secretos o dependencias | Vulnerabilidades o regresiones en el código | Code Review |
| Adopción continua de agentes de codificación en el ciclo de ingeniería | Controles no repetibles en tareas, PR y lanzamientos | Software Assurance Lifecycle |
| Decisión sobre go-live, riesgo residual, impactos de negocio o cumplimiento | Riesgo no priorizado o aceptado sin responsable | Risk Assessment |
| Arquitectura, flujos de datos, límites de confianza e integraciones complejas | Suposiciones de diseño débiles | Secure Architecture Review |
| App o API ya expuestas a usuarios y clientes | Comportamiento abusable desde el exterior | Web Application Penetration Testing |
La elección no debe ser un paquete estándar. Si el riesgo está en el diff, se necesita Code Review. Si el riesgo está en el proceso de adopción de los agentes, se necesita Software Assurance Lifecycle. Si el equipo debe decidir sobre riesgo residual, prioridades e impacto, se necesita Risk Assessment. Si la modificación atraviesa arquitectura, flujos de datos e integraciones, se necesita una revisión del diseño.
Evidencias a preparar
Para hacer efectiva la verificación se necesitan repositorios, pull requests, descripción de la tarea, prompt o issue de partida, lista de agentes o herramientas utilizadas, partes generadas o modificadas, roles de la aplicación, esquema de datos, API expuestas, integraciones, flujos de trabajo CI/CD, variables de entorno, dependencias principales y entornos disponibles.
También son útiles las evidencias de proceso: quién aprobó el plan del agente, quién revisó el diff, qué pruebas se añadieron, qué amenazas se consideraron, qué riesgos se aceptaron y qué remediaciones se planificaron. Esta información evita una revisión a ciegas, porque el código no siempre cuenta por qué se tomó una decisión, qué suposiciones hizo el agente o qué riesgo pensaba aceptar el equipo.
Preguntas frecuentes
- ¿El threat modeling sirve también para una sola PR generada por IA?
- Sí, si la PR toca datos, roles, API, secretos, pagos, pipelines, nube o lógica de negocio. Para modificaciones pequeñas basta un modelo de amenazas ligero, pero las preguntas sobre activos, actores, flujos y abuso siguen siendo útiles.
- ¿El threat modeling y la Code Review son lo mismo?
- No. El threat modeling define qué puede salir mal y qué controles se necesitan. La Code Review verifica si el código, el diff y las pruebas implementan esos controles sin regresiones.
- ¿STRIDE es suficiente para el código generado por IA?
- STRIDE es útil para no olvidar familias de amenazas, pero debe adaptarse a prompts, agentes, repositorios, pipelines, llamadas a herramientas, secretos y datos en tiempo de ejecución. La parte importante es transformar cada amenaza en un control verificable.
- ¿Las pruebas automáticas generadas por la IA son suficientes?
- No. Las pruebas generadas por la IA tienden a cubrir el camino previsto. Se necesitan también pruebas negativas, casos multiusuario, abuso de roles, aislamiento de inquilinos, entradas manipuladas y verificaciones en pipelines y configuraciones.
- ¿Cuándo se necesita un Risk Assessment?
- Cuando el equipo debe decidir si aceptar un riesgo, priorizar la remediación o vincular el proyecto a impactos empresariales, datos personales, cumplimiento, proveedores o continuidad operativa.
[Callforaction-SAL-Footer]