OWASP SAMM suma Agentic SAMM, una extensión para desarrollar con seguridad con agentes de IA

En torno a OWASP SAMM ha surgido un nuevo proyecto en borrador, Agentic SAMM (ASAMM): una extensión para los equipos que construyen productos con agentes de IA y usan modelos en el desarrollo. Su objetivo es cubrir los riesgos que un secure SDLC clásico detecta mal: contexto malicioso, llamadas peligrosas a herramientas y ventanas de autonomía demasiado largas.

Por qué el SAMM clásico se queda corto

El OWASP SAMM clásico funciona bien cuando los principales objetos de protección son el código, la compilación, el lanzamiento y la infraestructura de entrega. Pero en los sistemas agénticos la superficie de ataque se extiende más: a documentos, tareas del gestor de incidencias, descripciones de herramientas, resultados de búsqueda web, logs de CI y cualquier otro contenido que el modelo lee como parte de su contexto de trabajo. Si ese contexto influye en el comportamiento del agente, deja de ser un simple dato de entrada y pasa a formar parte del control plane.

Por eso el autor de ASAMM propone ver el desarrollo no como un ciclo cerrado, sino como una espiral. El equipo vuelve a pasar por el diseño, la implementación y la verificación, pero en cada vuelta cambian el sistema, las herramientas y las propias amenazas. En este esquema ya no basta con comprobar que al agente se le han concedido los permisos correctos. Incluso un agente totalmente autorizado puede ejecutar una acción que no corresponde a la tarea original si el contexto o la lógica de delegación lo desvían.

Qué propone ASAMM

ASAMM no se concibe como sustituto de OWASP SAMM, sino como una capa adicional para los equipos que implantan agentes de IA, servidores MCP y automatización con poderes delegados. El marco añade una capa independiente de garantías donde terminan las comprobaciones habituales del código: en el límite de las llamadas a herramientas, en el flujo de contexto, en los approval checkpoints y en el comportamiento del sistema en ejecución. No anula las prácticas básicas de SAMM, sino que las extiende al comportamiento en runtime y a las acciones delegadas.

• Una taxonomía de amenazas para sistemas agénticos, en la que el contexto se considera un posible comando
• Un modelo de confianza de dos ejes para agentes, herramientas, servidores MCP y fuentes de contexto
• Un conjunto de controles para las cinco funciones de SAMM, con niveles de madurez y escenarios de adopción
• Dos rutas de puesta en marcha: migrar desde un programa de seguridad existente o desplegar desde cero
• Un mapeo con el NIST AI RMF y las recomendaciones del NCSC para los equipos que necesitan compatibilidad con marcos ya conocidos

El material pone un énfasis especial en el entorno de desarrollo. Los plugins de IDE, los hooks de pre-commit, los agentes de CI y los conectores MCP externos trabajan con los privilegios del desarrollador, pero a menudo quedan fuera de un threat model completo. Para ASAMM no son un elemento accesorio, sino un objetivo de análisis de pleno derecho: si un agente puede leer, invocar y modificar más de lo que el equipo realmente supervisa, los estados en verde de los dashboards dejan de garantizar nada. En la práctica, el entorno de desarrollo se convierte en producción para el propio agente.

Dónde fallan ya los equipos

El documento enumera errores típicos que se notan sobre todo en el desarrollo agéntico. Un equipo puede dar por terminado su threat model aunque no incluya ninguna fuente de contexto ni rutas de llamada a herramientas. El code review puede cubrir todo el código de una PR, pero no tocar los prompts de sistema, los esquemas de tool calls ni las configuraciones de los agentes. El DAST puede arrojar un resultado limpio sin que nadie haya comprobado cómo se comporta el agente ante un contexto hostil. Y el least privilege suele aplicarse solo a nivel de cuentas de servicio, sin limitar las acciones que las herramientas permiten.

«Ningún plan sobrevive al primer contacto».

El autor usa esta idea como principio de diseño: el prompt de sistema debe fijar la intención, no intentar describir rígidamente todo el algoritmo de comportamiento.

De ahí surge otro parámetro de riesgo importante: el producto de la ventana de autonomía por el blast radius de las herramientas disponibles. Cuanto más tiempo actúa un agente sin un punto de control humano y cuanto más amplio es su conjunto de capacidades, mayor es el daño potencial, incluso con derechos de acceso formalmente correctos. Por eso las ventanas de autonomía se convierten aquí en un parámetro arquitectónico, y no solo operativo.

Qué significa

Agentic SAMM refleja un cambio que ya se ha producido en el desarrollo con IA: la seguridad ya no verifica solo el código, sino también el comportamiento del sistema tras el lanzamiento. Para los equipos que construyen productos sobre agentes y vibe coding, es una señal para revisar su threat model, el code review y el control de herramientas antes de que el primer error autónomo se convierta en un incidente en toda regla.