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, attenuating actor tokens, agent attestation tokens, agentic JWTs, transaction tokens, 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. 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. 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. 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. 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). 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 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 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 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 — 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 — runtime-enforced authority. The PDP contract, the Optional Modules, parameter binding and TOCTOU, decision evidence.
• Least-Privilege MCP Tool Calls Need a Mission — 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.