Tool calling and orchestration are reshaping AI agent governance

At a glance

What this is: This is a Stytch analysis of how tool calling and orchestration turn LLMs into AI agents that can act through authenticated tools, with governance moving from text generation to runtime control.

Why it matters: It matters because IAM teams now have to govern agent action, approval, and delegated authority, not just authentication and model access.

Context

Tool calling is the bridge between an LLM that can reason in text and an agent that can take action in a live environment. In this article, Stytch argues that the governance problem is no longer about model output alone, but about the authenticated tools, orchestration layers, and policy checks that determine what the agent is allowed to do.

For IAM and NHI programmes, that changes the control boundary. A tool-enabled agent is not just another chatbot because it can invoke side-effecting actions such as email, messaging, and data access, which means authorisation, consent, and approval flow become part of the identity model rather than an afterthought.

The article also frames multi-agent handoffs as an extension of the same problem: once tasks move between specialised agents, the governance question becomes who can delegate, what context follows, and where a policy interrupt must stop execution.

Key questions

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Why do tool-calling agents change IAM and governance priorities?

A: They shift the control problem from login and model access to delegated action. IAM teams have to decide which tools an agent may invoke, what policy conditions must be satisfied, and when a human approval is mandatory before a side effect occurs.

Q: How do security teams know if agent tokens are too permissive?

A: Look for tokens that are long-lived, reusable across services, or visible to the agent runtime itself. Those signs mean the credential can survive beyond the task and beyond the intended audience. A safe design binds the token to one resource server, limits its lifetime, and keeps it out of model context.

Q: What should organisations do when one agent hands tasks to another?

A: Treat every handoff as a new trust boundary. The receiving agent should not automatically inherit every prior permission, because delegation can widen the blast radius unless context, tool access, and approval rules are re-checked at the boundary.

Technical breakdown

Tool calling is execution intent, not execution itself

Tool calling is the mechanism by which an LLM expresses that it wants to use a function with certain parameters. The model does not execute the function, and that distinction matters. The agent runtime or application receives the predicted tool call, validates it, and decides whether to run it. In practical terms, this makes the runtime the enforcement point for identity, policy, and approval. The LLM can propose action, but the surrounding system decides whether the action becomes a real side effect.

Practical implication: Treat tool selection as untrusted intent until the runtime validates the call against policy and authorisation.

Orchestration binds context, policy, and side effects

Orchestration is the control layer that moves text, state, and results between models, tools, and sometimes multiple agents. In this article, orchestration is not just message routing. It is the structure that lets an agent retrieve context, select tools, pause for approval, and continue after a tool result returns. That means orchestration also carries governance weight because it determines when user consent is required, which tools are available, and how errors are handled when a tool call fails and must be retried.

Practical implication: Place policy checks inside the orchestration path, not around it, so every side effect is mediated consistently.

Multi-agent handoffs create delegated identity paths

When one agent hands work to another, the delegation chain becomes part of the identity problem. The article’s triage, Gmail, and Slack pattern shows that agents can pass tasks and tool access across functional boundaries, which is powerful but also creates scope transfer risk. Each handoff can carry context, authority, or both. Governance has to account for whether the downstream agent inherits only the request, the full context, or an implicit trust relationship that was never meant to be broad enough for the next action.

Practical implication: Define what authority moves with a handoff and what must be re-authorised at each boundary.

NHI Mgmt Group analysis

Tool calling turns agent governance into an authorisation problem, not a prompt problem. Once an LLM can request actions through authenticated tools, the question changes from what the model says to what the surrounding system lets it do. That means the meaningful control point is the tool runtime, approval gate, and policy boundary, not the text response itself. Practitioners should treat agent execution as a governed access path.

Human-paced review assumptions collapse when agents can invoke side effects in the middle of a task. Access review, consent, and change-control processes were designed for bounded sessions where a human actor persists long enough to be observed and certified. Tool-calling agents can enter, act, and continue without that same rhythm, which means governance that depends on post hoc review will miss the critical moment of authority transfer. The implication is that control must move to issuance and invocation time.

Multi-agent orchestration creates a new identity blast radius. The moment one agent can hand off work to another, the governance surface expands from single-session authorisation to delegated action chains. That does not automatically make the system autonomous in the strict sense, but it does multiply the places where policy can be diluted, context can be over-shared, and approvals can become too permissive. Practitioners should model handoffs as identity boundaries, not just workflow steps.

Policy interrupts are becoming the practical counterpart to least privilege for agents. The article’s approval-check pattern shows that side-effecting tools need a runtime gate before execution, especially when the action can spend money, send data, or message on behalf of a user. This is the agentic analogue to enforcing least privilege at the point of use. Teams that do not build interrupts into the control path will end up relying on model behaviour instead of governance.

Named concept: delegated tool authority. The article makes clear that agent usefulness comes from letting a model act through tools on behalf of a user, but that authority is delegated rather than native to the model. That distinction matters because it forces IAM teams to govern the scope, duration, and revocation of tool-backed action rather than treating the agent as a standalone principal. Practitioners need to design for delegated tool authority explicitly.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Delegated tool authority: Agent programmes need a control model that treats tool-backed actions as governed privileges, not as model features. That means approval, scope, and revocation have to be designed around the action path itself, not around prompts or chat history.

Orchestration layers will increasingly become the place where identity policy is enforced for AI agents, because they are the only components that see both the requested action and the runtime context needed to approve or block it. Teams that leave this outside the governance plane will lose visibility into who authorised what.

Access review cycles were built for stable privileges, but tool-calling agents can request and use authority inside a much shorter operational window. That makes issuance-time enforcement and action logging more valuable than retrospective certification.

For practitioners

• Define tool approval points Map every side-effecting tool to a required approval step or policy interrupt before execution, including email, messaging, data access, and external posting.
• Separate intent from execution Keep LLM tool selection in the agent layer, but enforce validation, authorisation, and error handling in the runtime that actually performs the action.
• Treat handoffs as governance boundaries Document what context and authority move between specialist agents, and require re-authorisation when a handoff changes the scope of action.
• Constrain side effects with policy Use explicit rules for spend limits, recipient limits, and data-sharing limits so an agent cannot exceed the user’s intended scope even when it reasons incorrectly.
• Log every tool invocation and interrupt Capture the requested tool, parameters, approval result, and downstream outcome so reviews can reconstruct who authorised what and why.

Key takeaways

• Tool calling changes AI governance because action now flows through authenticated runtime decisions, not just model output.
• Multi-agent orchestration increases the number of boundaries where authority can expand, so delegation has to be explicit.
• The most important control is policy at invocation time, because post hoc review cannot reliably contain side effects already executed.

Key terms

• Tool calling: Tool calling is the pattern where a model selects and invokes an external function during runtime. In agent systems this turns text generation into action execution, so the access decision must be constrained, logged, and governed like any other privileged interaction.
• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Delegated Tool Authority: Delegated tool authority is the practical permission a model receives when it is allowed to invoke scanners, APIs, shells, or other operational tools. The security risk is not only misuse, but also overreach, because the model may chain actions beyond what a human operator explicitly intended.
• Policy Interrupt: A policy interrupt is a runtime stop point that forces approval or additional checks before an agent can complete a side-effecting action. It is a practical control for agent governance because it converts an otherwise continuous execution path into a decision point that humans or policy engines can inspect.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.