The support agent is working two tickets. On ticket 8841 the supervisor has approved part two’s $480 refund, and before the agent executes it, the customer withdraws the complaint. In this deployment, a withdrawn complaint cancels any refund that has not yet executed. Ticket 8842, for another customer, should continue. The enterprise needs a control that stops ticket 8841’s remaining actions without disabling the agent, revoking the rep’s access, or interrupting ticket 8842.
The decisions parts one and two described do not supply it. The rep still holds refund permission, the agent’s token is valid, the approval has not expired, and the order is still refundable, so each of those decisions would permit the refund. Revoking the refund’s ARAP approval can stop that one action, since ARAP requires the PDP to “check current approval status during re-evaluation, including whether the approval has been revoked.” It does not stop the rest of ticket 8841, which also covers investigating the order and notifying the customer under other grants and policy owners. By the time the customer withdraws, the ticket has already produced a token at the commerce platform and a customer notification pending at the support service, so terminating the agent’s runtime session reaches neither. Stopping all of it requires every participating system to recognize that those grants, approvals, and actions belong to the same canceled work. An enterprise PDP that every gateway consults, as part one proposes, can check the ticket for the enterprise’s own decisions. The commerce platform and the support service answer to their own policy owners, and a task-scoped token already issued and validated offline answers to no PDP, so none of them sees the ticket.
A fleet that shares a decision contract still has no shared record of the task each decision serves, so ending the work across those policy owners takes a custom integration with each of them. A durable approval does not supply that record. What is missing is a shared way to relate approved work to its authority boundary, its derived grants and decisions, and its lifecycle, so the work can be ended with one change and an approval does not outlive the work it was meant to authorize. A ticket lookup and existing approval records may be enough inside one deployment. The standards question is what another implementation needs in order to recognize and enforce the same boundary. Fewer redundant prompts are a secondary benefit.
The Blueprint Alliance whitepaper says “task-scoped dynamic grants represent the aspirational goal,” and its own refund presupposes a record of the task. The support agent executes the refund “within an ephemeral runtime scoped to that single approved task,” and “The elevated privilege expires the instant the task is done.” The whitepaper’s answer to the task question is an intent-based policy engine that “detects the shift from lookup to transaction,” and section 3.2.1 notes that “Inspecting a plan is achievable with current tooling.” Inference can estimate whether an action looks like the task, but only a record can show whether the action belongs to the task someone approved. AuthZEN can carry a task reference, but the core API does not standardize what it means.
I write the Mission-Bound Authorization drafts, and this part argues for them against the candidates below. Adopting the Final AuthZEN API does not depend on any of them.
The Task Still Needs Shared Semantics
Part two’s token-side and resource-side placements can both authorize the refund at the right granularity. An order-scoped token can authorize only $480 on ord_58213, and a resource-side PDP can check the same order and amount, the rep’s relationship to the customer, and the supervisor’s approval. The withdrawn complaint changes none of those facts. The token’s order and amount still match, and the resource’s checks still pass unless they consult the state of the approved work. A task record serves both placements. On the token side, the issuer derives a bounded grant from it, though an identifier in an offline-validated token cannot deliver revocation by itself. On the resource side, the PDP checks it alongside the token, order, relationships, and approval. The Blueprint’s fine-grained and relationship-based controls remain necessary, and the task record gives them the approved work to evaluate against.
AuthZEN can carry task information in context. Any deployment can put a task reference there, and each vendor can put a different one. What the core API leaves unspecified is how different implementations identify the approved task, interpret its authority, and check whether it remains active. The Least-Privilege MCP series put the per-call version in one line: “Least-privilege per call can be locally correct and globally wrong.”
The word task already means two other things in this stack. ARAP returns a task handle for a pending approval. MCP’s Task, which SEP-2848 uses, is a handle for held work that lets a tool call wait. Neither records what the user approved the agent to do. In this part, the task means the approved work, and a task record is a durable, checkable record of it.
A task record that part one’s fleet can use needs five properties: an identifier other vendors’ enforcement points can check, accountable provenance naming who is answerable for the approval, an authority boundary that says what the task may do, a lifecycle state others can read, and revocation by reference, so that ending the task ends its authority without finding every credential first.
A Mission is my proposal for such a record. It holds the purpose a person approved, the authority that bounds it, who approved it, and a lifecycle state its issuer maintains. Tokens and PDP decisions reference it, and it is never the token itself.
The Blueprint’s purpose binding names the “approved workflow” and “requested task” without defining a record for either, and it says “end-to-end multi-hop delegation remains an aspirational target given today’s tooling.” The Blueprint already calls for selective containment, including control at the session level without “collateral impact to adjacent workflows” and revocation of “a single, specific interaction string.” It leaves open how independent systems recognize the same approved work across its sessions, credentials, approvals, and downstream execution, and enforce its cancellation within declared bounds. That interoperable contract is what this series proposes. The series reference quotes each requirement and maps it.
Tests for the Task Record
An enterprise can run these tests now, with the task check built as a ticket lookup at a PDP it owns. A Mission trial adds a Mission issuer and a Mission-aware PDP, using five drafts for the revocation test and a sixth for containment, listed in the series reference. ARAP approvals, templates, delegation, and metering are optional. Each step should be observed at an enforcement point from a second vendor, with evidence that connects the state change, the decision, and the refused attempt.
Task revocation.
- A refund succeeds while its task is active.
- After the task is revoked, the next refund is refused within a bound stated before the test, the enforcement point shows that it did not execute, and no further authority is issued for the task. A permit issued while the task was active and presented after the declared cutoff is also refused, and the result names the mechanism that set the cutoff, such as the permit’s expiry, active invalidation, or re-evaluation at use.
- The same refund, retried after revocation with its task context omitted or mismatched on an otherwise valid credential, is refused on every path declared to require task-bound authorization rather than evaluated against ordinary policy. A path outside that scope is reported as a limitation.
- The ticket’s other operations, such as the customer notification under a different policy authority, are refused within their own stated bounds.
- A separate task for the same agent, such as ticket 8842, is unaffected.
- When the enforcement point cannot establish fresh task state, it behaves as the deployment specified in advance, for example failing closed.
Selective containment.
- After refunds are contained for an active task, the next refund is refused within the stated bound.
- Read operations under the same task continue.
Uncovered path.
- A refund path has no containment-aware control in front of it, and the deployment’s declared choice holds. Either that path refuses refunds, or the issuer revokes the whole task, which also stops the task’s reads and gives up selectivity on that path.
Prompt budget.
- Across the whole ticket, prompts to a person stay within a count declared before the test, two in this ticket (the rep’s approval of the task at handoff and the supervisor’s approval of the $480 refund), with the permitted operations, constraints, authentication requirements, and exception thresholds unchanged. A prompt is any consent screen, step-up, CIBA push, or approval request, counted by joining them on the trace or task identifier. A newly required step-up or an operation outside the approved boundary may exceed the count, since the test targets redundant prompts, not necessary checks.
- Auto-approval never settles an
approval_requireddenial for an irreversible, external-commitment, or privileged-administration action without an independent approver. This is a criterion I propose whatever implements the task record, and the Mission AuthZEN profile states it as a MUST NOT.
The revocation test already runs in the Mission reference implementation. Its guided demo includes a scenario that revokes a Mission and shows the next action denied within its bound, and it can route the enforcement point through a remote PDP. It is the author’s own stack, so it demonstrates the mechanics, not interoperability.
A received change event shows only that the event arrived, so the tests count the refused refund, not the delivery, as evidence of enforcement.
A New Call or a New Request for Authority
A task record gives the fleet a way to tell a new call from a new request for authority. An open-world agent discovers resources, tools, and required authority while it works. Discovery can show how to perform already-approved work, but it cannot by itself establish authority over a newly discovered destination or effect. A new tool that performs an approved operation at an approved resource needs its mapping resolved and the concrete call evaluated, not another business approval, though the client may still need a suitable token. A new resource or operation needs an approved mapping or an authority expansion. An operation inside the boundary can still cross a separate exception threshold, as the $480 refund crosses the $250 limit.
Policy and reusable approvals already remove many prompts without unrestricted standing access. An enterprise PDP that permits order-specific operations from the requester, the customer relationship, the order state, and an amount ceiling settles the refund expansion without asking anyone. A task record adds one approval, the rep’s at handoff, and lets services under separate policy owners, here the commerce platform and the support service, settle requests inside the approved work without each reconstructing it, provided they recognize the task issuer and its vocabulary. Where every service can establish the relationship on its own, the record’s value is the shared lifecycle, not fewer prompts. The series reference compares the prompts in three deployments of this ticket.
Candidates for the Task Record
Several things in the Blueprint’s world already carry part of a task record, and they can be combined.
| Candidate | What it carries | What it lacks for this job | Status |
|---|---|---|---|
| The support ticket (in Salesforce, ServiceNow, or similar) | The business record of the work, with an owner and an open or closed state | An authority boundary, and a link from its state to authorization decisions at other vendors | Deployed everywhere |
| AgentCore per-task policy session | A session ID the application can set per logical task, with history-based rules such as “Block access to Tool B unless Tool A was called first,” carried across hops in a signed token | An approver, and a way to end it. Session IDs are “customer-managed,” “Explicit close” is “Not supported,” and multi-hop works only within one account and Region | Product feature |
| Transaction Tokens | A txn identifier, a scope for “the purpose of this particular transaction,” and immutable context in tctx, propagated through a call chain | An approver, a lifecycle beyond the token’s short life, and reach beyond one trust domain | Working group draft at -11, awaiting write-up |
| Task-scoped tokens, such as Okta’s ID-JAG “downscoped to the task” | Authority narrowed to the task at issuance, short-lived, with SSF-driven revocation through Okta’s kill switch | A task identifier other vendors can check, and revocation of one task without the subject’s other work | Product feature on a working group draft |
Rich Authorization Requests authorization_details | A precise authority boundary, down to one order, associated with a grant and carried through refresh and introspection | A cross-system identity and lifecycle for the approved task that coordinates several grants and enforcement domains | Final (RFC 9396) |
| The whitepaper’s ephemeral runtime | A task boundary equal to the runtime’s lifetime | An identifier or state that anything outside the runtime can check | Architecture guidance |
| An ARAP approval record bound to the ticket, with current-state evaluation | A durable approval with a scope, a lifetime, and a status the PDP must check on every re-evaluation, held by one Access Request Service the whole fleet can share and revocable when the complaint is withdrawn | A way to relate several approvals and grants, from different authorities, to one piece of work. | Working group draft |
| A composition of the ticket, Rich Authorization Requests, a task identifier carried in credentials, and a shared status adapter | Potentially all five properties, from parts that exist today | An agreed format for the identifier, the status interface, and the rules that bind the parts, so each deployment defines its own and a second vendor needs a bespoke integration | Buildable now from finished and custom parts |
| A Mission | The same composition, specified: an issuer-qualified identifier carried in the mission claim, an authority set written as a Rich Authorization Requests type, a named approver, and a lifecycle state readable through status and signals | Production deployment | One individual draft at -00, the rest editor’s copies |
The last composition in the table is the strongest alternative, and it is close to what the Mission drafts specify. A Mission’s authority set is a Rich Authorization Requests type, its identifier is carried in credentials, and its status interface is the shared status adapter. What the drafts add is one record format, one status interface, one set of lifecycle transitions, and one AuthZEN binding. Once more than one party implements them, a second vendor can check the task without a bespoke integration, though it still decides which issuers it trusts and which authority vocabulary it supports. A Mission would reference the ticket, not replace it. The ticket stays the business record of the work, and the Mission records what the agent may do for it.
The Refund’s Mission
When the rep hands ticket 8841 to the agent, the rep approves this Mission. Here it is, abridged, with field names from the current editor’s copy of the Mission OAuth binding.
| |
The authority set binds the work to one order and one ticket. It names the enterprise’s payment connector and support service, so learning which processor handled the order changes the route, not the resource, and the agent still discovers which tools to call. A processor the connector does not front would be a new destination and would need new authority. max_amount is a Common Constraint from the Mission Resource Access Profile, and it is a per-refund ceiling, not a total. A total across refunds would need the metering companion. order_id and ticket_id are deployment-defined constraints, and a resource that cannot enforce a constraint must fail closed rather than ignore it. A $480 refund on order ord_58213 is inside the Mission’s authority. A refund on any other order, or above $500, is outside it. Part two’s enterprise policy still requires a supervisor above $250, so the $480 refund also needs approval for this instance.
approval_basis.consent_principal names the rep as the accountable approver. The drafts require an accountable human, or a principal accountable to one, because someone has to answer for the authority a refund ran under. Where policy activates Missions at machine speed, it adjudicates inside a template, a ceiling a person consented to once, so each task does not need another human click. How much standing approval a template can carry for unattended work is still an open design question.
The Mission on the AuthZEN Wire
The Mission AuthZEN profile carries the Mission’s identifier and the gateway’s view of its state into every evaluation. After the supervisor approves, the PDP checks the order and amount against the Mission’s constraints and checks that the approval still applies and has not been revoked. Its permit covers these exact arguments, expires at a stated time, and can be used once. A refund on another order is denied as out_of_authority, and any refund after revocation as mission_inactive. The series reference shows the requests and the permit and lists the denial reasons.
Closing the Ticket
With a Mission, the ticket system integrates once, with the Mission’s issuer, and each PDP consumes a standard task record instead of rebuilding the ticket relationship inside its own engine. Revoking the Mission changes its state once, and every Mission-aware PDP denies the next evaluation under it with mission_inactive, including the $480 refund whose approval has not expired. The Mission for ticket 8842 keeps running. Revoking by subject or by agent would have stopped both tickets. The deployment still owns the business rule that decides which ticket transitions end the work, here that a withdrawn complaint cancels unexecuted refunds.
Containment is the narrower lever. It leaves the Mission active and removes one capability, such as refunds, while reads continue. A PDP that implements the Containment companion denies the next refund as authority_contained, which keeps removed authority distinct from authority that was never approved. Selective containment needs an effective control that cannot be bypassed on every execution path the contained capability can take. Components behind that control need not understand the Containment companion, so a task-aware gateway in front of a task-unaware commerce API can block the task’s refunds while reads continue. A path with no such control, such as a route around the gateway or work a downstream system has already accepted, needs another restriction or the broader fallback of revoking the task, and the drafts do not yet say what an issuer must do about it. COAZ-MCP states the same principle for its mappings: at least one COAZ-aware PEP “in the deployment path” should authorize each in-scope message. Test 9 checks the deployment’s declared fallback.
SSF carries either change to subscribers, and enforcement follows within a bound rather than instantly. In the worst case the response takes the published staleness bound plus the permit’s validity plus the action’s execution time. Paths with no PEP run until their credentials expire or are revoked, and actions already completed are not undone. The Blueprint’s kill switch also expects “the outcome is published back as a confirmation signal.” The Mission drafts do not yet define that confirmation. A useful one would say that receiver R applied lifecycle version N of Mission M at time T for the action classes it enforces, and would not claim that everything stopped.
The task record also lets part two’s loop run at the grain of approved work. A Mission is granted with an authority boundary. Its use is measured against that boundary, by decision evidence at every enforcement point and, where the Mission Consumption Metering companion is deployed, by cumulative bounds such as max_budget and max_calls. It is contained when risk rises, revoked when the work ends, and widened only through a new approval. The Blueprint calls this “pairing static permission ceilings with dynamic real-time scoping.” The task record holds the ceiling, and the loop adjusts authority within it for each task rather than for each agent.
What Each Deployment Level Guarantees
The flow this part describes is a runtime-enforced deployment, the most demanding level. A deployment can start smaller, and each level gives a different guarantee.
| Capability | Useful guarantee | What it does not establish |
|---|---|---|
| Mission-aware issuance with safe authority projection | Issued authority is bounded by approved work, and the issuer refuses to issue where a resource cannot enforce a safe projection of it | That credentials already issued notice later task changes |
| Task-state-aware enforcement | Participating paths stop further authorization or execution within declared freshness and permit bounds | That completed effects are undone, or that every distributed system stops at once |
| Cross-vendor semantic profiles and tests | Independent implementations agree on the identities, operations, state, and enforcement requirements that matter | That every product understands every optional capability |
The Case Against
The Mission is the least mature piece on the series’ map. The OAuth binding is one individual draft at -00. The other Mission documents cited here are editor’s copies. The tests come from one reference implementation in one deployment, recorded in its conformance manifest, and no production Mission deployment is known on any binding. The family’s index lists 47 documents, even though a trial needs five. Part of that breadth reflects the problem’s real scope, and part is cost that a smaller proposal would avoid.
A task record adds another system to run. The issuer and its state source become tier-0 dependencies, and a state source that goes stale makes Mission-aware PEPs fail closed. Failing closed prevents unauthorized refunds but also stops legitimate work until the state source recovers.
A task record also cannot create atomicity the resource lacks. If the payment connector cannot reserve and commit, the refund’s single-use permit limits the number of attempts but not what a failed attempt leaves behind.
A Mission is worth its cost only where the task has to be checked across vendors without a bespoke task integration and ended without stopping the agent’s other work.
The Two-Vendor Refund Test
An enterprise can require each gateway vendor to pass three stages against the enterprise’s own policy service and approval service, with its incumbent gateway and the candidate both on the refund path. The enterprise states every time bound in seconds before the test.
- Change the rule. Lower the refund limit in the enterprise policy service and show both gateways enforcing the new limit. The stage passes if neither gateway needs vendor-specific adapter code, and the result lists every configuration and mapping change, including how the refund amount reached the decision request.
- Approve the exception. Route the $480 refund through the enterprise’s approval service. The stage passes if the refund proceeds only after a fresh decision, an approval identifier alone permits nothing, and no vendor approval inbox is involved. The result states which approval-matching case it exercised, ARAP’s exact-match baseline or a broader scope the deployment defines. The commerce platform keeps its right to refuse.
- End the work. Issue a permit for a ticket 8841 refund, then withdraw ticket 8841. The stage passes if, after the declared cutoff, both the original permit and any new refund request are refused, while ticket 8842, worked by the same agent, continues throughout, as tests 1 to 5 above specify.
Four negative checks run alongside, each described earlier in the series. A refund whose amount is missing from the tool’s mapping is refused or enforced another way. An obligation the gateway cannot perform is treated as a denial. An unreachable policy service fails closed for refunds. A retry with the task context stripped does not fall through to ordinary policy. Decision logs should be OCSF records joined on X-Request-ID and a trace identifier, and the series reference lists the commitments to ask vendors for in writing.
The stages differ in maturity. The first uses the Final AuthZEN API with an explicitly declared mapping of the refund amount, configured on each gateway or taken from COAZ-MCP, and the result should say which. A configured mapping shows that both gateways ask one PDP the same question. A shared COAZ-MCP mapping also shows that the translation from tool call to decision request interoperates, and replacing a gateway with every change reported shows the integration portability a buyer cares about. The second uses ARAP, a working group draft. The third is an experiment in a portable task lifecycle, and an enterprise can run it today with a ticket lookup at its own policy service. A Mission is one proposed way to carry the task boundary across policy owners, and another composition can pass the same test. The Alliance and its members could run the same test in public and publish the integration work, the limitations that remain, and the enforcement evidence.