They should enforce authorization at the tool or resource boundary, not inside the model. Scope each tool to the minimum necessary permission, then deny any call that falls outside that scope. Prompt filtering still has value, but it cannot be the last line of defence because the model is exactly what the attacker is trying to influence.
Why This Matters for Security Teams
Prompt injection is not just a content-safety problem. It becomes a security incident when a model is allowed to translate hostile instructions into tool calls, data access, or state changes. The real risk sits at the boundary between the model and the systems it can reach, which is why guidance from the OWASP Agentic AI Top 10 is increasingly focused on tool abuse, not just prompt content.
Security teams often over-invest in prompt filters and under-invest in authorization design. That creates a fragile control path: the model may still be influenced, but the damage is limited only if the tool, API, or resource denies anything outside a tightly scoped entitlement. This is the same pattern NHI teams already see with over-privileged service accounts. NHIMG research shows that 97% of NHIs carry excessive privileges, which is exactly the kind of entitlement sprawl that turns a single successful injection into broad misuse. See Ultimate Guide to NHIs and the OWASP Agentic Applications Top 10 for the current risk framing.
In practice, many security teams encounter tool misuse only after an agent has already been tricked into taking an action that looked legitimate at the prompt layer.
How It Works in Practice
The control point should be the tool or resource boundary, not the model output. That means every tool exposed to an agent needs its own authorization rules, scope, and logging. The model can propose an action, but the tool service decides whether the action is allowed for that specific request, user context, and workflow state. Current guidance suggests treating the model as an untrusted requester, even when the user is authenticated.
Practitioners usually combine three layers:
- Scope each tool to a narrow purpose, such as read-only lookup, single-record update, or one repository path.
- Use short-lived, task-bound credentials so an injected prompt cannot reuse a standing secret after the task ends.
- Evaluate policy at request time with context, rather than relying on pre-approved static role mappings.
This is where NHI discipline matters. A tool credential is still an identity, and it should be treated like one. The State of Non-Human Identity Security shows how commonly organisations struggle with visibility and privilege creep, while the OWASP Top 10 for Agentic Applications 2026 reinforces that agent tool access is a direct attack surface. In practice, teams should pair authorization with workload identity, so the tool can verify what the agent is, what task it is performing, and whether that task is still in bounds.
That usually means a policy engine, such as policy-as-code, sitting in front of the tool and enforcing allow rules, deny rules, and contextual checks at runtime. These controls tend to break down when tools are shared across unrelated workflows because the authorization context becomes too coarse to distinguish legitimate actions from injected ones.
Common Variations and Edge Cases
Tighter tool authorization often increases engineering overhead, requiring organisations to balance containment against developer speed and operational flexibility. That tradeoff is real, especially in systems where an agent must chain several tools together to complete a task.
There is no universal standard for this yet, but current best practice is to reduce blast radius first and optimise convenience later. Read-only tools can usually be exposed more broadly than write-capable tools, and high-risk actions should require explicit step-up approval or human confirmation. For multi-step workflows, every hop should re-check scope because a prompt injection may not trigger immediately. It may wait until the agent reaches a later tool with more privilege.
Edge cases arise when the agent can call external systems through indirect connectors, plugin frameworks, or delegated tokens. Those pathways often bypass the original security review unless the organisation treats them as separate identities with separate controls. The State of Non-Human Identity Security is useful here because it shows how visibility gaps and over-privileged access amplify downstream risk. The OWASP Agentic AI Top 10 remains the best current reference for framing these controls around tool misuse rather than prompt hygiene alone.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Prompt injection leading to tool abuse is a core agentic risk. |
| CSA MAESTRO | AIC-04 | MAESTRO addresses agent tool governance and runtime control. |
| NIST AI RMF | AIRMF supports risk-based governance for autonomous AI behavior. |
Treat each tool as a governed capability and enforce contextual approval at execution time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
