The Handbook's Vocabulary, A to Z
The handbook’s vocabulary in one lookup table, A to Z: the objects, the artifacts, the mechanisms, the roles, and the named constructs, each defined in one to three sentences with a link to its canonical home. The entries are written to be quoted. The canonical homes carry the argument.
OAuth, WIMSE, and OpenID, Mapped to the Architecture
The Mission is the architecture’s new primitive. The rest should compose. This appendix tests that claim against the ratified OAuth substrate, the complete active OAuth and WIMSE working-group queues, selected individual drafts, and the relevant OpenID Foundation specifications. It separates publication status from architectural relationship and states the important deltas and substitution hazards plainly.
Six Questions for Anyone Claiming Agent Authorization
When a vendor says they support agent authorization, ask six questions: what is the approved task object, what derives authority from it, what keeps authority strictly narrower as work fans out, what checks each action at the moment of use, what happens when it is revoked, and can an auditor pull one identifier and see the whole task. The test is intentionally unforgiving: no approved task object means no category claim, token validation is not runtime enforcement, token expiry is not revocation, and logs are not task evidence. A vendor that passes can write the honest deployment claim with level, enforcement scope, freshness, evidence, and exclusions.
Answers for the People Who Run Today's Control Planes
A skeptical FAQ for IAM practitioners and architects. Twenty-three objections test mission-based authorization against IdPs, workload identity, OAuth, RAR and UMA, short-lived tokens, PDPs and Zero Trust, Shared Signals, PAM and IGA, workflow engines, internal composition, open-world discovery, semantic misuse, enforcement bypass, lifecycle ownership, and privacy. The answers concede where existing systems are sufficient, identify where a Mission-shaped implementation may already exist under another name, and limit the standards case to the boundaries where private task state no longer reaches.
The Q3 Board Packet, Exhibit by Exhibit
The handbook argues the architecture. This appendix shows the bytes: a Mission Intent submitted through PAR, the approved record’s integrity anchors, a Mission-bound access token, an AuthZEN permit bound to parameters, a parameter_violation denial, the revocation that ends the task, the lifecycle event that announces it, and the status check that fails the 02:00 resume. Every exhibit follows the current editor’s copies, and the two integrity anchors reproduce byte for byte.
The Category, the Litmus Test, the Landscape, and the Running Example
Mission-based authorization governs the approved task, not just the credential, session, or request. This page is the field reference: the definition and litmus test for what counts as mission-based, a competitive landscape, the adoption stages, threats and non-goals, the canonical diagram and glossary, and the Q3 board-packet example threaded through the handbook.
Token-Side and Resource-Side Authorization Are Two Projections of One Approved Task
The least-privilege MCP series ends on a gap: token-side and resource-side authorization both work per call, and neither names the task the user approved. This essay applies Mission-Bound Authorization at the MCP boundary. The Mission is the durable approved task, tokens and PDP decisions are projections of it, tool discovery and invocation and approval line up against it, expansion routes through a fresh approval, and audit joins on one identifier. A denial is traced end to end to show the whole spine working.
Bounding What an Agent May See, Not Just What It May Do
Least privilege scopes what an agent may do, one tool call at a time. But a perfectly authorized agent can still be compromised by what it is allowed to see. Least exposure is the broader control: task-scoped minimal disclosure for prompt context, retrieved documents, tool schemas, secrets, business rules, approval context, memory, and downstream responses. Because the model is untrusted reasoning, every input is attack surface. A Mission should therefore bound both halves: the actions the agent may take and the working set it may reason over.
The Outside Evidence, the Named Bets, and the Handbook's Close
The handbook closes on judgment. First the strongest outside evidence: AAuth, the proposed clean-slate agent protocol, adopted a first-class mission layer in its 01 revision after this model’s AAuth mapping circulated: not independent replication, adoption by a designer free to say no, which is its own kind of proof. Then the honest bets: admission grain, issuer home, the price of Termination, the necessity of the object itself, the portability of its authority, and the classification line, each stated with the evidence that would falsify it. The laws and the claim gate are the invariants. The bets are the wagers, and deployment experience, not this handbook, will settle them.
Where the Layer Sits in the Estate
Issuance gating and runtime enforcement are two independent chokepoints, strictly stronger together: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. The Mission Authority Server, the issuance grant, the Mandate, and Cross-Domain Projection extend the pattern space. And the structural reading that platform engineers reach for unprompted: the layer is the control plane for delegated authority, mapped concept by concept from desired state to the fleet API, with the disciplines that keep the framing honest.
The Substrate-Neutral Model and Its Verb Spine
OAuth is the flagship binding because it is deployment reality, but the model does not depend on it. This part states the framework the profiles realize: four functions (compilation, projection, containment, continuity), a verb spine of nine verbs from propose to analyze, and the fundamental-versus-accidental test. Which ideas survive if OAuth disappears? Nearly all of them: the layer, the laws, the vocabulary, the approved task with an integrity-anchored record, approval evidence, runtime containment. What is accidental is the realization: PAR, RAR, the claim names, the wire shapes.
The OAuth Community's Gap Catalog, Answered Line by Line
The standards community is converging on a problem statement: agents break OAuth’s pre-approval paradigm, tokens cannot represent delegation chains, revocation cannot reach a task, and consent screens cannot survive a thousand scopes. The agent authorization use-case catalog names nine scenarios and rolls its analysis up to five major gaps, and this part answers the catalog line by line at both grains with machinery that existed before it was published: task-level revocation is the Mission kill switch, bulk revocation is Mission Management, multi-hop chains are act chains and Child Missions, scope explosion dies at Mission-grain consent, and the paradigm mismatch is the discovery loop. One answer is partial and one is delegated, and the tally is stated rather than smoothed.
What NIST AI RMF, the EU AI Act, and ISO/IEC 42001 Ask Agents to Prove
The third kind of outside framing is the one with auditors behind it. NIST AI RMF, the EU AI Act, and ISO/IEC 42001 converge on one demand: show me. Show me who is accountable, what the system is for, how you observe it, and how you stop it. In most agent stacks the honest answer is archaeology through session logs. In this architecture the artifact that enforces is the artifact that documents: the Mission is the documented purpose, the approval is the accountable decision, the evidence family is the log, and Termination is the interrupt. The crosswalk maps eight obligations onto machinery that exists for safety reasons, and then names what compliance still requires, because evidence is not certification.
Fifteen Agentic Threats and the LLM Top 10, Each Given a Verdict
Security reviewers do not arrive with your framing. They arrive with OWASP’s: fifteen agentic threats from memory poisoning to human manipulation, plus the LLM Top 10. This part crosswalks both onto the handbook and refuses the move that makes crosswalks worthless, claiming everything. Each threat gets one of three verdicts. Contained means the threat lands on machinery built for it, with a draft behind it. Bounded means the cause is out of authorization’s reach but the blast radius is capped at the action gate. Delegated means it is not an authorization problem and a named complement owns it. Six of the fifteen are contained, nine are bounded, and half the LLM Top 10 is honestly someone else’s layer.
A Critical Crosswalk from Patrick Parker's Seven Laws to Mission-Bound Authorization
Patrick Parker’s Seven Laws of AIdentity describe the dynamics a system must govern when agents act through delegated authority: split actors, generated intent, bounded agency, continuous authorization, least exposure, justifiable action chains, and proof-carrying action. This part maps those laws onto Mission-Bound Authorization without turning resemblance into compliance. The strongest matches are generated intent and bounded agency. Continuous authorization and split-actor attribution require the runtime and identity profiles. Least exposure, chain necessity, policy retention, evidence completeness, and embodied action remain conditional or outside the current wire model.
How Mission-Bound Authorization Contains the Defining Agent Threat Model
Simon Willison named the combination that makes agents dangerous: access to private data, exposure to untrusted content, and the ability to communicate externally, held together in one loop. Any two legs are safe. All three are an exfiltration machine waiting for a poisoned document. This part runs the handbook against that threat model: the three legs become separately typed action classes under one Mission, the external leg becomes a consequential action that needs a fresh parameter-bound permit, mediated custody keeps the egress credential out of the agent’s hands, and the harness downgrades egress once untrusted content enters the session. Then the honest residuals: enforcement scope, composition, and the semantic gap.
Sessions Are Not Authority, Safe Unwinding, and Tamper-Evident Evidence
The first five layers make the Mission approvable, enforceable, governable, and delegable. This operational close makes them hold up against a real agent: a harness that treats session continuity as recoverable state and not as authority, an orchestrator that unwinds work already in flight when a Mission stops, and a transparency profile that makes the suite’s evidence independently verifiable across trust domains. It closes with a synthesis of the six operational layers and the Mission Assurance Levels, the practice-side view of the adoption path the architecture chapter stages.
Observe, Revoke, Grow, Complete
The issuance core gives a Mission three states and gates derivation on active. This part adds the surfaces that make state actionable over time: Status for canonical pull freshness with Signals as its push complement, Expansion for governed growth, and Completion for monotonic narrowing. One rule threads through all four. Only active permits reliance, so every state a newer profile adds fails safe for a consumer that predates it.
From Mission-Bound Tokens to Mission-Bound Actions
OAuth issuance bounds what authority may exist. It does not check the action at the point of use, so an active Mission becomes ambient authority within a token’s lifetime. The runtime layer closes that gap. A PEP at each consequential execution boundary obtains a permit from a PDP that evaluates the action, its parameters, the actor, and the current Mission state before any consequential effect occurs. The runtime profile fixes the invariants. The AuthZEN profile is its concrete wire binding.
From Authenticated Agent Identity to Bounded, Narrowing Authority
The AI agent auth best practices give an agent workload identity, credentials, and delegated user authority. This part binds Mission authority to that identity. The mission claim projects the approved task into every derived token, attested instance identifiers and actor chains keep every actor attributable, and delegated work gets explicit, narrower, separately revocable authority. A sub-agent that acts because it descends from a parent session is inheriting ambient authority, not delegated authority. Child Missions give durable sub-agents their own revocable handles with strict-subset authority and cascade revocation. Offline attenuation, the experimental roadmap for fan-out at scale, keeps the Authorization Server off the hot path with the runtime state check as the surviving kill switch.
Shaping, Consent Evidence, and Deferred Approval with Revision
A user request is untrusted input. This part covers the integrity of the approval event, the layer before any token exists: the client-side shaper that proposes a candidate Mission Intent, the Consent Evidence that commits the structured consent disclosure the Authorization Server recorded as rendered (not the pixels or the Approver’s comprehension), and the deferred and revisable approval that lets a human reviewer narrow a proposal in place. Authority is created only when the Authorization Server validates, narrows, and approves.
Crawl, Walk, Run
A definitive architecture that ends without a build order is a tour, not a blueprint. Most estates start at the read-only ceiling: agents capped at read access, humans approving or executing the writes, and pilots that never graduate. This closer names what that posture costs and stages the way off it: crawl by shipping the issuance core (approved, integrity-anchored Missions and a possession-independent kill switch, honestly labeled governance rather than safety), walk by adding the Runtime-Enforced level (per-action enforcement, the AuthZEN binding, and Status freshness, all on substrate that already shipped), and run by climbing to the Governed and High-Assurance Agent levels, each of which makes a broader class of write authority defensible. Plus the ecosystem to compose with, the five operational surfaces you will own, and the pieces the community still has to standardize.
The Missing Object Above Tokens and Sessions
The AI agent auth best-practices draft names the Mission and declares its translation into authorization out of scope. This is the core argument on the other side of that line: why the approved task is the missing object above authentication and instance identity, how the argument converged, the Mission-versus-Intent boundary, and where to start. The definitions, object model, lifecycle, and glossary live in the Reference.
Translating the Corporate-Card Model into Mission-Bound Authorization
What the Corporate Card Already Solved walked a working delegated-authority architecture one control at a time and never mentioned a protocol. This part is the joint between that mental model and this chapter’s architecture. The five rules the card world taught become the five laws of delegated authority, stated for any substrate. The corporate-card test becomes the claim gate a vendor claim must pass. And the build lists that closed each card post, the things the agent stack cannot borrow from the expense world, turn out to enumerate the draft family: disclosure integrity, field-speed narrowing, checkpoints per boundary, endings that propagate, and a record that earns trust without a bank.
Endings, Unwindings, and the Statement That Reconciles It All
Cancel a card and watch what refuses to end: the subscription bills the new number the network helpfully forwarded, the pending hotel charge settles days later, and the refund arrives through a process you do not control. Payments learned that ending an instrument is not ending an arrangement, and built machinery for the difference: reversible freezes, terminal cancellations, single-use cards that retire themselves, in-flight states between authorized and settled, chargebacks as governed compensation, and the statement that reconciles everything to one project code. This part maps each ending onto the agent task that must actually stop, and closes with the breaks, including the one where the analogy runs backward.
Per-Action Authorization, and the Escape Hatch Called Cash
A decline at the register is mild embarrassment and a tap of a different card, because the system is working: the network approves transactions, not cards. This part walks per-action authorization the way payments runs it: the plastic that proves almost nothing, the authorization that binds this amount at this merchant now, the hotel hold that expires, the freeze that declines the next swipe wherever the issuer decision is checked, and the ATM, the escape hatch every honest card program names in writing. Then the breaks: agents have no common payment-style network, their false-approval costs are unbounded, and their cardholder can be hypnotized mid-purchase.
Why Delegated Authority Must Narrow, and Never Be Borrowed
Crunch week. The contractor needs materials, and the project manager hands over her own card, just this once. Everything about it is convenient and everything about it is wrong, and every finance team knows exactly why. This part walks delegation the way a mature card program runs it: the contractor’s own card with a lower limit, attribution that survives the handoff, cards that die when the project closes, and caps on how many cards a project may issue, not just how big each one is. Then the three places the analogy breaks for AI agents, where the fixes have to be built.
What Spend Approval Knows About Approving an Agent's Task
A manager approves a conference request on their phone between meetings. Months later, the only defensible answer to ‘what did you approve?’ is the request as rendered on that screen. This part walks the anatomy of a real approval: requests that are proposals and nothing more, reviewers who narrow instead of denying, decisions that take days without losing their place, and the disclosure that binds. Payments turned that last idea into regulation. Then the honest part: three places the analogy breaks for AI agents, and what each break demands.
What Expense Governance Already Knows About Delegated Autonomy
Nobody hands a new hire the company checkbook. In a mature spend program, they get an instrument bound to an approved purpose, checked at each transaction, metered against a budget, and frozen when the reason for the spend goes away. Agent credentials today are blank checks with expiry dates. This part walks the expense-governance loop end to end, maps each control onto agent authority, and is honest about the five places the analogy breaks. Each break is something the agent stack still has to build.
Long-running agents discover mid-task that they need a destination their egress proxy does not allow, and the block comes back as an opaque connection failure with no machine-actionable way to ask for access and no human standing by. That block is a requestable denial, and the egress proxy is a policy enforcement point. RFC 8908, the Captive Portal API, supplies the recovery state machine for a blocked client on a network: discover captivity, learn the remediation endpoint, and retry after policy changes. A headless agent can use that state machine, with the denial carried by Proxy-Status and Problem Details where an HTTP response exists and by an authenticated side-channel status API where it does not. The recovery can ride the captive portal at two altitudes, destination-level on a proposed AuthZEN Access Request profile or operation-level on AAuth and Mission-bound authority. When the client already speaks AAuth, it needs no captive-portal shim at all, because AAuth carries the refusal and re-authorization in-band at the same request boundary the proxy already enforces.
Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the continuation handle never reaches a Resource Server.
Identity Assertion Trust Framework and Domain-Authorized Issuer Trust Method
Self-service agent sign-up exposes a first-contact trust problem: a Resource Authorization Server can verify a perfectly valid JWT and still not know whether the issuer is allowed to assert identities for the user’s domain. That is two questions, not one. Federation proves the issuer is authentic, but not that the namespace owner authorized it, and static allowlists do not scale to onboarding unknown domains at runtime. The Identity Assertion Trust Framework lets a Resource AS publish the evidence it requires. The Domain-Authorized Issuer Trust Method lets a domain owner publish which issuers may assert identities in its namespace, fail-closed, the way mail and the web already pushed authority into DNS. Both compose with ID-JAG and the JWT-bearer grant without changing the grant surface.
AuthZEN, ARAP, and the Task Neither Names
Part one laid out two ways to lock down a single tool call an agent makes through the Model Context Protocol: carry a narrow token, or let the resource decide each call. This part walks the standards that close the gaps. AuthZEN gives a standard way to ask the policy question, the Access Request and Approval Profile turns a denial into a governed request for approval, and a set of proposals carries that approval over the wire. Each makes one call’s authorization more interoperable, and none gives a multi-step task a shared identity. So a string of individually correct calls can still drift from what the user approved. The missing piece is a durable, governed record of the approved task, the object I call a Mission.
Carry Authority in a Token, or Decide at the Resource
There are two natural ways to lock an agent’s Model Context Protocol (MCP) tool calls down to least privilege. The agent can carry a narrow token scoped to the action, or the server can decide each call as it happens. Carrying a token gives portable proof of what the agent may do, but pushes domain knowledge onto the authorization server and token management onto the client. Deciding at the resource keeps the meaning where it lives, but the decision is not portable. MCP makes the tool boundary first-class for both. This part compares the two models and how to choose. Part two covers the standards that close the per-call gaps and the task object neither names.
Evals Made Intent Executable for Verification. A Mission Makes It Executable for Authorization.
Microsoft’s ASSERT compiles written behavior requirements into executable evaluations: intent made executable for verification. That answers what the agent did, not what it was allowed to do: an eval produces a verdict, not a binding authorization decision, and for irreversible actions that is the whole difference. The mission is the preventive counterpart: a shaper proposes the request as a bounded, machine-readable object, a trusted authority validates and narrows it, an approver signs off, and enforcement checks every consequential action against it. Same lineage from natural-language intent, a higher bar, and teeth an eval does not have. One approved mission then drives both the runtime boundary and the behavioral eval, while a separate shaping-quality check asks whether the boundary matched the user’s intent in the first place.
In Cross-App Access, a single signed-in user’s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant.
Closed-world authorization treated denial as the end of the interaction. Agents, runtime discovery, delegation, and mission expansion turn denial into the beginning of governance escalation. The draft AuthZEN access request and approval profile standardizes that handoff without standardizing the workflow engines behind it. Client-Initiated Backchannel Authentication (CIBA) is not the answer because the problem is not authentication freshness. It is whether authority should continue under newly discovered runtime conditions.
WorkOS auth.md is an agent-readable registration document for one-click setup, with Agent Verified, user-claimed, and anonymous paths. In the Agent Verified path, most pieces already exist across OAuth and OpenID standards: ID-JAG, OAuth metadata, dynamic client registration, standard token endpoints, and SSF/CAEP/OPC. The standards gap is a profile for runtime agent onboarding and trust establishment, not a new grant protocol.
Why Agent Harnesses Cannot Own the Mission Layer
Modern agent harnesses make work durable across restarts, devices, background jobs, and sub-agents. That durability is a runtime property, not a governance property. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working. Conflating them is a central failure mode of long-running autonomous agent systems.
Client instances are not new clients. They are actors. With the Actor Profile and the act chain already in place, and an instance_issuers field that fits any client registration channel (static, Dynamic Client Registration, or CIMD), treating instances as first-class actors needs no new grant type, no new client type, and no new claim. It needs a profile that ties them together.
Enterprise SaaS still defaults to app-by-app OAuth islands with their own clients, long-lived artifacts, and revocation paths. The architectural shift is OAuth federation: adopt issuer-mediated federation now for services and workloads, and adopt Cross-App Access (XAA) as the standards direction for user-delegated cross-app access.
The new version of AAuth (draft-hardt-aauth-protocol-01, since resubmitted as draft-hardt-oauth-aauth-protocol) materially changes the earlier comparison. Mission is now first-class in the protocol, with PS-mediated approval, mission-aware token choreography, and governance endpoints. The remaining gap is no longer whether Mission exists, but whether the published model is strong enough to support portable containment rather than just mission correlation and governance hooks.
ID-JAG, also often called Cross-App Access (XAA), is centered in the current draft on Enterprise IdP trust, but the issuer that matters is the immediate IdP the downstream authorization server already trusts for SSO and subject resolution, not necessarily the top-level workforce IdP. The same trust pattern can also extend architecturally to CIAM and platform identity layers that federate upstream workforce login while remaining authoritative for downstream product trust, tenant context, and subject resolution.
Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.
OAuth was built for closed worlds, and that constraint is why it became mature. Agents expose the limits of that deployment model. This post traces what the newer OAuth standards get right and which substrate gaps still need to close.
Part 2 turns from the semantic problem to the runtime one. Quiet expansion, delegation, headless execution, stale state, and open-world execution all push Mission shaping past its strongest domain. Containment and runtime governance carry more of the safety burden.
This essay picks up from Part 4 of the Mission-Bound OAuth series and focuses on the first hard problem: how approved intent becomes a governable Mission. In structured domains that can look like staged Mission shaping or compilation. Many current deployments still do not do it at all.
Mission-Bound OAuth is a serious attempt to govern delegated agent authority using existing OAuth infrastructure. This post takes the pessimistic view: it may be the wrong answer because it asks the authorization server to become a governance engine, a lifecycle controller, and a mission ledger all at once. A cleaner alternative is to treat Mission as a separate authority service and let OAuth be one projection of that model rather than its home.
Mission-Bound OAuth argues for a durable Mission object that governs delegated authority across approval, lifecycle, delegation, and termination. This follow-up asks whether Dick Hardt’s AAuth draft is a better protocol substrate for the same model, and where AAuth still appears to need an explicit Mission-like authority object.
Rich Authorization Requests are the natural first instinct for agent missions, but audience-bound access tokens and uneven cross-domain interoperability limit how far they can carry a governed task. Mission-Bound OAuth solves that by making the Mission a durable authority object at the authorization server. This post explores the authentication-layer companion profile: OpenID Connect Client Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.
OAuth answers whether a request is permitted right now. Mission-Bound OAuth asks whether a delegated mission should still be running at all. This RFC proposes a durable Mission object at the Authorization Server that governs token derivation, lifecycle, delegation, and termination across agent execution.
Enterprise IAM was designed for human-paced execution. Agents remove the presence, pacing, and natural scope-limiting that made those controls work. The result is a structural gap that stronger credentials, tighter scopes, and faster JIT provisioning cannot close.
Tokens, credentials, and scopes tell a system what an agent may do. They say nothing about why execution was authorized or when it should end. The Execution Mandate is the primitive that closes that gap: a signed, inspectable authority record that runtime systems can evaluate and revoke throughout the execution lifecycle.
An Execution Mandate defines what delegated authority looks like. This post builds the control plane that makes it operational: how mandates are issued and held as authoritative artifacts, how authority is evaluated continuously rather than at gates, how governance crosses organizational boundaries, and where enforcement lands in practice.