---
title: "From a Request to an Approved Mission"
date: "2026-06-06T11:00:00-07:00"
lastmod: "2026-06-06T11:00:00-07:00"
description: "Before any token exists, a user request has to become a trustworthy approved Mission. Shaping proposes a candidate Intent, Consent Evidence commits the structured consent disclosure the Authorization Server recorded as rendered (not the pixels or the Approver's comprehension), and Deferred Approval with its Revision companion makes the approval event async and narrowable. None of them grants authority."
summary: "A user request is untrusted input. This post covers the integrity of the approval event, the layer before any token exists: the client-side shaper that proposes a candidate Mission Intent, the Consent Evidence that commits the structured consent disclosure the Authorization Server recorded as rendered (not the pixels or the Approver\u0026rsquo;s comprehension), and the deferred and revisable approval that lets a human reviewer narrow a proposal in place. Authority is created only when the Authorization Server validates, narrows, and approves."
slug: "mission-approval-integrity"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
series:
  - "building-mission-bound-authorization"
---


{{< spine steps="intent,mission" >}}

{{< tldr >}}

- **The argument.** Between a user's prompt and the agent's first token sits a transition. A request becomes an *approved Mission*. Everything on the request side is untrusted. This post is about making the moment of transition, the [approval event](/notes/the-mission-is-the-missing-abstraction/#mission-versus-intent), trustworthy, before any authority exists.
- **What lives in this post.** Three concerns, none of which grant authority: [Shaping](#shaping-proposes-only) (turning a request into a candidate Mission Intent), [Consent Evidence](#consent-evidence-the-recorded-disclosure) (committing the structured disclosure the Authorization Server recorded as rendered), and [Deferred Approval with its Revision companion](#deferred-and-revisable-approval) (making the approval event asynchronous and narrowable). Then [how they compose](#how-they-compose) on one worked example. The shaper proposes only, consent evidence records only, deferred approval narrows only. Authority is created solely by the Authorization Server's validation and approval.
- **The card analogy.** This is the approval workflow that runs before the card exists: the request, the disclosure, and the sign-off. [You Approve What You Were Shown](/notes/you-approve-what-you-were-shown/) is this part with no protocol in sight. ([Where the analogy breaks](/notes/you-approve-what-you-were-shown/#where-the-analogy-breaks).)
- **The laws.** This post operationalizes [Attribution and Containment (Laws 2 and 5)](/series/mission-bound-authorization/#the-five-laws-of-delegated-authority): the approval record keeps authority attributable to a real approver, and it fixes the approved purpose that every later action is checked against.
- **Specs (editor's copies).** [Mission Intent Shaping](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-shaping.html), [Mission Consent Evidence](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html), [Mission Deferred Approval](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html), [Mission Approval Revision](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval-revision.html).

**Reading path.** ~15 minutes in order, or ~8 minutes for just the integrity story: [the boundary](#the-boundary-restated) → [Consent Evidence](#consent-evidence-the-recorded-disclosure) → [how they compose](#how-they-compose).

{{< /tldr >}}

# Overview

[The Mission Is the Missing Abstraction](/notes/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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-shaping.html), 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html), 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html) and its narrowing companion [Approval Revision](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval-revision.html), 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](/notes/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 control at a glance | |
| --- | --- |
| **Minimum useful version** | The Authorization Server validates and narrows every Mission Intent submitted through PAR and renders the derived authority to the Approver. Consent Evidence records the structured disclosure as rendered |
| **What it prevents** | Approvals that bind something other than what the Approver saw, and proposals that specify their own authority |
| **What it does not prevent** | An Approver accepting an over-broad disclosure. Breadth approved is breadth granted |
| **Operational owner** | The Mission Issuer owns validation, derivation, and consent rendering. The application team owns the shaper, which proposes only |
| **Evidence emitted** | The approval event and the Consent Evidence record, joined on the `mission_id` |
| **Maturity** | Consent Evidence is recommended for agents. Shaping is informational. Deferred Approval and Revision are experimental |

# 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](/notes/the-mission-is-the-missing-abstraction/#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.

```mermaid
flowchart LR
    subgraph U["Untrusted (client-side)"]
        direction TB
        P[Prompt or trigger]
        SH[Shaper]
        I[Candidate<br/>Mission Intent]
        SE[Shaping Evidence]
        P --> SH --> I
        SH -.records.-> SE
    end
    subgraph B["Approval event (Authorization Server)"]
        direction TB
        V[Validate + narrow,<br/>derive Authority Set]
        D[Render disclosure,<br/>commit consent_rendering_hash]
        UC[Approver consents]
        V --> D --> UC
    end
    subgraph T["Approved Mission (governed)"]
        M[("intent_hash<br/>authority_hash<br/>state=active")]
    end
    CE["consent_rendering_hash<br/>(Consent Evidence companion)"]
    I --> V
    UC --> M
    M -.companion.-> CE
```

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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-shaping.html) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html) (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](/notes/mission-bound-runtime-enforcement-profile/).) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval.html) makes the approval asynchronous, and the [Approval Revision draft](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-approval-revision.html) 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](/notes/mission-lifecycle-and-change/)). The draft profiles [OAuth Deferred Token Response](https://datatracker.ietf.org/doc/draft-gerber-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](/notes/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](/notes/mission-bound-authorization-reference/#the-running-example-end-to-end). 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](/notes/the-mission-is-the-missing-abstraction/) picked up this task at the issuance core. Here we watch the *approval-time integrity* around it.

```mermaid
sequenceDiagram
    autonumber
    participant Al as alice@example.com (Approver)
    participant Ag as Agent + Shaper<br/>(client-side, untrusted)
    participant AS as Authorization Server<br/>(Mission Issuer)

    Note over Ag: SHAPING (proposes only)
    Ag->>Ag: Shape request → candidate Intent<br/>resources=[finance, docs, workflow]<br/>constraints=[Q3 2026, audit-committee, ready-notice]<br/>record Shaping Evidence
    Ag->>AS: Submit Mission Intent via PAR
    Ag->>AS: Authorization code flow, then token request<br/>completion_mode=deferred revisable

    Note over AS: DEFERRED APPROVAL
    AS->>AS: Derive Authority Set<br/>(query_financials + create_doc + notify_reviewer),<br/>route to alice
    AS-->>Ag: authorization_pending (deferral_code)
    AS->>AS: Build Consent Disclosure,<br/>compute consent_rendering_hash
    AS->>Al: Render disclosure to alice
    Al-->>AS: Approve (asynchronously)

    Note over AS: CONSENT EVIDENCE
    AS->>AS: Sign Consent Evidence,<br/>bind Mission to the hash
    AS-->>Ag: Mission-bound token over<br/>msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1, authority_hash
```

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](/notes/mission-bound-runtime-enforcement-profile/) 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](/notes/the-mission-is-the-missing-abstraction/#the-intent-to-enforcement-spine). It sits between [The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/), which defines the Mission and the issuance core this layer feeds, and [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement-profile/), 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](/notes/mission-bound-runtime-enforcement-profile/) 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](/notes/mission-sub-agents-and-delegation/), [Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/) (including Mission Expansion, the *widening* counterpart to this post's narrowing-only revisions), and [The Agent Runtime and Audit](/notes/mission-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.