The Question Authorization Never Answered

Stand at any enforcement boundary and ask the question in this essay’s title. A resource server holds a valid token. A policy engine holds a permitted request. A session store holds an authenticated continuation. Now ask what work this is, who approved it, and whether it is still on. Every layer answers a question adjacent to that one, and none of them answers it.

Ask why, and the useful answer is that no one designed the authorization stack as a whole. It accumulated one problem at a time. Each generation solved the question its era made urgent, and deferred the question above, because someone else was always carrying the answer: the person at the keyboard, the application’s workflow table, the ticket in the queue. That is not a criticism. It is how infrastructure evolves, and this is a model history rather than a literal timeline, since the generations overlap and modern systems run all of them at once. The point is to name the scaling problem that made each abstraction succeed, the carrier that let it defer the undertaking, and the moment the deferral stopped working.

Every generation answered its era’s question

Passwords answered who may enter. Shared systems needed to distinguish users, and password authentication helped bind an interaction to a principal. The credential did not describe an undertaking. It did not need to: the person at the terminal was the carrier, holding the purpose in their head and stopping when the work was done.

Sessions answered continuity. The web split one interaction across many stateless requests, so sessions carried authenticated context from one request to the next. A session says that these requests belong to the same authenticated interaction. It does not prove that the person is still attentive or explain what the interaction is trying to accomplish. It does not need to: the person is presumed present, and presence is the carrier.

RBAC answered administration. Enterprises could not manage permissions one user at a time, so roles associated permissions with organizational responsibilities. NIST’s early RBAC work described the administrative advantage directly: users receive permissions through roles and can change assignments without rewriting the underlying access structure (Ferraiolo, Cugini, and Kuhn, 1995). A role is therefore usually sized to a responsibility or job function, not one bounded undertaking. The undertaking had its own carrier: the job itself, with a manager, a process, and a paper trail deciding what the role-holder should actually be doing today.

Federation answered trust across organizations. Enterprises needed one login to reach many providers, so SAML and later OpenID Connect standardized the assertion: a signed, minutes-lived statement of who authenticated, with what attributes, at what strength. A whole generation of trust infrastructure, and the undertaking never appears in it. It did not need to: the assertion opens a session on the far side, and the person inside that session carries the why across the boundary in their own head.

OAuth answered limited API authority. Applications needed a way to access protected resources without collecting every user’s password. OAuth 2.0 standardized how a client obtains and presents authorization, with access tokens representing particular scopes and durations. It also included client-only authority through the client credentials grant. OAuth’s core question is not simply “who delegated?” It is broader: what authorization may this client present to this resource server? OAuth is also the one generation where the approval visibly happened: a human saw a consent screen and said yes. Then the protocol kept the authority and discarded the event. The scopes survive on the token, what was shown and agreed to does not, and the person who consented becomes the carrier of what they meant by it.

UMA answered asynchronous resource sharing. User-Managed Access (UMA) 2.0 extended OAuth so a requesting party’s client could use a permission ticket to seek a requesting party token (RPT) for protected-resource access asynchronously from the resource owner’s authorization. The authorization server evaluates resource-owner policy conditions and requesting-party claims, and can manage access grants over time. UMA therefore removed the assumption that the resource owner must be present when access is requested.

That makes UMA important prior art, not a near miss to dismiss. Its governed object is a requested or granted set of permissions to protected resources. Policy condition setting is deployment-defined, and the specification does not make a multi-step undertaking the common root for authority derivation, delegation where supported, execution state, and evidence across all systems participating in the work. A deployment can add those semantics around UMA, and the added task lifecycle is the Mission-shaped part.

Workload identity answered which software is acting. Cloud and container platforms could not safely identify workloads with shared, manually provisioned secrets. Workload identity systems bind a runtime process to a verifiable software identity and issue credentials without requiring the workload to manage a long-lived secret. SPIFFE’s Workload API, for example, supplies X.509 or JWT identity documents to an identified workload, while SPIRE can select the identity from attested process and platform attributes.

That is a major step for attribution and credential hygiene. It still answers which workload, not which approved undertaking. One workload identity may execute thousands of tasks, and one task may fan out across many workload identities. The active IETF WIMSE working group is addressing how workload identity technologies compose across multiple systems. Task approval and lifecycle remain a separate authorization concern. And here the carrier begins to thin, because a workload has no head to hold the purpose in.

Fine-grained authorization answered the request. Scopes and roles were too coarse for many estates, so ABAC, ReBAC, policy engines, and externalized decision services made the request itself the decision unit. NIST’s ABAC definition allows policy to evaluate subject, object, operation, and environment attributes. A policy decision point can answer whether this request is permitted with great precision, but it can evaluate only the context it receives. It does not inherently own the approval, lifecycle, or cross-domain distribution of an undertaking. It evaluates what it is handed, and something else must carry the undertaking to the boundary.

Lay the abstractions out and the remaining responsibility becomes visible:

The claim is not that these layers cannot carry purpose. XACML’s privacy profile, for example, defines an explicit action:purpose attribute. ABAC can evaluate a purpose, ticket, or task identifier as an environment attribute. The unresolved architectural question is who creates that state, binds approval and authority to it, keeps it current, and makes it available across every boundary included in the claim.

The second stack

The why was never missing from the enterprise. It was in the other stack.

Alongside the authorization stack, every organization runs a work stack: purchase orders, change tickets, case records, workflow runs, access requests and their approvals. That stack has always held exactly what the authorization stack lacks: what was asked for, who approved it, what it covers, and when it ends. A change ticket has a scope and a window. A purchase order has an amount and a counterparty. An access request has an approver and a justification.

The two stacks never merged. The work stack’s records are not enforceable objects: nothing at a resource server consults the ticket before honoring the token that was provisioned because of it. The authorization stack’s artifacts are enforceable but carry no undertaking: the token outlives the change window it was granted for. The join between them was human process. Someone read the ticket, provisioned the grant, and was supposed to remember to remove it, and every access recertification campaign since is the cost of that join.

Seen from this history, the Mission is not a new kind of object so much as a merger the two stacks have owed each other for decades: the work stack’s record given the authorization stack’s enforceability, approval-backed state that boundaries consult rather than paperwork that boundaries trust someone else to have checked.

Why OAuth stopped where it did

It is tempting to read OAuth’s silence about a generic task lifecycle as an oversight. It is better understood as a protocol boundary.

OAuth standardized authorization grants, token issuance, scopes, durations, and resource-server access. It did not try to standardize the semantics of every workflow an API might serve. Later work expanded the model in important directions. UMA made authorization asynchronous with respect to the resource owner and policy-driven across protected resources. Rich Authorization Requests, for example, can represent a specific payment amount, creditor, and set of actions. But each API defines the meaning of those details, and RFC 9396 explicitly leaves their combination and comparison to the API and authorization server. Rich authority is not automatically a durable, shared task lifecycle.

That separation was productive: the work stack held the purpose, the person carried it between systems, and OAuth did not need to become a workflow protocol to succeed.

The limitation appears when work crosses the walls that held its context. A private task table can govern one platform well. It cannot govern a resource server, sub-agent, credential broker, or partner domain that never receives its state. What has no standard form is therefore not “purpose” in the abstract. It is interoperable, approval-backed task state at the boundaries that rely on it.

The theory arrived early

The idea of continuing authorization is not new. In 2004, Park and Sandhu’s UCONABC usage-control model generalized access control to include authorizations, obligations, conditions, ongoing decisions, and mutable attributes. UCON recognized that authorization need not be a one-time gate: relevant state can change during use, and a decision may need to change with it.

That prior art matters for two reasons. First, ongoing evaluation and mutable authorization state should not be presented as inventions of agent security. Second, continuing decisions alone do not identify the governed undertaking. A policy engine can repeatedly evaluate current state only after some system defines the state, owns its transitions, and makes it trustworthy to the enforcement point.

Mainstream authorization deployments had practical substitutes: application workflow, tickets, sessions, short-lived credentials, and human operators. Continuous checks also impose state-distribution, availability, latency, and ownership costs, and for twenty years the workaround was cheaper, because a human carrier costs nothing at the protocol layer. Unattended, cross-system work breaks the workaround. It makes stale task state a recurring runtime problem instead of an occasional integration concern, and it removes the person who used to notice.

The experiment that breaks the composition

Run the composition against one month-long undertaking. Alice tells an agent to handle the company’s taxes. The agent evaluates filing software, engages a bookkeeping sub-agent, requests documents from a payroll provider, files an extension, waits for a state response, resumes three weeks later, and appeals a rejected form.

Each component can be locally correct. Each provider issues a valid grant. Every resumed session authenticates successfully. Each API accepts only its own documented scopes or authorization details. The bookkeeping sub-agent has an attested workload identity and rotated credentials, and every policy decision is defensible from the inputs it received.

Now ask about the undertaking as a whole. Which approvals authorize the sub-agent to contact the accountant? Which grants belong to this tax engagement rather than another one? Which authority should survive the extension and which should discharge after filing? If Alice’s business is acquired and the engagement must stop, which active sessions, tokens, queued steps, and derived grants are part of the stop?

An orchestration platform may know the answer in a private workflow record. An IGA or PAM system may hold the approval. An audit system may reconstruct much of it afterward. The problem is that no individual credential, session, role, token, or policy decision necessarily carries the whole relationship, and a remote enforcement point cannot consult state it was never given.

Nothing in the underlying stack has malfunctioned. Every layer answered its own question correctly. What the composition is missing is the one participant whose job was never written down: the person who held the whole engagement in their head, noticed when circumstances changed, and stopped. Unattended work moves that person off the execution path while the work continues across hours, actors, and domains. The carrier is gone, and no layer was ever asked to replace them.

The missing shared answer

The Mission is this handbook’s proposed answer: a durable, approved, integrity-anchored record of an undertaking and its Authority Set. Credentials project authority from it. Consequential actions are checked against its current state within a declared enforcement scope. Delegation, where supported, cannot exceed the approved Authority Set. A non-active Mission stops new derivation and reliance within the deployment’s published freshness bound. Effects that already completed still require cancellation, compensation, or review.

The handbook develops that object and its five laws: Durability (the governing record is independent of credential lifetime), Attribution (actions remain attributable), Narrowing (derived authority only narrows), Termination (non-active state stops reliance within scope and freshness bounds), and Containment (consequential actions are checked against the approved Authority Set and current state). Those are deployment obligations, not properties that follow from adding a claim to a token.

This history also explains why the argument is broader than AI. CI pipelines deploy after a merge, scheduled jobs move money at midnight, and infrastructure controllers reconcile systems while teams sleep. Each is unattended work whose purpose often lives in a repository, ticket, or platform-local record while its credentials are sized for an integration.

Agents intensify the problem because their plans change, their work fans out, and untrusted content can steer their choices. They did not create the missing shared state. They make its absence harder to tolerate.

Identity now covers people, clients, and attested workloads, and authorization can decide whether a particular request is permitted. The question in this essay’s title was never unanswerable. It was deferrable: someone was always there to carry the answer, so no generation had to make it a standard. Every generation answered the question its era made unavoidable. This one is ours, because it just stopped being deferrable.