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.

Six 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. On 24 August 2026, 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 this record's first verification pass, dated the same day, treated that expectation as unconfirmed rather than resolving it, because the domains that would have confirmed it directly were blocked. Okta's own newsroom material states that 24 August 2026 was also the date it made Agent SSO, a named product folding Cross App Access into core Okta SSO, generally available, which this record did not know on its first verification pass and confirms only now. And on 1 September 2026, this record's current verification date, Moona Intelligence re-checked the claim, found it corroborated across many independently phrased search passes rather than a direct fetch of okta.com, and updated the record accordingly rather than silently rewriting the earlier pass. Six dates, six different kinds of event: an original protocol announcement, an ecosystem partner announcement, a piece of implementation documentation, a protocol governance roadmap, a scheduled catalog milestone that turned out to be a product's general availability date, and a later verification pass that confirmed it. 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.

Agent SSO: what 24 August 2026 actually was, confirmed 1 September 2026

This record's own first verification pass, dated 24 August 2026, read Auth0's hedged expected wording and stopped there, because the pages that would have confirmed or denied the milestone directly were blocked. That was the correct call on the evidence available that day, and this record does not pretend otherwise. What this 1 September 2026 verification pass adds is Okta's own account, reviewed after okta.com remained blocked and reconstructed instead from many independently phrased search passes returning consistent, specific detail: Okta brought first class identity to AI agents with Agent SSO, a named product, generally available on 24 August 2026. Agent SSO folds the open Cross App Access standard into core Okta SSO, so the capability this record has tracked as a protocol and an ecosystem since June 2025 is now also a shipped, generally available product feature, included in core SSO plans at no additional cost to Okta customers. Applying specifically to AI agents that support Cross App Access, Agent SSO registers a supported agent as a first class identity inside Okta's own Universal Directory, the same directory that already holds human employee identities, and issues short lived, identity governed tokens in place of the static API keys and stored credentials an agent would otherwise carry. Administrators assign, monitor and update agent policy through the same centralized console and workflows they already use for employees, rather than a separate agent specific tool. This record treats each of those claims individually rather than as one undifferentiated announcement: general availability is one claim, core SSO inclusion at no additional cost is a second, Universal Directory registration is a third, short lived token issuance is a fourth, and centralized administrator policy is a fifth, and independently phrased search passes returned consistent detail on all five, which is why this record grades each documented rather than either verified, absent a direct fetch, or claimed, which would understate consistency this strong across independent sources.

What Agent SSO's own general availability does not establish is broader than what it does. Okta's own material, reviewed for this update, states the product reaches an identity platform used by more than 20,000 customers. That sentence describes Okta's existing installed base, the customers who could in principle turn Agent SSO on, not a count of organizations that have actually deployed it, and this record does not read the two as the same number; nothing reviewed here documents how many of those 20,000 customers have enabled Agent SSO, connected a specific agent through it, or use Cross App Access at all. Nor does Agent SSO's own general availability mean that every agent, or even every agent named in Okta's June 2026 ecosystem announcement, is itself generally available through it: coverage is bounded by Cross App Access compatibility on both ends of a connection, the requesting agent and the resource application it reaches, and this record's own review of secondary technical analysis, independently corroborated, states that limitation plainly rather than treating Agent SSO's own launch as a blanket statement that every named partner integration has shipped. Okta's own material also distinguishes Agent SSO from a second, separate product this record's own prior coverage has already touched in its analysis of Okta's kill switch argument: Okta for AI Agents. Independently phrased search passes describe Agent SSO as answering how a Cross App Access compatible agent connects to enterprise applications and MCP servers, while Okta for AI Agents answers a broader question, where every agent is, what it can reach, and what it is allowed to do, covering discovery of unregistered and shadow agents, assignment of a named human owner, access certification and agent deactivation regardless of whether an agent uses Cross App Access at all. Okta for AI Agents itself reached general availability earlier, on 30 April 2026 on the evidence this record could locate, a materially different timeline from Agent SSO's own 24 August 2026 date, and this record keeps the two products, and their two different general availability dates, separate rather than treating one announcement as covering both.

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 Agent SSO itself, the product this record's 1 September update confirms reached general availability on 24 August 2026, folding Cross App Access into core Okta SSO. And none of those is the same claim as Claude's own integration, which this record's 24 August verification pass could establish only as a beta limited to approved joint Okta and Anthropic customers. This 1 September update finds consistent secondary corroboration, though not a direct fetch of claude.com, that Claude's own Enterprise Managed Authorization integration also reached general availability around the same date, with connector coverage expanded to Datadog, Notion and Slack alongside the seven providers already supported in beta; this record grades that claim documented rather than verified and does not treat Okta naming Anthropic as a partner, on its own, as proof of Claude's own general availability, which is why it sought and reports Anthropic's own reported claim separately. 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, a caution that still applies to every other named partner this record has not independently re-verified.

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

The task this record originally set for itself, on 24 August 2026, was to check the current Okta Integration Network catalog directly rather than rely on Auth0's 6 August prediction of what would appear there that day. That direct check was blocked then and remains blocked now: oin.okta.com, and the individual Claude and Slack integration pages, could not be fetched by this session on any attempt on either verification date. What was available on 24 August was search indexed material of uncertain freshness, describing a Slack listing that carried Cross App Access and Brokered Consent capability tags and a Claude listing that carried an AI agent management capability alongside a beta Cross App Access program, which that pass recorded as a lead rather than proof. This 1 September update does not treat that gap as closed: it still could not fetch the catalog directly. What it adds is a different, independently corroborated fact that supersedes the need to read the catalog to answer the narrower question this record was actually asking. The scheduled milestone Auth0 described as expected was Agent SSO's own general availability, and Okta's own newsroom material, corroborated across many independently phrased search passes, confirms that milestone happened on 24 August 2026. This record still cannot state, from a direct fetch, exactly what the Claude or Slack catalog listing itself now reads, and an editor with unblocked access should confirm the live pages rather than treat this paragraph as having done that.

Claude's own status has moved since the 24 August pass, and this record states precisely how. Okta's own support material, on 24 August, carried an article titled Claude Enterprise Managed Auth With Okta Cross App Access XAA Beta Participation Guide, a title that named a beta rather than a generally available capability, and this record held that line on 24 August rather than promoting a beta to general availability on the strength of an ecosystem announcement made two months earlier. This 1 September update independently sought Anthropic's own current claim rather than assuming Okta's Agent SSO milestone carried Claude's integration forward with it, and finds consistent secondary corroboration, including a claimed statement from Anthropic's own developer channel, that Claude's Enterprise Managed Authorization integration for MCP connectors also reached general availability, with connector coverage expanding to Datadog, Notion and Slack alongside the seven providers already supported in beta. This record could not fetch claude.com or support.claude.com directly to confirm that from Anthropic's own page, the same blocked domains as the 24 August pass, so it grades Claude's own general availability documented rather than verified, and states the earlier beta participation guide title as the prior, dated state rather than erasing it.

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. Agent SSO reaching general availability on 24 August 2026 does not close that gap. It gives the administrator's decision a shipped, generally available product surface, a console and a workflow, rather than a new source of organizational mandate; nothing in Okta's own Agent SSO material, reviewed for this 1 September update, describes a governance or resource ownership requirement that did not already exist in the underlying XAA protocol this record analysed on 24 August.

Okta's own product split, reviewed for this 1 September update, independently corroborates the distinction this record exists to hold onto rather than requiring this record to relax it. Okta's own material describes Agent SSO as answering how a Cross App Access compatible agent connects to enterprise applications and MCP servers, a connection level question, and describes a separate product, Okta for AI Agents, as answering where every agent is, what it can reach and what it is allowed to do, a broader governance question covering discovery, ownership, certification and deactivation regardless of whether an agent uses Cross App Access. That is Okta itself, independently of this record's own framework, drawing a line between a connection being authorized and an agent's broader conduct being governed, the same line this record has held throughout between whether a requesting application may reach a resource application at all and whether any specific action it later takes was separately authorized. Agent SSO reaching general availability strengthens the evidence that the connection level decision is real and shipped. It does not extend that evidence to action level authorization, a question this record has never found Agent SSO, Cross App Access or Enterprise Managed Authorization answering, and Okta's own decision to build a second, separate product for broader agent governance is read here as corroboration of that boundary rather than as a reason to soften it.

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.

A fourth path: HubSpot's own connector for Claude

Everything above reads Cross App Access, Enterprise Managed Authorization and the Model Context Protocol's own roadmap from an identity platform's side of the architecture: the party issuing the assertion that lets a requesting application stand in for an employee. HubSpot's own connector for Claude, verified for this 4 September 2026 update against HubSpot's Knowledge Base documentation, HubSpot's separate developer documentation for its remote MCP server and HubSpot's own general application-access administration documentation, arrives at the same distinction between constituting a delegation and being able to withdraw it from the opposite side: a single resource provider's own packaged connector, rather than an identity provider brokering access to many resource applications. This record treats HubSpot's evidence as a fourth, independently documented instance of its own recurring argument, not as a restatement of Cross App Access's own mechanics, because nothing in HubSpot's own material reviewed here attributes its connector's behavior to Cross App Access, Enterprise Managed Authorization or the Model Context Protocol's own specification, and this record does not import that attribution on its own.

Connector constitution: who grants, who selects, and what changed on 28 August 2025

HubSpot's own documentation, read through this session's own convergent search corroboration, states that a Super Admin or a user carrying HubSpot's own App Marketplace permission performs the connector's first connection and, in that same step, selects which connector permissions are permitted at all; no other role reviewed here can perform that initial constitution. That administrator, or a later Super Admin, then separately decides which of the organization's users may reach the already-configured connector, through HubSpot's own Connected Apps administration screen, described across independently phrased search passes as Settings, then Integrations, then Connected Apps, then the HubSpot connector's own entry, then Give users access. HubSpot's own 28 August 2025 changelog entry, titled Additional Object Access, Read-Only, and Admin Controls in this session's own search corroboration, is the dated point at which this record's search evidence locates a Super Admin's ability to govern which users may connect at all, alongside read-only access to further CRM object types beyond the connector's original contacts, companies, deals and tickets; this record states that changelog title and date as the documented milestone rather than inferring what an installation predating it could or could not do, a gap this record leaves unresolved rather than assumed. Read together, these are two separately governed decisions this record does not collapse into one grant: a maximum connector envelope the constituting administrator selects once, and a narrower, per-user population decision, itself revisable, over who may draw on that envelope at all.

User connection: two independent ceilings, not one

A user granted access to the already-configured connector still separately connects their own HubSpot identity inside Claude's own connector settings, an OAuth-shaped step this record's search evidence describes without independently verifying its exact grant type. What that connection then reaches is documented, consistently across this session's search passes, as the intersection of two independently governed ceilings rather than either one alone: the connector's own maximum permitted scope, fixed by the constituting administrator, and that user's own current, ordinary HubSpot permissions, the same role and object-level permissions that already govern what they can see and edit inside HubSpot's own interface. HubSpot's own material, corroborated here, states the connector automatically respects those existing user permissions, with a sales representative's own connector-mediated reach to pipeline data named as the illustrative case; this record does not extend that statement to a claim that every customizable HubSpot permission type, including permission sets this record's search could not individually enumerate, is honored identically, and states that as an open boundary rather than an inferred one. This record preserves, as three separately governed facts rather than one: the connector's own maximum scope, that user's own standing HubSpot permission, and, addressed separately below, whether either is checked again at the moment of a given call rather than only once at connection time.

Write capability, the ten-record bulk ceiling, and what the connector does not do

HubSpot's own documentation, corroborated across this session's search passes, states the connector's current write surface as create and update actions against CRM objects and activities, with no delete capability exposed through the connector at all; a user who wants a record removed still has to do so inside HubSpot itself or through HubSpot's own API, not through this connector. A single bulk create or update request is documented as capped at ten records at once. This record states that ceiling precisely as the technical effect HubSpot's own material describes it as, a bound on one request's own size rather than a documented authorization policy, and separately notes, at the same manual-review evidence level as the rest of this section, community-reported observation that a user instructing Claude to issue the bulk operation repeatedly reaches the same aggregate effect the per-request ceiling was set to slow; this record treats that as a property of the ceiling's own mechanism, not as evidence the ceiling is a fabricated or a stronger control than HubSpot's own material states it to be.

Custom validation rules: a different policy surface, not a bypassed permission

HubSpot's own documentation states plainly, corroborated across this session's search passes, that custom validation rules configured inside HubSpot's own interface, including pipeline-stage validation and association-label validation, are not applied when a record is created or updated through the Claude connector; a change HubSpot's own normal user interface would block can still reach the record through the connector, provided the connecting user already holds the underlying HubSpot permission to edit that record and object at all. This record states precisely what that is and is not evidence of. It is not evidence of an authentication bypass: nothing reviewed here shows the connector reaching a record without the connecting user's own valid, existing HubSpot session and permission. It is not evidence of a permission bypass either, on the same reasoning: the user's own standing HubSpot permission to edit the object is exactly what the section above already establishes still governs connector-mediated access. What it is evidence of is a narrower and still consequential fact this record treats as its own durable finding from HubSpot's own architecture: a custom validation rule is a UI- and workflow-layer policy HubSpot's own interface enforces at the point of a manual edit, not a property of the underlying CRM permission a user holds or of the API-level authorization the connector itself checks, and HubSpot's own documented choice not to run that UI-layer policy against connector writes means a technically authorized write can still land in a shape the organization's own validation rules exist specifically to prevent. This record does not describe that as a vulnerability without independent evidence establishing one, consistent with this record's own treatment of Agent SSO and Okta for AI Agents above as two deliberately separate products rather than one flawed one: HubSpot has built two different policy surfaces, CRM permission and UI validation, and documented that only the first currently governs the connector, a product limitation and an authority-context distinction this record states as such rather than inflating into a security finding it cannot independently support.

Write approval: a Claude-side setting, not a documented HubSpot hold

HubSpot's own documentation recommends configuring the connector's write tools to Needs Approval, described consistently across this session's search corroboration as a setting inside Claude's own connector tool configuration, alongside HubSpot's own stated alternative, Always Allow, under which a write can execute without a further approval prompt. This record reads that setting's own location precisely: every source this session's search could reach places Needs Approval and Always Allow inside Claude's own client-side connector settings, not inside anything HubSpot's own material describes as a server-side authorization hold at HubSpot's resource boundary, and this record does not describe HubSpot as mediating or enforcing that setting on its own initiative. Under Needs Approval, this session's search corroboration describes Claude drafting the proposed change and a user typing a confirmation before the connector performs the write; under Always Allow, no separate current-action confirmation is documented at all, and a write proceeds on the standing connector grant alone. This record states what that confirmation is documented as showing, a proposed change, and states plainly what it could not independently verify HubSpot documents about what the confirmation is technically bound to: whether the accepted confirmation is checked against an immutable record of the exact arguments proposed, a specific tool-call identifier, a single-use receipt, an expiry, or a replay protection. Nothing reviewed here establishes any of those properties, and this record keeps that binding unknown rather than assuming either that it is cryptographically strong or that it is absent, the same distinction this record already applies elsewhere in this corpus to Rydoo's, UiPath Maestro's and Docusign's own confirmation mechanisms.

Audit attribution: two named principals, not a decision record

HubSpot's own documentation, corroborated across this session's search passes, states that a create or update action performed through the connector is recorded in HubSpot's own audit log attributed to both the connecting user and the Claude connector itself; this session's search could not independently establish the audit entry's own exact field schema beyond that dual naming. This record reads that attribution precisely as identifying two principals whose action the log associates with a change, not as a decision record proving why the change was authorized, who reviewed a Needs Approval prompt before confirming it, or what business mandate the underlying write served; a name appearing in an audit log is evidence an action occurred and who is associated with it, not evidence that the represented business justification for it existed, a distinction this record already states of Rydoo's own audit claim elsewhere in this corpus and applies identically here. This record does not describe HubSpot's own audit attribution as immutable, cryptographically signed, non-repudiable or a complete decision receipt, because nothing reviewed here establishes any of those properties for it.

Revocation, precisely bounded to the connector-administration surface that grants it

This is the section this record treats as HubSpot's own most consequential contribution to its Authority Provenance argument, and it states each documented limitation narrowly rather than as one undifferentiated claim that a HubSpot administrator can never withdraw a connector's access. HubSpot's own documentation, corroborated across many independently phrased search passes returning consistent detail, states six specific things about the same connector-administration surface described above, the Super Admin's own Connected Apps, Give users access flow used to constitute and populate the connector's access in the first place. Once a Super Admin has enabled connector access for every user in the account, that account-wide enablement itself cannot afterward be turned off globally through that same flow. A user who has already connected remains bounded by the connector permissions the constituting administrator originally selected, and this record's own search evidence found no mechanism on this same surface for a Super Admin to afterward revoke, from an already-connected user specifically, the connector permissions that user's own connection already carries. Uninstalling the connector from the HubSpot account's own administration surface does not, on this evidence, remove a downstream user's own already-established connection; each connected user is documented as needing to uninstall their own connection individually for it to end. And where an administrator wants to reduce, rather than expand, the connector permissions originally selected, HubSpot's own documentation describes no in-place narrowing at all: the administrator must uninstall and reinstall the connector, and every user whose connection is meant to carry the narrower permission set must independently disconnect and reconnect as well. This record states the precise, bounded version of what that establishes: the original connector grantor cannot centrally reverse a downstream connector grant through the same connector-administration surface that issued it, not that a HubSpot administrator holds no path back to restricting a user's access at all.

That second, broader question is exactly what this record's own required investigation into alternative revocation paths turned up, and it does not collapse cleanly into either the account-wide claim above or its opposite. HubSpot's own separate, general application-access administration documentation, covering connected apps broadly rather than the HubSpot connector for Claude by name, describes a different surface entirely: from Integrations, then Connected Apps, then the account's own Approved apps listing, a Super Admin can revoke an app's approval outright, an action this record's search evidence describes as uninstalling that app for every user who had previously installed it, or, on the same screen, open Manage access for one specific app and uninstall it for one named user individually, each subject to a documented propagation delay of up to thirty minutes rather than taking effect instantly. This record does not assume that general Approved apps revocation path behaves identically, narrows the same permissions, or is even the same underlying mechanism as the HubSpot connector for Claude's own dedicated Give users access surface described above; HubSpot's own material never states the two are the same control, and this record leaves that relationship unconfirmed rather than assumed in either direction, while stating plainly that a path exists, on a different administration screen than the one this record's six-point finding above concerns, for a Super Admin to force an uninstall for one user or for everyone. This record separately could not establish, from anything reviewed here, whether deactivating a connecting user's own HubSpot account, on its own, immediately terminates that user's connector-mediated reach, though the user-permission intersection this record already documents above makes that plausible without itself confirming it; nor could this record establish whether an underlying HubSpot OAuth token revocation, independent of either administration screen described here, would end a connector session already in progress. This record states all three of those alternative paths, the general Approved apps revocation screen, account deactivation and OAuth token revocation, as distinct from and not yet independently confirmed to have the same effect as the connector's own dedicated, and more limited, administration surface, rather than treating the narrower surface's own documented limits as proof that a HubSpot administrator has no way back at all.

Authority freshness: the user's own permissions, kept distinct from the connector's own scope

This record keeps two different freshness questions apart, because HubSpot's own material answers them differently. Whether a connecting user's own current, ordinary HubSpot permissions bound each connector call is documented, corroborated through this session's own search, as continuously true rather than fixed at the moment of connection: the connector is described as respecting a user's existing permissions in the same way HubSpot's own interface already does, and this record's own search evidence, including a live practitioner test in September 2026, describes a user's connector-mediated reach as scoped to what their own current HubSpot seat can already see. Whether the connector's own maximum permitted scope, the set an administrator selected at constitution, updates for an already-connected user the moment that selection changes is a different and separately documented question, and HubSpot's own material answers it the opposite way: this record's search evidence describes an already-connected user needing to disconnect and reconnect their own connection before a newly added connector-level object type or permission becomes reachable to them, the same reconnection requirement this record's revocation section above documents for narrowing rather than widening. This record states that asymmetry precisely: underlying user-permission freshness is documented as continuous, while connector-scope freshness is documented as requiring an explicit reconnection step, and does not conflate the two into one undifferentiated freshness claim for the connector as a whole.

A remote, generic HubSpot MCP server is a separate architecture

HubSpot's own developer documentation, corroborated across this session's search passes after developers.hubspot.com itself was blocked to direct fetch, describes a second, distinct mechanism this record does not merge into the packaged Claude connector documented above: a HubSpot-hosted remote MCP server, reached at mcp.hubspot.com, that graduated from beta to general availability on 13 April 2026, a date this record keeps separate from the connector documentation's own 10 August 2026 last-updated date and from this record's own 4 September 2026 verification pass. This session's search evidence describes that server authenticating each connecting client through OAuth 2.1 with PKCE, with a connecting user's own existing HubSpot permissions again documented as the governing bound on what that specific connection can reach, consistent with this record's own general finding elsewhere that resource-side permission enforcement, not the calling client, decides an agent's technical reach into HubSpot's own data. This record does not, on that similarity, assume the remote MCP server carries the packaged Claude connector's own Needs Approval and Always Allow setting, its own documented administrator-access and reconnection behavior, or its own documented dual user-and-connector audit attribution: nothing reviewed here states any of those three properties for the remote MCP server specifically, and this record treats HubSpot resource permission as the one property demonstrably shared across both surfaces while treating client execution policy, approval behavior, administrative control and audit attribution as each potentially different depending on which client or integration reaches the server, a distinction this record's own search evidence into HubSpot Sensitive Data settings separately corroborates: a portal with Sensitive Data protection enabled is documented as blocking MCP access to activity objects, calls, emails, meetings, notes and tasks among them, a resource-side control this record found no equivalent statement of for the packaged Claude connector's own documented object coverage.

Recovery: unchanged from this record's own general finding

HubSpot's own documented absence of a delete capability through the Claude connector means a connector-created or connector-updated record persists inside HubSpot's own CRM after the fact; nothing reviewed here describes the connector itself reversing a create or an update once made, only a separate, manual deletion or edit inside HubSpot's own interface or API, performed by a human rather than by the connector. Disconnecting a user's own connection, uninstalling the connector, or revoking it through either administration surface this record documents above stops or narrows future access; none of them, on the evidence reviewed here, reverses a write already committed. This record states that as the same recovery gap it already documents for Cross App Access, Enterprise Managed Authorization, Workload Identity Federation and a future subagent delegation path above, arrived at independently from a fourth, product-specific architecture rather than restated from any of them.

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. This 4 September update adds a fourth, independently documented path, HubSpot's own connector for Claude, where a resource provider's own packaged connector, rather than an enterprise identity provider, is both the party constituting the grant and the party whose own documented administration surface later cannot centrally reverse it.

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. Agent SSO's own general availability, confirmed for this 1 September update, does not add a fourth path or change this one; it packages the same administrator configured policy inside a named, generally available product, and this record continues to name the administrator, not Agent SSO itself, as the grantor. 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 1 September re-check of the same repository. 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. For HubSpot's own connector for Claude, documented as a Super Admin or a user carrying HubSpot's own App Marketplace permission, who performs the connector's first connection and selects its maximum permitted permissions; a materially different grantor from Cross App Access's own identity-provider administrator, since the grant is constituted inside the resource provider's own product rather than at a separate identity broker, and this record does not treat the two as the same actor merely because both are titled administrator.

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. Agent SSO's own general availability, reviewed for this 1 September update, is a product maturity fact, not a governance fact, and nothing in Okta's own Agent SSO material supplies the governance requirement this paragraph has found absent since the 24 August verification pass. HubSpot's own material adds no governance requirement either: App Marketplace permission establishes who is technically able to constitute the connector's grant, not that the constituting administrator held the organizational mandate to authorize whichever CRM mutations Claude later proposes, the same gap this record already finds absent for every other path in this ledger.

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. For HubSpot's own connector for Claude, documented as the intersection of two independently governed ceilings rather than one: the connector's own maximum permitted scope, fixed by the constituting administrator at connection, and the connecting user's own current, ordinary HubSpot permissions, with create, update and, separately capped, bulk create and update against CRM objects and activities as the current documented action surface and no delete capability exposed through the connector at all.

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. For HubSpot's own connector for Claude, documented: the administrator-selected maximum permission set, the connecting user's own standing HubSpot permission, and a ten-record ceiling on a single bulk create or update request. Not documented as applying to the connector at all: HubSpot's own custom validation rules, including pipeline-stage and association-label validation, which this record's own reading of HubSpot's material states plainly are not run against connector writes, a UI- and workflow-layer policy surface this record keeps distinct from the CRM permission that does still govern the connector, rather than describing its absence as a permission or authentication bypass.

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. For HubSpot's own connector for Claude, documented more precisely than any other path in this ledger: the connector automatically respects the connecting user's own existing HubSpot permissions, checked, on this record's own search evidence, continuously rather than only at connection time, while the connector's own maximum permitted scope is fixed at whatever the constituting administrator last selected and does not itself widen or narrow for an already-connected user without an explicit reconnection.

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. For HubSpot's own connector for Claude, the most precisely bounded revocation finding in this ledger: through the connector's own dedicated administration surface, once enabled for every user an account-wide grant cannot afterward be turned off globally, an already-connected user's own permissions cannot be revoked from them individually, uninstalling the connector at the account level does not remove an already-established user connection, each connected user must disconnect individually, and narrowing a previously selected permission set requires the administrator and every affected user to uninstall and reconnect. This record states that precisely as a limitation of that one administration surface, not as proof no HubSpot administrator can ever restrict a user's access: a separate, general application-access administration screen is documented as able to force an uninstall for one named user or for every user, subject to a documented propagation delay, and this record could not confirm whether that screen behaves identically to, or independently of, the connector's own dedicated surface, nor whether deactivating a user's HubSpot account or revoking an underlying OAuth token independently terminates an in-progress connector session, and states each as a distinct, unconfirmed alternative path rather than folding it into either claim.

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. HubSpot's own material names none for its connector either: nothing reviewed here describes a channel by which a resource owner, an auditor or a security function other than the constituting Super Admin, acting through one of the administration surfaces described above, can challenge or override a connector grant already in place.

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. HubSpot's own connector for Claude documents the same gap independently: no delete capability exists through the connector at all, so a connector-created or connector-updated CRM record persists after the fact, and nothing reviewed here describes any of this record's documented HubSpot revocation paths, the connector's own dedicated surface, the general application-access screen, account deactivation or OAuth token revocation, reversing a write already committed rather than stopping or narrowing future ones.

Provenance evidence quality. Layered, not uniform, and now spanning two verification passes as well as 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, re-checked and unchanged as of 1 September 2026. 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, re-checked and unchanged as of 1 September 2026. The broader ecosystem announcement, the current Okta catalog state, Agent SSO's own 24 August 2026 general availability, and Claude's own general availability claim all remain documented through consistent, independently corroborated search evidence rather than a direct reading of Okta's, Auth0's or Anthropic's own pages, every one of which remained blocked on the 1 September re-check exactly as it was on 24 August, 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, and now a connection product's own general availability. 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, or a product reaching general availability, stand in for those absent layers, however many new mechanisms the protocol adds. HubSpot's own connector for Claude adds a fourth layering: its administrator-constitution step, its dual permission ceiling, its ten-record bulk limit, its Needs Approval and Always Allow setting, its dual audit attribution and its own connector-administration revocation limits are each documented through convergent, independently phrased search evidence rather than a direct fetch of knowledge.hubspot.com, developers.hubspot.com or tldv.io, every one of which this session's own attempts found blocked, and are marked manual review throughout rather than verified, consistent with how this record already grades every other blocked primary source in this ledger; an editor with unblocked access should confirm HubSpot's own pages directly before treating any exact HubSpot claim above as more than that.

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.

HubSpot's own connector for Claude, verified for this 4 September 2026 update, is this record's fifth line of corroboration and its first from a resource provider's own packaged product rather than an identity broker or a protocol maintainer. It reaches the same undocumented mandate layer from a fourth independent starting point: a Super Admin's technical ability to constitute and select a connector's maximum permissions is real and documented in detail, and a separate, higher bar establishing that administrator held the organizational mandate to authorize whichever CRM mutations Claude later proposes is documented nowhere this record could reach, the identical gap this record already names in Nuggets', Uber's and GitLab's own architectures and in Cross App Access itself. What HubSpot's own material adds beyond restating that gap is the sharpest documented instance in this record of Cross App Access's own still unresolved revocation question, whether disabling a user or adjusting an agent's permissions invalidates an already issued credential or only blocks its renewal: HubSpot's own connector-administration surface does not, on this record's own reading, even reach the renewal-blocking case for an already-connected user's specific permissions, and this record's own required search for an alternative path found one only on a separate, general application-access administration screen this record could not confirm behaves identically to the connector's own dedicated one. Read against Moona's own coverage of Claude's connector tool settings elsewhere in this corpus, HubSpot's own Needs Approval and Always Allow setting is independent confirmation, from a single named resource provider rather than a protocol specification, of this record's own recurring distinction between a connection being authorized once and a specific action being separately authorized at the moment it executes, which this record connects to, rather than duplicates into, this corpus's own record of that argument applied across many resource providers.