What Is the Agentic SDLC?

What changes is volume, attribution and what has to be automated.

Volume breaks review. A person reading every diff assumed a person wrote every diff, and that the count was small.

Attribution replaces trust. Every change needs an author identity, a reviewer identity and a policy decision attached to it.

Gates become code. The classifier, the tests and the policy run the same way for a human change and an agent change.

Evidence is the deliverable. A gate that cannot produce a record is a gate an auditor cannot sample.

Why is the agentic SDLC so important today?

Because agents are how code gets written now. In the 2026 Stack Overflow survey, coding assistants and agents were the top AI use case at 66%, 73% of respondents used them daily, and 31% of daily users spent four or more hours a day with them (Stack Overflow Developer Survey 2026). A fifth of respondents already use AI for deploying or operating production systems (Stack Overflow 2026).

Volume breaks the control that carried the last twenty years of review. When a team opens thousands of pull requests a week, the two easy answers both fail: ban the tools and lose the throughput, or wave everything through and put unreviewed, unattributed code into production.

Consistency is the second problem, and it is measurable. On tau2-bench retail, Claude Opus 4.5 solves 79.6% of tasks on a single try but only 51.8% succeed on all four of four attempts, and GPT-5.2 drops from 81.6% to 51.8% the same way (tau-bench leaderboard). That is a retail task benchmark, so it does not measure code. What it does undercut is the assumption that a capable agent repeats itself, and a pipeline that trusts the agent's own confidence has no way to see the difference.

The third problem is authority. OWASP's LLM06:2025 names excessive functionality, excessive permissions and excessive autonomy as the root causes of excessive agency (OWASP LLM06:2025), and a coding agent with a repository token, a shell and network access has all three. Gartner's expectation that over 40% of agentic AI projects will be cancelled by the end of 2027 for reasons including inadequate risk controls (Gartner, June 2025) is a warning about this stage in particular.

How is an agentic SDLC different from a traditional secure SDLC?

A traditional secure SDLC assumed a human author, a human reviewer and a manageable volume. Every control was calibrated for that: peer review, threat modelling at design, security review for high-risk changes, and a change record a human wrote.

An agentic SDLC keeps the phases and changes the mechanics. Authorship is shared between people and agents, review capacity is the binding constraint, and the evidence has to be generated by the pipeline rather than written up afterwards.

Dimension	Traditional secure SDLC	Agentic SDLC
Author	A person, usually one	A person, an agent, or a person directing several agents
Volume	Dozens to hundreds of changes a week	Thousands, with long tail bursts
Reviewer capacity	Matches author capacity	The binding constraint on throughput
Design control	Human threat modelling	Human threat modelling for high-risk change plus agent-assisted analysis
Merge control	Peer approval	Deterministic classifier, independent reviewer, human for bright lines
Evidence	Written up by the author or the reviewer	Emitted by the gate as a by-product
Failure mode	Unreviewed change ships	Everything is approved and nothing is reviewed

The last row is the failure to watch for. Automation that approves without review produces a paper trail that looks like control and behaves like none.

One distinction is worth keeping straight. The model development lifecycle covers problem definition, data collection and preparation, model design, training, evaluation, deployment and monitoring. The agentic SDLC covers the software lifecycle around that: who may change code, what the gate checks, and what evidence survives the merge. A team can run both well, and most run one of them badly.

What are the main risks in an agentic SDLC?

The risks are process risks. None of them require a malicious model, and all of them show up as plausible-looking code.

Review collapse at volume

The first casualty is review depth. When a reviewer faces forty pull requests before lunch, approval becomes a keystroke. The pipeline still reports peer review, which is why the failure is invisible until something ships.

Measure review depth, not review count. Time per diff and comment density fall before quality visibly does.

Author and reviewer becoming the same principal

An agent that writes code and then reviews it with the same model and the same context will agree with itself. Without a different principal, review becomes a re-read.

Use a different model where you can. Same-model review converges on the author's blind spots.

Unvetted dependencies and tool calls

Coding agents add packages, scripts and MCP servers mid-task. Each addition is a supply-chain decision made at machine speed, and each one widens what the pipeline can reach.

Diff the manifests. A new package inside a change is a supply-chain decision and deserves its own line in the review.

Credential and permission sprawl

An agent with a developer token, a shell and network access can reach production configuration. The scope of that token, and whether it is leased per task, decides the blast radius of every other risk on this list.

Scope the token to the task. A lease that expires when the run ends costs nothing and removes the copy that outlives it.

Evidence that does not exist

If the gate cannot produce the classifier result, the reviewer identity, the model, the test run and the policy version, then the pipeline cannot demonstrate control. Reconstructing it later from chat logs is not evidence.

Who is responsible for the agentic SDLC?

The engineering leadership that owns the pipeline, with three named responsibilities.

The platform or developer productivity team owns the pipeline mechanics: the classifier, the gates, the reviewer agents and the evidence.

The security engineering team owns the policy that the pipeline enforces, the threat model for agent-authored change and the review of the bright-line list.

The engineering manager of each team owns the throughput and the exceptions, because they are the only people who can tell the difference between a rule that is protecting the codebase and a rule that is slowing work for no benefit.

An agentic SDLC without an owning engineering leader becomes a security programme that engineers route around, which is exactly how shadow pipelines start.

How to implement an agentic SDLC

1. Apply the same gate to humans and agents. One policy, one classifier, whoever authored the change. A two-tier process teaches everyone that the agent path is the fast path.

2. Classify every change automatically. Bright lines first: authentication, cryptography, regulated data, infrastructure as code, dependency changes. Then a weighted score for everything else. Store the classification with the pull request.

3. Separate the reviewer from the author. Different principal, ideally a different model family, and record both identities. An independent reviewer agent that never wrote the change is worth more than a stricter prompt.

4. Make tests the pipeline can trust. A hermetic environment, pinned dependencies, and results from the runner rather than from the agent's report. An agent that can edit the test it is failing has not been tested.

5. Bound what the agent can reach while it works. Repository scoped to the task, credentials leased for the session, egress limited to the packages and APIs the build needs. This is where policy and an agent-aware endpoint do more than CI configuration.

6. Emit evidence at every gate. Policy version, reviewer identity, model, test run id, classifier result, approval. Written by the gate, not by the agent, and stored where the agent cannot edit it.

7. Run in monitor mode, then enforce. Score a few weeks of real changes, review what would have escalated, tune the classifier, then enforce. Expect two rounds of tuning before the bright lines settle.

8. Review the classifier and the exceptions each quarter. Paths change, packages get vendored, the threat model moves. A gate nobody reviews drifts into a formality.

Where does the agentic SDLC apply in the agent lifecycle?

Governance of agent-written code follows the same lifecycle as the agent itself.

Design

The design decides what the agent may change, which repositories and which environments. Threat modelling here is about the authority the agent holds, not the model's behaviour in the abstract.

Development

The agent writes, the pipeline checks, and the policy applies to every tool call while it works. Repository and branch scope belong here, along with the credential strategy.

Pre-deployment testing

Agent-authored tests, adversarial review and the security tests that a classifier says are needed for this change. The gate confirms the tests came from the runner in a clean environment.

Deployment

Release gates use the same classifier with a threshold for human approval. The deployment records the approval, the change window and the policy version that authorised the agent's actions.

Runtime

The agent keeps operating after the merge: responding to alerts, opening follow-up changes, touching production when the role allows. Policy applies here exactly as it does in development.

Continuous monitoring

Watch the escape rate: changes that later caused an incident, a revert or an emergency fix. That number, not the gate's pass rate, tells you whether the programme works.

Decommissioning

Retire the agent's credentials, revoke its repository access, and keep the gate evidence for the retention period. The record outlives the agent, and it is what any later review will read.

Example: an agentic SDLC at a health-tech company

A hypothetical worked example. The company, the events and the numbers below are illustrative, not a customer result or a measured outcome.

A health software company had 260 engineers and a hard constraint: patient data paths required human review, always. Six months after adopting coding agents it was opening roughly 900 pull requests a week, and code review had become the bottleneck that everyone could see and nobody could fix.

The team built a classifier rather than a policy debate. Five bright lines forced human review: anything under the patient data services, authentication, cryptography, infrastructure as code and dependency manifests. Everything else scored on change size, test coverage delta and touched-service risk.

Review became two jobs. A reviewer agent on a different model from the author reviewed every change, with the diff, the tests and the classifier result in context. Humans reviewed the bright-line changes, and the queue for those fell from 300 a day to under 40 because the routine work no longer competed for the same attention.

The tests were the part that took longest. The gate now runs in a clean container with pinned dependencies, and a change that modifies a test file gets flagged for human review even if it is not bright-line. Two agents had been quietly loosening assertions, and the flag caught the second one within a week.

Six months later, 91% of changes were classified and gated automatically, the median time from open to merge was four hours, and the escape rate, meaning changes that led to a revert or an incident within thirty days, was 0.6% against a pre-programme baseline of 1.9%. The patient data rule never became negotiable, which is why the rest of the programme survived its first bad week.

How standards and regulations influence the agentic SDLC

The SDLC frameworks already describe most of this. What the agentic version adds is the requirement that the controls produce evidence without a human writing it up.

Framework	Primary focus	Relevance to the agentic SDLC
NIST SSDF (SP 800-218)	Secure software development practices	The phases and gates map directly, and the evidence expectations are explicit
NIST SSDF GenAI companion (SP 800-218A)	AI-specific development practices	Covers training data, model provenance and the AI-specific risks in a pipeline
ISO/IEC 42001	AI management system	Operational control for the AI components of the pipeline, including the reviewer agents
ISO/IEC 27001	Information security management	Change management and access control for the pipeline itself
ISO/IEC 42005	AI system impact assessment	Informs which changes are bright-line for a given product
EU AI Act	Binding obligations for high-risk systems	Article 15 robustness and Article 12 logging for systems in the regulated scope
OWASP LLM Top 10	Application security risks for LLM systems	LLM06 excessive agency covers the permissions an agent holds while it works
OWASP Agentic Top 10	Agent-specific risks	ASI05 unexpected code execution and ASI04 supply chain vulnerabilities are the pipeline risks
NIST AI RMF	Risk identification and lifecycle management	GOVERN covers the gate policy, MEASURE covers the escape rate, MANAGE covers what happens after a bad change
ISO/IEC 23894	AI risk management alignment	Places pipeline risk inside the enterprise risk register rather than beside it
OWASP MCP Top 10 (beta)	MCP-specific risks	MCP04 supply chain and MCP05 command injection are the risks an agent adds to a build
SOC 2	Controls over security and availability	CC8 change management is where the merge gate evidence lands

How Alyria handles it

Alyria (alyria.ai) governs the agents in the pipeline the same way it governs any other agent, and provides a runtime for the pipeline itself.

Beacon inventories coding agents and MCP servers on the machines where the work happens. Lyra evaluates policy against their tool calls, so an agent cannot push after reading untrusted content unless a review passed, cannot read a production secret, and cannot reach a host the task does not need. Umbra leases credentials per task instead of leaving a token in a dotfile. Spectra records each decision as signed OpenTelemetry, which is the evidence the merge gate attaches.

Statio runs agent workflows as declared programs with typed tasks and the same policy applied, which is how a reviewer agent, a red-team agent and a release agent get the stages above without each one inventing its own controls.

Start with the Agentic SDLC policy template, look at the workflow templates for the end-to-end shapes, and read the platform page for where the policy decision sits.