Prompt Injection Is a Permission Problem

Prompt injection is usually framed as a model problem: make the model better at spotting bad instructions. That is necessary. It is also the wrong place to stop.

An agent that reads untrusted email, documents, web pages, tickets, or repositories is going to encounter text that tries to steer it. Sometimes the attack will be a crude “ignore previous instructions.” Increasingly, it will look like ordinary social engineering: urgency, authority, a plausible business process, and one helpful-looking link. OpenAI says this shift is already visible in real-world attacks, and that filtering inputs alone cannot contain the impact when manipulation succeeds.¹

That leaves one practical conclusion: prompt injection is fundamentally a permissions problem.

The question is not only whether an agent believes a malicious sentence. The question is what it can do after it believes one.

If the answer is “summarise this page,” the failure is embarrassing. If the answer is “send data to a new recipient,” “approve a payment,” “change a deployment,” or “run code in a privileged environment,” the same failure has a price tag.

Stop Treating the Model as the Security Boundary

Models do not have a reliable, cryptographic way to distinguish a user’s intent from hostile instructions embedded in the material they are asked to process. They reason over one context window. The system can label provenance and train the model to respect instruction hierarchy, but it cannot turn arbitrary prose into a safe authority channel by wishing harder.

So put the hard boundary somewhere deterministic: between a proposed action and the authority to perform it.

I use a simple test for every agent capability:

If an untrusted document successfully changes the agent’s mind, what is the worst thing the agent can do before a human or policy engine catches it?

If the answer is “anything my user can do,” the system is not an agent with guardrails. It is a browser extension with a hostage negotiation problem.

OWASP’s 2026 Top 10 for Agentic Applications exists because agents combine planning, action, and decisions across workflows rather than merely generating text.² That combination is what changes the threat model. The danger is not that an attacker gets the model to print a strange sentence. It is that the attacker gets a capable loop to cross a trust boundary.

The Architecture That Actually Helps

A useful design separates four things that product teams routinely mash together.

1. Untrusted content

Email bodies, web pages, fetched documents, issue comments, retrieved search results, and tool output should arrive labelled as data, not as instructions. The label will not make the model invulnerable. It does give the harness a basis to apply stricter rules: extracted links do not become approved destinations; text claiming authorisation does not grant authorisation.

2. Intent

The user’s request is the goal. It should be captured before the agent starts roaming. “Research vendors and prepare a comparison” is not permission to contact vendors, create accounts, or forward internal notes. A plan can make the proposed interpretation visible; it is not decorative ceremony.

3. Authority

Tools need narrow, typed permissions. An agent that may read a mailbox does not automatically get permission to forward it. An agent that may draft a change does not automatically get permission to deploy it. Read, write, send, purchase, delete, and execute are different verbs. Treat them that way.

This is not a plea for approval pop-ups after every click. Anthropic argues for keeping humans in control while using oversight at the level where judgment matters, and describes an agent as a loop that plans, acts, observes, and adjusts.³ The sensible checkpoint is before a consequential transition: a new external recipient, a credential-bearing action, an irreversible write, or a jump in scope.

4. Verification

The action layer should check facts the model cannot be trusted to self-certify. Is this recipient on an allowlist? Is the requested domain the same one the user approved? Does the action exceed a spending, deletion, or publication threshold? Does the change match a declared plan?

A model can propose. A policy engine can refuse. That division is not glamorous, which is why it works.

Three Rules Worth Shipping This Week

Make exfiltration deliberately awkward. Do not give one tool access to sensitive data and arbitrary network destinations. Require an explicit destination policy, ideally with a separate confirmation when the recipient is new. A compromised reader should not become an instant courier.

Use capability tokens, not ambient power. Give an agent a scoped, short-lived grant for the task in front of it. Do not hand it a broad credential and hope its system prompt remains inspirational. The more power a tool exposes, the more precise the policy in front of it needs to be.

Log proposed actions as structured data. “The agent thought this was fine” is not a control. Record the user goal, source of the action parameters, tool invoked, target, policy decision, and confirmation state. That makes investigation possible and lets you test whether your guardrails are actually stopping adversarial paths.

The Uncomfortable Bit

There is no magic classifier that will permanently separate malicious instructions from legitimate ones. Human phishing has had decades to prove that point. Agents are harder because they can be both persuaded and empowered in the same turn.

That does not mean agent security is hopeless. It means the winning move is boring systems engineering: reduce ambient authority, bind actions to explicit intent, constrain destinations, and verify the transition from words to consequences.

Filters will improve. Models will improve. Attackers will improve too.

Permissions are the part you control.

Sources