---
title: "Least-Privilege MCP Tool Calls Need a Mission"
date: "2026-07-22T09:00:00-07:00"
lastmod: "2026-07-22T09:00:00-07:00"
description: "Least-privilege MCP tool calls can carry narrow authority in a token or decide each call at the resource. Both work for one call. Both fragment under fan-out. A Mission supplies the durable approved task both models project from."
summary: "The least-privilege MCP series ends on a gap: token-side and resource-side authorization both work per call, and neither names the task the user approved. This essay applies Mission-Bound Authorization at the MCP boundary. The Mission is the durable approved task, tokens and PDP decisions are projections of it, tool discovery and invocation and approval line up against it, expansion routes through a fresh approval, and audit joins on one identifier. A denial is traced end to end to show the whole spine working."
slug: "least-privilege-mcp-tool-calls-need-a-mission"
tags:
  - "OAuth"
  - "Authorization"
  - "MCP"
  - "AuthZEN"
  - "Fine-Grained Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "RAR"
---


{{< tldr >}}

- **The application.** Two architectures authorize least-privilege MCP tool calls: token-side and resource-side. Both fragment under fan-out because neither carries the durable task context. This essay applies the [Mission-Bound Authorization](/series/designing-mission-bound-authorization/) architecture to that gap, making the approved task an explicit protocol object both models project from. It rides alongside the handbook as the architecture chapter's applied companion, with the [Building Mission-Bound Authorization](/series/building-mission-bound-authorization/) chapter carrying the wire depth it applies.
- **Read the foundations first.** The two models, the tool boundary, and the per-call standards (AuthZEN, COAZ, ARAP) are the subject of the standalone [Least-Privilege MCP series](/series/least-privilege-mcp/), which ends on [the gap neither model closes](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/#the-gap-neither-model-closes). That series does not depend on this essay. This essay is the Mission series' answer to the gap it names.
- **What this essay adds.** What a Mission fixes for both models, the pipeline with a Mission in scope, the lethal-trifecta posture, the AAuth comparison, and a denial traced end to end.
- **Out of scope here.** The issuance core's wire detail ([The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/)) and the runtime contract's mechanics ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/)). This essay applies them, not redefines them.
- **Specs (editor's copies).** [Mission-Bound Authorization for OAuth 2.0](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html), [Mission-Bound Runtime Enforcement](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-runtime.html), [Runtime Enforcement: AuthZEN Profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html).

**Reading paths in this essay.**

- *MCP server developer (~15 min):* [The two models, in brief](#the-two-models-in-brief) → [What a Mission fixes](#what-a-mission-fixes) → [The pipeline with a Mission in scope](#the-pipeline-with-a-mission-in-scope) → [Tracing a denial end to end](#tracing-a-denial-end-to-end) → [Where to start building](#where-to-start-building).
- *Architecture reviewer (~10 min):* [The two models, in brief](#the-two-models-in-brief) → [What a Mission fixes](#what-a-mission-fixes) → [Does a Mission violate the lethal trifecta?](#does-a-mission-violate-the-lethal-trifecta).

{{< /tldr >}}

# The two models, in brief

An agent preparing a board packet has to make a sequence of tool calls across three MCP servers, each behind its own authorization domain: `query_financials` on a finance server, `create_doc` on a document server, `notify_reviewer` on a workflow server. The user approved the task before the agent started ("prepare the Q3 board packet for the audit committee"), but in today's systems that approval is application state, not protocol authority. Each call still has to be authorized at the right grain.

There are two natural ways to do that, and the [Least-Privilege MCP series](/series/least-privilege-mcp/) walks both in full. **Token-side authorization** carries the authority in the credential. The agent discovers what the server requires, asks the right Authorization Server for a token narrowed to the action, and presents it. **Resource-side authorization** keeps the decision at the resource. The MCP server is the Policy Enforcement Point, asks a PDP whether this exact call is allowed, and uses a requestable denial when the missing authority can be requested. [Least-Privilege MCP Tool Calls](/notes/least-privilege-mcp-tool-calls/) compares the models, and [Closing the Gaps](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/) covers the standards that make per-call decisions interoperable: AuthZEN for the decision shape, COAZ for the MCP mapping, ARAP for turning a denial into a governed request.

Both authorize one call well. Both share one blind spot. Tokens describe what authority a credential carries. PDP decisions describe whether a specific call is permitted. Neither describes the task the user actually approved. So once the task fans out across three servers and three authorization domains, the authority for it fragments. The user sees repeated approval prompts for fragments of one task. The agent accumulates narrow tokens or pending requests with no shared lifecycle. Audit joins fall back to timestamps and log correlation, and [correlation is not governance](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/#why-correlation-is-not-governance). The protocol stack has no standard object that names the task. That is the gap this essay closes.

A Mission makes that governed task an explicit protocol object both models can bind to, while each MCP server or Resource AS keeps its own domain semantics and local policy. What that buys, and how it is owned, derived, and enforced, is the rest of this essay.

# Board packet before and after

The board-packet example is the whole problem in miniature.

| Step | Without a Mission | With a Mission |
| --- | --- | --- |
| Finance read | Fresh token request or PDP approval for `query_financials`. Approval prompt has to restate the task context | Checked against the approved board-packet Mission. Finance system applies its own domain policy |
| Document creation | Separate AS/PDP decision for `create_doc`, with no protocol-level link to the finance read | Token or PDP decision carries the same Mission binding. Document system sees the same task context |
| Reviewer notification | Another isolated approval for `notify_reviewer`. Audit has to stitch by time, user, and client | Workflow action is evaluated as another projection of the same Mission |
| Scope expansion | New ad-hoc approval if the agent needs data outside the task | A fresh approval creates a successor Mission with lineage back to the original |
| Kill switch | Finding and revoking every narrow token independently | Revoking the Mission stops all further derivation at once |
| Audit | Three unrelated decisions across three systems | One task spine joined by `mission.id` and `mission.issuer` |

That is the standardization point. Least privilege per call is necessary, but it is not sufficient for agent tasks. The calls need a common object to point back to.

# What a Mission fixes

A Mission is that missing object. It is the durable, approval-backed governance object for the task, held at the Authorization Server that approved it and identified everywhere by `mission.id` and `mission.issuer`. Tokens and PDP decisions carry or resolve a binding to that record. As [the Mission series](/series/designing-mission-bound-authorization/) argues, the missing abstraction is not another credential or evaluation point. It is the governed task those artifacts serve. The precise definitions live in the [Reference](/notes/mission-based-authorization-field-reference/), and this task is its running example.

The flow is the Mission series' spine applied at the MCP boundary. A shaper turns the prompt into a structured Mission Intent and proposes it through Pushed Authorization Requests ([From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/)). The Authorization Server validates the Intent, derives the Authority Set the user will be asked to approve, and renders that derived set for consent. On approval it records the Mission, committed by `intent_hash` and `authority_hash`, and issues Mission-bound tokens carrying the `mission` claim ([The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/)).

For the board-packet task, the shaper submits this Mission Intent at PAR:

```json
{
  "goal": "Prepare the Q3 board packet for the audit committee",
  "purpose": "urn:example:mission:board-packet",
  "resources": ["https://finance.example.com",
    "https://docs.example.com",
    "https://workflow.example.com"],
  "constraints": ["Q3 2026", "Example Corp", "confidential"],
  "expires_at": "2026-10-15T18:00:00Z"
}
```

Note what the shaper does not author. It proposes resources and free-text constraints, and any candidate authority it offers rides in the Intent's optional `proposed_authority` member (absent here) as untrusted input the Authorization Server only narrows. The consented Authority Set is always the AS's derivation, never the proposal itself, and [shaping proposes only](/notes/from-a-request-to-an-approved-mission/#shaping-proposes-only) carries the member mechanics. The AS derives the `authorization_details` from the approved Mission and returns the derived array alongside the access token:

```json
[
  {
    "type": "mission_resource_access",
    "resource": "https://finance.example.com",
    "actions": ["query_financials"],
    "constraints": { "period": "Q3 2026" }
  },
  {
    "type": "mission_resource_access",
    "resource": "https://docs.example.com",
    "actions": ["create_doc"],
    "constraints": { "template": "board-packet" }
  },
  {
    "type": "mission_resource_access",
    "resource": "https://workflow.example.com",
    "actions": ["notify_reviewer"],
    "constraints": { "group": "audit-committee" }
  }
]
```

Read the two exhibits together and the trust boundary is visible in the bytes. "Q3 2026" is free text in the Intent and structure in the derived entry, and no function parsed one into the other: the words informed the human-authored derivation rule, or a structured `proposed_authority` candidate the AS only narrowed, and the Approver's check that the structure matches the words is what joins them. [The derivation policy, concretely](/notes/adopting-mission-bound-authorization/#the-derivation-policy-concretely) carries that boundary in full.

The approved Mission Intent itself stays on the Mission record at `mission.issuer`. Consumers learn Mission state through introspection, the Mission Status operation, or Lifecycle Signals ([Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/)), never from an unauthenticated request parameter.

The Mission fixes both models because it separates concerns they otherwise conflate. **The Authorization Server owns the user-approved task, its integrity anchors, and its lifecycle.** **The Authority Set is the typed maximum authority derived from that task.** **Each MCP server or Resource Server owns the domain semantics and local policy for its tools.** The validating AS does not have to implement every resource's policy engine. It validates the Mission Intent against client registration and deployment policy and derives authority only for resources it recognizes. The finance, document, and workflow systems remain authoritative for local resource policy. This division does not remove the ontology problem [Least-Privilege MCP Tool Calls](/notes/least-privilege-mcp-tool-calls/#the-ontology-problem) names. It makes the boundary and the validation responsibility explicit.

The Mission Intent does not need to carry exact MCP tool names. The Authority Set can describe actions at a grain the AS and the Resource Server can jointly validate, and the Resource Server still maps approved authority to concrete arguments and local policy. Where a deployment wants the approved action pinned to a specific capability, the runtime layer binds it to the source-content digest recorded at derivation, such as an operation in a captured MCP `tools/list` snapshot. If the tool is later redefined or poisoned, the digest mismatch fails closed as `capability_drift` ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/)).

One deployment note. The default topology holds the Mission at the Authorization Server. A deployment that cannot change its AS can adopt the [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) instead: a standalone Mission Issuer that derives no tokens, with the PDP joining each ordinary OAuth token to its Mission at the point of use. That mode trades away Mission-bound credentials and issuance gating, resting entirely on PEP coverage, and [The Authority Control Plane](/notes/the-authority-control-plane/) prices that trade.

## The pipeline with a Mission in scope

The per-call pipeline from the first two parts (discover, request or evaluate, authorize or escalate, execute) does not change shape. What each step refers to does. The Mission bootstrap (Intent at PAR, validation, derivation, consent) happens before step 1.

1. **Discover.** `tools/list` is filtered against the Mission's Authority Set projection and local policy. A tool unrelated to the approved task need not appear. This is exposure control, not enforcement. Every consequential `tools/call` still passes the runtime gate.
2. **Request or present.** A token-side request presents the Mission-bound credential for the derivation flow. A resource-side call presents the Mission-bound access token to the MCP server. Either way, `mission.id` and `mission.issuer` come from a validated artifact or trusted server-side binding.
3. **Evaluate.** The PDP evaluates the concrete action against the audience-relevant Authority Set entry, the concrete parameters, the actor chain, resource policy, and *current* Mission state, within the deployment's freshness bound ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/)).
4. **Authorize or escalate.** An in-bounds request produces a Mission-bound token or permit without expanding anything. Local policy may still require step-up authentication or an action-bound approval. A request that would broaden committed authority routes to Mission Expansion, which is a fresh approval creating a successor Mission ([Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/)).
5. **Execute.** The MCP server enforces the permit at the last controllable boundary, reverifies parameter bindings, and writes Decision Evidence (and, for high-consequence classes, Execution Evidence) bound to the Mission, so records across authorization domains join.

## Tool discovery, invocation, and approval

The three authorization problems from [Least-Privilege MCP Tool Calls](/notes/least-privilege-mcp-tool-calls/) line up cleanly once the Mission is in scope.

**Tool discovery.** Filtering `tools/list` against the Mission projection reduces exposure. It does not replace authorization of `tools/call`.

**Tool invocation.** Both models now have an object to point at. The Mission-bound token is least-privilege at the token grain and tagged with the task it serves. The PDP decision is least-privilege at the per-call grain and tagged with the same task. Either way, the invocation is bound to a specific user-approved task, not just to a specific resource.

**Tool approval.** Approval, consent, and access request share one governance surface without having identical lifecycle effects. In-bounds clarification, argument capture, step-up, or an action-bound approval for an action already inside committed authority leaves the Mission unchanged and is recorded in Decision Evidence. A request that would broaden resources, actions, constraints, audience, budget, or lifetime is Mission Expansion. The AuthZEN profile can mark an `out_of_authority` or `action_approval_required` denial as requestable, ARAP carries the request, and a grant lands as a separately approved successor Mission. The approver sees the Mission lineage rather than an isolated tool fragment.

```mermaid
flowchart TB
    User([User])
    Mission[("Mission record<br/>at the Authorization Server<br/>id, intent_hash, authority_hash")]
    Agent([Agent])
    subgraph TS["Token-side"]
      AS1[Resource AS-1]
      AS2[Resource AS-2]
    end
    subgraph RS["Resource-side"]
      PDP1[MCP-1 PDP]
      PDP2[MCP-2 PDP]
    end
    User -->|One Mission-level approval<br/>of intent and derived authority| Mission
    Agent -->|Mission-bound credential<br/>+ requested authority| AS1
    Agent -->|Mission-bound credential<br/>+ requested authority| AS2
    Agent -->|tool call + validated<br/>Mission-bound context| PDP1
    Agent -->|tool call + validated<br/>Mission-bound context| PDP2
    AS1 -.->|Mission state| Mission
    AS2 -.->|Mission state| Mission
    PDP1 -.->|Mission state| Mission
    PDP2 -.->|Mission state| Mission
```

The two models converge on the Mission. One Mission-level approval projects into many tokens and PDP decisions, while resources retain their own policy and interaction requirements.

The Mission is not a global operation vocabulary, and it does not eliminate the need for RAR-type metadata, AuthZEN evaluations, or Resource Server policy. It supplies the shared task handle and lifecycle. Resource domains still define their own semantics. This is [the ontology problem](/notes/least-privilege-mcp-tool-calls/#the-ontology-problem) and its policy-mapping half by name: the resource owns the meaning, and the governance and policy layers consume it through registered semantics, published metadata, capability digests, and, where the substrate supports it, the resource's own hash-committed declaration ([who owns the meaning](/notes/mission-based-authorization-field-reference/#who-owns-the-meaning) is the Reference's map). That division of concerns is the point:

| Concern | Owned by |
| --- | --- |
| User-approved task, expiry, lifecycle, audit anchor | Authorization Server at `mission.issuer` |
| Typed approved authority | Authority Set, projected as AS-derived `authorization_details` |
| Resource-specific operation meaning | MCP server or Resource Server |
| Resource-declared operation semantics | The resource itself, hash-committed at the encounter where the substrate supports it |
| Per-call enforcement | Resource AS, MCP server, or PDP |
| Cross-call audit join | `mission.id` and `mission.issuer` |
| Out-of-bounds expansion | Mission Expansion, carried by ARAP where deployed |

That is why the Mission composes with both styles: the same governed task and Authority Set to project from, never the grant itself.

# Does a Mission violate the lethal trifecta?

The lethal trifecta for agents is the combination, in one execution loop, of private-data access, untrusted-content exposure, and external side effects ([Splitting the Lethal Trifecta](/notes/splitting-the-lethal-trifecta/) is the validation story). The board-packet agent can easily touch all three. It reads confidential finance data, ingests public filings or partner documents, and sends notifications or publishes a packet. A Mission profile must not pretend that naming the task makes that safe.

The answer is that **a Mission does not inherently violate the lethal trifecta, but the authority attached to a badly designed Mission can package it.** If the Authority Set grants broad private-data reads, untrusted-web access, and external write authority as one undifferentiated bundle, naming the task has not reduced the risk.

The useful posture does the opposite. It gives the Authorization Server, Resource Servers, PDPs, and egress controls a common object for splitting and governing the bundle:

| Trifecta element | Mission control point |
| --- | --- |
| Private data access | `mission_resource_access` entries limit which systems, records, periods, tenants, and actions are in scope |
| Untrusted content exposure | Shaping treats prompt content as data, and the harness taints a session once untrusted content enters it, so injected input cannot expand authority by itself |
| External side effects | Runtime enforcement requires a per-action permit, parameter binding, and action-bound approval or Mission Expansion for sends, publishes, payments, and egress |

The [runtime profile's lethal-trifecta boundary](/notes/mission-bound-runtime-enforcement/#the-lethal-trifecta-at-execution-time) treats this as a first-order design constraint, and [Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/#the-lethal-trifecta-at-execution-time) is honest about the limits: the defense is as strong as PEP-placement completeness, and per-action checks are not information-flow control.

The design rule is simple. A Mission may describe a task that spans all three elements, but it must not grant all three as ambient authority. Private reads, untrusted inputs, and external writes need to remain separately typed, separately evaluated, and separately auditable under the same canonical Mission. One caveat rides with this essay's own workflow entry: a constraint naming `audit-committee` binds the group's identity, not its membership, which is state another system owns. [The runtime part](/notes/mission-bound-runtime-enforcement/#the-lethal-trifecta-at-execution-time) prices that residual, and its answer, pin enumerated recipients at derivation for high-consequence classes or say so in the enforcement-scope statement, applies verbatim here.

# How Missions compose with AuthZEN

The two models compose with the [AuthZEN Access Request and Approval Profile](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) at different enforcement points, exactly as [Closing the Gaps](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/) laid out for the per-call case. Token-side, a requestable denial at the AS can trigger an Access Request, and a fresh authorization decision can later issue a Mission-bound token. Resource-side, a requestable denial at the PDP can trigger an Access Request, after which the MCP server reevaluates before executing. Approval is input to a new decision in both cases. It is never itself an access grant, and a durable grant is committed as a successor Mission. The [AuthZEN profile](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authzen.html) defines the Mission-specific composition points, including the closed denial-reason set and the two evidence objects.

# Comparison with AAuth

The two models name where authorization lands on the OAuth substrate. [AAuth](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/) reaches the same question from a clean-slate agent substrate, and it carries a task object natively. The agent proposes a mission to its Person Server, the approved mission is bound by hash, and the agent presents a mission reference on each call. [AAuth Now Has a Mission Layer](/notes/aauth-now-has-a-mission-layer/) reads that design in depth.

The [Reference's landscape](/notes/mission-based-authorization-field-reference/#competitive-landscape) classifies the AAuth mission as a sibling instance of the same category rather than a competitor. The interesting question is shared governance when a deployment spans both substrates, and the current draft family states the substrate primitives a further binding must supply without yet specifying cross-substrate projection. What both families already agree on is the operating rule: carry authority when it must travel, evaluate locally when context must stay local, and bind both to the durable approved task when work spans calls, tools, or domains.

# Agents do not only call tools

The MCP tool boundary is one place this pattern surfaces. The egress boundary is another. When an agent reaches a destination its egress proxy does not allow, the result today has the same shape as a flat `403` with no machine-actionable recovery, and the same pipeline applies with the proxy as the PEP. [A Blocked Agent Is a Captive Client](/notes/a-blocked-agent-is-a-captive-client/) sketches the approval architectures for that boundary.

A Mission ties both boundaries together. Policy at the MCP and egress boundaries derives from the same Mission and Authority Set. In-bounds tool calls and destinations clear without a new Mission-level prompt, subject to local runtime policy. Authority-expanding events at either boundary route to Mission Expansion at `mission.issuer`. The approver sees one Mission lineage, not unrelated streams of tool and egress approvals. Real agents touch both boundaries on every non-trivial task. The board-packet agent does not only call MCP tools. It also fetches reference data from partner APIs and pulls public reports. The same governance object spanning both boundaries is what keeps the audit trail coherent, and the [harness](/notes/the-agent-runtime-and-audit/) is what guarantees there is no unmediated route around either PEP.

# Tracing a denial end to end

The framework above is easier to evaluate against a concrete failure mode than against the happy path. This walkthrough traces one Mission from approval through an out-of-bounds attempt, an expansion request, a user denial, and the resulting audit query. It is the [Reference's running example](/notes/mission-based-authorization-field-reference/#the-running-example-end-to-end) at the MCP boundary, and each stage names the part that defines the mechanic.

**Stage 1, approval.** The user asks an agent to prepare the Q3 board packet. The shaper turns the prompt into the Mission Intent shown above and submits it at PAR, recording Shaping Evidence ([From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/)). The AS validates the Intent, derives the three-entry Authority Set, and renders the derived set for consent. On approval it creates `msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1` in the `active` state, committing `intent_hash` and `authority_hash`, and issues Mission-bound tokens ([The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/)).

**Stage 2, out-of-bounds attempt.** Two hours in, the agent decides the packet needs CRM data on key accounts. CRM is not in the approved resources or Authority Set. The call reaches the CRM MCP server's PEP, whose PDP finds no `mission_resource_access` entry covering it and returns `decision: false` with `denial_reason: out_of_authority` ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/)). Because the missing authority is eligible for expansion, the denial is marked requestable with the deployment's Access Request binding context, and the PDP writes Decision Evidence bound to the Mission, the `authority_hash`, the policy-view version, the requested action, and the actor context.

**Stage 3, expansion request.** The orchestrator uses the requestable-denial context to submit the CRM authority through ARAP. Expansion is an ordinary Mission creation bound to the predecessor's grant (an eligibility rule, not an authority path), so the client presents the predecessor's refresh token and the AS adjudicates a successor of that specific Mission, obtaining fresh consent on the successor's full derived authority rather than a delta over the predecessor ([Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/)).

**Stage 4, user denial.** The user declines. CRM access is out of policy for board-packet preparation. No successor Mission is created, nothing supersedes anything, and `msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1` stays `active` with its original three entries. Subsequent identical attempts remain denied, and a deployment may suppress duplicate prompts with a denial cache.

**Stage 5, audit.** A week later, a governance reviewer queries the Authorization Server for the Mission's lifecycle events and the PDP's evidence store for records bound to `mission.id` and `mission.issuer`. The lifecycle records show approval at T0, no successor, and no termination. The evidence records show the permitted finance and workflow operations, the denied CRM attempt, and the denied expansion attached to it. Where the deployment registers evidence into a SCITT Transparency Service, the whole history is one verifiable, append-only feed under the Mission's subject ([The Agent Runtime and Audit](/notes/the-agent-runtime-and-audit/)). The join is deterministic, not stitched from timestamps. That property has a name the [series adopted](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/): verifiable continuity, the approval, the denied attempt, the expansion, and every permitted operation provably one undertaking, which is a different property from the lifecycle continuity that lets parked work survive a disconnect.

That is the answer to the question the MCP series keeps asking. "Did the agent stay within what the user approved?" is answerable only if the protocol knows what was approved. The Mission is that record. The Authority Set and the evidence answer what was allowed and what occurred, and the denial trace shows the whole spine holding under refusal, which is where governance systems usually fall apart.

# Where to start building

Start with the per-call foundations from the [Closing the Gaps checklist](/notes/closing-the-gaps-least-privilege-mcp-tool-calls/#where-to-start): authorize every `tools/call` at the MCP server, filter `tools/list` with the same policy, and adopt the AuthZEN decision shape so denials can become governed requests. Each pays for itself before any Mission machinery arrives. The Mission layer is what makes them compose:

- **When approvals must compose across calls, servers, or authorization domains**, adopt the issuance core so both models project from the same task object ([The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/)), and add the runtime and AuthZEN profiles for the per-action gate and evidence ([Mission-Bound Runtime Enforcement](/notes/mission-bound-runtime-enforcement/)). With a freshness source in place, that is the Runtime-Enforced level of the Mission Assurance Levels.
- **When revocation must bite faster than token expiry**, add Mission Status and Lifecycle Signals as the freshness source ([Mission Lifecycle and Change](/notes/mission-lifecycle-and-change/)).
- **When the approval itself must be trustworthy**, add shaping discipline and Consent Evidence ([From a Request to an Approved Mission](/notes/from-a-request-to-an-approved-mission/)), and the harness for session and egress mediation ([The Agent Runtime and Audit](/notes/the-agent-runtime-and-audit/)).
- **When the Authorization Server cannot change**, the [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) is the AS-optional peer binding: governance and per-action enforcement with ordinary tokens, at the cost of issuance gating.
- **For the full map of levels and maturity**, the [Mission Assurance Levels](/notes/adopting-mission-bound-authorization/#run-governed-and-beyond) in Adopting Mission-Bound Authorization and the [draft-family table](/notes/mission-based-authorization-field-reference/#the-draft-family-at-a-glance) in the Reference are the current state.

Missions do not replace resource authorization. They organize task identity across calls, servers, authorization domains, and credential substrates. Token-side and resource-side are two OAuth-shaped ways authority reaches enforcement. In either, carry authority when it must travel, evaluate locally when context must stay local, and bind the resulting actions to the Mission when work spans calls, tools, or domains.