Claude and Okta Turned Off the MCP Consent Screen. The Grant Moved Out of the App You Audit.
On 24 August, Okta's Agent SSO and Anthropic's enterprise-managed authorization for MCP connectors both went generally available, and between them the per-server OAuth consent screen stopped appearing. An admin policy in the identity provider now decides which agent reaches which server.
The mechanism underneath is Cross App Access, an OAuth extension where your IdP mints a short-lived, audience-bound assertion that the client redeems at the MCP server. It is a real improvement over pasted tokens, and it relocates the grant record from the resource app into the IdP.
Two things change quietly. The per-user approval that used to live inside Notion or Figma is not there to review any more, and revocation becomes a policy change whose real latency is whatever access token lifetime the resource server chose.
What shipped
Okta made Agent SSO generally available on 24 August. It registers agents as identities in Universal Directory and issues short-lived, policy-governed tokens instead of static API keys. It is bundled into core Okta SSO at no extra cost, which matters more than the feature list, because it means the default posture for a very large installed base changed on a Monday.
Anthropic shipped the other end the same day. Enterprise-managed authorization went GA for Claude Team and Enterprise after a beta that started on 18 June. An admin connects the IdP, picks which connectors the organisation gets, and users find those connectors already wired up on first login, across Claude chat, Claude Code and Cowork. Okta is the only supported provider so far.
Neither of these is a proprietary handshake. The protocol is Cross App Access, formally the Identity Assertion JWT Authorization Grant, an OAuth extension being standardised at the IETF. MCP adopted it as the Enterprise-Managed Authorization extension, stable since 18 June.
The flow is worth knowing in detail, because the detail is where the operational consequences hide.
The user signs in to the client over normal OIDC. The client then calls the IdP's token endpoint using OAuth token exchange, but asks for an identity assertion rather than an access token. The IdP evaluates the admin's policy: is this client allowed to talk to this server, for this user, in this group, at these scopes, with or without step-up. If policy passes, the IdP returns a signed JWT bound by audience to that one MCP server, so it is useless anywhere else. The client presents that assertion to the MCP server's own token endpoint, the server checks the signature against the IdP's JWKS, and issues its own short-lived access token.
Nobody was asked anything. That is the product.
The consent screen was doing bookkeeping
The consent screen was bad security. Everyone knows this. Users click Allow, the scope list is unreadable, and the decision gets made by whoever is in a hurry, which is everyone. Replacing it with a policy an administrator writes once is straightforwardly better at deciding access.
It was also, quietly, the only per-user artifact recording that a tool had been let into a system. It was timestamped. It sat in each resource app's own connected-applications view. It was scoped to one person, and that person could remove it themselves.
Cross App Access replaces all of that with a policy attached to a group. The improvement is real: one place to look, conditional access rules that already exist, no static secret in a config file. The tradeoff is that the shape of the evidence changed, and most access review processes are built around the old shape.
If your quarterly review works by enumerating OAuth grants inside each SaaS app, that review now sees less every quarter, and the reason is that things are working. Silent success and no usage look identical from inside the resource app. The record you want moved to IdP policy plus token issuance logs, and you have to go and get it there.
The other consequence is directional. Under per-user OAuth, access widened one person at a time, and each person got a prompt. Under Cross App Access, adding an app to a group grants it to everyone in that group at once, and nobody gets prompted, because not prompting is the entire feature. That is fine, as long as somebody owns group membership with that in mind. Okta's own number is the uncomfortable part here: only 34 percent of organisations apply the same controls to agents that they apply to human staff.
Revoking is a policy change, not a kill
This is the part I would check before Friday.
A static API key had one useful property. Deleting it was instant and total. Every caller holding it lost access the moment you hit revoke, and there was no window to reason about.
In this model the thing you revoke is the policy. Flipping it stops the IdP from issuing new assertions, which stops the client from getting new access tokens. It does not reach out and invalidate the access token the MCP server already issued. That token lives until it expires, or until that server honours a revocation it was told about.
So your actual revocation latency is now the resource server's access token lifetime, and that number was chosen by a vendor, not by you. Across fourteen named integrations it will not be one number. Find out what it is for the connectors that touch anything you would be unhappy to explain, and find out whether those servers implement token revocation at all or just short expiry.
None of this is an argument against the design. Short-lived credentials are the right answer. It is an argument for knowing that "revoked" has become a slightly softer word than it was last month.
The list is short, and your servers are not on it
Claude's launch connectors are Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase, with Slack, Exa, Miro and Zoom flagged as coming. Okta's own named set adds Datadog, Glean, Notion, MintMCP and Archestra.AI. Call it fourteen.
Cross App Access needs both ends. The client has to be a confidential client that can authenticate to the IdP, and the MCP server has to validate assertions and run its own authorization server. Your internal MCP server, wrapping your own API, written in an afternoon, does neither.
That leaves most organisations running two authorization regimes at once. One is governed and centrally visible, and it covers a shortlist of large SaaS products. The other is the pile of personal access tokens and service accounts wired into the servers you wrote yourself, and it is unchanged.
The failure mode is not that the second regime exists. It is that the first one has a dashboard. Attention follows the dashboard, the static keys stop getting reviewed at all, and the org tells itself it solved agent identity in August. Okta is explicit that Agent SSO does not cover shadow agent discovery, lifecycle governance, access certification or deactivation. Those sit in a separate paid product, which is also why Okta agreed on 30 July to buy Permiso Security for around 200 million dollars.
What to actually do
Move the access review to where the grant lives. If you are on Okta, your connector inventory is now IdP policy and issuance logs, not per-app connected-application pages. Whoever runs that review needs the new query, not the old one.
Check token lifetimes on the connectors that matter, and treat that number as your incident response clock. Ask each vendor whether they support revocation or only expiry.
Write down which agents are not covered. Every internal MCP server and every cron job holding a PAT belongs on a list that is explicitly outside this system, so the gap is a known gap rather than an assumed absence.
Watch group membership like it is an access grant, because it is one now. The prompt that used to slow down a widening scope is gone by design, and the only remaining check is whoever approves adding people to groups.
Ric Smith, Okta's president of products and technology, described agents becoming "a primary interface for how work gets done." That framing is right, and it is why this landed as a free feature in the base plan rather than a security upsell. The consent screen was never protecting anything. It was just the last place an ordinary person was told, in writing, what their tools could reach.