Securing the Agentic Development Lifecycle: Six Requirements, One Architecture

On June 3, Snyk published "The New Security Risks of the Agentic Development Lifecycle" by Daniel Berman. It gives the shift a name and a definition. The agentic development lifecycle is "the process by which AI agents plan, build, modify, test, and ship software by interacting with tools, codebases, data sources, and development environments." And it closes with a requirements list for securing it.

This is worth welcoming without reservation. When a vendor of Snyk's standing defines the new unit of analysis (the lifecycle, not the artifact) and publishes what securing it requires, the argument shifts from whether to how. This post is about the how: what those requirements demand architecturally.

The Diagnosis: Secure the Process, Not Just the Artifact

Berman's core claim is that risk now enters before code reaches the repository, which changes the question security has to answer. In his words: "The security question changes from 'Is this code secure?' to 'Can we trust the system that created it?'"

He is specific about why. Agents pull in MCP servers, skills, and external tools that were never declared as dependencies. They run scripts and call APIs at machine speed. They generate output that can move from suggestion to commit before any checkpoint sees it. On the input side, the risk is documented, not hypothetical: Snyk's own ToxicSkills research found 76 confirmed malicious skills out of 3,984 analyzed.

The sentence that deserves a place on whiteboards: "Traditional AppSec secures the artifact. Agentic Development Security secures the process that creates it."

The Requirements List Is an Architecture Spec

The article's section before its close lays out what securing this lifecycle requires. Paraphrased closely, security teams need to:

• discover which agents, tools, skills, and MCP servers are in use
• evaluate whether those inputs are trusted
• govern what agents are allowed to access and execute
• enforce policy during agent workflows
• validate generated code and dependencies in real time
• maintain an audit trail across agent-driven development activity

Read as a checklist, this is sensible. Read as an engineering spec, it is demanding, because each item constrains where the control plane can physically live. Three of those constraints are worth walking through.

Constraint One: Policy Belongs Inside the Generation Context

Berman writes: "Scanning after commit is no longer enough; security has to validate what agents generate at creation."

Take that seriously and a structural consequence follows. An agent's behavior is a function of its context: the instructions, tools, and information present when it generates. A control that sits adjacent to the workflow, whether a proxy or a post-hoc scanner, evaluates decisions the agent has already made. It can block an action; it cannot un-generate the code or reshape the intent that produced it.

Enforcing policy during agent workflows means the policy has to be present inside the context the agent generates from, delivered before generation, for example over MCP, so the active rules and controls are part of the agent's working input. An agent cannot follow a policy it never saw. And validating output "at creation" has the same implication: the earliest point you can validate generated code is the same place it is generated.

Constraint Two: Continuous Control Without Slowdown Means Graduation

The article is careful to rule out the obvious bad answer: "Securing this lifecycle does not mean slowing developers down with another review cycle or banning AI tools."

Hold those two requirements together, enforce continuously and slow nobody down, and a single checkpoint cannot satisfy both. A checkpoint strong enough to be authoritative is, by definition, another review cycle.

The resolution is graduated velocity layers: the same policy set enforced at four points of increasing authority. Policy in the agent's context over MCP shapes generation itself. IDE feedback catches deviations in real time, while the developer still holds the context. Git hooks validate at commit. The PR gate is the authoritative, server-side backstop that nothing non-compliant merges past.

Constraint Three: The Audit Trail Should Be a Byproduct

The article's real-time logic applies to evidence too: "Agent behavior has to be governed in real time, because actions can happen faster than human review can intervene." What outruns human review also outruns human record-keeping.

There are two ways to have an audit trail across agent-driven development. You can reconstruct one after the fact, assembling logs scattered across assistants, repos, and CI systems into a narrative that is expensive, lossy, and slower than the activity it describes. Or every enforcement decision can emit its own record at the moment it executes. When each policy evaluation produces an audit-ready, machine-readable (OSCAL) evidence record as it runs, the audit trail exists by construction. Enforcement and evidence become the same event, which is the only arrangement that keeps pace with agents.

The Spec Is Public Now

Snyk's closing section is titled "The lifecycle changed. Security has to change with it." That is the right summary, and it is good for the category that it now comes from one of the most established names in application security. Naming the agentic development lifecycle, and publishing the requirements for securing it, gives engineering and security leaders a shared, citable vocabulary for a conversation that has lacked one.

It also gives them a test. MergeGuide is built on the architecture those requirements describe: policies injected into the AI assistant's context over MCP at generation time, the same policies enforced at the IDE, Git hooks, and the PR gate, with audit-ready, machine-readable (OSCAL) evidence records generated at evaluation time.

However you assemble your stack, the requirements list is now public. Map each of the six against your toolchain and ask one question per line: does this control operate inside the agent's workflow, or next to it? The distance between those two answers is the work ahead.