Enterprise-Managed MCP Connectors: What IdP-Governed Authorization Covers, and What It Does Not (2026)

Enterprise-managed MCP connectors are now generally available in Claude, and this is a genuinely good security change. Anthropic's 24 August 2026 update moved the feature to general availability. As Cyber Security News summarized it on 25 August 2026, an admin authorizes a connector once through the identity provider and employees inherit access, with "no consent screen, no manual OAuth flow, and no separate credential to manage." That removes the worst structural problem in MCP authorization: the per-employee OAuth grant nobody could enumerate or revoke centrally.

The per-user OAuth grant is exactly the risk this site has documented, and centralizing it is the right fix. The boundary is scope: remote connectors, enabled by an admin, reached through an opted-in client, by users who authenticate through the IdP - background in Model Context Protocol security explained. Everything else on your fleet works as it did yesterday.

What shipped on 24 August 2026?

Enterprise-managed authorization is now generally available and supports Datadog, Notion, and Slack with Exa, Miro, and Zoom coming soon in addition to the existing support for Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. (August 24, 2026)Anthropic, "Centrally manage authorization for MCP connectors", update dated 24 August 2026

The Help Center's setup flow assumes an identity provider connection is already in place: an admin confirms it, then chooses which roles receive the connector and which scopes Claude can request, under Organization settings > Connectors. Anthropic says "Access stays consistent across Claude chat, Claude Code, and Cowork."

One detail the coverage skipped makes the news better rather than worse: this is not an Anthropic-proprietary feature. It is the Enterprise-Managed Authorization extension to the Model Context Protocol, io.modelcontextprotocol/enterprise-managed-authorization, declared stable on 18 June 2026 per the MCP project blog and originating as SEP-990. Anthropic calls its product "the first implementation of the Enterprise-Managed Authorization extension." That launch post named two clients - Anthropic's shared MCP layer across Claude, Claude Code and Cowork, and Visual Studio Code - and seven server implementations, "with Slack and more actively adding support." It belongs on the same timeline as the 2026 MCP specification changes.

Why enterprise-managed MCP connectors close the worst authorization gap

Before this, in Anthropic's words, "admins enabled a connector for the organization, and then every individual user authorized it themselves." The MCP project named the consequence: security teams "cannot enforce consistent policy: access is whatever each user authorized, with no central control or audit trail." Supabase CISO Bil Harmer, quoted in Anthropic's announcement, describes the prior state as credential sprawl: "The only way to use Supabase through Claude was to be an org owner or hand out Personal Access Tokens to everyone on your team." That is the failure mode in secrets management for AI agents, and one of the five paths by which MCP servers expose enterprise credentials.

The admin controls Anthropic names are the ones a security team would ask for: provision once through the IdP, scope by group and role, revoke through the IdP, shorten access token lifetimes, and require that a connector only ever connects through the IdP. The reasoning on lifetimes is the interesting part - because checking access with the IdP is frictionless, admins can shorten them "without impacting productivity", so a deprovisioned employee's access expires fast instead of lingering on an old token. That is the discipline non-human identity governance has been asking for. Anthropic names HubSpot, Ramp and Webflow as organizations rolling this out; the most-quoted number, "2,000 employees, provisioned through Okta, zero extra steps", is a named customer statement inside that vendor announcement, not measured adoption data.

How does the authorization flow actually work?

The mechanism is Okta's Cross App Access protocol and Identity Assertion JWT Authorization Grants. The client completes single sign-on, exchanges the resulting ID Token for an ID-JAG - the IdP evaluates policy at that step - and presents the ID-JAG to the MCP server's authorization server for an access token. There is no per-server consent screen. Four parties are defined: MCP client, enterprise IdP, MCP authorization server, MCP resource server. Cyber Security News frames the design choice accurately: it extends "existing OAuth infrastructure rather than introducing a parallel authentication surface for security teams to monitor separately." AI gateways and user-level OAuth for MCP servers covers the same token-exchange primitive.

For a server to qualify, WorkOS notes its authorization server must accept the urn:ietf:params:oauth:grant-type:jwt-bearer grant type and advertise it in the grant_types_supported array of its RFC 8414 metadata. Dynamic Client Registration is not supported, so pre-registered client IDs are required. Atlassian described the same exchange from the server side when it brought enterprise-managed authorization to its Rovo MCP server on 29 June 2026, then in private beta: Atlassian OAuth accepts the ID-JAG over the JWT bearer grant and validates its signature against an admin-configured trusted IdP, plus the audience and the client_id binding. A useful scoping of the work, alongside the MCP server security guide.

{
  "issuer": "https://auth.example.com",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "urn:ietf:params:oauth:grant-type:jwt-bearer"
  ]
}

What do enterprise-managed MCP connectors not govern?

Anthropic's post does not frame limitations, and it does not need to - the boundary falls out of the architecture. All four parties must exist for the flow to run, and MCP.Directory puts the failure mode bluntly: missing any one of IdP, client or server support silently "falls back to standard per-server OAuth", the exact grant this feature exists to remove.

Control plane, endpoint plane

The clean way to hold both halves is the two-plane model this site already uses. The control plane decides who may connect, from where, and with what token. The endpoint plane is what is actually configured on the developer's machine. Enterprise-managed authorization is a strong control-plane feature and makes no claim about the other - the same structure as Entra Agent ID governing agents that are registered rather than installed, and the same line drawn in where scan-time vetting ends.

The bottom half of that table is what an audit of Claude Code across a fleet turns up: settings files, hooks, .mcp.json entries, plugins and skills. None of it produces an IdP event, because none of it involves an authorization server.

Does the IdP tell you what the connector did?

No. What becomes centrally visible is authorization and access decisions in the IdP console. MCP.Directory, quoting independent auth researcher Ehsan Hosseini, states the limit precisely: it "answers can this user connect this client to this server, and which scopes? It never answers should this specific action run, right now, on this resource?" The same write-up notes it has no visibility into what happens after that - in its words, "the IdP is not in the loop for the individual tools/call requests that follow" - and advises against treating an EMA-issued token "as a substitute for your own runtime guardrails on what a connected agent is allowed to do."

A second limit sits alongside it. Control works only to the granularity the server defined its OAuth scopes, evaluated at the moment the token is issued rather than per call, and each ID-JAG is audience-restricted to one MCP server. Coarse scopes granted at issue time are not least privilege for AI agents, and a correctly authorized connector can still be steered into a wrong action by content the agent read. That evaluation happens where the agent exposes a decision point - for Claude Code, the PreToolUse hook.

How Anomity covers what enterprise-managed MCP connectors cannot see

Anomity does not broker OAuth, integrate with Okta, replace an identity provider, or block a connector authorization. Those belong on the control plane, and enterprise-managed authorization is the right way to run them. Anomity works the other plane, in three steps.

1. Inventory. The unprivileged Endpoint Sensor runs on Windows, macOS and Linux and inventories eight AI artifact types per endpoint - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - each tied to the endpoint it was found on. That is the register for the local .mcp.json entry and the self-hosted server nobody told IT about: how to build an AI agent inventory.
2. Allow, deny, or log at the hook. Where an agent exposes one, such as Claude Code's PreToolUse event, Anomity evaluates the call against policy before it runs. That is the per-action decision the extension does not make.
3. Audit. Every added, changed and removed artifact lands in a queryable 90-day audit trail and routes to SIEM, Slack, email or Jira - ideally the SIEM your IdP events already reach, so both planes answer from one place.

Anomity collects metadata only, never source code, prompts or secret values, with secrets redacted on the endpoint, and is SOC 2 Type II. It complements rather than replaces network, EDR, DLP and GRC tooling, and the same applies to your IdP. The honest limits: no enforcement where an agent exposes no hook, and no visibility into what happens inside a vendor's cloud.

You can't govern what you can't see.The Anomity principle

What to do next

• Turn it on. On Claude Team or Enterprise with Okta, enable enterprise-managed authorization for every GA connector you already use - it is strictly better than the per-user OAuth grants it replaces. Expect to run both paths for a while: WorkOS points out that Okta is the only identity provider at launch and the ID-JAG standard is still emerging.
• Enable the IdP-only requirement deliberately, per connector, since browser sign-in can otherwise stay on alongside it, and shorten token lifetimes at the same time - that is what converts IdP revocation into access that actually expires.
• Ask internal MCP server owners whether their authorization server advertises the JWT bearer grant in its RFC 8414 metadata, and track approved servers centrally, as in how to build an MCP server registry.
• Count what the IdP will never show you: local .mcp.json entries, per-client configurations, hooks, skills and plugins. Deploying Claude Code across a fleet covers the settings hierarchy they live in.
• Add a per-action decision point at the agent's hook, and send both planes to one SIEM, so "which MCP servers do we have, and what did they do" becomes one answerable question.

Enterprise-managed MCP connectors are the best thing to happen to MCP authorization since the spec added OAuth, and shipping as an open extension with a second client implementation makes it better still. It moves one slice - remote connectors, reached through EMA-capable clients, by IdP-authenticated users - out of the shadow IT category AI agents and MCP servers occupy. The rest is local, self-hosted and per-developer configuration no authorization server sees, and it becomes governable only once it is enumerated. To see what an endpoint inventory returns next to your connector list, book a demo.

Related

• OAuth for MCP Servers: How AI Agent Authorization Actually Works
• MCP Server Security: The Complete Guide
• How to Build an MCP Server Registry
• Microsoft Agent 365 and Entra Agent ID: What It Governs
• Auditing Claude Code Across a Fleet
• AI and OAuth: The Risk Report