One SDLC, two kinds of author: securing development when AI agents write the code

A lot of teams now have two kinds of author in every repository. One is a person. The other is a coding agent with a shell, a package manager and permission to commit.

A common question is whether that calls for a separate "AI SDLC" running alongside the normal one. The security frameworks, the research and the incident record point to a different answer:

Keep one lifecycle, and add a security profile for AI-assisted development on top of it.

The code problem hasn't gone away

Newer models haven't made the "AI writes insecure code" problem disappear.

Veracode's 2026 GenAI Code Security Report tested more than 100 models and found an average security pass rate of 56%, which it described as "virtually unchanged" from the year before (Veracode). That's a vendor study scored with its own scanner, and the models were tested without any security prompting. Still, the trend line is flat.

Agents working on real repositories are a newer area of research, and results swing a lot with the model, the agent harness and how much supervision it gets. The finding that keeps repeating is simpler: working code and secure code aren’t the same thing. A green test run tells you the feature works, not that it’s safe.

Then there's the human side. In Stanford's study at ACM CCS 2023, developers using an AI assistant wrote less secure code and were more confident that it was secure (arXiv). That combination is the dangerous part: review gets lighter exactly when it should get heavier.

![A software lifecycle loop with a human and an AI working together inside a security shield]

The agent itself is new attack surface

Insecure code is the familiar half. The newer half is that the agent is a privileged process on a developer's machine, and it reads a lot of untrusted text.

Over the past year, pretty much every major coding tool has had a vulnerability where opening a malicious repository could lead to code execution or leaked credentials:

• GitHub Copilot (CVE-2025-53773): injected instructions got the agent to switch on auto-approval in .vscode/settings.json, then run commands (Wiz).
• Cursor (CVE-2025-54135 and CVE-2025-54136): injection through MCP data, and an already-approved MCP config silently swapped for a malicious command (Tenable).
• OpenAI Codex CLI (CVE-2025-61260): a repository's config made MCP commands run at startup without approval (Check Point Research).
• Claude Code has had its own command-parsing bypasses, such as CVE-2025-58764 (advisory).

These are patched. The lesson that stays is that repository config, rule files and MCP definitions have become an execution path. Simon Willison's "lethal trifecta" explains why: an agent with access to private data, exposure to untrusted content and a way to send data out is an exfiltration tool waiting for the right prompt (Simon Willison).

The supply chain shows up too:

• Package hallucination. In the USENIX Security 2025 study, commercial models recommended packages that didn't exist 5.2% of the time, and open-source models 21.7% of the time, across 205,474 unique made-up names. Anyone can register those names (arXiv).
• Malicious MCP servers. postmark-mcp, the first one found in the wild, quietly BCC'd every email it sent to the attacker (Koi). Anthropic's own docs are clear that it "does not security-audit or manage any MCP server" (Claude Code security docs).
• Malware that drives your agent for you. The compromised Nx npm package in August 2025 looked for locally installed AI CLIs and prompted them to search the disk for secrets (StepSecurity).
• Compromised tooling. An Amazon Q Developer extension release for VS Code shipped with an injected instruction to delete local files and cloud resources, after an over-scoped GitHub token let an attacker commit to it. AWS says the payload didn't execute because of a syntax error (AWS-2025-015).

Why one SDLC, not two

After all that, a dedicated "AI SDLC" can look like the obvious response. The major security frameworks don't recommend one.

NIST's profile for generative AI is blunt about it. Its practices "do not distinguish between human-written and AI-generated source code, because it is assumed that all source code should be evaluated for vulnerabilities and other issues before use" (NIST SP 800-218A). The profile also only works on top of the main SSDF, not instead of it.

The others say the same thing in different words. OWASP's Top 10:2025 puts it simply: "You are responsible for all code that you commit" (OWASP). CIS and SAFECode say AI-generated code should get "the same testing, review, and validation processes as human-written software." The Cloud Security Alliance's draft Agentic Secure Development Lifecycle says it "does not replace traditional SDL practices. It extends them" (CSA).

Even Anthropic's own AI-native SDLC playbook frames it as one lifecycle that "combines the old control objectives with new enforcement" and "has to fit around what exists" (Anthropic).

There's a practical argument too. Human and AI code end up in the same pull request, so there's no clean line to route work down. And if there are two tracks with different gates, people will use whichever one has fewer gates.

What's actually new: the agent as a privileged actor

So the code goes through the same gates. What genuinely has no home in a traditional SDLC is governing the agent itself: what it can read, what it can run, which tools and MCP servers it talks to, what identity it uses, and what it logs. That's closer to CI/CD platform security than to a second lifecycle.

![A friendly robot coding inside a glass sandbox while a developer holds approve and stop buttons]

A starting profile for AI-assisted development

A reasonable starting set of controls is below. None of it is exotic, and most of it is configuration rather than process.

Approved tools and accounts. Use enterprise or commercial plans only. The account type decides whether your code can be used for training: Anthropic, for example, separates consumer plans from commercial ones on exactly this point (data usage). Funding approved seats beats banning tools, because bans push people to whatever they can sign up for themselves.

Keep sensitive data out of agent sessions. No production data, customer data or secrets in prompts or in the files the agent can read. Agents can read whatever the developer's account can read unless you restrict them, so deny access to .env files, connection strings and certificate stores, and use synthetic test data.

Central, managed agent settings. Most coding agents now support policy that IT can push and developers can't override. For Claude Code that means managed settings that disable bypass mode, allow only managed hooks and approved MCP servers, and turn on audit telemetry (managed settings). Check every key against the current docs before you deploy, because these change.

Isolation where it matters. Run agents in containers or VMs for untrusted repositories, which is also Anthropic's own advice. Note that Claude Code's built-in sandbox doesn't run on native Windows, so Windows-heavy teams should lean on WSL2, dev containers or VMs (sandboxing).

Treat agent config as code. Put CODEOWNERS on .claude/, .mcp.json, .vscode/, CLAUDE.md and AGENTS.md, and scan for hidden Unicode in rule files.

Human review with separation. Agents shouldn't push to main, and the person who prompted the agent shouldn't be the only approver. GitHub's Copilot cloud agent is a good reference model: it can only push to its own branches and can't approve its own pull request (GitHub docs).

Label AI-assisted changes. A co-author trailer or a pull request checkbox costs nothing. It lets you measure whether AI-assisted changes carry more findings, and it helps you scope an incident later.

Gate new dependencies. Route packages through an approved feed or proxy, use lock files, and put a review step on any new package. That's your defence against invented package names.

Tier the risk by code area. The UK NCSC's "vibe coding spectrum" says to "slide left (towards manual)" for authentication, secrets and sensitive personal data (NCSC). In practice that means tests and docs can take more agent autonomy, while auth, crypto and anything touching personal data stay human-led with deep review.

Log what the agent does. Send agent telemetry to your SIEM and alert on things like bypass mode being switched on or a new MCP server appearing.

If you're in Australia, the OAIC's guidance on commercial AI products is worth reading alongside this, especially if you handle health or other sensitive information (OAIC).

Where to start

These controls don't have to arrive all at once. Many of them are a settings change or a repository rule, so they can be adopted one at a time, starting with whichever gap worries you most.

One thing to keep separate: securing AI features inside your product is a different problem, with different controls (prompt injection in your app, model supply chain, output handling). It deserves its own profile rather than getting folded into this one.

A few community "AI SDLC" frameworks have appeared on GitHub this year, and some have good ideas, like tracing requirements to tests or leaving every change for human review before it's committed. Most say very little about security, and that's the part worth adding.