Topic starter
22/06/2026 10:23 am
TL;DR: AI agents calling external services need authentication flows that hide tokens from the model itself, and WorkOS’s source analysis says Arcade’s zero-token-exposure approach, OAuth 2.1 handling, and just-in-time authorization are aimed at that gap. The core issue is that access review and least-privilege assumptions break down when the identity that decides what to call is separate from the identity that stores the credential.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Arcade for AI Agent Security: Features, Pricing, and Alternatives”.
Key questions
Q: How should security teams govern AI agent tool calls without exposing credentials?
A: Security teams should place credentials in a separate execution layer, not in the model context, and bind every tool call to a distinct agent identity.
Q: Why do AI agents complicate least-privilege design?
A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent.
Q: What breaks when AI agents use the wrong OAuth flow or token type?
A: The main failure is a confused trust model.
Practitioner guidance
- Separate decision and custody paths Keep the model out of secret storage, token refresh, and credential replay so the agent can request an action without ever holding reusable access material.
- Scope every tool grant to the minimum action Tie OAuth scopes and API permissions to one tool, one user context, and one task so standing privilege does not accumulate across agent runs.
- Enforce execution-time authorization checks Require the runtime to validate tenant, user, tool, and scope before each external call rather than trusting a prior approval event.
Bottom line: AI agent tool-calling changes the security problem from authenticating a user to governing where credentials live during execution.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 11:17 am
Credential custody is now the decisive control boundary for agentic workflows: The central question is no longer whether an AI agent can request an action, but whether it ever sees the reusable credential that makes the action possible. Traditional auth designs often assume the same identity can both decide and execute, yet tool-calling splits those roles. The implication is that governance must follow custody, not just permission labels.
A few things that frame the scale:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
A question worth separating out:
Q: How do enterprise teams decide where agent tool authorization should live?
A: Put primary user authentication in the enterprise identity stack and place tool authorization in the agent runtime. That separation lets SSO, directory sync, and tenant controls govern the application while the runtime enforces per-tool scopes and execution-time checks. Mixing those layers usually creates policy gaps and unclear accountability.
👉 Read our full editorial: AI agent tool-calling shifts identity control to the execution layer