The Two Paths, 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 Server: 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 Least-Privilege MCP Tool Calls walks both in full.

Token-side FGA 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 FGA 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 AuthZEN Access Request when the denial is requestable.

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 tasks with no shared lifecycle, and audit joins fall back to timestamps and log correlation. The protocol stack has no first-class object that names the task. That is the gap this post closes.

A Mission makes that governed task an explicit protocol object both paths 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 post.

Board Packet Before and After

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

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 closes the gap: it is a typed governance object for the task the user approved, with a state authority identified by mission.origin. The default OAuth topology places the Mission record at the originating AS; the Mission Authority Server topology moves it to a dedicated MAS. Tokens and PDP decisions carry or resolve a binding to that record. As the Missing Abstraction post argues, the missing abstraction is not another credential or evaluation point. It is the governed task that those artifacts serve.

The user approves a structured Mission Intent that describes the task: goal, objects, constraints, success criteria, and expiry. The validating server renders the proposal and effective authority for approval. The state authority stores the Approved Mission and integrity anchors. The OAuth AS derives the authorization_details that represent actual OAuth authority and binds derived tokens to the Mission through a mission claim carrying id and origin. The Mission-Bound OAuth Profile defines this default OAuth composition.

The Mission fixes both paths because it separates concerns that token-side and resource-side FGA otherwise conflate. The state authority owns the user-approved task, its integrity anchors, and its lifecycle. The Authority Set represents the typed grantable authority derived for that task. Each Resource Server owns the domain semantics and local policy for its tools. Under the Mission Authority Server topology, mission.origin resolves to the MAS issuer URI; in the default topology it resolves to the originating AS.

The validating AS does not have to implement every resource’s policy engine. It validates the Mission Intent against client registration and deployment policy, then obtains resource-domain validation where local semantics are required. The finance, document, and workflow systems remain authoritative for local resource policy. This division does not remove the ontology boundary; it makes the boundary and validation responsibility explicit.

For the board-packet task, the client submits a Mission Intent like this at PAR:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "goal": "Prepare the audit-committee board packet for Q3 2026",
  "objects": ["Q3 financials", "board packet document", "audit-committee reviewer"],
  "constraints": [
    "confidential classification",
    "Example Corp tenant",
    "audit-committee-q3-2026 meeting"
  ],
  "success_criteria": ["packet drafted", "reviewer notified"],
  "mission_expiry": "2026-10-15T18:00:00Z"
}

The Authorization Server derives the authorization_details from the Approved Mission. The token-endpoint response returns this derived array alongside the access token and the mission claim. The approved Mission Intent itself stays on the Mission record at mission.origin; an authenticated Mission read or Mission Status API may expose authorized fields. Issuer introspection may return Mission state and selected fields when the AS also owns the Mission, but base RFC 7662 is not a full Mission-record retrieval API. Just the derived array:

 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

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

The Mission Intent does not need to carry exact MCP tool names. The Authority Set or OAuth authorization_details can describe actions at a grain the validating server and Resource Server can jointly validate. When the Tool Binding module is enabled, an approved action is additionally pinned to a source-identified capability, such as an operation in a captured MCP tools/list snapshot, with an operation reference and source digest. The Resource Server still maps that approved authority to concrete arguments and local policy.

The Mission-Bound OAuth Profile defines ID-JAG propagation and identifies Transaction Token Chaining as a follow-on composition point. The Runtime Enforcement Profile defines how a PDP evaluates a Mission projection at execution time. This post shows how those mechanics land at the pipeline grain and at the three authorization problems: tool discovery, tool invocation, and tool approval.

The Pipeline with a Mission in Scope

The five-step pipeline from the foundations post (discover need, request authority, evaluate, authorize or escalate, execute) does not change shape. What each step refers to does. The pipeline below describes how each step looks once an Approved Mission exists at the state authority. The initial Mission bootstrap (Mission Intent at PAR, validation, and user consent) is the OAuth Profile’s Authorization Request flow and happens before step 1.

1. Discover need. Under the proposed MBO/MCP binding, tools/list becomes Mission-aware. The MCP server filters the catalog against the Mission projection and local policy.
2. Request authority. A Path A request presents the Mission-bound credential or assertion required by the selected OAuth derivation flow. A Path B call presents the Mission-bound access token or authenticated context accepted by the MCP server. The Resource AS or PDP obtains mission.id and mission.origin from a validated artifact or trusted server-side binding, never from an unauthenticated request parameter.
3. Evaluate. The credential issuer validates the credential. The state authority at mission.origin supplies Mission status when it is a separate service. The Resource AS or PDP evaluates the audience-relevant Authority Set projection with its own domain knowledge and freshness policy.
4. Authorize or escalate. An in-bounds request produces a Mission-bound token (Path A) or permit (Path B) without expanding the Mission. Local policy may still require authentication, confirmation, contractual consent, or another interaction. A request that would broaden committed authority routes to Mission Expansion.
5. Execute. The MCP server validates and enforces the token or permit. When the Runtime Enforcement Profile is adopted, decision evidence binds the executed call to the Mission so records across authorization domains can be joined.

Tool Discovery and Approval with a Mission

The three authorization problems, tool discovery, tool invocation, and tool approval, line up cleanly once the Mission is in scope.

Tool discovery. The proposed binding filters tools/list against the Mission projection and local policy. A tool unrelated to the approved task need not appear. This reduces exposure but does not replace authorization of tools/call.

Tool invocation. Both FGA paths now have an object to point at. The Mission-bound token in Path A is least-privilege at the token grain and tagged with the task it serves. The PDP decision in Path B 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 can share one governance surface without having identical lifecycle effects. In-bound clarification, argument capture, step-up authentication, or approval of an action already inside committed authority leaves the current Mission unchanged and is recorded in decision evidence. A request that would broaden resources, actions, constraints, audience, budget, or lifetime is Mission Expansion: it is routed through AuthZEN Access Request and, when approved, committed as a successor Mission. The approver sees the Mission lineage rather than an isolated tool fragment.

When the Runtime Enforcement Profile is adopted, every consequential PDP decision produces a Mission-bound evidence record. Audit joins then use the Mission binding; audience-pairwise identifiers require authorized resolution through mission.origin.

The two paths converge on the Mission. One Mission-level approval can project 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. That division of concerns is the point:

That is why the Mission composes with both token-side and resource-side FGA. It does not pick one enforcement style or act as the grant itself. It gives both styles the same governed task and Authority Set to project from.

Does a Mission Violate the Lethal Trifecta?

The lethal trifecta for agents is the combination of three capabilities in one execution loop:

1. Access to private or sensitive data.
2. Exposure to untrusted content that can influence the agent.
3. Ability to cause external side effects or exfiltrate data.

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: 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/send authority as one undifferentiated bundle, naming the task has not reduced the risk.

The useful Mission profile does the opposite. It gives the state authority, Resource Servers, PDPs, and egress controls a common object for splitting and governing the bundle:

The OAuth Profile’s Lethal Trifecta Boundary mainly supplies lifecycle and derivation control. That is useful, but it is not enough for a high-risk agent that touches all three sides of the trifecta. The Runtime Enforcement Profile’s Lethal Trifecta Control makes the stronger posture concrete: consequential actions are evaluated at execution time, parameters are bound into the decision, out-of-bounds actions route through Mission Expansion, and evidence records identify which Mission-bound step caused a side effect.

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.

How Missions Compose with AuthZEN

Path A and Path B compose with the AuthZEN Access Request and Approval Profile at different enforcement points. Path A gates token issuance: a requestable denial at the AS can trigger an Access Request, and a fresh authorization decision can later issue a Mission-bound token. Path B gates execution: 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 not itself an access grant. The Runtime Enforcement Profile and Mission-Bound OAuth Profile define the Mission-specific composition points.

Comparison with AAuth

The two paths name where authorization lands on the OAuth substrate. AAuth Protocol -02 reaches the same question from a clean-slate substrate and gives the Resource four modes, each adding parties and capabilities: identity-based, resource-managed, PS-asserted, and federated. Least-Privilege MCP Tool Calls maps those four modes onto token-side and resource-side FGA. What matters here is the task object.

AAuth carries one natively. The Agent proposes a Mission to its Person Server; once approved, the Mission is immutable, bound by the SHA-256 hash of its JSON, and the Agent presents a Mission Reference (the approver URL plus that hash) on each call through the AAuth-Mission header. Mission-aware resource tokens and auth tokens carry the same reference without translating it into OAuth RAR. Resource policy still decides what a scope or request means, so AAuth does not eliminate the ontology problem by standardizing one universal operation vocabulary.

That leaves two substrates expressing the same task abstraction differently, and the series treats them as one governance model. The Mission-Bound AAuth Composition Profile maps AAuth’s Mission Reference onto the governance Mission so audit, lifecycle, and Authority Set semantics are common across both, and the Mission Authority Server Profile lets both substrates project from one canonical Mission without pretending their credential formats are identical. OAuth acquires the task object by adopting Mission Intent at PAR, the mission claim, and the integrity anchors; AAuth already has it.

The operating rule is the same in both families: carry authority when it must travel, evaluate locally when context must stay local, and bind both to the Mission 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 is the same shape as a flat 401 with no machine-actionable recovery, and the same five-step pipeline applies with the proxy as the PEP. The foundations post works through that mapping at each proxy altitude, and A Blocked Agent Is a Captive Client sketches the approval architectures.

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 can clear without a new Mission-level prompt, subject to local runtime policy. Authority-expandable events at either boundary route to Mission Expansion through the state authority at mission.origin. 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.

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, a Mission Expansion request, a user denial, and the resulting audit-reconstruction query. Every step references which post in the series defines the mechanic.

Stage 1, Mission approval. The user asks an agent to prepare the Q3 board packet. The orchestrator’s Shaper turns the prompt into a Mission Intent (the Mission Shaper Profile): goal = prepare Q3 board packet, objects = financials and presentation, constraints = audit-committee-only, mission_expiry = 2026-10-15. The orchestrator submits Mission Intent at PAR (the Mission-Bound OAuth Profile Authorization Request). In this default-topology example, the AS validates against client registration, renders for consent, and creates msn_01J9Z2P8 after approval. It computes proposal_hash, derives authorization_details for the finance and workflow MCP servers, computes authority_hash, transitions the Mission to active, and issues Mission-bound access tokens.

Stage 2, out-of-bounds attempt. Two hours in, the agent realizes the packet needs CRM data on key accounts. CRM was not in the approved objects or Authority Set. The request reaches the CRM MCP server’s PDP (the Runtime Enforcement Profile Resource-Side Enforcement Contract). The PDP evaluates the applicable policy view and finds no mission_resource_access entry covering CRM. Because the missing authority is eligible for expansion, the denial is requestable. It returns the deployment’s Access Request binding context and writes a decision evidence record bound to msn_01J9Z2P8, the integrity hashes, policy_version, the requested action, actor context, and denial classifier.

Stage 3, Mission Expansion request. The orchestrator uses the requestable-denial context to submit the requested CRM authority to the Access Request endpoint (the Mission-Bound OAuth Profile Mission Expansion). The state authority coordinates the expansion workflow and presents the user with the difference between the current Mission and the proposed successor.

Stage 4, user denial. The user denies the expansion. CRM access stays outside the approved task. The Access Request profile records the denial. The AS does not create a successor Mission. msn_01J9Z2P8 stays active with its original bounds. Subsequent identical attempts remain unauthorized. A deployment MAY suppress duplicate prompts through a denial cache or a separately defined idempotency extension.

Stage 5, audit reconstruction. A week later, a governance reviewer queries the state authority for msn_01J9Z2P8 lifecycle events (the Mission-Bound OAuth Profile Audit and Receipts) and the PDP for decision evidence bound to that Mission (the Runtime Enforcement Profile Decision Evidence Records). The lifecycle records show approval at T0, no successor Mission, and no termination event. The evidence records show permitted finance and workflow operations, the denied CRM attempt, and the denied expansion attached to it. After any audience-pairwise identifiers are resolved at mission.origin, the join is deterministic.

What the walkthrough shows. The Mission is the primary governance object for asking “did the agent stay within what the user approved?” The Authority Set and decision evidence answer what was allowed and what occurred. Without the Mission binding, the review requires stitching token issuance logs, AuthZEN denials, Access Requests, and per-resource audit logs by approximate timestamp. With it, the join is deterministic after any pairwise-identifier resolution.

Where to Start

Start with the two foundational pieces from Least-Privilege MCP Tool Calls: authorize every tools/call at the MCP server and filter tools/list with the same policy, and publish RAR-type metadata with resource-domain validation at the Authorization Server. Each pays for itself before any Mission machinery arrives. The Mission layer is what makes them compose:

• When you need approvals to compose across calls, servers, or authorization domains, the Mission-Bound OAuth Profile is the layer that makes Path A and Path B project from the same task object. The Runtime Enforcement Profile adds the runtime PDP contract and per-decision evidence on top.
• When the deployment runs multiple ASes, has a separate governance team owning consent and audit, or combines OAuth with AAuth surfaces, the Mission Authority Server Profile moves the Mission record into a dedicated server so every substrate consumes one Mission. It applies to either Path A or Path B and can be adopted at any Capability Ladder level.
• When you build the orchestrator or agent client that turns user prompts into Mission Intent, the Mission Shaper Profile specifies how to resolve proposed actions against captured MCP tool catalogs or other capability sources, record source identifiers and digests, surface ambiguity through a structured clarification protocol, and produce a Shaper Trace for audit replay.
• When you need to map the levers above onto a capability description, the Capability Model defines the Capability Ladder, Resource Server Tiers, and Authorization Domain Tiers a deployment uses to report what it actually delivers. Most token-side MCP deployments start at Ladder Level 1 with RS-A audiences; resource-side deployments that consult a PDP per tools/call are reaching for Level 3 or Level 4.

Missions do not replace resource authorization. They organize task identity across calls, servers, authorization domains, and credential substrates. Path A and Path B are two OAuth-shaped ways authority reaches enforcement. AAuth supplies its own four resource-access modes. In either family, 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.