This is the essay of the publication’s fast path: the category case in five minutes. The vendor test and the blueprint are its companions, and the deep library is one link away throughout.

At 23:00 the board meeting is cancelled, and the reason for the agent’s work disappears with it. At 02:00 the agent’s runtime wakes and resumes drafting the board packet. Every credential in its session is still valid. Every scope still matches. The agent is authenticated exactly as the best practices prescribe. By every rule the stack knows how to check, the work should continue. The one fact that should stop it is a fact no layer can represent. The approved task no longer exists.

That is the failure this category exists to close, and it is worth stating as plainly as possible:

Agent auth today can prove who is acting and what credential they hold. It cannot prove the work is still authorized.

Look at what each layer of the stack actually answers. Identity says who exists. Authentication proves who is present. Tokens say what authority was granted. Sessions say the runtime survived. A policy decision point evaluates one request at a time. None of them owns the question an autonomous agent runs on: what was approved, by whom, within what bounds, until when, and whether it is still in force. Human-driven software never needed that layer, because a person at a keyboard naturally terminates their own intent. Agents remove the person, and the gap becomes the failure mode.

This is not a hypothetical gap. The industry’s converging best-practices document for agent identity, draft-klrc-aiagent-auth, names the Mission as “the task or objective the Agent will pursue” and then declares the process of translating it into authorization requirements out of scope. The gap has a name in the document everyone is converging on. It does not yet have an object. And the timing is not incidental: AuthZEN went Final in January 2026, MCP standardized the tool boundary where enforcement has to land, and agents crossed from drafting to executing, in an open world where tools are discovered rather than configured. Every layer around the missing one has hardened, which is exactly when the missing one becomes the bottleneck.

The object matters because credentials are the wrong unit of governance. A credential can be valid while the work is invalid. A token can be fresh while the purpose is dead. A session can resume perfectly while the task it resumes has been cancelled. That is not a bug in identity, OAuth, or policy decision points. It is a missing layer above them.

Enterprise finance already built the pattern. A corporate card is not permission to spend. It is a bounded projection of an approved purpose, checked at every swipe against live state, and frozen the moment the reason for the spend goes away. Enterprise spend is not controlled because cards are secure. It is controlled because every card is continuously bound to a business purpose. What the Corporate Card Already Solved walks that working system one control at a time, and From the Card to the Architecture translates it. Agent credentials today are the card program nobody would run: no purpose attached, no per-use check, nothing that ends when the reason does. A blank check with an expiry date.

The missing object is the approved task itself, made first-class. This publication calls it the Mission: a durable, approval-backed governance record that authority is derived from, tokens and decisions bind back to, enforcement consults at the point of use, and lifecycle ends when the reason for the work ends.

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

Any implementation of that object, whatever it is called, has to satisfy five laws:

  1. Durability. Authority must outlive credentials.
  2. Attribution. Every action must remain attributable, and the approval record must commit exactly what the approver was shown.
  3. Narrowing. Authority can only narrow as work fans out.
  4. Termination. Revocation must end authority, not merely tokens.
  5. Containment. Execution must continuously remain inside approved purpose.

Run the familiar alternatives against those laws and each one breaks at least one: scopes and short-lived tokens break Durability and Termination, sessions break Durability, a PDP alone has no task to check against, and approval prompts collapse at exactly the scale where agents are useful. The Field Reference runs that argument row by row. The category is forced, not preferred: an architecture that satisfies all five laws contains a Mission-shaped object.

The count matters. There are five laws because they are the substrate-neutral invariants of delegated authority. The six-property test is different: it is the public claim gate for a deployed system. It adds the concrete surfaces that make the laws observable: an approved task object, authority derived from it, tokens and decisions bound to it, per-action runtime enforcement, observable lifecycle state, and evidence that joins on the task’s identity. Anything claiming mission-based authorization either has all six properties or it is claiming something else, and the vendor test turns them into the questions to ask.

Two honesty clauses keep the category from becoming marketing.

First: a mission-bound token without runtime enforcement is governance metadata, not agent safety. The object earns its keep at the point of use or not at all.

Second: mission-based authorization does not make the agent’s reasoning trustworthy. It bounds authority structurally: the approved task, the derived authority, the actor, the parameters, the lifecycle state, and the evidence. Where the content itself is the harm, such as a confidential email body or an external commitment, the answer is not a smarter token. It is runtime review, action-bound approval, or a mediated path that keeps the agent from holding the dangerous instrument directly.

And the starting point is deliberately small. The minimum useful deployment is four pieces on ratified substrate: an issuance core that records the approved task, runtime enforcement with a standard decision wire, and a status surface consumers can check. The blueprint fits on one page, and Adopting Mission-Bound Authorization stages the whole path as crawl, walk, run.

The depth is where it should be, one layer down. The corporate-card series teaches the mental model with no protocol in sight. The Mission-Bound Authorization series carries the architecture: the object, the laws, the build order. The Building Mission-Bound Authorization series carries each control at wire depth. And the Field Reference is the citable appendix for all of it.

The industry knows how to authenticate an agent. It does not yet have an object for the work the agent was trusted to do. That is the whole proposal: give the approved task a name, a record, a runtime check, and a kill switch, and make credentials, decisions, delegation, lifecycle, and audit projections of that object.