Delegation and consent

An agent acts for a user only within the authority the user gives it. Today, that authority is the set of scopes on the agent’s key. Delegation credentials, which are not yet released, would add finer-grained, per-task grants.

​

What the Agent APIs enforce today

These controls limit what an agent can request from AIR. They don’t express a per-merchant, per-claim, or per-action grant, and they don’t replace the receiving application’s own checks.

​

Ask for consent before binding

The bind request has no user-facing approval step. Your application owns consent, so before you bind an agent:

1. Show the user which agent they are connecting, using the nickname you will bind it with.
2. Explain each scope in plain language:

   Scope	Tell the user the agent can
   credentials.read	See which credentials they hold, such as issuer and credential type.
   credentials.verify	Check their credentials against a verification program and share the result, including any claims the program discloses.
   commerce.checkout	Start a checkout with a supported merchant, which receives their AIR Account address.

3. Bind only the scopes the user approved, and keep a record of the approval.

Ask again before adding scopes. A key’s scopes are fixed at bind time, so bind a new key for the wider set and revoke the old one.

​

Let users see and disconnect agents

Give users a place in your product to review and remove connected agents:

• List the agents your partner bound for the user with List bound agents.
• When the user disconnects an agent, call Revoke an agent key.
• Revocation is documented as stopping new sessions. To also end sessions already issued, rotate the key before you revoke it.

AIR Kit also has agent key calls that run in the user’s own session (getAgentKeys, registerAgentKey, removeAgentKey). See the Web SDK reference. Removing access does not undo completed purchases or recall claims already disclosed.

​

Disclosure and purchase authority

Permission to show a loyalty tier lets an agent get a member quote. Placing an order and paying need separate permission. With the Agent APIs, that means binding commerce.checkout only when the user wants the agent to start purchases. For each integration, define the claims an agent may present, the applications that may receive them, and the actions it may take. When the task changes, get the additional approval. For example, an agent allowed to compare hotel prices should ask again before it books a non-refundable room.

​

Proof, disclosure, and context

Request only what the task needs. Proving one attribute does not grant access to the user’s whole profile.

​

Delegation credentials

Not yet released. A delegation credential would record a user’s authorization for a specific agent and task, linking the agent to the user’s AIR Account. The receiving application would check it alongside the user’s claims. A grant could cover: These are illustrative terms, not API fields. Expiry would end a grant at a set time, and revocation would withdraw it earlier. How quickly revocation takes effect, and what happens to requests already in progress, will be defined with the release.

​

Spending limits

A spending limit only works if the payment or wallet integration enforces it. The Agent APIs don’t set spending caps. Decide whether a cap applies per purchase, per session, or over a period, and how concurrent requests count against it. Enforce the cap wherever money moves. A limit in one payment path doesn’t protect a different path the agent can reach.

​

Match authority to the task

• One task: get the evidence for a single interaction, and let the authority end with it.
• One session: keep the approved scope across a multi-step shopping or booking flow.
• An ongoing relationship: define renewal, expiry, withdrawal, and approval for repeated actions.

An agent remembering a conversation or preference does not extend its authority. Scheduled purchases and standing spending mandates are not supported. Portable user context, such as preferences carried in credentials, needs its own schema and access model for each integration. AIR does not provide a general-purpose memory-sharing service.