AI agent identity vs authorisation: who can act, and on what terms?

Updated 26 October 2026.

AI agent identity establishes which agent is involved. Authorisation determines what that agent may do. Delegation connects the agent’s action to a person or organisation that granted authority. These checks work together, but passing one does not imply that the others have passed.

For a merchant, the difference becomes concrete when an agent asks to place an order. The merchant needs evidence about the requester, the customer’s approval and the exact transaction. It may also need evidence that the customer qualifies for a requested benefit.

What question does each check answer?

• Identity: which agent or service is this?
• Authentication: can the requester demonstrate control of the identity or credentials it presents?
• Delegation: who gave the agent authority to act on their behalf?
• Authorisation: does that authority permit the specific action now?
• Eligibility: is the represented customer entitled to this offer?
• Payment approval: will the payment provider approve this payment under its own checks?

These are decision boundaries, not necessarily six separate products. One service can perform several checks, provided its evidence and outcomes remain clear.

Why an agent badge is not enough

Suppose a merchant recognises a shopping service and authenticates its request. That establishes something about the software calling the merchant. It does not establish that a particular customer approved a new order, or that the service may access every part of the customer’s account.

Similarly, a customer’s login session may establish access to their account without granting an agent permission to spend. The integration needs an explicit connection between the customer’s approval, the agent and the permitted action. Record that connection in enforceable data, rather than relying on a conversation transcript as the only control.

How delegation differs from impersonation

RFC 8693 distinguishes delegation from impersonation and defines actor information for token exchange. That distinction matters operationally: a service acting on a customer’s behalf can remain identifiable as the actor, instead of every action appearing to come directly from the customer.

Our recommendation is to preserve both roles in transaction records where the chosen protocol supports them. If a refund request arrives later, support should be able to identify the customer, the agent service and the authority used for the purchase. Avoid recording full credentials when references and decision results are sufficient.

A worked example: permission changes with the basket

In this illustrative flow, a customer approves one desk lamp from Merchant B for up to HK$800, including delivery. The agent finds the lamp, then discovers a bundle with an extra bulb for HK$790.

The lower price does not settle the permission question. If the customer approved that exact lamp only, a different bundle may fall outside the allowed basket. If approval explicitly allowed equivalent bundles within the price cap, the purchase may fit. The merchant’s decision must follow the actual approval, not infer consent from a favourable price.

A useful permission record therefore states the action, eligible goods or exact basket, merchant, total amount, currency, expiry and any rules for substitutions. The receiving system evaluates these conditions before committing the order.

What payment mandates establish

The current Agent Payments Protocol specification, AP2 v0.2, separates Checkout Mandates from linked Payment Mandates. The former concern the purchase being authorised; the latter concern payment. The specification assigns verification responsibilities to the parties involved.

This is useful transaction evidence. Whether a customer deserves a loyalty discount remains a merchant policy question. A commerce integration should make the discounted price part of the authorised transaction and retain the separate basis for eligibility.

How AIR connects customer identity and agent authority

AIR is identity infrastructure built by Moca Network. AIR Identity supports reusable customer credentials; AIR Agent is designed to apply the customer identity and permission model to agent interactions. For a merchant, the relevant question is whether the represented customer qualifies for the offer and has authorised the requested action.

The AIR credential architecture documents issuance, user consent and verification. It provides technical evidence for the customer-credential part of a commerce design. Credential verification alone does not demonstrate that an agent may spend, that the merchant enforces a limit, or that a payment has been approved.

For a proposed deployment, assign an owner to agent authentication, the customer-to-agent link, action authorisation, eligibility and payment approval. Confirm supported interfaces, availability and enforcement responsibilities with each provider. AIR’s public product pages describe the intended roles; they do not, by themselves, establish that every combination of these controls is available in production. Product and documentation sources reviewed 26 October 2026.

How to turn the distinction into acceptance tests

Use separate test outcomes. A known agent with no customer approval should fail the authority check. A permitted agent with an expired membership should fail the benefit check. A valid order with a declined payment should remain unpaid. This gives product, engineering and support teams a shared explanation of each result.

Our agent permissions guide explains concrete limits and revocation. For the broader framework, read Know Your Agent.

Frequently asked questions

What is the difference between agent identity and authorisation?

Identity identifies the agent. Authorisation evaluates whether it may perform a particular action under the applicable permissions and conditions.

What does delegation mean for an AI agent?

Delegation means a person or organisation grants an agent authority to act on their behalf. The integration needs evidence of that relationship and the limits attached to it.

Can login consent also authorise a purchase?

Only if the approval and integration explicitly cover the purchase. Account access alone should not be assumed to grant spending authority.

Does a payment mandate establish loyalty eligibility?

It can provide evidence of transaction approval. Eligibility for a loyalty offer still depends on the merchant’s benefit rules and the evidence it accepts.

How do AIR Identity and AIR Agent fit together?

AIR Identity supports reusable customer credentials. AIR Agent is designed to apply the customer identity and permission model to agent interactions. A merchant still needs evidence of the customer’s authority for the action, eligibility for the offer and separate payment approval. Confirm supported interfaces and availability for the intended integration.

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.