An AI assistant may spend hours carrying out a task after the user leaves. During that time, a background worker may take over and its access credentials may need renewal. The system still has to enforce the limits the user approved and respond if that approval is withdrawn before the work is complete.
In Who May Do What? Authentication and Authorization for AI Agents, Alice asked a fictional Travel App to rebook her flight for the next morning, preserving the route and passengers and spending no more than CHF 500 extra. She approved a protected task record, g42, that permits one completed rebooking and allows a background worker called Fare Finder to help. The Booking Service stores that record and controls the path to the airline’s API.
We’ll now follow the job through the handover, the wait for a fare, and the eventual booking change. The service must connect the worker’s validated identity to Alice’s current permissions and the task she approved, then apply those checks to the actual quote submitted to the airline. This part assumes familiarity with applications calling services; the relevant details of Alice’s approval are below.
User and initial representative Alice (
user:u123); Travel App (service:travel-app)Parent task and operation
g42: rebookABC123Route and passengers Preserve those recorded in the current booking.
Departure window 27 September 2026, 06:00–12:00, Europe/Zurich
Maximum additional charge CHF 500, including fees
Approval time and expiry Approved 26 September 2026 at 14:00; expires that day at 20:00, Europe/Zurich
Permitted worker Fare Finder
Shared execution allowance One completed rebooking across the parent and its children
The services and dates are fictional design choices. Access tokens identify Alice as the represented subject and the software acting for her as the actor. The Booking Service validates those identities and checks current relationships in a permission service: Alice must be allowed to rebook ABC123, and the actor must be allowed to represent her. A grant reference locates the protected approval record; possession of that reference alone does not authorize its use.
1. A specialist receives part of the job
The Travel App handles the conversation, but searching may take hours. Fare Finder is a background worker that monitors offers and can submit a candidate change to the Booking Service. It has its own identity, service:fare-finder, and no authority to change bookings directly at the airline.
Alice’s task permits this specialist. There is also a standing relationship to establish: when she enabled background searches during enrollment, the account-management flow recorded Fare Finder as an approved booking representative. The task’s specialist list and that standing relationship must both allow the handover. If either is absent, the Travel App’s request for help is refused.
The Travel App sends grant reference g42 with its handover request. Its validated access context identifies Alice as the represented user and the Travel App as the actor. The Booking Service verifies that the Travel App is an authorized participant, that Alice still has the required rights, and that the grant allows Fare Finder. Only then does its task-management code create child grant g43.
The child identifies Alice, Fare Finder, and parent g42. It keeps booking ABC123, the confirmed departure window, the CHF 500 ceiling, and the 20:00 expiry. It forbids further delegation. Its one execution must consume the parent’s shared allowance.
This is attenuation: narrowing the authority available to the next participant. The child could have a lower budget or earlier expiry; it cannot increase either. These are application rules checked during creation and execution. Token exchange does not automatically copy and preserve them.
If two workers receive child grants, they must still share the one rebooking Alice approved. The Booking Service accounts for that allowance at the parent task.
Figure 1. The child inherits the parent’s limits and shares its single execution allowance.
Getting access to the worker
The job placed in Fare Finder’s queue contains the child-grant reference and search parameters, without user credentials. A component within the Travel App server manages access credentials outside the language model’s context.
Fare Finder authenticates to that component using its configured workload identity. The component verifies that the worker is assigned to g43 and checks the live grant before arranging access. Fare Finder also authenticates to the identity service and requests its own service token through a client-credentials grant.[1][6] For OAuth token exchange, the Travel App server’s credential component presents the allowed Alice subject token and Fare Finder actor token to the issuer. The issuer validates both under its exchange policy and returns access intended for the Booking Service.[7]
This requires an issuer policy explicitly permitting the Travel App server’s component to request access for that actor and subject. The component does not choose arbitrary identities supplied by a caller. The resulting token is intended for the Booking Service and is delivered only to the authenticated, assigned worker. At the Booking Service, validated actor information now identifies Fare Finder rather than the Travel App.
The Booking Service checks the task grant again when the worker submits a change. Token issuance leaves the task’s approval and execution state unchanged.
RFC 8693 treats historical nested actors as informational for access-control decisions. Earlier actor names can help reconstruct the route, but permitted handovers must be established through the parent–child records and issuance policies.[7]
Fare Finder can search while Alice is away from the browser.
2. Fare Finder gets a quote two hours later
Alice’s confirmation was recorded at 14:00, and she has left the application. No suitable fare is available immediately. At 16:00, Fare Finder finds an offer for the next morning, departing at 09:10 and costing CHF 420 extra, including fees.
The 20:00 task expiry is still four hours away. The access credentials used to submit the change may already need renewal.
For this example, our identity service supports offline access for the required booking flow. Alice granted the required consent, and the Travel App server received a refresh token. The server retains it securely and uses it at the identity service to obtain fresh user access when needed. The renewed subject token can then enter the configured token-exchange flow used to obtain access for Fare Finder. The worker never receives the refresh token.[1][2]
The refreshed credentials remain subject to g42’s original expiry and budget, and to Alice’s current permissions. If renewal or exchange fails, the work must pause or ask Alice to reauthorize. Switching to an unrestricted service account would bypass her authority.
Alice can cancel the task through an explicit control that withdraws its authority for future execution. Closing her browser may leave a server-side session alive, and ending that session need not cancel the task or revoke issued tokens. The application defines each action separately.
Figure 2. Two alternative histories, shown schematically rather than to scale. A cancellation committed before the execution claim blocks the task and its children; token renewal cannot restore that approval.
Checking the current authority
During the wait, Alice could lose access to the booking, disable Fare Finder as a representative, or cancel g42. Any of these must affect the eventual execution decision even if a token remains valid.
This raises a freshness question. Token introspection can be cached, and permission checks may use older snapshots of relationship data. A successful lookup does not necessarily mean every recent withdrawal has been observed.[4]
Zanzibar addresses this class of problem with explicit consistency mechanisms, including markers that can require a check to reflect a relevant point in history. The execution path must request and propagate the consistency guarantees needed to observe relevant rights changes.[5]
For our system, the execution path requires token validation and relationship reads meeting its defined freshness policy, alongside a current task-record check. Task cancellation and claiming the execution allowance use coordinated state in the task store. A cancellation committed before that claim prevents new execution through the parent or its children.
The task store, permission service, token issuer, and airline do not share one atomic transaction. The implementation must define how concurrent rights changes affect an operation already in flight. Cancellation cannot guarantee an undo once an irreversible airline operation has begun.
The final check must also apply to the exact quote submitted to the airline.
3. The service authorizes the actual change
Fare Finder submits a request identifying the booking, operation, child grant, and quote. In this conceptual request, q17 identifies the quote:
Operation: rebook
Booking: ABC123
Grant: g43
Quote: q17
The request arrives with an access token intended for the Booking Service. Validating it yields Alice as the represented user and Fare Finder as the actor. Those identities come from the trusted validation result, not from fields the worker can freely set.
The Booking Service retrieves g43 and its parent g42. It also resolves q17 against the airline’s trusted quote information. The worker can propose a quote reference; it cannot establish the charge by declaring extra_cost = 420.
At 16:00 on 26 September, the Booking Service evaluates the request:
Is the presented access acceptable here? Evidence used: Validated issuer, activity, lifetime, audience, and required scope. Result: Yes.
May Alice rebook
ABC123? Evidence used: Alice’s mapped identity and current ownership relationship. Result: Yes.May Fare Finder act for Alice? Evidence used: The validated actor and the standing representative relationship. Result: Yes.
Is this worker assigned to this task? Evidence used:
g43names Alice, Fare Finder,ABC123, and parentg42. Result: Yes.Are the task and its parent still valid? Evidence used: Neither is cancelled; both are within expiry; the child respects the parent’s limits. Result: Yes.
Does the quote satisfy the instruction? Evidence used:
q17preserves route and passengers, departs at 09:10 on 27 September, and costs CHF 420 extra including fees. Result: Yes.Is the shared execution allowance available? Evidence used: Parent task’s protected execution state. Result: Yes, subject to the atomic claim below.
The identities must line up across all these checks. If the grant belongs to Bob, Alice’s token does not make it usable. If the actor is the Travel App but the child permits only Fare Finder, the child check fails. The service reads those assignments from its protected record.
Some systems evaluate the price and time conditions inside their permission engine; others use application policy code. Either arrangement still depends on trusted inputs and an enforcement point that combines the results. Missing quote details, a failed check, or an unavailable required check causes a refusal or temporary failure. The booking remains unchanged.
From an allowed request to one completed operation
A permission check does not reserve a fare. The Booking Service must bind the airline request to the quote it actually evaluated. In this fictional integration, the airline supports a quote-bound operation: it either accepts q17 on its stated terms or rejects the request if those terms are no longer available. A provider lacking that capability would require a different design; merely checking the price first would not create the same guarantee.[9]
The Booking Service also claims the parent’s single execution allowance through an atomic state change. This prevents two workers from simultaneously observing “unused” and both proceeding. It records a stable operation ID, op81, before submitting the airline request. An in-progress or uncertain operation continues to hold that allowance.
The service calls the airline using the downstream access configured for its integration. The internal user-and-actor token is not automatically valid at the airline. The Booking Service may have broader airline rights than Alice’s task; its own enforcement is what prevents those rights being used for an unapproved change.
If the response is lost, the service must resolve the outcome before starting another operation. Our illustrative airline integration supports querying or retrying op81 without creating another booking change. This is idempotency: repetition of the same operation does not repeat its intended effect. Neither a valid token nor a permission-engine response provides it automatically.[10]
For the main case, the airline accepts q17 and confirms the rebooking. The Booking Service records op81 as completed and consumes the shared allowance. The booking now reflects Alice’s approved change.
Figure 3. Passing the checks is followed by a coordinated execution claim. This example also assumes the airline supports quote-bound changes and idempotent operation identifiers; uncertain outcomes require reconciliation.
Change one fact
The quote costs CHF 700. Alice still owns the booking, Fare Finder remains her representative, and the token is valid. The task-limit check fails. No airline operation begins. The worker can keep looking within the remaining time or ask Alice for a new approval; it cannot amend the existing limit itself.
Alice cancels at 15:30, before execution is claimed. At 16:00, the CHF 420 quote still meets the original limits, but the parent task is cancelled. The task check fails and its child cannot execute. A newly refreshed token does not restore the cancelled authority.
Both requests arrive with valid credentials. The Booking Service refuses them because the quote exceeds the approved budget or the task has been cancelled.
4. Explain the result
Alice returns and sees the confirmation: her flight now leaves at 09:10 the next morning, with an additional charge of CHF 420. The application should be able to explain more than “the agent completed your request.”
A compact execution record could show:
Represented user and attributed actor Alice; Fare Finder
Approved authority Parent
g42, childg43, retained approved versionsOperation
op81: rebookABC123using quoteq17Decisive limits CHF 500 maximum; confirmed departure window; one change
Decision Required identity, relationship, task, and quote checks passed at execution.
Outcome Airline confirmed; CHF 420 extra; parent allowance consumed.
The actual audit design also needs timestamps, policy or data references sufficient to investigate the decision, and protection against unauthorized alteration. It should not store usable access tokens, refresh tokens, session cookies, or private keys. Actor attribution should remain distinguishable from any separately verified sender identity.[11]
If Alice later questions the charge, the record should let her see the limits she confirmed and the quote the service accepted. An operator should be able to establish which worker submitted the request, which checks allowed it, and whether a retry reused op81. Those are the records needed to investigate the change.
The approval path is covered in Who May Do What? Authentication and Authorization for AI Agents.
Technical notes
Validating subject and actor
Our example uses opaque bearer access tokens. The Booking Service obtains their validity and identity information through authenticated introspection at the configured issuer. That lookup must expose both subject and actor; support for token exchange alone does not establish this capability. The service also checks audience, lifetime, and required scope.[4][7]
Because the tokens are bearer tokens, a thief who possesses one may present it with the same actor information. Actor attribution does not prove the identity of the current sender. Sender-constrained tokens, such as DPoP or mutual-TLS certificate-bound tokens, address that separate requirement.[3][8]
Gateways and MCP
A gateway can route requests and enforce shared rules without becoming the owner of every business decision. If it reverse-proxies the Booking Service as the same protected recipient, the token still needs to be valid for that recipient. If the backend instead trusts identity assertions supplied by the gateway, the authenticated path, removal of caller-controlled identity fields, and prevention of bypass become part of that trust design.
Exposing booking operations through the Model Context Protocol does not change the task’s authority. The cited HTTP MCP authorization specification requires intended-audience validation and defines discovery and resource-identification requirements. A token intended for an unrelated upstream service is not a universal pass through an MCP server.[12]
Lifetimes and service-owned work
Our example assumes supported offline access, service-token issuance, actor-aware exchange, and introspection. Those capabilities and their policies must be verified as one integration; no single OAuth feature guarantees the whole path. Revocation of an input token also does not automatically revoke every token derived through exchange.[7]
Some software acts under its own authority. The Booking Service might delete expired quotes as routine housekeeping. That job requires its own permitted service access, without inventing a user behind it. Continuing Alice’s rebooking task is different: its user rights and task approval remain relevant throughout.
Sources and further reading
These sources support the protocol and security concepts discussed in this part. The services, permission rules, task grants, and airline capabilities are explicit choices in the fictional example.
IETF, The OAuth 2.0 Authorization Framework. RFC 6749, particularly sections 4.4 and 6 on client credentials and refresh tokens. Read with RFC 9700, OAuth Security Best Current Practice.
OpenID Foundation, OpenID Connect Core 1.0, errata set 2. Specification. Offline-access consent and refresh-token provisions. Issuer policy must permit the API access used in this example.
IETF, Bearer Token Usage. RFC 6750. Bearer semantics, request presentation, and token protection.
IETF, OAuth 2.0 Token Introspection. RFC 7662. Protected lookups, response fields, and caching considerations.
Pang et al., Zanzibar: Google’s Consistent, Global Authorization System. USENIX ATC 2019 paper. Relationship tuples, configured rules, and consistency across authorization changes.
IETF, JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants. RFC 7523. Client assertions and the distinction between authentication and grants.
IETF, OAuth 2.0 Token Exchange. RFC 8693, especially sections 2 and 4.1. Subject and actor tokens, actor claims, and lifecycle limitations.
IETF, Sender-constrained access. DPoP, RFC 9449 and mutual TLS and certificate-bound access tokens, RFC 8705.
OWASP, Transaction Authorization Cheat Sheet. Guidance. Binding authorization to significant transaction details and final execution.
IETF, HTTP Semantics. RFC 9110, section 9.2.2. Idempotency semantics. The quote-binding, operation-ID, and status-query capabilities in this article are assumptions about the fictional airline API, not guarantees of HTTP.
OWASP, Logging Cheat Sheet. Guidance. Useful event evidence and exclusion or protection of credentials and sensitive data.
Model Context Protocol, specification version 2025-11-25. Authorization and Security Best Practices. Audience boundaries and token-passthrough risks.