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 in most estates 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. Infrastructure usually evolves that way, 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.

Capabilities answered delegation by possession. Dennis and Van Horn (1966) described the capability: an unforgeable reference that carries its own authority, so whoever holds it may use it and pass it on. The tradition made narrowing the native operation of delegation, and macaroons (2014) brought it to web credentials, with caveats that “attenuate and contextually confine when, where, by who, and for what purpose” a service should authorize requests. A caveat can name a purpose. It does not make the undertaking an object with an owner and a lifecycle that other boundaries consult: the authority travels with the holder, and the person who handed it out carries the reason it should stop.

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, because the person is presumed present, and presence is the carrier. The session grain later gained a cross-domain stop signal: OpenID’s Shared Signals Framework and its Continuous Access Evaluation Profile (1.0, 2025) let one party tell another that a session or credential changed state so the receiver can end it. That answers whether the session is still on, and the work the session serves still has no state of its own.

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. The undertaking appears nowhere in that trust infrastructure, because 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 base 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.

Two later standards come closer still. GNAP (RFC 9635, 2024) makes the grant a negotiated object at the authorization server: a client can continue, modify, or revoke an ongoing grant request, so access has a lifecycle both sides share. Transaction Tokens, an OAuth working-group draft awaiting its write-up, carry an authorization context through a call chain inside one trust domain, with the transaction’s purpose scoped as narrowly as possible and context that stays immutable along the chain. GNAP gives the grant a lifecycle, and Transaction Tokens carry purpose across hops, but neither makes the approved undertaking the governed object: a GNAP grant governs access, and a transaction token lives for one request inside one domain.

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.

Outside a few regulated domains, 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 the 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.

One branch of OAuth did build the object, inside one domain. Open banking needed a customer’s approval of a specific account access or payment to outlast the tokens that carried it, so the UK Open Banking APIs have the client first create a consent resource at the bank. The resource has its own identifier and a status (awaiting authorisation, authorised, rejected), the customer authorizes that intent, the client can delete it, and the bank’s security profile treats the intent’s authorized state separately from token expiry. Australia’s Consumer Data Right returns a cdr_arrangement_id with the tokens and defines an arrangement revocation endpoint, and OpenID’s Grant Management gives a general grant an identifier a client can query and revoke. These are approved-intent objects with a lifecycle and tokens bound to them, deployed across national ecosystems. Each lives inside one data holder’s authorization server, with a schema its domain fixes, governing access to that holder’s resources. The Mission generalizes the pattern across resource servers, sub-agents, delegation, and runtime checks.

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.

Integrations broke it first. In April 2022, stolen OAuth user tokens issued to Heroku and Travis CI were used to download data from dozens of GitHub organizations, including private repositories. In August 2025, compromised OAuth tokens from the Salesloft Drift integration were used to steal data from Salesforce instances, and affected organizations were advised to review every third-party integration connected to Drift and revoke and rotate its credentials. In both, the tokens were valid and did what they were scoped to do, and response meant finding and revoking credentials integration by integration, because no record said which work each token served.

The experiment that breaks the composition

Run the composition against one month-long undertaking. Jordan 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 Jordan’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 strongest case for leaving the stack alone combines the pieces that already work. Short-lived tokens bound the exposure but do not know which task they serve. A workflow engine knows the task but keeps that state private to its platform. IGA approves access at provisioning time and reviews it later, not at the moment of use. A human in the loop restores the carrier, and with it the approval load that unattended work exists to remove. Each closes part of the gap, and the objections appendix takes them one at a time.

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 stops reliance on each path the deployment governs within that path’s published bound; a path outside Mission enforcement is not reached. Effects that already completed still require cancellation, compensation, or review.

The field has reached the same question from other directions. AIMS, a WIMSE working-group document, names the agent’s mission and leaves its translation into authorization requirements out of scope, and other proposals are converging on the same object. The thesis is wrong if platform-private task state plus short-lived credentials prove enough for work that crosses domains, and Chapter 5 states those wagers, the issuer bet and the revocation bet, with the evidence that would settle them.

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, but 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 could always be answered and could always be deferred, because someone was there to carry the answer and no generation had to make it a standard. Unattended work removes that someone, which makes it this generation’s question.