Tool calling and orchestration are reshaping AI agent governance

At a glance

What this is: This is a Stytch episode on tool calling, orchestration, and agent development, with the key finding that LLMs become operationally useful only when connected to authenticated tools and controlled execution paths.

Why it matters: It matters because IAM teams now have to govern not just model access but the delegated actions of AI agents, including consent, authorization, policy enforcement, and multi-agent handoffs.

👉 Read Stytch's session on tool calling, orchestration, and agent development

Context

Tool calling is the mechanism that lets an LLM move from generating text to initiating real actions through external systems. In identity terms, that shifts the discussion from model prompts to delegated access, authenticated tools, and approval boundaries for AI agents.

The article’s core governance gap is simple: an LLM can express intent, but the runtime still decides whether the action is authorised, approved, and safe to execute. That makes agentic AI an identity problem as much as a model problem, especially where agents can send messages, access inboxes, or hand work off to other agents.

Key questions

Q: How should security teams govern AI agents that can call tools on behalf of users?

A: Security teams should treat tool calling as delegated execution, not just model output. The runtime must validate parameters, check authorisation, and enforce approval for side-effecting actions before anything is sent to an external system. Without that boundary, a user prompt can become a real transaction with little oversight.

Q: Why do AI agents create new IAM risks compared with ordinary automation?

A: AI agents create new IAM risk because they can choose actions at runtime and chain tools through orchestration. That means the security problem is not only what the identity can access, but how far it can extend its actions within a single session or delegation chain.

Q: What breaks when tool calling is not separated from execution?

A: When tool calling and execution are not separated, the model’s intent can be mistaken for an authorised action. That creates uncontrolled side effects, weak auditability, and a false sense of safety because the system appears conversational while actually performing privileged work.

Q: What should identity teams review first when adopting multi-agent systems?

A: Identity teams should review which tools can create state changes, which agents can hand off authority, and where approval is enforced. The first priority is to understand the delegation chain, because that is where scope expands beyond the original user request.

Technical breakdown

Tool calling vs execution in AI agents

Tool calling is the LLM’s ability to select a function and provide parameters, but it does not execute anything by itself. The agent application or runtime receives the intent, validates the inputs, checks authorisation, and then calls the external system. This separation matters because the security boundary is not the model. It is the code that decides whether a requested action becomes a real side effect, such as sending email or writing data into another service.

Practical implication: Treat the agent runtime as the control point for authorization, validation, and consent enforcement.

Orchestration and multi-agent handoffs

Orchestration is the layer that moves context between models, tools, and specialised agents. In a multi-agent design, one agent may triage, another may retrieve mailbox data, and a third may format the response. Handoffs are operationally powerful because they let work continue without human copy-paste, but they also create a delegation chain that must remain bounded, observable, and revocable. Without that, a simple request can expand into a wider action path than the user intended.

Practical implication: Map every handoff to a specific trust boundary and log the full delegation chain.

User impersonation, consent, and policy guardrails

The article shows the real unlock for agent utility is not just tool access, but acting on behalf of the user. That requires authentication, authorization, and explicit policy controls that constrain what the agent may do, where it may do it, and how much it may spend or disclose. This is why human-in-the-loop approval still matters for side-effecting tools. The danger is not that the model thinks badly. The danger is that the runtime lets bad intent become a real external transaction.

Practical implication: Use policy-based approval for side effects such as email, payments, and data sharing.

Threat narrative

Attacker objective: The objective is to turn legitimate delegated access into authorised-looking actions that the user did not explicitly intend or approve.

1. Entry occurs when an agent receives legitimate access to tools, data sources, or delegated user context through a trusted runtime. Escalation begins if orchestration lets the agent expand from read-only retrieval into side-effecting actions without a fresh approval boundary.
2. Impact follows when the agent uses authenticated tools to send messages, move data, or trigger downstream actions on behalf of a user or another agent. In a poorly governed setup, the same delegation path can be reused across sessions, creating compounded action scope without meaningful review.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool calling creates an identity boundary, not just an integration pattern. The article is right to separate the LLM’s intent from the runtime’s execution. That separation means security teams must govern the runtime as the enforcement layer for authenticated tools, consent, and policy checks. For practitioners, the key issue is not whether the model can act, but whether every act is mediated by a control that can be audited and revoked.

Human-paced approval models were not designed for agent-paced action. The session shows how quickly an agent can move from prompt to side effect once the tool path is available. That is a governance assumption mismatch: IAM review and approval processes assume a stable request that can be observed before execution. For AI agents, the request can be generated, revised, and reissued inside one interaction window, so the review point shifts into runtime.

Multi-agent orchestration expands the delegation chain faster than most IAM programmes can model. When one agent hands off to another, the security question changes from “who is the user?” to “which identity is allowed to delegate what to whom, and under what constraints?” That is especially important in environments where inboxes, chat systems, calendars, and SaaS tools all become agent-executable surfaces. Practitioners need delegation-aware governance, not just tool inventories.

Policy is becoming the practical control plane for agentic AI. The episode repeatedly returns to user consent, spend limits, merchant restrictions, and side-effect approval as the mechanisms that keep tool use within bounds. That aligns with NIST AI RMF thinking and the OWASP Agentic AI Top 10 focus on tool misuse and identity abuse. The field is moving toward explicit action policy, because prompt quality alone cannot contain runtime behaviour.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often machine identity governance starts from incomplete inventory.
• For the broader control context, see 52 NHI Breaches Analysis for recurring failure patterns across exposed credentials and delegated access.

What this signals

Tool-calling governance will converge on policy enforcement, not prompt optimisation. As AI agents move from retrieval into side effects, the control question becomes whether the runtime can constrain actions before execution. That is why identity teams should align agent policy with the same discipline used for privileged access and high-risk workflow approvals.

Ephemeral agent sessions do not eliminate governance debt. If approval, logging, and revocation are not built into the runtime, the organisation will inherit the same visibility problem it already has with NHIs, only faster. The practical lesson is to design for traceable delegation, not just authenticated connectivity.

For practitioners

• Define the agent runtime as the enforcement boundary Require every tool call to pass through a server-side validation and authorization layer before any external side effect occurs. Keep model output separate from execution, and log the approval decision with the tool name, parameters, and requesting identity.
• Inventory side-effecting tools first Classify tools that can send email, modify records, move money, or expose data, then place those tools behind human approval or policy gates. Start with the highest-impact actions, not the largest tool catalog.
• Model delegation chains across agents Map handoffs between triage agents, specialist agents, and external tools so you can see where authority expands. Include the receiving identity, the permitted action scope, and the revocation point for each handoff.
• Apply consent to every state-changing call Do not rely on a one-time login or session grant for actions that create durable effects. Use explicit consent for each state-changing call, especially where the agent can retry after an error or switch tools mid-task.

Key takeaways

• AI agents become an IAM problem the moment tool calling can trigger real side effects.
• The main security boundary is the runtime that validates, authorises, and logs tool execution, not the model that proposes it.
• Delegation chains and approval gates are now central controls for multi-agent systems, especially where agents can act on behalf of users.

Key terms

• Tool calling: Tool calling is the mechanism by which an LLM requests that an external function be executed with specific parameters. The model proposes intent, but the agent runtime performs validation, authorization, and execution, which makes tool calling an identity and control problem rather than a model-only feature.
• Agent orchestration: Agent orchestration is the coordination layer that moves context, tasks, and results between models, tools, and specialist agents. It determines how work is sequenced and delegated, so in security terms it is where authority can expand, split, or persist beyond the original user request.
• Delegation chain: A delegation chain is the path of authority that passes from a user to one or more agents, tools, or downstream identities. It matters because every handoff can widen or blur accountability, especially when multiple agents can transfer work without fresh review.
• Side-effecting action: A side-effecting action is any agent operation that changes state outside the model, such as sending email, modifying records, or sharing data. These actions need stronger controls because they create durable consequences that cannot be safely inferred from the model’s text output alone.

What's in the full article

Stytch's full post covers the implementation detail this analysis intentionally leaves for the source:

• Live code walkthroughs showing how tool calls are wired into an agent runtime.
• Examples of interrupt handling and approval gates for side-effecting actions.
• Multi-agent handoff patterns using separate specialist agents for email and triage.
• UI and backend flow details that show where security checks are enforced.

👉 The full Stytch episode covers the live builds, approval flow, and multi-agent handoff example.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.