Overview

The Mission Is the Missing Abstraction drew the boundary between Mission Intent (a proposal) and an approved Mission (the governance object). The proposal is untrusted. The Mission is authoritative. The approval event is the single moment of transition, where the Authorization Server validates the Intent, derives an Authority Set, the Approver consents, and the Mission record is committed by intent_hash and authority_hash.

This post is about the integrity of that transition. A request arrives as natural language, or as an upstream trigger, and has to become something the Authorization Server can validate and an Approver can meaningfully consent to. Three things have to hold for the resulting Mission to be trustworthy, and each maps to its own drafts in the suite:

1. The proposal must be honest about what it is. A shaper turns the request into a candidate Mission Intent, and that candidate has to fail closed on ambiguity rather than invent authority. (Shaping, Informational.)
2. The approval must commit what the Approver was actually shown. Otherwise a faulty rendering layer can display a narrow task while the Mission records a broad one. (Consent Evidence, Standards Track.)
3. The approval must survive a real human review. Reviews are asynchronous, and reviewers approve a narrowed subset far more often than they accept all-or-nothing. (Deferred Approval and its narrowing companion Approval Revision, both Standards Track, both labeled experimental for now.)

The unifying claim, hammered through every section below, is the one from The Mission Is the Missing Abstraction. None of these three grants authority. Authority is created only by the Authorization Server’s validation and approval. The shaper proposes. Consent evidence records. Deferred approval narrows. They make the approval that does grant authority trustworthy, without ever becoming it.

The boundary, restated

The trust boundary is the whole reason this layer exists, so it is worth stating in the terms of this post before we add anything to it. The Mission versus Intent section of the architecture series is the canonical treatment. The short version:

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The user’s raw prompt, the shaper, the model behind the shaper, and the candidate Mission Intent are all on the untrusted side. The Authorization Server’s admission decision is the boundary. Before it, only Intent exists. After it, only the Mission is authoritative.

Each of the three drafts in this post strengthens a different edge of this picture. Shaping makes the left box honest and auditable. Consent Evidence makes the middle box reconstructable after the fact. Deferred Approval makes the middle box tolerate a slow, picky human reviewer without losing state. The boundary itself never moves.

Shaping: proposes only

The issuance core defines the Mission Intent object and how the Authorization Server derives an Authority Set from it. It does not define how a deployment turns “reconcile our Q3 invoices and post any adjustments under $500” into that structured object. That step is the Mission Shaper, and the Shaping draft describes it.

The draft is Informational by deliberate choice. Client-side prompt processing is shaped by deployment policy, model choice, and product ergonomics. No two deployments agree on the transformation, and the interoperable surface is not the transformation but its result, the Mission Intent, which the issuance core already validates on the wire. So the draft specifies the shaper’s role and trust posture and the behaviors a sound implementation follows, not a portable shaping protocol.

A shaper can be an LLM-assisted function, a deterministic rules engine, a form, or a workflow. Whatever it is, its single rule is propose only:

• It MUST NOT issue, derive, or certify authority. Its output is untrusted client input until the Authorization Server validates and narrows it.
• It MUST NOT emit members that mimic Authorization Server outputs. No mission.id, no intent_hash, no authority_hash, no Authority Set, no lifecycle state. Those are produced by the Authorization Server at and after approval. A shaper that emits them is misusing its role, and the issuance core rejects a Mission Intent carrying any such member with invalid_request rather than silently stripping it.
• A model-based shaper is no exception. The model can draft a proposal. It is never the thing that grants or widens access.

What a sound shaper builds is a Mission Intent with goal, resources (each an absolute URI), free-text constraints, optional free-text success_criteria (disclosure and audit material only, carrying no machine semantics), an optional purpose, expires_at, and optional machine-actionable controls. The shaper proposes resources and describes the desired bounds in free text. It does not author actions, structured constraints, or delegation. Those are members of the Authority Set the Authorization Server derives, not inputs from the shaper.

Fail closed, not open. The interesting design content is what a shaper does when the request is ambiguous. An ambiguity is material when resolving it one way rather than another would change the Authority Set, the action class, the actor, the expiry, or the risk posture. For a material ambiguity, a sound shaper does one of three things: request clarification, emit a narrower proposal that excludes the ambiguous authority, or refuse with a reason. What it must not do is silently default a vague goal into a wide proposal. Because the shaper’s internal reasoning is unobservable to the Authorization Server, the draft expresses this through the audit artifact. When a shaper resolves an ambiguity in the broadening direction, Shaping Evidence MUST record it, and a proposal that broadens on an ambiguity without a matching record is unsound. (The draft says “unsound” deliberately. It is Informational and defines no conformance class.)

Shaping Evidence is that artifact: a record of the inputs, inferences, policy decisions, capability resolutions, ambiguities, and any model trace that produced the proposal. It is audit material, not authority. A Resource Server or PDP MUST NOT use it to permit an action. A deployment that wants the Mission record to cite how its proposal was produced can bind the two with an optional shaping_evidence_hash, computed over the suite’s domain-separated {typ, iss, value} envelope exactly as intent_hash and authority_hash are. That hash commits how the proposal was made. It confers no authority and proves nothing about the proposal’s correctness.

The threat this contains is silent broadening: a vague request quietly becoming a broad Authority Set, or prompt-injected content in the request expanding resources, pushing out expires_at, or suppressing a stated constraint. The shaper’s defenses (treat all prompt content as data not instructions, use resolved capabilities as a hard allowlist, refuse on injection patterns, record everything) reduce but cannot eliminate the risk. The real defense in depth is downstream. The Approver sees the validated Intent in a disclosure rendered by the Authorization Server, not by the shaper, before authority is bound. Which is exactly what the next section makes verifiable.

Consent Evidence: the recorded disclosure

The issuance core commits what was approved, the Mission Intent and the Authority Set, through intent_hash and authority_hash. It deliberately leaves one gap open. It does not commit the consent disclosure the Approver actually saw. A faulty or malicious rendering layer could show a narrower task than the Authority Set really records, and nothing in the core would catch it. The Consent Evidence draft (Standards Track) narrows that gap.

It adds two artifacts at the approval event:

• A structured Consent Disclosure object: the task summary (including the rendered expires_at), the rendered authority summary (resources, actions, constraints, delegation, consumption bounds), the material notices for high-risk authority, the Approver and Subject identities, and the intent_hash / authority_hash the disclosure corresponds to. It is constructed after Authority Set derivation and before approval. If the Authority Set changes afterward, the disclosure is discarded and rebuilt.
• A consent_rendering_hash over that disclosure object (again in the {typ, iss, value} envelope), and a signed Consent Evidence object that records the approval-or-decline event, the authentication context, and an integrity envelope (a JWS) over the whole record, bound to the same Mission anchors used for authority.

The precise scope claim matters, and the draft is careful about it:

Consent Evidence commits the structured disclosure the Authorization Server says it rendered. It does not, and cannot, prove what pixels reached the Approver, that the Approver read or understood them, or that the rendering layer was honest.

What it buys you is a durable, integrity-protected record tying a specific structured disclosure to a specific approval decision and Authority Set, so that any divergence between the recorded disclosure and the authority later enforced becomes detectable in audit. An auditor can re-render the committed disclosure and check it against the Authority Set the agent actually used.

The “what a human perceived” problem is not all-or-nothing, so the draft defines a rendering-assurance ladder a deployment climbs as far as its threat model needs. Rung 0 commits the disclosure. Rung 1 makes rendering a deterministic function of the disclosure and its template, so an auditor can re-render the intended form. Rung 2 adds an attestation that an identified, attested renderer produced it. Rung 3 is the what-you-see-is-what-you-sign rung. The Approver’s own authenticator signs the consent_rendering_hash, moving trust from the rendering layer to the Approver’s authenticator. (Rung 4, out-of-band confirmation at execution time, belongs to Mission-Bound Runtime Enforcement.) A deployment SHOULD reach Rung 3 for high-risk classes: irreversible actions, external commitments, privileged administration, cross-domain disclosure.

Two details are easy to miss and worth keeping. First, declines are recorded too. A declined approval creates no Mission, token, or authority, but Consent Evidence is still recorded, so that coercion, decline-then-reshape fatigue attacks, and rendering confusion cannot be made invisible to audit. Second, the disclosure renders the derived authority, not just the friendly summary. A disclosure that shows a mission_summary without a faithful authority_summary does not conform. The Approver consents to the authority, with the summary as context.

Deferred and revisable approval

The issuance core records an approval event but treats it as immediate. Real human review of an agent’s proposed Mission is not. Two facts go unspecified, and two companion drafts supply them: the Deferred Approval draft makes the approval asynchronous, and the Approval Revision draft lets the reviewer narrow it in place. One honesty note first: both are labeled experimental. Deferred Approval depends normatively on OAuth Deferred Token Response, which is not yet ratified, and Approval Revision rides the same substrate. Synchronous approval is the stable path, and these profiles are for evaluation until that substrate settles.

Reviews are asynchronous. The agent submits a proposed Mission and may wait a long time for a decision. This is deliberately the shape of the request-and-approval workflows an enterprise already runs, so an IGA or ticketing system can drive the decision without new human ritual, and for approval volume the ceiling-and-drawdown model of progressive authorization is the companion answer (Mission Lifecycle and Change). The draft profiles OAuth Deferred Token Response so a Mission approval can be deferred and polled. The client includes deferred among its completion_mode values, the Authorization Server returns authorization_pending with a deferral_code instead of a token, and the client polls until the approval resolves. Deferral changes only the timing of the approval event. The Authority Set, its authority_hash, and the recorded consent are exactly as in a synchronous approval.

Reviewers narrow. A reviewer commonly approves a subset of the proposed Mission, not the whole thing. Without a way to revise in place, the agent has to abandon the proposal and start over, losing the approval state and any preceding work. The Approval Revision companion adds a revisable mode. The client offers revisable alongside deferred, and when the Authorization Server can grant only a narrowed version, it extends the authorization_pending response with revision_required, a single-use sender-constrained revision_handle, and (optionally) the rejected_scope and rejected_authorization_details that tell the agent which dimensions were refused. The client pushes a narrowed Mission Intent to PAR with the handle, and keeps polling the same deferral_code. The approval resolves over the narrowed proposal. The client never lost its place, and the stable path without this companion is deny-and-resubmit under Deferred Approval alone.

The hard invariant, and the boundary to keep straight, is that this is narrowing only:

A revision can reduce the proposed Mission. It can never broaden it. The Authorization Server verifies the revised Authority Set is a subset of the proposed one under the issuance core’s subset rule before it re-reviews.

Widening an already approved Mission is a different operation with its own fresh approval, Mission Expansion, which lives in Mission Lifecycle and Change. Deferred Approval and its revision companion govern only how the initial approval is reached over time. And the rejected-dimension parameters are not a grant. A client MUST treat revision_required and the refused dimensions as evidence of nothing approved yet.

This is also where the layers start to interlock. The rejected_scope and rejected_authorization_details are precisely the machine-readable input a shaper consumes to plan the narrowing. Shaping narrows a proposal before submission. Deferred approval narrows it during review. And because a narrowed proposal is a different disclosure, a deployment recording Consent Evidence MUST compute a fresh consent_rendering_hash for the re-reviewed revision. Prior consent does not transfer to a different Authority Set.

How they compose

The three concerns are easiest to see threaded through one task. This is the series’ canonical running example. Alice asks her agent, in free text, “Put together the Q3 board packet for the audit committee and let them know it’s ready.” The Mission Is the Missing Abstraction picked up this task at the issuance core. Here we watch the approval-time integrity around it.

Walking it:

1. Shaping proposes. The shaper turns the open-ended prompt into a bounded candidate Intent. It resolves “the audit committee” to the audit-committee reviewer group, and it proposes three resources URIs (the finance, docs, and workflow services) bounded by invariants expressed as free-text constraints: the Q3 2026 fiscal period, the audit-committee recipient, the board-packet deliverable. It bounds the work in time with a expires_at of 2026-10-15T18:00:00Z. What it does not do is author the actions. It proposes resources and describes the desired bounds, and grants nothing. Had “the audit committee” been ambiguous about which group, the shaper would have asked alice rather than guess. It records Shaping Evidence and proposes.

2. The Authorization Server validates and derives. It is the Authorization Server, not the shaper, that turns the proposed resources and free-text constraints into a concrete Authority Set: a query_financials action (finance, scoped to Q3 2026), a create_doc action (docs, bound to the board-packet template), and a notify_reviewer action (workflow, targeting the audit-committee group). The shaper’s proposal informed that derivation. The Authorization Server authored every action in it.

3. The approval defers. Because the agent offered deferred revisable, the review need not be synchronous. The Authorization Server returns authorization_pending with a deferral_code and routes the rendered disclosure to alice, who approves on her own schedule while the agent polls. Had she instead refused the notify_reviewer action (a common reviewer instinct, holding back the external-facing step), the revisable mode would let the agent drop that action, push the narrowed Intent, and keep polling the same deferral_code. Narrowing only, never broadening. Here she approves the proposal as derived.

4. Consent Evidence commits the surface. The structured disclosure the Authorization Server recorded as rendered (the task summary plus the faithful authority_summary over all three actions) was committed by consent_rendering_hash before approval, and her approval produces a signed Consent Evidence record bound to it. The committed intent_hash and authority_hash are over exactly the Intent and Authority Set she approved, so an auditor can later re-render the recorded disclosure and compare it to the authority the agent used. The Authorization Server commits the Mission as msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1, state=active, and issues the Mission-bound token that runtime enforcement will police.

The result is an approved Mission whose integrity anchors commit a proposal that was honestly shaped, a disclosure that was faithfully recorded, and an approval that reflected a real human decision, without any of those three steps ever having granted authority. That is the whole job of this layer.

Where this sits in the series

This is the Intent step and the integrity of the Mission approval event on the series spine. It sits between The Mission Is the Missing Abstraction, which defines the Mission and the issuance core this layer feeds, and Mission-Bound Runtime Enforcement, which is where a Mission-bound token becomes a Mission-bound action, the load-bearing safety layer of the whole series.

Everything here happens before any token exists. By the time Mission-Bound Runtime Enforcement is evaluating an action against the current Mission, the questions this post answers, was the proposal honest, was the disclosure faithful, did the approval reflect a real human decision, have already been settled and committed. The later parts carry the approved Mission forward: Mission-Bound Authority, Mission Lifecycle and Change (including Mission Expansion, the widening counterpart to this post’s narrowing-only revisions), and The Agent Runtime and Audit.

The laws this part proves are the quiet ones. An approval binds only what it can replay (Attribution), and enforcement can only hold a boundary the approval actually drew (Containment). This is the one place in the loop where safety is still cheap. Spend the friction here.