The Rule of Two: A Prompt Design Discipline for Hijack-Resistant Agents
Prompt injection stopped being a theoretical concern the moment agents started reading web pages, emails, and documents on our behalf. A retrieved page is not neutral text; it is content that a stranger controls, arriving inside the same context window that already holds your system instructions. When a model cannot reliably tell the two apart, the attacker's sentence and your policy live in the same stream of tokens.
Two recent developments pushed this from a research curiosity to an engineering constraint. A widely discussed security paper on agent design proposed a simple combinatorial rule for limiting the damage, and a separate study took twelve published prompt injection defenses and broke most of them with adaptive attacks. That second result is the one worth internalizing: defenses that only look clever against a fixed attack do not survive contact with an opponent who reads your defense.
Name the Lethal Trifecta Before You Write a Prompt
Security practitioners have settled on a useful framing for the risk. An agent becomes dangerous when it combines three properties at once: access to private data, exposure to untrusted content, and the ability to communicate externally or take irreversible action. Any two are manageable. All three in one loop means a hostile string in an untrusted document can read your data and send it somewhere.
The Rule of Two formalizes this as a design constraint rather than a prompt trick. If an agent handles private data and untrusted content, it should not be able to take consequential external actions without a human stepping in. If it must act autonomously, then cut one of the other legs. That reframing matters because it moves the decision out of the prompt and into architecture, where it can actually be enforced.
Layers Beat Instructions
The most common mistake is trying to solve injection with better wording. Add a line to the system prompt instructing the model to ignore instructions inside documents, and you have created a suggestion, not a boundary. Models follow strong instructions most of the time, which is exactly the problem: you need a guarantee, and probabilities compound badly across a long agent run.
The durable approach separates three layers that people habitually mush together. Instructions are your policy. Data is content that may be hostile and that never carries authority. Code is the deterministic logic that decides what happens next. When those layers are distinct, an injected sentence can at worst corrupt the interpretation of the data, never the policy or the control flow.
Practical Techniques That Survive Adaptive Attacks
Start with the quarantine pattern. Instead of letting one model both read untrusted content and choose actions, have a restricted model process the untrusted text and emit only a narrow, typed result. The main agent then acts on that structured value, which it can validate, rather than on prose it must trust. The untrusted content never reaches the planner in a form the attacker can shape into an instruction.
Then constrain output shape aggressively. If a tool call field must be one of a known set of actions, validate it against that set in code. If a URL is suggested, check the host against an allowlist before fetching it. If the model proposes sending a message, surface the draft for approval. Every one of those checks is a few lines of ordinary Python, and together they convert an unbounded failure into a bounded one.
- Treat retrieved text as data: never concatenate it into the instruction channel.
- Use a quarantined model for untrusted content, returning typed values only.
- Validate tool arguments against schemas and allowlists in deterministic code.
- Require re-authorization when privilege level or action scope changes mid-run.
- Cap the blast radius: read-only credentials for anything that touches strangers.
- Log the full provenance of every instruction that changed the plan.
If your only defense against prompt injection is a sentence in the system prompt, you do not have a defense. You have a preference, and your adversary has read it too.
Why Adaptive Attacks Keep Winning
The study that broke twelve published defenses did something unglamorous. It assumed the attacker knew the defense existed and let them optimize against it. Under those conditions, most filtering, paraphrasing, and delimiter schemes collapsed, because the attacker only needs one phrasing that slips through while the defender needs all of them blocked.
That asymmetry is why detection-based defenses are structurally weak and architecture-based defenses are not. You cannot out-prompt an attacker who gets unlimited attempts, but you can make success economically pointless by ensuring a successful hijack reaches nothing valuable. Design so that the worst case is a wasted API call and a log line.
Writing Prompts for the Worst Case
Once the architecture is set, prompt craft changes character. You stop writing prose that begs the model to behave and start writing specifications that are easy to verify. Define what the agent is allowed to decide, what it must escalate, and what it must never attempt, then express each of those as a checkable condition. A prompt that reads like a contract is more useful than one that reads like an appeal.
Keep instructions short and unambiguous. Long, hedged system prompts accumulate contradictions that a clever injection can exploit by picking whichever clause suits it. Version them alongside your code, review them like code, and test them with an adversarial suite that includes the injection attempts you expect to face.
Testing Injection Like You Test Bugs
Build a small harness with a handful of hostile documents: a page that tries to redirect the agent's goal, one that tries to exfiltrate a secret file, one that impersonates a system message. Run the suite on every prompt or tool change. The test does not need to be exhaustive to be valuable, because it catches regressions in the exact places your architecture is supposed to hold.
Final Thoughts
The Rule of Two will not make your agent hack-proof, and nobody honest claims otherwise. What it does is convert an open-ended trust problem into a concrete design decision you can make on a whiteboard: which leg of the trifecta are you removing, and what enforces that in code rather than in prose. Prompt engineering in 2026 is less about persuasion and more about drawing boundaries the model cannot talk its way across.
