Scoped Access for AI Agents Starts in Your Directory
Central SSO decides which systems an AI agent may reach and gives you one revocation switch. Here is what it still leaves you to build before launch.
A Cursor agent working on PocketOS’s infrastructure decided that deleting a volume would resolve a credential mismatch, and aimed at what it believed was staging. The volume ID was shared across environments, so production went with it, and nothing in the stack objected because the agent was holding legitimate credentials — the account is here.
The loud question afterward was why the token permitted that call. The quieter one is who inside that company could have written down, in advance, every system the agent was able to reach. Scoped access for AI agents is that list: which systems a given agent may reach, granted by whom, recorded where.
How scoped access for AI agents gets granted
The assumption in most tool-connection protocols, MCP included, is that one user authorizes one connection. You click through a consent screen and the tool gets a token. For one person hooking an automation to their own calendar, that is the right shape.
Across a company it comes apart. Dozens of internal tools and hundreds of employees. Every connection gets consented to individually, by whoever happened to be setting up their environment that week, and the record of who connected what lives in nobody’s console.
MCP’s Enterprise-Managed Authorization extension moves the grant to the identity provider. During SSO the IdP issues a signed assertion vouching for both the user and the requesting client; the tool’s authorization server exchanges that assertion for a scoped token, and no consent screen appears. Underneath it is Identity Assertion JWT Authorization Grant, an IETF draft, which Okta ships as a branded variant called Cross App Access.
For a buyer the change is administrative. Which tools an agent can reach becomes a group policy an admin sets, and engineers stop getting chased over Slack to authorize a connector.
Why an AI agent needs its own identity in your directory
Grants attach to identities. An agent without one borrows a person’s, which is how a departed employee’s access outlives their employment: the account gets deactivated, while a token issued through a consent screen keeps working inside a client nobody is looking at and surfaces six months later.
Give the agent its own directory entry and revocation is one action in one place. The two questions an auditor asks — who can read this data, and when were they granted that — become console queries. It also makes the messy case harder to hit by accident, the one where an employee wires a personal account into a work agent, because the assertion the tool will accept has to come from the corporate IdP.
Most of that sits in the auth and API layer, which is why the integration layer has to be in shape before an agent is issued anything at all.
Does central identity make an AI agent safe to deploy?
No. The extension governs which servers a client may reach. Nothing in it decides whether this agent may act on this record at this moment. Okta’s director of identity standards called the identity provider a “centralized governance plane” in the launch announcement, and governance is the accurate word for it: the grant is per-server, not per-record, so what gets handed over at connection time is broad by construction.
Take an agent wired through the directory to a helpdesk and a payments account. Both connections are legitimate and both revoke cleanly. The agent also holds everything it needs to refund an order it should never have touched, because a customer wrote an angry enough message. Constraining that is a second build, and it lives in a policy layer between the agent and the API: an allowlist naming individual routes, argument validation, a spend ceiling per run, and an approval queue for anything irreversible.
If the constrained version of the job has no discretion left in it, a fixed workflow with fixed rules does the same work with no runtime authorization layer to build.
Scope the token, then connect the agent
Start with the specific routes each connection exposes, listed by endpoint, because tool names hide too much. Then the identity the grant attaches to, which should be the agent’s own. Then the actions that stop for a signature, with a named role against each one. Last, how you would reconstruct state if the agent wrote something wrong overnight.
That document is what a risk review will ask for, and it also sets the build cost. An agent with write access to one or two systems of record, an approval path for anything above your limit and full tracing sits in the ₹14L – ₹18L tier of our agent development scoping guide; a staff-facing agent that reads your systems and changes no record is a tier below that. Producing the document is what the scoping step of an AI agent engagement is for: one job, the systems it has to touch, and what it must never do alone.
Before you switch on a connector, write out the worst single action the new scope permits and make that action require a signature.