How AI Agents Should Request Tenant-Scoped Permissions

Tenant-scoped permissions for AI agents must bind each action to a tenant, an agent, and the authority behind its task. A login grant alone cannot do that job. The workable pattern is to narrow tokens before use, preserve their ownership through storage and refresh, and check permission at execution time.

Why AI agents are structurally different from human users in a multi-tenant permission model

Traditional OAuth was designed around a human session, with a redirect, a consent screen, and a short-lived token. That token expires on a timer independently of when the user closes the browser. An agent may keep working hours or days later, so the authorization event and the context in which it acts drift apart. Delegated access becomes long-lived infrastructure. In a multi-tenant system, that leaves a non-human principal that keeps working as permissions change.

The execution path also differs from a conventional integration. An agent can choose an unexpected API call, chain actions in an unintended order, or follow instructions planted in retrieved content. Generic tool calls can expose more access than its task needs. Meanwhile, a shared application credential tells the receiving server which application called, but not which user, tenant, or agent instance initiated the work. The server sees one badge on a crowd of actors.

What scope collapse looks like and why it is the primary risk in multi-tenant deployments

Scope collapse occurs when an agent receives the initiating user’s full privileges for a task that needs only a narrow slice. Handing it access to “the whole CRM” is convenient until prompt injection turns an unintended tool call into a valid API request. An actor thereby uses another party’s authority to do more than that party meant to allow. With weak tenant isolation, an overbroad credential can resolve against another tenant’s data. The blast radius then reaches other customers, so the damage goes beyond one mistaken action.

The relevant boundary is the intersection of what the agent may do and what the user may do. Neither identity alone supplies enough information. A permission pattern earns its keep by limiting what a mistaken or manipulated agent can reach.

The three OAuth flows agents actually use and which one does the tenant-scoping work

The three relevant OAuth flows are Authorization Code, Client Credentials, and Token Exchange. Authorization Code, defined in RFC 6749, supports delegated user access, such as a Slack summarization agent working within consented scopes. Client Credentials, also in RFC 6749, supports a service identity, such as a compliance scanner with no user in the loop. OAuth 2.1 supplies the baseline, mandating PKCE for public clients and deprecating implicit grant and resource owner password credentials.

Token Exchange, defined in RFC 8693, does the narrowing work before a downstream call. Its request carries a subject_token for the existing credential, an actor_token for the agent, the reduced scope, and a requested_token_type. The Security Token Service validates the credentials and issues a narrower token. A support agent might get tickets.update, while a reporting agent gets billing.view. These action-and-resource scopes make the potential damage more calculable than a broad application grant.

The act claim hierarchy tracks the delegation path from the original authorizer through each step that follows. But delegation chain splicing is still a known weakness. A compromised intermediary can submit valid subject and actor tokens from different authorization contexts, producing a signed chain that never occurred if the service validates them independently. Binding both tokens to the same authorization request addresses that risk, but most current implementations do not enforce that binding.

How to structure the two-identity model so every agent call carries both agent and user context

For delegated work, each request must carry the project-level key that identifies the agent application and the user-level identity of the user behind the action. A delegated execution context binds that user to that agent for that task. The backend can then evaluate authority rather than accept the agent’s account of its own importance. The token claims must also carry an explicit tenant_id. A cross-tenant relationship does not authorize an agent working for Tenant A to resolve resources in Tenant B.

The identity model is nevertheless a per-integration choice. Agent-as-itself gives clear bot attribution but weak user-data isolation, while agent-as-specific-user offers stronger isolation at the cost of per-user OAuth onboarding. A shared organization identity is quicker to set up but leaves the team to enforce access in-house. Project- or workspace-scoped identities isolate team integration contexts and are the right default for multi-tenant products. A product can therefore use per-user OAuth for a CRM, a bot token for notifications, and a project-scoped token for an analytics warehouse, documenting and revisiting each choice as it grows.

Token storage and lifecycle management as the runtime boundary that tenant isolation actually depends on

A token with the right scope can still cross tenant boundaries through a shared cache or when it is unclear who owns it in storage. Each stored token must thus keep its tenant and identity context in the storage layer as well as in application code. A query must not return a credential stripped of the information that says who owns it. Envelope encryption, with keys kept separate for each tenant, limits how much a storage failure can expose. Decryption belongs in runtime access, and decrypted tokens must never persist outside controlled memory.

Lifecycle metadata belongs with the credential, including expiration, scope snapshots, and revocation status. Without it, refresh handling and auditing become exercises in reconstructing intent from scattered records. Refresh tokens rotate as access tokens expire and are renewed, all while the agent keeps working. Coordinated background refresh must keep the current narrow scope and avoid quietly bringing back the original broad grant. Centralized OAuth lifecycle management behind scoped identifiers keeps storage, refresh orchestration, and tenant isolation together, preventing a routine renewal from becoming a permission upgrade.

How MCP's authorization model extends and complicates tenant-scoped permissions for agent-to-tool calls

MCP standardizes agent-to-application connections, but authenticating a client to an MCP server does not authorize every tenant, connection, tool, or argument. MCP’s Enterprise-Managed Authorization extension reached stable on June 18, 2026, centralizing grants and revocation through an exchange of a signed identity token for a scoped tool access token. C1 built the model with the open Cross-App Access (XAA) standard, giving short-lived scoped tokens to servers that were entitled to access without asking for consent in separate prompts. Yet MCP’s July 2026 handshake hardening did not resolve CVE-2025-54136, disclosed July 2025, in which a tool description can change after approval. Application-level authorization must therefore revalidate the consented scope against the tool’s current description at call time, because a better handshake does not make everything behind the door trustworthy.

Revocation that cascades across sub-agents and MCP connections, including the offboarding case

Revocation must stop current tokens, refresh tokens, and sessions created for sub-agents. An orchestrator can delegate authority to agents that hold their own credentials, so revoking only the parent leaves descendants able to act. The delegation chain therefore serves as both an audit record and a revocation dependency. Partial revocation leaves working authority behind. Calling that cleanup would be generous.

Employee offboarding exposes the same gap across MCP connections. Removing email, Slack, and SSO access does not by itself revoke credentials that an employee’s agents obtained elsewhere. In the SCIM-driven model, deprovisioning reaches the gateway, which revokes access and stops downstream MCP connections that flowed through it. Without centralized authorization, those connections have separate credentials that someone must keep track of and revoke by hand. Short token lifetimes provide a partial fallback when refresh tokens are tied to the identity provider session, limiting access to the next refresh cycle.

Per-call authorization enforcement and the event schema that makes it auditable

Revocation takes away authority when it is withdrawn, while per-call authorization catches changes during work that is otherwise allowed. Roles can be downgraded, users removed, and resources reshared between consent and execution. Each tool call must therefore face the permissions that apply now. Passing a user-scoped token lets the downstream API enforce what the user can access, which keeps users’ data more separate than relying only on checks in the agent application. With an organization-level token, that enforcement responsibility moves in-house.

Every authorized action should emit an event carrying tenant_id, agent_id, user_id, task_id, the tool called, and the outcome. The surrounding records must support reconstruction of the identity and token used, external API requests, successes and failures, and the workflow’s initiator. This turns attribution into something investigators can follow rather than guess. The same tenant, agent, and task identifiers also support usage-based billing auditability and revenue recognition for variable-consumption contracts under ASC 606 and IFRS 15. A shared event schema lets authorization, usage, and cost attribution use the same record of what happened.

GDPR and data residency as a scoping constraint on what an agent may retrieve into its context window

Permission to call an API does not settle which fields an agent may retrieve. Fetching EU personal data into a context window through MCP is a processing event under GDPR, even when the model runs outside the EU. Tenant scope must therefore constrain data retrieval as well as API actions. Field-level minimization belongs before a tool response leaves the perimeter. The context window is not a customs-free zone.

For EU personal data, the controls must include an integration layer that uses pass-through instead of caching, a region-pinned configuration store, and a zero-retention LLM contract with the right region pin. Small teams rely on that subprocessor chain to keep their residency promises, so procurement requests also ask for data flow diagrams and proof of regional inference. From August 2, 2026, EU AI Act Article 50 also requires disclosure for AI systems that are meant to interact directly with natural persons. Background agents and machine-to-machine communication fall outside that obligation. Disclosure, scoped permission, and lawful data handling are each needed in their own right.

The practical checklist: what a tenant-scoped permission request actually looks like end to end

First, choose and document whether the integration uses an agent, user, organization, or project identity. Second, use Token Exchange before each downstream call to ask for only the action-and-resource scopes the task needs. Third, carry the agent application identity and, for delegated work, the user identity, explicitly bound to tenant_id in the claims. These decisions establish whose authority is being used, where it applies, and how far it reaches.

Fourth, preserve that boundary in storage with envelope encryption, per-tenant keys, lifecycle metadata, and coordinated refresh that retains the current scope. Fifth, authorize every tool call, using user-scoped downstream enforcement where possible. Sixth, map the sub-agent token chains and connect SCIM-driven deprovisioning to MCP revocation, with short token lifetimes as the partial fallback. These controls keep the original grant from outliving either its scope or its owner’s authority.

Seventh, emit the structured event with tenant, agent, user, task, tool, and outcome so the action remains attributable. Eighth, minimize response fields and confirm the required regional and retention controls before retrieving EU personal data. These are not boxes to tick once and archive. As agent fleets and tenant counts grow, identity bindings, live authorization, and event attribution become harder to coordinate, making shared context and a shared schema increasingly valuable. The implementation will evolve, but the rule holds steady, which is that every call must stay inside the authority granted for that tenant and that task.