Enterprise MCP authorization: central access is not complete tool governance

Separate access approval from permission to act

An enterprise can centrally approve an employee's agent connection without establishing that every later tool call is permitted. MCP's enterprise-managed authorization extension coordinates that access decision through the enterprise identity provider. Its Stable technical profile explicitly limits the provider's visibility to access-token issuance, not the actual traffic between client and server.[1][2]

MCP, the Model Context Protocol, connects an agent application (the client) to services that expose tools (the servers).[2][6] An identity provider, or IdP, authenticates employees and supplies their enterprise identity. The opt-in extension io.modelcontextprotocol/enterprise-managed-authorization uses that identity infrastructure so employees do not have to manually authorize each internal connection.[1][2]

The practical distinction is between two acceptance decisions. Central access asks whether approved people and applications can obtain appropriately limited access to approved servers. Tool-level governance asks whether each operation is allowed, whether withdrawn access stops execution, and whether the enterprise can reconstruct what happened. Our recommendation is to accept those controls separately, with evidence from the component that actually enforces each one.

How access is granted

• Sign in. The employee authenticates to the MCP client through enterprise single sign-on: one enterprise login supplies an identity assertion, such as an OpenID Connect ID Token or SAML assertion.[2]
• Request a grant. The client asks the IdP for an Identity Assertion JWT Authorization Grant, or ID-JAG. JWT means JSON Web Token; here it carries a signed grant. The IdP evaluates administrator-defined policy for the user, client, target MCP server and requested scopes.[2]
• Obtain the resource credential. The client presents the ID-JAG to the MCP server's authorization server. This service validates the grant and applies local policy before issuing an access token for the protected resource.[2][5]
• Call the server. The client sends the access token to the MCP resource server, the service that exposes the tools. That server validates the token and its audience, meaning its intended recipient. The IdP is not specified as an intermediary inspecting every call.[2][3]

The ID-JAG is not the Bearer access token used to call the MCP server. In the profile's token-exchange example, the ID-JAG appears in a field named access_token with token_type N_A. The later resource-authorization response supplies the Bearer token. The grant targets the resource authorization server; the final access token must be restricted to the intended MCP server.[2] Treating both credentials as interchangeable would erase an important enforcement boundary.

A scope is a named permission in the authorization process. Fine-grained scopes can let central policy distinguish read access from write access, but the Stable profile makes this depend on the scope granularity defined by the MCP server.[2] The server still needs to check the relevant scope and any object or argument restrictions when performing an operation. A scope label alone does not demonstrate that mapping.

MCP also provides runtime authorization mechanisms. The core specification describes insufficient-scope responses and challenges for permissions needed by an operation, including scopes determined from request arguments and context.[3] The limitation is therefore not that MCP lacks runtime authorization. It is that an IdP issuance decision does not establish how a particular resource server enforces it.

Match each control to its enforcement evidence

What would make revocation immediate?

The overview says revoking an employee's MCP access at the IdP takes effect immediately across all MCP clients.[1] That is an official overview claim, not an independently observed result. The technical profile describes how to obtain the resource token and limits IdP visibility to issuance.[2] RFC 8693, the token-exchange standard used in that flow, says revocation propagation is not a general property of the exchange protocol: it depends on the implementation, token type or deployment.[4]

Rapid revocation may still be possible. A deployment might connect resource-token validation to live status checks or revocation events. The narrower conclusion is that the exchange alone does not prove an immediate stop at the MCP server. Evidence must show how the central administrative change causes a runtime denial in the selected implementation.

The profile illustrates a 300-second ID-JAG response and an 86,400-second resource access-token response. Those are examples, not mandated lifetimes, product defaults or measured offboarding delays.[2] Core MCP requires rejection of invalid or expired access tokens, and its security guidance recommends short-lived tokens. Neither provision establishes an immediate employee-deprovisioning deadline.[3][9]

Renewal deserves its own check. The profile references ID-JAG draft 04, whose resource-authorization-server guidance says refresh tokens SHOULD NOT be returned and allows the original grant to be resubmitted when an access token expires. The draft separately discusses IdP refresh tokens for obtaining renewed identity assertions or new grants.[5] A refresh token is a credential used to obtain another token. Offboarding checks must distinguish the existing resource access token, a still-valid ID-JAG, the IdP session or refresh path, and any resource refresh path actually implemented.

Define the offboarding requirement before testing: denial of new grants, rejection of existing credentials at the resource server, or cessation of an already-started operation. Give each an acceptable interval. Denying the next HTTP request does not demonstrate cancellation of work already in progress.

Check support and audit identity separately

Extensions are disabled by default and require explicit developer opt-in. Current documentation places client extension support in per-request _meta["io.modelcontextprotocol/clientCapabilities"] and server support in the server/discover response.[7] Separately, the authorization server advertises the ID-JAG grant profile using urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported.[2] These declarations identify different capabilities; neither alone proves the complete authorization flow works.

The overview says client support varies.[1] The community-maintained client matrix retrieved for this analysis had empty Enterprise Auth cells, including in its preserved raw table.[8] Those blanks establish neither support nor non-support for named products. Require documentation and authorized interoperability evidence for the exact client, IdP, authorization server and resource server versions under consideration.

Audit identity also needs a defined boundary. The overview recommends the subject claim as the primary stable user identifier, with email as a fallback for matching existing accounts.[1] A subject identifies the user; an issuer identifies the authority that supplied that identity; a tenant distinguishes organizations using a shared identity service. Draft 04 scopes subject uniqueness by issuer plus subject for single-tenant issuers, and issuer plus tenant plus subject for multi-tenant issuers.[5] Bare email or bare subject is not a sufficient universal enterprise audit key. Preserve the mapping to the resource service's local principal and the client relationship.

Core Tools requires servers to implement proper access controls and recommends client tool-usage logging.[6] Our proposed audit requirement goes further: protect a correlation record linking enterprise identity, client, resource, operation, policy decision and actual outcome. Include enough target context to distinguish permitted from forbidden operations, while redacting tokens, secrets and unnecessary personal data. The IdP's authorization log cannot supply that execution record, and a request accepted by the MCP server does not prove a downstream change completed.

Use two acceptance gates

Gate A accepts the central-access integration: the selected components interoperate under approved user, client, server and scope policy. Gate B accepts the stronger tool-level governance claim: runtime restrictions, offboarding behavior and correlated call auditing are demonstrated too. Passing Gate A alone can justify a bounded integration pilot using test identities and disposable data. It does not waive controls required for real business use. The following procedure is proposed for an authorized, nonproduction environment; none was executed for this article.

• 1. Define the boundary. Record exact component versions, trusted issuers and tenants, client registrations, intended resource, scope mappings, token lifetimes and validation/cache configuration. Specify allowed and forbidden operations and acceptable offboarding intervals. Use test identities and disposable data, not employee secrets or production mutations.
• 2. Check Gate A. Confirm extension opt-in and separate grant-profile discovery. Exercise permitted and denied user/client/server/scope combinations, including wrong-tenant and unsupported-client cases. Where enterprise authorization is mandatory, verify that an unsupported path is rejected rather than bypassing policy; extension documentation allows rejection when a required extension is absent.[7] Preserve issuance decisions and check that the resource server accepts only its intended credential.
• 3. Check runtime enforcement for Gate B. With a valid limited token, submit an allowed operation and forbidden tool, action, object and argument cases directly to the resource server where applicable. Verify server-side denial and the absence of forbidden downstream reads or mutations. If the client requests broader scopes after a challenge, check that central policy still refuses disallowed access.
• 4. Check offboarding for Gate B. Hold an issued access token and a live grant, then withdraw the test identity's access at the IdP and timestamp the acknowledged change. Probe new exchanges, existing-grant redemption, token reuse and every available renewal path. Record requests and decisions, probe frequency, expiry and cache conditions. Report the interval to observed denial; assess already-started work separately. If no denial occurs during observation, report that duration and the unresolved bound, not zero delay or an assumed expiry-only guarantee.
• 5. Check auditing and decide. Correlate issuance with allowed, denied, failed and completed calls and their downstream outcomes. Check missing-event and logging-error handling, redaction, access protection and retention. If only Gate A passes, accept only the test integration, without a complete-governance claim. Approve business use only within the scope whose required controls pass. Correct and recheck failed controls, or defer the affected workflow.

Keep the conclusion scoped to the tested versions, routes, operations and configuration, and revalidate affected controls when those change. An independently inspected deployment showing granular server enforcement, credential-status propagation within its stated interval and protected call-to-outcome correlation would support a stronger governance conclusion. A capability badge or standards citation would not.

Hypothetical example: read-only repository access

Hypothetical, not a deployment report: a company wants engineers to use a managed code assistant with an internal source-control MCP server. Its policy permits repository reads for the engineering group and denies writes and reads of restricted repositories. Central access allows that client, server and limited read scope for the group. This applies the engineering read-only policy described in the Stable profile; repository restrictions here are additional hypothetical requirements.[2]

For Gate A, the team would establish that the permitted exchange works and that an unauthorized user, wrong tenant and broader write-scope request are refused. That would support a test integration using disposable repositories, not approval for unrestricted access to company code. For business use under Gate B, the server must also deny attempted writes and restricted-repository reads with the valid limited token, and meet the accepted offboarding and audit requirements. Hiding a write button in the assistant does not satisfy the server-enforcement test.

Disabling the test engineer would be checked against new grant issuance, the assistant's saved access token, a still-valid grant and each configured renewal path. The offboarding claim would use the observed interval and treatment of already-started reads, rather than assume immediate enforcement. The audit would connect enterprise identity and client to the repository operation, policy decision and actual outcome without storing credentials. No success rate, token lifetime or time-to-denial is assumed in this example.

The resulting responsibility split is specific: the IdP coordinates access issuance, the resource authorization server controls its credentials, and the MCP server and downstream service enforce operations and supply execution evidence. An enterprise should claim governance only for the controls it has demonstrated across that chain.

Evidence limits and edition

This analysis uses the official core authorization and Tools pages labeled 2026-07-28, the independently maintained enterprise-authorization profile marked Stable, and that profile's explicitly referenced ID-JAG draft 04.[2][3][6] The Internet-Draft was published on 21 May 2026 and expires on 22 November 2026. It remains work in progress, not an RFC; it is cited as the referenced edition, not asserted to be the latest IETF revision.[5]

The overview, extension specification and client matrix did not establish explicit publication or update dates in the preserved content. Retrieval on 8 October 2026, Asia/Seoul, is an evidence-observation date, not a product launch date. Actual client interoperability, deployed token lifetimes, revocation propagation, in-flight execution and complete audit coverage remain unmeasured. This is a documented control-boundary analysis and proposed acceptance method, not proof that a particular implementation is safe, unsafe or compliant.