By Nolan Sullivan, Founding Growth Engineerextending IAM to agents
Extending IAM to agents means the same identity provider, groups, and grants that already govern people also govern AI agents, at the tool call, without a second access model. IAM is extended to an agent when its session authenticates as a directory principal, either the driving person or a dedicated identity with a named owner, and every tool call is allowed or denied against that principal’s existing roles.
Most organizations already run a serious IAM program. Employees typically sign in through Okta or Entra, groups map to roles, roles map to grants, and offboarding is a single directory event. None of that reaches agents by default, because agents act after the login. An agent connected to a Model Context Protocol (MCP) server calls tools directly, and the server calls the downstream system with its own separate credential, not one tied to the identity of whoever is driving.
The default workaround shows what unextended IAM looks like, with one shared service account for every agent and a server-level allowlist that is the same for everyone. Extending IAM to agents replaces that with the access model the organization already trusts.
How cleanly the extension maps depends on the kind of agent. One that an employee drives directly in a client like Claude Desktop inherits the employee’s grants in an obvious way, while a custom agent built by one person and triggered by another raises the question of whose permissions apply at all. The broader identity problem behind both cases is mapped in agent identity.
Why do existing IAM controls miss agent tool calls?
IAM as deployed governs the login. A person authenticates through SSO, the identity provider asserts who they are, and the application decides what they can see. That gate sits at the session boundary of applications built for people.
Agent traffic typically bypasses that gate. An agent calls tools over MCP, and the MCP server authenticates to the downstream system with a credential of its own, usually a service account or a long-lived API key provisioned when the server was set up. The person’s roles are generally not consulted, the call is attributed to the service account rather than to anyone in particular, and disabling the person in the IdP typically changes nothing about what the agent path can reach.
This is the same gap that makes non-human identity a discipline of its own, made up of credentials that act with real reach but belong to no one the directory knows about.
It also compounds, since each new MCP server adds another standing credential outside the directory, which is why an agent inventory that records what each agent runs as is the companion control to extending IAM at all.
What does it mean for an agent to inherit a person’s grants?
Inheritance means the agent session authenticates as a directory principal
and carries that principal’s existing roles into every tool call. For an
agent a person drives, the principal is the person. The session starts with
their SSO login, and the agent can call create_refund only if their roles
already allow it. For an autonomous agent, the principal is a dedicated
directory identity with a named human owner, so someone answers for it the
same way a manager answers for a service they run.
The consequence is that existing permissions can apply to agents without new access-control machinery. Teams generally do not need to write an agent-specific policy language or rebuild the role model, since the grants already reviewed, audited, and scoped for people are the grants available to the agent. Inheritance sets the ceiling rather than copying the whole grant, and most organizations restrict the agent to a subset of the driver’s roles, so a person whose role allows a destructive call can still drive an agent that is denied it.
Two supporting pieces make inheritance precise rather than approximate:
- Composite identity. A session records more than the person. It binds the agent workload, the client it runs in, and the task at hand together as one principal. What that tuple contains and why each element matters is covered in agent composite identity.
- Task-scoped credentials. Instead of the person’s password or a long-lived key, the agent authenticates with a short-lived credential minted for the task and bound to the identity, which expires when the task completes. The mechanics are covered in task-scoped credentials.
How this identity model governs what agents actually do in production is walked through end to end in governing agent actions with enterprise identity.
Whose permissions does a custom agent run with?
Inheritance is clean when the person driving the agent is the person whose grants apply. An employee working an agent directly in Claude Desktop or an IDE is that case. The session starts with their login, every action is attributable to them, and the agent carries their roles, usually narrowed rather than widened.
A custom agent breaks that symmetry, since the person who builds a workflow and the person who triggers it are often different people. Three identities could plausibly govern the run, and each maps to IAM differently:
- The builder’s. The agent runs as the engineer who wrote it, so everyone who triggers it borrows that engineer’s reach. This is the confused deputy problem, where authorization reflects who built the tool rather than who is using it, and the audit trail attributes every run to one person who performed none of them.
- The triggering user’s. Attribution improves, but the fit is wrong in both directions. The workflow may need a call the user’s role does not include, which blocks legitimate runs, and the user’s role includes far more than the workflow needs, which the agent inherits for no reason.
- The workflow’s own. The agent gets grants scoped to what the workflow does. But that creates a principal that is neither a person nor a traditional service account, and the directory needs somewhere to put it.
Sometimes the directory can absorb this. The workflow is registered as a dedicated principal with a named owner, the same pattern autonomous agents use, and its grants are reviewed like any other role. Other times the workflow needs a concept the identity system does not have, and that concept is task-scoped credentials, a short-lived credential minted per run, naming the triggering person as subject and the agent as actor, and scoped to what this workflow needs for this task. The credential asserts which agent is acting and for whom, without granting either party’s full standing permissions, and it expires when the run completes.
How is tool-call RBAC different from an MCP server allowlist?
A server allowlist and tool-call RBAC both answer “is this call allowed?”, but they answer it at different places with different information.
| Property | Server allowlist | Tool-call RBAC |
|---|---|---|
| When the decision is made | Once, when the server is configured | On every tool call |
| Who it varies by | Nobody; the same for every caller | The directory principal behind the session |
| What it knows | The server and its tool list | The person, the system, and the action |
| What revocation takes | Redeploying or reconfiguring the server | A directory change, effective on the next call |
A server allowlist is a property of infrastructure. If the GitHub MCP server exposes twelve tools and the allowlist admits eight, every engineer, contractor, and intern who connects gets the same eight. The decision was made before any of them showed up, and a flat allowlist has no way to differentiate one caller from another without a separate server or an equivalent extra layer in front of it.
Tool-call RBAC scopes policy to the person, the system, and the action,
rather than a server-level list that treats every caller the same. A support
engineer’s session can call create_refund because their role allows it, while
a contractor connected to the identical server is read-only. Enforcing that
requires a decision point on the path of every call, which is the job of an
MCP gateway. It terminates the agent session,
resolves the principal, and evaluates each tool call against that principal’s
grants before anything reaches the downstream system.
What happens to agent access when you deprovision a user?
The answer shows whether IAM actually extends to agents or just looks like it does on paper. When IAM is extended to agents, agent access is derived from the directory rather than copied out of it. Disabling the account in the IdP means sessions can no longer authenticate as that person and their grants no longer resolve, so agent access ends at the same point their other access ends. Directory Sync keeps users, groups, and attributes current in between, so a role change can narrow an agent’s reach without anyone editing agent configuration.
When IAM is not extended, offboarding can miss the agent path. A shared service account exists independently of any one employee, so one person leaving does not affect it. An API key embedded in an MCP server config was never tied to that person’s identity in the first place. And the leaver’s security review has no register that would surface either credential.
Autonomous agents need one more control here. Because their principal is a dedicated identity rather than the leaver’s own account, the named owner field is what lets the agent inventory flag agents whose owner has left and needs replacing.
How does the Speakeasy AI Control Plane extend the directory to agents?
Everything above is an architecture, and the Speakeasy AI Control Plane ships it as a product. The platform puts a gateway on the path between agents and tools and wires its decisions to the directory the organization already runs:
- Sessions authenticate through the existing IdP. Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or most SAML or OIDC providers. Directory Sync keeps users, groups, and attributes current.
- The gateway evaluates each tool call. Every call is allowed or denied against the principal’s existing roles, with policy scoped to the person, the system, and the action rather than a server-level allowlist that is the same for everyone.
- Existing permissions apply to agents with no new machinery. The role model stays where it is, and agents are one more thing it governs.
- Deprovisioning in the IdP revokes agent access. The directory event that disables the person’s login is the event that ends their agents’ reach.
The details of the identity model, the credential lifecycle, and the audit trail behind each decision are on the agent identity product page. To see your own directory governing agent tool calls, talk to us.