Network Working Group K. McGuinness Internet-Draft Independent Intended status: Informational 23 June 2026 Expires: 25 December 2026 Mission Intent Shaping for OAuth 2.0 draft-mcguinness-oauth-mission-shaping-latest Abstract Mission-Bound Authorization for OAuth 2.0 defines a Mission Intent and the Authority Set an Authorization Server derives from it, but leaves the step that turns an open-ended task request into a candidate Mission Intent to deployment policy. This document is an OPTIONAL, Informational profile describing the Mission Shaper: a client-side component that turns a user prompt or upstream trigger into a candidate Mission Intent for submission to the issuance profile. It defines the shaper's role and trust boundary, recommended behavior for ambiguity, capability resolution, and refusal, and an audit artifact (Shaping Evidence). It deliberately defines no portable shaping wire protocol and claims no cross-vendor conformance: the shaper proposes only. It never grants authority, never widens authority, and never activates a Mission. A model-based shaper is no exception. Authority is created only by the issuance profile's validation and approval, never by the shaper. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-mission/draft- mcguinness-oauth-mission-shaping.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-shaping/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-mission. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Why this profile is Informational 2. Relationship to the Issuance Profile 3. Conventions and Definitions 4. Shaper Role and Trust Boundary 4.1. Client-side placement 4.2. The shaper does not issue authority 4.3. Untrusted output principle 4.4. The shaper never crosses the trust boundary 4.5. Deployment roles 5. Processing Model 6. Mission Intent Construction 6.1. Authority ceiling and default deny 6.2. Delegation and child work 6.3. Construction guidance 7. Ambiguity Handling 7.1. Clarifications 7.2. Refusal 8. Capability and Resource Resolution 9. Shaping Evidence 9.1. Integrity and the evidence hash 9.2. Illustrative evidence (non-normative) 10. Mission Issuer Handling 11. Composition 11.1. Entering the issuance flow 11.2. Runtime enforcement 12. Exposing Shaping as a Service 13. Security Considerations 13.1. Model output is not authority 13.2. Shaper compromise does not directly grant authority 13.3. Prompt injection and untrusted content 13.4. Silent broadening and stale capability sources 13.5. Shaper-to-client integrity in a multi-process client 13.6. Confidentiality of prompt content 14. Privacy Considerations 15. IANA Considerations 16. References 16.1. Normative References 16.2. Informative References Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") makes a Mission a first-class authorization artifact. It defines how a Mission Intent is submitted, how an Authorization Server derives an Authority Set, how an Approver consents, and how issued tokens are bound to the approved Mission. It does not standardize how a deployment turns an open-ended task request, such as "resolve this billing dispute," into a Mission Intent with resources, actions, constraints, context, and expiry. This document describes that missing shaping step. A *Mission Shaper* is a client-side component that produces a candidate Mission Intent before the issuance profile's approval flow begins. The shaper can be a deterministic rules engine, a form, an LLM-assisted function, or a workflow. Whatever its implementation, its output is only a proposal: the Authorization Server validates and narrows it, the Approver or governing policy approves it, and only the resulting approved Mission carries authority. The purpose of this profile is to make shaping auditable and fail closed. When a task request is ambiguous, the shaper does not silently invent authority: it narrows to a defensible candidate, asks for clarification, or refuses to shape. When a capability or resource is unknown, the shaper records that fact rather than treating natural language as authority to create it. When the shaper uses model output, that output is evidence for review, not an entitlement decision. 1.1. Why this profile is Informational This document is Informational by deliberate choice, not by omission. Client-side prompt processing is loosely shaped by deployment policy, language-model choice, and product ergonomics; no two deployments will agree on the transformation from a request to a Mission Intent. A Standards Track wire protocol for that transformation would overclaim, because the interoperable surface is not the transformation but its result: the Mission Intent, which the issuance profile already defines and validates on the wire. What is stable, and what this profile records, is the shaper's role inside the trust model and the behaviors a sound implementation follows. This profile therefore defines role boundaries, trust posture, and recommended behavior; it does not define a portable shaping protocol, register a media type or claim name, or define a conformance test suite. A deployment that exposes shaping as a network service MAY do so (Section 12), but that surface is a local implementation detail, not an interoperability contract. 2. Relationship to the Issuance Profile This document is OPTIONAL and layered on [I-D.draft-mcguinness-oauth-mission]. A deployment that accepts only hand-authored Mission Intent values is fully conformant to the issuance profile and is unaffected by this document. This document describes: * the shaper's role and trust boundary (Section 4); * a processing model and recommended Mission Intent construction (Section 5, Section 6); * recommended ambiguity, refusal, and capability-resolution behavior (Section 7, Section 8); * Shaping Evidence, an audit artifact (Section 9); and * how a shaped proposal enters the issuance flow (Section 11). This document does not define a new OAuth grant type, a new access token format, a policy language, a runtime authorization decision API, or a required shaping endpoint. The approved Mission and its tokens remain those of the issuance profile. It uses the terms Mission, Mission Intent, Authority Set, Mission Issuer, Approver, and Authorization Server as defined by [I-D.draft-mcguinness-oauth-mission]. Where this document refers to "the issuance profile" without a section, it means that document as a whole. 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The normative keywords in this document describe recommended shaper and Mission Issuer behavior. They do not establish a conformance class: this profile is Informational (Section 1.1). All JSON shown in this document is non-normative and illustrative; the member descriptions in the surrounding text are authoritative. This document uses JSON [RFC8259] as the data model for the illustrative objects, and JCS [RFC8785] where a hash is computed over Shaping Evidence (Section 9). This document additionally uses: Mission Shaper (or "shaper"): A client-side component that produces a candidate Mission Intent from a task request and supporting context. A Mission Shaper does not grant authority. Mission requester: The component or user that supplies the task request to be shaped. Mission Intent proposal: The candidate mission_intent object the shaper emits for validation and approval under the issuance profile. Capability source: A resource-owning catalog, metadata endpoint, policy service, or other source the shaper consults to resolve candidate resources and actions. Shaping Evidence: The record of inputs, inferences, policy decisions, unresolved ambiguities, and capability-resolution facts that produced the Mission Intent proposal. Audit material, not authority. 4. Shaper Role and Trust Boundary The Mission Shaper occupies a single, narrow role. This section defines that role and the trust boundary the shaper does not cross. It is the stable core of this profile. 4.1. Client-side placement The shaper executes on the client side of the Mission-Bound Authorization trust boundary: in the same trust domain as the requesting client that will submit the Mission Intent. Its output is consumed by that client and submitted to the Mission Issuer through the issuance profile's mission_intent submission (Section 11). The shaper is not a separate principal. It has no identity of its own to the Mission Issuer; the Mission Issuer sees the requesting client. A deployment MAY factor the shaper into its own process or network service for engineering reasons (Section 12), but doing so does not make the shaper a principal to the Authorization Server and does not move it across the trust boundary: it remains client-side machinery that produces an untrusted proposal. 4.2. The shaper does not issue authority The Mission Shaper MUST NOT issue, derive, or certify authority of any kind. It produces a Mission Intent proposal. That proposal is, by the issuance profile's definition, untrusted client input until the Mission Issuer validates and narrows it and binds authority at the approval event. The shaper's output therefore has no authority implications until the Mission Issuer approves a Mission from it and derives an Authority Set. A shaper that signs its output, attaches an authority assertion, emits a credential, or otherwise behaves as a credential issuer is acting outside the role this profile describes and is NOT RECOMMENDED. A deployment MAY integrity-protect shaper output for client-internal reasons (for example, to detect tampering between the shaper and the submission step in a multi-process client, Section 13.5), but that protection has no authority semantics at the Mission Issuer and MUST NOT be relied upon by anything beyond the client. 4.3. Untrusted output principle A Mission Issuer that receives a Mission Intent MUST treat it as untrusted input under the issuance profile's validation rules. Nothing in this profile changes that, and a shaper SHOULD NOT structure its output to imply otherwise. In particular, a shaper MUST NOT emit, in the Mission Intent proposal, members that mimic Mission Issuer outputs. The proposal MUST NOT carry mission.id, intent_hash, authority_hash, an Authority Set, a lifecycle state, or approving-principal evidence. Those values are produced by the Mission Issuer on the Mission record at and after the approval event, never by the client ([I-D.draft-mcguinness-oauth-mission]). A shaper that emits them is either confused about its role or attempting to mislead an auditor, and a Mission Issuer MUST ignore any such member presented in a Mission Intent. 4.4. The shaper never crosses the trust boundary The trust boundary separates the client, where the shaper lives, from the Mission Issuer, where the Mission Intent is validated and the Authority Set is created. Crossing that boundary is a Mission Issuer action. The shaper produces an input; the client transmits the input; the Mission Issuer decides what to do with it. The shaper does not initiate the submission, does not invoke the OAuth Pushed Authorization Request or Authorization Endpoint, does not select the recipient Mission Issuer on its own authority, and does not attest to the submission's correctness on the Mission Issuer's behalf. 4.5. Deployment roles This profile separates four roles that implementations often collapse: Mission requester: Supplies the task request to be shaped. Mission Shaper: Produces a Mission Intent proposal and Shaping Evidence. Not authoritative for policy or consent. Mission Issuer: The Authorization Server that validates the proposal, derives the Authority Set, records the approval event, and issues Mission-bound credentials under [I-D.draft-mcguinness-oauth-mission]. Capability source: A catalog, metadata endpoint, or policy service the shaper consults to resolve candidate resources and actions. A deployment MAY co-locate these roles, but it SHOULD preserve the authority boundary: shaping produces a proposal, issuance creates an approved Mission, and runtime enforcement permits or denies actions. 5. Processing Model A sound shaper processes a request in this order: 1. Normalize and classify the caller-supplied task input. 2. Distinguish facts supplied by the requester, facts supplied by trusted context, and facts inferred by the shaper. 3. Resolve candidate resources and actions against capability sources (Section 8). 4. Apply deployment shaping policy, including authority ceilings and risk classification. 5. Detect material ambiguity (Section 7). 6. Produce an outcome: a proposal, a request for clarification, or a refusal. 7. Record Shaping Evidence and, for a proposal, optionally a shaping_evidence_hash (Section 9). The shaper SHOULD NOT skip capability resolution merely because a task is natural-language plausible. A request such as "email the customer" does not identify which mailbox, sender, recipient, template, or data source is allowed unless the deployment's capability sources or policy resolve those details. 6. Mission Intent Construction A Mission Intent proposal MUST satisfy the syntactic requirements of the issuance profile's mission_intent object ([I-D.draft-mcguinness-oauth-mission]): a goal, resources with their actions and constraints, mission_expiry, and optional purpose and context. It MUST be bounded enough for the Mission Issuer to derive an Authority Set without interpreting natural language as authority. The proposal MUST NOT include a resource, action, or constraint merely because the task text implies it might be useful. The shaper MUST have a resolution basis under Section 8, or it MUST produce a clarification request or a refusal. 6.1. Authority ceiling and default deny A shaper MUST apply a default-deny posture. The Mission Intent proposal contains only resources, actions, constraints, and delegation rights that have a positive basis in the request, context, capability source, and shaping policy. The shaper MUST NOT include a broad resource or action class as a convenience fallback for unresolved detail. When a deployment or caller supplies an authority ceiling, the proposal MUST be a subset of it. If the task cannot be completed within that ceiling, the shaper MUST request clarification or refuse; it MUST NOT silently drop necessary authority while emitting a proposal that appears complete, unless Shaping Evidence records the excluded authority and the outcome clearly indicates the proposal may not satisfy the task. The Mission Issuer remains responsible for enforcing its own ceiling even when no caller ceiling is present. 6.2. Delegation and child work If the task implies use of sub-agents, background workers, or delegated execution, the proposal MUST either include delegation constraints in the relevant authority entry under [I-D.draft-mcguinness-oauth-mission], state that delegation is excluded, or request clarification. Delegation MUST NOT be inferred from the existence of a task graph or an agent harness: a child actor needs explicit authority, not session ancestry. 6.3. Construction guidance The following maps a prompt or trigger onto the Mission Intent fields. It is guidance, not a normative algorithm; the SHOULD/MUST points are called out. +================+=============================+====================+ | Field | Guidance | Avoid | +================+=============================+====================+ | goal | Concise user-readable | SHOULD NOT quote | | | summary in the form the | verbatim prompt | | | Approver sees at consent; | text that | | | preserve the user's framing | contains | | | so the disclosure matches | instructions or | | | their understanding. | commands | | | | (Section 13.3). | +----------------+-----------------------------+--------------------+ | resources | Enumerate the resources, | SHOULD NOT widen | | | datasets, tools, or domains | beyond what the | | | the prompt referenced; | prompt | | | prefer canonical | referenced; "for | | | identifiers, falling back | convenience" | | | to a label only when none | enlarges approved | | | resolves. | authority. | +----------------+-----------------------------+--------------------+ | actions | Resolve each action against | MUST NOT propose | | | a capability source | an action with no | | | (Section 8). | resolution basis. | +----------------+-----------------------------+--------------------+ | constraints | Reflect bounds the user | MUST NOT silently | | | expressed plus deployment- | drop a user- | | | policy constraints always | expressed | | | applied, so the Approver | constraint the | | | sees the full bound set. | shaper cannot | | | | map; clarify or | | | | refuse instead. | +----------------+-----------------------------+--------------------+ | mission_expiry | The smallest ceiling that | Don't request the | | | lets the task complete; if | maximum the | | | the prompt names no bound, | Mission Issuer | | | apply a conservative | allows; the | | | deployment default. | Issuer MAY narrow | | | | further. | +----------------+-----------------------------+--------------------+ | purpose | If the client has | SHOULD NOT invent | | | registered purposes, select | a new purpose | | | the closest registered URI. | URI. | +----------------+-----------------------------+--------------------+ | context | Emit only context keys the | Unknown keys | | | deployment recognizes. | force the Mission | | | | Issuer to reject | | | | the Intent. | +----------------+-----------------------------+--------------------+ Table 1 7. Ambiguity Handling A shaper MUST classify material ambiguity. Ambiguity is material when choosing one interpretation over another would change the Authority Set, the action class, the actor allowed to exercise it, the expiry, or the risk posture. For material ambiguity, the shaper MUST do one of: 1. request clarification; 2. emit a narrower proposal that excludes the ambiguous authority and records the exclusion in Shaping Evidence; or 3. refuse with a reason. The shaper MUST NOT silently choose the broader interpretation. If a deployment permits policy-based default narrowing, Shaping Evidence MUST record the policy rule that authorized that narrowing. Requesting clarification is not approval. The user's response is incorporated into the Mission Intent; the Mission Issuer still validates, narrows, and renders the consent disclosure for binding approval. A shaper MUST NOT treat answered clarifications as a reason to skip the Mission Issuer consent step: the shaper is not the Approver's agent for consent. 7.1. Clarifications A clarification SHOULD be phrased so the requester can understand the authority consequence of each answer. "Need more scope?" is not sufficient; "May this Mission read invoices for customer 5678 in addition to customer 1234?" is. A clarification SHOULD identify the authority consequence of each offered choice and SHOULD state what the shaper will do if it is left unanswered (refuse, narrow, or wait). 7.2. Refusal There are inputs a shaper SHOULD refuse to shape. Refusal is a shaper-internal decision; it requires no Mission Issuer involvement, and this profile defines no wire-level refusal error. A shaper SHOULD refuse when: * it cannot produce a Mission Intent for the task class (unsupported_task); * a requested resource or action cannot be resolved to a capability source (unresolved_resource, unresolved_action); * the task requires authority outside the deployment or caller authority ceiling (outside_authority_ceiling); * deployment policy prohibits shaping the task (policy_prohibited); * material ambiguity remains and policy requires refusal rather than clarification (material_ambiguity); or * the request includes adversarial, conflicting, or untrusted content that prevents a defensible proposal (unsafe_to_shape). The reason strings above are recommended labels for Shaping Evidence and for surfacing a refusal to the requesting client; a deployment MAY define additional labels but SHOULD NOT reuse these with different meaning. A shaper SHOULD NOT refuse merely because the requested authority is broad, or because the Authority Set the Mission Issuer would derive looks expensive. Breadth is the Mission Issuer's decision and the Approver's; cost is a runtime concern. Refusing on those grounds substitutes the shaper's judgment for the Approver's. 8. Capability and Resource Resolution Before proposing a resource or action, the shaper MUST establish a resolution basis. The basis is one of: catalog: Resolved from a catalog, metadata endpoint, OpenAPI description, MCP tool catalog, or equivalent source. policy: Selected by a deployment policy rule. user_supplied_exact: The requester supplied a concrete resource identifier and the shaper verified it is admissible for shaping. authority_source: A resource-owning system or Authorization Server supplied an allowed resource/action projection for this task. The shaper MUST record the resolution basis in Shaping Evidence. A model-generated capability name with none of these bases is not resolved, and the shaper MUST treat it as unresolved (Section 7.2). For each resolved capability, Shaping Evidence SHOULD record what was requested, what it resolved to, the basis, the source consulted (for catalog and authority_source), and, where available, a digest over the source representation so later approval and runtime enforcement can detect drift. A confidence value, if recorded, is audit evidence only and MUST NOT be treated as authority. 9. Shaping Evidence Shaping Evidence records how a proposal was produced. It is audit material: it does not grant authority and MUST NOT be used by a Resource Server or Policy Decision Point to permit an action. This profile defines no required schema, media type, or transport for it; the following members are RECOMMENDED content. shaper_id: A string identifying the shaper. shaper_version: A string identifying the shaper implementation, model, policy bundle, or workflow version. input_digest: A digest over the shaping request, excluding fields deployment policy marks as non-retained. user_supplied_facts: Facts copied from the request. inferred_facts: Facts the shaper inferred, each with its supporting evidence and whether human confirmation is required. policy_decisions: Policy rules applied during shaping. capability_resolutions: Each resource or action and its resolution basis (Section 8). ambiguities: Material ambiguities and how each was handled. excluded_authority: Plausible authority the shaper deliberately excluded. model_trace: Model prompts, outputs, or tool calls used during shaping. When retained it MUST be treated as sensitive audit data (Section 14) and MUST NOT be rendered as authority. 9.1. Integrity and the evidence hash A deployment MAY bind a proposal to its evidence so the Mission record can cite how the proposal was produced. When it does: * shaping_evidence_hash is a string in the integrity-anchor form of [I-D.draft-mcguinness-oauth-mission], computed over the JCS [RFC8785] canonical bytes of the Shaping Evidence object. It is an audit commitment only. * A deployment MAY instead, or in addition, carry an integrity envelope over the Shaping Evidence, for example a JWS [RFC7515] Compact Serialization over the JCS canonical bytes of the evidence with the envelope member removed. Neither the hash nor the envelope confers authority. A Resource Server or PDP MUST NOT treat a shaping evidence hash as proof of authority. 9.2. Illustrative evidence (non-normative) { "shaper_id": "mission-shaper.example.com", "shaper_version": "policy-bundle-2026-06-30", "input_digest": "sha-256:InP9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4", "user_supplied_facts": [ "support ticket 456", "customer 1234" ], "capability_resolutions": [ { "requested": "invoice.read", "resolved": "invoice.read", "basis": "catalog", "source_uri": "https://billing.example.com/.well-known/tools" } ] } 10. Mission Issuer Handling A Mission Issuer that receives a shaped Mission Intent MAY use a shaping_evidence_hash and Shaping Evidence as input to approval and audit, but MUST independently validate the Mission Intent under [I-D.draft-mcguinness-oauth-mission]. The Mission Issuer MUST NOT approve a Mission solely because a shaper produced it. It MUST derive an Authority Set under issuer policy and MUST refuse, narrow, or require approval as the issuance profile requires. If the Mission Issuer records a shaping_evidence_hash on the Mission record, it MUST treat that value as an audit commitment only. A Mission Issuer SHOULD refuse a stale shaped proposal: a deployment that conveys a freshness bound with the proposal (for example, an expiry, or an evidence source digest that no longer matches) SHOULD re-shape rather than submit a proposal built against a capability catalog or policy version that has since changed. 11. Composition 11.1. Entering the issuance flow Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] defines a mission_intent parameter carried inside a Pushed Authorization Request (PAR) [RFC9126]. The Mission Intent the shaper produced is the value of that parameter. The Authorization Server [RFC6749] acts as the Mission Issuer: it validates, narrows, renders the consent disclosure, records the approval event, and derives an Authority Set ([I-D.draft-mcguinness-oauth-mission]). The shaper does not invoke the PAR endpoint or the Authorization Endpoint and does not handle the authorization response. Those are requesting-client responsibilities (Section 4.4). The shaper hands its output to the requesting client, which performs the OAuth flow and MAY also convey a shaping_evidence_hash as deployment extension data so the Mission record can cite the evidence. Conveying it does not require the Mission Issuer to trust the shaper. 11.2. Runtime enforcement Mission-Bound Runtime Enforcement for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission-runtime] defines the per-action PDP and PEP contract. The runtime does not consume shaper output. It consumes the Mission Intent and the Authority Set on the Mission record, both produced by the Mission Issuer, not by the shaper. A runtime that reads Shaping Evidence for an authorization decision is misusing it. 12. Exposing Shaping as a Service This profile requires no shaping endpoint, and a shaper is a client- side function (Section 4.1). A deployment that nevertheless factors shaping into a network service for engineering reasons MAY expose it over HTTPS. The request and response shapes such a service uses are a local implementation detail, not an interoperability contract, and this section is non-normative. A request typically conveys the task (free text and/or structured fields), the subject and agent on whose behalf the Mission would run, deployment context, an optional authority ceiling, and the capability sources the shaper may consult. A response typically conveys an outcome — a Mission Intent proposal, a set of clarifications, or a refusal — together with Shaping Evidence and, for a proposal, an optional shaping_evidence_hash. A deployment that publishes such an endpoint through its metadata might use fields such as mission_shaping_endpoint and mission_shaping_profiles_supported. Such an endpoint MUST be authenticated when it can reveal sensitive task, tenant, or resource information; an anonymous shaping endpoint is appropriate only for public, non-sensitive tasks. Exposing the shaper this way does not change its role: it remains client-side machinery that produces an untrusted proposal (Section 4), and it is not a principal to the Authorization Server. 13. Security Considerations The shaper sits at the prompt-to-Intent boundary. Its security properties follow from the role contract: the shaper proposes, and authority is created only at the Mission Issuer's approval event. 13.1. Model output is not authority A model-based shaper can draft a Mission Intent, but the model MUST NOT be the authority that grants or widens access. The approved Mission is created only through the issuance profile's validation and approval. A deployment that lets a model's proposal become active without validation and approval is not following this profile. A model-based shaper inherits its model's failure modes — hallucinated resources, fabricated constraints, inconsistent paraphrase, sensitivity to small input perturbations — and SHOULD record the model identifier and version in Shaping Evidence so failures can be attributed. 13.2. Shaper compromise does not directly grant authority A compromised shaper can produce arbitrary Mission Intent and can suppress ambiguity, but it cannot, by itself, cause the Mission Issuer to approve that Intent. A compromised shaper can cause spurious proposals to be submitted, mis-shape Intent so the Approver approves a task different from the one intended, or leak prompts through shaper-local logging. It cannot issue credentials, set or change Mission lifecycle state, bypass the approval event, or cause a Resource Server to act without Mission Issuer-issued authority. The Mission Issuer remains the enforcement point for approval and MUST validate and narrow the proposal; deployments SHOULD monitor shaper versions and evidence for anomalous broadening. 13.3. Prompt injection and untrusted content The shaper's input is, by assumption, partially or wholly attacker- influenceable: prompts may contain pasted content, content the user was tricked into typing, or content arriving through a non-prompt trigger such as an inbound email or webhook. Task text, tickets, documents, tool descriptions, and catalog metadata can all carry instructions aimed at the shaper. Concrete threats include attempts to expand resources beyond what the user requested, to push mission_expiry past deployment policy, to suppress a stated constraint, or to select a purpose the user did not choose. Mitigations the shaper SHOULD apply: 1. Treat all prompt and attachment content as untrusted data, not as instructions to the shaper. Do not let it alter shaper policy or override deployment defaults. 2. Apply the refusal behavior of Section 7.2 when the input exhibits injection patterns. 3. Do not echo verbatim prompt-derived instruction text into goal or constraints the Approver will read; paraphrase, or quote with clear attribution, but do not present injected content as if it came from the user. 4. Use the capability sources' resolved vocabulary as a hard allowlist (Section 8); do not infer new authority types from the prompt. 5. Record the prompt, the parsed intent, and the chosen defaults in Shaping Evidence so an auditor can reconstruct what the shaper saw. Injection cannot be fully eliminated at the shaper. The defense in depth is the Approver seeing the Mission Intent in a consent disclosure rendered by the Mission Issuer, not by the shaper, before authority is bound. A shaper that builds Intent truthfully and a Mission Issuer that renders disclosure truthfully together make injection visible at the approval step. 13.4. Silent broadening and stale capability sources The primary failure mode is silent broadening: a vague goal becomes a wide Authority Set. The ambiguity rules of Section 7 are intended to fail closed by requiring clarification, narrowing, or refusal. A proposal shaped against an old catalog can also resolve the wrong capability; capability resolutions SHOULD record source digests (Section 8) and deployments SHOULD re-shape when catalog data is volatile, so approval and runtime enforcement can detect drift. 13.5. Shaper-to-client integrity in a multi-process client In a client where the shaper runs in a different process or machine from the OAuth submission code, the shaper-to-submission step is an in-client boundary. An attacker between the two could alter the Mission Intent before submission. The Mission Issuer will still validate the altered Intent and render its consent disclosure, so the Approver remains the final line of defense, but the altered Intent will not match what the shaper actually produced. A deployment MAY apply client-internal integrity protection between shaper output and the submission code (a client-local signature, a process-isolated channel). Such protection has no semantics at the Mission Issuer and MUST NOT be carried into the Mission Intent as if it did (Section 4.2). 13.6. Confidentiality of prompt content Prompts may carry sensitive content (personal data, business data, free-form expression). The shaper SHOULD apply the requesting client's data-handling policy to prompt content, including Shaping Evidence. Evidence transmitted outside the client's trust domain (for example, shipped to a centralized audit store) SHOULD carry the same controls the client applies to any other prompt or user-content log. 14. Privacy Considerations The shaper sits where a user's natural-language prompt — which may carry personal data, business-confidential content, or free-form expression — becomes structured artifacts. The privacy surface follows from where that content flows. The shaper copies or paraphrases prompt content into goal, resources, constraints, and context, which the Mission Issuer renders in a consent disclosure the Approver reads and which may be retained in the Mission record. A shaper SHOULD carry into these fields only the content needed to describe the task, SHOULD NOT widen resources or echo unrelated prompt content (Section 6), and SHOULD avoid copying third-party personal data into goal where a non-identifying description suffices. Shaping Evidence aggregates the prompt, applied defaults, inferences, and model outputs into one artifact and is therefore a concentrated sink of sensitive content. Deployments SHOULD minimize retained raw task text, prefer digests where full content is not required for audit, apply access controls equivalent to those used for Mission records, and be able to produce a redacted evidence record for audiences that need the transformation provenance but not the raw prompt. The shaper introduces no identifier of its own and is not a separate principal to the Mission Issuer (Section 4). It therefore adds no cross-party correlation surface beyond the prompt content it processes and the requesting-client identity the Mission Issuer already sees. 15. IANA Considerations This document has no IANA actions. The Mission Intent Shaping profile is Informational; it registers no media type, claim name, endpoint name, parameter name, error code, metadata field, or namespace URI. A future portable shaping protocol, if specified, would be a separate document and would carry its own registrations there. 16. References 16.1. Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 16.2. Informative References [I-D.draft-mcguinness-oauth-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement for OAuth 2.0", Work in Progress, Internet-Draft, draft- mcguinness-oauth-mission-runtime, 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . Acknowledgments This document is part of the Mission-Bound Authorization for OAuth 2.0 set and describes the shaping layer that precedes Mission issuance. It builds on Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] and complements Mission-Bound Runtime Enforcement for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission-runtime]. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com