The Agent Development Lifecycle (Agent DLC)

An agent tested twice on identical data can behave differently each run, so the SDLC’s “deploy once staging passes” breaks - agentic systems need an evaluation-first lifecycle of their own.

What’s different about agents

• IBM and Anthropic call this the ADLC (Agent Development Lifecycle) - standard DevSecOps, extended for agents. The shift is deterministic → probabilistic, static → adaptive, and code-first → evaluation-first: ship only with evidence of behavior, not just a green build.
• Four stages have no analog in the model lifecycle (VI.2 · The five boundaries) or the SDLC (VII.1 · The secure AI SDLC): tool and MCP integration, memory and context, deploy-time identity (NHI), and runtime guardrails with human-in-the-loop.
• Google’s rule for the runtime: deterministic controls MUST gate any critical or irreversible action - reasoning-based defenses are inadequate on their own.
• No standards body publishes a canonical numbered agent lifecycle. The nine stages here are a synthesis over the IBM/Anthropic ADLC, Google’s SAIF-for-agents, OWASP Agentic guidance, and the vendor agent guides.

Why agents need their own lifecycle

The SDLC in VII.1 · The secure AI SDLC secures the software around a model. An agent is more than software: it perceives context, reasons over goals and constraints, keeps memory, and acts through tools in a continuous loop (I.2 · Shaping a model). That changes the build. IBM’s Guide to Architecting Secure Enterprise AI Agents with MCP (verified by Anthropic, October 2025) names three shifts that break the old cycle:

• Deterministic → probabilistic. Traditional software follows predictable paths; agents make dynamic decisions that vary even on identical inputs.
• Static → adaptive. Applications have fixed functionality; agents adapt behavior from interactions and feedback.
• Code-first → evaluation-first. A perfect implementation can still behave badly, and messy prompts can work great. Success depends on measuring behavior and outcomes, not on inspecting code.

That is why the ADLC adds two inner loops the SDLC has no need for: an experimentation loop between Build and Test (agent evaluation and benchmarking drive build-time improvement) and a runtime optimization loop after Deploy (inference-time tuning of quality and cost). IBM organizes the ADLC into six DevSecOps phases; the nine stages below elaborate them into the security work a builder does at each step.

flowchart TB
  P1["Plan<br/>use case, KPIs, acceptable agency"] --> P2["Code and Build<br/>prompts, memory, tools and MCP, sandbox"]
  P2 --> P3["Test, Optimize, Release<br/>evals, red-team, certify"]
  P3 --> P4["Deploy<br/>identity, gateway, kill-switch"]
  P4 --> P5["Monitor<br/>drift, agent threats, feedback"]
  P5 --> P6["Operate<br/>governed catalog, decommission"]
  P3 -.->|"experimentation loop"| P2
  P5 -.->|"runtime optimization loop"| P4
  P6 -.->|"lessons"| P1
  classDef p fill:#0f1a18,stroke:#5bd1c5,color:#bdeee2;
  classDef l fill:#1a160f,stroke:#e4a23f,color:#f0d9ad;
  class P1,P2,P3,P5,P6 p;
  class P4 l;

IBM’s six ADLC phases with the two signature inner loops. Each phase ships a deliverable behind a gate - use-case charter (leadership approval), design (design review), test (quality and risk thresholds), deploy (change-advisory approval), monitor (operational readiness), review (compliance review closed).

The Agent Development Lifecycle (Agent DLC)

No standards body publishes a canonical numbered Agent DLC - this nine-stage sequence is a synthesis. The four bolded stages (tool and MCP, memory, deploy-time identity/NHI, and runtime guardrails) have no analog in the model lifecycle of VI.2 · The five boundaries. Risk IDs use OWASP’s agent taxonomy: T1-T15 from Agentic AI - Threats and Mitigations, and ASI01-ASI10 from the Top 10 for Agentic Applications.

Explore it interactively

Click through the nine stages below - each shows what to watch for, what to secure, and the threats it answers (the full text is in the table beneath). The four ◆ stages are agent-specific, with no analog in the model lifecycle.

Stage	What to look for	What to secure	Source
1. Design and scoping	Over-broad task or unbounded autonomy; no well-defined human controller; an ambiguous tool budget inviting Tool Misuse (T2 / ASI02) and Agent Goal Hijack (T6 / ASI01); no threat model	Pick the least-agentic pattern that works - Anthropic reserve agents for open-ended problems where you can’t hardcode a fixed path, and “maintain simplicity in your agent’s design”; add explicit stopping conditions and max iterations; assign a well-defined human controller and limit agent powers (Google SAIF-for-agents P1 and P2); treat autonomy as earned through ongoing evaluation (AWS). Threat-model → VI.3	Anthropic Building Effective Agents; Google SAIF-for-agents P1/P2; AWS; OWASP Agentic
2. Tool and MCP integration (agent-specific)	Tool Misuse (T2 / ASI02); Agentic Supply Chain (ASI04); Unexpected Code Execution (T11 / ASI05); thin one-tool-per-endpoint wrappers with no namespacing; tool and RAG output treated as trusted input	Consolidate into fewer high-signal tools and namespace them (Anthropic); disclose destructive or open-world tools via MCP annotations; enforce deterministic, infrastructure-level authorization external to the agent (AWS P3 deterministic external controls; Google P2); vet and pin MCP servers; sandbox tool execution; treat all tool output as untrusted. Remote MCP → OAuth 2.1; local STDIO → credentials from the environment → IV.2	Anthropic (writing tools) + MCP spec; Google SAIF-for-agents; AWS; OWASP Agentic
3. Memory and context (agent-specific)	Memory Poisoning (T1 / ASI06) - malicious data stored as a “fact”; cross-user or cross-context contamination; Cascading Hallucination (T5)	Enforce strict memory isolation between users and between contexts, and extend it to the RAG vector store - per-tenant isolation and query-time ACL enforcement (Google); validate and sanitize content before persisting; give users transparency and control over stored memory (Google); track provenance and enable rollback to a trusted state (IBM runtime memory-layer protection)	Google SAIF-for-agents; OWASP Agentic T1 / ASI06; IBM agentic runtime
4. Build and orchestration	Insecure Inter-Agent Communication (T12 / ASI07); Rogue Agents in a multi-agent system (T13 / ASI10); Identity Spoofing (T9); Privilege Compromise and self-escalation (T3 / ASI03)	Keep the architecture as simple as the task allows (Anthropic; OpenAI: get a single agent working before manager or decentralized multi-agent patterns); authenticate and authorize every inter-agent message; enforce a maximum permission ceiling and block privilege escalation (Google P2); structure each agent as Model + Tools + Instructions (OpenAI)	Anthropic Building Effective Agents; OpenAI practical guide; Google SAIF-for-agents; OWASP Agentic
5. Evaluation and red-team	Misaligned and Deceptive Behaviors (T7); no adversarial test for injection, jailbreak, or the specific tool and memory paths; autonomy expanded with no evidence	Red-team against OWASP T1-T15 / ASI01-ASI10; do “extensive testing in sandboxed environments” before granting autonomy (Anthropic); gate every autonomy increase on measured evals (AWS earned autonomy); instrument a verify-the-work step - rules-based checks are the most reliable feedback, then visual, then LLM-as-judge (Anthropic Agent SDK)	Anthropic (Building Effective Agents + Agent SDK); AWS; OWASP Agentic
6. Deploy: identity, least privilege, sandbox (agent-specific: NHI)	Agents sharing human identities or holding persistent broad permissions; embedded secrets; no workload sandbox	Provision a unique, verifiable non-human identity per agent with least-privilege authorization at the infrastructure level (Google P1 distinct identities; AWS IAM); grant access just-in-time, scoped, and revoked on completion; enforce the two isolation boundaries - filesystem and network - via OS primitives (bubblewrap on Linux, Seatbelt on macOS) with egress through an allowlisting proxy (Anthropic sandboxing); apply Zero Trust across the lifecycle - verify explicitly, least privilege, assume breach (Microsoft) → NHI lifecycle in IV.6	Anthropic sandboxing; Google SAIF-for-agents P1; Microsoft Zero Trust; AWS IAM
7. Runtime: guardrails and HITL (agent-specific)	Rogue Actions - injection reaching real tools (Google’s primary runtime risk); Overwhelming HITL (T10); Human-Agent Trust Exploitation (T15 / ASI09); Resource Overload and denial-of-wallet (T4); reliance on model self-restraint alone	Google hybrid defense-in-depth: Layer 1 deterministic runtime policy enforcement (allow / block / require-confirmation) plus Layer 2 reasoning-based defenses - and deterministic controls MUST gate critical or irreversible actions because reasoning defenses are “inadequate, on their own.” Layer guardrails (OpenAI: relevance and safety classifiers, PII filter, moderation, tool-risk, rules-based checks, output validation) and require HITL on high-risk actions. In the Anthropic Agent SDK, put every-call checks in a PreToolUse hook (a hook denial holds even in the most permissive mode). Rate-limit tool calls	Google SAIF-for-agents; OpenAI practical guide; Anthropic Agent SDK; OWASP Agentic T4/T10/T15
8. Observability and detection	Repudiation and Untraceability (T8); opaque planning and actions (Google P3); Cascading Agent Failures (ASI08)	Log across the whole architecture including every tool and API call; characterize each action as read-only vs state-changing (Google); surface reasoning and planned actions in real time so a human can intervene at any point (Anthropic); adapt AAA - authentication, authorization, audit - for agents; preserve audit integrity via MCP token-audience separation; never log tokens or secrets → VII.3	Google SAIF-for-agents P3; Anthropic framework; OWASP Agentic T8 / ASI08; MCP spec
9. Decommission and offboarding	Orphaned non-human identities and standing credentials; residual memory and tool access; no token revocation on shutdown	De-provision the agent identity and revoke all credentials and tokens on retirement; securely delete or archive memory and state per retention policy; retain audit logs for forensics before teardown; keep a kill-switch to disable the agent under emergencies. Bridge to NIST GV-1.7 safe decommissioning and MG-2.4 kill switch → VIII.3	IBM/Anthropic ADLC (Operate); NIST AI RMF

Stage 7 in code - the PreToolUse deny hook. Deterministic controls MUST gate irreversible actions; this is that gate. Route the state-changing tools through a PreToolUse hook in settings.json, then deny an irreversible-action denylist. A hook deny holds even in bypass-permissions mode, so it is the one control an injected instruction cannot reason its way past.

// settings.json - route the state-changing tools through the deny hook
{ "hooks": { "PreToolUse": [ {
  "matcher": "Bash|Write",
  "hooks": [ { "type": "command", "command": "python3 .claude/hooks/deny_irreversible.py" } ]
} ] } }

# .claude/hooks/deny_irreversible.py - deny irreversible actions before they run
import json, re, sys
e = json.load(sys.stdin); tool = e["tool_name"]; inp = e.get("tool_input", {})
cmd = inp.get("command", "")
BASH  = re.compile(r"\brm\s+-rf\b|curl\b.*(-X\s*POST|--data|-d\b)", re.I)          # destructive / mutating shell
MONEY = re.compile(r"/(payments?|charges?|refunds?|transfers?)\b|\bDELETE\b", re.I)  # payment / delete API
deny = (tool == "Bash" and BASH.search(cmd)) \
    or (tool == "Write" and not inp.get("file_path", "").startswith("/workspace/")) \
    or MONEY.search(json.dumps(inp))
if deny:
    print(json.dumps({"hookSpecificOutput": {"hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": "irreversible action blocked by deterministic policy (Stage 7)"}}))
sys.exit(0)

Securing agentic systems with MCP across the lifecycle

The Model Context Protocol is how most agents reach tools, so it earns its own pass through the lifecycle. This is the when; IV.2 · Model Context Protocol (MCP) is the deep dive on each control. Requirements below use RFC 2119 force (MUST / SHOULD) where the MCP specification does.

MCP phase	The move	Deep dive
Build and author the server	Least-privilege tools; validate every input against strict schemas; enforce access controls; rate-limit invocations; sanitize outputs; put no secrets or hidden instructions in tool descriptions (treat tool-authored text as data); clients MUST treat tool annotations as untrusted unless the server is trusted; the server MUST NOT pass a client token upstream; elicitation MUST NOT request passwords, keys, tokens, or payment credentials	IV.2
Curate tools and supply chain	Pin and allowlist servers; hash tool descriptions and re-verify on change to catch a silent rug-pull; guard against tool poisoning (Invariant Labs, Apr 2025) and name-collision or shadowing; minimize the number of concurrently trusted servers - an academic study measured a 78.3% attack success rate with five servers connected and one compromised (arXiv 2601.17549, Maloyan and Namiot - a research result, not a vendor figure)	IV.2
Deploy: gateway, OAuth, transport	Front servers with a gateway policy-enforcement point (authn, authz, allowlist, rate-limit, audit log); as an OAuth 2.1 resource server the MCP server MUST validate token audience (RFC 8707) and reject tokens not issued for it, and MUST NOT accept passthrough tokens; clients MUST implement PKCE S256, send the resource parameter, and consume RFC 9728 protected-resource metadata; prefer Streamable HTTP (the older HTTP+SSE transport was deprecated 2025-03-26); per-client consent plus an exact redirect_uri match defeats the confused deputy; block link-local ranges (including 169.254.169.254) against SSRF	IV.2
Runtime: trust boundaries	Keep a human able to deny any tool call and show tool inputs before the call; watch the three sampling-abuse vectors - Resource Theft, Conversation Hijacking, Covert Tool Invocation (Unit 42, Dec 2025); for URL-mode elicitation the client MUST show the full URL and MUST NOT auto-open or pre-fetch it; bind session IDs to the user and never use them for authorization; enforce denial-of-wallet rate limits; never log Authorization headers	IV.2

IV.2 · Model Context Protocol (MCP) also carries the current MCP CVE roll-up and the enterprise MCP Gateway pattern - link, don’t restate.

Agent security: four risks, four controls

IBM frames the agent-specific threat as four business-level risks, each answered by one added control area. These sit across the lifecycle, not at a single stage - they are the security spine of the ADLC.

Business risk	Added control (IBM Security Solution Framework)
Uncontrolled access and privilege escalation - agents self-escalate to bypass approval and tracking	Agent identity and access: unique credentials per agent, just-in-time access, context-aware controls, continuous audit trails → IV.6
Data leakage and prompt exploitation - sensitive data shared via malicious prompts or nondeterministic responses	Agent and data protection: gateway patterns (MCP gateways) that filter prompts for injection, monitor information flow, and isolate and harden deployments → II.5
Autonomous attack amplification - malicious agents outpace human defenders and compress attack timelines	Autonomous agent defense: proactive threat hunting, AI-assisted selection of protections, and rapid containment → VII.3
Agentic drift and noncompliance - agents adapt away from policy undetected	Agent security risk and compliance: fold agent risk into enterprise decisions across the ADLC; continuously monitor for configuration drift and access-pattern anomalies → VIII.3

Expand third-party risk to the agentic supply chain: SBOMs for tools, prompts, and agent code; artifact signing and verification before deployment from trusted registries only; dependency scanning with pinned versions; scoped tool permissions and approvals; and continuous audits for fairness, transparency, and security.

Back to the five boundaries

Every stage lands on one of VI.2 · The five boundaries’s five boundaries: tool and MCP integration and runtime guardrails are Tools and actions; memory and context is Memory and context; deploy-identity and decommission are External assets and identities. The model lifecycle (VI.2 · The five boundaries), the threat-model decomposition (VI.3 · Threat modeling for AI systems), the SDLC (VII.1 · The secure AI SDLC), and this Agent DLC are four views of one system - so any stage walks straight into SAIF/CoSAI (VIII.2 · Google SAIF), the NIST AI RMF (VIII.3 · NIST AI RMF), or MITRE ATLAS.

Maps to

OWASP Agentic AI - Threats and Mitigations (T1-T15) and Top 10 for Agentic Applications (ASI01-ASI10) ¹ · Google SAIF-for-agents (3 principles, 2-layer hybrid defense) (VIII.2 · Google SAIF) · IBM/Anthropic ADLC (six phases, gates, MCP server lifecycle) · MITRE ATLAS · NIST AI RMF decommission and kill-switch gates (VIII.3 · NIST AI RMF).

Footnotes

1. OWASP GenAI’s formal document is Top 10 Risks and Mitigations for Agentic AI Security; the ASI01-ASI10 and “2026” labels are convenience shorthand used across this book. ↩