TL;DR
The agentic SDLC is not a new lifecycle. It is your lifecycle with the human removed from the middle of every phase. Agents draft the plan, write the change, generate the tests, review the diff, ship behind a flag and triage the alert. Engineers set the intent and own the decisions. The phases survive. What changes is who performs the work inside them.
Every control you own was designed around a human. Code review assumed a second person. Least privilege assumed an employee with an identity. Provenance assumed an author. The audit trail assumed a name in a commit. Agents satisfy none of those assumptions, and nothing breaks loudly when they stop holding. The pipeline stays green.
Speed makes the gap structural, not occasional. Independent research on AI coding assistants puts around 40% of generated code as containing a security vulnerability, and volume rises far faster than review capacity. Add agents that install their own dependencies and read configuration nobody reviews, and a gate at the end of the pipeline is a gate on the wrong side of the damage.
What makes an agentic SDLC governable: an inventory of the agents and MCP servers actually running, a scoped tool surface per agent, configuration reviewed like code, checks at install time on the machine, signed provenance for what ships, and a trace that survives the incident. Xygeni AI Security, DevAI and Build Integrity cover those six across code, pipeline and endpoint.
What is Agentic SDLC?
The agentic SDLC is a software development life cycle in which AI agents carry out substantial work in every phase, from planning through operations, pursuing goals across many steps using tools, while engineers set intent, review outcomes, and own the irreversible decisions. It keeps the familiar phases and replaces the actor inside them.
What is agentic SDLC, precisely?
Three things separate it from AI-assisted development, and the distinction is not academic.
- Who drives. Anyone asking what agentic SDLC is usually starts here. With an assistant, a person types and the model suggests. In the agentic SDLC, a person states an outcome, and the agent decides the steps. The middle of the work, which used to be the job, moves.
- What it touches. An assistant produces text in an editor. An agent reads repositories, edits files, installs packages, calls internal APIs, runs pipelines, and opens pull requests, using tools it was given and credentials it inherited.
- How many? One agent on one laptop is a productivity story. Dozens of agents acting across shared systems, several per engineer, is an organisational one. That is where the answer to what is agentic SDLC stops being a definition and becomes a governance problem.
Most teams sit between the second and third state today: agents are real, they are running locally, and nobody has re-scoped a single control since they arrived.
How AI agents are reshaping every phase
The phases hold. The actor changes, and with it the control that phase depended on.
The agentic SDLC, phase by phase
Read the third column. That is the part nobody re-scoped when the agents arrived.
| Phase | What the agent does now | The control that assumed a human |
|---|---|---|
| Plan | Reads the ticket, pulls related services and history, drafts the spec and the approach. | Requirements review. Nobody checks whether the spec absorbed instructions from the ticket itself. |
| Code | Edits multiple files, resolves and installs dependencies, refactors adjacent code. | Approved-library policy. It assumed a person chose the package, and install scripts run before any pipeline exists. |
| Review | Comments on the diff, flags standards, sometimes reviews another agent's work. | Four eyes. Two agents and one rubber stamp is not a second opinion, and volume makes stamps inevitable. |
| Test | Generates tests, runs them, reads failures and fixes its own output until green. | The passing suite as evidence. An agent can make a test pass by weakening the test. |
| Build | Triggers pipelines, edits workflow files, updates build configuration. | Provenance. Attestations record what was built and by whom, and "whom" is now a token borrowed from a developer. |
| Deploy | Ships behind a flag, watches signals, ramps or rolls back on its own. | Change approval. A named approver becomes a service account, and the kill switch needs an owner who is awake. |
| Operate | Triages alerts, correlates deploys, proposes and sometimes applies the fix. | The audit trail. After the incident, the question is which agent did this, on whose credentials, and the session is usually gone. |
The four assumptions that quietly stop holding
Read the table again, and the same four failures repeat, whatever the phase. This is the part of what is agentic SDLC that no productivity chart shows.
- Identity. Almost nobody provisions an identity for an agent. It runs with the developer’s tokens, keys, and cloud session, so every access review describes a human who was not the actor, and least privilege becomes a fiction the moment an agent inherits a broad token.
- Independent review. Review worked because the reviewer had not written the code. When one agent writes, and another checks, and a person approves at machine volume, the independence that made the control valuable is gone, even though the process still runs.
- Provenance. Supply chain integrity rests on knowing what was built, from what, by whom. Agentic activity blurs the last part. Attestations still sign the artifact, but the author field no longer means what your policy assumed it meant.
- Traceability. The control that matters most after something goes wrong is the one least often configured. Agent sessions, tool calls, and the configuration state at the time are rarely retained, so the postmortem starts with reconstruction instead of evidence.
None of these produce an alert. That is what makes them dangerous: the agentic SDLC does not fail loudly; it degrades quietly while every dashboard stays green.
It breaks on the laptop, not in production
Not in production. On the laptop. The riskiest moments in the agentic SDLC happen before any pipeline runs: the agent reads a rules file nobody reviewed, resolves a package name that a model invented and an attacker registered, connects to an MCP server that exposes tools nobody audited, and executes an install script with the developer’s credentials already loaded. Industry research puts roughly 86% of MCP servers on developer machines rather than in production, which is precisely where your production controls cannot see.
A CI gate is still worth having. It is simply on the wrong side of the first three things that happen.
What makes an agentic SDLC governable
Six controls that survive contact with agents
Each one replaces an assumption the agentic SDLC broke. None of them require slowing the agents down.
- An inventory of agents, not a survey of engineers Discover the agents, assistants and MCP servers actually running, from code, dependencies and the configuration files the tools leave behind. Ask five engineers and you get five incomplete answers, because these tools install locally and change weekly.
- A scoped tool surface per agent The blast radius of an agent is the sum of its tool calls, not the quality of its prompt. Write down what each agent may reach, keep irreversible actions behind a human, and treat a broad inherited token as the finding it is.
- Configuration under review, like code Prompts, rules files, skill files and MCP definitions decide what the agent does, and no conventional scanner reads them. They need owners, diffs and checks for hidden characters, embedded credentials and instructions that widen access.
- Enforcement at install time, on the machine Packages get checked before they are written to disk and before install scripts execute, where the agent actually resolves them. A pipeline gate fires after the laptop already ran the code, which is the wrong side of the event.
- Provenance for what ships Signed attestations tying artifacts to the source, the build and the pipeline that produced them keep integrity claims meaningful when the author of a change is an agent rather than a person.
- A trace that survives the incident Anomalous activity across pipelines and endpoints, tied back to the machine and the identity it came from, is what turns the postmortem question of which agent did this into an answer rather than an archaeology project.
Closing the four gaps
Xygeni AI Security discovers the AI in your SDLC, including the models, agents, agent servers, MCP servers, datasets, skill files, prompts, and guardrails nobody declared, reads application code, declared dependencies, and the configuration files AI tools leave behind, then maps how they connect. It detects the risks specific to agentic work: prompt injection and system prompt leakage, malicious instructions and tool injection in rules and skill files, insecure MCP configuration, excessive agency and missing guardrails, secrets in AI files, and vulnerable or slopsquatted AI dependencies. Findings map to the OWASP Top 10 for LLM Applications and point to the exact file and line, and the prioritization funnel narrows thousands of findings to the ones that are in use, reachable, exploitable, privileged, and business-critical.
DevAI works where the agent works: securing code as it is written, covering AI-generated and human-written code alike, and intercepting what other agents are about to do before they do it. Build Integrity closes the provenance gap with SLSA and in-toto attestations across the pipeline, CI/CD Security watches the workflows and runners agents now edit, and Anomaly Detection ties suspicious events back to the endpoint they came from in a single timeline.
All of it applies to findings ingested from the scanners you already own, so extending your programme to the agentic SDLC does not mean replacing the stack you built for the last one.
FAQ
What is agentic SDLC in one sentence? A software lifecycle where AI agents perform substantial work in every phase while engineers set intent, review results, and own the irreversible decisions.
Is the agentic SDLC different from AI-assisted development? Yes, and the difference is who drives. An assistant suggests while a person works. An agent works while a person decides.
Which phase changes most? Review. The other phases get faster; review loses the property that made it a control, which is independence between the author and the reviewer.
Do we need new tools for the agentic SDLC? You need coverage of things existing tools do not read: agent and MCP inventory, the configuration layer, install-time behaviour on the endpoint. The rest of your stack still applies to the code that results.
Does the agentic SDLC break compliance? It breaks the evidence, not the obligation. Auditors ask who approved, who authored, and what changed, and those answers get harder when the actor is an agent with a borrowed identity and no retained trace.
Where should a security team start? Inventory, then the tool surface of the agent with the widest reach. The riskiest agent is rarely the one anyone was worried about.
The lifecycle did not change. The actor did
The honest answer to what is agentic SDLC is that every phase still exists, and most of your process still fits. What no longer fits is the assumption sitting underneath each control: that somewhere in the loop there was a person with a name, an identity, a second opinion, and a memory of what they did.
Teams that handle this well can answer three questions on any given day: which agents are running, what each one can reach, and what changed in the files that steer them. See what your agents are connected to at Xygeni.
