Short answer: Prompt injection cannot be fully solved at the model layer, so you cannot rely on the agent refusing malicious instructions. What contains the damage is authorization: if an agent can only ever do a few narrow things, and it cannot expand its own access, then a successful injection has very little to work with. Scope is your last line of defense, because it is the one that does not depend on the agent behaving.
Can prompt injection be fixed at the model level?
Not completely, and the model builders say so. Anthropic, reporting on its browser-agent defenses, wrote that even after major gains to a roughly 1 percent attack success rate, “no browser agent is immune to prompt injection,” and shared its results “to demonstrate progress, not to claim the problem is solved.” Palo Alto Networks Unit 42 reported in early 2026 that indirect prompt injection, where hidden instructions are planted in content the agent reads, is “no longer merely theoretical but is being actively weaponized” in the wild, with observed goals including unauthorized transactions and sensitive information leakage.
The reason is structural. An AI agent has to read untrusted content to be useful, and it cannot perfectly separate instructions it should follow from instructions buried in that content. Detection and training reduce the rate. They do not drive it to zero.
If you cannot stop injection, what actually limits the damage?
The blast radius. Once you accept that some injections will land, the question stops being “how do we make the agent perfect” and becomes “what can a compromised agent actually reach.” That is an authorization question, not a model question.
Consider two agents that both get hijacked by an injected instruction. The first holds a broad, standing API key. The second holds a grant scoped to reading one resource, that expires, and that it cannot widen on its own. The same injection lands on both. On the first it can exfiltrate or destroy widely. On the second it can do almost nothing. The difference was never the model. It was the access.
What do real incidents show about scope as a control?
They show that standing, over-broad access is what turns an injection into a breach:
- The GitHub MCP “toxic agent flow” (2025). A benign-looking request combined with a poisoned public issue led an agent to leak private repository data, all through the same over-broad token it already held. The injection supplied the intent; the broad token supplied the reach.
- EchoLeak (CVE-2025-32711). A zero-click prompt-injection flaw in Microsoft 365 Copilot could cause sensitive data to be exfiltrated with no user action at all. When the agent already has standing access, no human click is even required.
- In-the-wild indirect injection (Unit 42, 2026). Attackers embedded instructions in web content to drive unauthorized actions. What decides the outcome is what the agent was permitted to do when it read the poisoned page.
What does “authorization as the last line of defense” require?
Three properties, all independent of whether the agent behaves:
- Least privilege by default. Grant only the specific actions and resources the task needs, so there is little for a hijacked agent to abuse.
- No self-service escalation. The agent must not be able to widen its own access. If more access requires a fresh decision by the person, an injected instruction has no path to more power. A request beyond scope should return an error and route back to the human.
- The authorization decision lives outside the agent. If granting or expanding access happens in a channel the agent cannot operate, then an injected instruction cannot trigger it. This is the core idea behind user-mediated authorization: the person authors the grant in the app’s own session and the agent never has a programmatic path to create or escalate one.
None of this replaces model-level defenses or standards like OAuth and MCP. It sits underneath them as the control that still holds when the model is fooled, which the model builders tell us it sometimes will be.
Frequently asked questions
Is prompt injection an authorization problem or a model problem?
Both, but the durable control is authorization. The model layer reduces how often injection succeeds; it cannot eliminate it. Authorization decides how much damage a successful injection can do, which is why scope is the control that still holds when the model is fooled.
Can you prompt-engineer your way out of prompt injection?
No. Model builders including Anthropic state plainly that no browser agent is immune and the problem is not solved. Better prompts and classifiers lower the rate but leave a non-zero miss rate, so you have to assume some injections land and limit what they can reach.
How does least-privilege access stop prompt injection damage?
It shrinks the blast radius. A hijacked agent can only do what it was authorized to do, so an agent scoped to a single read cannot delete data or move money no matter what a malicious instruction tells it. The narrower and more revocable the grant, the less an injection is worth.
Why does keeping the authorization decision outside the agent matter?
Because an injected instruction is something the agent acts on. If the agent could grant or expand its own access, injection could drive that escalation. When the grant is authored by the person in a channel the agent cannot reach, there is no path from a malicious prompt to more access.
AgentAdmit is the authorization layer for AI agents, built so a hijacked agent cannot widen its own access and the authorization decision lives outside the agent’s reach. Learn more at agentadmit.com.
Related reading: What is user-mediated authorization for AI agents?, What is the Context Access Divide?, and MCP security: how to let an AI agent access user data safely, Can an AI agent approve its own permission request?, AI agent authorization vs API keys.