The ADLC maturity model: stages of agentic development security

TL;DR

• The ADLC maturity model measures how well security controls govern coding agents. It scores security maturity, not adoption, across five stages from unmanaged experimentation to continuous verification.
• Each stage sets requirements across two tracks: agent actions, such as shell commands, MCP tool calls, and package installs; and agent output, such as code, dependencies, and secrets.
• Stage 3 is the key threshold. Rules in system prompts, AGENTS.md, or .cursorrules provide guidance. Hooks that block actions before execution enforce rules.
• Stage 4 often stalls because agents open far more PRs, creating more finding noise. Reachability-based prioritization and exploitability confirmation on PRs keep developers acting on findings.
• Score each area separately using evidence, not claims. Your lowest-scoring area defines your real stage, and closing that gap should guide spending.
• Common traps include treating tools as progress, relying on prompt-level rules, approving a few agents while unreviewed MCP servers spread, and using noisy blocking checks that push developers to unmanaged tools.

What does the ADLC maturity model measure?

The ADLC maturity model measures how well your security controls govern coding agents, both what they do and what they produce. The ADLC (agentic development lifecycle) is the familiar plan, build, test, deploy, and maintain loop of the SDLC, with coding agents writing code and taking actions inside it. You'll sometimes see ADLC used for the "agent development lifecycle," which is about building AI agents as products. This model doesn't cover that meaning.

The model scores security maturity, not adoption maturity. A team can be far along on adoption and early on security. Picture an engineering org where every developer runs several agents in parallel all day, and nobody can list which MCP servers those agents call. On adoption, that team is advanced. On security, it's at stage 1.

There's no official ADLC security maturity standard yet. Even OWASP SAMM, the maturity model most security programs use, hasn't added practice streams for agentic AI, as GEICO's engineering team points out. Treat this model as a proposed framework. Teams also mature unevenly. You might be at stage 4 for code scanning and stage 1 for agent permissions. The assessment section shows how to score that honestly.

Why SDLC security maturity doesn't carry over

Traditional AppSec maturity assumes humans write code and pipelines check it later. If you've used a general application security maturity model, you'll recognize that assumption. Coding agents break it. They run commands, install packages, execute code, call tools, and inherit developer permissions. Many of those actions happen before a traditional AppSec control ever sees the result.

That creates two risk surfaces:

• Agent actions: what the agent does at runtime, such as shell commands, file access, MCP tool calls, and package installs.
• Agent output: what the agent introduces into your codebase, such as first-party code, open source dependencies, and secrets.

Risk crosses between the two. A poisoned MCP server can lead to a destructive command, and a malicious package can end up as compromised code in production. Securing both today often means stitching together separate tools, which leaves gaps between the agent runtime, the malware that can compromise it, and the code it produces.

So this model scores maturity on two tracks, and every stage has a requirement on both. Many teams find they're mature on code scanning and blind to what their agents execute. The two-track view makes that gap visible and easy to explain in a budget conversation.

The agent-specific risks to plan for include:

• Prompt injection through repository files, issues, pull request comments, or tool output. The OWASP Top 10 for LLM Applications lists prompt injection as a core risk category.
• Excessive agency, another OWASP category. In practice, agents inherit whatever permissions the developer has, including production credentials and write access to sensitive repos.
• Unvetted MCP servers and skills that developers add without review.
• Secrets exposure, where credentials land in prompts, agent context, logs, or committed code.

For more on how this changes the AppSec program itself, read why AppSec needs coding agent governance.

The model at a glance

Stage 1: unmanaged experimentation

Most teams start here. Developers found tools that make them faster and started using them.

You're here if:

• Individual developers install agents, IDE extensions, skills, and MCP servers with no central review.
• Nobody can produce a list of what's in use.
• Human PR review is the only control on both tracks.
• Secrets may end up in prompts or agent context, and you wouldn't know.
• Agents run with each developer's full permissions.

The main problem at stage 1 is that you can't answer basic questions about your agents, such as which ones are running and what they can reach.

To reach stage 2:

1. Start an inventory. Even a survey plus a scan of developer machines gives you a baseline of agents, models, MCP servers, and skills.
2. Require human review on every agent-generated change, and label those PRs so you can track them.

Stage 2: visibility into agents and their actions

Stage 2 means you know what's actually running and what it does.

On the agent actions track, you have an inventory of coding agents, models, MCP servers, and skills that teams actually use, including ones nobody approved. You also keep an audit log that covers shell commands, file access, MCP tool calls, and package installs. That log is centralized across Cursor, Claude Code, and other agents instead of scattered across each tool's local history.

On the agent output track, you run secrets scanning and dependency scanning on agent-generated changes. Treat models as dependencies too. They belong in the same inventory, with the same questions about origin, version, and license. You're here if:

• You can produce a current list of agents and MCP servers on request.
• You can pull the commands an agent ran during a specific session.
• Secrets and dependency findings on agent PRs show up in the same place as everything else.

At this stage you still can't stop anything. Visibility tells you a risky action happened, but it doesn't prevent the next one.

To reach stage 3:

1. Turn what you observe into written policy. Decide which MCP servers are allowed, which commands are off-limits, and which files agents should never read.
2. Rank your observed risks by impact so you know which policies to enforce first.

Stage 3: deterministic guardrails on agent actions

Stage 3 is the most important threshold in the model. 

Controls at earlier stages depend on what the model decides to do. Stage 3 controls apply regardless of what the model decides.

The difference shows up in where a rule lives. A rule in a system prompt, AGENTS.md, or .cursorrules file is guidance. The model can ignore it, misread it, or get talked out of it by a prompt injection buried in a README. A hook that intercepts a command before it executes and blocks rm -rf, reads of .env files, or calls to an unapproved MCP server is enforcement. It works the same way every time.

If the model can bypass a control by changing its mind, that control doesn't count toward stage 3.

Stage 3 controls on the agent actions track include:

• Least-privilege permissions. Agents get scoped credentials, not the developer's full set.
• Sandboxing for code execution and command runs.
• MCP allowlists that restrict which servers agents can call.
• Action policies that allow, block, or audit consequential actions before they run.

On the agent output track, stage 3 adds install-time blocking of malicious packages, so a compromised dependency never lands in the working tree.

As one implementation example, Endor Labs Coding Agent Governance uses native hooks inside the agent loop to evaluate consequential actions before they execute. It blocks destructive commands, sensitive file access, and unapproved MCP servers, and its Package Firewall blocks malicious packages at install time. Deployment is agentless and can go through Cursor Enterprise, Claude Enterprise, or MDM. For more detail on how policy works over agent actions, see our overview of AI coding agent governance.

You're here if you can show a blocked action and the policy that blocked it.

To reach stage 4:

1. Get security feedback to the agent while it's writing code, before the PR opens.
2. Fix your prioritization before adding more scanners. The next section explains why.

Stage 4: security inside the agent's loop

At stage 4, security becomes part of how agents write code. 

The agent gets security context during the task, so it picks a safe dependency version or avoids an injectable query before a human ever reviews the diff.

Many teams plateau before this stage because of finding noise. Agents open many more PRs than humans do. If every PR comes back with a pile of unprioritized findings, either delivery stalls or developers learn to ignore the findings. Both outcomes undo your progress.

Two practices make stage 4 sustainable:

• Reachability-based prioritization. Rank findings by whether vulnerable code is actually reachable from your application, across first-party code, open source dependencies, and containers.
• Exploitability confirmation on PRs. Confirm which findings on a pull request are actually exploitable before asking anyone to fix them.

As one implementation example, AURI by Endor Labs can be embedded into any MCP-compatible agent, so the agent gets security context while it writes. AURI uses full-stack reachability across first-party code, open source dependencies, and container images to prioritize findings by real risk. AI Security Review runs on every pull request to confirm which vulnerabilities are exploitable and suggest context-aware fixes. Endor Labs reports up to 95% false positive reduction for AI SAST and 83% fewer blocked PRs. Those numbers are relevant here because noise, more than detection, is what usually stalls stage 4. 

For practical depth on this track, see our guide to securing the code your agents write.

You're here if:

• Agents receive security findings during the task and fix them before the PR opens.
• Developers act on the findings that reach them instead of dismissing them in bulk.
• Your stage 3 guardrails still run underneath all of this.

To reach stage 5:

1. Define outcome metrics for both tracks and start tracking them.
2. Make evidence automatic, so nobody has to assemble it by hand before an audit.

Stage 5: measured, evidenced, and continuously verified

Stage 5 is the target state. Controls are tested, outcomes are measured, and evidence is a byproduct of normal work.

Mature programs produce evidence continuously. Scan results, remediation records, and agent activity logs come out of every build and every agent session. AI components show up in your SBOMs. Exports are ready for certification bodies and customer security reviews without a special project.

Continuous validation is the other half:

• Adversarial regression tests for prompt injection and tool abuse. Plant a malicious instruction in a test issue and confirm the agent's action gets blocked.
• Bypass checks that confirm agents can't turn off hooks, edit their own policy, or route around an MCP allowlist.
• Policy drift reviews when new agents, models, or MCP servers appear in your inventory.

Auditors and regulators are starting to ask about this. ISO/IEC 42001, the AI management system standard, expects organizations to keep records and monitor their AI systems, so teams that use coding agents should expect questions about how they govern them. Confirm the specific clauses that apply to you with your auditor. Government guidance is moving the same way. In 2026, CISA and its Five Eyes partner agencies published joint guidance on adopting agentic AI, and the Cloud Security Alliance's practitioner roadmap for that guidance is a useful check that your control areas match what others recommend.

You're here if you can answer a customer security questionnaire about coding agents with exports instead of narratives.

How to assess your stage honestly

Self-assessments tend to overstate maturity. GEICO's engineering team calls one version of this "maturity inflation": a program's effective maturity drops when agents multiply code volume and review processes don't scale with it, so many organizations sit lower than their SAMM scores suggest. A policy document can have the same effect, earning a "yes" on "Do you govern MCP servers?" even when nothing enforces it. Ask for evidence instead of claims.

Run these questions with your team. For each one, either produce the artifact or score it as missing.

Inventory

• Can you export a list of every MCP server in use this week?
• Can you list every coding agent and model developers used last month, including unapproved ones?

Permissions and tool access

• Can you show what credentials an agent session had access to?
• Can you show a blocked action and the policy that blocked it?

Code security

• Can you show which findings on a recent agent PR were confirmed exploitable?
• Can you show a fix an agent made during the task in response to a security finding?

Secrets

• Can you show a secret caught before commit on an agent-generated change?
• Can you show whether that secret was live or revoked?

Supply chain

• Can you show a malicious or risky package blocked at install time?
• Can you show models and AI components in your SBOM?

Oversight

• Can you show the log of commands an agent ran on a given PR?
• Can you show who reviewed and approved a specific agent change?

Monitoring and response

• Can you show the result of your last prompt injection regression test?
• Can you show how long it took to detect and respond to the last risky agent action?

Score each area separately. Your lowest area is your real stage. A team with stage 4 code security and stage 1 inventory is a stage 1 team with one strong area.

Track outcomes rather than tool counts. Useful metrics by stage include:

• Share of agent sessions under policy (stages 2 and 3)
• Unapproved MCP servers discovered per month (stage 2)
• Risky actions blocked, by policy (stage 3)
• Time to remediate agent-introduced findings (stage 4)
• False positive rate on findings sent to developers and agents (stage 4)
• Share of audit evidence produced automatically (stage 5)

Traps that stall maturity

• Counting tools as progress. Three scanners and a dashboard don't move you up a stage. Evidence does. If you can't answer the assessment questions, the tools aren't working for you yet.
• Relying on prompt-level rules. Rules files give agents useful guidance, but they can't enforce anything. A model can ignore them, and a prompt injection can override them. Teams that stop here believe they're at stage 3 when they're at stage 2.
• Approving a short list while the long tail spreads. You approve two agents. Meanwhile, developers add dozens of MCP servers and skills that nobody reviewed. An allowlist for agents without visibility into what they connect to leaves the biggest gap open.
• Adding blocking checks that push developers away. This trap carries over from the "scan after build" model, where security sits at the end of the pipeline as a checkpoint that stops work. 

At agent speed, that model fails. If every agent PR gets stuck behind noisy checks, developers move to unmanaged tools and personal accounts, and your visibility drops. A mature program provides security context where code is written and reserves enforcement for actions that are actually dangerous.

FAQs

Can you use OWASP SAMM to measure ADLC security maturity?

You can use OWASP SAMM for part of it. SAMM gives you a solid structure for software security practices, and many teams already use it, but it doesn't yet include practice streams for agent actions such as command execution, MCP tool calls, or inherited permissions. Use SAMM for your agent output track and add the agent actions areas from this model alongside it.

What are the five phases of the SDLC, and how do they map to the agentic development lifecycle?

A common version of the SDLC has five phases: plan, build, test, deploy, and maintain. In the agentic development lifecycle, the phases stay the same, but agents take part in each one. They draft plans, write and test code, and sometimes run deployment steps. The main security change is that agents take actions inside those phases, so you need controls on both what agents do and what they produce.

Do you have to reach every stage in order?

Mostly, yes, because each stage depends on the one before it. You can't write enforceable policy (stage 3) for agents you can't see (stage 2). Areas can still move at different speeds. Your code security track might reach stage 4 while inventory sits at stage 2. Use the lowest-area rule to decide where to spend next, and close that gap first.