agent access management
Agent access management is the set of controls that decide and enforce what each AI agent may call: which tools, on which systems, under which directory principal. It replaces a shared bot credential and a flat MCP server allowlist with an authorization decision on every tool call, evaluated against the grants of the person driving the agent or of a dedicated agent identity with a named owner.
The category exists because agents act after the login. An employee’s access is decided when they sign in, by an application that checks their directory roles. An agent connected to a Model Context Protocol (MCP) server calls tools directly, and the server usually reaches the downstream system with a credential of its own, so nothing on that path consults the person’s grants. In practice that credential is a token in a config file. The GitGuardian 2026 State of Secrets Sprawl report found 24,008 unique secrets in MCP configuration files on public GitHub, 2,117 of them still valid.
Two sibling pages cover the pieces this category is built from. Extending IAM to agents covers sourcing agent grants from the identity provider, groups, and roles the organization already runs. Agent identity covers binding each agent session to a directory principal in the first place. This page covers the category those pieces belong to: how the decision is made, where it is enforced, and which method attaches grants to a session. Where access management sits among the other agent controls, and what order to deploy them in, is the subject of agent governance.
Agent access management has five parts:
- A principal behind every session. Each agent session resolves to a directory identity, either the person driving it or a dedicated agent identity with a named human owner. Without one there is nothing to authorize against. This is the subject of agent identity.
- Grants that stay in the directory. The identity provider remains the system of record for who may do what, and agent access is derived from it on each call rather than copied into agent configuration. This is what extending IAM to agents describes.
- An enforcement point on the tool-call path. A gateway between the agent and every tool it reaches resolves the principal and allows or denies each call. The login gate never sees this traffic, so something else has to. That is the job of an MCP gateway.
- A method for attaching grants to a session. Inherited from the driving person, persistent on a dedicated identity, or task-scoped and minted per run. Each fits a different kind of agent.
- A record of every decision under a name. The audit answers who called what, through which agent, with the grant that allowed it. That takes the composite identity of person, agent, client, and task.
How do organizations manage agent access today?
Most organizations have no written policy for agent access, and the arrangements they run grew out of how agents arrived. A developer connects an MCP server to Claude or Cursor, pastes a personal access token into the client config, and gets to work. Usage spreads through the team, the team consolidates onto one shared credential, and someone in security adds a list of approved servers. Three arrangements account for most deployments:
- Personal tokens in agent configs. The token sits in
claude_desktop_config.jsonor~/.cursor/mcp.jsonwith whatever scope the person accepted when they created it. The GitGuardian report notes that popular MCP setup guides recommend putting keys directly in configuration files, so the pattern spreads with the documentation. - One shared service account per integration. Once a team needs the same server, individual tokens give way to one bot credential granted the union of everyone’s needs. Every agent on the team presents it, and every downstream system records it as the actor.
- A server allowlist in the client or a proxy. The MCP client, or a proxy in front of it, decides which servers may be connected. The decision is made once, applies to everyone, and knows the server and its tool list. It knows nothing about who is calling or what the call does.
For a solo developer, the first arrangement is the right amount of process. The problems start when the same arrangement carries a team, because three controls that work for people stop working at that point.
Attribution. Every call arrives as the service account, so when security asks which agent did something, and who was driving it, the audit answers with one name that covers everyone. Adding agents does not add distinguishable actors.
Least privilege. The credential carries the union of every team member’s
needs. The Supabase MCP demonstration in July 2025 worked because the agent
held the service_role key, which
bypasses row-level security,
so a prompt injection planted in a support ticket could read integration
tokens out of an unrelated table. A read-only, project-scoped configuration
was available and documented. The shared credential made it optional.
Lifecycle. Nothing ends the credential when the people behind it leave, and nothing short of rotation ends it when it leaks. The Salesloft Drift OAuth tokens stolen in August 2025 were used from August 8 to at least August 18 to export data from Salesforce instances at more than 700 organizations before they were revoked. A Silverfort analysis of authentications across hundreds of organizations found that 40% of cloud non-human identities have no owner, which is the condition that lets a credential outlive its purpose.
Replacing the shared account with a per-session principal is the subject of agent identity. The wider catalog of unowned-credential failures is in non-human identity.
Why isn’t employee access control enough for agents?
The reasonable objection to all of this is that the organization already has an access model. Groups map to roles, roles map to grants, and quarterly reviews keep them honest, so agents should use it. That objection is half right. The grants should be the same ones, and a second permission model for agents recreates the shared-account problem in a new place. What cannot be the same is the point of enforcement.
| Employee access | Agent access | |
|---|---|---|
| When the decision is made | Once, at login | On every tool call |
| What it can assume about intent | The person means what they click | Nothing; the agent may be following instructions planted in content it read |
| How fast the population changes | On HR events | Sessions created and destroyed many times a day, with no HR event |
| Who the actor is | The person who logged in | The person, the agent workload, the client, and the task, together |
Timing. A person clicking through an application can only do what the application offers, so a decision at login holds for the session. An agent’s session says nothing about what it will do next. The same session can read a wiki page and then reach for a destructive operation, and because the MCP server usually authenticates downstream with its own credential, login-time controls never see the traffic at all. The decision has to be made per call: this tool, on this system, under this principal.
Intent. An employee’s access model trusts that the person means the action they take. An agent’s cannot, because the model will follow any instruction that reaches it, whether or not the person driving wrote it. Simon Willison’s lethal trifecta names the conditions: private data, untrusted content, and a way to send data out. The July 2026 flaw in the Microsoft Azure DevOps MCP server showed it in production. An HTML comment hidden in a pull request description steered a review agent running with the reviewer’s own credentials into triggering a pipeline in another project, reading a confidential wiki page, and posting it back as a comment. Every call in that chain was one the reviewer was allowed to make. When intent cannot be trusted, a deterministic check on each action is the control that still works, which is why the OWASP Top 10 for Agentic Applications ranks identity and privilege abuse third.
Churn. Employee access changes on HR events, and a quarterly review keeps up with that pace. The Entra Agent ID documentation describes agents that exist for minutes during a task, or are created and destroyed thousands of times per day. A quarterly review of an identity that lived for four minutes is not a control. That is why a dedicated agent identity needs an owner of record, and why an agent inventory is what turns “did offboarding reach the agents” into a question with an answer.
Composite actor. A person acts as one principal. An agent acts as a combination: the person behind the session, the agent workload, the client it runs in, and the task. One assistant serving a whole team produces calls from dozens of people under one workload, so the record has to carry the whole tuple, which is the subject of agent composite identity.
The grants can stay where they are. The decision moves to the call.
Which system should grant, and which should gate?
Two systems share the job, and they should stay separate. The identity provider grants, and a gateway on the tool-call path gates. NIST SP 800-162, the attribute-based access control reference, names the roles: the policy administration and information points hold the rules and the attributes, and the policy decision and enforcement points compute and apply each decision, and may live somewhere else entirely. For employees, the application is the enforcement point. For agents, nothing is, until something is placed on the path of the call.
The identity provider grants
The identity provider already holds who exists, which groups and roles they have, and who owns what, and it is where access reviews and offboarding run. The vendors are extending it to agents on those terms. Okta for AI Agents registers agents in Universal Directory with a named human owner and brings them into standard certification workflows. Microsoft Entra Agent ID gives agents their own identity type, with delegated access on a user’s behalf and autonomous access under rights granted directly to the agent. Both are the right place for the grant to live, because both already answer to the reviews and offboarding the organization runs.
The identity provider is the wrong place to gate, because it never sees the tool call. It issues a token when the session starts and learns nothing about what the agent does with it. Arcade.dev put the gap plainly in its analysis of the MCP enterprise authorization extension: “provisioned” was never the same as “authorized,” and the gap between them is where real attacks live.
A gateway on the tool-call path gates
The gating system sits between the agent and every tool it reaches. It terminates the agent session, resolves the directory principal behind it, evaluates each call against that principal’s grants, and brokers the downstream credential so the MCP server’s own key stops being the recorded actor. That is the job of an MCP gateway, and the products in the market split along the granting and gating line. Cloudflare MCP Server Portals authenticate the person against the corporate identity provider and then enforce which servers the person may reach regardless of the server’s own policy. MCP gateways such as MintMCP and Runlayer sit on the tool-call path. Okta and Entra stay on the granting side.
The gateway is the wrong place to own grants. A gateway that keeps its own allowlists becomes the config file the category set out to replace, with the same drift from the directory and the same invisibility to offboarding. The protocol now connects the two sides. The MCP authorization specification requires OAuth 2.1, and its Enterprise-Managed Authorization extension, which Okta ships as Cross App Access, lets the identity provider issue the grant that the gateway or server enforces. The person signs in once, the directory decides what the agent may connect to, and the gateway decides what each call may do. How that sign-on flows across many servers is covered in MCP SSO.
How is agent access management different from an MCP server allowlist?
A server allowlist is a property of the infrastructure. Agent access management is a property of the principal. If the GitHub MCP server exposes 12 tools and the allowlist admits eight, every engineer, contractor, and intern who connects gets the same eight, and the decision was made before any of them showed up. Revoking one person’s access means reconfiguring the server for everyone.
Agent access management makes the decision per tool call and per principal, so a support engineer and a contractor connected to the identical server get different answers because their directory roles differ, and disabling the contractor in the directory ends their access on the next call. The allowlist is worth keeping as the coarse outer boundary, and per-call authorization does the work the allowlist cannot. How tool-call RBAC maps onto directory roles, with the property-by-property comparison, is in extending IAM to agents.
What are the methods of agent access control?
Three methods attach grants to an agent session, and per-call authorization applies on top of all three. Which method fits depends on whether a person is steering, the split mapped in types of AI agents.
| Method | Principal | Grant lifetime | Fits | Standard |
|---|---|---|---|---|
| Inherited | The driving person, with the agent named as actor | The session; ends when the person is disabled | User-steered agents in Claude, Cursor, or a terminal | OAuth token exchange with an actor token |
| Persistent | A dedicated agent identity with a named owner | Standing, until reviewed or revoked | Workflow and product agents that run unattended | Workload identity, such as Entra Agent ID or SPIFFE |
| Task-scoped | The triggering person as subject, the agent as actor | The task; expires on completion | Delegated runs and assistant-style agents serving many people | Rich authorization requests and short-lived tokens |
Inherited access runs the agent under the driving person’s directory roles. RFC 8693 draws the line that matters: in delegation, the acting party keeps its own identity and acts on behalf of the subject, so the record shows both the person and the agent, where impersonation would show only the person. The person’s grants are the ceiling, and most organizations narrow rather than copy them, so a person whose role allows a destructive call can still drive an agent that is denied it. This is the model for user-steered agents.
Persistent access gives a dedicated agent identity standing grants of its own, scoped to what the workload does rather than to any person. It fits background agents that run on a schedule or serve a product, and it carries the cost of any standing privilege: the grants exist whether or not a task is running, so they need an owner of record and a place in the access review cycle. The autonomous access mode in Entra Agent ID, where rights are granted directly to the agent identity, is the directory-side reference.
Task-scoped access mints a credential per run. It names the triggering person as subject and the agent as actor, carries only what this run needs, and expires when the run completes, so nothing stands between tasks. RFC 9396 exists because a scope string cannot express “please let me transfer an amount of 45 Euros to Merchant A”, and a per-task grant needs that precision. The mechanics, and the case of a workflow built by one person and triggered by another, are in task-scoped credentials.
Per-call authorization is the check that runs whichever method attached
the grants. On each call, the gateway evaluates the tool, the system, and the
principal, and it can require a step up for the calls that warrant one. The
MCP specification supports this directly: a server can reject a call with
insufficient_scope, and a client acting for a user
should attempt a step-up authorization flow
for the additional scope. Tool annotations such as destructiveHint help a
client decide which calls to confirm with a person, though the specification
is explicit that
annotations are hints and must be treated as untrusted
unless they come from a trusted server, so the deterministic rule at the
gateway is what holds.
What does agent access management cost?
The category has four costs that show up in every deployment.
- A hop on every tool call. Per-call authorization means a network hop and a policy evaluation between the agent and the tool, every time. An agent that makes 40 tool calls to finish a task pays it 40 times, and teams that have tuned model latency will notice.
- A chokepoint. The gateway that gates everything is also the component that, when it is down, stops everything. It also governs only what routes through it. A local stdio MCP server on a laptop, or a server an agent reaches directly, is outside the decision, which is why agent inventory and agent discovery are companion controls rather than optional ones.
- Policy that someone has to write. Directory roles do not arrive with a
mapping to
create_refund. Somebody decides which roles may call which tools on which systems, and that work grows with the number of tools, which is why most organizations start with deny rules on destructive calls and widen from there. - Standards and vendors that are still settling. Okta for AI Agents went to early access in March 2026, and Cross App Access integrations reach the Okta Integration Network from August 2026. As of June 2026, the MCP Enterprise-Managed Authorization extension had SDK support in TypeScript and Java, with Python in progress. Most organizations will run a mix of OAuth-native servers, brokered legacy servers, and unmanaged local ones for a while, and the gateway has to carry all three.
For a five-person startup, none of this is worth it yet. A personal token per developer and a short allowlist are proportionate. The calculation changes when one credential serves a team, when agents run unattended, or when an auditor asks who issued a refund and the answer has to be a name.
How does the Speakeasy AI Control Plane enforce agent access management?
The Speakeasy AI Control Plane is one implementation of the category above. The grants stay in the directory, and the decision moves to the call:
- Grants stay in the identity provider. Sessions authenticate through Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or most SAML or OIDC providers, over OAuth 2.1 with PKCE and dynamic client registration. The directory stays the system of record, and the platform reads grants from it on each call. Revocation is a directory change, effective on the next call.
- The gateway evaluates each tool call. Agents reach tools through the platform’s MCP gateway, which resolves the principal behind the session and allows or denies each call against that principal’s grants, whether the principal is the driving person or a dedicated agent identity with a named owner. The gateway brokers downstream tokens, so nobody re-authenticates per MCP server and the server’s own key stops being the recorded actor.
- All three methods run on one path. User-steered sessions inherit the person. Workflow and product agents get a dedicated identity whose name, owner, and grants the platform holds without holding a long-lived secret. Delegated runs get a task-scoped credential minted per request and expired when the task completes.
- Every decision is recorded under a name. The audit answers who called what, through which agent, in which client, with the grant that allowed it.
The identity model and the credential lifecycle behind those decisions are on the agent identity product page. If you are replacing a shared bot account and want to see the gateway evaluate your own directory’s grants per call, talk to us.