Your Employee Has Access. Whether an Agent Inherits It Is Not Their Call.

Okta's Cross App Access did not launch today, and the first thing this record has to do is refuse the framing that it did. It was announced on 23 June 2025. What is actually new, as of the current radar date of 24 August 2026, is narrower: a scheduled Okta Integration Network milestone that Auth0 itself described only as expected, and a chance to check what has and has not actually reached general availability against what was merely promised.

Five dates, kept separate

On 23 June 2025, Okta announced Cross App Access as an OAuth based protocol for centrally governing app to app and agent to app access. On 23 June 2026, a year later, Okta announced an expanded ecosystem naming more than 25 early adopters, Anthropic, Asana, Atlassian, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, Glean, Granola, Linear, Slack, Supabase, VS Code and Zoom among them. On 6 August 2026, Auth0 published implementation guidance for building a Resource Application against XAA, describing that support as Open Early Access, and documented its relationship to the Model Context Protocol's own Enterprise Managed Authorization extension. On 22 August 2026, the Model Context Protocol's own Lead Maintainers published a new protocol roadmap naming agent identity and enterprise ready security a top level priority for the first time, distinct from anything Okta, Auth0 or Anthropic announced and two days before this record's own current radar date. And on 24 August 2026, today, Auth0's own guidance named the date when integrations including Anthropic, Asana, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, VS Code and Zoom were expected to become available through the Okta Integration Network, and today is also this record's own verification date for the roadmap, not the roadmap's own publication date. Five dates, five different kinds of event: an original protocol announcement, an ecosystem partner announcement, a piece of implementation documentation, a protocol governance roadmap, and a scheduled catalog milestone framed as an expectation rather than a promise. Collapsing them into one launch, or worse, into one date, is the single easiest way to get this story wrong, and it is the mistake this record is built to avoid.

What the protocol actually does

Read directly from Auth0's own public sample implementation, auth0-samples/auth0-cross-app-access-inspector on GitHub, the mechanics are specific and worth stating precisely rather than in the abstract. A requesting application, acting on behalf of a signed in user, does not prompt that user to separately authorize a connection to each resource application it needs. Instead it exchanges an ID token for a signed identity assertion, an Identity Assertion JWT, universally shortened to ID JAG, at the enterprise identity provider's authorization server, using the RFC 8693 OAuth token exchange grant. The identity provider issues that ID JAG only if an administrator has already configured policy permitting the requesting application to reach the named resource application on behalf of that user. The requesting application then presents the ID JAG to the resource application's own authorization server and exchanges it for an access token, using a JWT bearer grant, with the resource application's own registered API identifier carried as the audience the ID JAG names. The resource application's authorization server is the party that actually issues the token the requesting application ultimately uses, and it does so against its own registration, not against a token minted unilaterally by the identity provider.

That sequence answers a question this record treats as central rather than incidental. What is authorized is a relationship: this requesting application, reaching this resource application, on behalf of this user, because an administrator's policy already says so. Nothing in the mechanics reviewed for this record describes the identity provider or the resource application evaluating a specific tool call, message, file or transaction the requesting application later attempts with the resulting access token. That is a deliberate architectural choice worth stating plainly: Cross App Access governs delegated cross application access. It does not, on the evidence available to this record, perform action level authorization, and this record does not describe it as though it does.

Where this sits in the standards, and where it does not

Okta describes XAA as built on an OAuth extension and says it has been incorporated into the Model Context Protocol's own Enterprise Managed Authorization work. Moona Intelligence checked the Model Context Protocol's own account of that directly, fetching blog.modelcontextprotocol.io rather than relying on Okta's characterization of it. The Model Context Protocol's own post, dated 18 June 2026 and authored by Paul Carleton, a core maintainer, states plainly that Enterprise Managed Authorization is now stable, and just as plainly that it is an extension, documented in a separate extension repository, rather than a change to the ratified core specification. The same post presents Okta's Cross App Access, and the underlying ID JAG grant, as one compatible mechanism for implementing that extension, naming Okta as the identity provider early adopter alongside Anthropic's Claude and Visual Studio Code as client side early adopters and Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase as server side early adopters, with Slack separately described as still adding support as of that post's own date. Nothing in that account names XAA as the only mechanism the extension permits, and this record does not describe it as one.

The ID JAG grant itself carries a more specific standards status than a vendor feature and a less settled one than a ratified standard. Search indexed content of the IETF Datatracker, which this session could not fetch directly, identifies draft ietf oauth identity assertion authz grant as a working group document of the IETF's OAuth Working Group, succeeding an earlier individual submission by the same editors, with its own intended RFC status still unset. An adopted working group draft is a meaningfully different claim from an individual proposal nobody has taken up, and it is still a meaningfully different claim from a ratified RFC. This record states the distinction rather than rounding it in either direction.

The 22 August roadmap: agent identity becomes a top level priority

On 22 August 2026, the Model Context Protocol's blog published The New MCP Roadmap, authored by David Soria Parra and Den Delimarsky, both named in the post's own byline as Lead Maintainer. Moona Intelligence fetched the post directly from blog.modelcontextprotocol.io, the same domain this record already relies on for the 18 June Enterprise Managed Authorization post, so this claim is verified rather than search indexed. The post opens by reviewing a prior roadmap from March 2026, which set four priority areas, transport evolution and scalability, agent communication, governance maturation and enterprise readiness, and states that the bulk of that work landed in the 2026 07 28 specification release. The updated roadmap that follows sets five priority areas for the specification cycle ahead: agentic messaging primitives, HTTP native transport unification and hardening, agent identity and enterprise ready security, improved primitives, and improved SDK developer experience. This record verifies the third of those five, because it is the one that speaks directly to Authority Provenance, and treats the other four as outside its scope.

The post states its own reasoning for elevating agent identity in language worth quoting rather than paraphrasing, because the framing itself is the news. MCP authorization today, the post says, is built around a person approving access in a browser, and that works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who is not present, or delegating narrower authority to subagents. The post states the maintainers want MCP servers to have a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long lived tokens. That is the Model Context Protocol's own core maintainers naming, in their own words, the same gap this record has spent this piece describing inside Cross App Access specifically: a model built for a present, interactive human is being asked to cover callers that are not that.

The technical path the roadmap names is specific rather than aspirational in its vocabulary, even where the underlying work is not yet complete. The post states the work covers finalizing Demonstrating Proof of Possession, DPoP, defined in RFC 9449, and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID JAG grant already behind Enterprise Managed Authorization, and standard token exchange, alongside continued engagement with the IETF OAuth and WIMSE working groups. Read against the rest of this record, that sentence does two things at once. It confirms, in the Model Context Protocol's own words, that the ID JAG grant and Enterprise Managed Authorization this record already analyses are the mechanism the project intends to build the rest of its enterprise identity story around, rather than a side branch. And it names two additional pieces, DPoP and Workload Identity Federation, that this record had not previously covered, as work still underway rather than work already shipped. The post itself supports that reading directly: it states that Specification Enhancement Proposals falling within these priority areas get expedited review and the best chance of acceptance, language that describes a review queue for proposals not yet accepted, not a changelog of proposals already merged.

What is stable, and what is still an open draft, checked directly

This record does not take the roadmap's own framing of DPoP and Workload Identity Federation as underway on trust. It checked the two Specification Enhancement Proposals the roadmap itself points at, directly on github.com, which resolved for this session where modelcontextprotocol.io and datatracker.ietf.org did not. SEP 1932, DPoP Profile for MCP, is Pull Request 1932 in the modelcontextprotocol modelcontextprotocol repository. Fetched directly, it carries the labels auth, draft, extension, roadmap slash security, security and SEP, and its own project status is Draft inside what the repository calls its SEP Review Pipeline. It remains open and unmerged as of this record's verification. SEP 1933, Workload Identity Federation, is Pull Request 1933 in the same repository, itself the link the roadmap post cites for Workload Identity Federation. Fetched directly, it is titled SEP 1933, Workload Identity Federation, carries the same Draft status inside the same review pipeline, and also remains open and unmerged as of this record's verification. Neither proposal is a ratified extension. Neither is the current specification. Both sit distinctly behind Enterprise Managed Authorization, which this record has already established reached stable extension status, documented in a separate stable extension repository, on 18 June 2026. This record states that maturity ladder explicitly because the roadmap post itself uses confident, direction setting language, finalizing, driving adoption, defining an opinionated path, for work that, checked against the proposals themselves, has not yet been accepted.

SEP 1933's own text, read directly rather than through the roadmap's summary of it, proposes a specific mechanism: autonomous workloads, the kind that run on Kubernetes, under SPIFFE and SPIRE, or inside a cloud provider's own runtime, would authenticate to an MCP authorization server by presenting a platform issued JWT, a Kubernetes projected service account token or a SPIFFE JWT SVID among the examples named, through RFC 7523's JWT bearer grant, with the authorization server resolving the issuer's signing keys through OpenID Connect Discovery rather than a new, MCP specific trust mechanism. The proposal's own stated motivation is that requiring these workloads to additionally register as OAuth clients or manage long lived secrets introduces unnecessary complexity and weakens security posture, and the proposal explicitly declines to support WIMSE Workload Identity Tokens or invent a new authentication mechanism, building instead on RFC 7523 and existing OpenID Connect Discovery. Conformance tests and early SDK work are referenced inside the pull request's own discussion, but this record found no evidence, in the proposal itself or in the Model Context Protocol's published conformance material this session could reach, of a merged, shippable Workload Identity Federation extension as of the verification date. A reader checking this claim later, after the SEP process has moved, should treat this record's snapshot as dated 24 August 2026 rather than as a permanent status.

What an ID JAG's own claims actually establish

Enterprise Managed Authorization's own stable specification, fetched directly from the modelcontextprotocol ext auth repository on github.com, documents the Identity Assertion JWT Authorization Grant with a worked example rather than a standalone claims table, and states plainly that the ID JAG is a JWT issued and signed by the identity provider with the claims defined in Section 3.1 of the IETF's own draft ietf oauth identity assertion authz grant, the same working group document this record already tracks separately as not yet a ratified RFC. The worked example itself carries, and this record lists only what it actually shows rather than inferring a fuller schema: jti, a unique identifier for the assertion, iss, the identity provider that issued it, sub and email, identifying the represented user, aud, the MCP server's own authorization server, resource, the canonical MCP server URL the connection targets, client_id, identifying the requesting application, exp and iat, bounding the assertion's own lifetime, and scope, the enterprise policy limited OAuth scope the identity provider is willing to assert for that user, application and server together. The specification is explicit that the MCP server's own authorization server must independently validate the resource claim against its own registered identifier, stating that a server which skips this check cannot distinguish an ID JAG intended for it from one intended for a different server, which is the same architectural boundary this record already described above: the resource application's authorization server, not the identity provider, issues the token actually used, and does so against its own registration.

What that claim set proves, read strictly, is who the identity provider says the represented user is, which requesting application it is willing to vouch for on that user's behalf, which single resource server the vouching is scoped to, and a policy derived scope and expiry the identity provider is willing to stand behind. What it does not prove, because nothing in the claims or the specification's own text says otherwise, is the organizational mandate question this record already raised above: an administrator's technical ability to configure the policy that causes an ID JAG to issue is not the same fact as that administrator holding the correct governance authority to make that specific delegation. This record also checked the stable specification directly for revocation language and found none. The specification's own text describes issuance, not what happens to a policy, an assertion or a downstream access token after issuance when an administrator later changes that policy. This record's earlier treatment of revocation, resting on Auth0's general material rather than Enterprise Managed Authorization's own specification, stands unchanged by this check, and this gap, the specification's own silence on revocation, is now confirmed directly rather than inferred.

The subagent sentence, and the mechanism it does not yet name

The roadmap's own language, delegating narrower authority to subagents, is a specific and material claim for this record's purposes, because it is the Model Context Protocol's own core maintainers naming, for the first time in a top level roadmap, the same downstream delegation question this record's own coverage of Anthropic's subagent forking and Grantex's bounded delegation protocol already treats as a distinct governance problem. This record searched the roadmap post itself, SEP 1932, SEP 1933 and the Enterprise Managed Authorization stable specification for an actual attenuation mechanism, a rule establishing that a subagent's granted scope must be a subset of its parent's, a token exchange step that narrows scope on each hop, an audience or resource restriction tied to delegation depth, a numeric hop limit, or a rule that revoking a parent grant cascades to revoke everything delegated from it. It found none. The Enterprise Managed Authorization specification, checked directly above, describes a single hop relationship between a requesting application, a resource application and a represented user, and says nothing about a requesting application itself delegating the resulting access onward to a second agent. SEP 1933 describes a workload authenticating to an MCP server directly through its own platform issued identity, not a workload receiving delegated authority narrowed down from a first agent's own grant. Nothing this record could reach names which principal would even technically constitute the downstream grant in a subagent scenario, the parent agent's own credential, a fresh workload identity for the subagent, or some third construction. This record states that gap plainly rather than filling it: the Model Context Protocol has made subagent delegation a named, top level protocol priority. It has not, on anything this record could verify as of 24 August 2026, published a mechanism for it. Moona Intelligence's own coverage of Grantex's Protocol Specification, which does define scope subset enforcement, an expiry ceiling tied to the parent grant, a default delegation depth of three hops with a hard cap of ten, and atomic cascading revocation of descendant grants, is the sharpest available contrast to what the Model Context Protocol has stated an intention to build and has not yet specified. This record treats that contrast as informative, not as evidence that the Model Context Protocol will converge on the same design.

Twenty five partners is not twenty five identical facts

Okta's own 23 June 2026 announcement is reported, across independently phrased search passes, as sorting its named partners into requesting applications, among them Claude, Cursor, Docker, VS Code and Zoom, resource applications, among them Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, Slack, Supabase and Zoom again, and a further category of identity infrastructure and gateway providers. That a partner can appear as both a requesting application and a resource application in the same announcement, as Zoom does, is itself evidence against reading the list as one uniform thing. So is the maturity ladder underneath it. A protocol announced in June 2025 is not the same claim as an MCP extension marked stable a year later. Neither is the same claim as more than 25 companies named as early adopters. Neither of those is the same claim as Auth0's own Resource Application support, which Auth0 itself labels Open Early Access rather than general availability. None of those is the same claim as a scheduled catalog milestone Auth0's own guidance describes only as expected. And none of those is the same claim as Claude's own integration, which remains, as far as this record can establish, a beta limited to approved joint Okta and Anthropic customers months after the ecosystem announcement that named it. Moona Intelligence's own evidence ledger counts an artifact once no matter how many partners it names, and a partner named in an ecosystem announcement is evidence of a commitment, not independent proof that the partner has itself shipped, tested or operated the integration.

What the catalog shows today, as best this record can establish it

The task this record set for itself was to check the current Okta Integration Network catalog directly rather than rely on Auth0's 6 August prediction of what would appear there on 24 August. That direct check was blocked: oin.okta.com, and the individual Claude and Slack integration pages, could not be fetched by this session on any attempt. What is available instead is search indexed material of uncertain freshness, describing a Slack listing that carries Cross App Access and Brokered Consent capability tags and a Claude listing that carries an AI agent management capability alongside a beta Cross App Access program. This record records that as a real lead worth an editor's direct confirmation, and explicitly does not treat it as proof that today's catalog state matches the scheduled milestone, because an indexed snippet cannot establish its own freshness and this session has no way to date it against the live page.

What is more solidly established, because it is corroborated by an independently confirmed document title across separate search passes rather than a single snippet's paraphrase, is Claude's own status. Okta's own support material carries an article titled Claude Enterprise Managed Auth With Okta Cross App Access XAA Beta Participation Guide. A title alone is not the same as reading the article's body, and this record does not claim the body's exact wording. But a support article whose own title names a beta and a participation guide is not, on its face, a description of a generally available capability, and this record holds that line rather than promoting a beta to general availability on the strength of an ecosystem announcement made two months earlier.

The distinction this record exists to hold onto

Underneath the chronology is a single question, and it is the reason this record exists rather than a shorter note about a product update. When an AI agent, Claude among the named requesting applications, reaches a resource application, Slack or Asana or Supabase, on an employee's behalf, two different facts are doing two different kinds of work, and Cross App Access's own design keeps them separate rather than collapsing them.

The first fact is the employee's own identity and their own existing standing in the resource application: which groups they belong to, what role they hold, what they were already permitted to touch before any agent was involved. Nothing reviewed for this record shows XAA replacing that. The Model Context Protocol's own account of the extension is explicit that access is scoped to the groups and roles a user already holds, and that the user is granted access automatically, without a fresh consent prompt, the first time they use the requesting application after an administrator has already enabled it.

The second fact is a different decision entirely: whether the requesting application, the AI agent, is permitted to exercise that employee's standing at all. That decision belongs to whoever configured the XAA policy at the identity provider, and it is made once, for the organization, rather than once per employee per app. The protocol proves that an administrator made that decision. It does not, on any evidence available to this record, prove that the administrator was the correct person, under the organization's own governance, resource ownership or separation of duties rules, to make it. This record searched specifically for a documented administrative role requirement, a delegated administration boundary, a resource owner approval step or an entitlement management workflow gating who may configure an XAA policy, across Okta's, Auth0's and Anthropic's own material. It found technical capability to configure the policy documented everywhere. It found a separate, higher bar establishing that the configuring administrator was organizationally entitled to make that specific delegation nowhere. That gap is not a flaw unique to Okta. It is the same gap Moona Intelligence has already found in Nuggets' Authority Control Plane and in Uber's own actor chain architecture: proof of who technically constituted an authorization is not proof that the constituting party held the mandate the resulting delegation implied. This record preserves the mandate question as partially documented rather than resolved, because the identity of the grantor is real and the grantor's underlying legitimacy is not addressed by anything reviewed here.

Consent removed for the connection, not for the person

The architectural claim Okta, Auth0 and the Model Context Protocol's own material all make in the same direction is that Cross App Access reduces or removes repeated end user OAuth consent prompts for connections an administrator has already approved. That is a real and specific claim, and this record does not read it as making the user irrelevant to the authorization, because it does not. The user remains the represented principal: the party whose identity is asserted in the ID JAG, whose existing group membership and role the access is scoped to, and whose resource level permissions inside the destination application, as far as this record could establish, continue to govern what is actually reachable once the connection exists. What changes is a narrower and still consequential thing: the user is no longer the party who decides, app by app, whether an external requesting application may stand in for them at all. That decision moved to the organization, once, upstream of the user's own session.

An unresolved question this record does not manufacture an answer to

One property this record went looking for specifically, because the task of separating authority layers requires it, is whether Cross App Access can grant a requesting application access to something the user does not already hold in the resource application, a Slack channel they are not a member of, an Asana project they cannot see, a Supabase resource outside their own role. The architecture reviewed here is consistent with an upper bound: the resource application's own authorization server independently issues the final access token, against its own registration, after the identity provider has only authorized that the connection may exist. But nothing reviewed for this record states that upper bound directly, in Okta's, Auth0's or the Model Context Protocol's own material. This record leaves the question undocumented rather than assuming, in either direction, that the underlying resource permission model is or is not preserved as a ceiling.

Revocation, precisely stated

Auth0's own general material, not specific to XAA, states that because access is governed centrally by the identity provider, disabling a user or adjusting an agent's permissions blocks renewal of that access across connected applications. That is a specific and checkable claim about one object: the ability to obtain a new token going forward. It is a different claim from stating that a token already issued is invalidated the instant a policy changes, and this record could not confirm which of those two the actual XAA token lifetime supports. General OAuth refresh token behavior, which this record does not extend to XAA as a confirmed claim but notes as the pattern the architecture is built from, has revoking a refresh token stop future renewal while a short lived access token already issued continues to work until its own expiration. This record keeps preventing renewal and invalidating an already issued credential as two separate claims, states what is documented for the first, and marks the second undocumented rather than assumed.

The Authority Provenance ledger

Four distinct actors sit inside the Cross App Access and Enterprise Managed Authorization architecture, and this record does not collapse them. The organization, acting through whichever administrator configured the XAA policy, is the party authorizing the relationship between a requesting application and a resource application. The human employee is the party whose identity, group membership and resource level permissions are represented and exercised. The requesting application, an AI agent among them, is the party receiving delegated access to act. The resource application is the party independently enforcing its own access controls when it issues the final token. The 22 August roadmap adds two further, distinct grant paths this ledger keeps separate rather than folding into the same rows: a workload identity path, where a trusted issuer, not an enterprise administrator, is the technical authority, and a still unspecified subagent delegation path, where the roadmap has not yet named which principal would constitute the grant at all.

Authority grantor. Three separate paths, not one. For Cross App Access and Enterprise Managed Authorization, documented as the administrator who configures the XAA policy at the identity provider, verified through the protocol's own mechanics: no ID JAG issues without that configured policy existing first. For Workload Identity Federation, SEP 1933's own draft text names a trusted workload identity issuer, a Kubernetes control plane, a SPIFFE and SPIRE trust domain or a cloud provider's own runtime, as the party whose platform issued JWT the MCP authorization server accepts, a materially different grantor from an enterprise administrator, though this record treats the mechanism itself as unimplemented rather than live, because SEP 1933 remains an open, unmerged draft as of the verification date. For subagent delegation, undocumented: the roadmap names the scenario, delegating narrower authority to subagents, without naming which agent or principal would technically constitute the downstream grant, and this record does not invent one.

Mandate or basis. Undocumented across all three paths, and for a consistent reason this record states once rather than three times. Enterprise identity policy can prove an administrator configured access. A workload identity assertion, once Workload Identity Federation ships, would prove a trusted issuer vouched for a workload. Neither proves that the administrator or the workload's operator held the organizational, contractual or governance mandate to delegate every consequential capability later exercised through the resulting connection. Nothing reviewed for this record, across Okta's, Auth0's, Anthropic's or the Model Context Protocol's own material, establishes a specific governance requirement, a resource ownership rule, a delegated administration boundary or an approval workflow an administrator or a workload identity issuer must satisfy before that technical grant occurs. Possession of Okta administrator privilege, or operation of a trusted workload identity issuer, is not treated here as evidence of organizational entitlement to make a given delegation decision, and this record does not infer the second from the first.

Delegated scope. Documented at the level the Enterprise Managed Authorization protocol actually operates, now confirmed against the stable specification's own worked example: a specific requesting application, carried as the client_id claim, a specific resource application, carried as the resource and aud claims, and the represented user's own existing groups and roles, expressed as a scope claim the identity provider derives from enterprise policy. Nothing reviewed for this record shows a token carrying a scope narrower than that relationship, such as a specific MCP tool, a specific channel or a specific record, and this record does not describe the scope as finer grained than what is actually documented. For subagent delegation, the roadmap's own word is narrower, not narrowed by a specified mechanism, and this record preserves that as intended architecture rather than demonstrated attenuation.

Explicit limits. Documented for Enterprise Managed Authorization: the administrator configured policy at the identity provider, the requesting and resource application identities themselves, the audience binding carried in the token exchange, a short credential lifetime bounded by the exp and iat claims, and an assertion identifier, jti, that ties a given ID JAG to a single issuance. Not documented, in anything reviewed here: a numeric or time bound ceiling on how the resulting access may be used once issued, a sender constraint binding the resulting access token to a specific client key, which is the gap DPoP, still an open draft under SEP 1932, is intended to close, and any resource or audience restriction specific to a subagent hop, which no proposal reviewed here defines.

Inherited permissions and assumptions. The Enterprise Managed Authorization architecture reviewed here is consistent with an intersection: the connection exists only because the organization permits it, and what it reaches is scoped to the user's own existing access inside the resource application. This record states that as the architecture's apparent shape rather than as a confirmed rule, because no source reviewed states the composition explicitly enough to call it verified. For subagent delegation, the roadmap's own language points toward the same intersection principle, narrower authority, but this record does not treat a roadmap sentence as normative enforcement, and specifically flags that nothing reviewed here rules out a downstream agent's authority widening rather than narrowing, because no scope subset rule, no token exchange step that provably shrinks scope on each hop and no depth limit currently exists in any Model Context Protocol proposal this record could verify.

Revocation or modification. Partially documented for Enterprise Managed Authorization, and now checked directly against the stable specification rather than only against Auth0's general material: the specification's own text describes issuance and validation but says nothing about revocation, so this record's treatment of revocation rests on Auth0's general OAuth material, which documents disabling a user or changing an agent's permissions through the identity provider as blocking renewal of access across connected applications, not as invalidating an already issued token before its own expiry. This record continues to keep those two claims separate rather than assuming the stronger one. For subagent delegation, cascade revocation, whether revoking a parent agent's grant also revokes what it delegated onward, is undocumented in anything reviewed here, a gap this record notes stands in direct contrast to Grantex's own specification, covered elsewhere in Moona's corpus, which does define atomic cascading revocation of descendant grants.

Challenge authority. Undocumented across all three paths. Nothing reviewed for this record names a channel by which a resource owner, an application owner, an auditor or a security function other than the configuring administrator or the workload identity issuer can challenge or override a granted relationship already in place, distinct from an administrator's own ordinary ability to edit policy. The roadmap does not describe one for subagent delegation either.

Recovery. Undocumented. Revoking access, on the evidence available here, stops or limits future access. Nothing reviewed for this record describes a mechanism for reversing a message sent, a file changed or a record altered through a connection that was valid at the time it was used, for Cross App Access, Enterprise Managed Authorization, Workload Identity Federation or a future subagent delegation.

Provenance evidence quality. Layered, not uniform, and now spanning more maturity stages than before. The protocol's own mechanics, the requesting and resource application roles, and the token exchange sequence are directly verified against Auth0's own public sample code. The Model Context Protocol's own account of Enterprise Managed Authorization's stable status, its connection level scope and its worked ID JAG example are directly verified against the Model Context Protocol's own stable specification repository on github.com. The 22 August roadmap's own framing, its five priority areas and its exact language about cloud workload agents, absent users and subagent delegation are directly verified against the Model Context Protocol's own blog. SEP 1932 and SEP 1933's own draft status, labels and review pipeline position are directly verified against the pull requests themselves on github.com. The broader ecosystem announcement, the current Okta catalog state and Claude's own beta status remain documented through consistent, independently corroborated search evidence rather than a direct reading of Okta's, Auth0's or Anthropic's own pages, each blocked in this session, and are marked accordingly. What is well evidenced, across every path in this ledger, is the technical act of a grant occurring, an administrator's policy, a workload issuer's assertion, a roadmap's stated intention. What remains undocumented, across every path, is the mandate behind the grantor, a challenge mechanism and a recovery path for what already executed, and this record does not let well evidenced technical mechanics stand in for those absent layers, however many new mechanisms the protocol adds.

Where this sits against Moona's own coverage

GitLab's composite identity answers an adjacent question inside one product: what happens to authority the instant an agent acts for a human, once, resolved there as the intersection of a human role and a service account role. Cross App Access answers a different question, upstream of any single action: whether an external requesting application may stand in for a human at all, resolved not by intersecting two roles but by an administrator's standing policy at the identity provider. Nuggets' Authority Control Plane and Uber's own actor chain architecture, read in this record's own coverage of both, already established that proof of who technically granted an agent its authority is not proof that the grantor held the organizational mandate the delegation implied. Cross App Access is a third, independently arrived at architecture landing on the same gap from an enterprise identity and access management starting point rather than a payments platform or an agent runtime, which is itself a form of corroboration: three different vendors, solving three different problems, keep leaving the same layer undocumented. This record's distinct contribution is narrower than any of those three. It is that the party whose application access an agent exercises, the employee, is architecturally and explicitly not the same party who decided the agent could exercise it, the organization, and that Cross App Access is the clearest public example yet of an identity platform building that separation into the protocol itself rather than leaving it to be inferred.

The Model Context Protocol's own 22 August 2026 roadmap adds a fourth line of corroboration, and it is a distinct kind. Nuggets, Uber and GitLab are three vendors independently landing on the same undocumented mandate layer from three different starting points. The roadmap is the protocol itself, the layer underneath all three, naming the same underlying shift in its own words: authorization built for a person approving access in a browser does not cover a cloud workload with its own identity, a user who is not present or an agent delegating to a subagent. This record treats that as the clearest available signal that the gap it keeps finding is structural to how agentic systems are being built, not a pattern this record is imposing on unrelated evidence. It does not treat the roadmap as having closed the gap. Enterprise Managed Authorization, stable since 18 June 2026, already answers the connection level question this record analyses throughout: whether a requesting application may reach a resource server on a user's behalf. DPoP and Workload Identity Federation, both still open drafts as of 24 August 2026, extend that same architecture toward sender constrained tokens and non human workload identities. Subagent delegation, named in the same roadmap sentence, remains a stated priority without a stated mechanism. Moona Intelligence's own coverage of Grantex's bounded delegation protocol, which does specify scope subset enforcement, an expiry ceiling and cascading revocation for exactly this scenario, is the sharpest existing comparison for what a completed answer to that piece of the roadmap would need to specify, and this record does not credit the Model Context Protocol with having specified it yet.