---
title: "The Mission is the Missing Abstraction for Agents"
date: "2026-06-01T18:00:00-07:00"
lastmod: "2026-06-01T18:00:00-07:00"
description: "The identity stack has no first-class object for the task the user approved. Mission-Bound OAuth makes that task explicit as a durable Mission authority record, giving every layer of the stack a common identifier to refer to."
summary: "Four prior bodies of work converge on the same structural gap. The identity stack has no durable object for the task the user approved. The Mission is that object. Part 1 frames the gap and introduces the spec proposal that closes it. The MVP and Runtime Enforcement Profile follow in Parts 2 and 3. Part 4 applies the spec to MCP tool calls."
slug: "the-mission-is-the-missing-oauth-abstraction"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound OAuth"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
series:
  - "mission-bound-oauth-mvp"
---


The missing abstraction in OAuth for agents is not another token type. It is a durable Mission authority object.

OAuth is not solving the wrong problem. It solves the credential and delegation problem. The missing layer is durable governance for the task the user approved. Agents do not just need identity. They need bounded authority that can persist, narrow, expand, and terminate as the work evolves. A valid token can still be used for the wrong task. A session can outlive the mandate. A delegation chain can preserve actors while losing intent.

The proposals in flight ([agent-extended RAR types](https://datatracker.ietf.org/doc/draft-chen-oauth-rar-agent-extensions/), attenuating actor tokens, [agent attestation tokens](https://datatracker.ietf.org/doc/draft-yakung-oauth-agent-attestation/), [agentic JWTs](https://datatracker.ietf.org/doc/draft-aap-oauth-profile/), [transaction tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/), [scope aggregation](https://datatracker.ietf.org/doc/draft-jia-oauth-scope-aggregation/), decoupled authorization models) each add a new credential or wrapper. None of them addresses the structural gap. OAuth has no first-class object for *the task the user approved*. Tokens, scopes, prompts, and logs are projections of that task. The task itself is implicit, scattered across application state, prompt context, and audit log stitching.

# The core thesis

This argument has been building across four prior bodies of work that each describe the same structural gap from a different angle, plus the proposal that closes it.

**[You Don't Give Agents Credentials, You Grant Them Power of Attorney](/series/you-dont-give-agents-credentials-you-grant-them-power-of-attorney/).** Enterprise IAM governs who an agent is and what each call may do. It does not govern whether the mission behind those calls should still be running. Tokens stay valid past the moment approval expired. Policies still pass after intent has changed. Credentials remain secure while the work they authorize has become unauthorized. The breach is structurally invisible because no layer of the stack was built to ask the question. Agents need delegated authority that behaves like a Power of Attorney, not a credential.

**[Mission Shaping](/series/mission-shaping/).** A user approves an objective, not the authority needed to execute it. Something has to turn that approval into something a control plane can evaluate. In most deployments today that shaping step is implicit, local, or delegated to the agent itself. The model infers its own boundaries and the system trusts it. That is not governance. It is optimism.

**[Open-World OAuth](/series/open-world-oauth/).** OAuth succeeded because its closed-world relationships were known ahead of time. The client knew the AS, the RS knew its issuers, scopes were configured before deployment. Agents push OAuth into an open-world model where tools, Resource Servers, and ASes are discovered at runtime and may not share prior trust. That exposes two challenges at different layers. The substrate problem covers protocol mechanics like discovery, resource binding, sender constraints, metadata integrity, and first-contact trust. The governance problem is deciding whether newly requested authority is still inside the task the user approved. Fixing the substrate does not fix the governance.

**[Sessions Are Not Missions](/notes/sessions-are-not-missions/).** Modern agent harnesses make work durable across restarts, devices, sub-agents, and reconnected tools. That durability is a runtime property, not a governance property. A session can prove the runtime survived. It cannot prove the mission did. The harness that runs the agent is not the layer that owns the mission.

**[Mission-Bound OAuth (the architecture series)](/series/mission-bound-oauth/).** The Mission is a durable authority object at the Authorization Server: bounded by purpose, governed across its lifecycle, revocable by business event, and enforced across every token and downstream exchange derived from it. Agent authority belongs to a typed governance object, not to a credential.

Mission-Bound OAuth makes the task explicit. The Mission is a durable, AS-stored, user-approved authority record. Tokens carry handles back to it. Resource Servers introspect it. PDPs evaluate against it. Audit systems join on it. Once it exists as a typed object on the wire, every other layer can refer to the same thing.

# The Mission as the common object

The Mission is the common object that lets OAuth, AuthZEN, Token Exchange, Resource Servers, tool runtimes, and audit systems talk about the same delegated task.

- **OAuth** projects the Mission into access tokens, refresh tokens, and ID-JAGs via the `mission` claim carrying `id` and `origin`.
- **AuthZEN** evaluates per-action requests against the Mission's compiled policy artifact and produces a decision plus advice or evidence.
- **Token Exchange and Identity Chaining** preserve `mission.id` and `mission.origin` across trust-domain boundaries; the [Transaction Token Chaining Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) carries the Mission through Txn-Token-rooted flows.
- **Resource Servers** introspect Mission state per request or consume Mission state events through SSF and CAEP.
- **Tool runtimes** receive `tool_id`-bound permits and verify `parameter_digest` at execution time to close TOCTOU gaps.
- **Audit systems** key on `mission.id`, `proposal_hash`, `consent_rendering_hash`, and the `act` chain for end-to-end provenance.

Without the Mission, each system carries its own implicit notion of "the task." Logs do not join across hops. Revocation does not propagate cleanly. Audit reconstruction is stitching by approximate timestamps. With the Mission, every system refers to the same identifier with the same anchored history.

# Why IBAC becomes practical

Intent-Based Access Control is hard when intent is inferred from agent behavior at enforcement time. A PDP that reconstructs "what did the user actually want" from a prompt, a tool call, or an observed trajectory is doing probabilistic interpretation against adversarial input. Recent agent-authorization research shows that post-hoc intent verification degrades sharply under paraphrasing and prompt-injection attacks.

IBAC becomes practical when intent is compiled from a user-approved Mission, not inferred from prompts at enforcement time. The orchestrator submits a structured proposal. The AS validates it against client registration and deployment policy. The user approves a rendered version that is anchored by `consent_rendering_hash`. The AS compiles the approved bounds into a deterministic policy artifact with a stable `policy_version`. By the time the PDP evaluates a request, "what did the user approve" is a typed object the PDP reads directly.

The interpretation problem moves to consent time, where the user is present and the AS owns the validation, instead of to enforcement time, where the agent is adversarial-input territory and the PDP has no user to ask. This is the design move that makes IBAC ship.

# Three layers, one stack

Mission-Bound OAuth lands as a three-layer stack. Each layer has a clear job, and the Mission is the typed object that the upper layers project from.

1. **OAuth / token layer.** Authenticate the client, bind the token to a sender constraint, narrow the token's authority, exchange the token across audiences, revoke when needed. This is what existing OAuth already does well. The series composes with this layer rather than rebuilding it.
2. **Mission / governance layer (issuance-bound authority).** The Authorization Server preserves the user-approved task as a durable, typed object with bounds, lifecycle, and an audit spine every downstream artifact joins on. OAuth token issuance, refresh, exchange, and cross-AS derivation all gate on Mission state. Every derived artifact carries the Mission handle. Revoking the Mission terminates future derivation. The Mission lifecycle is independent of token expiry. This is what the [Mission-Bound OAuth MVP](/notes/mission-bound-oauth-mvp/) adds.
3. **Runtime enforcement layer (runtime-enforced authority).** A Policy Decision Point evaluates every consequential agent action against the Mission's compiled policy and produces per-decision evidence. The orchestrator cannot execute consequential local actions inline. The Mission becomes the authoritative input to runtime policy, not only the bounding object on a token. Mission-Bound OAuth becomes Intent-Based Access Control when the same Mission drives both layers. This is what the [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) adds.

Most adjacent work is strong in one of those layers. Very little tries to connect all three into one coherent standards stack. The Mission record is the connective tissue. It is what lets the token layer, the governance layer, and the runtime layer refer to the same object instead of inventing parallel state. The two upper layers project from the same Mission. That is what makes them coherent rather than parallel.

# Adoption is incremental

The Mission-Bound OAuth MVP is designed for a Conformance Ladder, not a single all-or-nothing rollout. Deployments sit at the level that matches their infrastructure today and move up as the policy and runtime layers are ready.

- **Level 0:** Baseline OAuth 2.0. No Mission awareness.
- **Level 1:** Mission-bound issuance at the Authorization Server. Tokens carry the `mission` claim; refresh and exchange gate on Mission state.
- **Level 2:** Mission-aware Resource AS. Cross-AS handoff via ID-JAG or the Transaction Token Chaining Profile, with `mission.id` preserved.
- **Level 3:** Mission-aware Resource Server. Request-time checks for OAuth-protected requests at RS-B or higher. AuthZEN Access Evaluation is a composition option at this level, not a Level 3 requirement.
- **Level 4:** Full Runtime Enforcement. Every consequential action evaluated against the Mission's compiled policy; per-decision evidence required.
- **Level 5:** Verifiable governance. Portable cryptographic receipts, tool-manifest binding, attestation-bound `cnf`, governed purpose registries.

Levels 1-3 are covered by the MVP: Mission-bound issuance, cross-AS projection, and Mission-aware Resource Server checks. Levels 4-5 are covered by the Runtime Enforcement Profile and its Optional Modules. A deployment ships value at Level 1 and adds capability without invalidating earlier levels.

# Where to start

The series has two protocol posts and one application post:

- [Mission-Bound OAuth MVP](/notes/mission-bound-oauth-mvp/) — Mission-bound OAuth authority. The five wire additions, the seven-state Mission lifecycle, cross-AS handoff, deployment-defined context constraints, audit anchors, the Conformance Ladder.
- [Mission-Bound OAuth Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) — runtime-enforced authority. The PDP contract, the Optional Modules, parameter binding and TOCTOU, decision evidence.
- [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls/) — the spec applied to a concrete deployment. The five-step capability acquisition pipeline, the three authorization problems (discovery, invocation, approval), and how a Mission lets token-side and resource-side FGA become projections of the same task.

The first two compose with existing OAuth, AuthZEN, Token Exchange, Identity Chaining, Transaction Tokens, and Shared Signals work. Neither requires a clean-slate protocol substrate. The third shows how the spec lands at the MCP boundary that most agent deployments hit first. The Mission is the missing abstraction that ties all three together.