This page is for the people who run today’s control planes: an IdP for human access, workload identity for the fleet, an Authorization Server for credentials, a PDP for decisions, PAM for privileged access, IGA for entitlements, and workflow systems around all of them. The recurring question, “isn’t this something we already operate?”, deserves its strongest answer rather than a category boundary drawn for convenience.

The answer is sometimes yes. Existing products can keep task state, carry purpose attributes, issue task-specific credentials, and gate actions. A system that makes an approval-backed task record the root of authority and enforcement may already implement mission-based authorization within its declared scope, whatever it calls the object. The standards case begins where that private state must cross a boundary the platform does not own.

Use four questions throughout the page:

The handbook calls that root object the Mission and the surrounding function the control plane for delegated authority. It composes with the systems above rather than requiring their removal. The Field Reference carries the definitions and the competitive landscape these answers lean on, and the vendor test turns the category into six questions to ask anyone claiming it.

The test is behavioral, not nominal. A workflow record that passes it can be Mission-shaped. A product labeled “mission-aware” that merely adds a token claim does not pass. Most objections below therefore turn on whether an existing artifact supplies one input, or actually owns the approval, derivation, enforcement, lifecycle, and evidence relationship.

Jump by the plane you run: identity and workload, credential, decision, privileged and entitlement, workflow, or go straight to the hard questions.

The identity and workload plane

“Our IdP is our control plane. Why is this not just an IdP feature?” The IdP is the control plane for authentication and human access: identities, authentication events, sessions, and federation. OIDC and SAML do not standardize an approved-work object or its lifecycle, but an IdP product can add one. If that feature owns the approval-backed task record, derives authority from it, and makes its state available to the claimed enforcement paths, it is a valid local implementation of the category. On the OAuth binding, the Authorization Server, often part of the same platform, can host the Mission record and gate issuance on its state. Where that product cannot change, the standalone Mission Authority Server carries the record with a PDP join at the point of use. The distinction is a responsibility boundary, not a requirement to buy another control plane.

“We run workload identity and a non-human identity program: SPIFFE, attested instances, inventoried and rotated credentials.” Keep it. Mission-Bound Authorization composes with that stack: instance attestation and sender constraint are inputs, not alternatives. Custody governs the credential, inventory knows what exists, and attestation supports a claim about which workload is speaking. Those identity functions do not by themselves identify the approved task. An attested workload with freshly rotated keys can still resume work whose approval ended. Deployment policy can bind workload identity to private task state; the Mission standardizes that binding when it must cross systems. An NHI program answers what non-humans exist and what credentials or entitlements they hold. The Mission answers what approved task governs a particular use of that authority, and Mission-Bound Authority is where the two bind: the mission claim rides tokens that are already instance-bound and sender-constrained. The same analysis applies to existing automation: a CI pipeline, Terraform apply, or reconciling controller becomes a candidate for task-bound authority when its work outlives one request or crosses enforcement domains.

“Isn’t this just a session?” A session primarily preserves runtime continuity and may also cache authorization state. A server-side session record can even carry a task identifier. What sessions do not standardize is an approval-backed task lifecycle from which authority is derived across credentials, actors, and domains. If a session record does own those semantics and every claimed action is gated on its current state, it may be a sufficient local implementation. Sessions Are Not Missions gives the general distinction: resume state must remain subordinate to the governing task, not become evidence that the task still stands.

The credential plane

“Isn’t this just RAR?” Rich Authorization Requests can express fine-grained, resource-specific authorization requirements and can be the subject of an OAuth approval flow. An API-defined RAR type can also carry a task identifier. That makes RAR a natural serialization for an Authority Set, not evidence that RAR itself defines the governing task. RFC 9396 does not standardize a cross-domain task identity, lifecycle, current-state surface, evidence model, or comparison rule for arbitrary authorization-detail types. A deployment may define all of those around RAR; when it does, the surrounding object and behavior, not the JSON parameter alone, are the Mission-shaped part.

“Isn’t this just UMA?” UMA is closer than a token-format analogy. UMA 2.0 lets a requesting party’s client use a permission ticket to seek a requesting party token (RPT) for protected-resource access asynchronously from the resource owner’s authorization. Its authorization server evaluates resource-owner policy conditions and requesting-party claims and can manage grants over time. UMA’s companion federated-authorization specification also allows authorization and resource servers to be loosely coupled. It directly disproves any claim that OAuth-family authorization always requires a synchronously present resource owner.

The remaining distinction is the governed object and its scope. UMA standardizes party-to-party access to protected resources; it does not standardize a cross-system undertaking whose approved Authority Set is the source of credential projection and, where supported, delegation, whose current state gates claimed consequential paths within a declared scope, and whose evidence joins across the work. A UMA deployment can define that task object and bind permission tickets, RPTs, policy changes, and enforcement to it. If it does, it may implement mission-based authorization under UMA rather than compete with it. Mission-based authorization should reuse UMA’s asynchronous and claims-gathering patterns where they fit.

“Why not just short-lived tokens?” Short lifetimes bound staleness. They do not represent the task, and they make the wrong thing the clock. A revoked task keeps deriving fresh short tokens unless issuance is gated on task state. Token lifetime alone also supplies no common task identifier for cross-system evidence. Mission-bound deployments use short-lived tokens too. They are a control inside the design, not a substitute for the object. And the bridge form is different from tokens alone: short-lived tokens minted under state-gated issuance are the Baseline pattern for estates whose resources cannot check state, a conforming freshness source with revocation explicitly bounded by the token lifetime (the Reference’s revocation matrix prices it).

“This drags authorization back to stateful. The industry spent twenty years going stateless.” Stateless validation was real progress, and Mission-bound tokens can still verify offline. But offline validation cannot provide fresh revocation without some state signal, introspection, revocation list, or bounded credential lifetime. Short lifetimes choose the last option, which is a freshness source with the dial set to the token lifetime, the state tax paid at the issuer on every refresh. This architecture makes the availability and staleness trade explicit: each action class chooses its bound, permits can amortize round-trips, the coarse end (bounded staleness at the token lifetime) adds no new state dependency at all, and only the classes whose consequences justify it pay for per-action freshness. The objection still lands on availability: a state service or PDP becomes a tier-0 dependency for each path that fails closed on it. Leases, caches, replication, and scoped degradation reduce that cost but do not erase it. The revocation bet names the wager and the deployment evidence needed to evaluate it.

The decision plane

“Our PDP already evaluates every request, and our Zero Trust architecture verifies continuously.” A PDP can evaluate purpose or task state if policy receives those attributes, and Zero Trust does not forbid doing so. NIST’s Zero Trust Architecture already places a PDP and PEP around access to enterprise resources. The question is where trustworthy approved-task state comes from and who owns its lifecycle. Without that input, repeated evaluation can keep permitting a cancelled task because actor, device, and resource policy remain valid. Mission-based authorization does not replace the PDP or the doctrine; it defines one governed input and its state semantics. The AuthZEN binding carries that input to the decision point. The control-plane reading states where that input lives, and the runtime profile is the per-action check, with its enforcement scope and freshness bound made part of the deployment claim.

“Isn’t this just CAEP and Shared Signals?” The transport pattern is right, and the family reuses it. The Shared Signals Framework is intentionally extensible: cooperating parties can define event types and subject identifiers beyond those in CAEP. That means a Mission event can ride this substrate; it does not mean the substrate defines the Mission object or its lifecycle semantics. Mission Lifecycle Signals are Security Event Tokens used as the push side of the freshness dial. Existing Shared Signals plumbing keeps its job. The Mission profile adds an agreed subject, transition vocabulary, and state authority, with Status as the fail-closed pull underneath push delivery.

The privileged and entitlement planes

“Isn’t this just PAM, or an IGA request?” Closest cousins, and the differences are the point. IGA often produces standing entitlements, and PAM often binds elevation to an identity, ticket, session, and time window. Mature deployments can already make those grants task-aware. The category test asks whether the task record is merely approval context or the continuing authorization root: is authority derived from it, are claimed consequential paths checked against current state, and does termination propagate within a published bound? A PAM or IGA product that does all of that may already be Mission-shaped within its scope. Deferred Approval is designed so an existing request workflow can drive the approval rather than be replaced. The same machinery can produce task-scoped human access today, which is the better IGA outcome in one sentence.

“Our agents are standing. The work never ends.” Then the authority should cycle even though the agent does not. The standing charter becomes a consented ceiling, each unit of work draws a bounded Mission from it under policy, discharge retires what each unit used, and the ceiling’s renewal is a governance review with the last cycle’s evidence in front of the reviewer, not a habit. The standing agent at scale carries the pattern, and the tell that it has decayed into a blank check with a calendar: renewals that never narrow.

“Everything still hangs on a human meaningfully consenting. That is the consent screen, again.” The approval event requires accountability and delegated authority, not a human click for every Mission. An accountable approver decides against committed inputs before authority exists: a person for decisions that require individual judgment, or an authorized policy operating within an organizationally approved ceiling for repeatable work. Nor is the disclosure take-it-or-leave-it. The approver can interrogate it before deciding, with answers drawn from recorded shaping material, and the interrogation lands in the record. That does not prove meaningful understanding. Consent Evidence records the disclosure and decision; it cannot prove the approver read, understood, or wisely accepted them. Mission-grain fatigue is therefore a security constraint rather than a UX footnote. The fatigue budget spends human attention on the ceilings and the guard exceptions instead of per Mission, and shaping keeps the disclosure readable enough to decide on. Generated judgment is not accepted as the sole granting authority for attacker-influenced proposals, because the approver would share the agent’s injection surface. The residual is governance quality: a badly designed ceiling or rubber-stamped approval still grants bad authority.

The workflow plane

“Isn’t this just a workflow instance, a case record, or a durable execution?” Those systems already hold durable task state, and some also drive access decisions. Run the behavioral test: is authority derived from the record, is each claimed consequential action enforced against its current state, and do lifecycle and evidence join on its identity? If yes, the workflow may be a valid Mission implementation inside that platform. If it only schedules steps, carries a ticket ID, or replays durable execution while authorization remains independent, it is a neighboring system. The name and storage location are not the distinction. The authority relationship is. The looks-like table runs the full lineup.

“We built this internally in a quarter: a task table, a PDP, and scoped tokens. Why standardize a new object?” That may be enough, and the landscape concedes it: inside one platform, careful composition can implement the category. Custom engineering can also produce revocation across known audiences, joined evidence, integrity anchors, and lifecycle-aware issuance and enforcement (what becomes possible only with a Mission itemizes the target properties). Standardization is justified only when multiple implementations need common semantics and wire behavior: the SaaS API that cannot read your private task table, a third-party tool server, a partner domain, or an auditor joining evidence across them. If one platform owns every relevant boundary, keep the private design. The handbook treats the interoperability case as a bet rather than a theorem: the composition bet names the deployment evidence that would prove composition enough. An internal implementation is useful evidence for the venue conversation, especially where proprietary integrations repeat across products.

The hard questions

“An agent discovers tools and resources at runtime. You cannot approve what you cannot enumerate.” The Mission approves the task, not the toolset, and discovery is a proposal event, not an authority event. A runtime-discovered tool or resource acquires authority in one of two governed ways. Either it was already inside the approved bounds (the Intent’s constraints and the derivation policy govern resources the Approver bounded without enumerating), or it arrives through the discovery loop: the PDP denies with a requestable out_of_authority, the current ARAP draft turns the denial into a governed request, and the widening lands as a separately approved successor Mission through Expansion. The experimental Mission Open-World Discovery profile names this end to end: each encounter is adjudicated against a ceiling the Approver pre-consented, a resource’s self-declaration is never classification authority, and a session that has ingested untrusted content cannot bind a communication- or commitment-capable resource without the additional approval required by deployment policy. High-consequence deployments can require that approval to be human. The alternative, broad standing grants to cover the unknown, is the blank check this handbook exists to retire. What a Mission cannot do is make a discovered counterparty trustworthy: whether to trust a runtime-discovered issuer, tool server, or its metadata is the substrate problem, and the Open-World OAuth series carries it.

“How does the Mission know the meeting was cancelled?” It does not infer business truth. An authorized source must change authoritative state: the subject or approver, an administrator, a policy process, or an orchestrator reacting to a trusted business event. If no transition arrives, the Mission remains active until expiry or an entry discharges. That is why ownership of lifecycle operations, default expiries, and source integration are operational requirements rather than protocol decoration. The guarantee begins after the authoritative transition: new derivation stops immediately at the state authority, while reliance stops on each claimed path within its published freshness bound. The architecture makes termination enforceable; it does not make the system omniscient.

“An agent can stay inside every parameter bound and still do damage with the content.” Correct, and the layer never claims otherwise. Sharpened, the objection says the model stops unauthorized access but not the malicious execution of authorized access, and the handbook states exactly that as its own residual, because survivable incorrectness assumes the agent will be steered. Structure still bites on the shape of in-bounds misuse: quotas meter the thousand-comment spam run, parameter bounds pin the fields and destinations, and reversibility classes route what cannot be undone to a human before it happens. What structure cannot do is judge content, and the bound is stated as canon: Mission compliance is evaluated against the approved representation of purpose, not against an independent oracle of human intent. Parameter binding, metering, and state checks are structural enforcement: they bound the blast radius, and they cannot judge whether an in-bounds email body leaks intellectual property. The architecture’s answers to semantic risk are deliberately structural too: keep the envelope small (scope, and exposure), keep the lethal trifecta split at execution time, and escalate the classes where content is the harm to action-bound human approval under mediated custody. Content-aware controls (DLP verdicts, classifiers, an LLM judge) compose as decision inputs through the AuthZEN binding’s context, and they raise the bar without becoming a guarantee, because a judge model reading attacker-influenced content is itself injectable. The adversary model carries the residual in writing: within the approved scope, a steered agent can still misuse what was granted, which is why scope stays tight.

“The agent can bypass the PEP through a shell, direct network access, or another tool.” Then that path is not runtime-enforced. The protocol cannot prove that a deployment enumerated every execution channel. A claim must name its mediated paths, issuance-gated-only paths, and unmediated exclusions; the harness, network policy, gateway, or resource server must close the paths included in the claim. An action observed in logs but not forced through a gate is evidence, not containment. This is the reason the deployment claim publishes enforcement coverage instead of saying “all agent actions.”

“Your subset rule cannot prove the child is really narrower.” For the representation, it can: exact-or-prefix resources, subset actions, tighter constraints, capped expiry, delegation policy no broader, all mechanically checkable on every derivation. What representation alone cannot prove is semantic narrowing, that the child cannot produce effects outside the parent’s approved purpose, because contextual and quantitative constraints can compare as narrower while permitting purpose-inconsistent effects. The Reference names the distinction and the required posture where the comparison relation cannot decide: conservative refusal or a separately approved projection, never an optimistic mapping.

“Who decides what ‘prepare the board packet’ permits?” Not the sentence, and not the agent. The Authorization Server derives a concrete Authority Set from the validated Intent under deployment derivation policy, the approver consents to that derived authority with the summary as context (never the summary alone), and enforcement checks each action’s concrete parameters against the committed set. Natural language never becomes executable authority by interpretation at run time: the Mission authorizes parameterized operations, not free-form intent, and the classes where a wrong reading costs most carry action-bound approval on top. A mis-derived set an approver accepts is still approved. The disclosure therefore renders the derived authority and the fatigue budget keeps the reviewer able to read it.

“Why not just keep agents read-only?” That is the control most estates run today, and it is a legitimate containment strategy for work that is genuinely read-only. It also sets a capability ceiling: work that requires mutation still moves to another actor or process. Read-only access does not make exposure harmless, because an agent can be steered by anything it was allowed to see and data it holds can leak, which is least exposure’s whole argument. Where a human executes agent-drafted writes, that human is the enforcement point and needs a bounded, intelligible approval surface. The adoption path keeps read-only as a valid starting posture and stages broader authority only where the added controls justify it.

“Isn’t this overkill?” For a single user-driven request, a machine-to-machine service credential, or any flow where the credential lifetime is the task, yes. Skip it. The category earns its keep when authorization must remain bound to approved work across a credential, session, actor, or domain boundary. The protocol MVP is deliberately the smallest surface that does that. Size is not the threshold, and neither is the actor: one resource for one afternoon is a well-formed Mission, a human’s task access qualifies as readily as an agent’s, and the first deployment does not need an agent at all.

“The Mission record is itself a disclosure risk. You have built a registry of business intent.” Yes, and the design treats it that way. A Mission store is a high-value catalog of organizational activity, and a reference projected across domains is a durable correlation handle. The token-side claim (id, issuer, authority_hash) does not directly carry the task description, but it still reveals that a shared undertaking exists and who issued it. Deployments must minimize stored intent, partition access, encrypt records, audit reads, and set retention deliberately. Selective disclosure is the Mandate’s job when a third party needs some committed facts and not all of them. The adversary model carries the residual in full: evidence stores require access control commensurate with the systems they describe, the evidence chain may outlive the task, and no protocol feature makes cross-domain correlation disappear.

An objection this page does not answer belongs in the issues on the draft repository, where the drafts move with the argument.