CaMeL (“Defeating Prompt Injections by Design,” Debenedetti, Shumailov, Fan, Hayes, Carlini, Fabian, Kern, Shi, Terzis and Tramèr, Google DeepMind, Google and ETH Zurich, 2025) takes a different approach: fix this with system design instead of a better prompt.

The idea

CaMeL splits the agent into pieces with different trust levels:

• A privileged LLM (P-LLM) sees only the user’s original, trusted query. It plans by writing a restricted Python program — calls like get_last_email(), query_quarantined_llm(), send_email() — but it never sees the content of tool outputs directly.
• A quarantined LLM (Q-LLM) is the only component that reads untrusted data (email bodies, web pages, file contents). It has no tool access, so even if injected instructions steer it, it can’t act on anything — it can only return a value back into the program.
• A custom interpreter executes the P-LLM’s plan and tracks, for every value, where it came from (a “capability”). If a variable was derived from untrusted data, the interpreter enforces security policies before letting it flow into a sensitive tool call — e.g. it can require explicit user approval before sending an email to an address that was read from an untrusted document.

Because the control flow (which functions get called, in which order) comes entirely from the trusted query, injected text in the data can change a value but never the program itself. That’s the “by design” part: security doesn’t depend on the model resisting a manipulative prompt, it depends on the interpreter refusing to let tainted data reach sensitive operations without a policy check.

The results back this up: on the AgentDojo benchmark, CaMeL solves 77% of tasks with provable security guarantees, against 84% for an undefended baseline. Across the 949 AgentDojo attack cases, CaMeL drives successful attacks to (or near) zero for every model tested — e.g. GPT-4o goes from 233 successful attacks without CaMeL to 0 with it, Gemini 2.5 Pro from 300 to 0 — and the paper notes that the handful of attacks AgentDojo still rates as “successful” against CaMeL aren’t actually prompt injections. The cost is real: the paper reports roughly 2.8x the input and 2.7x the output tokens for the median AgentDojo task, since the system now runs two LLMs and an interpreter instead of one model in a loop.

Applying the pattern to a setup like ours

Our own setup is a small team of agents — conductor, layout, writer, reviewer — coordinating over a repo, issues, and PRs. The same failure mode applies: a PR description, an issue comment, or a fetched web page could contain injected instructions aimed at whichever agent reads it.

The CaMeL-style fix would be to keep the conductor as the privileged planner: it decides which agent runs, on which branch, with which files, based only on the task and issue text it trusts. The writer and layout agents act like quarantined readers — they fetch and summarize untrusted content (a video page, an article, PR comments) but that content should never be able to trigger actions outside their own file edits. Anything derived from fetched content that would cross a trust boundary — committing, pushing, merging, changing CI, touching secrets — should require the conductor (or a human) to explicitly approve it, not be inferred from what an agent read.

We don’t have a capability-tracking interpreter; our “policy” today is informal (agent prompts, file-path restrictions, and a human-reviewed PR). That’s the gap CaMeL highlights: without something enforcing the boundary mechanically, we’re relying on agents behaving well, which is exactly the assumption CaMeL is designed to remove.

Limitations worth keeping in mind

CaMeL isn’t a free lunch. It needs the user (or system designer) to write and maintain sensible security policies, which is real ongoing effort. Approval prompts can be a source of fatigue — users who click “allow” reflexively erode the guarantee. And the ~2.8x/2.7x token overhead is a genuine cost for latency- or budget-sensitive agents. It also only protects what’s expressed as capabilities and policies; anything outside that model (side channels, timing, or actions the policy simply didn’t anticipate) isn’t covered automatically.

Still, the core idea — separate planning-on-trusted-input from reading-untrusted-input, and mechanically enforce what tainted data is allowed to touch — is a pattern worth designing toward, even before we have anything as formal as CaMeL’s interpreter.

The four agents

conductor (model: opus, tools: Agent, Read, Glob, Grep, Bash) is the entry point. It doesn’t build the site or write content itself — it reads the task or issue, sets up a feature branch, splits the work between the other two builder agents, and takes the result through to a reviewed PR. It’s explicitly barred from editing anything in docs/ itself; even a small fix gets delegated.

layout (model: sonnet, tools: Read, Write, Edit, Glob, Grep, Bash) owns Jekyll site structure: _config.yml, layouts, includes, styles, navigation, and the pages that render content. It’s responsible for keeping docs/CNAME intact, using only plugins GitHub Pages supports, and passing internal links through relative_url/absolute_url. It renders from the content sources the writer fills — posts and the “from the web” data file — rather than hard-coding text, and it doesn’t write articles itself.

writer (model: sonnet, tools: Read, Write, Edit, Glob, Grep, WebFetch, WebSearch — this is the agent producing the post you’re reading) owns content: blog posts in docs/_posts/ and “from the web” entries in docs/_data/from_the_web.yml. Its core rule is to check sources before summarizing them — fetch the linked video or article, don’t invent quotes or numbers — and, when it’s asked for a sample or placeholder entry it can’t fully research, to label it clearly as a draft rather than pass it off as finished. It stays out of layouts, includes, styles, _config.yml, and docs/CNAME.

reviewer (model: opus, tools: Read, Glob, Grep, Bash) checks a PR against its issue’s acceptance criteria and against GitHub Pages validity — front matter conventions, that docs/CNAME and _config.yml are intact, that referenced layouts and includes exist, that no build output got committed. It’s read-only: it can run read-only gh commands like gh pr view and gh issue view, but it never edits, commits, pushes, merges, approves or closes anything. Its output is a fixed format: a verdict of “approve” or “changes needed,” a checklist of acceptance criteria marked met, partially met or missing, and any required fixes labeled by which agent owns them.

The end-to-end workflow

1. Read the issue. The conductor runs gh issue view <N> and treats its intent and acceptance criteria as the definition of done. If the task is genuinely ambiguous, it asks the user rather than guessing.
2. Branch. It creates a feature branch from an up-to-date origin/main — never working directly on main — named for the intent of the work, and keeps using that branch for the rest of the session.
3. Delegate, layout before writer. Structure and styling go to layout; posts, entries and copy go to writer. When a task needs both, layout runs first so the writer fills structures that already exist. Each agent gets a self-contained brief — the issue’s intent, the specific acceptance criteria it owns, and the relevant conventions — because the sub-agents don’t see the conductor’s conversation.
4. Check the result. The conductor reads the changed files itself and confirms every acceptance criterion is covered before moving on.
5. Commit, push, open the PR. The conductor commits with a descriptive message, pushes, and opens or updates the PR via gh pr create/gh pr edit, including Closes #<N> for the linked issue.
6. Review. The conductor spawns the reviewer with the PR number. If the verdict is “changes needed,” it routes the concrete fixes to whichever agent owns them, then commits, pushes, and re-reviews. It repeats this for at most five fix rounds — if it still fails after the fifth, it reports what’s left rather than retrying indefinitely.
7. Report. The conductor tells the user the PR link, the final review verdict, and anything that wasn’t verified — for example, a Jekyll build it couldn’t run locally.

How it gets started

There’s no dashboard or scheduler behind any of this. A session starts with claude --agent conductor and a task like “work on issue #6” — the conductor takes it from there. Each agent can also be invoked directly for narrower work, bypassing the conductor entirely.

Guardrails

A few constraints run across the agent definitions and CLAUDE.md:

• No force-push, no merging, no closing issues. This rule lives in conductor.md: the conductor is explicit that merging a PR is the user’s call, not something an agent does on its own.
• Only GitHub-Pages-supported plugins. Since the site builds natively on GitHub Pages with no CI, layout can’t reach for custom Ruby plugins or anything outside what github-pages ships.
• The writer fetches before it summarizes. No quotes, numbers or claims get written up without checking the source first, and if it can’t access a source, it says so and writes only what it can support — anything unverifiable is left out rather than invented.
• The reviewer is read-only by instruction, not by tooling alone. Its tool list is Read, Glob, Grep, Bash — no Write or Edit — but Bash itself can write, commit and push. What actually keeps it from doing that is its prompt: only read-only gh commands (gh pr view, gh pr diff, gh pr checks, gh issue view), a rule to never edit, commit, push, merge, approve or close anything, and a PR comment only when its caller explicitly asks.
• A committed allowlist backs some of this up. .claude/settings.json pre-approves only read-only gh commands (pr view/diff/checks/list, issue view/list) and read-only git commands (status, log, diff, show, ls-tree, branch listing). Any other Bash command — a push, a commit, a file write through the shell — still needs a permission prompt unless the session’s permissions allow it.
• Path ownership stays fixed. Posts and data files are the writer’s; _config.yml, layouts, includes and styles are layout’s; the conductor edits neither directly. Those content paths and field names are kept consistent across the writer, layout and reviewer prompts specifically so they don’t drift apart.

Trade-offs, honestly

Some of this is genuinely enforced, and some of it isn’t. What Claude Code actually enforces is each agent’s tools: allowlist in its frontmatter: the writer has no Bash at all, and the conductor and reviewer have no Write or Edit — so, for example, the reviewer literally cannot call a file-editing tool, whatever its prompt says. .claude/settings.json adds a second, committed layer on top: it pre-approves only read-only gh and git commands, so anything else run through Bash — a push, a commit, a shell-based file write — still needs a permission prompt rather than running silently.

What isn’t enforced this way is finer-grained: which specific paths under docs/ an agent should touch is prompt-level, not tool-level — layout could technically call Write on a file in _posts/, and nothing path-specific stops it: any permission check it hits is the same one that covers its legitimate writes to layouts and styles. The agents that carry Bash — conductor, layout and reviewer — aren’t kept from running something like gh pr merge or git push --force by their tool lists either; those commands simply aren’t in the .claude/settings.json allowlist, so running them still triggers a permission prompt. For the conductor and reviewer, what stops them is that prompt plus an explicit instruction never to merge or force-push — and, for the reviewer, never to push at all. Layout’s prompt says nothing about merging or pushing, so for layout the permission prompt is the only check there is; a user approving it, or a session with permissive settings, removes that check with nothing behind it.

Separately, any of the agents also reads content from outside the conversation — issue text, PR comments, a fetched article — and a CaMeL-style design would treat that as untrusted input that shouldn’t be able to trigger actions on its own. Today that boundary is informal: agent prompts, file-path conventions, permission prompts, and a human deciding whether to merge.

The five-round review limit is also a real trade-off: it caps how long the conductor will iterate before handing a problem back to the user, which keeps sessions bounded but means some issues need a manual pass rather than getting fully closed out by the agents alone. The cap used to be one round, and it moved to five for a mundane reason: while this post was being drafted, the second review of its own PR still found issues after the single allowed fix round, so the user raised the limit rather than absorb every leftover fix by hand.

A meta note

This post is itself an example of the workflow it describes: it resolves issue #6, “New Blog Post: Current Agent setup,” and was produced by the conductor delegating to the writer, with the reviewer checking the result before it went out. Every claim about the setup is drawn directly from CLAUDE.md, the four agent definitions in .claude/agents/, and .claude/settings.json as they exist in this repository — nothing here is aspirational. The one exception is the cap-history detail above, which comes from this post’s own review history rather than from those files.