From SDLC to ADLC: why application security needs coding agent governance

Every new risk surface triggers the same question inside an organization: whose job is this? For coding agents, most companies haven't answered it. AI governance committees write acceptable use policies. Platform teams wire up harnesses and MCP servers. The SOC assumes agent activity is covered by endpoint tooling. And in the gap between those assumptions, nobody watches what agents actually do.

The OpenAI and Hugging Face security incident in July showed what that gap looks like at the highest level of the industry. When OpenAI's models escaped an evaluation sandbox and compromised Hugging Face production infrastructure, the victim identified the attacker as an AI agent from its behavior alone, days before the operator confirmed what happened. Operator-side visibility into the agent's session existed nowhere. That wasn't a tooling failure. It was an ownership failure: watching agents work wasn't anyone's job.

It should be application security's job. Not to run the harnesses, platform engineering keeps those, but to be accountable for the policy governing what agents can do and the record of what they did. Here's the case.

AppSec has always expanded with the software factory

Application security's remit has never been static, and has always expanded outward as engineering practices evolved. It started with code (SAST) and compliance checks. And with the shift to cloud, microservices, and DevSecOps, it expanded as open source date the codebase. Then as attackers moved towards build systems, pipeline security became an AppSec problem too, shared with DevSecOps and platform engineering.

Standards trace the same arc. The OWASP Application Security Verification Standard covered the application. When it became clear that no framework could prove a modern CI/CD pipeline was secure end to end, the community built the OWASP Secure Pipeline Verification Standard, with auditable controls across Plan, Develop, Integrate, Release, and Operate. We support SPVS natively because our customers' AppSec teams are the ones accountable for it.

SPVS exists because the industry already settled this principle: application security owns the integrity of how software gets made, not just the artifacts that ship. The factory is in scope. Coding agents are now part of the factory.

The ADLC: a development lifecycle with autonomous actors inside it

Call the new shape of that factory the agentic development lifecycle, or ADLC: the SDLC with autonomous actors operating inside it. Agents plan tasks, assemble context, call tools, install dependencies, write and execute code, and open pull requests, in continuous loops that run alongside human developers.

The structural difference from the SDLC is where the risk lives. The SDLC's stages are checkpoints where humans hand off artifacts, and our controls evolved to inspect those artifacts: scan the code, scan the dependencies, and gate the pull request. The ADLC adds something between the checkpoints: sessions. An agent session is a runtime, and the risk inside it doesn't reduce to any artifact. A package install, a credential lookup, and an outbound connection can each pass inspection alone and constitute a breach together. The signal only exists across the trajectory.

Reading that trajectory takes development context: what the task was, which repo, what a normal workflow looks like. Endpoint tools see a process tree without a task, which is why this work can't simply be forwarded to the SOC. The context that makes an agent session legible is the context application security already holds.

Deterministic controls for non-deterministic actors

Governing agents also requires a control pattern AppSec happens to have spent fifteen years perfecting.

You cannot predict what a non-deterministic system will do. The same task can produce a different action sequence on every run, and there is no complete list of things a frontier model might try. So the control model can't depend on anticipating agent behavior. It has to bound behavior with mechanisms that fire the same way every time.

Application security has run this exact playbook twice. Branch protections and required reviews were deterministic gates on unpredictable humans. Pipeline gates and admission controls were deterministic gates on unpredictable automation. 

Hooks are the third instance of the same pattern, relocated into the agent loop: lifecycle events that fire before an agent executes a consequential action, evaluate the proposed action as data, and return a verdict. Allow, block, or escalate. We've written about how hooks work in practice, and their core property is the one that matters here: a hook is not subject to jailbreaks. Policy as code, gate placement, exception workflows. The muscle memory transfers directly.

Shared responsibility, single owner

None of this means AppSec does it alone. Pipeline security was always shared: platform engineering runs the infrastructure, DevSecOps automates the controls, AppSec defines and verifies the policy. SPVS assumes exactly that division of labor, and the ADLC inherits it. Platform teams will own the agent harnesses the way they own CI runners. The SOC keeps enterprise-wide detection. AI governance committees set intent.

But shared responsibility without a single accountable owner is how the OpenAI incident happens: everyone adjacent, nobody watching. The accountable owner for agent behavior inside the development lifecycle should be the team whose entire discipline is securing that lifecycle. 

Agent sessions are a new surface, and it's why we're building coding agent governance for application security teams: an inventory of the agents in use, deterministic policy at every consequential action, and a system of record for what every agent did, on whose machine, under which policy.

Want to discuss how to secure your ADLC? Contact us today for a demo of coding agent governance.