The Mission Is the Missing Abstraction

Overview

The industry’s best-practices path for AI agent identity is taking shape. AI Identity Management System (AIMS), now a WIMSE working-group document, composes WIMSE, OAuth, and SPIFFE into a way to provision, credential, and authenticate agents and to delegate user authority to them. And it names the thing all of that identity exists to serve. Its Agent Mission section (Section 10.1 of -00) defines the Mission as “the task or objective the Agent will pursue,” and then draws a line: “The process through which the mission is translated into authorization requirements is out of scope of this specification.”

This part is about what lives on the other side of that line. OAuth represents credential issuance and delegation. It does not represent the durable task those credentials serve. The stack can prove who is acting and what credential they hold. It cannot prove the work is still authorized. Agents need authority that remains bound to a user-approved purpose as work spans tokens, calls, tools, sub-agents, and time. This part argues that the missing object is a Mission: a durable, approval-backed governance object on the OAuth substrate, and the anchor for every other claim the handbook makes. The Mission is not a new way to express authority. Rich Authorization Requests already do that. It is the approved task that authority is derived for, bound to, and gated on.

Mission-based authorization governs the approved task, not just the credential, session, or individual request.

This is more than a category. It is a claim about the shape of the stack. Identity, authentication, authorization, policy, and transport are named layers, and none of them governs delegated authority as an object of its own: what was approved, by whom, within what bounds, until when, and whether it is still in force. Read operationally, the missing layer is a control plane: the Mission record is desired state, issuance and the runtime gate are the data plane consulting it, and the concluding chapter develops that reading in full. The drafts decompose the layer into five deployable packages (Mission Control, Authority Distribution, Runtime Enforcement, Agent Execution Governance, and Evidence and Accountability), so the missing layer is a small set of named components rather than a monolith.

And the layer’s value is context before it is control. A resource that does not itself run the undertaking evaluates each request at perfect local resolution and zero task resolution: it can read the call and never the reason. The Mission carries task-grain context in one form that every independently built component on the path can consult, and that context cuts both ways. It makes an alarming-looking action priceable, a database deletion that is step four of an approved migration whose copy steps already ran, and it makes an innocent-looking one conspicuous, a payroll task’s agent reading the M&A folder. Neither judgment is possible at such a resource, because the why never arrives there.

The largest claim this chapter makes is that delegated authority management is a layer with no standard form, missing not from every estate but from the interoperable stack, with its own laws and vocabulary, and the Mission is one proposed standard form of it. A system qualifies as mission-based with four category properties: an approved task object (not a prompt, trace ID, session, or token), authority derived from that task, narrow-only delegation, and observable lifecycle state (expiry, revocation, completion, and expansion through a successor). It backs an action-time defense claim only with two more: runtime enforcement against current state, and evidence that binds back to the task. The Reference is the citable version of that test. This part makes the case for the object the test is about.

Three layers, one gap

An agent deployment has to answer three different questions, and only two of them have best-practices answers today.

How does the agent authenticate? That is draft-ietf-wimse-aims territory: workload identity, credentials, transport and application authentication, and the OAuth machinery for acting on a user’s behalf.

Which instance is acting, for whom? A platform’s client_id collapses every concurrent agent session into one identity, which defeats per-agent policy, audit attribution, and containment. The Actor Profile makes the delegation chain explicit, Client Instance Identification carries the specific instance’s identifier in its attestation-based client authentication, and Client Attester Endorsement lets the client endorse the attesters that vouch for its instances. Instance evidence identifies no actor by itself, and attributing a token’s use to one instance needs a key unique to that instance.

What may this instance do, why, for how long, on whose approval? That is the Mission, and it is the layer the Agent Mission section leaves open. The first two layers are necessary and not sufficient. A perfectly authenticated, perfectly attributed agent instance holding valid credentials can still be working on a task that no longer exists, with no layer positioned to notice.

Identity says who. Credentials say what may be accessed. The Mission says what the work is, who approved it, and when it ends.

How the argument converged

Several earlier lines of work expose the same structural gap from different directions:

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. The substrate problem covers protocol mechanics like discovery, resource binding, sender constraints, and metadata integrity. 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.

Authorization Is the Other Half of Executable Intent. Evals showed the pattern: take intent expressed in language and compile it into an artifact a machine can execute. That made intent executable for verification, answering whether the agent behaved. Authorization needs the same move at a higher bar, because a grant confers authority rather than evidence, and a grant that is right most of the time is a breach the rest of the time. The compiled artifact on the authorization side needs an approval path, a default that denies, and a lifecycle that ends.

AI Identity Management System. The best-practices convergence itself points here. It gives agents workload identity, credentials, and delegated user authority, then defines the Mission as the task the agent pursues and places the translation of that mission into authorization requirements out of scope. The gap is now named in the document the industry is converging on, a WIMSE working-group draft.

An earlier working series, Mission-Bound OAuth, sketched the durable governance object these lines of work point at. This chapter is the concrete answer. Mission-Bound Authorization makes the task explicit. The Authorization Server holds the Mission, commits its maximum approved authority, and governs its lifecycle. Every derived credential and decision carries a reference to it, and audit joins activity across hops on it.

The Mission as the common object

The Mission lets OAuth token issuance, runtime enforcement, delegation, and audit refer to the same approved task.

• Issuance projects the Mission into every derived token through the mission claim, carrying id and issuer (and optionally the Mission’s expires_at); the integrity anchors stay on the record. A Resource Server relies on the signed token as the AS’s assertion that the carried authority is a subset of the approved set, unless it adopts Approved-Set Verification to check against the complete set. Token issuance is gated on Mission state.
• Runtime enforcement evaluates each consequential action against the current Mission before it happens, and writes decision evidence bound to the Mission.
• Delegation is carried by the RFC 8693 act chain. A delegated token keeps the same mission claim with subset authority and an act chain identifying each actor, so revoking the Mission stops all further derivation for every actor in the chain at once. Already-issued tokens age out within their short lifetimes, or die faster where introspection or runtime checks consult Mission state.
• Lifecycle surfaces let an authorized party revoke the Mission (with suspend, resume, and complete supplied by the Status companion), and let a consumer learn its current state.
• Audit keys on the Mission and its integrity anchors (intent_hash, authority_hash, and proposal_hash where the client proposed authority), making the records tamper-evident and independently verifiable.

Without a Mission, each system carries its own implicit notion of the task. Logs join by approximate timestamps, and stopping the work means finding every credential and execution surface independently. With a Mission, each layer consumes an authenticated projection of one governance record, and revoking or expiring the Mission stops all further derivation of authority for the task at once.

What a Mission contains, and what is not one

Concretely, an approved Mission holds the approved Mission Intent (goal, target resources, purpose, human-readable task bounds, expiry), the Authority Set derived from it, its integrity anchors (intent_hash, authority_hash, and proposal_hash when the client proposed authority), a lifecycle state, and its identity (id, issuer). The Authority Set is one component of the Mission, not the whole. A bundle of permitted actions with no approved task, lifecycle, or evidence is just authority, which OAuth’s authorization_details already gave us without any of this.

That is also the fastest way to see what is not a Mission:

• A token is a short-lived projection. Its jti names the token, not the task.
• A scope or authorization detail expresses authority, not the approved task or its lifecycle.
• A session preserves runtime continuity but commits no authority.
• A consent record proves an approval happened but does not govern the work over time.
• An authorization grant, the consent behind a refresh token, comes close. With Grant Management it is durable, queryable, and revocable, but it records consent to authority, carries no task, no integrity commitment, and no derivation gating. What OAuth does not standardize is an approved-task object whose meaning persists across tokens, actors, audiences, and evidence, which is the Mission, and a deployment can still expose Mission revocation through a grant-management-style API.
• An open-banking consent, such as a UK Open Banking consent resource or an Australian Consumer Data Right arrangement, comes closest: an approved intent with its own identifier and status, bound to tokens and revocable apart from them. It lives at one data holder, with a schema its domain fixes, and governs access to that holder’s resources rather than work that spans resource servers, delegates, and runtime checks.
• A purpose URI labels a task class, with no instance lifecycle.
• A trace or task ID correlates activity but carries no approval or authority.
• A Mandate is a portable, verifiable statement about a Mission, minted by its issuer. Evidence, not a second object, and not a competing primitive.

Each is something the Mission binds to or projects into. None of them is the approved task. The full object model, a concrete JSON record, the six-property litmus, and what anchors a Mission’s legitimacy when no user is present at approval time are in the Reference’s object model.

What it buys one estate

A careful estate can compose much of this inside one administrative domain: policy engines, workflow state, and richer token claims can hold durable task state, join fan-out, narrow authority, and keep audit locally, as the composition bet concedes, and the Architecture claims standardization across bindings and trust domains, not that local systems cannot reach equivalent outcomes. The argument for one estate is this handbook’s. Even one estate crosses product boundaries. The Authorization Server, the API gateway, the MCP servers, the agent platform’s harness, and the audit store usually come from different vendors, and composition holds the task in one of them or in glue code that every other product has to be integrated to. A standard object lets each product consume the same record instead:

This is the composition bet stated for one estate, and it is what a single-domain pilot can test: whether one record, consumed by several products, costs less than the integrations it replaces.

Three objects, three lifecycles

The list above rules out artifacts inside the authorization machinery. Two more objects live outside it, in the deployment’s own systems, and an estate that runs agents under an agent identity system and this layer governs three distinct objects. Each answers a different question, each has its own owner, lifecycle, and revocation, and the model stays clean only while none absorbs another’s job.

Agent identity is the logical agent and, where client instance identification is deployed, the concrete instance. The Mission system consumes it, in the OAuth binding, as the client_id, the client-instance attestation, and validated Instance Context, and defines none of it. Defining agent identity, or the registry that holds it, is an explicit non-goal of this family.

Agent Deployment is the approved behavioral version of the agent: its code, model, system prompt, tool allowlist, data scope, and runtime configuration. A change to any of these is a new Agent Deployment, and which changes require re-approving standing Missions is policy that change governance records (the lifecycle part takes this up). The boundary composes rather than duplicates: the Agent Deployment’s tool allowlist is version-scoped, while the allowed_tools Common Constraint of the Resource Access Profile bounds tools per Mission entry, task-scoped. The name is deliberate. This object is distinct from the Mission Deployment Profile, which is the estate’s published claims manifest, not a property of an agent.

The Mission is this layer’s object: the approved task, its Authority Set, and its lifecycle.

The temptation the separation resists is overloading. A purpose field on the agent’s identity record describes what the agent is for, in general and indefinitely, which is exactly the shape of standing authority this handbook exists to retire. The Mission carries why this authority exists now, for this task, until this work ends. Keep the who durable and the why bounded.

Authorization then composes conjunctively across the three lifecycles. A decision can depend on agent state, Mission state, and credential validity, and each gates independently: a valid credential never overrides a revoked agent or a non-active Mission, and a live agent under an active Mission still fails on an expired credential. The Reference carries the working integration, what the Mission system consumes from an agent registry and the combined stack the two control planes form, and the architecture draft’s Agent Identity, Agent Deployment, and Mission section is the informative statement.

Mission, Intent, Plan, Execution

Four related concepts appear around a user-approved task. Keeping them separate prevents the Mission from becoming a vague name for every artifact in the system.

A Mission can outlive multiple plans and execution attempts. Plans and execution draw from its authority and can only narrow it. Re-planning is therefore free: the agent can observe, re-plan, and retry inside the bounds without any authorization event, because plans grant nothing, and a plan that discovers it needs authority the Mission lacks engages the discovery loop rather than editing the Mission. The Intent can be edited or refused before approval. The Plan describes how the agent intends to act but commits nothing. Execution events reference the Mission. Revoking it stops future derivation and, where state is checked, future execution. It does not undo completed actions.

This separation prevents three mistakes: treating the Mission Intent as already approved, treating an agent plan as authority, and treating an executed call as the governance object itself.

Mission versus Intent

The Mission and Mission Intent are not the same object, and conflating them is the most common mistake about this work.

Mission Intent is the proposal. Mission is the approval. The integrity anchors commit the moment of transition.

The transition is one explicit moment, the approval event. The Authorization Server validates the Intent, derives an Authority Set, the user consents to the rendered Intent and derived Authority Set, and the AS records a Mission committed by intent_hash and authority_hash (and by proposal_hash, where the client proposed authority). Before it, only Intent exists. After it, only the Mission is authoritative.

Four consequences matter most:

• Trust. Mission Intent is untrusted input. The client, the shaper, the model behind it, and the raw prompt are all the untrusted plane. The AS’s admission decision is the trust boundary.
• Authority. Intent describes a task. It does not commit authority. Authority is committed only by authority_hash over the Authority Set the AS derives from the Intent. Submitting a broad Intent asks the AS to derive from a broad task. It is not a demand for broad authority.
• Integrity. intent_hash commits the approved Intent, recorded verbatim as the client submitted it and the user approved it (not the raw prompt). The Intent itself is never edited behind the user’s back. An unrecognized target_resources entry is, by deployment policy, either omitted from the derived Authority Set or refused with access_denied; the granted authorization_details in the token response is the authoritative statement of what was granted, and a client that proposed authority compares it against its proposal, which proposal_hash commits. Validation-time narrowing applies to the derived Authority Set (committed by authority_hash). It does not rewrite the Intent.
• Lifecycle. A Mission has exactly one approved Intent for its whole life. Widening means a successor Mission (Mission Lifecycle and Change), not a second Intent.

The full treatment (the approval-event diagram, the remaining consequences, and the precise definitions) is in From a Request to an Approved Mission and the Reference.

Why this makes IBAC practical

Intent-Based Access Control is hard when intent is inferred from agent behavior at enforcement time. A policy decision point (PDP) reconstructing “what did the user want” from a prompt or a trajectory is doing probabilistic interpretation against adversarial input. It becomes practical when enforcement consumes approved intent instead of reconstructing it. The AS checks a structured proposal, the user approves it, and intent_hash and authority_hash commit the result.

The interpretation problem moves to consent time, where the accountable approver is present and the Authorization Server owns admission, instead of to enforcement time, where the agent is adversarial-input territory and the PDP has no approver to ask.

That is the design move that makes IBAC ship.

The intent-to-enforcement spine

The handbook follows one temporal spine, Intent → Mission → Authority → Enforcement:

1. Intent. A prompt or trigger is shaped into a structured Mission Intent. The shaper proposes, it does not grant authority (From a Request to an Approved Mission).
2. Mission. The Authorization Server validates the Intent, derives the Authority Set, and renders that derived set for consent. On approval it records a Mission committed by intent_hash and authority_hash (this part, and the issuance profile).
3. Authority. The approval fixes the Approved Authority Set. Containment and entry discharge only subtract from it, producing the Effective Authority Set, and tokens derived from that set under the subset rule each carry the mission claim (Mission-Bound Authority).
4. Enforcement. A PDP checks each consequential action against the current Mission state and Effective Authority Set and writes per-decision evidence (Mission-Bound Runtime Enforcement).

Each part specifies one or two steps. The spine explains when each concern enters the system. Its object-level companion is the Reference’s canonical sequence, Mission Intent to Authority Set to Mission to Projection to Runtime Decision to Evidence, which names what each transition produces.

Governance and runtime are two halves

Mission governance makes authority auditable, bounded, and revocable. Runtime enforcement is what prevents an active Mission from becoming ambient authority.

The Mission says what was approved, by whom, for how long, and within what bounds. Runtime enforcement decides whether this concrete action, with these parameters, by this actor, at this time, is allowed under those bounds. For parameter-bound writes, bounds finer than the receiving Resource Server enforces, and external side effects, the runtime layer does the safety-critical work.

This is also the lethal-trifecta boundary. The governance object is common, but private-data reads, untrusted-content ingestion, and external side effects stay separately typed and separately evaluated under it, so the Mission never becomes one ambient bundle. The architecture chapter develops both halves.

The Mission Assurance Levels name how much of this a deployment runs. They are adoption bundles, taken in the order deployments build them, and Adopting sets them side by side. In adoption order they are Baseline Issuance, Runtime-Enforced, Governed Agent, and High-Assurance Agent.

The Reference’s implementation checklist turns each bundle into checkable assurance claims, and a relying party compares the claims a deployment can show, not its level.

Where the details live

The affirmative definition of the primitive and the precise, citable definitions live in the Reference:

• The primitive, defined. The canonical decomposition is the Reference’s object model (this part’s “what a Mission contains” is the abbreviated view of it), along with what becomes possible only with a Mission, the trust boundaries and roles, and the defense of the name.
• The citable tests and structures. The Reference carries the six-property litmus and near-miss table, the object model with a concrete record, the lifecycle states, the competitive landscape, the adoption bundles, the glossary, and a reproducible integrity-hash test vector.

Where this leads

The architecture chapter continues with Adopting Mission-Bound Authorization, the staged build order in adoption bundles: the issuance-only floor on the OAuth binding and published RFCs, the Runtime-Enforced bundle above it, and a roadmap of Evaluate-only profiles, held for evaluation until deployments teach us what to harden next. The concluding chapter, Weighing Mission-Bound Authorization, carries the model beyond its bindings and the wagers. From there, the Building Mission-Bound Authorization chapter reads the Mission-Bound Authorization drafts as one layered architecture:

• Part 1: From a request to an approved Mission. Approval-time integrity: turning a prompt into a candidate Intent (shaping), committing the structured consent disclosure the Authorization Server recorded as rendered (consent evidence), and handling async or narrowed approvals (deferred approval and its revision companion).
• Part 2: Mission-bound authority. The bridge from agent identity to Mission authority: the mission claim on tokens bound to attested agent instances, the actor chain, and delegation that only narrows, from act chains to Child Missions to offline attenuation.
• Part 3: Runtime enforcement. The per-action safety layer and the heart of the Runtime-Enforced bundle. Before each consequential action, an enforcement checkpoint (PEP) gets a permit from a PDP that evaluates the action against the current Mission.
• Part 4: Lifecycle and change. State over time: Status, the Status List, and Signals for observation and revocation, expansion for governed growth, and completion and entry discharge for ending the work whole or one entry at a time.
• Part 5: The agent runtime and audit. Binding sessions to Mission state, unwinding in-flight work safely, and tamper-evident, independently verifiable evidence.

The issuance profile defined here stands on its own as the OAuth-substrate baseline. Everything else is an optional companion that layers on it without changing it, and optional means optional to the OAuth binding, not to the claims: the action-time enforcement claim needs runtime enforcement, and the Governed Agent bundle needs Consent Evidence and the harness. Least-Privilege MCP Tool Calls Need a Mission applies the full spine to a concrete MCP deployment.

The so-what is Durability and Narrowing. Authority that outlives credentials and only narrows as work fans out requires something durable for tokens to project from and narrow against, and nothing in the current stack is that thing. Now it has a name, a record, and a kill switch.