Quirin Schlegel

Loading

Good plumbing, wrong name - Okta ships MCP's enterprise auth free and the token still carries a person

Okta's Agent SSO reached general availability on 24 August 2026 and is included in core Okta SSO at no additional cost: an AI agent supporting Cross App Access is registered as a first-class identity in Universal Directory alongside human employees and receives short-lived, identity-governed tokens in place of stored credentials. The obvious reading, that agent identity is now a solved and free problem, needs two corrections. First, this is not a new standard - Cross App Access was incorporated into MCP as the Enterprise-Managed Authorization extension on 25 November 2025 and sits in the specification's stable directory, so what shipped in August was distribution and price. Second, the flow delegates human authority: the client exchanges an ID token for an Identity Assertion JWT Authorization Grant and then for an access token, and the specification directs authorization servers to map IdP claims to permissions, use the subject claim "as the primary stable identifier for the user", and determine "who the employee is and what the employee can access". The agent gets a directory row; the token still carries a person. The extension names compliance among its own reasons to adopt - "an auditable authorization trail for all MCP server access" - but an authorization trail is not a record of processing: GDPR Article 30(1)(b) asks for the purposes of the processing, and an ID-JAG states only that an employee was permitted to reach a server at a time. The practitioner move is to adopt it for the genuine Article 32 value of immediate cross-client revocation and the retirement of stored credentials, while writing purpose alongside scope somewhere a DPIA can cite, and starting six-month log retention before Article 26(6) requires it of Annex III deployers from 2 December 2027.

27 August 202611 verified claims8 sources

Okta made agent identity free three days ago. The interesting part is what the token still says.

On 24 August, Agent SSO went GA inside core Okta SSO at no extra cost. An AI agent supporting Cross App Access is registered as a first-class identity in Universal Directory — alongside human employees — and gets short-lived, identity-governed tokens instead of stored credentials. Okta's own survey, fielded in March, found 92% of executives already running autonomous agents and 34% applying the same security controls to them as to people.

Three things before you file this as solved.

1. It is not a new standard. Cross App Access was incorporated into MCP as the Enterprise-Managed Authorization extension on 25 November 2025. It sits in the specification's stable directory. What shipped in August was the price.

2. The flow is delegated human authority. The client exchanges an ID token for an Identity Assertion JWT Authorization Grant, then trades that for an access token. The specification tells server implementers to map IdP claims to permissions and use the subject claim to work out "who the employee is and what the employee can access".

The agent gets a row in the directory. The token still carries a person.

3. The extension names compliance in its own reasons to adopt: "your organization needs an auditable authorization trail for all MCP server access."

An authorization trail is not a record of processing. GDPR Article 30(1)(b) asks for the purposes of the processing. An ID-JAG says employee X was permitted to reach server Y at 09:14. It does not say what the agent did there, or why.

What I would do Monday:

1. Turn it on. Revocation that takes effect immediately across every client is real Article 32 value, and it retires stored credentials. 2. Do not let the token trail become your record. Write the purpose next to the scope, somewhere a DPIA can cite. 3. Decide who the accountable actor is when the subject claim belongs to an employee who was asleep. 4. Start six-month log retention before Article 26(6) makes you. Annex III high-risk applies from 2 December 2027.

Agent SSO answers who asked. Article 30 asks what for.

Which of your agents can answer the second one?

#AIAct #DSGVO #AgenticAI #MCP #IdentitySecurity

Evidence

What this rests on

Every factual claim in the edition above, stated on its own and checked before publication. If one of these is wrong, the argument is wrong — so they are listed where you can check them.

Okta Agent SSO reached general availability on 24 August 2026 and is included in core Okta SSO plans at no additional cost.
Why it mattersIt removes price as the reason not to govern agent access; the remaining reasons are architectural.
okta2026okta
Agent SSO registers AI agents that support Cross App Access as first-class identities in Okta's Universal Directory alongside human employees, and issues short-lived, identity-governed tokens in place of stored credentials.
Why it mattersStored credentials in agent configuration are the single most common finding in an agent security review. This retires them for the covered subset.
okta2026okta
Agent SSO covers only AI agents that support Cross App Access; Okta for AI Agents, generally available since May 2026 as a separate subscription, extends governance to agents regardless of origin or protocol support.
Why it mattersThe free tier is scoped. An estate of home-built agents and MCP clients without the extension is untouched by it.
okta2026okta
Cross App Access was incorporated into the Model Context Protocol as the Enterprise-Managed Authorization extension on 25 November 2025, announced by Okta on that date.
Why it mattersIt reframes the August news: the standard is nine months old, and what shipped in August was distribution and price, not protocol.
okta2025cross · modelcontex2026enterpris · modelcontex2026sep
In the Enterprise-Managed Authorization flow, the MCP client obtains an Identity Assertion JWT Authorization Grant from the enterprise IdP and exchanges it for an access token; the specification directs authorization servers to map IdP claims to permissions, to use the subject claim "as the primary stable identifier for the user", and to determine "who the employee is and what the employee can access".
Why it mattersThe authority carried on the wire is the employee's, delegated. A directory entry for the agent and a user-subject token are different things, and only the second is what the resource server enforces on.
modelcontex2026enterpris
The Enterprise-Managed Authorization extension page lists "Meeting compliance requirements - your organization needs an auditable authorization trail for all MCP server access" among its stated reasons to adopt.
Why it mattersThe compliance framing comes from the specification itself, which is what makes it fair to test that framing against what GDPR Article 30 actually requires.
modelcontex2026enterpris
The Enterprise-Managed Authorization extension is opt-in and never active by default, and support for it varies by MCP client.
Why it mattersAdopting it at the identity provider says nothing about the clients in the estate. The unsupported ones keep doing per-user OAuth and will not appear in the admin console.
modelcontex2026enterpris
Okta's AI Agents at Work 2026 report, published 27 May 2026 from a survey of 292 executives and 492 knowledge workers across seven countries fielded in March 2026, found that 92% of executives say autonomous AI agents are already in widespread or moderate use, and that only 34% of organizations apply the same security controls to AI agents as to human workers.
Why it mattersIt is the comparator: near-universal deployment against one organization in three governing agents like people.
okta2026ai · okta2026okta
GDPR Article 30(1)(b) requires a controller's record of processing activities to contain the purposes of the processing.
Why it mattersAn authorization trail records which principal was permitted to reach which resource. It does not record why, which is what the Article asks for.
privacyregu2016records
AI Act Article 26(6) requires deployers of high-risk AI systems to keep the logs automatically generated by the system, to the extent those logs are under their control, for a period appropriate to the intended purpose and of at least six months.
Why it mattersSix months is a floor, and identity-provider token logs are the logs most likely to be under the deployer's control.
euartificia2026article
Regulation (EU) 2026/1744, in force since 27 July 2026, moved the Annex III high-risk obligations of the AI Act to 2 December 2027.
Why it mattersIt dates the Article 19 and Article 26(6) log duties for Annex III: the runway for deciding which logs are genuinely under your control runs to 2 December 2027.
eurlex2026regulatio

Sources

Every source for this edition, as one PDF BibTeX — all editions

Corrections

What changed after publication

- Took the general-availability date from Okta's own press release (24 August 2026), not from the aggregator listings that placed it on 26 August. A coverage date is not an event date. - Did not present Cross App Access or Enterprise-Managed Authorization as new. Okta's own article dates the incorporation into MCP to 25 November 2025, nine months before the August release; the extension lives under specification/stable/. - Attributed the 92% and 34% figures to Okta's own AI Agents at Work 2026 report, named its publication date (27 May 2026) and its March 2026 fielding, and graded it secondary rather than primary: Okta sells the product the survey motivates. - Dropped two figures from that report as unsafe. Its widespread/moderate split is given as 58% and 35%, summing to 93% against a stated 92%; and 58% appears separately as the share of executives reporting an AI-related security issue. A repeated figure with two meanings is a conflation risk, so neither sub-figure is used. - Used artificialintelligenceact.eu only for the verbatim text of Article 26(1) and 26(6). No date in this edition comes from that site, whose implementation-timeline pages were found stale in a previous edition. The 2 December 2027 Annex III date is carried from CLAIM-2026-08-23-08, verified against Regulation (EU) 2026/1744 on EUR-Lex. - Reused the existing cite key euartificia2026article for the Article 26 page (same URL, already archived) and issued a new key privacyregu2016records for GDPR Article 30, because the existing privacyregu2016article points at Article 25 and cite keys must not be overloaded. - The reading that a directory identity and a user-subject token are different things is presented as the edition's argument from quoted specification text, not as a separate verified claim about Okta's implementation.