OWASP SAMM Gets Agentic SAMM, an Extension for Secure Development with AI Agents

A new draft project, Agentic SAMM (ASAMM), has appeared around OWASP SAMM. It is an extension for teams that build products with AI agents and use models in development. Its goal is to cover risks that a classic secure SDLC handles poorly: malicious context, dangerous tool calls and autonomy windows that run too long.

Why the old SAMM is not enough

Classic OWASP SAMM works well where the main assets to protect are code, build, release and delivery infrastructure. In agentic systems, however, the attack surface extends further: into documents, tracker tickets, tool descriptions, web search results, CI logs and any other content the model reads as part of its working context. If that context influences the agent's behavior, it is no longer just input data. It becomes part of the control plane.

That is why the author of ASAMM proposes viewing development not as a closed loop but as a spiral. The team passes through design, implementation and verification again and again, but with each turn the system, the tools and the threats themselves change. In this setup, it is no longer enough to check that the agent was given the correct permissions. Even a fully authorized agent can take an action that does not match the original task if the context or the delegation logic steers it off course.

What ASAMM offers

ASAMM is designed not to replace OWASP SAMM but as an add-on for teams that deploy AI agents, MCP servers and automation with delegated authority. The framework adds a separate layer of assurance where the usual code checks end: at the boundary of tool calls, in the context flow, in approval checkpoints and in the system's runtime behavior. It does not cancel the core SAMM practices; it extends them to runtime behavior and delegated actions.

• A threat taxonomy for agentic systems, in which 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 the five SAMM functions, with maturity levels and adoption scenarios
• Two launch paths: migrating from an existing security program or deploying from scratch
• A mapping to the NIST AI RMF and NCSC guidance for teams that need compatibility with familiar frameworks

The material puts particular emphasis on the development environment. IDE plugins, pre-commit hooks, CI agents and external MCP connectors run with developer privileges but often sit outside a proper threat model. ASAMM treats them not as a side issue but as a full target for analysis: if an agent can read, call and modify more than the team actually tracks, green statuses on dashboards no longer guarantee anything. In effect, the development environment becomes production for the agent itself.

Where teams already go wrong

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

"No plan survives first contact."

The author uses this idea as a design principle: a system prompt should set intent rather than try to spell out the entire behavioral algorithm.

This leads to another important risk parameter: the product of the autonomy window and the blast radius of the available tools. The longer an agent acts without a human checkpoint and the wider its set of capabilities, the greater the potential damage, even with formally correct access rights. That is why autonomy windows here become an architectural parameter, not just an operational one.

What this means

Agentic SAMM records a shift that has already happened in AI development: security now has to verify not only the code but also the system's behavior after release. For teams building products on top of agents and vibe coding, it is a signal to revisit their threat model, code review and tool controls before the first autonomous error turns into a full-blown incident.