Ask why the authorization stack looks the way it does and the useful answer is that no one designed it as a whole. It accumulated one problem at a time. Each generation solved the question its era made urgent, then relied on people, applications, and organizational process to supply the rest.

That is not a criticism. It is how infrastructure evolves. It also explains the gap that unattended work exposes: not the total absence of purpose, but the absence of a standard, durable object that tells every relevant boundary why authority exists and whether the approved work is still active.

This is a model history, not a literal timeline. The generations overlap; modern systems use all of them; and each can be extended beyond the job described here. The point is to identify the scaling problem that made each abstraction succeed, and the responsibility it did not need to own.

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 user and the application supplied the immediate context.

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.

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.

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?

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; 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.

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.

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.

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. A purchase order, case record, change ticket, workflow run, or deployment plan could hold purpose inside the system that owned the work. In interactive flows, a person also carried context between systems and stopped taking actions when circumstances changed. 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. The missing layer 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. Unattended, cross-system work changes that trade. It makes stale task state a recurring runtime problem instead of an occasional integration concern.

The experiment that breaks the composition

Consider an illustrative month-long task. 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. The composition is missing an owner for shared undertaking state. The human used to bridge many of those gaps through attention and judgment. Unattended work moves that human off the execution path, while the work continues across hours, actors, and domains.

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: the governing record is independent of credential lifetime; actions remain attributable; derived authority only narrows; non-active state stops reliance within scope and freshness bounds; and 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, while authorization can decide whether a particular request is permitted. Unattended work creates a reason to standardize the next answer: what approved undertaking governs this authority, and does it still?