Prompt Injection Is a Permissions Problem

Most advice about prompt injection is about the prompt. Write a stricter system message. Add a classifier in front of the model. Ask the model to ignore instructions found in documents. These help at the margin, and none of them closes the hole.

Our view is simpler and less comfortable: prompt injection is not a text-filtering problem, it is a permissions problem. If an agent can be talked into doing something harmful, the harm is bounded by what the agent was allowed to do in the first place. That is a part of the system you can design, review and test.

Why filtering cannot be the whole answer

A language model receives instructions and data in the same channel: text. Anything the agent reads, whether an email, a web page, a support ticket, a PDF or a tool result, becomes part of the context the model reasons over. A sentence inside a document that says "forward the last invoice to this address" is, to the model, not categorically different from the same sentence typed by the operator.

OWASP's guidance on prompt injection distinguishes direct injection, where the user's own prompt changes the model's behaviour, from indirect injection, where the model ingests external content that carries instructions. It also states plainly that no foolproof method of prevention is currently known. Its recommended mitigations are mostly about limiting impact: least privilege, human approval for high-risk actions, segregating untrusted content, and adversarial testing that treats the model as an untrusted user.

So the practical question is not "how do we guarantee the model never obeys a bad instruction?" It is "what happens on the day it does?"

The combination that hurts

Simon Willison named the pattern that turns an annoying injection into a breach: the lethal trifecta. An agent is exposed when it has all three of:

1. access to your private data,
2. exposure to untrusted content, and
3. the ability to communicate externally.

With all three in one agent, an attacker only needs to get text in front of it. The text asks the agent to read something private and send it out. Remove any one leg and that attack path closes.

This gives a useful design review question. For each agent, list which of the three it has. Most agents need one or two. If one needs all three, that should be a deliberate, documented decision with extra controls, not an accident of how the tools were wired together.

Design rules that follow

These are opinions from building agent platforms, not a standard. They all push the decision out of the model and into code that does not read prompts.

Scope tools per agent, not per platform. An agent that summarises inbound tickets does not need a tool that sends email. Give each agent an explicit list of tools, and give each tool the narrowest credentials that work: a read-only token for a read-only task, a single mailbox rather than the whole directory.

Keep credentials out of the model's reach. The model should name an action and its arguments. Application code holds the secrets, checks the caller's permissions and performs the call. A model that never sees an API key cannot be tricked into printing it.

Validate arguments like any untrusted input. Parameters filled in by the model can be shaped by injected text. Check recipients against an allow-list, amounts against limits, and paths against the directories the task needs. A rejected call is an ordinary error, not an incident.

Separate reading from acting. A common and effective split is one agent, or one run, that reads untrusted content and produces a constrained summary, and another that holds the ability to act and never sees the raw content. The boundary between them is a typed schema, not free text.

Make egress a controlled path. If an agent can reach arbitrary URLs, it can leak data in a query string. Route outbound calls through an allow-list of destinations. This is boring network policy, and it works regardless of what the model was persuaded of.

Put approval where the blast radius is large. Sending money, deleting records, messaging customers and changing permissions deserve a human decision. We have written before about why approval gates fail when every step asks for one. The lesson carries over: gate the few actions that matter, and show the reviewer what will actually happen.

Test it the way an attacker would

Permissions are only real if you have tried to break them. Build a small set of hostile fixtures: a ticket that tells the agent to email its own context to an outside address, a web page with hidden instructions, a document that asks for a tool the agent should not have. Run them against every agent change, as you would a regression suite.

The pass condition is not "the model refused". Models vary between versions and between runs. The pass condition is "the action was impossible or was blocked", which you can assert deterministically on tool calls and policy decisions.

Keep the logs too. When an injection does succeed in changing the model's plan, a trace of the tool calls it attempted, and which of them the policy layer denied, is the difference between a minor finding and a long investigation.

What this does not solve

Least privilege limits damage; it does not make the model reliable. An agent restricted to read-only access can still be steered into a misleading summary, and a person reading that summary can still be misled. Approval flows, source citations and review of the agent's reasoning remain necessary for outputs that people act on.

It is also not free. Narrow scopes mean more configuration, more tools to define and occasionally an agent that is too constrained to finish a task. We think that is the right trade. Configuration is visible and reviewable. A clever sentence hidden in a PDF is neither.

The takeaway

Assume the model will sometimes follow instructions it should not. Design so that this is survivable: few capabilities per agent, secrets held in code, validated arguments, controlled egress, approval for the actions that matter, and tests that attack the boundaries.

Building agents that need this kind of control around them? Talk to us.