I would separate three identities before discussing a token. There is the human who asked, the agent run doing work on that person's behalf, and the service that actually calls the account or payment system. If all three collapse into one broad service credential, the payment service has no way to tell a permitted refund from a model suggestion. The model should never receive a payment credential in its prompt, tool result, or sandbox environment.

The runtime can let the agent propose a refund. That proposal contains the account, original payment, amount, currency, reason, and evidence. A policy service evaluates the current user grant, tenant, resource, limits, and whether a second human approval is required. If approved, the approval record binds the exact action or a narrowly defined range. It must not be a free text “looks good” that still works after the model changes the amount or recipient. The tool gateway then uses its own tightly scoped workload identity to call the provider. The service credential belongs to that gateway, with access limited to the operation and environment it serves. Secrets stay in a managed secret store or token broker, not inside the model process.

If the downstream service supports delegation, a short lived token can carry the user subject, actor, audience, and scopes. OAuth token exchange describes one way to represent a delegation chain. That format is useful for identity and audit, but the existence of a token does not prove that this amount on this account is still authorized. A service that only accepts an application credential still needs the gateway to enforce the user action policy and log the on behalf of identity. I would not put a generic “refund” bearer token in the agent's hands just because it expires in five minutes.

There are two gates at different times. Before the model sees account data, authorize that read and limit the fields returned. Before a refund leaves our boundary, authorize that precise effect again against current grants and the approval payload. Record the policy revision, decision, approver, operation ID, arguments digest, provider request reference, and eventual effect status. The audit trail needs enough to reconstruct who caused what without copying full account data into a general trace. The refund can be submitted and then time out, so the ledger must support an unknown outcome. The recovery mechanics are covered in the refund failure question, but here the key point is that a model's “done” cannot close the audit entry.

Now the run pauses for an hour and the user's refund authority is revoked. Any old approval derived from that authority must be invalidated under the product's grant rules. On resume the runtime does not simply replay an old prompt and send the stored tool call. It checks the live grant and approval validity at the effect boundary. A cached access token may remain cryptographically valid until expiry, so revocation needs either introspection, a revocation epoch checked by the gateway, very short validity with an accepted exposure window, or a downstream conditional check. OAuth token introspection defines an active status mechanism, though each deployment chooses its caching and revocation contract. If the policy service is unavailable for a money movement, stop and surface pending authorization, rather than treat its absence as permission.

What if the refund request had already been submitted just before the grant was revoked? Our local gate can prevent later submissions. It cannot undo a request that left the process. Keep the ordering point in the audit log, reconcile the provider's outcome, and report it. A stronger promise that revocation prevents an effect right up to remote commit requires participation from the payment system.

I would test the exact approval with a changed amount, a changed account, a replayed approval, an expired grant, a paused run resumed under a new user, and revocation racing with submission. The question is not “can the agent call the refund API?” It is whether every call has a current, attributable, bounded authority for the precise effect.