Least-Privilege MCP Tool Calls Need a Mission

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 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 compares the models, and Closing the Gaps 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. 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.

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 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, 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). 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).

For the board-packet task, the shaper submits this Mission Intent at PAR. The mission_intent parameter carries it inside a Submission envelope, with no Intent Submission Evidence alongside it here, and intent_hash covers only the intent object:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

Note what the shaper does not author. It names target resources and human-readable task bounds, and any candidate authority it offers rides beside the Intent as standard top-level authorization_details (absent here), untrusted input the Authorization Server only narrows, committed by the conditional proposal_hash. The consented Authority Set is always the AS’s derivation, never the proposal itself, and 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:

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

[
  {
    "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 a human-readable task bound in the Intent and structure in the derived entry, and no function parsed one into the other. No authority was proposed, so the AS derives the set in configured-mapping mode: the mapping configured for the board-packet purpose binds the current reporting period (Q3 2026), the board-packet template, and the audit-committee group, within the Intent’s target_resources. The task_bounds are shown to the user beside the result; the AS does not read them, and the Approver’s check that the structure matches the words is what joins them. 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, the Mission Status List where one consumer relies on many Missions, or Lifecycle Signals (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 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 Mission Capability Binding companion to the runtime layer binds it to the source and content digest recorded at derivation, such as a tool in a captured MCP tools/list snapshot, and verifies it at decision time. If the tool is later redefined or poisoned, the digest mismatch fails closed as capability_drift (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 instead: a standalone Mission Issuer over the OAuth Mission data model that derives no tokens, with the PDP joining each ordinary OAuth token to its Mission at the point of use. On its own that mode trades away Mission-bound credentials and issuance gating, resting entirely on PEP coverage, and The Authority Control Plane prices that trade. The Mission Issuance Grant buys both back at each Authorization Server that redeems its grant for Mission-bound tokens: an AS with a Mission-state integration checks the Mission at redemption and at every refresh, and one without issues no refresh tokens.

The pipeline with a Mission in scope

The per-call pipeline from the MCP series’ 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 two authority bounds, the audience-relevant entry the credential carries and the Mission’s current Effective Authority Set (the approved set after any discharge or containment), and against the concrete parameters, the actor chain, resource policy, and current Mission state, within the deployment’s freshness bound (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).
5. Execute. The MCP server enforces the permit at the last controllable boundary and reverifies parameter bindings. The PDP’s Decision Evidence and, for high-consequence classes, the MCP server’s Execution Evidence are 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 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 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.

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 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 is the Reference’s map). That division of concerns is the point:

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 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:

The runtime profile’s lethal-trifecta boundary treats this as a first-order design constraint, and Mission-Bound Runtime Enforcement 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 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 at different enforcement points, exactly as Closing the Gaps 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 defines the Mission-specific composition points, including the denial-reason set, which companion profiles extend by specification and in which an unrecognized value denies. Mission Runtime Evidence defines the three records the runtime layer emits: Decision Evidence, Execution Evidence, and the Refusal Record for a refusal before any decision.

Comparison with AAuth

The two models name where authorization lands on the OAuth substrate. AAuth 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 reads that design in depth.

The Reference’s 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. The draft family now includes an AAuth binding, Mission Context Binding for AAuth, which uses AAuth’s own mission, its Mission Reference (the approving Person Server and the mission’s s256 hash), and its active and terminated states unchanged, adding no wire members, but no draft yet specifies projection across substrates. 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 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 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 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). The AS validates the Intent, derives the three-entry Authority Set, and renders the derived set for consent. On approval it creates msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p in the active state, committing intent_hash and authority_hash, and issues Mission-bound tokens (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 among the Intent’s target resources or in the 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 context.reason set to out_of_authority (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, which records the same value as denial_reason, bound to the Mission, its decision basis (a policy-view identifier, or the authority_hash with the PDP’s policy version where it evaluates the recorded authority directly), 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, and this deployment realizes the request as a Mission Expansion. Expansion is an RFC 8693 token exchange that carries the successor’s mission_intent and presents the predecessor’s sender-constrained Mission-bound access token as the subject_token (a refresh token is refused, and the possession proof is an eligibility rule, not an authority path), so 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).

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_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p 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). The join is deterministic, not stitched from timestamps. That property has a name the series adopted: 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: 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 profile so both models project from the same task object (The Mission Is the Missing Abstraction), and add the runtime and AuthZEN profiles for the per-action gate and evidence (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, the Mission Status List where one gateway relies on many Missions, and Lifecycle Signals as the freshness source (Mission Lifecycle and Change).
• When the approval itself must be trustworthy, add shaping discipline and Consent Evidence (From a Request to an Approved Mission), and the harness for session and egress mediation (The Agent Runtime and Audit).
• When the Authorization Server cannot change, the Mission Authority Server is the standalone controller over the OAuth Mission data model: governance and per-action enforcement with ordinary tokens, at the cost of issuance gating unless an Authorization Server redeems its Mission Issuance Grant for Mission-bound tokens.
• For the full map of levels and maturity, the Mission Assurance Levels in Adopting Mission-Bound Authorization and the draft-family table 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.