Agent Development Lifecycle Security Gates

AI agent security needs gates built for agents. Because agents act probabilistically across tools, memory, and external services, their risks do not stop at deployment. A workable framework puts distinct controls at Design, Build, Test, Deploy, and Operate, connected by shared identity, policy, and audit records.

Why traditional SDLC security gates fail for AI agents

Traditional software development lifecycle gates assume that code will follow paths that can be predicted. Static analysis, dynamic testing, and dependency scanning look for flaws in software whose execution can be examined at a defined boundary. Agents cross those boundaries as they plan, call tools, retain memory, and coordinate with other agents. Harm can emerge from several individually authorized actions. There need not be one broken function to find.

The University of Connecticut survey formalizes this mismatch through its Layered Attack Surface Model, or LASM. Its seven layers are Foundation, Cognitive, Memory, Tool Execution, Multi-Agent Coordination, Ecosystem, and Governance. The survey’s non-transferability theorem says a control at one architectural layer has zero detection power against an attack localized at another. Coverage does not transfer between those layers. A clean result at one boundary says nothing about an attack confined to another.

Time makes the gap harder to see. The survey describes how a crafted document found in a routine web search corrupts long-term memory and affects an unrelated session weeks later. Neither the injection nor the later exploitation need produce a detectable anomaly at its own boundary. The TU Berlin / Max Planck paper makes a related point by looking at operating-system security. An agent runtime has the kernel’s job of arbitrating resource access, yet current designs diverge from that principle at nearly every boundary.

What an agent lifecycle actually looks like, and where the attack surface lives at each stage

The five stages mark different trust boundaries. Design sets the tool scope and permission budgets, along with the assumptions about threats. Build uses those decisions to set up tool integrations, composed skills, credential wiring, and memory architecture. That work brings in supply-chain exposure. Test then examines behavior under adversarial conditions, including attacks that outlast a single exchange.

Deploy brings runtime hardening, MCP server registration, and identity provisioning into production. Authentication gaps become live exposure at this boundary. Operate covers how the agent behaves, how its permissions drift, and what its audit records show throughout its working life. The survey’s time categories cut across these stages, from instantaneous threats, T1, to session-persistent threats, T2, and cross-session cumulative threats, T3. Sub-session-stack threats, T4, arise when tool chains are composed during Build, while their behavior unfolds at runtime.

Security gates for the Design stage: threat modeling before a line of tool integration is written

Design locks in choices that later controls must live with. Each added tool grows the permission budget and adds a surface that must be defended at every later stage. The Design gate should therefore produce an explicit tool allowlist with a reason for each inclusion. Later stages must re-review that budget before they expand it. Whether access belongs in the design must be decided before a deployment control can do its job.

The principal hierarchy must be equally explicit. The OS-security paper treats the LLM as an untrusted actor, the runtime as the kernel, and tools as system calls. That analogy gives architects a concrete authorization question, namely which principal can approve which tool invocation. The architects must answer that question before integration work starts. Design must also establish agent identity, an owner of record, and a succession policy, rather than leaving ownership with whoever happens to build or deploy it.

The threat model must name the mechanisms. Tool description poisoning changes a description so the model misreads a tool’s purpose. A rug pull changes how a server behaves after registration, while cross-server tool shadowing uses descriptions from one compromised server to steer the use of another server’s trusted tools. These threats go beyond coding mistakes to how the system is built. T3 memory abuse adds a separate requirement to define what the agent may retain and act on across sessions, captured in a memory retention policy beside the principal hierarchy and permission budget.

Security gates for the Build stage: supply-chain vetting, tool registration controls, and credential architecture

Build must treat every third-party MCP server and skill as untrusted until vetted. OX Security’s April 2026 disclosure identified command execution exposure in Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust. The STDIO transport passed parameters directly to the host operating system’s shell without sanitization. Trust in the reference implementation propagated that design default downstream. An official SDK was not a security guarantee.

The Build gate needs checks that go beyond direct dependencies. As of May 2026, at least seven confirmed high- or critical-severity CVEs spanned major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf. CVE tracking must cover every integrated MCP platform. VirusTotal documented hundreds of malicious OpenClaw skills in February 2026, reinforcing why third-party skills require review as executable code. The survey’s inventory document gives that agent-specific inventory a concrete artifact.

Credential architecture belongs in this gate as well. An agent may hold access to CRM, email, cloud infrastructure, and payment systems at once. The recommended design replaces standing credentials with just-in-time provisioning for the specific action, paired with per-action authorization scoping. Runtime monitoring cannot fix that architecture once it is in place. Tool outputs also need a firm boundary, because the survey traces every examined Tool Execution layer attack to principal trust inversion, where untrusted returned content gains the authority of the original principal.

Security gates for the Test stage: behavioral validation, adversarial probing, and the temporal threat gap

EchoLeak, CVE-2025-32711, shows why functional testing is insufficient. An attacker sends a crafted email, an agent reads it while handling an unrelated query, and embedded instructions cause silent exfiltration of sensitive data. The attack requires no click from the user. Its entry point is content the agent is allowed to read. The Test gate must therefore probe indirect injection through every permitted data source.

Vetting during Build cannot show how the agent will behave in those tests. Tests must send adversarial inputs through each approved tool and check whether the agent treats the content it gets back as data or instructions. A multi-agent pipeline needs a scenario in which one sub-agent is adversarially controlled, because malicious intent can spread through peer trust relationships. Each tool needs its own adversarial cases. The test scope must cover the orchestration boundary as well as individual components.

Tests within a single session still miss threats that play out over time. The survey’s Empirical Finding 4 states that no surveyed benchmark evaluates T3 or T4 threats, so benchmark performance cannot establish coverage of either class. Tests need to examine session-persistent behavior and changes that survive or accumulate across sessions. A payload installed in one session may act in an unrelated later one. The release gate should require cross-session behavioral regression tests, multi-agent trust scenarios, and an explicit red-team scope covering T2–T4, rather than treating a successful immediate response as sufficient evidence.

Security gates for the Deploy stage: MCP authentication enforcement, identity provisioning, and zero-trust tool registration

A well-tested agent can still enter production with broken authentication. The Deploy gate must assess OAuth 2.1 compliance against the 2026-07-28 MCP spec revision. Dynamic Client Registration, which earlier guides recommended before Client ID Metadata Documents arrived in the 2025-11-25 revision, is formally deprecated in that later revision. It remains only a third-priority fallback behind pre-registered credentials and Client ID Metadata Documents. The registration path is the first check.

Deployments predating July 2026 must then confirm that the resource parameter is sent on both requests and that the server rejects tokens that do not name it. Resource Indicators under RFC 8707 bind the requested token to the MCP server it is meant for, so a malicious server cannot get tokens meant for another. Authentication cannot remain an assumed property of deployment. A 2025 internet scan found 1,862 publicly accessible MCP instances responding to unauthenticated requests. A dynamic assessment in July 2026 found that a large majority of audited servers lacked OAuth authentication completely, with 687 tool instances exposing shell execution without access controls.

Identity provisioning must keep the authorization chain set in Design intact. Every agent needs a non-human identity, or NHI, tied to SSO, scoped to its approved tools, and revocable independently of its builder. The registry entry must record its owner, scope, and revocation path. Tool registration needs a separate enforcement boundary. Every MCP server must be checked against the approved allowlist, with unapproved tools blocked at the gateway before the runtime can invoke them.

Security gates for the Operate stage: per-invocation authorization, permission drift detection, and tamper-proof audit logging

Authentication at launch does not authorize every later action. The Cloud Security Alliance’s Agentic MCP Security Best Practices Guide requires authorization beyond initial authentication, extending to per-invocation verification. Each call must be evaluated against the agent’s current permissions, context, user identity, and session state. High-privilege operations need explicit re-authorization for just-in-time escalation. Connection-time permissions are not a permanent pass.

Permission drift makes that distinction operationally important. A developer may grant access to unblock a workflow without revisiting permissions that are no longer needed. Ownership can drift too, leaving an agent running with active credentials after its human owner changes roles or leaves. The Operate gate needs rotation schedules, automated ownership-transfer triggers, and periodic scope re-certification. Those reviews must use the original Design-stage permission budget as their reference.

Behavioral monitoring covers a different failure mode. Intent-drift detection asks whether the current action sequence still matches the agent’s declared purpose, while exfiltration detection looks for data moving beyond approved destinations. Monitoring must also cover multi-agent coordination anomalies alongside individual agents. A trusted peer can become the route across boundaries. The survey identifies the cross-session and sub-session-stack region spanning Multi-Agent Coordination, Ecosystem, and Governance as under-studied despite containing the highest-severity threats.

Audit records must make those events investigable. The EU AI Act’s retention provisions, separate from Article 12 itself, set retention of at least six months for high-risk systems through Article 19(1) for providers and Article 26(6) for deployers. The recommended implementation uses append-only logs with hash chaining, plus OTEL tracing attached to every tool invocation and its agent identity. When an attack passes earlier gates and appears only in runtime behavior, continuous monitoring becomes the necessary complement to release checks.

Building the gate framework as a unified platform rather than a stack of point tools

These gates form a control model only when identity, policy, and audit connect them. Design’s principal hierarchy, Build’s ABOM, Test’s adversarial scope, Deploy’s NHI registry, and Operate’s authorization engine all need to identify the same agent acting for the same principal. That chain breaks when identity stores are kept separate and logs are disconnected. Those who investigate an incident then lose the link between what was approved and what the agent did.

Policy needs the same continuity as identity. A permission budget defined during Design must be enforceable at the deployment gateway and the runtime authorization engine. Separate configurations create room for the approved policy and the enforced policy to diverge. Governance must also reach beyond agent builders. Employees who use agent-powered workflows belong inside the control model even when they never integrate a tool or write an agent.

Work should begin by mapping existing tooling against all five stages and locating the breaks in identity continuity. Gaps should be closed from the highest-severity under-covered stage, typically Operate’s per-invocation authorization and behavioral monitoring. That work is an ongoing governance program. Shared controls give security teams a way to govern changing policies without rebuilding separate configurations at every stage. By owning that framework, security teams make enterprise AI adoption possible at scale rather than serving only as its final release barrier.