Skip to main content
Current scope: The Agent APIs support agent identity binding, short-lived sessions, and credential lookup and verification. Wallet delegation for Web3 use cases is planned. Fine-grained delegation credentials and user-bound proof handoff are not yet released. Existing merchant checkout tokens provide an identity handoff, rather than wallet signing authority. Contact the AIR team to confirm environment access.
An application deciding on an agent’s request needs three things:
  • Who the agent is?
  • What the user has allowed it to do?
  • Verified claims behind the request.

​
The building blocks

The binding shows whom the agent represents. Its scopes limit what the agent can do through AIR. A credential such as a membership supplies the evidence for a benefit decision.

​
The interaction

1

The user approves the agent

The user approves identity access for a specific agent, normally through the AIR app. Its link is coming soon. For a partner-managed in-app journey, your application shows which agent is being connected and which scopes it requests. The bind request has no approval screen of its own. See Plan your integration.
2

Bind the agent

The approved connection links the agent identity to the user’s AIR Account. In the partner-managed route, your backend binds it while the user has an AIR Kit session. Request only approved scopes, such as credentials.read and credentials.verify. See Using Agentic Identity.
3

Request the required evidence

The receiving application decides which claims and issuers it accepts, and sets them in a verification program. For a member price, it might check a loyalty tier. For an eligibility check, it might check that a condition is met.
4

Verify

Your backend creates a 15-minute agent session and runs the program against the user’s credentials. The result is Compliant, Non-Compliant, or NotFound, with a verifiable presentation when compliant.
5

Apply the result

The application returns the benefit or service the user qualifies for, asks for more approval, or declines the request. A purchase then follows its own checkout and payment steps. For a supported merchant, the agent can mint a checkout token scoped to that merchant.
Not yet released: with delegation credentials, the user would also grant per-task authority, such as a specific merchant, claim, and duration, and verification would check that authority alongside the user’s claims.

​
Verification through the Agent APIs

Agents reach credential verification through the Agent APIs, REST endpoints your backend calls. With an agent session, your backend lists the user’s credentials and runs a verification program in a single call. See the Using Agentic Identity. If the user doesn’t hold the required credential, the result is NotFound. Verification never issues the missing credential itself. Issuing credentials is a separate integration owned by the issuer. See Issuing credentials.

​
What a verification result proves

Agent verification runs offchain, and status tells your backend the outcome. A Compliant result includes an SD-JWT presentation: the issuer-signed JWT plus the disclosures the program requested. If you send a nonce and the credential was issued with cnf.jwk, it also includes a key-binding JWT tied to your challenge. A third party, such as a merchant, can check that presentation itself: the issuer signature, the disclosures, and the key-binding JWT when present. See Verify SD-JWT on your backend. The status field is not signed, so a recipient that receives only the status has to trust your backend’s report. The checkout token identifies the user and their AIR Account address. To share a verification result with a merchant, agree the format and how the merchant checks it.
Programs that use Iden3 credentials (Advanced) return a different presentation. See the endpoint reference.

​
What the receiving application checks

A verified claim does not authorize every action. A verified loyalty tier can support a price decision, but placing an order or spending money needs separate authority. With the Agent APIs today, the application relies on:
  • The result of the verification program it accepts.
  • The agent key’s scopes, which limit what the agent can request from AIR.
  • For checkout, a token whose audience is the merchant, which the merchant must verify.
Not yet released: with delegation credentials, the application would also check that the requester is the delegated agent, that the grant covers this application and action, that it hasn’t expired or been revoked, and that the evidence is bound to this interaction.

​
What information is shared

The verification program sets which claims are requested and how. A program can return an eligibility result or approved claims; the result is not always a single yes-or-no value. AIR Credentials are encrypted before storage, and issuers keep their source data. Anyone who receives disclosed claims must handle them appropriately. See How AIR Credentials work.