TL;DR
- Finance leaders should treat agent spending authority as a business approval decision, not a technical rollout. This approval checklist covers the mandate, the control path, and the evidence a counterparty can check later.
- The mandate should name the principal, delegated authority, eligible payees, transaction and cumulative limits, required approvals, expiration, and revocation authority.
- AP2 and x402 already provide native payment controls. Before approval, finance leaders should require evidence that every covered payment route enforces the approved policy before execution and draws on an authoritative spending record. Alternate signers or credentials must not bypass those checks.
- A counterparty can check evidence that a covered action was evaluated against the committed mandate. Separate checks must establish payment binding, freshness, replay safety, and settlement.
Why this decision belongs to finance, not engineering
Finance must decide whether an AI agent may spend company money before engineering gives it payment access. Engineering can test configured permissions, but finance must define which payments the business authorizes and who may approve exceptions. Configured permissions can still allow a payment the business did not intend to authorize.
Consider an accounts payable agent permitted to change a vendor’s bank details and release payments. The agent could redirect a payment without exceeding either permission. Finance should separate authority to change vendor bank details from authority to release a payment, so a single agent cannot redirect and release it without an independent check. Technical permission alone does not establish business approval.
Finance should require a written mandate, a map of the pre-execution control path, and evidence a counterparty can verify for each covered payment. The mandate defines permitted spending. The control map identifies enforcement and bypass routes. The evidence specifies what an outside party can check against the committed mandate. The agent guardrails guide (opens in a new tab) covers the wider control stack.
Define the mandate before granting authority
Finance should approve a written spending mandate before an agent can initiate payments. The mandate should identify the principal: the legal entity or account holder whose funds the agent may commit. It should name the person authorized to delegate spending power and distinguish payments the agent may prepare from payments it may submit for execution.
The mandate should specify eligible payees and destination accounts. Finance must decide how new payees and changes to bank details receive approval. An agent that changes a vendor’s account details should not release a payment to that account without an independent check. Any approval should identify the payee, account, and amount it covers. A change to those details requires fresh approval.
Finance should set a per-payment ceiling and a cumulative cap over a defined period. The cap should state which agent identities and payment routes draw on the same allowance. Finance must also name the required approver for payments above a threshold or outside the permitted scope. The mandate should state when authority expires, who can suspend or revoke it, and how pending payments and issued credentials are handled after revocation.
AP2’s payment mandate specification (opens in a new tab) defines payee, budget, and execution-date constraints. Finance still has to choose the permitted values and approve who may change them. Lead Bank’s proposed “Authorized Financial Agent” framework addresses verifiable mandates and revocation, but a social post alone is not sufficient support for its specific provisions or legal status. Confirm the proposal in a primary document before retaining these claims.
The finance approver should record the mandate decision against these criteria.
- Principal and delegation: The funding entity, delegating authority, and permitted payment actions are named.
- Payees and approvals: Eligible payees and accounts are recorded. New or changed details require a defined independent check, and approval thresholds have named owners.
- Exposure: Per-payment and cumulative limits include a period and specify which identities and routes share the cap.
- End of authority: Expiration, suspension, revocation, pending payments, and issued credentials have documented handling.
- Decision: A named finance approver signs the mandate and requires reapproval before any material change takes effect.
Map the control path from mandate to money movement
A finance leader should approve spending authority only after engineering maps every route between an agent’s payment request and money movement. The map should identify who holds each signing key or payment credential, which checks run before use, and which actor can stop a transaction. A policy check on one application route does not constrain a second wallet signer or an API key that can initiate the same payment elsewhere.
Native protocol controls belong on that map. AP2 verifies a chain of delegated mandates (opens in a new tab) before accepting an action. Its payment mandate specification (opens in a new tab) supports allowed payees, payment instruments, date ranges, and budgets. Confirm with Patrick how AP2 accounts for previously approved mandates when checking a budget before retaining this implementation claim. The finance question is whether every covered payment route applies the approved corporate mandate and draws on the same reliable spending record.
x402 buyer controls (opens in a new tab) restrict recognized assets and cap individual payments by default. Buyers can change or disable those settings. Payment liability also depends on the scheme. Exact payments specify a fixed amount. Under upto (opens in a new tab), a buyer authorizes a ceiling and the seller can charge less, so a corporate budget would need to reserve the ceiling while that authorization remains usable. Batch-settlement (opens in a new tab) uses deposited escrow and cumulative vouchers, with claims settled later. Engineering should explain how each scheme consumes budget before another covered request can spend it.
A separate pre-execution policy check can enforce company terms on routes required to pass through it. The route inventory must identify any signer or credential that can bypass that check. The approver should ask whether an alternate signer, card credential, payment API key, facilitator, or transfer route can move funds without that check. Engineering should also identify the authoritative spending record across covered paths, how it prevents simultaneous approvals from exceeding a cumulative limit, and how reservations become settled, released, or expired. Any shared-state integration across AP2, x402, wallets, or other rails remains a proposed design until validated on the actual routes. Monitoring can flag a payment after execution, but an alert cannot prevent a payment that has already settled.
External inputs need their own checks before policy enforcement relies on them. If a payee’s eligibility comes from a screening service, engineering should identify the service, authenticate its response, and define how recent that response must be. A valid policy evaluation can establish that a covered action met the committed rule using the supplied input. It cannot independently establish that the screening service supplied a true or current assessment. Inherence’s evidence applies to 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.
What a counterparty can verify after the fact
A counterparty can verify an Inherence policy receipt for a covered action without relying solely on the agent operator’s logs. The verifier checks the receipt against the accepted public inputs and a verification key, then confirms that the key corresponds to the approved policy version. That check can establish the defined policy evaluation without disclosing protected inputs encoded in the proof.
A valid policy receipt does not, by itself, identify the payment that executed. The receiving party must match the covered action to the payment authorization and, separately, to the settlement record. The receiving party must check the evidence’s freshness and the payment system’s replay protections separately. Inherence’s guardrails guide (opens in a new tab) explains why proof validity alone cannot establish those acceptance conditions.
Evidence also depends on the inputs and spending history the policy evaluated. A receipt can show that a payee-eligibility result entered the defined check, but it cannot independently establish that the source supplied a true result. Likewise, a correct budget calculation does not prove that an authoritative ledger captured every competing payment. A counterparty must therefore establish that the payment used the defined enforcement path and that the evaluated inputs came from the specified sources.
The AP2 Mandate Receipt (opens in a new tab) records a verifier’s signed result against a referenced mandate; confirm this description against AP2’s primary documentation and have Patrick review it before publication. It should not be confused with evidence of an internal policy computation. Shared spending state across AP2, x402, or multiple wallets would require enforced routes and an authoritative ledger. Any such cross-protocol or cross-wallet integration remains proposed architecture until demonstrated, not a shipped capability.
Approval checklist: conditions to document before go-live
The go-live record should identify the finance approver, document the following checks, and record approval or a reason for withholding it.
- Record the principal that owns the funds, the agent identity, and the payment actions delegated. Keep vendor-bank-detail changes separate from payment-release authority.
- List eligible payees and verified destination accounts. Require independent confirmation of a changed account using contact information already on file.
- Set per-transaction and cumulative limits, including the time window for each. State how pending authorizations count toward the cumulative limit.
- Name the approver for payments that require human sign-off. Bind each approval to a payee, account, and amount. Require re-approval if any of those details change before execution.
- Record when authority begins and expires, who can revoke it, and how pending payments can be stopped. Require re-approval after any mandate change.
- Inventory every wallet signer, card credential, API key, and alternative payment route. Confirm that each route carrying covered payments passes through the pre-execution check. Disable routes that bypass it before go-live.
- Record the native controls on each route. AP2 defines payee and budget constraints (opens in a new tab), and x402 clients support configurable per-payment controls (opens in a new tab). Specify which ledger reserves spending capacity across covered routes and how it releases or settles reservations. Treat any unvalidated cross-wallet or cross-protocol integration as proposed architecture.
- Name the source of payee and account information, the required authentication method, and the maximum acceptable age of each result. A valid policy evaluation does not establish that an external input was truthful or current.
- Specify which receipt and mandate version a counterparty receives for each covered action. Document how the verifier binds the receipt to the payment authorization and checks signer authority, freshness, replay protection, and settlement matching separately.
- Record the evidence boundary in the approval. 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.
Conclusion
The finance approver should grant an AI agent spending authority only after the mandate, enforcement routes, spending record, and counterparty evidence are documented. The sign-off should name any unresolved route or integration that remains outside the approved scope.
Approval should apply only to payment routes shown to pass through the required pre-execution controls. A counterparty should receive the specified evidence and independently check its connection to the authorization and settlement.
The agent guardrails guide (opens in a new tab) covers the wider control stack, and the payment mandate guide (opens in a new tab) covers compliance timing. Add links to the Payment & Treasury and Delegated & AI Agent pillar pages when those pages are live.