Who Can Change an AI Agent’s Spending Mandate After Approval?

TL;DR

• After initial approval (opens in a new tab), the mandate owner must assign change authority for each covered payment path. No protocol assigns a corporate approver by default.
• The mandate owner should separate change requests from approvals and require independent approval for changes to the approver list. DFNS policies (opens in a new tab) illustrate how such requirements can be configured.
• Emergency exceptions need a defined scope, expiry, and activation time. Revoking future signing does not necessarily cancel authorizations already signed (opens in a new tab).
• A counterparty can check a covered action against the policy version identified in a verifiable receipt (opens in a new tab). Proof validity alone does not establish corporate approval, external-input accuracy, replay protection, or settlement.

Why spending mandate changes require separate approval

An approved spending mandate does not settle who may change it later. A higher limit or an emergency override can change what an AI agent may spend after initial approval. Adding a counterparty can change where it may spend. The business must assign amendment authority for each payment path covered by the mandate.

Payment protocols can check an authorization without choosing a company’s change approver. The AP2 specification (opens in a new tab) defines mandates and verification rules, but it does not prescribe which corporate role approves a later amendment. The DFNS Policies API (opens in a new tab) shows how a buyer can require approval for policy changes. It can also govern changes to permissions that determine who may edit a policy. Neither design supplies a universal finance or risk approver.

A request, an approval, and an effective revision are separate events. A treasury operator might request a higher limit, while a designated risk approver decides whether to authorize it. The approval record should identify the revised policy and when it takes effect on each covered path. The business must also check pending payments and previously issued authorizations before treating the old limit as withdrawn.

Who can request a change versus who must approve it?

A mandate owner should assign change requests and change approvals to separate roles. An agent or treasury operator may need to request a higher limit or a new payment destination. A designated finance or risk approver should decide whether that request takes effect.

The separation needs to cover the authority to edit the mandate itself. In a DFNS managed-account example (opens in a new tab), a service account requests a destination-policy update. A separate policy requires compliance-officer approval before the update takes effect. DFNS also documents controls for policy modifications and permission changes (opens in a new tab). The example illustrates a governance pattern, not a required arrangement for every AI agent.

The mandate owner must decide who can change the approver group. The DFNS user and group guide (opens in a new tab) explains how group membership determines who is eligible to approve a request. If a requester can add themselves to the approver group without independent review, the approval requirement may be bypassed. Permission grants and changes to the rules governing approval deserve the same scrutiny.

For each covered payment path, the authority record should name who owns the mandate, who can request an amendment, who must approve it, and who can alter those approval rights. A separate approval record should identify the decision and the policy revision it authorizes. The mandate owner should verify that these controls are active on the paths where the revised mandate will apply.

AP2 schema versions and approved policy versions

AP2’s vct suffix identifies a mandate’s schema version, not a company’s approved spending-policy version. The AP2 specification (opens in a new tab) requires verifiers to match the full vct value, including its numeric suffix. The same AP2 schema version can describe mandates with different approved spending limits. The shared suffix says nothing about who authorized the change.

A company therefore needs a separate record for each approved policy revision. That record should identify the mandate owner, the person who requested the change, the required approver, the approved terms, and the time the revision takes effect. It should also identify which payment paths use the revision and which earlier revision it replaces. A verifier cannot infer those corporate decisions from the AP2 schema version.

AP2 provides signed mandates and native checks for authorization and defined constraints, but its specification does not prescribe a corporate process for amending or replacing an in-force mandate. Issuing a revised mandate also does not, by itself, establish that every outstanding authorization under the earlier terms has expired or been cancelled. The change record should state how the company handles those authorizations on each covered payment path.

Emergency exceptions: scope, expiry, and activation timing

An emergency exception should name the payment paths it covers, the temporary rule, and the person authorized to approve it. The approval record should state when the exception begins and expires. If the payment system cannot restore the prior rule automatically, an assigned owner must make and verify that change at the stated time.

Activation timing needs a separate decision because a policy change may affect requests already in progress. In DFNS policy management (opens in a new tab), an update takes effect immediately and applies to pending approvals. Before activating an exception, the approver should identify pending requests and decide whether they should remain subject to the prior rule or receive a new review. The mandate owner must check how each other covered payment path handles pending requests.

The exception record should also specify the version that resumes after expiry. Revoking an emergency rule for future requests does not, by itself, establish what happens to authorizations already issued under it. That question requires a check of the affected payment path.

What happens to authorizations already signed before the change?

Revoking an agent’s mandate stops new authorizations only on paths that enforce the revocation. It may not cancel payment authorizations the agent already signed. DFNS warns that an existing ERC-3009 authorization remains usable (opens in a new tab) until its validBefore expiry, even if the signing policy changes. Any earlier cancellation depends on the payment rail’s available mechanisms.

In x402’s exact scheme (opens in a new tab), a validity window limits when a signed payment can be used, and a nonce helps prevent replay. Neither check establishes whether the buyer later revoked the agent’s business mandate. The x402 upto scheme (opens in a new tab) sets a deadline and consumes an authorization after settlement. An unused upto authorization may remain available until its deadline unless the applicable payment path provides an effective cancellation mechanism.

Before a mandate change takes effect, the mandate owner should inventory signed authorizations that have not settled. The inventory should identify each payment rail, recipient, amount or ceiling, validity window, and current status. For each rail, the owner should ask whether an unused authorization can be canceled, who can cancel it, and how to confirm cancellation. If cancellation is unavailable, the owner must account for the remaining validity window. Payments that have already settled require a separate refund or dispute process where one exists.

Comparing the control classes that can enforce a change

A mandate change constrains payments only where the covered path enforces the revised authorization or policy. Each control class has a different approval point, coverage boundary, and evidence record.

In a proposed Inherence payment integration, the buyer would require each covered payment path to check the approved policy version before authorization. A failed check would stop the action on that path only if the check were mandatory. A verifiable receipt would let a counterparty check the defined evaluation against that version without receiving protected inputs encoded in the proof. Monitoring can flag activity later, but it cannot stop a payment that has already executed.

What a counterparty can verify about a change and its governing policy

A counterparty can verify the evaluation of a covered proposed payment if the integration supplies a receipt, an accepted verification key, and the expected public inputs. The receipt’s proof (opens in a new tab) must be checked against the expected public inputs and an accepted verification key. Proof validity alone does not establish who approved a mandate change or whether that version had taken effect.

A counterparty should compare the receipt with independently trusted authorization and payment records.

• Expected-action binding. The receipt must match the intended payee, amount, and payment instrument.
• Policy-version match. The receipt must name the approved version governing that payment, rather than an earlier or unapproved revision.
• Freshness. The receipt must fall within the counterparty’s accepted time window. The payment path also needs a separate replay check for identifiers or authorizations that cannot be reused.
• Record association. Receipt identifiers must match the relevant authorization and payment records. A valid proof cannot establish those links on its own.

Corporate approval needs separate evidence, such as a signed change record identifying the authorized approvers and the amendment’s effective time. External facts used in a policy check need evidence from an authoritative source. Settlement needs confirmation from the payment provider or network. Native protocol authorization checks still apply where AP2 or x402 governs the payment.

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. Any binding between Inherence receipts and AP2 or x402 records remains proposed integration architecture unless a specific implementation has been validated.

Decision checklist before authorizing a mandate change

• Confirm mandate ownership. Record the business owner responsible for approving changes to spending limits, permitted recipients, and covered payment paths.
• Separate requests from approvals. Check who can submit an amendment, who must approve it, and who can change the approver list.
• Bound emergency exceptions. Specify the permitted action, affected paths, approver, expiry, and point when the prior policy resumes.
• Set the activation time. Record the new business policy version and confirm how the change affects pending requests on each covered path.
• Sweep outstanding authorizations. Identify payments already signed, check their validity windows, and determine whether each payment rail permits cancellation. A change to future signing rules may leave earlier authorizations usable.
• Retain the evidence record. Keep the request, approvals, effective time, prior and new policy versions, and affected authorization identifiers. For covered actions, retain any receipt that binds the proposed payment to the evaluated policy version. Verify approval authority, external inputs, replay status, and settlement through separate records or controls.

Conclusion

A mandate owner should record who may approve changes on each covered payment path. The change record should identify the approved version, its effective time, and any exception’s expiry. A counterparty needs that approval evidence separately from evidence of the payment’s policy evaluation.

The pre-approval checklist (opens in a new tab) addresses initial setup. The payment mandate guide (opens in a new tab) covers compliance timing.

FAQ

• Can an agent amend its own mandate? An agent can request a change if its owner permits it, but the owner should assign approval authority separately. The owner should also govern changes to approver permissions, which could otherwise bypass the approval requirement. A DFNS example (opens in a new tab) requires compliance officer approval before a requested destination-policy change takes effect.
• Does revoking a mandate cancel payments already signed? Revocation can stop future authorization without canceling a previously signed payment. An x402 payment authorization (opens in a new tab) may remain usable until its validBefore expiry. The mandate owner must check outstanding authorizations and the payment rail’s cancellation rules.
• Is AP2’s version number the same as the approval record? No. AP2’s vct version suffix (opens in a new tab) identifies the mandate’s schema, not the business policy revision that an approver accepted. The mandate owner needs a separate record of the approved policy version and its effective time.
• What can a counterparty check, and what requires separate evidence? A counterparty can verify a receipt (opens in a new tab) for a covered action against the expected action and policy version when the integration provides the required verification inputs. Proof validity alone does not establish who approved a change, whether external inputs were true, whether an authorization was replayed, or whether payment settled. Each question requires its own evidence or control.