OWASP SAMM recibe la extensión Agentic SAMM para el desarrollo seguro con agentes de AI

Alrededor de OWASP SAMM ha surgido un nuevo proyecto draft llamado Agentic SAMM, o ASAMM — una extensión para equipos que construyen productos con agentes de IA y utilizan modelos en el desarrollo. Su objetivo es cerrar los riesgos que el SDLC seguro clásico ve mal: contexto malicioso, invocaciones de herramientas peligrosas y ventanas de autonomía demasiado largas.

Por qué el SAMM antiguo no es suficiente

El OWASP SAMM clásico funciona bien donde los principales objetos de protección son el código, la compilación, el lanzamiento y la infraestructura de entrega. Pero en sistemas de agentes, la superficie de ataque va más allá: en documentos, tareas en el rastreador, descripciones de herramientas, resultados de búsqueda web, logs de CI y cualquier otro contenido que el modelo lea como parte de su contexto de trabajo. Si este contexto influye en el comportamiento del agente, ya se convierte en parte del plano de control, no solo en datos de entrada.

Es por esto que el autor de ASAMM propone ver el desarrollo no como un ciclo cerrado, sino como una espiral. El equipo pasa nuevamente por diseño, implementación y revisión, pero en cada iteración cambian el sistema, las herramientas y las propias amenazas. En este esquema, ya no es suficiente verificar que al agente se le dieron permisos correctos. Incluso un agente completamente autorizado puede realizar una acción que no corresponde a la tarea original si el contexto o la lógica de delegación lo desvían.

Qué ofrece ASAMM

ASAMM no está concebido como un reemplazo para OWASP SAMM, sino como una extensión para equipos que despliegan agentes de IA, servidores MCP y automatización con permisos delegados. El marco añade una capa separada de garantías donde termina la revisión de código tradicional: en el límite de invocaciones de herramientas, en el flujo de contexto, en puntos de aprobación y en el comportamiento del sistema durante la ejecución. No cancela las prácticas básicas de SAMM, sino que las extiende al comportamiento en tiempo de ejecución y acciones delegadas.

• Una taxonomía de amenazas para sistemas de agentes, donde el contexto se trata como un posible comando
• Un modelo de confianza de dos ejes para agentes, herramientas, servidores MCP y fuentes de contexto
• Un conjunto de controles en las cinco funciones de SAMM con niveles de madurez y escenarios de implementación
• Dos rutas de despliegue: migración desde un programa de seguridad existente o despliegue desde cero
• Asignación a NIST AI RMF y recomendaciones de NCSC para equipos que necesitan compatibilidad con marcos ya familiares

Se hace especial énfasis en el entorno de desarrollo. Los plugins de IDE, hooks pre-commit, agentes de CI y conectores MCP externos funcionan con privilegios de desarrollador, pero frecuentemente existen fuera de un modelo de amenaza completo. Para ASAMM, esto no es un elemento secundario, sino un objetivo de análisis completo: si un agente puede leer, invocar y modificar más de lo que el equipo realmente rastrea, los estados verdes en los paneles dejan de garantizar nada. De hecho, el entorno de desarrollo se convierte en producción para el propio agente.

Dónde los equipos ya están cometiendo errores

El material enumera errores típicos que son especialmente visibles en el desarrollo de agentes. Un equipo puede considerar el modelo de amenaza completo, aunque no contenga fuentes de contexto ni rutas de invocación de herramientas. La revisión de código puede cubrir todo el código en un PR, pero no toca los prompts del sistema, esquemas de llamadas de herramientas y configuraciones de agentes. DAST puede mostrar un resultado limpio, aunque nadie haya probado cómo se comporta el agente con contexto adversario. Y el principio de privilegio mínimo a menudo se implementa solo a nivel de cuenta de servicio, sin restringir las acciones reales permitidas a través de herramientas.

"Ningún plan sobrevive al primer contacto."

El autor usa este pensamiento como un principio de diseño: el prompt del sistema debe establecer la intención, no intentar describir rígidamente todo el algoritmo de comportamiento. De ahí otro parámetro crítico de riesgo: el producto de la ventana de autonomía y el radio de explosión de herramientas disponibles. Cuanto más tiempo actúa un agente sin punto de control humano y cuanto más amplio su conjunto de capacidades, mayor el daño potencial incluso con derechos de acceso formalmente correctos. Por eso las ventanas de autonomía se convierten en un parámetro arquitectónico, no solo operativo.

Lo que esto significa

Agentic SAMM captura un cambio que ya ha ocurrido en el desarrollo de IA: la seguridad ahora verifica no solo el código sino el comportamiento del sistema después del lanzamiento. Para equipos que construyen productos sobre agentes y vibe coding, esta es una señal para revisar los modelos de amenaza, la revisión de código y el control de herramientas antes de que el primer error autónomo se convierta en un incidente completo.