When I wrote Mission Architecture on AAuth, AAuth was a proposal with a strong identity and choreography story and an open question at the governance layer. My argument was that it looked like a better clean-sheet substrate than OAuth for agent authorization, but that it still did not clearly define where durable task authority would live.

The published draft-hardt-aauth-protocol-01 changes that argument materially.

The earlier post made a narrow claim:

AAuth looked like a better clean-sheet substrate than OAuth for agent authorization, but it still did not clearly remove the need for a Mission-like governance object above the protocol.

That claim is no longer accurate as written. Mission is now a first-class concept in the published protocol. There is a mission proposal and approval flow, an AAuth-Mission header, mission-aware token choreography, and PS governance endpoints for interaction, permissions, and audit. The protocol moved toward exactly the kind of governance layer the earlier post said was missing.

That does not mean the architecture is finished. What it means is that the question has shifted. The draft closes the “where is the mission layer?” question. It does not close the “what authority does the mission actually confer?” question. The gap is no longer whether AAuth needs a mission layer. The gap is whether the mission layer it has is semantically rich and lifecycle-complete enough to do the work that durable task authority actually requires.

The honest answer is mostly the latter. That is what this post works through.

Before getting into the details, the current state of the draft is straightforward:

What the Earlier Post Got Right

The earlier post got three big things right, and they still hold.

First, AAuth is a cleaner protocol substrate than OAuth for agent systems. Signed requests with proof of key possession, PS-mediated deferred authorization, and explicit clarification as a first-class operation all provide a stronger base shape than stretching classic OAuth.

The chaining difference matters most. OAuth Token Exchange (RFC 8693) does give OAuth a delegation chain story, but those chains are not PS-mediated, not correlated to a governance object at each hop, and not visible to a central authority that can enforce mission context across the full chain. AAuth’s chaining is architecturally different in ways that matter specifically for mission governance.

Second, better protocol choreography is not the same thing as durable authority governance. A protocol can be conversational and chain-aware without defining a durable authority object.

Third, the missing piece looked like a Mission-like governance object rather than just another purpose string or another token field. That point is now partly validated by the protocol itself, because the published draft introduces Mission as a first-class governance concept.

That is the core delta.

What This Closes From the Earlier Argument

The published draft now gives Mission a real place in the protocol:

• a Mission as a scoped authorization context
• mission creation and approval at the Person Server (PS)
• an AAuth-Mission request header
• mission context that can be carried in resource tokens and auth tokens
• mission lifecycle and mission log semantics
• governance endpoints for interaction, permissions, and audit

This is a meaningful change. The older post said AAuth still appeared to need a Mission-like governance object above the protocol. The published draft now has one in the protocol. The architecture is no longer only about agent identity, proof-of-possession, and token choreography.

The mission-aware flow in draft-hardt-aauth-protocol-01 works as follows:

1. The agent obtains an agent token from its agent server.
2. If it wants governance, it sends a mission proposal to the PS’s mission_endpoint.
3. The PS may involve the user through review, approval, or clarification.
4. On approval, the PS returns an AAuth-Mission header containing the approver and s256 hash of the approved mission body.
5. The agent includes that AAuth-Mission header on later resource requests.
6. A mission-aware resource can include the mission object in the resource token it returns.
7. The agent presents that resource token to the PS as part of the authorization flow.
8. The PS evaluates the request against mission context before issuing an auth token directly or federating with the resource’s AS.

The approved mission is now a real protocol object. The mission blob must include:

• approver
• agent
• approved_at
• description

It may also include:

• approved_tools
• capabilities

That is enough to say the published protocol now has a mission layer in a meaningful sense.

It also means several claims from the earlier post need to be revised.

Mission is now clearly first-class in the protocol. Approval is part of the core governance flow. Mission context survives the initial approval event and travels through token choreography. The PS has a genuine governance role rather than serving only as a broker in authorization exchanges.

That governance role is architecturally significant. The PS is playing policy-definition and decision roles in the mission governance layer, while also acting as the user’s interaction proxy for clarification and consent. Combining those roles in a single entity keeps the governance stack coherent but also makes the PS a critical dependency for every authorization decision in the chain. That concentration has real implications for availability, trust model separation, and deployment topology that are worth keeping in mind as the architecture matures.

That is real progress.

What Still Does Not Close

The published draft materially changes the comparison. It does not eliminate the harder parts of the Mission argument.

1. Mission is still text-first, not authority-model-first

This is now a real mission layer, but it is still not a portable authority model. The approved mission body includes structured top-level fields, but the actual mission scope still centers on a Markdown description.

That is a design choice, not an oversight. Understanding why it matters requires being clear about two fundamentally different models for what a mission is in a multi-system context.

The AAuth model: mission as governance object, with enforcement coordinated but not fully shared.

In the published protocol, Mission sits at the PS as a governance artifact. The PS approves it, carries it, correlates it, and governs it. The AS and Resource, as downstream systems, receive mission context and participate in token issuance and enforcement. What the protocol does not provide is a shared, portable authority derivative that all of them evaluate the same way. Each system still combines mission context with its own local policy and its own interpretation of the request. The PS can refuse future token issuance, and any resource can refuse a request, but the draft does not require independent systems to converge on the same interpretation of what “inside the mission” means.

The Mission Authority Model: mission as shared enforcement artifact, compiled from approved intent.

The mission series argues for something different. Approved intent should produce a machine-evaluable derivative: a structured representation of which resource classes, actions, constraints, stages, and delegation bounds are actually inside the mission. That artifact travels with or can be derived from the mission. Multiple PSes, ASes, and Resources evaluate consistently against the same bounded authority envelope. Enforcement is shared because the authority model is shared.

The difference is not just technical. It is a question of what “mission governance” actually guarantees.

In the AAuth model, governance means the PS approved the intent and can revoke or log against it. Whether a specific downstream action was actually inside that intent is still evaluated through local policy and local request interpretation at each participating system. The protocol does not guarantee that independent implementations will converge on the same answer about mission containment.

In a shared enforcement model, governance means the authorized boundary can be evaluated consistently by independent systems. A compliant implementation that approves an out-of-scope request is wrong, not just permissive.

OAuth readers will recognize the pattern. Two OAuth authorization servers can treat the same scope value differently and still be spec-compliant, because OAuth standardizes scope syntax, not scope semantics. AAuth inherits that problem at a higher semantic level: mission prose is richer than a scope string, but still not a shared authority model.

The practical consequences show up in three places.

Audit. Mission correlation — was this request associated with an approved mission? — is achievable with the AAuth model. Mission containment — was this request actually inside the mission’s authority? — requires the shared enforcement model. Correlation supports traceability. Containment is what high-governance environments actually require.

Attenuation. If mission authority lives in prose, there is no formal way to prove that a downstream token is a subset of the approved grant. A PS can assert it and a resource can accept it, but neither can prove it. A Mission Authority Model is the prerequisite for making attenuation provable rather than merely asserted. This is also what makes gap #4 on downstream attenuation harder than it looks: the attenuation problem cannot be cleanly solved without first solving the authority model problem.

Cross-domain enforcement. Two independent PSes can correlate the same mission through the hash. They cannot enforce it consistently unless they share a semantic model of what the mission permits. The AAuth protocol makes cross-domain mission correlation interoperable now. Cross-domain enforcement remains local to each deployment.

The draft’s optional approved_tools field does not close this gap. A tool list is a permission set, not a bounded authority envelope. It says which tools may be called. It does not define the resource classes those tools may touch, the actions they may perform within those classes, the stage constraints on when each applies, or the explicit exclusions the approver intended.

This is also where Rich Resource Requests (R3) matters, even though it does not fully solve the authority-model problem. R3 is a companion draft that defines structured authorization vocabularies for resources: mappings to MCP, OpenAPI, gRPC, and similar formats that let resources describe their operations precisely. Resources publish R3 documents; the PS or AS evaluates them; auth tokens carry back the result as specific granted operations (r3_granted) and operations requiring per-call parameter validation (r3_conditional). The semantic richness is for the authorization layer, not the agent:

• The Resource describes what it offers in precise vocabulary
• The AS evaluates what the mission permits against that vocabulary
• The user sees curated human-readable consent text from the display section
• The agent carries an R3 document hash and acts on the result

Agents carry R3 document hashes without reading the definitions themselves. The authorization layer does the semantic work server-to-server.

What R3 contributes is a more structured authorization surface. Instead of comparing mission prose against bare scope strings, the PS can compare mission intent against a precise vocabulary of what the resource actually permits. That narrows the gap between approval and enforcement without closing it. It is a more structured surface for local evaluation, not a shared authority model.

It is worth being direct about why AAuth makes this tradeoff. Standardizing a compact mission object with human-readable description is tractable today. Standardizing a universal authority language is not, at least not before there is enough implementation experience to know what fields, selectors, constraints, and stage semantics actually need to interoperate across real deployments. The AAuth approach lowers coordination cost sharply and makes early adoption realistic. The Mission Authority Model approach is more correct about what strong governance eventually requires. Both can be true at the same time.

The practical path is layered. Early deployments use mission text plus PS-local heuristics. Stronger implementations add locally compiled authority artifacts behind the PS. R3 improves authorization precision in the meantime by giving the PS structured resource vocabularies to reason against. A later companion profile can standardize a portable Mission Authority Model once there is enough operational evidence to know what actually needs to interoperate. The current draft creates the protocol slot. It does not fill it.

2. Lifecycle exists, but remains intentionally narrow

In draft-hardt-aauth-protocol-01, a mission has two states: active and terminated. Completion is the expected path into termination. The draft defers revocation mechanics, delegation tree queries, and administrative interfaces to a companion specification.

That is meaningful progress over no lifecycle at all, but also a deliberately minimal model with real consequences.

The AAuth model: mission has existence and completion, not rich lifecycle semantics.

The protocol establishes that missions exist, that they can be approved, and that they end. What it does not establish is why they end or what that means for participants downstream. Termination is termination. Normal completion looks the same as operator cancellation, which looks the same as policy suspension, which looks the same as business-driven revocation. Each arrives at the same protocol state: terminated.

Outstanding token requests, in-flight agent operations, and queued work all see the same signal regardless of the reason. What they do with it is up to each implementation.

The mission series model: lifecycle states carry semantic meaning that downstream systems need.

A richer lifecycle model would likely need to distinguish states that have different operational implications, for example:

• Completed: task finished successfully; outstanding tokens may drain normally
• Suspended: temporarily paused for review; downstream operations should queue, not abort
• Cancelled: business-driven stop; outstanding work should roll back where possible
• Terminated for policy violation: immediate halt; already-issued tokens should be treated as invalid even if not yet expired
• Timed out: deadline exceeded; tokens within window may complete, new ones should not issue

These are not academic distinctions. They determine what downstream agents and resources should do when they receive the signal.

The concrete failure mode.

An agent is three days into a multi-step financial workflow. A compliance officer wants to pause it pending investigation, not cancel it. Under the current protocol there is no pause state. The compliance officer terminates the mission. The agent’s running operations see terminated and must decide locally whether to abort, checkpoint, or drain. The downstream AS stops issuing tokens. The agent has no protocol-level signal distinguishing “hold and wait for review” from “stop and clean up.”

The compliance officer now manages the suspension outside the protocol, through operational coordination, direct system access, or implementation-specific admin tooling. That is exactly the kind of problem a lifecycle model exists to solve.

Why AAuth makes this tradeoff.

A minimal state model is much easier to implement and much easier to align across vendors. Every additional lifecycle state multiplies both the implementation surface and the edge cases requiring interoperability. Prematurely standardizing administrative semantics before deployments have real operational experience risks standardizing the wrong model. The draft is right to defer this. The spec also gives a concrete architectural reason: there is no push channel from the PS to the agent. AAuth agents poll; they do not receive notifications. A suspended state would require the agent to learn the mission has resumed, which is not possible without polling indefinitely with no indication of when to stop. Terminating and creating a new mission scoped to the changed circumstances is the spec’s recommended path.

The cost is that every deployment independently invents lifecycle semantics that should eventually be interoperable. A mission terminated in org A’s PS means something locally specific. Org B’s systems, participating in that mission’s execution, receive a terminated signal and interpret it by their own rules. When the ecosystem eventually needs lifecycle semantics to interoperate across deployments (and high-governance environments will require this), each deployment’s bespoke model becomes a migration problem.

The current draft is strong enough to anchor mission existence and completion. It is not yet strong enough to anchor the full administrative lifecycle that durable task authority requires. The companion specification is the right place for that work. The gap is real in the meantime.

3. Revocation is stronger in the control plane than in the runtime plane

The PS now has meaningful revocation authority:

• terminate missions
• deny future token requests
• revoke outstanding auth tokens through revocation endpoints where implemented

That is a real and important capability. The failure mode is not in the control plane. It is in the gap between control-plane revocation and runtime stop.

The AAuth model: the PS can withdraw authority; whether execution stops is an implementation question.

When a mission is terminated, the PS refuses new token requests. Outstanding auth tokens can be revoked through the revocation endpoint where that revocation path is implemented. The protocol authority is withdrawn.

One clarification on the token model matters here. Resource tokens in AAuth are not access tokens. They are credentials issued by the resource server to the agent so the agent can request an auth token from the PS. Auth tokens are what the agent presents to the resource for access. In three-party flows the PS issues them directly. In four-party flows the PS federates with the resource’s AS, the AS issues the auth token, and the PS delivers it to the agent. In both cases the PS is on the critical issuance path: it can refuse to federate or refuse to issue, stopping new auth tokens from reaching the agent.

For outstanding tokens already held by the agent, the protocol defines a revocation path in both flows where revocation endpoints are implemented. In three-party flows the PS can call the resource’s revocation endpoint with the auth token’s jti. In four-party flows the PS can do the same, calling the resource’s revocation endpoint directly and optionally notifying the AS. The runtime-stop argument does not depend on the AS being the revocation hop. It depends on whether revocation support exists and how quickly it propagates.

All AAuth auth tokens are also proof-of-possession: they are bound to the agent’s signing key and useless without it. This means the revocation window is a risk only for the legitimate agent still holding the private key, not for an attacker who might have intercepted the token.

The practical revocation gap is therefore not about issuer identity. It is about timing and propagation: where a revocation path exists, the PS can call the resource’s revocation endpoint, but an agent may already have submitted a request using a token issued minutes before revocation was triggered. If the resource has not yet processed the revocation call, the request proceeds.

What the protocol does not, and arguably cannot, define is what happens to work already in motion. An agent may hold valid auth tokens issued minutes before revocation. A downstream agent may have cached resource decisions. Queued operations may have already been submitted to external systems. Work that was authorized under the mission continues until those tokens expire, those caches invalidate, and those operations complete or fail on their own.

The practical strength of revocation depends on:

• the shortest-lived token in the chain
• how aggressively each participating resource checks revocation
• how many downstream hops already hold tokens or cached decisions
• whether queued operations in external systems can be recalled

The mission series model: revocation needs stop semantics, not just revocation authority.

For high-consequence agent work, revocation authority is not the same as guaranteed stop. What matters is that when the PS terminates a mission, execution actually stops across the full delegation chain within a defined and operationally meaningful bound.

That requires more than a revocation endpoint. It requires short token lifetimes, eager revocation checking at each hop, event-driven propagation to participating systems, and operational architecture built around the assumption that mission termination is a hard control signal rather than an advisory one.

The concrete failure mode.

A user discovers their agent is about to execute a bulk data export they did not authorize. They terminate the mission. The PS marks it terminated, calls the export service’s revocation endpoint with the auth token’s jti, and stops issuing new tokens.

But the agent already submitted a request to the export service using a token issued two minutes before revocation was triggered. The request arrived at the export service before the PS’s revocation call was processed. The export service queues the request, processes the revocation call, but the queued operation is already in flight. The data export proceeds.

The PS did everything the protocol allows. Execution continued anyway. The control-plane revocation was correct and complete. The runtime stop failed.

Why AAuth makes this tradeoff.

Standardizing guaranteed stop semantics across arbitrary resources, caches, and execution environments is extremely hard. Different resources have different capabilities. Some can check revocation eagerly. Some cannot. Some queue work internally in ways that make recall difficult. Forcing the core protocol to guarantee instantaneous stop would require defining runtime architecture constraints that go well beyond what an authorization protocol should specify, and would exclude many legitimate resource implementations.

Revocation authority belongs in the core protocol. Runtime stop guarantees belong in deployment profiles and operational architecture.

The cost is real. In high-consequence environments such as financial operations, data access, and actions with external effects, the gap between “authority revoked” and “execution stopped” is exactly where harmful outcomes occur. Short-lived tokens and aggressive revocation checking can narrow the gap considerably, but closing it requires implementation discipline the protocol does not mandate. Deployments operating in high-stakes environments need to design for this explicitly. It will not be visible in the protocol spec alone.

4. Downstream attenuation is still too weak

The published draft explicitly does not require downstream authorization to be a subset of upstream scopes. The design rationale is stated directly in the spec: a flight booking API that calls a payment processor needs the payment processor to charge a card, an operation orthogonal to the upstream scope. Formal subset rules would break legitimate cross-domain delegation chains. There is no mechanism to require attenuation and no vocabulary in the core protocol to express or verify it. A deployment profile could add formal attenuation constraints without contradicting the core protocol, but it would have to define scope vocabulary and subset semantics from scratch since the core provides no building blocks.

That tradeoff is defensible in open cross-domain ecosystems. But from a mission governance standpoint, it is a significant gap in the delegation model.

The AAuth model: chain transparency without chain containment.

AAuth gives you provenance: the full delegation chain is visible. You can see that agent A authorized agent B, which authorized agent C, all correlated to the same mission. The audit record is complete.

What the protocol does not guarantee is containment: that each downstream grant is actually a subset of the upstream authority. The PS evaluates each hop against the mission, but since the mission is prose, that evaluation is heuristic. A PS can assert that C’s request is within the mission. It cannot prove it.

The mission series model: attenuation as a provable property of the authority chain.

In a system with a Mission Authority Model, attenuation is a formal property. Each downstream grant can be verified as a subset of the upstream authority envelope. If the parent grant permits resource class R, action A, within stage S, then the downstream grant must specify a subset of R, A, and S or be rejected. The evaluation is mechanical, not interpretive.

That is not a theoretical nicety. It is what makes delegation chains trustworthy in adversarial or high-stakes environments.

The concrete failure mode.

An agent is authorized on a mission to “coordinate vendor onboarding for the Q3 contract.” It delegates a sub-task to a procurement agent, which further delegates to a financial reconciliation agent. The PS evaluates each hop and issues tokens because each request sounds plausible relative to the mission description.

The financial reconciliation agent ultimately performs actions that touch live payment systems, well outside what the user intended when they approved “vendor onboarding.” Each individual PS evaluation was reasonable in isolation. The cumulative chain escaped the authority envelope. No participant can prove it was out-of-scope because there is no shared, machine-evaluable representation of what “vendor onboarding” actually authorizes.

The provenance log records the chain perfectly. The audit record is clean. Nothing shows a containment violation because containment was never enforced.

Transparency is not the same as safety.

This is the critical distinction. Chain transparency is valuable: you can reconstruct exactly what happened and who authorized what. But observability after the fact is a different control from enforcement before the fact.

Attenuation is a pre-execution guarantee: this request is within a provably bounded subset of the original authority. Provenance is a post-execution record: here is how the authorization chain evolved.

Transparency tells you how authority evolved. Attenuation tells you whether it stayed inside a bounded envelope. Only one of them prevents harm before it occurs.

Why AAuth makes this tradeoff.

Formal attenuation rules that require each downstream scope to be a mathematical subset of upstream scopes work cleanly in closed, homogeneous systems. They break in cross-domain workflows where downstream resources have capability models that do not map onto upstream scope vocabularies. Forcing strict subset semantics would make the protocol unusable for many legitimate multi-domain workflows.

The tradeoff favors flexibility and deployability now. The cost is that delegation chains cannot be formally verified, only asserted. In agentic systems where chains can be deep and execution can be long-running, that is not a theoretical risk. It is the expected failure pattern when scope creep occurs across a multi-hop delegation chain. The protocol will show you the chain clearly. It will not stop the chain from expanding beyond its intended bounds.

5. Cross-domain mission semantics are still local

Gap #1 is about what the mission object provides within a single deployment for local enforcement. This gap is different: it is about what happens when two independently operated systems need to evaluate the same mission across a trust boundary without sharing the mission body.

Mission correlation travels more easily than mission meaning

The protocol now carries mission correlation through the chain: the s256 hash and approver URL appear in resource tokens, auth tokens, and audit records. Any system that receives these can confirm “this action was correlated to mission M, approved by PS X.” That is correlation.

What it cannot do is enable a system to independently evaluate whether this action falls within what mission M permits. That requires the full mission body and a shared semantic model for interpreting it.

Two distinct levels of interoperability.

Correlation interop: two systems agree that a set of actions are associated with the same approved mission. The s256 hash enables this. It is achievable today, across independent deployments, without sharing the mission body.

Enforcement interop: two systems evaluate independently whether a given action is within the mission’s authority and reach consistent conclusions. This requires either sharing the mission body (which creates disclosure problems) or sharing a machine-evaluable authority model derived from the mission that is safe to propagate.

The draft achieves the first. It does not attempt the second. “Interoperable mission governance” as the protocol currently defines it means “interoperable mission correlation.” Those are not the same thing.

The concrete failure mode.

An agent operates on a mission approved by org A’s PS. Its execution requires resources hosted in org B’s domain. Org B’s AS federates with org A’s PS and receives the mission hash and approver URL. Org B now must decide: does this mission permit the actions the agent is requesting against org B’s resources?

The AS can confirm a mission was approved. It cannot evaluate what the mission permits. Doing so would require fetching and interpreting the full mission body, which creates both a disclosure problem and an interpretation problem: org B’s AS may read the same prose differently than org A’s PS did.

Org B’s AS falls back to local policy. It might trust missions from PS X broadly, or require additional verification for sensitive resource classes. Two different deployments may apply entirely different local rules to the same federated mission. All of that variation is outside the protocol.

The privacy-enforcement tension.

The protocol’s choice to share only the hash and approver URL rather than the full mission body is the right privacy decision. Mission bodies often contain sensitive business context. Forcing disclosure to every AS in a cross-domain workflow would be a serious privacy failure.

But that constraint means richer cross-domain enforcement requires a way to convey mission authority without conveying mission content. That is precisely the problem a portable Mission Authority Model could solve: a compact, structured, privacy-safe artifact expressing what is permitted without revealing why, derivable from the approved mission and safe to share across trust boundaries. The protocol does not define one.

R3 can narrow part of this gap without eliminating it. Resources publish structured authorization vocabularies; auth tokens carry precise granted operations rather than bare scope strings. That gives independent systems a richer, less ambiguous surface for reasoning about what was actually authorized at each hop. It still does not tell them what the mission authorized in the first place. R3 improves the precision of what authorization grants express and strengthens the substrate a mission-aware governance layer can use. A Mission Authority Model is still what would make mission containment portable.

Correlation is interoperable now. Meaning is not. For deployments where cross-domain systems need to enforce against mission scope rather than simply correlate with it, that is the remaining gap. It is also the hardest one to close without solving gap #1 first.

Federation does not remove relying-party trust policy

The published draft makes real progress on cross-domain mechanics:

• explicit PS-to-AS federation with trust establishment
• pairwise user identifiers that limit cross-domain correlation
• mission object propagation through token choreography
• governance endpoints for cross-domain interaction and audit

The remaining problem is not whether the federation flow works. It is that relying parties still have to decide for themselves what trust to place in federated mission context even if mission meaning becomes somewhat sharper.

What the federation model actually guarantees.

When the PS federates with an external AS, the AS receives the mission hash and approver URL. It can verify the signature chain, establish trust with the PS, and issue tokens correlated to the mission. The choreography is defined. The trust relationship is defined.

What is not defined is what the AS is trusted to accept from the PS as sufficient mission context for its own resources. The AS sees a hash. It trusts the PS to have performed appropriate mission governance. It still has to decide, by local policy, whether that is enough for a given resource class, tenant, or risk level.

This is where the federation story remains intentionally policy-heavy. Even if future profiles improve semantic portability, a relying-party AS still has to decide which PSes it trusts, for which resource classes, and under which operating conditions. The protocol can move more mission context and more structured request meaning. It still cannot remove the relying party’s obligation to set trust policy at the boundary.

The concrete failure mode.

An enterprise PS approves a mission that includes “coordinate document review with external counsel.” The agent operates across the trust boundary, submitting documents to a law firm’s AS. The law firm’s AS federates with the enterprise PS.

The law firm’s AS has its own data handling policies. It needs to decide: does this mission permit submission of documents marked “confidential”? Does it permit bulk submissions? Read access to the full document library, or only documents explicitly listed?

The federated trust model tells the law firm’s AS that a mission was approved. It does not convey what the mission permits in the law firm’s context. The law firm has to choose: trust the enterprise PS entirely, make conservative local assumptions, or require out-of-band clarification. None of these is a governance answer. All of them leave the cross-domain policy question unresolved at the protocol level.

If the enterprise and the law firm are both compliant AAuth implementations with different local policies, they will handle the same federated mission differently. The protocol does not and should not fully remove that discretion. Two deployments that trust each other at the identity layer may still make different authorization decisions at the policy layer.

The privacy-enforcement tension.

The protocol’s choice to share only the hash and approver URL rather than the full mission body is the right privacy decision. Mission bodies contain sensitive business context. Disclosing them to every federated party would be a serious privacy failure.

But this creates a hard constraint on what cross-domain enforcement can look like. Richer enforcement requires conveying more about mission scope without conveying mission content. That is the gap a portable Mission Authority Model could fill: a compact, structured, privacy-safe artifact expressing permitted scope, derivable from the approved mission yet safe to share across trust boundaries without disclosing the underlying business rationale. R3 may help on the authorization side by making granted operations more precise: the relying-party AS sees structured grants rather than bare scope strings. It still does not decide what the relying party should trust the mission to authorize.

Why the current approach is defensible for now.

Defining a cross-domain semantic model before there is operational evidence of what mission semantics need to cross boundaries, and in what form, would likely produce the wrong model. The federation mechanics need to work first. Trust choreography is the harder near-term problem. Semantic portability can follow once deployments show what cross-domain enforcement actually requires in practice.

The cost is that the current federation story is strong on identity correlation and trust choreography, and still dependent on local relying-party policy for enforcement. Deployments requiring richer cross-domain enforcement will need bilateral agreements, ecosystem-specific profiles, or custom projection mechanisms above the current core. That is the right place for them. But the work is not free, and nothing in the protocol spec will tell you where each relying party should draw its trust boundary.

6. Runtime alignment is still outside the protocol

The PS provides meaningful request-time governance:

• approve missions before execution begins
• deny permissions when requests fall outside approved scope
• log audit events for correlation and review
• relay interaction when the agent needs clarification
• refuse future token issuance when governance conditions change

That is real and necessary. It is also only half the governance problem.

The distinction between request-time governance and runtime alignment.

Request-time governance answers the question: is this request authorized? It evaluates individual authorization decisions at the moment a token is requested.

Runtime alignment answers a different question: is the trajectory of this execution still aligned with the user’s original intent? It evaluates the cumulative pattern of agent behavior over time, across many individually authorized decisions, each of which may have been locally correct.

These are not the same control. A protocol that solves the first does not automatically solve the second. The published AAuth draft solves the first well. It does not address the second.

The concrete failure mode.

An agent is authorized on a mission to “prepare a due diligence report on Acme Corp for our M&A team.” The PS approves it. Each individual request is authorized: pulling filings, accessing analyst reports, querying internal deal databases. The audit log is clean.

Midway through execution, the agent begins correlating information across the deal database and external news sources in ways the analyst did not anticipate. It drafts sections that mix confidential internal deal strategy with public market data in a form the user never sanctioned. Each step is within some plausible reading of the approved mission. The PS sees authorized requests and approves them.

No individual authorization check fails. The cumulative execution has drifted meaningfully from user intent. The governance system has no visibility into this trajectory.

This is what Mission Shaping Is Not Enough describes: an agent can remain nominally inside mission scope while drifting semantically away from the user’s actual intent. Approval at T=0 does not govern behavior at T=N.

What runtime alignment would actually require.

A runtime alignment layer needs capabilities the authorization protocol does not and should not define:

• continuous observation of execution state, not just authorization events
• semantic evaluation of accumulated agent behavior relative to approved intent
• staged release gates that pause before high-consequence or irreversible actions
• a feedback path from observation systems back into mission governance, so detected drift can trigger mission review or suspension

Why this is not a protocol design failure.

Standardizing runtime alignment inside the core AAuth protocol would be the wrong move. It would require the protocol to define agent behavioral semantics, execution monitoring, and semantic evaluation, all of which depend heavily on agent architecture, task domain, and risk model. That is not a protocol-layer problem.

The gap here is one of architectural scope, not protocol design error. The protocol provides the authorization substrate and the governance hook: a PS with mission context that can refuse tokens and relay interaction. Runtime alignment needs to be built above that hook, treating it as a feedback point in the execution loop rather than just a record-keeping endpoint.

That distinction matters for how deployments are designed. The protocol does not determine whether the PS is a passive logging mechanism or an active control point. A deployment that wires observation systems into the PS interaction endpoint and uses staged release gates before irreversible actions has far stronger runtime governance than one that treats mission approval as a one-time gate. The protocol does not make that choice for you. Deployments that assume it does will be surprised by the gap.

The Practical Takeaway

The old takeaway was:

AAuth looks like a better substrate than OAuth, but it still appears to need a Mission-like governance object.

The better takeaway now is:

AAuth now has a mission layer. The right question is no longer theoretical. It is operational.

The architecture is now much closer to the one I have been arguing for:

• agent identity and proof-of-possession at the protocol edge
• a Person Server representing the legal person
• mission proposal and approval before broader authorization unfolds
• mission-aware resource and auth tokens
• PS-to-AS federation across trust domains
• governance endpoints for interaction, permission, and audit
• a richer authorization description layer emerging at the resource boundary through R3

The remaining gaps are now easier to name precisely:

• mission text is still not a full authority model, so correlation is more interoperable than containment
• lifecycle and revocation are stronger in the control plane than in guaranteed runtime stop
• attenuation across delegation chains is still too weak to make containment provable
• cross-domain mission semantics and runtime alignment still need to be built above the current protocol layer

The protocol family is no longer treating agent identity and token choreography as the whole answer. It is now building around a mission-aware governance layer and a richer authorization layer at the resource boundary, even if the deeper authority-model problem is still not fully solved. The published draft standardizes mission coordination and correlation. R3 adds more precise request meaning at the resource boundary. Together they strengthen the substrate for governance without yet standardizing shared mission containment.

That is not a reason to dismiss the work. It is a reason to position it correctly. This is foundational work for an agent-native world because it moves the protocol stack toward mission-aware governance without overreaching into every harder problem at once. The published protocol gives Mission a first-class governance role. R3 makes resource requests more semantically legible. That combination materially improves the substrate even before a full Mission Authority Model exists. The stack is now much stronger on mission correlation and governance hooks than it was before. It still does not standardize portable mission containment. That is the real remaining gap, and the right place for the next layer of work to explore.

Sources

• draft-hardt-aauth-protocol-01 on Datatracker
• AAuth Rich Resource Requests (R3) draft dated April 13, 2026
• Mission Architecture on AAuth
• Open-World OAuth Still Needs Mission Shaping
• The Mission Shaping Problem
• Mission Shaping Is Not Enough
• Why Mission-Bound OAuth Might Be the Wrong Answer