Guarding
the Gates

In August, a researcher asked a widely used coding agent to summarize a web page. A few ordinary steps later, it was running a stranger's code. Nobody told it to.

Johann Rehberger built and published the chain. Figure 5 lays out the seven steps and, under each, the layer that should have refused:

1. The agent is asked to summarize a web page.
2. The page turns away the agent's built-in web reader, so the agent fetches it with a plain download from the command line instead.
3. The download is redirected to an archive: an encoded file, a decoder, and some helper files.
4. The agent sensibly declines to run the stranger's decoder and writes its own.
5. It changes into the folder it just unpacked and runs its decoder from there.
6. One of the helper files has the same name as a piece of Python's standard library. Python looks first in the folder it's running from, which the attacker had just filled, so the decoder loads the attacker's version.
7. That code quietly starts a background process that fetches and runs a second stage.

He ran three variants five times each and saw it land in 10 of the 15 runs, and he calls that a small sample.

The vendor closed his report as working as designed. In his account of their reply, the agent's automatic mode is a convenience backed by a best-effort classifier, not a security guarantee; the real boundary is isolating the process and controlling where it can connect. That's the vendor's position as much as his, and it's the right one. (His write-up has the details.)

The simplest fix I can see for steps 5 and 6 is one line: never run a helper from inside a folder an attacker filled, or run it in Python's isolated mode, which skips that folder. (Fittingly, the attacker's own second stage ran in isolated mode.) I'd clip that, but I wouldn't treat it as the whole answer: it closes this route, not every way an attacker could chain through a helper the agent trusts. It's also the least interesting lesson here.

Text description of Figure 5

A published attack chain drawn as seven steps. 1: the agent is asked to summarize a web page. 2: the page refuses the agent's reader, and the agent switches to a command-line download. 3: a redirect delivers an archive. 4: the agent declines the supplied decoder and writes its own. 5: it runs that decoder inside the extracted folder. 6: a planted file shadows a standard library module. 7: a detached background process downloads and runs a second stage. Four steps are marked as boundary crossings and three as ordinary-looking work. Under each step is the layer that should have refused it: intent, transport, content, transformation, and runtime and network egress.

Most agent-safety talk is about what an AI may do. This chain started with what it was allowed to read.

Every useful agent reads the outside world: search results, pages, newsletters, papers, tool output, messages from other agents. Any of it can carry instructions, and a language model has no reliable way to tell "text I'm reading" from "text I'm being told." Training helps; it doesn't settle it, and even OpenAI says it may never be fully solved. That's prompt injection, and it tops OWASP's list of risks for LLM applications.

The instinct is to make the agent more suspicious: teach it to spot injections, filter the obvious ones, add a classifier. Those are useful layers. But the agent asked "should I run this?" once, about the obvious file. Every other step was a reader quietly becoming something else: a downloader, an unpacker, a place where code ran.

Here's why it matters to me. My agents work across my projects, so one that a web page talks into something could reach as far as they do.

So the rule I've ended up with isn't "trust content less." It's this: content may inform; it may never instruct. Outside content can change what I know. It can never change what an agent is allowed to do.

The field has done good work here. I group the published work into five patterns. Each is a trade-off, and the price is rarely money: it's tokens and time, tasks that get harder to finish, a person's attention, or flexibility.

Keep two of three. Simon Willison named the lethal trifecta; Meta turned it into the Agents Rule of Two. Within one session and without a person in the loop, an agent should hold at most two of three: untrusted input, access to sensitive data or systems, and the ability to change things or talk to the outside world. You give up the all-three agents people most want, or a person's time approving the third.

Separate the reader from the actor. A quarantined model reads the untrusted content and can only hand back data; a privileged model plans and acts but never sees the raw content. That's Willison's dual-LLM pattern. Google DeepMind's CaMeL adds an interpreter that tracks where each value came from and what it may touch. You give up more machinery and some task success.

Plan before you read. Decide which steps you'll take before untrusted content arrives, so it can't add or reorder them; it's one pattern in a good catalog. You give up flexibility. And as I read it, a plan protects which steps run, not the values that fill them. A link, a recipient or a file path taken from the page is still where an injection lands.

Control the exits. If code does run, it runs somewhere that can't reach the network, holds no secrets and doesn't outlive the task. You give up real infrastructure to build, and friction for legitimate work that needs the network.

Watch the composition. Treat a change in the kind of action as a new decision: reading becoming downloading, downloading becoming running. That's the chain above. It's the least settled of the five and the one the Kingdom leans on hardest. You give up attention to false alarms.

One caution hangs over all five. In The Attacker Moves Second, researchers took 12 published defenses that reported near-zero attack success and broke most of them, above 90% of the time, with adaptive attacks: attackers who see what failed and try again. A defense measured against yesterday's attacks tells you about yesterday.

The Kingdom is my working system: separate project workspaces I call houses, each with its own job, sharing one set of tools. Some houses watch the outside world on purpose, and those standing feeds come in through one route: Bellows. When I say "the gate," that's what I mean. It isn't the only way outside text gets in. When an agent searches the web mid-task, as the ones helping me write this did, the results come straight back into its session. There the rule is simpler: what it reads is data, not instructions.

Bellows started in July as a news-watcher. When a house paused a decision, it wrote down what news would reopen it. Each morning Bellows checked research feeds and specification releases against those written questions, so relevance came from what we'd written, not from a guess.

Three weeks later I shut it down. Before connecting more houses, I had my agents threat-model their own tooling from the attacker's side, and that review found Bellows pasting web text straight into notes the whole Kingdom later reads. Nobody had exploited it; I stood it down as a precaution. The pasting was the danger. That's persistent injection, or memory poisoning: one bad page could plant instructions every future session would meet. It also had write access across the Kingdom and nobody watching. Untrusted content, private data and the power to act, all in one unattended job: the Rule of Two, broken three ways at once.

It came back rebuilt around four parts.

Text description of Figure 6

Outside content flows left to right. A standing question is written first. A simple matcher drops anything that doesn't overlap a live question. What matches lands in quarantine at the lowest trust grade, fenced and hashed. A vertical authority line follows: content never crosses it as an instruction. Only a person can promote a card, and the decision is recorded with who and when. Promoted research joins a catalog that informs decisions and never fires an action. Below, a separate path shows research inside a task going around the gate; it relies on procedure, not on the gate.

1. The question comes first. Before anything is read, a house writes down what decision it informs, which terms would make something worth a look, and what a real signal would change.
2. A deliberately simple matcher. Bellows keeps what overlaps those questions and drops the rest. It's a keyword filter, gameable by design, so nothing downstream trusts it.
3. Quarantine. What matches lands as a card: a short note that code builds from a fixed set of fields. Every outside field is fenced, set off by markers as quoted text, never pasted in as instructions. Each card carries a trust grade, a label for how far we rely on it, and starts at the lowest. No card can raise its own grade, whatever it says.
4. A person decides. A person reads the card and decides whether it's worth anything, and the decision is written down with who made it and when. Raising a card's grade (we call it promoting) lets it inform a decision; it never becomes a step an agent runs. When an agent later reads a promoted card, it reads it as quoted material under the same rule.

Each piece was proven on its own. The regression tests include a deliberately broken copy of the old matcher, kept to prove the tests still catch an escape. A small, runnable version of Bellows is on GitHub, with a hostile test card that tries to close its own fence and promote itself. It stays inert. That's a parser test, with no model in the loop.

Bellows runs supervised, not yet on a schedule everywhere it should. That's on me, and it's on the list.

Would Bellows have stopped the chain at the top of this piece? No. That attack never goes near it: it happened while an agent was reading in the middle of a task, which is a different path. Had the same page come in through Bellows, it would have landed as a fenced card, and Bellows doesn't download archives or run anything. That's a design claim, not a tested one.

In September, after reading the disclosure, I asked Foundry, the house that keeps the shared tools, to map every way outside material gets in and tell me where we were exposed. Its verdict: the Kingdom has many of the right ideas, but "the strongest guarantees are still procedural." That means much of the safety depends on an agent following instructions correctly, not on something that physically refuses.

The pattern	Where the Kingdom stands
Keep two of three	Outside research informs and never acts; a person raises trust. Partly procedural.
Delimit and label (procedural)	Outside text is fenced as quoted data. There's no separate reader model.
Plan before you read	Questions are written before content arrives, at the gate. Procedural elsewhere.
Control the exits	Sandbox defaults and rules. Making outbound-network controls uniform is next.
Watch the composition	A written rule that reading-to-running is a new kind of action. Still a rule, not a check.

Two gaps sit under that table. Research inside a task relies more on procedure than the gate does. And nothing yet checks, by mechanism, where a link or file path from a card goes once someone acts on it; today that's procedure too. Both are named targets of the test below.

None of this was news by August. The evidence was already loud.

• It's in the wild. Google reported a 32% relative rise in the share of crawled pages carrying malicious hidden instructions between November 2025 and February 2026. Forcepoint found live examples, including a hidden delete command aimed at coding agents asked to summarize the page. That's the "control the exits" and "watch the composition" rows, in public.
• No model is the boundary. NIST's AI standards center showed new attacks raising hijack success against one leading model from 11% to 81% on the AgentDojo benchmark (January 2025). In a red-team competition run with Gray Swan and the UK AI Security Institute, at least one attack succeeded against all 13 frontier models tested (March 2026). That's why the reader-and-actor row matters more than the model's cleverness.
• The standards name the chain. OWASP's Top 10 for Agentic Applications (December 2025) puts agent goal hijack first and lists unexpected code execution: this piece's opening, in two lines.

For the Kingdom, the lesson I take is simple: the parts still held only by procedure, a rule someone has to remember, are the ones worth hardening next.

I once called the Kingdom's security carefully designed and barely attacked. Truer: tested one piece at a time, never by an adversary who chains attacks. That's the test.

Cupel, the Kingdom's lab, measures. A separate offensive team attacks. I write it up and agree the rules first. That's internal separation of duties, not third-party testing.

• A disposable range. A sealed test setup: harmless markers instead of payloads, fake credentials, nothing reachable outside it, and no real targets.
• The bar written first. For each attack family, before anything runs, we write down which layer should refuse it first. Figure 5 is a rough version of that bar for the opening's chain.
• Families, not a score. Redirect chains, booby-trapped archives, files that shadow trusted names, processes that outlive the task, tool responses that claim authority they don't have, a file swapped between the check and the use, and sources that steer by repetition.
• An attacker who adapts. A budget of attempts per family, repeated runs because models aren't deterministic, and an attacker who sees what failed and tries again.
• Two targets, four measures. The gate, and an ordinary research session in a house. For each: did the attack complete, which layer refused first, did anything reach the network that shouldn't have, and how often the defenses refused something harmless.
• Me. A person is part of this gate, and people can be fooled or tired. The test includes cards built to talk me into promoting them.