AI Agent Security Development Lifecycle for Enterprise Platform Teams

Enterprise agents do not fit the security model that most organizations still run. The fix is not another checklist bolted onto the existing SDLC. It is a five-phase lifecycle built around how agents actually behave: what they call, whose credentials they hold, and why they act.

Why the traditional SDLC security model fails for AI agents

Traditional controls evaluate traffic content and identity. An agent holds credentials and then decides, autonomously, what to do with them. No existing perimeter tool evaluates intent before a tool call executes. None is positioned to ask whether this specific invocation is legitimate.

Agents also do not behave like the persistent artifacts that IAM and SDLC security were built around. The persistent-account model has no place to put them. The Supabase MCP incident from June 2025 shows the gap clearly: no credential was stolen, no network intrusion occurred, and no conventional software vulnerability was exploited. A support ticket was the weapon. The GitHub MCP indirect injection worked the same way, using a public issue to plant exfiltration instructions that an agent with elevated repository access then carried out.

The governance picture makes it worse. Only a small fraction of enterprise agentic AI pilots reach production, with the rest stalling on identity, audit, and access-control gaps. The security deficit precedes deployment. That is why a structured AI Agent Security Development Lifecycle is not a layer on top of existing SDLC checklists. It is a set of purpose-built phases tuned to agentic risk, from design through decommissioning.

The five threat classes that a lifecycle must be designed to catch

Five documented threat classes define the agentic attack surface. Each one needs a different lifecycle control to intercept it, so mapping them together is the prerequisite for a coherent design. Tool poisoning embeds malicious instructions in MCP tool descriptions, where the agent reads them but users never see. Invariant Labs proved this on Cursor IDE, exfiltrating a user's SSH private key through a hidden instruction in a calculator tool description, with no visible indication to the user. Supply chain compromise is broader: the OX Security disclosure from April 2026 found a command execution vulnerability embedded in Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust. Unauthenticated server exposure is the third class. A July 2025 internet scan found 1,862 publicly accessible MCP server instances responding to unauthenticated requests, and the MCP specification marks authorization optional.

Agent-to-agent lateral movement is the fourth. Indirect prompt injection is the fifth: the GitHub and Supabase incidents both succeeded because no control was positioned to evaluate intent before tool execution. A supply chain compromise can deliver a tool-poisoned server that enables prompt injection, which then fuels lateral movement using over-provisioned credentials. A lifecycle must catch each class at the phase where it is cheapest to stop.

Phase 1: Threat modeling agents before a line of code is written

Agent threat modeling at design time forces decisions that become exponentially harder to retrofit in production. Standard STRIDE or PASTA modeling does not account for tool-call intent evaluation, cross-agent trust boundaries, or the distinction between a legitimate instruction and an injected one arriving through the same channel. A design-time threat model for an agent must answer questions that never arise for a conventional service: which MCP servers will this agent connect to, and what is each server's provenance and authentication posture? What is the blast radius if this agent is compromised? Which content sources are attacker-influenced? Can the agent act autonomously, or must certain tool calls be confirmed? What is the decommissioning plan?

The Railway database deletion is the reference failure here. It happened because a long-lived API token with account-scoped permissions was reachable from a staging context. Scope and lifetime were both wrong. That is a design decision, not an exploited vulnerability. The output of this phase is a documented agent threat model covering tool scope, content source risk, cross-agent trust boundaries, blast radius, and decommissioning. It is the gate before Phase 2 begins.

Phase 2: Vetting and governing MCP servers as a supply chain problem

Choosing an MCP server without vetting is equivalent to adding an unreviewed third-party dependency with privileged access to every system the agent can reach. The scale is not hypothetical. The OX Security flaw affects an estimated 200,000 vulnerable instances across a supply chain with more than 150 million package downloads. The Vulnerable MCP Project, maintained by Vineeth Sai with contributing researchers from SentinelOne, Snyk, Trail of Bits, and CyberArk, now tracks over 50 known MCP vulnerabilities, with 13 rated critical.

Provenance is not protection. Antiy CERT confirmed over a thousand malicious skills in the ClawHub ecosystem. Snyk's ToxicSkills audit found that 13.4 percent of audited skills, 534 of 3,984, contained at least one critical security issue, and 36.82 percent had at least one flaw of any severity.

A vetting process must treat each server as a decision, so you need clear criteria. Check authentication posture: does the server implement OAuth 2.0, or is authorization absent? The spec marks authorization optional, so assume unauthenticated until confirmed. Run Snyk's mcp-scan against server packages and agent skill registries. Pin verified versions and block auto-update. Check the transport mechanism: STDIO carries higher RCE risk from the OX Security flaw, while Streamable HTTP uses a different execution path. Audit tool descriptions for embedded instructions not visible in the UI, and add automated prompt injection scanning of tool metadata to CI. The Sentry MCP event injection case from June 2026 shows a vendor declining remediation and deploying only a payload-string filter. A proper registry with an approval workflow is the governance mechanism that most enterprise pilots lack. Runlayer provides a catalog of MCP servers with built-in credential handling and OAuth management, which gives platform teams a governed path to adoption instead of asking each team to vet and wire servers on its own.

Phase 3: Agent identity architecture and credential design

The identity patterns most enterprises apply to agents create an attack surface larger and slower to contain than traditional IAM problems. Non-human identities now outnumber human identities by a large margin in large enterprises. Roughly 41 percent of identity breaches involve compromised non-human identity credentials, per Sophos research. And 31 percent of organizations operate agents under delegated human user identities, so an agent's actions appear in logs as a human's and the accountability chain collapses.

Long-lived, account-scoped tokens are the recurring failure. The Railway deletion happened precisely because one was reachable from a staging context. The correct model starts with a unique, revocable identity per agent, not a shared service account. Credentials should be issued just in time, at the moment of a specific tool call, scoped to that call's minimum permissions and not held persistently. Agent identities should be managed through the same SSO and SCIM directory as human identities, so an employee departure or project end triggers revocation automatically.

The MCP specification has moved in this direction. The June 2025 revision mandated OAuth 2.0 Protected Resource Metadata per RFC 9728, carried forward in MCP 2026-07-28, with clients sending the resource parameter on both authorization and token requests and servers rejecting any token not issued for themselves. But the Enterprise-Managed Authorization extension, stable as of June 18, 2026 and adopted by Anthropic, Microsoft, and Okta, governs the connection moment, not the runtime action. What happens after the access token is issued is outside its visibility. Runlayer's OAuth and JIT credential handling addresses that gap by tying identity to every tool call rather than only to session establishment.

Phase 4: Runtime enforcement at tool-call depth

A valid access token is not evidence that a specific tool call is legitimate. It was zero-click against Microsoft 365 Copilot, requiring only that the agent read a crafted email. No perimeter control was positioned to intercept it. Intent drift is the runtime analog of tool poisoning: an agent starts with legitimate scope, then drifts into unauthorized actions within the same session through injected instructions in content it processes.

Runtime enforcement at tool-call depth requires policies evaluated against the specific tool, the specific parameters, and the initiating context, not just the session identity. That is what separates agentic security controls from API gateway rules. Intent drift detection asks whether the sequence of tool calls matches the stated task scope. An agent that begins by querying a CRM and then issues file exfiltration commands to a repository is drifting, and behavioral sequencing can catch it. Human confirmation gates must block high-consequence actions like production data writes, credential operations, and cross-environment moves until a person approves them. In multi-agent architectures, an agent receiving instructions from another should not inherit that agent's trust level automatically. The CSA research note recommends zero trust at the tool integration layer, which operationally means every tool call is evaluated independently. Runlayer's control layer enforces policies at tool-call depth with identity tied to every action, and its security layer runs real-time detection for tool poisoning, prompt injection, and intent drift. The combination addresses the gap that EMA and traditional IAM leave open.

Phase 5: Audit architecture and tamper-proof logging for agents

Agent audit answers a different question than application logging. It is not "what did the system do" but "why did the agent do it, on whose authority, and what surrounded the action." Shadow agents compound the problem. Among organizations with more than 100 sanctioned agents, more than half reported an equal or larger number of unsanctioned agents operating in parallel. Agents that governance cannot enumerate are agents whose actions cannot be audited.

An agent audit log must contain the unique agent identity and its human sponsor attribution, the specific tool called and the MCP server it was routed to, the full parameters passed, the input that triggered the action including the prompt and the content being processed, the full output produced, a timestamp with enough resolution to reconstruct sequences, a session identifier linking all tool calls in a task, and a human confirmation record for any tool call that required one. Logs an agent or the systems it can reach can modify are not audit logs. They are notes. OTEL tracing provides the substrate for tracing a single user action through multiple agent hops and tool calls, and without it multi-agent incident reconstruction becomes manual and incomplete.

The zombie agent problem is an inventory failure. If a retired agent still holds active system access, that is a decommissioning gap. Retirement must trigger credential revocation, identity removal, and a final audit log entry. The EU AI Act's high-risk obligations apply to MCP gateways used on regulated data, and its logging, human oversight, and cybersecurity resilience requirements map directly to what a complete agent audit architecture must provide. Runlayer's tamper-proof audit logs and full OTEL tracing provide the attribution chain from human sponsor through agent identity to specific tool call that compliance frameworks require and that most enterprise logging architectures cannot currently produce for agentic workloads.

How to build the lifecycle as an organizational capability, not a checklist

A lifecycle framework fails when it is treated as a pre-deployment gate rather than a continuous operational capability. Agents change, MCP servers update, and threat actors adapt. A checklist completed at launch catches none of those changes. MCP server governance is not a one-time vetting event. The CSA research note says enterprises should establish ongoing MCP governance programs, not run a one-time patch cycle. The CVE surface is active and growing.

The lifecycle becomes self-improving through feedback loops. Audit logs from Phase 5 feed threat model updates in Phase 1. Incidents and near-misses should trigger revision. Runtime enforcement detections in Phase 4 feed MCP server governance reviews in Phase 2. A tool poisoning detection against a specific server is a signal to re-evaluate its approval status. Identity and credential reviews in Phase 3 should be triggered by personnel changes, project completions, and quarterly access reviews, not only by incidents.

The organizational model that makes this work is the golden path. Platform teams build the lifecycle into the agent provisioning workflow, so a team requesting a new agent gets identity, credential scoping, MCP server governance, runtime controls, and audit automatically. That removes the friction that drives shadow agent deployment, and the secure path becomes the default path. Runlayer's enablement layer gives every employee a governed path to agent deployment through chat-based setup, while its control layer gives platform teams a single pane over every MCP, skill, and agent. Security work at setup time becomes what enables broad adoption rather than what limits it. The lifecycle is complete only when decommissioning is as governed as provisioning. Retiring an agent must trigger the same workflow rigor as creating one.