> ## Documentation Index
> Fetch the complete documentation index at: https://docs.air3.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Identity and agent binding

> Follow a user from approving an agent to the agent presenting verified claims and the receiving application making a decision.

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

| Element | What it establishes |
| - | - |
| AIR Account | The user's identity and the credentials they hold. |
| Agent identity | The agent performing the action. On its own, it does not show which user the agent represents. |
| Agent binding | The link between the user's AIR Account and the agent. With the Agent APIs, this is an agent key bound to the user with a set of scopes. |
| Delegation credential | **Not yet released.** A credential recording the authority the user grants the agent, with finer-grained scope and conditions. |
| User credential | An issuer-signed claim about the user, such as membership or eligibility. |
| Verification | Whether the user's credentials satisfy the receiving application's verification program. |

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

<Steps>
  <Step title="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](/products/agents/integration-options#choose-the-delegation-journey).
  </Step>

  <Step title="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](/products/agents/partner-agent-api).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

**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](/products/agents/partner-agent-api).

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](/products/identity/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](/products/identity/verify-sd-jwt). 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.

<Note>
  Programs that use [Iden3 credentials](/products/identity/iden3-credentials) (Advanced) return a different presentation. See the [endpoint reference](/api-reference/agents/verify-credential-by-agent).
</Note>

## 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](/products/identity/credentials-flow).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.