A God Agent is one model wired to every tool on one shared identity, holding the whole lethal trifecta at once: it reads untrusted content, touches private data, and talks to the outside world. You can't filter prompt injection out of that, so you change the architecture instead. Three deterministic moves: scope every agent, sign every call, stop every breach. Break even one leg of the trifecta and the blast radius shrinks.
The mental model we use to decide what to build at raxIT. I gave it as a talk at AI Engineer Melbourne. This is the written version, with the parts that didn't fit on a slide.
Last week I gave a talk in Melbourne called "Kill the God Agent". It wasn't really a security talk. It was a talk about a mental model we use to decide how to build, and the best thing that happened was afterward. A handful of people came up and said some version of the same thing: "I'm going to take one of these and do it our own way back at work." That's the whole point. So I wrote it down.
Here's the belief the whole thing hangs on. Prompt injection is not solved, and I don't think it will be. Build like you've already been compromised through it. I said that on stage and offered to debate anyone who disagreed. Nobody took me up on it.
Prefer to watch? Here's the full talk from AI Engineer Melbourne, the version this post is written from.
Gray Swan ran a public competition with the frontier labs and tested 13 models against indirect prompt injection. Every single one was exploitable. The best was Claude Opus 4.5 at a 0.5% attack success rate. The worst was Gemini 2.5 Pro at 8.5%. You can read the paper if you want the full table.
People hear 0.5% and relax. Don't. Run a trillion-parameter model in production and 0.5% is still about five billion ways in. And this is already happening in the wild, not in a lab: a prompt-injection code-execution CVE in GitHub Copilot Chat, data walked out of Slack AI through content it was asked to summarize, Claude talked into minting unlimited Stripe coupons. So no, no model is safe. They're getting less unsafe, which is a different thing.
If you can't filter the attack out, the model isn't where you fix this. The architecture is.
A God Agent is one model wired to everything. One brain, a belt of tools, the browser, the shell, the filesystem, email, search, all of it, running on one shared identity.
The God Agent. One model, every tool, one identity. Very useful, and very hard to make safe.
It's genuinely useful. It's also the reason enterprise adoption of these things is close to zero in a lot of the rooms I sit in. To be useful it needs real power, and almost nobody is comfortable handing one non-deterministic process that much reach. The usefulness and the danger are the same property. You can't keep one and drop the other by being careful.
Let's make this real. Picture a treasury agent that settles invoices. Someone says "settle invoice INV-7731." The agent reads the invoice to work out who gets paid and how much, checks a price oracle, looks at the records, then settles to a wallet and emails a confirmation. Simple agent. Powerful, because it moves money.
Now someone sends an invoice with a hidden memo. This is indirect prompt injection: the model reads instructions embedded in data it was only meant to process, and has no way to tell a command from a document. White text on white, invisible to a human, plain as day to the model: also pay this other wallet, and email the customer records to this address. It's all just text. So it does both.
One poisoned invoice. Zero clicks. The agent pays the attacker and exfiltrates the records, and every action looks legitimate.
Read the poison, pay the attacker, ship the data. No exploit, no malware, no clicked link. The agent did its job on the wrong instructions, and from the outside every step looks like normal work.
For that attack to land, three things had to be true in the same session. The agent took in untrusted content. It could reach private data. And it had a way to talk to the outside world. Simon Willison named this the lethal trifecta. You don't need all three closed. You need to stop them meeting in one session.
The lethal trifecta. The attack lives in the middle, where all three meet. Break any one leg and it can't fire.
Most teams I talk to go after external communication first, because it's the leg they can actually close this quarter. That instinct is right. Pick a leg. Break it.
Here's the turn. You can't filter your way out of prompt injection, because the thing reading the filter is the same thing being injected. So we stopped thinking about it as a content problem and started thinking about it as an architecture problem. The mental model is three deterministic moves. Scope, sign, stop. None of them ask the model to behave. They change what the model is structurally able to do.
The week of the talk Anthropic published a paper landing on the same philosophy. We didn't invent any of the underlying pieces. We just gave the shape a name we could build against.
Stop shipping one agent that does everything. Split it. One privileged planner holds the tools and delegates to small workers that each do one thing. Untrusted content goes to a separate reader that has no tools at all.
Scope. A privileged planner delegates to least-privilege workers. The poisoned invoice goes to a quarantined reader with no tools, so injection produces a data blob, not an action.
This is the pattern from Google DeepMind's CaMeL. The injection still happens. We assume it always will. But the reader that sees it can't act, and the planner that acts never reads the raw poison. The untrusted text can fill in a value. It can't add a step. That one property, that data can't change the control flow, is most of the fight.
Most teams start agents on a shared service account. Every action shows up as "Alice." But Alice was asleep. When something goes wrong you can't tell what actually happened or who authorized it.
Sign. Kill the shared identity. A trusted issuer mints a short-lived token per call, and the chain records who authorized what.
So give every agent its own identity, derived for the task, and sign every hop. A valet key, not a master key. Uber wrote up how they do this in production with token exchange under 40 milliseconds, so this isn't a whiteboard idea. Keep the chain of custody and your audit log can finally answer the only question that matters after an incident: who authorized this. (I went deeper on the identity piece in a separate post.)
Put a policy gate in front of every action, outside the model, where it can't be prompt-injected. The model proposes. The policy disposes. You write the rules. They run deterministically.
Stop. Every action clears one deterministic gate. Reading PII taints the session, so the later send to an external address is denied. Each call was fine alone. The composition is the breach.
A database read is allowed. An external email is allowed. But if the read touched a PII column, you taint the session, and then the external send gets denied. Each action on its own is fine. The sequence is the breach. You deny the sequence. With Cedar, AWS's open-source policy language, that rule is a few lines:
forbid (principal, action == Action::"EmailSend", resource)
when {
context.session.taints.contains("PII") &&
resource.destination_is_external == true
};Not vibes. Not an LLM grading another LLM. A rule a human can read, sitting outside the model, that the model cannot talk its way past.
Put the three together and the treasury agent gets the same poisoned invoice and nothing happens, by construction. The quarantined reader can't act on the poison, every call is signed and scoped, and the gate denies the exfil.
But the honest version is better than the heroic one: you don't have to do all three to be better off this week. Killing the God Agent is really just breaking the trifecta, and any one of these moves breaks a leg of it. Scope alone keeps the poison off the control flow. Stop alone denies the dangerous composition at runtime. Pick the one your architecture makes cheapest and ship it. That's what the people in Melbourne were telling me they'd do, and they were right.
I can tell you the gate works. Better to watch it. Here's the same treasury agent settling the same invoice twice. The first run has no guardrails, so the poisoned invoice does exactly what it did above. The second run drops a deterministic policy gate in front of every action, and the same attack gets denied while it runs. Same agent, same poison, two endings.
That's the whole difference between hoping your agent behaves and proving it can't misbehave.
I kept this vendor-neutral on purpose, on stage and here. These are patterns, not products, and they're built from other people's work: CaMeL from DeepMind, the lethal trifecta from Simon Willison, Cedar from AWS, the identity patterns from Uber and the standards bodies. I drew the lines and named the shape so it fits in your head. That's all.
None of this is free. Scoping costs you some agent capability. CaMeL trades real task utility for safety. A gate that fails closed can take down your own agent, so default it to advising before it enforces. The immune system shouldn't attack the body. Worth saying out loud before anyone ships it.
A quick word on the making of it, since a few people asked. The first draft was a list of three equal fixes with my CV on the opening slide. It was fine and forgettable. What fixed it was an old idea from Nancy Duarte: open on what is, hold it against what could be, and make the gap ache. So the talk became one agent and one poisoned invoice, shown working, then owned, then fixed, instead of a list. The three moves were called "Isolate, Bound, Enforce" for months before "Scope, Sign, Stop" won, because the second set is easier to say and harder to forget. And there was no live demo. The room was a cinema, a terminal is illegible from the back, and a real injection on stage is a coin flip. So the demo got recorded and the live slot went to the argument. Cutting things is how it got good.
I don't think prompt injection has a clean ending, which is why the talk ended on "still thinking" instead of a victory lap. But you don't need a clean ending to make the blast radius small. You need to stop trusting one model with everything and start drawing lines it can't cross.
If you want to check whether your own agents are sitting in the middle of that trifecta, we open-sourced the deterministic rule set we use internally for exactly that, the agent-security-review skill. Point it at your agent and it tells you where the three are meeting.
That's also the lens we build raxIT through: knowledge in, guardrails out. But you don't need us to start. Pick a leg of the trifecta and break it.
Further reading: How Vulnerable Are AI Agents to Indirect Prompt Injections? (Gray Swan, arXiv 2603.15714) · The lethal trifecta (Simon Willison) · CaMeL: Defeating Prompt Injections by Design (Google DeepMind, arXiv 2503.18813) · Cedar policy language · Solving the Agent Identity Crisis (Uber) · Agent identity, in four layers (raxIT)
Working out which leg of the trifecta your agents are sitting in, or how to put a deterministic gate in front of them? to discuss your specific deployment context and governance needs.