The Mission Is the Missing Abstraction

Overview

The industry’s best-practices path for AI agent identity is taking shape. AI Agent Authentication and Authorization 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 (10.1 in the current -03) 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. One warning travels with the whole argument, and it is settled in Mission-Bound Runtime Enforcement: a mission-bound token that nothing enforces is record-keeping, not agent safety. The object defined here earns its keep at the point of use.

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 evaluates each request at perfect local resolution and zero task resolution: it can read the call and never the reason. The Mission is the one place where task-grain context exists to be consulted, 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 the 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 substrate properties: an approved task object (not a prompt, trace ID, session, or token), authority derived from that task, narrow-only delegation, and a lifecycle that can expire, revoke, expand, and complete. 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-klrc-aiagent-auth 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, the Client Instance Assertion identifies the specific instance, and the AI Agent Instance Profile adds attested instance identifiers and agent provenance.

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 Agent Authentication and Authorization. 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.

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, issuer, and authority_hash. 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), 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, resources, constraints, expiry), the Authority Set derived from it, its two integrity anchors (intent_hash, authority_hash), a lifecycle state, and its identity (id, issuer). The crucial relationship is that 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.
• 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.

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 the instance profiles are deployed, the concrete instance. The Mission system consumes it as the client_id, the instance assertion, and verified instance claims, 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 core’s allowed_tools Common Constraint 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 Three Objects, Three Lifecycles section is the normative 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. 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 (the post-validation form the user consented to, not the raw prompt). The Intent itself is never edited behind the user’s back. An unrecognized resources entry causes the AS to refuse the submission or, by deployment policy, to omit the entry from the derived Authority Set with the partial derivation signaled to the client. 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 core).
3. Authority. The Mission’s canonical Authority Set is projected into tokens that each carry the mission claim (Mission-Bound Authority).
4. Enforcement. A PDP checks each consequential action against the current Mission 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 any agent that touches consequential writes or external side effects, the runtime layer is doing the safety-critical work. That is why the sharpest way to state it is:

A mission-bound token without runtime enforcement is governance metadata, not agent safety.

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.

How much of this a deployment runs is a claimable level, the Mission Assurance Levels, and the taxonomy recurs through the handbook:

The Reference’s implementation checklist turns each level into a checkable claim.

Where the details live

This part is the argument. 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 deployment ladder, the glossary, and a reproducible integrity-hash test vector.

Where this leads

This is the framing post. The architecture chapter continues with Adopting Mission-Bound Authorization, the staged build order: the Runtime-Enforced level on ratified substrate now, the experimental roadmap as 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 load-bearing safety layer and the heart of the Runtime-Enforced level. 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 and signals for observation and revocation, expansion for governed growth, completion for safe narrowing.
• 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 core 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 protocol core, not to the claims: runtime enforcement is required for the Runtime-Enforced claim, and Consent Evidence and the harness are required for the Governed Agent claim. 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.