Primer
What identity for AI agents actually means, why traditional IAM cannot model it, and how to build the missing layer.
Identity for AI agents is the system that binds every action an agent takes to a verifiable principal — typically the user who deployed the agent — so the action can be authorized, attributed, and revoked. It is to agentic AI what IAM is to human users: the substrate every other security control depends on.
This primer covers the model: what it means to give an agent identity, why traditional IAM systems (Okta, Azure AD, Auth0) cannot model agents, how scopes and delegation work in agent chains, how MCP and OAuth fit in, and what a reference architecture looks like in production.
For two decades, enterprise software assumed two kinds of principals: humans who log in with credentials, and machines that run with service-account tokens. Permissions were attached to those principals. Logs recorded their actions. When something went wrong, you traced the action back to the user or the service and revoked or rotated as needed.
AI agents break this model. An agent is software, but it acts on behalf of a user. It can chain actions across tools that have never shared an identity fabric. It can pass context — including hidden instructions — to other agents. It can interpret prompts, hallucinate authority, and take steps the user never authorized. Without per-agent identity, every action looks like it came from a shared service account, and accountability collapses.
The first move is to model the agent as a distinct principal in your identity system. The agent has its own ID, its own credentials, and its own permissions. Crucially, those permissions are not standing — they are derived from the user who deployed the agent, narrowed to the specific tools and data the agent needs.
A useful invariant: the agent's authority is the intersection of (a) the user's permissions and (b) the policy that governs what the agent is allowed to do. Neither alone is enough. Anchoring authority to a user gives you attribution and revocation. Layering policy on top gives you least-privilege and guardrails.
OAuth scopes are app-level: "read calendar," "send email." That granularity is too coarse for agents, which take many distinct actions inside one app. A practical agent identity system supports action-level scopes — "send email to contacts in CRM," "read documents matching a label," "approve refunds under $50" — and evaluates them on every tool call.
Multi-agent workflows add another dimension: delegation. When a planner agent hands a subtask to a worker agent, the worker should inherit a strictly narrower set of permissions, never broader. The identity layer must propagate identity and scope through the chain without losing the link back to the original user.
MCP (Model Context Protocol) is the emerging standard for connecting agents to tools. It defines how an agent discovers, authenticates against, and invokes external capabilities. MCP solves the wire protocol — but it does not, by itself, answer "who is this agent and what are they allowed to do?"
That is the agent identity layer's job. The pattern: the agent identity layer sits in front of MCP servers, authenticates the agent, looks up the user's permissions, checks them against policy, mints a short-lived token, and forwards the call. OAuth is the substrate for tokens and refresh flows; the identity layer owns brokering, storage, scope translation, and revocation.
Identity without audit is unverifiable. Every action that flows through the identity layer should produce an immutable record: which agent, which user, which tool, what inputs, what outputs, what outcome. Audit records belong in a durable store and should be exportable to SIEMs.
Revocation is the back-pressure mechanism. When a user offboards, a credential leaks, or an agent misbehaves, the identity layer must be able to invalidate the agent's access immediately. Token TTLs alone are not enough — the broker should check current policy on every call so revocation propagates in milliseconds, not hours.
A production-ready agent identity layer typically has five components:
Agentic Fabriq implements this architecture as a drop-in layer. The next cornerstone in this series goes deep on MCP, OAuth, and the agent permissioning problem.