Spending authority
MPP and x402 describe how a client answers one payment challenge. Sui Agent Payments adds memory across requests: an on-chain record of who may spend, where, how much, and until when.
Delegated signers and grants
The unit of agent authority is a delegated signer: a logical agent identity that maps to one on-chain grant per asset on the owner's spend account.
A grant binds:
| Field | Meaning |
|---|---|
| Account | The single funded spend account this grant may draw from |
| Delegate | The one Sui address allowed to call pay with this grant |
| Policy snapshot | Immutable list of on-chain policy IDs at grant creation |
| Session / total budget | Cap on cumulative spend for this grant (session_cap) |
| Per-payment cap | Per-signer ceiling (max_per_payment) in addition to policy/target caps |
| Expiry | Wall-clock expiry in ms; 0 means no expiry |
| Pause / revoke | Lifecycle flags enforced on every pay |
Creation is owner-only (create_grant). Settlement is
spend_account::settle_policy_payment. Revoke is owner-only and terminal
(revoke_grant).
The agent authenticates by signing the payment transaction as the registered delegate. The contract applies policy because that key is a registered scoped signer, not because a server session says so.
Policy scope (enforced on chain)
At payment time, pay checks (among other things):
- delegate matches the grant;
- spend account, grant, and policy are active, unpaused, unrevoked, and unexpired;
- the service target hash is a member of the grant's snapshotted policies;
- recipient is the stored target recipient (no free-form pay-to at pay time);
- amount is within policy total remaining, policy/target per-payment caps,
grant remaining budget, and grant
max_per_payment; - spend-account balance is sufficient;
payment_id_hashhas not been consumed on this account (account-scoped replay marker).
Off-chain entitlement checks may mirror these rules to fail early. They are
advisory. If an off-chain check and pay disagree, the chain wins and the
resource is not served.
Two provisioning methods, one spend account
| MCP OAuth | Bring-your-own key | |
|---|---|---|
| Key custody | Agent generates and holds the key; OAuth binds the grant to that address | Agent generates the keypair; Sui Agent Payments stores only the public address |
| How you connect | Remote MCP OAuth consent | POST /v1/delegated-signers + owner-signed create_grant |
| Grant | Spend-account grant bound to the agent-held address | Same grant, with max_per_payment on the grant |
| Settlement | Agent signs in the process that holds the key | spend_account::settle_policy_payment with the BYO delegate as sender |
See Authorizing agents for the product-level comparison and Authorize an agent for the owner BYO flow.
What the agent does not get
A delegated key cannot withdraw from the spend account, top up, create or alter policies, manage other grants, redirect payment to an arbitrary address, exceed grant or policy caps, or spend after expiry or revoke. Blast radius of a leaked key is the remaining grant budget within the snapshotted policies and caps, plus any sponsored gas quota for that signer.