Notifications
Clear all
Topic starter
22/06/2026 10:19 am
TL;DR: AI agent systems are organized into five layers, but the article argues that identity and authorization run through all of them, with session-scoped access, agent-as-principal logging, and fine-grained authorization becoming essential as tool use, MCP servers, and prompt injection risks expand. The core issue is that human-oriented auth models assume stable, reviewable access, while agentic systems often need task-scoped control and explicit approval boundaries.
NHIMG editorial — based on content published by WorkOS: The building blocks of an AI agent
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern AI agents that call external tools?
A: Treat the agent as a distinct principal, not just a user session with automation attached.
Q: Why do AI agent systems need session-scoped access instead of long-lived tokens?
A: Because agentic workflows often outlive the original human intent and can continue using delegated access after the task is finished.
Q: What breaks when MCP tools are exposed without access scoping?
A: The agent can discover and invoke capabilities that were never intended for that task, which turns tool discovery into ambient authority.
Practitioner guidance
- Map identity controls to every agent layer Document where authentication, authorisation, and logging occur at the user surface, orchestrator, tool boundary, and downstream service level.
- Scope MCP tools as discrete governed capabilities Limit each tool to the smallest meaningful action, then validate the caller before allowing execution.
- Replace long-lived delegation with task-bounded sessions Use session-scoped access for agent workflows that touch external services or sensitive data.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of tool, orchestrator, and MCP server boundaries in a production agent stack
- Code-level explanation of how tool definitions and JSON schemas shape model behaviour
- Implementation detail for OAuth 2.1, OIDC, and session-scoped access in MCP workflows
- Practical breakdown of how WorkOS structures agent identity, approval flows, and audit logging
👉 Read WorkOS's analysis of the building blocks of an AI agent →
AI agent stacks and auth layers: what IAM teams need to know?
Explore further
22/06/2026 11:10 am
Identity architecture is now part of the agent runtime, not a peripheral control. Once an AI agent can choose tools, sequence actions, and continue across multiple calls, auth becomes a runtime dependency rather than an upstream gate. That matters because the stack no longer has a single trust point. Practitioners should treat identity as an execution-plane design problem, not an afterthought.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do IAM and PAM teams account for agent actions in audit trails?
A: They should log the human requester, the agent principal, the tool or service called, the permissions used, and the outcome. That separation matters because agent behaviour is not the same as user behaviour, even when the agent acts on behalf of a person. Clear attribution is the only way to support review, compliance, and containment.
👉 Read our full editorial: AI agent stacks fail when identity is bolted on last
