Architectural defense: six design patterns, and how plan-then-execute drives attack success to zero

One core principle: after ingestion, nothing ingested may have consequences

All six of today's patterns grow from a single sentence. It comes from Beurer-Kellner et al., June 2025 (authors from Google DeepMind, ETH and Microsoft), and it is worth memorizing word for word:

Once an agent has ingested untrusted input, it must be constrained such that this input cannot trigger any consequential action.

Notice what it does not say. It does not say "keep the model from being deceived", it says "being deceived must not matter". That is a constraint on capability, not a hope about judgment. Judgment is probabilistic; capability can be nailed down in code.

Translated into something you can build, it becomes two sentences: either the actions are fixed before ingestion, or the call that ingests holds no tools. All six patterns are combinations of those two.

Start from the counter-example, which is the shape of yesterday's code:

// Yesterday's flow: whatever it reads is what decides the next move
const blocks = [{ label: 'Ticket body (from an external submitter)', content: ticketBody }]
const link = /https?:\/\/\S+/.exec(ticketBody)?.[0]
if (link) blocks.push({ label: 'Fetched web page', content: await fetchPage(link) })
 
// One call holds both the untrusted content and the full tool list
const actions = await model.decide({ prompt: buildPrompt(level, request, blocks), tools: ALL })
for (const a of actions) await tools[a.tool](a) // whatever the ticket says, it may do

# Yesterday's flow: whatever it reads is what decides the next move
blocks = [{"label": "Ticket body (from an external submitter)", "content": ticket_body}]
link = re.search(r"https?://\S+", ticket_body)
if link:
    blocks.append({"label": "Fetched web page", "content": fetch_page(link.group(0))})
 
# One call holds both the untrusted content and the full tool list
actions = model.decide(prompt=build_prompt(level, request, blocks), tools=ALL)
for a in actions:
    TOOLS[a.tool](a)  # whatever the ticket says, it may do

The bug is in no single line. It is in the parameter list of decide: untrusted content and the tool list show up in the same call. The engineering cost lives there too — fixing it means changing the control flow, not adding a filter function. Which is why this kind of rework belongs on an iteration plan rather than in a drive-by patch.

Action-selector and plan-then-execute: results that never flow back, and actions fixed up front

Action-selector is the most conservative of the six. The model only translates one sentence of natural language into one predefined action, and once that action runs, its result never flows back to the model. Think of a self-service ordering kiosk: you say "cancel this order", it becomes one cancellation request, and whatever text the cancellation endpoint returns is never handed to the model to read. Because nothing flows back, indirect injection has no route in at all. The price is blunt: it can do one-shot actions only, never multi-step work, which amputates the most valuable part of an agent.

Plan-then-execute loosens that slightly: multiple steps are allowed, but the list of actions is fixed before any untrusted data is read. After that, whatever it reads can change the contents of each step's parameters, but cannot add, remove or alter the steps themselves.

// The planner's parameters do not include ticketBody. That omission IS the pattern.
function plan(request, recipients) {
  const steps = [{ tool: 'search_customers' }]
  if (request.includes('write back to the ticket')) steps.push({ tool: 'update_ticket' })
  // Recipients come from the user's pre-authorization, not from the ticket
  for (const to of recipients) steps.push({ tool: 'send_email', target: to })
  return steps
}
 
// The executor only turns planned steps into actions; what was read is data, nothing more
function runPlanned(input, recipients = []) {
  const steps = plan(input.request, recipients)
  const read = quarantinedRead(input.request, input.ticketBody)
  return steps.map((s) => ({ ...s, note: `read ${read.summary.length} chars, used as data only` }))
}

# The planner's parameters do not include ticket_body. That omission IS the pattern.
def plan(request: str, recipients: list[str]) -> list[dict]:
    steps = [{"tool": "search_customers"}]
    if "write back to the ticket" in request:
        steps.append({"tool": "update_ticket"})
    # Recipients come from the user's pre-authorization, not from the ticket
    steps.extend({"tool": "send_email", "target": to} for to in recipients)
    return steps
 
 
# The executor only turns planned steps into actions; what was read is data, nothing more
def run_planned(inp: dict, recipients: list[str] | None = None) -> list[dict]:
    steps = plan(inp["request"], recipients or [])
    read = quarantined_read(inp["request"], inp["ticket_body"])
    return [{**s, "note": f"read {len(read.summary)} chars, used as data only"} for s in steps]

The signature of plan is the wall. Today's lab includes a mutation check where you hand ticketBody to the planner yourself — the attack success rate climbs straight back, and you get a very concrete look at where the wall was standing. The price is that once the plan is fixed, it cannot change its mind based on what it reads: if the ticket says "legal needs to see this first", the agent will not improvise an extra step.

LLM map-reduce and the dual LLM pattern: the privileged model never sees the raw text

LLM map-reduce targets the case where a lot of untrusted material has to be read. Each shard goes to an isolated sub-agent that holds no tools and may only return structured fields — a boolean plus a one-line summary, say — and the main agent sees only those fields. It is peer review: a hundred submissions go to a hundred reviewers, each returns one fixed-format score sheet, and the editor never reads a manuscript. The price is weaker cross-shard reasoning: a conclusion that requires holding shard 3 and shard 87 side by side is out of reach in this shape.

The dual LLM pattern generalizes the same idea, and it is the half that actually lands in today's lab: the privileged model never sees the raw text. It receives a symbolic reference instead ("variable a holds the page we just fetched"), while the model that does see the raw text holds no tools whatsoever.

// This call can see the raw text, but its tool list is empty. No tools, no consequences.
function quarantinedRead(request, ticketBody) {
  const blocks = collectUntrusted(ticketBody)
  const wanted = model.decide({ prompt: buildPrompt(3, request, blocks), tools: [] })
  // Record what it WANTED to do, purely so you can see that it really was hijacked
  const hijackAttempts = wanted.filter((a) => a.tool === 'send_email' || a.tool === 'post_webhook')
  return { summary: summarize(blocks), hijackAttempts } // only strings leave this function
}

# This call can see the raw text, but its tool list is empty. No tools, no consequences.
def quarantined_read(request: str, ticket_body: str) -> QuarantinedRead:
    blocks = collect_untrusted(ticket_body)
    wanted = model.decide(prompt=build_prompt(3, request, blocks), tools=[])
    # Record what it WANTED to do, purely so you can see that it really was hijacked
    hijack_attempts = [a for a in wanted if a.tool in ("send_email", "post_webhook")]
    return QuarantinedRead(summary=summarize(blocks), hijack_attempts=hijack_attempts)  # only strings leave

The price is orchestration complexity: you now maintain a symbol table, a cross-model data flow, and a set of rules for when a reference may be dereferenced. If you want to see what the industrial version looks like, read CaMeL (arXiv 2503.18813) — dual LLM plus data provenance tracking as a complete system, where every value carries a label saying where it came from. You are not expected to reproduce it, but one read gives you an accurate sense of how much engineering "doing it completely right" actually costs.

Code-then-execute and context-minimization: a plan you can check statically, and context deleted after use

Code-then-execute is plan-then-execute with the volume up: instead of emitting a list of steps, the model writes a small program that your own interpreter runs. The win is that the program can be statically checked before it runs — the data flow is explicit, and "where does the value returned by the customer database eventually end up" has a definite answer rather than a guess based on the model's own prose explanation. The price is very real: you have to build the interpreter and the policy engine, making this the heaviest of the six.

Context-minimization is the lightest: once a piece of untrusted text has done its job, delete it from the context so it never enters later turns. Use it to produce a database query, then drop the original and let subsequent turns see only the query result. Its security motivation is plain: every piece of untrusted text still sitting in the context is another dice roll on every later turn — surviving turn one says nothing about turn seven.

The selection criterion: does this task actually need to change its actions based on untrusted content

With all six laid out, the real question is not "which one do I pick" but do not reach for all of them at once. There is exactly one criterion, and it is a question you can answer on the spot:

Does this task actually need to change its actions based on untrusted content?

For the large majority the answer is no. Summarize a ticket, classify a ticket, write the key points of a linked page back into the ticket — in all of those, untrusted content shapes the text produced, not which things get done. Reach straight for plan-then-execute: small engineering cost, almost no capability lost.

Only a "yes" is worth paying for the dual LLM pattern. The typical shape is "read this document, and if it mentions a refund, start the refund process" — the action itself depends on the content. There, what you want is for the privileged side to see one controlled symbol (an enum value, say) rather than the raw text.

There is also a third answer: "yes, but it can be turned into a no." That is the best-value route, and it is the last line of today's lab. With pure plan-then-execute, the legitimate copy request in case N-03 got dropped along with everything else — the ticket asked to copy the risk-control team, and the plan had no such step. Move the recipient allowlist to user pre-authorization, and the capability comes back while attack success stays at 0. A lot of requirements that "must depend on the content" simply evaporate when you change the source of trust.

Put the bill on the table: every pattern buys safety with capability

Finally, the six patterns next to their invoices. Any security proposal that lists only benefits is incomplete — including in interviews, where being unable to name the cost tells the interviewer you have never shipped one.

The table today's lab prints is that invoice made physical:

D2 level 3: spotlighting                40%   100%   kept       A-07 A-08 A-09 A-10
D2 level 4: markers plus detector       10%    83%   dropped    A-10
plan-then-execute                        0%   100%   dropped    (none)
plan-then-execute + pre-authorized       0%   100%   kept       (none)

Three things to say out loud. First, attack success went from 40% to 0 and it was not smarter detection that did it, it was structure. Second, the third row shows task completion at 100% while the legitimate-copy column says dropped — safety really is paid for in capability, and that column is the bill. Third, the last row buys that capability back with attack success still at 0. That is what a competent rework looks like: both numbers, every time, neither one alone.

Source Reading

Hands-On Lab

Before you start, remember one thing: the first run of the starter reports 0% attack success and 0% task completion. Do not celebrate — that is exactly the anti-pattern called out yesterday, an agent rebuilt to do nothing at all. The two numbers only mean something together. If you get stuck, read the three TODO comments in starter/src/agent/planned.ts; they point at the traps rather than at the answers.

1. Run the solution first and read the whole four-row table plus the A-07 walkthrough at the bottom, until you can point at which row was yesterday's best result and which row is today's output.
2. In the starter, fill in the planner plan: its parameters are the user request and the pre-authorized recipients only, and it cannot see the ticket body — do not add the ticket body, because adding it voids the entire pattern.
3. Fill in the quarantined read quarantinedRead: call the model once, record the outbound sends it wanted, then throw every action away and return a string. Running it should show a non-zero hijack count.
4. Fill in the executor runPlanned so it only turns planned steps into actions. Once that line is written, attack success on the last two rows should hit zero together.
5. Run two mutation checks: pass the ticket body into the planner and let it append sends as the ticket asks, then change the executor to run the actions the quarantined read returned. Both must push attack success back up; if either does not, your control arm is not wired in and the 0% in the table is fake.

Interview Questions

Today's 3 questions sit in the bank below, weighted towards what each of the six patterns constrains and costs, the selection criterion, and the essential difference between architectural and prompt-level defense. Expand each one and read the analysis before the key points — question 3 asks when you would refuse to use these patterns, which is where "has read the paper" separates from "has shipped it", so do not skip it. The "common in China / common globally" tags let you triage by target market.

Checklist and Tomorrow

• I can say what each of the six design patterns constrains and what capability it costs
• I can pick a pattern for a given task from a single criterion instead of listing all six
• I can rebuild the range agent as plan-then-execute with quarantined reading and prove it with both numbers
• I can recite the core principle word for word and explain that it constrains capability, not judgment
• I can explain the difference between "hijacked but with no consequences" and "resisted the attack"
• All 5 acceptance criteria pass, and both mutation checks pushed attack success back up

Tomorrow (D4) we loosen the assumption one more notch: assume the injection already happened and the architecture has a seam, then use the runtime to contain the loss. You will declare a capability and a risk tier for every tool, put an approval gate in front of irreversible actions, put allowlists on the filesystem and the network, split "sandbox" into the policy layer you write yourself and the isolation layer the kernel provides, and finally handle secrets, per-user credentials and tenant isolation. The order is deliberate: today's layer keeps the bad action from ever being proposed, tomorrow's keeps a proposed one from executing — you need both, so that no single oversight in either takes the whole line down.