Notifications
Clear all
Topic starter
11/07/2026 8:48 pm
TL;DR: Tool calling turns LLMs from text generators into systems that can act through authenticated tools, and Stytch’s episode with Arcade shows how orchestration, approval checks, and multi-agent handoffs make that possible. The governance problem is no longer model quality alone, but who can act, when, and under which policy boundaries.
NHIMG editorial — based on content published by Stytch: Agent ready episode 5 with Arcade on tool calling, orchestration, and agent development
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Model delegation chains across agents Map handoffs between triage agents, specialist agents, and external tools so you can see where authority expands.
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.
👉 Read Stytch's session on tool calling, orchestration, and agent development →
Tool calling and orchestration for AI agents: what changes for IAM?
Explore further
11/07/2026 9:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Tool calling and orchestration are reshaping AI agent governance
