Teams should authorise each tool call separately and preserve delegated human context in the decision path. If the agent can call infrastructure, data, or workflow tools, every call needs its own policy check because the risk changes by resource and protocol. This is the point where per-session thinking stops being enough.
Why This Matters for Security Teams
When an AI agent can call multiple tools, the risk is no longer tied to one login or one session. Each tool expands the blast radius: a harmless-looking planning step can become data exfiltration, infrastructure change, or workflow abuse if the next call is not independently authorised. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls rather than one-time trust decisions.
That distinction matters because autonomous agents do not behave like fixed human roles. Their sequence of actions depends on prompts, retrieved context, tool outputs, and errors, which means the same agent can move from read-only analysis to privileged change execution in seconds. Security teams that only think in terms of “session access” often miss the fact that tool chaining creates a new policy decision point at every step. The practical failure mode is not theoretical: agentic systems often look compliant until the first unexpected tool path appears.
In practice, many security teams encounter tool abuse only after an agent has already crossed a boundary they assumed was impossible.
How It Works in Practice
The safest operating model is per-tool, per-action authorisation. Each call should be evaluated against the specific resource, protocol, and business context involved, not merely against the identity of the agent. That usually means pairing workload identity with runtime policy checks, then issuing only the minimum credential needed for the current task. The agent should not hold broad standing access simply because it is “trusted” to operate the workflow.
Practitioners usually break this into four layers:
Workload identity: prove what the agent is using cryptographic identity, not a shared secret.
Intent-aware policy: decide whether the requested action matches the declared task and current context.
JIT credentials: issue short-lived credentials only for the current tool call or narrowly bounded task.
Delegated human context: preserve who approved the action, what they approved, and what the agent is allowed to do on their behalf.
This is where frameworks such as CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework become operationally useful: they support threat modeling and governance around the agent’s action chain, not just its login state. NHIMG’s OWASP NHI Top 10 also aligns with this approach by treating identity and access abuse as a first-class control problem in autonomous systems.
Security teams should also log each tool invocation with enough detail to reconstruct why the call was permitted, which context was present, and whether any downstream action inherited the same trust. These controls tend to break down when multiple tools share a single broker with broad default permissions, because the broker becomes the hidden privilege amplifier.
Common Variations and Edge Cases
Tighter per-call authorisation often increases latency, policy complexity, and operational overhead, so organisations must balance safety against workflow friction. That tradeoff becomes sharper when agents need to complete multi-step tasks quickly across SaaS, cloud, and internal systems.
Best practice is evolving for a few edge cases. There is no universal standard yet for how much human approval should persist across chained tool calls, especially when a task starts as user-directed but later becomes fully autonomous. Some environments treat each call as a fresh decision; others allow a bounded delegation window for a specific objective. The right choice depends on data sensitivity, tool criticality, and whether the action is reversible.
Two patterns deserve special caution:
Shared connectors: if one connector can reach many systems, a single compromise can span the environment.
Long-lived tokens: static credentials give an agent more time to drift from the original intent, which defeats the purpose of stepwise checks.
For teams formalising controls, NHIMG’s AI LLM hijack breach analysis and the NIST AI Risk Management Framework both reinforce the same operational lesson: autonomous access must be constrained by task, time, and context, not by blanket trust in the agent. The model breaks down fastest in highly interconnected environments where one tool call can silently trigger many downstream permissions.
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 | T10 | Tool chaining and agent misuse are core agentic AI risks. |
| CSA MAESTRO | TRM | MAESTRO models agent workflows and multi-tool risk paths. |
| NIST AI RMF | GOVERN | Runtime accountability and oversight are needed for autonomous actions. |
Require policy checks at each tool call and restrict the agent to the minimum action needed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
