They should authorise the session first, then allow tools only within that session’s scope. The decision should depend on cryptographic proof of the actor, the permitted task, and the destination, not on the tool name alone or the process path being present on an allowlist.
Why This Matters for Security Teams
External tools are where an agent turns from a chat interface into an active operator. The risk is not the tool name by itself, but the combination of identity, task, destination, and runtime context. If security teams decide access based on an allowlist alone, a model can still misuse a permitted tool for an unpermitted outcome. That is why current guidance leans toward session-scoped authorisation and tightly bounded execution rights.
The practical failure mode is familiar: an agent is approved for one purpose, then chains tools, retries requests, or shifts to a new target without a fresh decision. The most common issues are over-broad credentials, weak destination controls, and a lack of task-specific context at approval time. NHIMG’s The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, which fits the pattern of incomplete control over non-human access.
Practitioners should treat tool use as a policy decision, not a software feature. In practice, many security teams encounter unsafe tool use only after an agent has already executed the wrong action, rather than through intentional approval design.
How It Works in Practice
The cleanest pattern is to authorise the session first, then issue the minimum rights needed for that exact task. That means cryptographically proving the actor, binding the approval to a task description, and constraining where the agent may send data or commands. For agentic workloads, static role-based IAM is usually too coarse because the tool call is only one step in a longer autonomous chain.
A workable control model usually combines:
- Workload identity for the agent, so the system knows what is acting before any tool is exposed.
- Intent-based or context-aware authorisation, so the decision reflects the current task, data sensitivity, and destination.
- JIT credentials or short-lived delegation, so access expires automatically when the session ends.
- Policy evaluation at request time, so a tool call can be blocked even if the agent was authorised minutes earlier.
That approach is consistent with the direction of the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, both of which emphasise governance, accountability, and managing dynamic AI behaviour. NHIMG’s OWASP Agentic Applications Top 10 also helps teams think about tool abuse as a runtime abuse problem rather than a static permission problem.
In implementation terms, the approval should record the actor, the approved task, the destination class, the TTL, and the revocation condition. The tool broker should enforce those fields on every call, with deny-by-default behaviour for new destinations, new scopes, or elevated actions. These controls tend to break down when agents are allowed to improvise across multiple back-end systems because policy context is lost between tool hops.
Common Variations and Edge Cases
Tighter tool control often increases operational friction, requiring organisations to balance automation speed against review burden. That tradeoff is real, especially when teams need agents to work across many APIs or internal systems without constant human intervention.
Best practice is evolving for multi-agent pipelines. There is no universal standard for whether each sub-agent needs its own identity, whether a parent session can delegate narrowly, or how much context must be inherited downstream. In high-risk environments, the safer model is to treat every new tool, destination, or privilege increase as a new authorisation event. This is especially important when tools can mutate state, move data externally, or trigger other agents.
Security teams should also watch for cases where the tool itself is harmless but the destination is not. An agent that can query a read-only service may still exfiltrate sensitive data if the destination endpoint is external. The same logic applies to prompt-injection paths, where a seemingly valid tool call is actually steering the agent into unsafe behaviour. NHIMG’s Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio illustrate how tool-enabled workflows can be redirected if the session boundary is weak. The core rule is simple: approve the session, not the tool in isolation.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF 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 | A2 | Tool use decisions hinge on runtime abuse and agentic control failures. |
| CSA MAESTRO | TRM | MAESTRO models agent tool paths, delegation, and runtime trust boundaries. |
| NIST AI RMF | AI RMF addresses governance for dynamic, context-dependent AI actions. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials reduce exposure when agents use external tools. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires destination-aware enforcement for every tool session. |
Gate every external tool call with task-bound policy checks and least-privilege session scope.
