What Is the Agentic Development Lifecycle (ADLC)?

TL;DR

• The Agentic Development Lifecycle (ADLC) is the software development lifecycle (SDLC) under machine-driven execution, running continuously from prompt through Model Context Protocol (MCP), skill, agent, code, cloud, and data without default human review gates.
• Decision authority moves upstream from human developers to system prompts, agentic skills, and MCP tool configurations.
• Vibe coding is a behavior inside the ADLC, not a replacement for the overall lifecycle that governs prompt-to-runtime software delivery.
• Repository scanners miss upstream context, detecting syntax flaws in committed diffs while remaining blind to prompt intent and agent tool permissions.
• Asset inventory is the mandatory first step, requiring security teams to index MCP servers, prompts, and skills before setting agentic governance policies.

The Challenge: Why the SDLC Broke – Humans Left the Loop, Controls Stayed

The Agentic Development Lifecycle (ADLC) is the software development lifecycle operating when autonomous AI agents author, review, refactor, and deploy code – a continuous chain from developer prompt through Model Context Protocol (MCP) tool calls, agent skills, repository commits, and cloud runtimes where human approval gates are absent unless explicitly re-engineered.

For two decades, SDLC security controls relied on human agency at every key decision point: selecting dependencies, reviewing pull requests, and approving production releases. The secure SDLC placed its checkpoints entirely around human evaluation.

In the Mythos Age – the era in which AI systems operate autonomously, making decisions and executing code without step-by-step human approval – agentic development breaks this model by removing the human decisions behind those checkpoints. Coding agents generate thousands of lines of diffs, auto-resolve libraries, and trigger CI/CD pipelines in seconds. The security gate still fires, but it operates as an empty ceremony – a human reviewer skimming massive synthetic pull requests cannot realistically evaluate intent or architectural risk.

This structural disconnect is reflected in industry data. DORA’s 2025 research on AI adoption, drawn from its State of AI-assisted Software Development report, finds that 90% of technology professionals now use AI at work and more than 80% say it has increased their productivity – and that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Autonomous workflows push release frequency past the point where human review keeps pace. The SDLC assumed a human speed limit; the ADLC operates without one. 

This article is for AppSec teams, CISOs, and security architects who need to know what the ADLC changes about where the security decisions are made.

Core Concepts: What Is the ADLC, and What Is It Not?

The Agentic Development Lifecycle is the continuous software delivery pipeline operating under machine-driven execution. It tracks code evolution across a multi-stage operational chain that runs from the initial developer prompt down through live cloud runtime execution.

The ADLC does not invent new software delivery phases; planning, building, testing, and deploying remain the core stages. Instead, it relocates decision-making authority. Where the traditional SDLC relied on human developers to write logic and approve changes, the ADLC shifts execution to system prompts, MCP server calls, agentic tool configurations, and automated merge gates.

To secure this environment, AppSec teams must distinguish the ADLC from related concepts:

• ADLC vs. agent development lifecycle: IBM and Microsoft use “ADLC” for “agent development lifecycle”: the process of building and operating AI agents themselves. This article uses “ADLC” for the “agentic development lifecycle”: the software delivery lifecycle executed by agents, sometimes called the agentic software development lifecycle.
• ADLC vs. SDLC: The SDLC is bounded by human writing speed and manual review capability. The ADLC is an agentic framework operating at machine velocity, where software changes are generated, tested, and iterated continuously without requiring human intervention at every step.
• ADLC vs. CI/CD: CI/CD is the deterministic automation engine that builds, tests, and deploys code artifacts. The ADLC encompasses CI/CD, but extends upstream to include prompt intent, LLM context windows, and agent reasoning steps before code ever hits a repository.
• ADLC vs. Vibe Coding: “Vibe coding,” the practice of using plain-language prompts to generate software without reading the underlying diffs, is merely a developer behavior inside the ADLC. The ADLC is the end-to-end engineering lifecycle that governs, executes, and secures those prompt-driven changes down to runtime data.

The Chain: What Happens Between Prompt and Data?

The ADLC operates as a continuous execution chain where machine intent transforms into production infrastructure. Security controls that only inspect committed code miss the context generated across the early stages of this chain.

The Authoring Half: Prompt, MCP, Skill, Agent

The authoring half transforms natural language into executable instructions. A human or orchestrator issues a prompt setting intent. MCP servers expose database connections, enterprise APIs, and local file systems to the model. Pre-configured skills package these capabilities into reusable subroutines. Finally, the agent evaluates the prompt, selects the appropriate skills, calls the MCP tools, and writes code to satisfy the request.

The primary security exposure in this phase is that prompts, MCP bindings, skills, and agent parameters are runtime configurations rather than compiled code. They often sit outside traditional version control, meaning malicious prompt injections or over-privileged MCP tool access can end up leaving no trace in Git history.

The Delivery Half: Code, Cloud, Data

The delivery half represents the downstream physical assets: committed code, provisioned cloud infrastructure, and production data stores. Traditional AppSec scanners operate exclusively in this half, detecting security flaws without understanding the upstream authoring context that created them.

For example, an IaC scanner might flag a Terraform file containing an overly permissive IAM policy. In a traditional SDLC, an AppSec engineer assumes a human developer made a lazy configuration choice. In the ADLC, that policy is often the direct output of a prompt instructing an agent to connect a microservice so that it “just works.” The scanner flags the permissive cloud policy, but because it lacks visibility into the upstream prompt and MCP configuration, it cannot prevent the agent from repeatedly generating the identical vulnerability across future iterations.

Where Does Accountability Live in the ADLC?

Accountability breaks down in the ADLC because Git history records identities that mask machine execution. In an agentic pipeline, the committer is frequently a CI/CD service account, the reviewer may be a secondary automated agent, and the approving human (when one exists) approves a high-level UI summary rather than reading the raw diff. If a vulnerability reaches production, inspecting version control only reveals that a line of code changed, not why the agent chose to write it.

This identity abstraction maps directly to the systemic risks outlined in the OWASP Top 10 for Agentic Applications, particularly around agent goal hijack (ASI01), tool misuse & exploitation (ASI02), and identity and privilege abuse (ASI03). Agent accountability is the ability to tie every machine-authored change to the agent that produced it, the authority it acted under, and the context it was working from. Establishing it means capturing three distinct records for every automated action:

1. Agent Identity: The specific model version, agent framework, and execution instance that generated the change.
2. Delegated Authority: The explicit human identity, API token scope, and RBAC policy that authorized the agent to act.
3. Upstream Context: The exact prompt, MCP server state, and active skill configuration present when the decision was executed.

Because standard version control captures none of these three records, accountability must be enforced outside the repository, binding prompt-to-runtime execution metadata directly to every release artifact.

Implications for AppSec Programs

Transitioning from an SDLC to an ADLC security model requires fundamentally restructuring AI code security: how application security teams measure coverage, evaluate threats, and enforce policies across AI-assisted codebases. To implement an effective ADLC security strategy, AppSec leads must execute these shifts in a strict operational sequence, beginning with visibility.

• Asset Inventory First: Security teams cannot protect what they cannot trace. The inventory must expand beyond repositories and cloud services to index every active MCP server, system prompt repository, and agent skill deployed across the enterprise. Inventory is the prerequisite for all downstream controls.
• Agent-Aware Threat Modeling: Threat models can no longer treat software as a static architecture diagram. AppSec must evaluate the inventory of tools an agent can call, the boundaries of its MCP connections, and the potential blast radius if an upstream prompt is injected.
• Diff-Based Coverage Metrics: Measuring security coverage by percentage of pull requests scanned is meaningless when agents generate hundreds of PRs a day. Coverage must be calculated against the total volume of agent-authored code diffs and tool executions.
• Targeted Human Review Gates: Blanket human approval requirements fail at machine scale. Review policies must be re-engineered so that human gates trigger exclusively for high-risk operations – such as architectural changes, authentication refactoring, or new database schema migrations – while routine agent diffs pass through automated verification checks.

Common Mistakes and Limitations

Organizations adapting their security postures to the ADLC frequently fall into four recurring operational traps detailed across agentic AI security risk models:

1. Bolting Policy onto Legacy Pull-Request Gates: Inspecting agent-authored pull requests with traditional SAST and SCA tools catches vulnerable syntax, but completely misses the upstream prompt context, skill subroutines, and MCP tool configurations that generated the code.
2. Treating Autonomous Agents as Standard Developers: Assigning long-lived API keys, broad developer privileges, or standing repository permissions to AI agents allows a single prompt injection to escalate into a company-wide breach.
3. Over-Relying on Model Provider Guardrails: Assuming that safety controls at the LLM provider level (such as content filters) protect system infrastructure ignores the fact that provider guardrails have zero visibility into your local tool permissions or database schemas.
4. Conducting Point-in-Time Agent Inventories: Auditing AI agents and MCP tools on a quarterly or annual schedule fails in modern development environments, where agent skills and tool bindings evolve on a weekly basis.

ADLC Failure Mode	Traditional Root Cause	Operational & Security Impact	Pipeline Remediation Strategy
Over-Privileged Agent Credentials	Issuing standing developer API keys to autonomous agents	A single prompt injection or agent compromise grants full repository write and merge access	Implement short-lived, dynamic tokens scoped strictly via least-privilege RBAC per tool execution
Unmonitored MCP Server Connections	Treating MCP tool bindings as static local developer configurations	Agents access unvetted enterprise databases, internal APIs, or file systems without audit logging	Establish real-time discovery and access auditing across all active MCP endpoints and skill subroutines
Synthetic Review Fatigue	Forcing human developers to manually approve massive AI-generated pull requests	Developers auto-approve 2,000+ line diffs, turning human gates into empty compliance ceremonies	Deploy automated merge gates that enforce mandatory human review strictly on high-risk architectural diffs
Code-Only Security Scanning	Applying legacy SAST/SCA scanners exclusively at the pull-request boundary	Scanners detect syntax flaws but miss malicious prompt context, tool misuse, and context-blind logic	Capture prompt-to-runtime lineage to evaluate agent intent alongside committed source code
Stale Agent Asset Inventories	Performing quarterly or annual audits of development tools and IDE plugins	Shadow AI agents, unverified skills, and third-party MCP servers enter the environment untracked	Maintain a continuous asset inventory that dynamically indexes AI models, prompts, skills, and MCP servers

The OX Security Angle: Governing the Full ADLC Chain

The defining security challenge of the Agentic Development Lifecycle is the location of risk. In an agentic architecture, key decisions occur upstream of the repository – within natural language prompts, Model Context Protocol server capabilities, skill definitions, and autonomous tool selections. Traditional AppSec scanners engage no earlier than the repository boundary, inspecting committed code after those decisions have already executed. Relying solely on code-level scanning leaves security teams blind to prompt injection attacks, unvetted MCP tool bindings, and context-blind logic flaws generated during the authoring phase.

The OX AI-Native Application Protection Platform (AINAPP) bridges this gap by extending governance across the entire ADLC chain, governing the full agentic development lifecycle from prompt to runtime. Rather than treating code as an isolated artifact, OX evaluates software evolution from initial developer prompt through MCP tools and agent skills down to live cloud runtime execution:

• Pipeline & AI Asset Visibility: Indexes the agents, MCPs, skills, and packages in use alongside repositories and cloud assets.
• Context-Aware Risk Evaluation: Correlates upstream prompt intent and agent tool access with downstream code changes, preventing hallucinated dependencies or over-privileged infrastructure configurations before code merges.
• Automated Lineage & Provenance: Captures full execution metadata for machine-authored changes, establishing verifiable auditability for every agent action.
• Targeted Merge Enforcement: Replaces manual pull-request fatigue with automated merge gates that block merges based on policy conditions such as issue type and severity, so review effort lands where the risk is.

By positioning controls directly where decisions are made (across the prompt, protocol, and code layers), OX enables organizations to embrace agentic development velocity without sacrificing visibility or security control.

Governing the Authoring Layer in the Agentic Era

The Agentic Development Lifecycle does not replace the fundamental phases of software delivery, but it fundamentally relocates where decisions occur. When autonomous agents author, refactor, and deploy code at machine scale, security choices move upstream – shifting from human developers to natural language prompts, Model Context Protocol configurations, and agentic skills.

Securing the ADLC cannot be achieved by piling additional scan gates onto legacy pull requests. Protecting modern pipelines requires governance that operates directly across the authoring layer: tracking execution lineage, auditing agent permissions, and verifying intent from initial prompt down to live runtime data.

To see how your organization can secure agentic development without compromising velocity, explore the OX Application Security Platform or schedule a personalized demo with an OX security expert today.