Abstract

On the spine: Part 2 specifies the Intent step. The Shaper produces Mission Intent. The Mission and Authority steps (Parts 3, 4, 5) consume it. Enforcement (Part 6) is downstream.

The Mission-Bound OAuth Profile introduces the Mission Shaper as the component that transforms user input into Mission Intent. It explains why shaping belongs in the client layer and establishes the hard boundary: the Shaper does not issue authority, derive scopes, or mint tokens. It does not define the Shaper’s input/output contract.

This profile fills that gap. It defines the Shaper’s contract with the orchestrator, the versioned discovery snapshot it consumes, optional derivation hints that connect proposed actions to discovered operations, the clarification protocol for material ambiguity, and the trace needed for audit and replay.

The output remains an untrusted proposal until the validating server admits it. This profile improves the quality and auditability of that proposal; it does not move the trust boundary.

Introduction

A user provides a goal. The Shaper turns it into Mission Intent. The validating server admits that proposal and produces an Approved Mission. Substrate-native credentials then carry references to the Approved Mission.

The rest of the series specifies admission, authority derivation, credential projection, and enforcement. The first step, from input to Mission Intent, has the greatest implementation variance and the least protocol structure.

The Mission Shaper is where untrusted instructions are interpreted, entity references are resolved, defaults are applied, and proposed actions are connected to available capabilities. Errors here do not directly grant authority, but they can distort the proposal shown to the user and increase the chance of overbroad derivation. The critical distinction is whether uncertainty is surfaced or silently converted into a confident-looking Mission Intent.

This profile standardizes the observable contract, not the model, prompt template, or implementation language. It defines discovery inputs, output rules, optional operation bindings, ambiguity handling, refusals, and audit evidence.

This profile is substrate-independent. In OAuth, the orchestrator submits the structured Mission Intent to the Authorization Server. In an AAuth composition, an adapter renders it into AAuth’s native Mission proposal plus optional tools and MAY carry the structured object as an extension for governance mapping. Under the MAS topology, the consuming AS or PS coordinates validation with the MAS. Throughout this profile, validating server means the component responsible for admitting the governance Mission; it does not imply one common wire protocol.

This companion profile is optional for the wider Mission-Bound Authorization architecture. A deployment can use a simpler Shaper and still implement the OAuth Profile. A component claiming Mission Shaper Profile conformance, however, implements the full contract defined here.

Design Goals

This profile:

• Specifies the Shaper as a role with a stable input/output contract, separate from how it is implemented internally.
• Defines the minimum discovery context and the additional sources a Shaper SHOULD consume.
• Defines non-authoritative tool-and-action hints tied to a discovery snapshot so the validating server can reproduce and check the proposed mapping before deriving authority.
• Defines a structured ambiguity protocol so the Shaper surfaces uncertainty to the user instead of guessing.
• Defines a Shaper Trace artifact that the orchestrator can retain for audit, replay, and confidential evidence.
• Composes with the OAuth Profile, the Runtime Enforcement Profile, and the Mission Authority Server Profile without changing any of their wire shapes.

This profile does not:

• Define LLM prompts, templates, or model selection.
• Define formal verification of Shaper correctness. Future work.
• Standardize a capability-catalog aggregation format. It composes with existing source formats.
• Define multi-Shaper coordination.
• Change the trust boundary. The validating server admits Mission Intent regardless of which Shaper produced it.

What a Shaper Is

A Mission Shaper takes user input (such as a prompt, workflow trigger, or form submission) plus a versioned discovery snapshot containing requester bounds, available capabilities, resource descriptions, and deployment policy. It returns exactly one result: a Mission Intent proposal, a clarification request, or a refusal. Every result carries a result discriminator and includes the Shaper Trace inline or by reference.

The Shaper contract has two operations:

extract(input, snapshot) returns one of:

• intent: a Mission Intent proposal, optional derivation hints, and a Shaper Trace;
• clarification: a clarification request, a partial intent containing only resolved fields, and a Shaper Trace; or
• refusal: a structured refusal and a Shaper Trace.

clarify(handle, user_response, snapshot) resumes a prior clarification exchange against a current or explicitly pinned snapshot and returns one of the same three result types.

The orchestrator owns the loop. It or a dedicated discovery aggregator retrieves and validates network metadata, constructs the snapshot, calls the Shaper, presents clarification questions to the user, and submits a completed proposal through the substrate adapter. At this logical interface, the Shaper receives supplied input and snapshot data; it does not independently submit to the validating server or modify discovery sources. An implementation may invoke a local or hosted model internally, but that implementation detail does not change the contract.

What a Shaper MUST NOT do, restated from the OAuth Profile:

• MUST NOT issue authority, derive scopes, or mint access tokens.
• MUST NOT submit Mission Intent directly to the validating server. That is the orchestrator’s job.
• MUST NOT modify client registration, capability catalogs, or any discovery source. It reads; it does not write.
• MUST NOT present a resource, action, or constraint as discovered when it has no basis in the snapshot. User-requested but undiscovered objects remain explicit unresolved intent, not authority.

Why the Shaper Lives Client-Side

A natural question: why not accept the raw prompt at the validating server and have it extract Mission Intent itself? Four reasons keep the Shaper in the orchestrator:

1. Trust boundary. Running an LLM or other extractor inside the validating server expands its TCB to include adversarial-input handling. A compromised extractor compromises every Mission from every client. The current split treats orchestrator output as untrusted and lets the validating server do deterministic validation against requester registration and deployment policy. That boundary disappears under server-side extraction.
2. Integrity-anchor semantics. proposal_hash covers the structured, post-validation Mission Intent disclosed for approval. It does not replace agent-attestation evidence such as ACAP’s att_intent; it commits a different object for a different purpose. Server-side extraction would also make the validating server responsible for proving how an unstructured prompt became that object.
3. Ontology locality. Multi-tenant validating servers rarely own every tenant’s resource ontology. The orchestrator can propose mappings from tool manifests, OpenAPI documents, MCP server descriptors, RAR-type metadata, and substrate-native resource metadata. Those mappings remain non-authoritative: the validating server, or a trusted resource-domain validator, independently resolves current resource semantics before deriving authority.
4. Shaper diversity. Not every Mission Shaper is an LLM. Forms-based UIs, rules engines, workflow builders, and registered agent templates are all valid Shapers. Pushing extraction to the validating server would force LLM inference into that server for cases that do not need it.

The user remains the final disambiguator. Whatever the Shaper produces, the validating server renders the validated proposal and effective authority for explicit approval.

Shaper Implementations

The MVP names five implementation shapes. This profile defines what each is and where each fits.

LLM-driven Shaper. A common shape for natural-language agent interfaces. A model receives the prompt plus the discovery snapshot (or a bounded index over it) and emits a structured Mission Intent. Most interpretive variance lives here. The hint and ambiguity rules below constrain what the model may claim to have discovered.

Rules-engine Shaper. Deterministic mapping from a structured trigger (a calendar event, workflow start, or webhook) to a Mission Intent template. Common in workflow-engine deployments. It reduces interpretive variance, but missing or conflicting inputs can still require clarification or refusal.

Form-based Shaper. The user completes a structured form whose fields map to Mission Intent. No LLM is required. The form can enforce syntax and required fields, while the Shaper still resolves discovery bindings, policy defaults, and unsupported requests.

Workflow-builder Shaper. A graphical or declarative workflow definition is compiled into Mission Intent. The user assembles steps from a registered catalog, giving the Shaper stronger operation references than free-form input provides.

Hybrid Shaper. Composes two or more of the above. Common shape: LLM extracts a draft Mission Intent, then a rules-engine layer enforces deployment-specific constraints, then a form layer captures missing fields. Each layer’s output is the next layer’s input. The Shaper Trace records the composition.

A Shaper that claims conformance to this profile MUST satisfy the rules below regardless of which implementation shape it adopts. The discovery, binding, and ambiguity rules are about input/output behavior, not about implementation.

Architecture

Conceptual Model

Reading the diagram:

• Arrows show result and protocol flow, not trust. The Shaper can return an intent, clarification, or refusal.
• The discovery aggregator performs network retrieval and records provenance. The Shaper consumes the resulting snapshot and does not contact a validating server, user, or resource directly.
• The orchestrator owns user interaction, substrate submission, and the loop between the Shaper and the user.
• The Mission record is created at the state authority after the validating server admits the Mission Intent. The Shaper’s output is one input to that validation.

Roles

This profile names one new role and refines one existing role from the OAuth Profile.

• Mission Shaper. New. Transforms user input within a bounded discovery snapshot. Returns a Mission Intent proposal, clarification request, or refusal; emits derivation hints when the applicable profile requires them; and records a Shaper Trace.
• Orchestrator. Refined. Obtains a discovery snapshot, calls the Shaper, manages the clarification loop with the user, submits Mission Intent and derivation hints through the substrate adapter, and stores or references the Shaper Trace as confidential evidence.
• Discovery Aggregator. New logical role. Retrieves, authenticates where possible, normalizes, timestamps, and digests registration, metadata, capability catalogs, and deployment-policy inputs. It may be part of the orchestrator.

The Authorization Server, Person Server, MAS, Resource AS, PDP, and Resource Server roles from the governance profiles are unchanged. The Shaper need not be protocol-visible unless deployment policy requires registered Shaper identity or signed trace evidence. The applicable validating server admits Mission Intent and gates downstream artifacts regardless of which Shaper produced the input.

Trust Boundary

The Shaper’s output is untrusted until the validating server admits it. This profile reinforces that boundary rather than relaxing it:

• The Shaper Trace is evidence, not authorization. It explains how the Shaper produced the Mission Intent but does not bind the validating server to that explanation.
• Derivation hints make validation reproducible, but they are not authority and are never authoritative evidence that an operation exists. The validating server independently resolves current resource semantics and rejects hints that conflict with registration, policy, or current metadata.
• A non-conformant Shaper is allowed by the OAuth Profile. Its output receives no special trust and the validating server handles it like any other proposal. This profile improves proposal quality and evidence; server-side validation remains the security boundary.

Detailed Solution

Discovery Sources

A conformant deployment MUST supply requester-registration or equivalent authority bounds plus at least one resource or capability description relevant to the request. It SHOULD include the applicable sources below:

1. Requester registration metadata. In OAuth, this includes the client’s registered scopes, supported authorization_details types, registered purpose URIs, and any registered resource ontology. Other substrates provide equivalent requester bounds.
2. RAR Metadata (draft-zehavi-oauth-rar-metadata). The AS’s authorization_details_types_metadata_endpoint publishes JSON Schema for supported RAR types. The Shaper can use those schemas when constructing derivation hints. Mission Intent has its own schema, discovered separately through mission_intent_schema_uri.
3. Protected Resource Metadata (RFC 9728 PRM). PRM identifies the protected resource and its authorization servers and can carry registered extension metadata. Action catalogs or required RAR types need an extension or a linked resource-specific document; RFC 9728 alone does not define them.
4. MCP tool catalogs. When the Mission involves MCP tools, the aggregator captures the server’s tools/list result, filtered for the requester where possible. MCP does not define this response as a signed manifest; the snapshot therefore records the server identity, retrieval context, response digest, and trust status.
5. OpenAPI documents. For HTTP API surfaces without MCP, an OpenAPI document can describe available operations. When operationId is present and stable under deployment policy, the Shaper can bind to it; otherwise the deployment needs a canonical operation reference.
6. AAuth metadata. For AAuth composition, Person Server and Resource metadata identify native endpoints, supported access modes, scopes, and capabilities. These inputs inform shaping and substrate adaptation; they do not convert AAuth scopes into OAuth RAR types.
7. Deployment policy. Constraints set by deployment configuration (maximum Mission expiry, required purpose URI, allowed tenants, allowed resource domains). The Shaper applies these as proposal bounds. The validating server enforces them independently.

A deployment MAY supply other sources, such as a registered template or vendor ontology. Every snapshot entry MUST retain its source, retrieval time, digest, and trust status. The snapshot is descriptive, not an authority union: registration, resource metadata, and policy can intersect or conflict, and the validating server resolves those relationships.

Mission Intent Construction

Given an input and a discovery snapshot, the Shaper produces a Mission Intent per the OAuth Profile shape: goal, objects, constraints, success_criteria, mission_expiry, with optional profile extensions.

The construction rules:

• goal is a human-readable restatement of the user’s task. The Shaper SHOULD preserve the user’s meaning and language while normalizing for clarity.
• objects are business-level entities. The Shaper SHOULD resolve referenced entities (e.g., “Q3 financials” → “Q3 2026 financials at Example Corp”) using deployment context where unambiguous, and surface a clarification request where the resolution is uncertain.
• constraints are user-language requirements (“require user approval before sending”; “only the audit-committee folder”). The Shaper SHOULD preserve the user’s expressed constraints verbatim where possible.
• success_criteria are observable outcomes. The Shaper MAY propose criteria implied by the goal when the user has not stated them explicitly. It MUST mark them as synthesized in the trace and surface any criterion that would materially alter authority or completion semantics.
• mission_expiry is the hardest field. The Shaper MAY apply a deployment-approved operational default when the policy identifies that default as non-material for the Mission class. The default MUST be recorded in the trace and included in the consent disclosure. Otherwise, an unstated expiry is a material ambiguity and requires clarification. The Shaper MUST NOT choose an arbitrary long expiry to avoid clarification.

The Shaper MUST NOT claim that an entity, action, or resource exists when the snapshot does not support it. If ambiguity about the user’s reference can be resolved by asking the user, the Shaper requests clarification. If the requested capability is absent or prohibited, the Shaper refuses. In neither case does it create a derivation hint for the unsupported capability.

Tool and Action Binding

When the deployment adopts the Runtime Enforcement Profile Tool Binding Optional Module, the Shaper emits derivation_hints alongside Mission Intent. Each hint ties a proposed action to a specific operation in the supplied snapshot.

For each proposed action, the Shaper:

• Looks up the action in the relevant discovery source (MCP tool catalog, OpenAPI document, registered RAR type, or equivalent).
• Records the source URI or identifier, operation reference, and source digest at lookup time.
• Includes the binding in derivation_hints and records the same data in the Shaper Trace.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "derivation_hints": [
    {
      "resource": "https://finance.example.com/mcp",
      "action": "query_financials",
      "operation_ref": "mcp:tool/query_financials",
      "source_uri": "https://finance.example.com/mcp",
      "source_digest": "sha256:base64url-digest"
    }
  ]
}

The validating server MUST treat these values only as hints. It performs its own freshness-bounded lookup or consults a trusted Resource AS or PDP, checks the referenced source and operation semantics, and derives the authoritative Authority Set or authorization_details. The Shaper Trace is audit evidence, not an admission input.

Unless the source format defines canonicalization, source_digest covers the exact retrieved representation and the snapshot also records its media type. Cross-format semantic equivalence is outside this profile.

A discrepancy between the source snapshot the Shaper observed and the source the validating server observes at derivation time is a drift signal. Under the Tool Binding module, the validating server refuses derivation or requires Mission Expansion according to that module’s rules.

Snapshot-bound hints let the validating server detect drift before approval without relying on confidential post-hoc evidence.

Ambiguity Surfacing

The OAuth Profile requires Shapers to “surface ambiguity rather than guess.” This profile defines the Shaper-orchestrator contract for doing so.

When the Shaper cannot resolve a material field from the input and snapshot together, it returns a clarification result instead of a final Mission Intent. An ambiguity is material when plausible resolutions would change effective authority, audience, subject or tenant binding, consequential side effects, cost or data bounds, required assurance, or Mission lifetime beyond an approved default.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "result": "clarification",
  "clarification_handle": "clr_01HX...",
  "ambiguities": [
    {
      "field": "objects",
      "input_span": "Q3 financials",
      "candidates": [
        { "value": "Q3 2026 financials, Example Corp", "confidence": 0.7 },
        { "value": "Q3 2026 financials, Example Holdings", "confidence": 0.6 }
      ],
      "question": "Which entity should the financials come from?"
    },
    {
      "field": "mission_expiry",
      "input_span": null,
      "candidates": [],
      "question": "When does this task need to be done by?"
    }
  ],
  "partial_intent": {
    "goal": "Prepare the Q3 financial summary",
    "constraints": ["draft only; do not publish"]
  },
  "trace_id": "trace_01HX..."
}

Fields:

• clarification_handle: opaque, unguessable, short-lived identifier the orchestrator passes back on clarify. It binds the prior input, trace, and snapshot identifier and MUST be replay-protected.
• ambiguities: one entry per unresolved question. Each entry names the Mission Intent field, the relevant span of the input (when applicable), candidate resolutions (when the Shaper has them), and a human-readable question for the user.
• partial_intent: only the fields already resolved from input, policy-approved defaults, and snapshot context. It is not a valid Mission Intent while required fields remain unresolved. Unresolved fields are omitted; the Shaper MUST NOT fill them with its highest-confidence candidate.

Candidate confidence values are optional and deployment-specific. They help order choices; they are not calibrated probabilities unless the implementation can substantiate that interpretation.

The orchestrator presents the questions to the user. The user selects a candidate, supplies another value, or declines. The orchestrator calls clarify(handle, user_response, snapshot). The Shaper then returns an intent, another clarification, or a refusal.

A Shaper MUST NOT emit a final Mission Intent with a known material ambiguity. Non-material presentation choices and policy-approved defaults may be resolved without interruption when they are recorded in the trace and disclosed at consent. The user remains the final disambiguator for material choices; the validating server remains responsible for rejecting unresolved or unsafe proposals.

The Shaper Trace

For every extract and clarify invocation, the Shaper produces a Shaper Trace: a structured record of how it reached the result. The deployment retains the trace as confidential evidence and MAY reference it from a Mission audit record through the OAuth Profile’s evidence_id pattern.

A minimum trace includes:

• The discovery sources consulted (URIs, digests, timestamps).
• The raw input or a privacy-preserving reference or keyed digest, according to deployment policy.
• The intermediate decisions: which entity resolutions were made, which actions were bound to which tools, which fields were defaulted, which clarifications were issued and how they were resolved.
• The result type and, when produced, the final Mission Intent.
• The Shaper implementation identifier and version.

The trace is not part of Mission Intent and is not authoritative during admission. A validating server may verify a signed trace as supporting evidence, but it derives authority from validated intent, trusted metadata, registration, and policy. The trace supports replay, regression testing, and forensic review.

A deployment MAY require the trace to be signed by the Shaper’s implementation key when high-assurance audit is needed. A signature authenticates the signer and protects trace integrity; it does not prove that the declared implementation produced correct output. Signature validation rules are deployment-specific in this profile.

Shaper Registration

A deployment MAY register Shapers with the requester they serve. An OAuth profile can express this through client metadata; an AAuth profile can bind it to Agent Provider or agent governance configuration. Registration names:

• The Shaper implementation identifier.
• The Shaper version.
• The Shaper’s signing key (when traces are signed).
• The discovery sources the Shaper is authorized to consume.

Registration is not required by this profile. An unregistered Shaper produces output the validating server treats like any other untrusted proposal. Registration enables a deployment to require vetted Shapers and signed traces for high-assurance Missions; it does not make their proposed authority authoritative.

Operational Requirements

Observability

A conformant Shaper SHOULD emit metrics on:

• Result rate by type (intent, clarification, and refusal).
• Clarification rate per Mission Intent field (which fields trigger the most clarifications).
• Tool-binding success rate when Tool Binding is enabled.
• Discovery-context staleness by source class.

These metrics let deployments tune discovery, identify recurring ambiguity, and detect stale capability data. Metric labels MUST NOT contain raw prompts, sensitive object names, or unbounded user-controlled values.

Error Handling

A Shaper that cannot produce a Mission Intent or a clarification request (the input is outside the Shaper’s domain, the discovery snapshot is unavailable, the deployment policy forbids the proposal) MUST return a structured refusal:

1
2
3
4
5
6
7
8
9

{
  "result": "refusal",
  "refusal": {
    "reason": "out_of_policy",
    "detail": "Mission Intent would request access to resource outside client registration",
    "operator_hint": "Check client registration scope or request the resource owner add it"
  },
  "trace_id": "trace_01HX..."
}

The orchestrator presents a user-appropriate explanation and keeps operator-only detail out of the user response. The Shaper does not produce a degraded Mission Intent under refusal conditions; that would convert failure into an ambiguous proposal.

Discovery-Context Freshness

The Shaper’s discovery snapshot can go stale. Capability catalogs, client registration, and RAR-type metadata all change. A conformant deployment SHOULD:

• Have the aggregator refresh discovery sources before extract, or maintain a TTL-bounded snapshot cache.
• Record source identifiers and digests in both applicable derivation hints and the Shaper Trace.
• Bind each clarification exchange to a snapshot identifier. If relevant discovery data changes before clarify, re-evaluate the partial result against the new snapshot or refuse the stale clarification handle.
• Refuse extraction when the snapshot is older than a deployment-configured freshness limit for high-risk Mission classes.

Worked Example: the Board-Packet Shaper

To make the contract concrete, walk the board-packet scenario used across the series (Part 1, Part 3, Part 4, Part 7) through the Shaper.

The user types: “Prepare the Q3 board packet for the audit committee. Pull financials and the standard board template, then notify Pat once it’s ready.”

The orchestrator calls extract(input, snapshot). The snapshot contains: the agent client’s registered scopes and authorization_details types, RAR Metadata schemas, captured tools/list snapshots from the finance, document, and workflow MCP servers (with source_digest per snapshot), and the deployment policy that requires mission_expiry for any tenant-data-touching Mission.

The Shaper resolves most of the input cleanly: the goal restates the user’s task, the objects are ["Q3 financials", "board packet document", "audit-committee reviewer"], the constraints carry ["confidential classification", "audit-committee-q3-2026 meeting"]. The Shaper binds proposed actions to discovered operations through derivation_hints:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "derivation_hints": [
    {
      "resource": "https://finance.example.com/mcp",
      "action": "query_financials",
      "operation_ref": "mcp:tool/query_financials",
      "source_uri": "https://finance.example.com/mcp",
      "source_digest": "sha256:..."
    },
    {
      "resource": "https://docs.example.com/mcp",
      "action": "create_doc",
      "operation_ref": "mcp:tool/create_doc",
      "source_uri": "https://docs.example.com/mcp",
      "source_digest": "sha256:..."
    },
    {
      "resource": "https://workflow.example.com/mcp",
      "action": "notify_reviewer",
      "operation_ref": "mcp:tool/notify_reviewer",
      "source_uri": "https://workflow.example.com/mcp",
      "source_digest": "sha256:..."
    }
  ]
}

Two fields are ambiguous, and the Shaper refuses to guess:

1. The reviewer’s identity. “Pat” maps to two audit-committee members in the deployment’s contact directory (Pat Williams and Pat Chen). The Shaper does not pick one.
2. mission_expiry. The user did not state a deadline. Deployment policy classifies mission_expiry as material for tenant-data-touching Missions, so the Shaper does not apply a default.

The Shaper returns a clarification:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "result": "clarification",
  "clarification_handle": "clr_01HX...",
  "ambiguities": [
    {
      "field": "objects",
      "input_span": "Pat",
      "candidates": [
        { "value": "Pat Williams (audit-committee)", "confidence": 0.55 },
        { "value": "Pat Chen (audit-committee)", "confidence": 0.45 }
      ],
      "question": "Which Pat on the audit committee?"
    },
    {
      "field": "mission_expiry",
      "input_span": null,
      "candidates": [],
      "question": "When does the packet need to be ready?"
    }
  ],
  "partial_intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "objects": ["Q3 financials", "board packet document"],
    "constraints": ["confidential classification", "audit-committee-q3-2026 meeting"],
    "success_criteria": ["packet drafted", "reviewer notified"]
  },
  "trace_id": "trace_01HX..."
}

The orchestrator surfaces the questions to the user. The user responds: “Pat Williams” and “by October 15, 6pm UTC.”

The orchestrator calls clarify(handle, user_response, snapshot). The Shaper resumes against the still-current snapshot, fills the resolved fields, and emits the final Mission Intent:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "result": "intent",
  "mission_intent": {
    "goal": "Prepare the Q3 board packet for the audit committee",
    "objects": ["Q3 financials", "board packet document", "Pat Williams (audit-committee)"],
    "constraints": ["confidential classification", "audit-committee-q3-2026 meeting"],
    "success_criteria": ["packet drafted", "reviewer notified"],
    "mission_expiry": "2026-10-15T18:00:00Z"
  },
  "derivation_hints": [ "..." ],
  "trace_id": "trace_01HX..."
}

The orchestrator submits this Mission Intent through PAR (OAuth substrate) or through the AAuth-native mission endpoint (AAuth substrate). What the AS/PS does with it is the validating-server admission decision specified in Part 3, Part 4, or Part 5. The Shaper Trace (trace_01HX...) is retained as confidential evidence and may be referenced from the Mission audit record through evidence_id.

What the walkthrough demonstrates: the Shaper surfaced the two material ambiguities rather than guessing, bound proposed actions to source-identified MCP operations, applied no defaults the deployment policy did not approve, and produced both a structured Mission Intent and a replayable trace. None of those are authority; admission still happens at the validating server.

Threat Model

What This Profile Bounds

• Prompt injection at the Shaper. Snapshot bounds, material-ambiguity handling, independent server validation, and the Shaper Trace limit how an injected instruction can become authority and make failures reconstructable. They do not prove the user’s true intent or prevent a model from producing a malicious in-snapshot proposal.
• Capability drift. A tool catalog or API description changes between shaping and authority derivation. Defense: source-bound derivation hints let the validating server compare its current view with the Shaper’s snapshot and apply the Tool Binding module’s refusal or Mission Expansion rules.
• Silent overreach via defaulted fields. A Shaper that defaults mission_expiry to “forever” or objects to “everything” silently broadens the Mission. Defense: required clarification when defaults would exceed deployment policy; explicit refusal when defaults are not within policy.
• Shaper-implementation substitution. An orchestrator swaps in an unapproved Shaper. Registered Shapers and signed traces help only when the validating server receives the implementation identity and verifies its binding under deployment policy. They do not protect a flow in which the orchestrator can omit or replace all Shaper evidence.

What This Profile Does Not Defend Against

• Compromised orchestrator. A compromised orchestrator can lie about the Shaper Trace, present false clarifications to the user, or substitute the Shaper output entirely. The validating-server admission boundary still holds, but the user’s view of the loop is mediated by the orchestrator. Mitigation requires separating the consent UX from the orchestrator (a MAS-rendered consent flow under the Part 5 topology, for instance).
• Misleading discovery sources. A compromised tool catalog, OpenAPI document, or PRM document can cause false bindings. Source authentication, trusted retrieval, and independent validation are required; a digest records content but does not establish that the content is trustworthy.
• Adversarial users. A user can deliberately request authority they should not have. The Shaper can apply proposal bounds, but the validating server remains responsible for enforcing registration, policy, and resource-owner authority.

Privacy

The Shaper handles raw user input. Some of that input is sensitive (personal correspondence, financial data, regulated identifiers). Privacy considerations:

• Raw input in the Shaper Trace. The trace SHOULD avoid storing sensitive raw input. When equality checks are needed, use a deployment-controlled keyed digest or another construction appropriate to the input’s entropy; a plain hash of predictable text can leak through guessing. Replay requires separately retained input under deployment policy.
• Discovery-source identifiers in the trace. Source URIs and internal catalog identifiers may reveal protected resources. The trace inherits the confidentiality of the resources it references.
• Clarification questions. Candidate labels and values MUST be drawn only from discovery context authorized for disclosure to the current user and requester. Client registration alone is not sufficient evidence that a user may learn a resource exists.
• Shaper implementation identity. The Shaper version and signing key in registration are not sensitive, but the deployment of which Shaper handles which client is governance-relevant. Treat it as you would treat client registration metadata.

Conformance

A Shaper claims Profile conformance when it:

• Implements the extract and clarify operations and their three result types.
• Consumes a snapshot containing requester registration or equivalent bounds plus at least one resource-description source.
• Emits source-bound, non-authoritative derivation hints when the deployment adopts Tool Binding.
• Surfaces ambiguity through structured clarification requests rather than silently defaulting or guessing.
• Produces a Shaper Trace per invocation.
• Refuses rather than degrading when input is unsupported, prohibited, or cannot be processed with a valid snapshot.

A Shaper that omits any of the above remains usable with the OAuth Profile but does not claim Shaper Profile conformance.

This profile does not define conformance levels analogous to Part 8’s Conformance Ladder. The Shaper either implements the profile or it does not. A future revision may layer attestation-bound Shapers (verifiable Shaper-implementation identity) and formally-verified Shapers (provable extraction correctness) as higher tiers.

Standards Composition

Gaps and Open Issues

☐ Capability-catalog aggregation format. A Shaper that consumes MCP tool catalogs, OpenAPI documents, PRM, and vendor metadata currently normalizes them through deployment-specific adapters. Should there be a standard aggregate format, or is per-source consumption sufficient?

☐ Clarification protocol on the wire. The structured clarification request defined above is a Shaper-orchestrator contract, not yet a wire protocol. Should a future profile define the orchestrator-to-user clarification surface (a JSON shape that maps cleanly to UI) so multi-Shaper deployments can share a clarification UX?

☐ Shaper Trace canonical format. A minimum shape is described above. A future profile could standardize the JSON shape, the canonicalization rules, and the signing format for high-assurance audit.

☐ Formally-verified Shapers. For regulated industries, “the Shaper does what it claims” may need formal verification, such as proof that it never labels an unsupported operation as discovered. Future profile work.

☐ Attestation-bound Shapers. A Shaper running in an attested execution environment (Confidential Computing, TEEs) could carry attestation evidence with its trace. Composes with RATS PTV and is future work.

☐ Multi-Shaper coordination. Some deployments compose multiple Shapers (an LLM Shaper then a rules-engine Shaper then a form Shaper). The trace pattern supports this through composition records, but a coordination protocol (handoff, partial-extraction transfer, conflict resolution) is not specified.

☐ Adversarial-input benchmark. A future benchmark could exercise prompt injection, capability drift, unsupported references, unsafe defaults, and ambiguous input. What test corpus and scoring rules are needed before such a benchmark can support a meaningful conformance claim?

Standards Path

The natural shape is a single Internet-Draft, draft-mcguinness-oauth-mission-shaper-profile, layered as a companion profile to draft-mcguinness-oauth-mission-bound-minimum-profile. Normative additions:

• The Mission Shaper role definition with extract and clarify operations.
• The discovery-source consumption requirement.
• The tool-and-action binding requirement (when Tool Binding Optional Module is in effect).
• The structured clarification request shape.
• The Shaper Trace minimum schema.
• Substrate-specific optional Shaper registration bindings.
• The refusal shape.

The profile composes with the OAuth Profile without changing any OAuth wire artifact. With the Runtime Enforcement Profile’s Tool Binding Optional Module, source-bound hints expose capability drift before approval. It also composes with the Mission Authority Server Profile: the orchestrator submits the completed proposal through the selected substrate.

Roadmap

Now: Shipping This Profile

Package the Core Shaper contract defined here as draft-mcguinness-oauth-mission-shaper-profile, composed with the OAuth Profile, Runtime Enforcement Profile, and MAS Profile.

Next: Ambiguity and Trace Formats

• Canonical Clarification Request Schema. JSON Schema for the clarification request shape, with rendering hints for UI generation.
• Shaper Trace Format Profile. Canonical JSON form, canonicalization rules, signing format for high-assurance audit.

Later: Attestation and Verification

• Attested Shaper Profile. RATS PTV composition for Shapers running in attested execution environments. Future profile.
• Formally-Verified Shaper Profile. Proof artifacts and verification rules for Shapers with safety properties (no false discovery claims, no silent material ambiguity, reproducible hint generation). Future profile.
• Adversarial Benchmark Suite. Companion test corpus for prompt injection, capability drift, unsupported references, unsafe defaults, and ambiguous input.

Implementation Checklist

A Shaper claims conformance to this profile when:

• Implements extract(input, snapshot) with intent, clarification, and refusal result types.
• Implements clarify(handle, user_response, snapshot) with the same result types and rejects or re-evaluates stale clarification state.
• Consumes requester registration metadata or equivalent substrate-specific authority bounds.
• Consumes at least one relevant resource or capability source, such as RAR Metadata, PRM, an MCP tool catalog, or an OpenAPI document.
• Records discovery source URIs and digests in the Shaper Trace.
• Does not present undiscovered resources or actions as discovered capabilities.
• Surfaces material ambiguity through structured clarification requests; records and discloses any policy-approved defaults.
• When tool-and-action binding is required, emits non-authoritative derivation hints and records matching bindings in the Shaper Trace.
• Returns a structured refusal when the input is out of policy or out of domain; does not produce degraded Mission Intent.
• Produces a Shaper Trace per extract and clarify invocation.
• Avoids sensitive raw input in traces and uses a deployment-approved privacy-preserving reference or keyed digest when needed.

A deployment that requires Shaper registration:

• Binds the Shaper implementation identifier, version, and signing key to the requester through substrate-appropriate metadata.
• Requires Shaper Traces to be signed for high-assurance Mission classes.
• Rejects Mission Intent submissions from unregistered Shapers per deployment policy.

References

• The Mission is the Missing Abstraction for Agents
• Mission-Bound OAuth Profile
• Mission-Bound OAuth Runtime Enforcement Profile
• Least-Privilege MCP Tool Calls Need a Mission
• Mission Authority Server Profile
• Mission Shaping (architecture series)
• RFC 9126: OAuth 2.0 Pushed Authorization Requests
• RFC 9396: OAuth 2.0 Rich Authorization Requests
• RFC 9728: OAuth 2.0 Protected Resource Metadata
• draft-zehavi-oauth-rar-metadata: RAR Type Metadata
• Model Context Protocol
• OpenAPI Specification
• draft-anandakrishnan-rats-ptv-agent-identity: RATS PTV