# Mandate

A record of bounded intent or authority, represented so that another system can verify it — naming who authorised what, for whom, within which limits and for how long.

Source: https://aecon.ai/glossary/mandate
Updated: 2026-09-15

## In practice

A signed record permits one named supplier, one purpose, a maximum amount and a two-hour window, and requires fresh approval if the total or the seller changes.

## The distinction

A mandate represents authority; it does not enforce it. The receiving system still has to validate the scope, expiry and revocation state, and a payment credential that can spend is not the same as permission to buy this thing from this supplier.

## What a usable mandate answers

- Which legal or account principal owns the budget
- Which agent or workload may propose the purchase
- Permitted supplier, category and geography
- The purpose and the required output
- Per-purchase and cumulative limits
- Currency, asset, network and fee limits
- Start, expiry and revocation
- Whether a change to price, recipient, scope or delivery needs fresh approval
- Which data may be disclosed
- Who can stop, reconcile and remedy the job

## Approval binds to the effect, not the topic

Approving "handle my inbox" is too broad to authorise sending any particular message. Approving a draft is incomplete if the agent can change the recipient or the attachment afterwards.

Effective approval binds to a canonical representation of the proposed action — target, operation, material fields and timing — expires, and fails when a material field changes. A denial or an expiry is never converted into approval by retrying.

## Three different things

A mandate says what was authorised. A **credential** is what gets presented to the seller or payment system. An **authorisation** is the issuer's or bank's acceptance of a proposed payment.

They are frequently collapsed into one word, which is how an agent ends up with a token that can spend far beyond the job it was given.

## Sources & context

- [AP2 specification](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md) — Google Agentic Commerce, v0.2. Specifies signed Intent, Checkout and Payment Mandates for human-present and constrained human-not-present commerce. It binds represented constraints and does not supply a catalogue, rail, contract or dispute institution. Checked 2026-09-13.
- [PayTo FAQs](https://www.auspayplus.com.au/solutions/payto-faqs) — Australian Payments Plus, 2026. Describes agreements stating amount, purpose and frequency for one-off, ad hoc and recurring debits that customers can view and manage. The agreement authorises a debit, not the underlying job. Checked 2026-09-13.

## Related reading

- [Authority](https://aecon.ai/glossary#authority)
- [Delegation](https://aecon.ai/glossary#delegation)
- [Commerce protocol](https://aecon.ai/glossary/commerce-protocol)
- [Settlement](https://aecon.ai/glossary/settlement)