They reduce risk because the model can only request actions already encoded in the token. If a prompt injection tries to turn a summarization agent into an email sender or deleter, the resource server can reject the call at authorization time. The attacker can influence intent, but not expand the token’s authority.
Why scope-per-tool tokens change the prompt injection model
Scope-per-tool tokens reduce prompt injection risk because the model is no longer carrying a broad credential that can be repurposed across actions. The prompt may still influence what the model asks for, but the authorization decision is pushed down to the resource server, which can compare the requested tool against the token’s encoded scope and reject anything outside it.
This matters because prompt injection is best understood as a control-confusion problem, not just a content problem. If an attacker can steer a model’s intent, the damage depends on whether the surrounding authorization layer treats that intent as enough authority to act. Narrow tokens make that mistake harder to turn into cross-tool abuse.
In practice, scope-per-tool works best when each tool maps to a distinct operational verb, such as read, send, delete, or export. The token then becomes a bounded delegation artifact, not a general pass. A prompt injection can still try to redirect behavior, but it cannot expand the permitted action set if the server enforces scope at request time.
Where the protection comes from, and where it does not
The protection comes from separating model output from execution authority. A malicious prompt can shape the model’s next step, but the token scope defines the maximum authority of that step. That means the security boundary is not “did the model sound trustworthy,” but “does this request match the permission that was actually issued.”
This boundary is especially important for tool-using agents that can act on behalf of a person or workflow. If the same token is reused across multiple tools, a single successful injection can become a privilege multiplier. A scope-per-tool design limits that blast radius because compromise of one prompt does not automatically imply access to every connected capability. For broader agent security context, see NHIMG’s Agentic AI Security Guide and AI Agent Authorisation Guide.
The control is strongest when the token is also audience-bound and short-lived. If a token can be replayed elsewhere, or if it is accepted by more than one resource, the scope boundary weakens in practice. That is why scope design should be paired with strict resource validation, not treated as a standalone safeguard. The same principle is reflected in RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP).
What still has to be true for it to work safely
Scope-per-tool tokens only reduce risk if the authorization server, resource server, and tool registry agree on the same permission model. If a tool ignores scope, silently broadens it, or accepts a token for a different resource, the design collapses back into overbroad delegation. In other words, the security gain comes from enforcement, not from token labeling.
The implementation also has to account for operational edge cases such as token reuse, stale permissions, and ambiguous tool names. A token that is technically scoped but functionally lets the agent reach adjacent actions is still too broad. That is why per-tool scoping should be designed as least privilege for executable actions, not as a convenience filter.
For teams building or reviewing these systems, the important question is whether each tool has its own authorization decision path. If the answer is yes, prompt injection can influence what is attempted but not what is permitted. If the answer is no, the model may be able to convert conversational manipulation into an execution-level failure. MCP authorization for HTTP transports is a useful reference point for this pattern.
Risk and Threat Considerations
Scope-per-tool tokens mainly reduce the damage from prompt injection by limiting authorization, but they do not eliminate prompt manipulation itself. If the attacker can still steer the model toward a sensitive tool, the remaining risk is abuse of whatever scope was legitimately issued, especially when tools are high impact or scopes are still too broad.
Failure mechanism: The model is tricked into requesting an action the user did not intend, but the resource server only prevents harm if it reliably checks the requested tool, audience, and scope before executing the call. Weak enforcement, shared scopes, or token replay can turn a “bounded” token back into a broad one.
Impact: Without tight scope and resource checks, prompt injection can escalate from harmless instruction steering into unauthorized sending, deletion, data access, or other side-effecting actions. With strong enforcement, the attack is usually contained to attempted abuse rather than executed abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Prompt injection becomes dangerous when it can expand an agent's authority. |
| ASI02 — Tool Misuse | The question is about preventing injected prompts from driving unsafe tool actions. | |
| ASI09 — Human-Agent Trust Exploitation | Prompt injection exploits trust in agent instructions to induce unintended actions. | |
| Recommendation — Restrict each tool to the minimum scoped authority and reject calls outside that scope. Validate tool requests against policy before execution and block unsafe action chains. Separate instruction trust from authorization and require explicit approval for sensitive actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Per-tool scoping is a least-privilege control for agent tool access. |
| IA-5 — Authenticator Management | Tokens are identity-bearing material whose lifecycle affects reuse and replay risk. | |
| Recommendation — Issue the narrowest permission set needed for each tool and revoke excess access. Bind, rotate, and expire tokens so they cannot be reused beyond their intended scope. | ||
Practitioner Guidance
What to verify: Confirm that every tool call is authorized against the requested verb and target resource, not just against a generic session or user token. If the same token can call multiple tools, the scoping model is probably too coarse.
Decision rule: If a tool can cause external side effects, give it a distinct scope and require the resource server to reject any out-of-scope request. If a tool only reads data, keep its scope read-only and do not reuse a broader token “for convenience.”
Practitioner takeaway: Scope-per-tool tokens are effective when they turn prompt injection into an intent signal without turning it into usable authority. The security boundary must be enforced by the authorization layer, not inferred from the model’s behavior.
Related resources from NHI Mgmt Group
- How can organisations reduce risk from prompt injection and tool misuse?
- How should security teams design agent controls to reduce prompt injection risk across tool calls and browser actions?
- Why do short-lived per-tool tokens reduce risk but still fail to stop a compromised AI agent from doing the wrong thing?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?