---
title: "Agents Need a Mission, Not Just Credentials"
date: "2026-06-07T09:00:00-07:00"
lastmod: "2026-06-07T09:00:00-07:00"
description: "The category-defining essay for mission-based authorization: agent auth can prove who is acting and what credential they hold, but not whether the work is still authorized. The missing object is the approved task. This essay makes the case in five minutes and points to the test, blueprint, and deep library."
summary: "The five-minute case for the category. A cancelled meeting at 23:00, an agent that resumes at 02:00 with every credential still valid, and the one fact no layer of the stack can represent: the approved task no longer exists. Enterprise finance solved this pattern decades ago for money. This essay names the missing object, the laws it must satisfy, and the six-property test for anything that claims to be it, then hands off to the public canon: the vendor test, the minimum viable blueprint, and the deeper series."
slug: "agents-need-a-mission-not-just-credentials"
tags:
  - "Agentic Identity"
  - "Authorization"
  - "Mission-Bound Authorization"
  - "Delegated Authority"
  - "OAuth"
---


> This is the essay of the publication's fast path: the category case
> in five minutes. The [vendor test](/notes/mission-based-authorization-vendor-test/)
> and the [blueprint](/notes/minimum-viable-mission-based-authorization/)
> 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](https://datatracker.ietf.org/doc/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](/series/what-the-corporate-card-already-solved/)
walks that working system one control at a time, and
[From the Card to the Architecture](/notes/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](/notes/mission-bound-authorization-reference/#competitive-landscape)
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](/notes/mission-based-authorization-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](/notes/minimum-viable-mission-based-authorization/) fits on
one page, and
[Adopting Mission-Bound Authorization](/notes/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](/series/what-the-corporate-card-already-solved/)
teaches the mental model with no protocol in sight. The
[Mission-Bound Authorization series](/series/mission-bound-authorization/)
carries the architecture: the object, the laws, the build order. The
[Building Mission-Bound Authorization series](/series/building-mission-bound-authorization/)
carries each control at wire depth. And the
[Field Reference](/notes/mission-bound-authorization-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.