AI agent permissions: spending limits, expiry and revocation

AI agent permissions should specify the action, merchant, amount, currency and time window the customer approves. Systems handling the order and payment must enforce those limits. Expiry ends authority at a defined time; revocation provides a way to withdraw it earlier.

A natural-language instruction such as “find a good deal” is useful input for an agent. Before an irreversible action, the integration needs a precise approval that the receiving service can evaluate. The following is a proposed control design, not a claim that every protocol or AIR integration already implements every field.

What should a purchase permission contain?

• Actor and customer: which agent may act for which customer?
• Action: search, quote, reserve, purchase or redeem points?
• Merchant and goods: which seller, item, basket or permitted substitutions?
• Budget: maximum amount and currency, including the agreed fees, delivery and taxes?
• Usage: one purchase, a fixed number, or a cumulative budget?
• Time: when does authority begin and end?
• Withdrawal: where can permission be revoked, and how quickly must services observe that change?

OAuth Rich Authorization Requests, RFC 9396, defines a structure for carrying detailed authorisation information. The receiving systems still need agreed field meanings and enforcement. A well-shaped request is not evidence that a budget control has actually run.

Allow and deny examples

Use this hypothetical approval: one purchase from Merchant C, total no more than HK$500 including delivery, valid until 6pm Hong Kong time on the stated date, with no points redemption.

• Allow: the approved item totals HK$480 at Merchant C at 5pm, all required checks pass, and the permission has not already been consumed.
• Deny: a HK$490 item plus HK$30 delivery exceeds the total cap.
• Deny: another merchant offers the same item for HK$450. The seller is outside the approved scope.
• Deny: the request reaches the final authorisation check after 6pm, even if the agent began searching earlier.
• Deny: a second order attempts to use a permission restricted to one purchase.
• Request new approval: a points redemption would reduce the cash total but requires an action the customer did not authorise.

Represent timestamps unambiguously, including timezone or UTC offset. Define which processing event must happen before expiry so that the agent, merchant and payment provider apply the same rule.

How to enforce a spending limit across simultaneous requests

Checking each order against the original cap is insufficient for a cumulative budget. Two parallel HK$300 orders can each appear acceptable against a HK$500 budget, while their combined total exceeds it.

We recommend a shared budget record with an atomic reservation or equivalent concurrency control. Reserve the amount before commitment, settle it when the purchase succeeds and release it according to defined failure rules. Use an idempotency mechanism so a retry returns the earlier outcome rather than creating another purchase.

Expiry and revocation solve different timing problems

Expiry is scheduled. Revocation is a change of decision. OAuth token revocation, RFC 7009, specifies a revocation endpoint, but implementations must account for propagation and the relationship between tokens. Do not promise immediate withdrawal across every service without testing it.

Credential status is another layer. W3C Bitstring Status List provides a mechanism for publishing status such as suspension or revocation. A membership credential’s status and an agent’s purchase permission can change independently.

For a purchase that has already completed, withdrawing permission does not itself reverse settlement. Cancellation, refund and dispute handling need their own merchant and payment workflows.

Make the customer’s control understandable

Show active permissions in plain language: the agent, merchant, maximum spend, expiry and whether another purchase is permitted. Let the customer distinguish stopping future actions from requesting cancellation of an existing order.

For operations teams, record when a withdrawal was received and when each service enforced it. Test a request in flight during revocation. This exposes gaps that a successful “revoke” button response can hide.

Apply these controls to an AIR commerce design

The AIR, Minds, Reap and Pivota announcement describes planned payment controls tied to constraints such as merchant, amount and time. Treat this as a proposed partnership flow, not evidence of production behaviour or measured outcomes.

When scoping an AIR Agent integration, agree who enforces each condition and what happens if that component is unavailable. Use the merchant checklist to turn those agreements into acceptance tests.

Frequently asked questions

What is a scoped AI agent permission?

It is approval bounded by explicit conditions, such as a permitted action, merchant, budget, usage count and expiry time.

Should spending limits include delivery and taxes?

The approval should state what the cap includes. For a customer-facing total budget, we recommend checking the complete payable amount before commitment.

What is the difference between expiry and revocation?

Expiry ends authority at a scheduled time. Revocation withdraws authority earlier. Integrations need to define how services learn about and enforce a revocation.

Does revoking an agent cancel an existing payment?

Not by itself. Stopping future authority and reversing an already completed payment are separate workflows.

How can merchants prevent duplicate purchases?

Use a defined idempotency mechanism and track permission consumption. For cumulative budgets, coordinate reservations across simultaneous requests rather than checking each request independently.

About AIR

We build identity, money and loyalty infrastructure for businesses. Explore AIR Agent or discuss your commerce flow with AIR.

Moca Network, the identity network of Animoca Brands.