The Four Questions of Delegated Work, and the Invariants That Compose Their Answers
Delegated work forces four separate continuity questions: request provenance, identity attribution, target-applicable authority, and continuing work justification. Their answers compose through a common boundary contract: authoritative sources, bound and correlated evidence, explicit lifecycle semantics, local decisions, and declared failure behavior. Current proposals fill different parts of that contract; narrow profiles adopted one boundary at a time offer a more credible path than one universal delegation artifact.
A Vocabulary, a Rubric, and a Living Map for the Four Questions
Continuity Is Not One Thing argues that delegated work poses four independently governed continuity questions. This companion carries the parts built to be revised rather than to last: a vocabulary that separates facts from evidence, artifacts, authorities, decisions, and state; a twelve-question rubric a working group can apply to any proposal without accepting anyone’s architecture; worked evaluations of Transaction Tokens and Identity Chaining; the sixteen active OAuth working-group documents classified against the framing; and the two-layer standards map with dated versions and statuses.
The handbook’s vocabulary in one lookup table, A to Z: the objects, the artifacts, the mechanisms, the roles, and the named constructs, each defined in one to three sentences with a link to its canonical home. The entries are written to be quoted. The canonical homes carry the argument.
When a vendor says they support agent authorization, ask six questions: what is the approved task object, what derives authority from it, what keeps authority strictly narrower as work fans out, what checks each action at the moment of use, what happens when it is revoked, and can an auditor pull one identifier and see the whole task. The test is intentionally unforgiving: no approved task object means no category claim, token validation is not runtime enforcement, token expiry is not revocation, and logs are not task evidence. A vendor that passes can write the honest deployment claim with level, enforcement scope, freshness, evidence, and exclusions.
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.
Authorization looks the way it does because each generation solved the question its era made urgent, and deferred one question that someone else was always carrying: what approved work is this, and is it still on? Purpose was not absent. A second stack of tickets, purchase orders, workflows, and approval systems held it locally, and people carried it between systems. UMA decoupled protected-resource access from synchronous resource-owner interaction, and workload identity made software actors attributable without making their credentials task-specific. What never became a standard cross-boundary object was the approved undertaking itself, with authority derived from it and a lifecycle independent of any credential. Usage control identified ongoing authorization two decades ago. Unattended work now removes the human carrier and makes shared task state an operational requirement. This is the history that makes the Mission a legible next step rather than an idea from nowhere.
The third kind of outside framing is the one with auditors behind it. NIST AI RMF, the EU AI Act, and ISO/IEC 42001 converge on one demand: show me. Show me who is accountable, what the system is for, how you observe it, and how you stop it. In most agent stacks the honest answer is archaeology through session logs. In this architecture the artifact that enforces is the artifact that documents: the Mission is the documented purpose, the approval is the accountable decision, the evidence family is the log, and Termination is the interrupt. The crosswalk maps eight obligations onto machinery that exists for safety reasons, and then names what compliance still requires, because evidence is not certification.
Patrick Parker’s Seven Laws of AIdentity describe the dynamics a system must govern when agents act through delegated authority: split actors, generated intent, bounded agency, continuous authorization, least exposure, justifiable action chains, and proof-carrying action. This part maps those laws onto Mission-Bound Authorization without turning resemblance into compliance. The strongest matches are generated intent and bounded agency. Continuous authorization and split-actor attribution require the runtime and identity profiles. Least exposure, chain necessity, policy retention, evidence completeness, and embodied action remain conditional or outside the current wire model.
Cancel a card and watch what refuses to end: the subscription bills the new number the network helpfully forwarded, the pending hotel charge settles days later, and the refund arrives through a process you do not control. Payments learned that ending an instrument is not ending an arrangement, and built machinery for the difference: reversible freezes, terminal cancellations, single-use cards that retire themselves, in-flight states between authorized and settled, chargebacks as governed compensation, and the statement that reconciles everything to one project code. This part maps each ending onto the agent task that must actually stop, and closes with the breaks, including the one where the analogy runs backward.
A decline at the register is mild embarrassment and a tap of a different card, because the system is working: the network approves transactions, not cards. This part walks per-action authorization the way payments runs it: the plastic that proves almost nothing, the authorization that binds this amount at this merchant now, the hotel hold that expires, the freeze that declines the next swipe wherever the issuer decision is checked, and the ATM, the escape hatch every honest card program names in writing. Then the breaks: agents have no common payment-style network, their false-approval costs are unbounded, and their cardholder can be hypnotized mid-purchase.
Crunch week. The contractor needs materials, and the project manager hands over her own card, just this once. Everything about it is convenient and everything about it is wrong, and every finance team knows exactly why. This part walks delegation the way a mature card program runs it: the contractor’s own card with a lower limit, attribution that survives the handoff, cards that die when the project closes, and caps on how many cards a project may issue, not just how big each one is. Then the three places the analogy breaks for AI agents, where the fixes have to be built.
A manager approves a conference request on their phone between meetings. Months later, the only defensible answer to ‘what did you approve?’ is the request as rendered on that screen. This part walks the anatomy of a real approval: requests that are proposals and nothing more, reviewers who narrow instead of denying, decisions that take days without losing their place, and the disclosure that binds. Payments turned that last idea into regulation. Then the honest part: three places the analogy breaks for AI agents, and what each break demands.
Nobody hands a new hire the company checkbook. In a mature spend program, they get an instrument bound to an approved purpose, checked at each transaction, metered against a budget, and frozen when the reason for the spend goes away. Agent credentials today are blank checks with expiry dates. This part walks the expense-governance loop end to end, maps each control onto agent authority, and is honest about the five places the analogy breaks. Each break is something the agent stack still has to build.
Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the continuation handle never reaches a Resource Server.
In Cross-App Access, a single signed-in user’s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant.
Closed-world authorization treated denial as the end of the interaction. Agents, runtime discovery, delegation, and mission expansion turn denial into the beginning of governance escalation. The draft AuthZEN access request and approval profile standardizes that handoff without standardizing the workflow engines behind it. Client-Initiated Backchannel Authentication (CIBA) is not the answer because the problem is not authentication freshness. It is whether authority should continue under newly discovered runtime conditions.
OpenID Connect is mature, standardized, and widely deployed, but SAML remains the enterprise SSO default because it is familiar, explicit, and deeply embedded in procurement and operations. That familiarity now hides a harder problem: XML Signature complexity, aging implementation stacks, limited post-login integration, and post-quantum migration pressure make SAML difficult to defend as the long-term enterprise baseline. The industry needs a secure enterprise OIDC profile and a credible migration path that preserves identity contract continuity for existing SAML federations.
WorkOS auth.md is an agent-readable registration document for one-click setup, with Agent Verified, user-claimed, and anonymous paths. In the Agent Verified path, most pieces already exist across OAuth and OpenID standards: ID-JAG, OAuth metadata, dynamic client registration, standard token endpoints, and SSF/CAEP/OPC. The standards gap is a profile for runtime agent onboarding and trust establishment, not a new grant protocol.
Modern agent harnesses make work durable across restarts, devices, background jobs, and sub-agents. That durability is a runtime property, not a governance property. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working. Conflating them is a central failure mode of long-running autonomous agent systems.
Enterprise SaaS still defaults to app-by-app OAuth islands with their own clients, long-lived artifacts, and revocation paths. The architectural shift is OAuth federation: adopt issuer-mediated federation now for services and workloads, and adopt Cross-App Access (XAA) as the standards direction for user-delegated cross-app access.
ID-JAG, also often called Cross-App Access (XAA), is centered in the current draft on Enterprise IdP trust, but the issuer that matters is the immediate IdP the downstream authorization server already trusts for SSO and subject resolution, not necessarily the top-level workforce IdP. The same trust pattern can also extend architecturally to CIAM and platform identity layers that federate upstream workforce login while remaining authoritative for downstream product trust, tenant context, and subject resolution.
Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.
Part 2 turns from the semantic problem to the runtime one. Quiet expansion, delegation, headless execution, stale state, and open-world execution all push Mission shaping past its strongest domain. Containment and runtime governance carry more of the safety burden.
This essay picks up from Part 4 of the Mission-Bound OAuth series and focuses on the first hard problem: how approved intent becomes a governable Mission. In structured domains that can look like staged Mission shaping or compilation. Many current deployments still do not do it at all.
Mission-Bound OAuth is a serious attempt to govern delegated agent authority using existing OAuth infrastructure. This post takes the pessimistic view: it may be the wrong answer because it asks the authorization server to become a governance engine, a lifecycle controller, and a mission ledger all at once. A cleaner alternative is to treat Mission as a separate authority service and let OAuth be one projection of that model rather than its home.
Rich Authorization Requests are the natural first instinct for agent missions, but audience-bound access tokens and uneven cross-domain interoperability limit how far they can carry a governed task. Mission-Bound OAuth solves that by making the Mission a durable authority object at the authorization server. This post explores the authentication-layer companion profile: OpenID Connect Client Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.
Enterprise IAM was designed for human-paced execution. Agents remove the presence, pacing, and natural scope-limiting that made those controls work. The result is a structural gap that stronger credentials, tighter scopes, and faster JIT provisioning cannot close.
Tokens, credentials, and scopes tell a system what an agent may do. They say nothing about why execution was authorized or when it should end. The Execution Mandate is the primitive that closes that gap: a signed, inspectable authority record that runtime systems can evaluate and revoke throughout the execution lifecycle.
An Execution Mandate defines what delegated authority looks like. This post builds the control plane that makes it operational: how mandates are issued and held as authoritative artifacts, how authority is evaluated continuously rather than at gates, how governance crosses organizational boundaries, and where enforcement lands in practice.