---
title: "Common Objections to Mission-Based Authorization"
date: "2026-07-10T20:05:00-07:00"
lastmod: "2026-07-10T20:05:00-07:00"
description: "Twenty-three strong objections to mission-based authorization, answered by control plane while keeping existing capabilities, proposed additions, and residual risks distinct."
summary: "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."
slug: "common-objections-to-mission-based-authorization"
tags:
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "IAM"
  - "Delegated Authority"
---



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:

| Question | What a sufficient answer must show |
| --- | --- |
| What is the root object? | A durable record of approved work, not only a credential, session, or correlation ID |
| What projects from it? | Authority is derived from the approved bounds, including delegation where supported |
| What enforces it? | Claimed consequential paths check current task state within published freshness bounds |
| What remains outside the claim? | Unmediated paths, semantic misuse, completed effects, and privacy risks are named |

The handbook calls that root object the Mission and the surrounding
function [the control plane for delegated authority](/series/designing-mission-bound-authorization/#the-control-plane-for-delegated-authority).
It composes with the systems above rather than requiring their removal.
The
[Field Reference](/notes/mission-based-authorization-field-reference/)
carries the definitions and the
[competitive landscape](/notes/mission-based-authorization-field-reference/#competitive-landscape)
these answers lean on, and the
[vendor test](/notes/mission-based-authorization-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](#the-identity-and-workload-plane),
[credential](#the-credential-plane),
[decision](#the-decision-plane),
[privileged and entitlement](#the-privileged-and-entitlement-planes),
[workflow](#the-workflow-plane), or go straight to
[the hard questions](#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](/notes/the-authority-control-plane/) 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](/notes/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](/notes/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](https://www.rfc-editor.org/rfc/rfc9396.html) 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](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html)
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](https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html)
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](/notes/mission-based-authorization-field-reference/#when-revocation-bites) 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](/notes/mission-bound-runtime-enforcement/#fail-closed-and-active-freshness)
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](/notes/mission-based-authorization-field-reference/#when-revocation-bites))
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](/notes/the-convergence-and-the-wagers/#where-this-could-be-wrong)
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](https://csrc.nist.gov/pubs/sp/800/207/final) 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](/series/designing-mission-bound-authorization/#the-control-plane-for-delegated-authority)
states where that input lives, and the
[runtime profile](/notes/mission-bound-runtime-enforcement/) 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](https://openid.net/specs/openid-sharedsignals-framework-1_0.html)
is intentionally extensible: cooperating parties can define event types
and subject identifiers beyond those in
[CAEP](https://openid.net/specs/openid-caep-1_0.html). 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](/notes/mission-bound-runtime-enforcement/#fail-closed-and-active-freshness).
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](/notes/mission-lifecycle-and-change/)
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](/notes/adopting-mission-bound-authorization/#you-do-not-need-an-agent-to-start)
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](/notes/mission-lifecycle-and-change/#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](/notes/from-a-request-to-an-approved-mission/#who-may-approve)
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](/notes/from-a-request-to-an-approved-mission/#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](/notes/mission-based-authorization-field-reference/#what-looks-like-a-mission-but-is-not)
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](/notes/mission-based-authorization-field-reference/#competitive-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](/notes/mission-based-authorization-field-reference/#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](/notes/the-convergence-and-the-wagers/#where-this-could-be-wrong)
names the deployment evidence that would prove composition enough.
An internal implementation is useful evidence for the
[venue conversation](/notes/adopting-mission-bound-authorization/#what-the-community-still-has-to-standardize),
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](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html)
turns the denial into a governed request, and the widening lands as a
separately approved successor Mission through
[Expansion](/notes/mission-lifecycle-and-change/#grow-expansion-creates-a-successor).
The experimental
[Mission Open-World Discovery](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-discovery.html)
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](/series/open-world-oauth/) 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](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority)
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](/notes/least-exposure-is-broader-than-least-privilege/)),
keep the
[lethal trifecta split at execution time](/notes/mission-bound-runtime-enforcement/#the-lethal-trifecta-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](/notes/mission-based-authorization-field-reference/#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](/notes/mission-based-authorization-field-reference/#the-honest-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](/notes/mission-based-authorization-field-reference/#the-mission-object-model)
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](/notes/adopting-mission-bound-authorization/#what-you-will-operate),
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](/notes/mission-bound-runtime-enforcement/#the-high-assurance-level)
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](/notes/least-exposure-is-broader-than-least-privilege/)
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](/notes/adopting-mission-bound-authorization/#the-read-only-ceiling)
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](/notes/adopting-mission-bound-authorization/#you-do-not-need-an-agent-to-start).

**"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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html)
job when a third party needs some committed facts and not all of them.
The [adversary model](/notes/mission-based-authorization-field-reference/#the-mission-record-is-itself-sensitive)
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](https://github.com/mcguinness/mission-bound-authorization/issues),
where the drafts move with the argument.