MCP Enterprise-Managed Authorization: Security Architecture and Deployment Checklist
A practical guide for security engineers, IAM architects, and security leaders. It maps trust boundaries, assigns validation work to each component, and closes with acceptance tests for MCP Enterprise-Managed Authorization.
Executive Summary
MCP Enterprise-Managed Authorization lets an enterprise identity provider decide which MCP servers an employee’s AI client may reach. The MCP project declared the extension stable on June 18, 2026. Anthropic launched its implementation in beta that day and announced general availability in an August 24, 2026 update.
The decision moves into the IdP, but only at token issuance. This guide shows how a security team can verify a deployment, component by component, and closes with an acceptance checklist.
How MCP Enterprise-Managed Authorization Works
Launch details are in the official MCP announcement. The extension profiles the IETF Identity Assertion JWT Authorization Grant, or ID-JAG, which remains an Internet-Draft.
After enterprise SSO, the client sends its identity assertion to the IdP in an OAuth Token Exchange request. If policy allows, the IdP returns an ID-JAG. The client presents it to the MCP authorization server as a JWT bearer grant. That server validates it and issues an access token for the MCP server.
Draft Section 7.2 says the authorization server SHOULD advertise urn:ietf:params:oauth:grant-profile:id-jag in authorization_grant_profiles_supported. Advertising the profile does not mean any particular issuer or tenant will be accepted.
How Clients Declare Support
The official 2026-07-28 changelog removed the initialize handshake. Every request now carries its protocol version and client capabilities in _meta. The current extension documentation shows support declared there. Examples using initialize reflect 2025-11-25 and earlier revisions.
{
"jsonrpc": "2.0",
"id": 1,
"method": "...",
"params": {
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/enterprise-managed-authorization": {}
}
}
}
}
}Trust Boundaries and Validation Responsibilities
Four components take part across two trust domains. The IdP sits in the enterprise domain. The MCP authorization server and resource server sit in the provider’s domain. The client bridges both. Assessment work should confirm that each check runs at the component responsible for it.
Enterprise Identity Provider
The IdP authenticates the user and evaluates administrator policy during token exchange, as draft Section 4.3.3 describes. The draft sets the ID-JAG audience to the MCP authorization server’s issuer identifier. The IdP may grant fewer scopes than requested, and it MUST then reflect the granted values. Group, conditional access, and step-up rules are IdP policy, so their behavior is vendor-specific.
MCP Authorization Server
This server owns ID-JAG validation. Draft Section 4.4.1 requires checking the typ header oauth-id-jag+jwt. It also requires rejecting a mismatched aud and matching client_id to the authenticated client. JWT grant processing under RFC 7523 Section 3 covers issuer, signature, and expiry. Which issuers to trust is a deployment decision.
The server then applies local policy and may narrow scopes further. The EMA specification, Section 5.1, requires restricting the access token’s audience to the MCP server in the resource claim.
MCP Resource Server
The resource server does not receive the ID-JAG. Draft Section 2.1 describes it as having no direct trust relationship with the IdP. The MCP security considerations require MCP servers to reject tokens not issued for them. Also validate expiry, applicable scopes, and other requirements of the token profile.
Mapping scopes to tools and data is the server’s own authorization design. A valid token describes what the client may request, not what each call may touch.
MCP Client
The client may hold an identity assertion, an IdP refresh token, the ID-JAG, and access tokens. That makes its credential store a high-value target. Draft Section 9.1 says this grant SHOULD only be supported for confidential clients. We recommend asking each vendor where token exchange runs and how client credentials are protected.
Identity Mapping and Account Linking
Subject Resolution
The sub claim is the stable identifier. Draft Section 3.1 requires it to be unique per issuer for single-tenant IdPs. For multi-tenant issuers, uniqueness holds only when the tenant is included. We recommend resolving users by issuer and subject, plus tenant context where the IdP’s identifier model requires it. Store that composite key, not an email address, as the durable link.
Linking Pre-Existing Accounts
The extension documentation permits email fallback for accounts created before enterprise-managed authorization. That fallback is the riskiest mapping step, because addresses get reassigned and reused.
We recommend four safeguards. Require proof that the user controls the existing account, such as signing in to it. Confirm that enterprise and tenant context match. Make linking a controlled, one-time event with an audit trail. Corporate-domain membership alone does not prove ownership of a pre-existing account.
Anthropic states that admins can require a connector to connect only through the IdP. That is vendor behavior, so verify it per connector.
Scopes and Downstream Permissions
The EMA specification, Section 7.2, notes that IdP policy can only be as granular as the server’s scopes. If a server offers one broad scope, the IdP can only grant or deny everything. Review the scope catalog before writing group policy.
We recommend mapping each scope to specific tools and giving write tools distinct scopes. That is design guidance, not a protocol requirement. Then test that the resource server rejects calls outside the token’s scope. The user’s role inside the underlying application also limits access, so document which layer enforces each restriction.
Token Lifetime, Sessions, and Offboarding
Separate two outcomes during offboarding. Blocking new authorization happens at the IdP. Invalidating existing tokens and sessions depends on the provider’s authorization server, resource server, and application.
What Disabling a User Stops
Once a user is disabled, the IdP should refuse new ID-JAG requests. Confirm this also holds when the client presents an IdP refresh token. Draft Section 4.3.3 requires the IdP to reject revoked refresh tokens. How quickly deprovisioning reaches that check is IdP behavior, so measure it.
What Can Survive Offboarding
Draft Section 4.4.3 lets a client re-present an unexpired ID-JAG for a new access token. Access tokens stay valid until expiry unless the provider supports revocation or introspection. The draft’s 300-second grant and 24-hour token are illustrations, not requirements.
Those mechanics suggest a rough estimate, not a guarantee. If grants can be reused and nothing revokes tokens, exposure may reach the remaining grant lifetime plus one token lifetime. Revocation, shorter lifetimes, or provider-side reuse checks shrink it. Surviving application sessions can extend it.
The extension overview calls IdP revocation immediate, which we read as applying to new authorization. Anthropic advises shorter access-token lifetimes. Measure each path rather than assuming instant revocation.
Logging, Attribution, and Incident Investigation
The EMA specification, Section 7.2, limits IdP visibility to token issuance. An investigation therefore needs three log sources, and they use different issuers and identifiers. The IdP issues the ID-JAG, while the MCP authorization server issues the access token.
What Each Source Should Record
The IdP log should show each token exchange decision: subject, tenant where relevant, client, audience, granted scopes, and result. Ideally it also records the grant’s jti. The authorization server log should record each accepted grant’s issuer, subject, jti, and client_id. It should also record a safe identifier for the access token it issued. The resource server log should show tool calls, the resolved local user, and that token identifier.
Building the Correlation Chain
Teams need a demonstrable chain from grant issuance to token issuance to tool calls. The grant’s jti can link IdP and authorization server records. The authorization server’s token identifier can link issuance to tool calls. A documented subject mapping links the enterprise identity to the application account.
Where a link is missing, fall back on timestamps and explicit mappings. Record each missing identifier as an implementation limitation, not a passed test. Route all three sources into one security monitoring and detection pipeline before go-live.
Keeping Credentials Out of Logs
We recommend never logging raw access tokens, refresh tokens, identity assertions, ID-JAGs, or client secrets. Log server-assigned token identifiers instead, or keyed fingerprints whose key is access-controlled. Restrict who can read both the logs and the fingerprint key.
Attribution has one more limit. Tool calls appear under the user’s identity, so separating human and agent actions usually needs client-side records.
Hypothetical Deployment Example
Assessing Access
A 600-person firm connects an AI assistant to an internal ticketing MCP server. Engineers receive tickets.read and tickets.write. Contractors receive tickets.read only. The authorization server issues one-hour access tokens and no refresh tokens.
The team tests a contractor account requesting tickets.write. The IdP returns a grant containing only tickets.read. The resource server then rejects a write call with an insufficient-scope error. A user outside both groups receives a token exchange error and no grant.
Investigating a Failure
An engineer is disabled at 09:00. A ticket update appears under that identity at 09:40. The IdP log shows a final grant at 08:55, with its jti, and denials after 09:00. The authorization server log links that jti to an access token issued at 08:57, valid for one hour. The resource server log ties the 09:40 call to the same token identifier.
The controls behaved as configured, but the token lifetime left a 57-minute exposure window. Remediation shortens access-token lifetime and asks the provider about revocation support. Because a write occurred, the team’s incident response process reviews whether the change needs rollback.
MCP Enterprise-Managed Authorization Acceptance Checklist
These tests are recommended validation work, not a record of testing SiegePal performed. Expected outcomes are our proposed acceptance policy unless a cell cites a requirement. Each method names the owning component. Run the tests in a staging tenant with test identities.
Identity Provider Tests
| Test | Test method | Expected secure outcome | Implementation caveat |
|---|---|---|---|
| User outside the authorized group | Request an ID-JAG as an unassigned test user. Owner: IdP. | Token exchange fails. No grant is issued. | Assumes policy is assigned per MCP server, not only per client. |
| Request for excessive scopes | Request a write scope as a read-only user. Owners: IdP, then authorization server. | Grant or token omits the scope. The resource server rejects write calls. | Effective only if the server defines granular scopes. |
Authorization Server Tests
| Test | Test method | Expected secure outcome | Implementation caveat |
|---|---|---|---|
| Invalid, expired, or mis-targeted grant | Present grants with a bad signature, past exp, wrong aud, wrong typ, or mismatched client_id. Owner: authorization server. | Each is rejected, typically with invalid_grant. No access token is issued. | Crafting test grants may need a test IdP tenant or vendor tooling. |
| Enterprise and personal account mislinking | Create a pre-existing account with a matching email, then sign in through the IdP. Owner: authorization server. | Proposed policy: no link without verified ownership and matching tenant context. Linking is logged. | The extension documentation permits email fallback, so results vary. |
Offboarding Tests
Disable a test user holding a fresh grant, a valid access token, and an open application session. Record when each path stops, then compare against the approved offboarding window.
| Test | Test method | Expected secure outcome | Implementation caveat |
|---|---|---|---|
| New grant request | Request a new ID-JAG. Owner: IdP. | Exchange fails. | Timing depends on IdP deprovisioning and refresh-token handling. |
| Issued, unexpired grant | Exchange the earlier ID-JAG. Owner: authorization server. | Rejected, or accepted only within the approved window. | The draft permits re-presenting unexpired grants. |
| Existing access token | Call a tool with the earlier token. Owner: resource server. | Fails by expiry or revocation, within the window. | Depends on lifetime, revocation, and introspection support. |
| Application session | Continue the session past token expiry. Owner: provider. | Session ends within the window. | Session behavior is vendor-specific. |
Logging Tests
| Test | Test method | Expected secure outcome | Implementation caveat |
|---|---|---|---|
| Log correlation | Make one tool call and trace it across all three logs. Owner: security operations. | A documented chain connects grant issuance, token issuance, and the tool call. | Missing identifiers are implementation limitations to record. |
| Credentials in logs | Search every log store for the test grant and token values. Owner: security operations. | No raw credential appears. Only identifiers or keyed fingerprints are present. | Include debug logs, proxies, and error traces. |
Deployment Dependencies and Remaining Gaps
Deployment Dependencies
This guide assumes the preconditions in draft Appendix A.1.1. The client has an SSO registration with the IdP and a client relationship with each authorization server. Each authorization server is configured to trust the enterprise issuer. The IdP knows which client_id each authorization server expects, as Section 5 describes. Clients and servers also speak compatible protocol revisions.
Identity provider and connector support varies by vendor, so check current documentation before rollout.
Remaining Security Gaps
The extension governs who obtains a token, not what an agent does with it. A prompt injection hidden in a ticket or document can still steer authorized tool calls. SiegePal’s OWASP Top 10 for LLM Applications guide covers that risk class.
Connector code quality, tool design, and data exposure also remain separate review items. Runtime controls are covered in deploying AI agents in production.
Key Takeaways
- Confirm each validation check runs at the component the draft assigns it to.
- Key identities on issuer, subject, and tenant context where required, and gate email-based linking.
- Test each offboarding path separately against an approved window.
- Prove a correlation chain across all three logs without storing raw credentials.
How SiegePal Helps
SiegePal’s cloud security engineering services cover identity federation with SAML 2.0, OIDC, and SCIM. SiegePal helps teams assess identity mapping, validate authorization boundaries, and remediate implementation gaps. Authorization testing of grants, tokens, and trust relationships can be scoped through SiegePal’s penetration testing services. For the runtime risks this extension leaves open, our AI security services assess agent tool abuse and action boundaries. Your team can then retest each fix against this checklist.
Sources Used
Sources are grouped by category. Pages were opened on October 23, 2026, and the analysis reflects public information as of that date.
Specifications and standards work
- Model Context Protocol. Enterprise-Managed Authorization specification (status: Stable). ext-auth repository. Undated.
- Model Context Protocol. Enterprise-Managed Authorization extension documentation. Undated.
- Model Context Protocol. Specification 2026-07-28: Key Changes. Undated.
- Model Context Protocol. Specification 2026-07-28: Authorization Security Considerations. Undated.
- IETF OAuth Working Group. Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant). Revision -04, May 21, 2026. Work in progress.
- IETF. RFC 7523, JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants. May 2015.
Official announcements
- Model Context Protocol Blog. Enterprise-Managed Authorization: Zero-touch OAuth for MCP. June 18, 2026; modified July 9, 2026.
- Anthropic. Centrally manage authorization for MCP connectors. June 18, 2026; general availability update dated August 24, 2026.
Company sources (service scope only)
- SiegePal. AI Security Services. Undated.
- SiegePal. Cloud Security Engineering. Undated.
- SiegePal. Security Monitoring and Detection. Undated.
- SiegePal. Incident Response Services. Undated.
- SiegePal. Penetration Testing Services. Undated.
Need Help With This Topic?
Schedule a free consultation with our team to discuss your specific needs.
Book a Free Consultation