Architectural trust boundaries: disarming prompt injection
Most teams try to defend against prompt injection by detecting it. That does not work, and it will not start working. A language model cannot separate instructions from data, so any content an agent reads can be interpreted as a command. You cannot filter your way out of that. You architect your way out of it.
This is the fourth post in our series on securing AI coding agents, and it sits on top of the first three. If you are landing here first, start with the security risks of AI coding agents, which frames the whole problem as the lethal trifecta, then network egress control and sandboxing and execution isolation, the two containment disciplines that come before this one. For the full framework across all four disciplines, plus a maturity self-assessment, download The Agentic AI Security Maturity Guide.
Architectural trust boundaries are how. You design the system so the three dangerous capabilities never come together in a single step. The part that reads untrusted content is not the part that holds the tools and the private data. The injection still lands. It just lands in a context with nothing worth stealing and no way to act.
The dual-LLM pattern
The core technique is the dual-LLM, or split-context, pattern, described by Simon Willison, the developer who coined the term prompt injection. It splits the work across two model calls with a hard boundary between them.
The first call reads the untrusted content and does one thing: turn it into validated, structured data. No tools. No secrets. If it gets injected, the damage is limited to what can fit through the validation layer, and that layer is where the real work is.
The second call holds the tools and the private data. It never sees the raw untrusted content. It only ever receives the validated output from the first call. The injection payload cannot reach the context that can act, so the trifecta never assembles in one place.
Plan-then-execute is the same idea from another angle. A planning context can safely read untrusted input as long as it cannot act on it, and a separate execution context carries out only the approved plan. Reading and acting live in different trust contexts.
Least privilege and human gates
Two controls harden the boundaries.
Scope every tool to least privilege. An agent holds the narrowest set of capabilities its task requires and nothing more. The fewer actions a compromised context can take, the less an injection accomplishes even if it reaches a tool.
Gate irreversible actions with a human, and design the gate. Sending money, deleting data, publishing. These should require human approval. The catch is that a bad approval flow gets rubber-stamped. Prompts that are too frequent or too opaque get clicked through within a week, and the gate becomes decorative. Every security team has watched this happen with permission dialogs, and agent approvals fail the same way faster, because agents generate more requests than any UI pattern was designed for. A real gate is rare, specific, and shows the human exactly what is about to happen and why. The approval experience is a craft problem, and getting it right is what makes the control real.
The validation layer is the hard part
The boundary is only as good as the validation sitting on it, and that validation layer is where the work actually is. Tuning it is empirical, not theoretical. Too rigid, and it rejects legitimate input and breaks the workflow. Too loose, and injection payloads slip through disguised as valid structured data. There is no universal setting. It takes iteration against real inputs to find the boundary that holds without getting in the way.
This is why trust boundaries are an engineering discipline, not a library you install. The pattern is well understood. Making it hold in production, with a validation layer tuned to your data and approval gates people do not rubber-stamp, is the job. You do not need a perfect model. You need a system where the untrusted read and the privileged action never happen in the same breath.
Frequently asked questions
How do you defend against prompt injection? Not by detecting it, because a language model cannot reliably tell instructions from data. The durable defense is architectural: separate the context that reads untrusted content from the context that holds tools and private data, so an injection lands where it cannot act. The dual-LLM pattern is the canonical approach.
What is the dual-LLM pattern? A design where one model call reads untrusted content and emits only validated, structured data, and a separate call that holds the tools and private data sees only that validated output. The injection payload never reaches the context that can take action.
What is plan-then-execute? A pattern where a planning context can read untrusted input but cannot act, and a separate execution context carries out only the approved plan. It keeps reading and acting in different trust contexts.
Why do human approval gates fail? Because approval prompts that are too frequent or too opaque get rubber-stamped. People click through them out of habit, so the gate stops working. Designing an approval experience people actually read is essential.
Where to start
Find the places where one agent step both reads untrusted content and can take a consequential action. Those are the convergence points. Split them. Route untrusted reads through a validating context, keep tools and secrets in a separate one, and put a well-designed human gate on anything irreversible.
Trust boundaries are one of four disciplines that close the agent security gap, alongside network egress control, sandboxing and execution isolation, and observability and composition. For the full framework and a maturity self-assessment, download The Agentic AI Security Maturity Guide.
