The question worth asking about AAuth is not only whether the protocol is good. Kerberos won because of everything around the protocol: SSPI and GSS-API hid the mechanism from application developers, the LSA owned keys and ticket lifecycle, machine accounts existed as a side effect of domain join, Active Directory shipped the KDC by default, and SPNEGO made rollout incremental. Mapping that stack onto agents names the first control point in this series: the provider seam through which a harness or gateway acquires and presents credentials without exposing the mechanism to agent logic. MCP clients, SPIFFE, cloud identity systems, vendor brokers, and HTTP message-signature negotiation supply pieces, but no general seam composes them. That seam still cannot decide whose agent is running, which work is approved, or whether a resource permits one action. Those are separate records and decisions.
Agent runtimes naturally create the first trustworthy evidence about an instance, which gives them the default position in agent identity. Runtime proof and enterprise binding are still separate jobs. In heterogeneous enterprises, a binding layer can map evidence from many runtimes into durable Agent and Agent Deployment records and supply that governed context to credential issuers and resources. It is a real control plane only if the enterprise state survives changing runtimes. In the open world, model-provider harnesses are better positioned to integrate the stack because they hold the user relationship and execution loop. Distribution determines the default. Standard seams determine whether it can be challenged. Even a won binding layer answers whose agent is running, not whether its current work remains approved. That requires the third control point, an approved-task record with its own lifecycle.
Agent task authority is scattered across four de facto records: harness permission prompts, OAuth grants, IAM roles, and change tickets. Each performs a real job, but none is a general, portable system of record for approved work. An action click is not task approval, a grant is not a task lifecycle, and an identity role is not a reason for one undertaking. The missing object is an approved-task record with its own owner, bounds, lifecycle, and evidence relationships. Existing standards provide much of the transport for structured requests, user interaction, decisions, and credential projection. They do not yet supply shared task semantics, lifecycle propagation, trust, or enforcement behavior. Four plays are competing to mint the record, and the contest turns on distribution, durable state, and resource acceptance.
The control-points series argues that distribution determines defaults and standard seams determine whether those defaults remain contestable. MCP adds the clock. It launched with a specification, SDKs, a distributed host, and reference servers, and one developer could run the whole loop before the ecosystem coordinated. Mature authorization and governance followed the adoption pressure. The lesson is not that ratification is obsolete or that protocols can be adopted unilaterally. It is that a seam needs a small first coordination radius, immediate utility, low exposed implementation cost, running code, and a path from one controlled deployment to multilateral interoperability. This essay runs the series’ seam table through that test, uses AAuth as the clean-sheet stress test, and explains what would produce an enterprise ‘SAML moment’ for agents.
Cross App Access is not twenty-five generally available integrations. It is three different things at three different stages: a stable MCP authorization extension, a live Claude and Okta beta, and a partner graph whose broader product rollout is still under way. That distinction makes the strategic result clearer. The launch coalition moves protocol coordination from each buyer to the vendors assembling the loop, giving the layered identity play an adoption wedge. ID-JAG carries both the enterprise user and a required OAuth client identifier, while the resource authorization server retains the final decision. What it does not standardize is the binding from that client to a logical Agent, approved deployment, or runtime instance, nor a record of the task that justifies access. The credential-projection foothold shipped. The Agent and approved-work records remain open.
Long-running agents discover mid-task that they need a destination their egress proxy does not allow, and the block comes back as an opaque connection failure with no machine-actionable way to ask for access and no human standing by. That block is a requestable denial, and the egress proxy is a policy enforcement point. RFC 8908, the Captive Portal API, supplies the recovery state machine for a blocked client on a network: discover captivity, learn the remediation endpoint, and retry after policy changes. A headless agent can use that state machine, with the denial carried by Proxy-Status and Problem Details where an HTTP response exists and by an authenticated side-channel status API where it does not. The recovery can ride the captive portal at two altitudes, destination-level on a proposed AuthZEN Access Request profile or operation-level on AAuth and Mission-bound authority. When the client already speaks AAuth, it needs no captive-portal shim at all, because AAuth carries the refusal and re-authorization in-band at the same request boundary the proxy already enforces.
The Four Questions of Delegated Work, and the Invariants That Compose Their Answers
Delegated work forces four separate continuity questions: request provenance, identity attribution, target-applicable authority, and continuing work justification. Their answers compose through a common boundary contract: authoritative sources, bound and correlated evidence, explicit lifecycle semantics, local decisions, and declared failure behavior. Current proposals fill different parts of that contract; narrow profiles adopted one boundary at a time offer a more credible path than one universal delegation artifact.
A Vocabulary, a Rubric, and a Living Map for the Four Questions
Continuity Is Not One Thing argues that delegated work poses four independently governed continuity questions. This companion carries the parts built to be revised rather than to last: a vocabulary that separates facts from evidence, artifacts, authorities, decisions, and state; a twelve-question rubric a working group can apply to any proposal without accepting anyone’s architecture; worked evaluations of Transaction Tokens and Identity Chaining; the sixteen active OAuth working-group documents classified against the framing; and the two-layer standards map with dated versions and statuses.
The enterprise agent control stack is not one product or one call chain. It is a set of independently governed answers: which instance is running, whose Agent it is, which deployment was approved, why its current work remains authorized, what an issuer may project, how credentials are acquired and presented, whether a resource permits one concrete action, and which evidence proves the joins afterward. Three upstream positions are contested control points: the provider seam, identity binding, and the approved-task record. The resource decision remains the non-delegable final word, while runtime evidence, issuance, and audit support the chain without substituting for its records. The context and memory plane crosses this path but does not merge with it: approved work bounds exposure and memory-write rights, while canonical institutional memory keeps its own lifecycle. Six rules, one forward-and-reverse trace, and five component-replacement tests turn the series into an architecture and procurement tool.
Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the continuation handle never reaches a Resource Server.
Evals Made Intent Executable for Verification. A Mission Makes It Executable for Authorization.
Microsoft’s ASSERT compiles written behavior requirements into executable evaluations: intent made executable for verification. That answers what the agent did, not what it was allowed to do: an eval produces a verdict, not a binding authorization decision, and for irreversible actions that is the whole difference. The mission is the preventive counterpart: a shaper proposes the request as a bounded, machine-readable object, a trusted authority validates and narrows it, an approver signs off, and enforcement checks every consequential action against it. Same lineage from natural-language intent, a higher bar, and teeth an eval does not have. One approved mission then drives both the runtime boundary and the behavioral eval, while a separate shaping-quality check asks whether the boundary matched the user’s intent in the first place.
In Cross-App Access, a single signed-in user’s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant.
Closed-world authorization treated denial as the end of the interaction. Agents, runtime discovery, delegation, and mission expansion turn denial into the beginning of governance escalation. The draft AuthZEN access request and approval profile standardizes that handoff without standardizing the workflow engines behind it. Client-Initiated Backchannel Authentication (CIBA) is not the answer because the problem is not authentication freshness. It is whether authority should continue under newly discovered runtime conditions.
WorkOS auth.md is an agent-readable registration document for one-click setup, with Agent Verified, user-claimed, and anonymous paths. In the Agent Verified path, most pieces already exist across OAuth and OpenID standards: ID-JAG, OAuth metadata, dynamic client registration, standard token endpoints, and SSF/CAEP/OPC. The standards gap is a profile for runtime agent onboarding and trust establishment, not a new grant protocol.
Client instances are not new clients. They are actors. With the Actor Profile and the act chain already in place, and an instance_issuers field that fits any client registration channel (static, Dynamic Client Registration, or CIMD), treating instances as first-class actors needs no new grant type, no new client type, and no new claim. It needs a profile that ties them together.
The new version of AAuth (draft-hardt-aauth-protocol-01, since resubmitted as draft-hardt-oauth-aauth-protocol) materially changes the earlier comparison. Mission is now first-class in the protocol, with PS-mediated approval, mission-aware token choreography, and governance endpoints. The remaining gap is no longer whether Mission exists, but whether the published model is strong enough to support portable containment rather than just mission correlation and governance hooks.
Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.
OAuth was built for closed worlds, and that constraint is why it became mature. Agents expose the limits of that deployment model. This post traces what the newer OAuth standards get right and which substrate gaps still need to close.
The current split between token exchange semantics and JWT access token practice creates avoidable interoperability failures. A common profile for act, grounded in entity profiles, can align JWT assertion grant and JWT access token processing.