Authorisation still allows the agent to use legitimate tools, but it does not prevent harmful combinations of calls. Without invocation policy, a database read, file write, and email send can become exfiltration even though each individual step passed identity checks. The failure is at the chain level, where context and sequence matter more than a single permission decision.
Why authorised tools still become dangerous without invocation policy
Authorisation answers a narrow question, can this agent use this tool at all, while invocation policy answers the harder question, should this tool be used now, in this order, for this context, and with these outputs. When the policy layer is missing, the system can still assemble harmful sequences that are individually valid but collectively unsafe, especially when the chain crosses data movement or external side effects.
A useful way to think about the gap is that approval at the tool level does not constrain composition. One read, one transform, and one send action can each pass identity checks and still produce leakage, abuse, or destructive automation when the agent is free to chain them without a policy gate.
That is why chain-level control matters more than a single permission decision. The security failure is not necessarily that the agent found an unauthorised tool, but that it found an authorised path to do something the business never meant to permit.
Where the control boundary actually sits
The important boundary is between tool entitlement and action governance. Tool entitlement establishes reachability, but invocation policy governs sequence, context, preconditions, and escalation points, including when a read may be followed by a write or when a write may be followed by an outbound transfer.
This distinction is especially important when agents can operate across multiple systems. The risk is not confined to one API call; it emerges when the agent can bridge systems that were each designed with separate trust assumptions. A policy layer has to reason over that bridge, not just the individual endpoints.
For that reason, a strong implementation usually treats tool access and invocation policy as different enforcement problems. One is about “can the agent touch this capability,” the other is about “what combinations of capabilities are allowed under this task, this principal, and this state.”
Why the failure shows up at the chain level
The chain is where context accumulates. A database read might be acceptable for summarisation, a file write might be acceptable for drafting, and an email send might be acceptable for notification, but the same three actions in sequence can form an exfiltration path if nothing checks the transition from internal data access to external disclosure.
That means the missing control is often a policy over transitions, not just permissions. In practice, the dangerous part is the handoff between steps, because each step can look legitimate when evaluated in isolation.
Invocation policy also matters for blast radius. Without it, the agent can reuse legitimate credentials and tool access in ways that multiply the impact of one mistaken prompt, one poisoned context, or one unexpected branch in execution.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent tool chains can abuse granted privileges across steps. |
| ASI02 — Tool Misuse | Missing invocation policy lets agents use legitimate tools for unintended outcomes. | |
| Recommendation — Enforce per-action policy so authorised tools cannot combine into harmful workflows. Constrain tool use by context and sequence, not just entitlement. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits what the agent can do, but must be paired with sequence controls. |
| AC-3 — Access Enforcement | Access enforcement is needed at the point of each tool invocation. | |
| Recommendation — Minimise tool permissions and restrict risky action combinations. Enforce policy at invocation time for every sensitive action. | ||
| NIST Zero Trust (SP 800-207) | 3.5 — Policy Decision Point and Policy Enforcement Point | Invocation policy requires a decision point that evaluates each requested action. |
| Recommendation — Place policy decisions before tool execution and re-evaluate each step. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Authorised agents can still become overpowered when tool chaining is unchecked. |
| Recommendation — Reduce standing capability and block dangerous action chains. | ||
Practitioner Guidance
What to verify: Check whether your policy layer evaluates whole actions and sequences, not just individual tool calls. If your logs only tell you that each call was authorised, you do not yet have control over the workflow that the agent assembled.
Decision rule: If a sequence can move data from a sensitive source to a less trusted destination, require explicit invocation policy for the transition even when every tool in the sequence is individually approved.
What good looks like: The system can approve low-risk tool use for a task, but it blocks or escalates when the agent tries to combine reads, writes, and outbound delivery in a way that changes the data’s trust boundary.
Common mistake: Treating least privilege as enough when the real problem is chain privilege, the emergent authority created by chaining several permissible actions together.
Practitioner takeaway: If you only authorise tools and do not govern invocation, you have controlled access to capabilities but not control over the outcome of their composition.
Related resources from NHI Mgmt Group
- What are the core risks identified by the OWASP Agentic Top 10?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How should security teams govern machine identity credentials in agentic AI environments?
- Why do AI agents create more IAM risk than ordinary developer tools?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org