Identify the agent and its owner
Classify the actual deployment rather than inferring ownership from its name. A personal assistant can run on a provider’s servers; an embedded agent still needs each customer’s approval before using their identity.
The agent’s operator and the user it represents can be different people or organizations. Record both roles and identify the agent key or instance to which access is granted.
Map consent and verification
Use one concrete journey to answer these questions:
A user preference or a statement in chat is context, not automatically an issuer-verified fact. If the journey needs a credential the user does not hold, define an issuance flow; verification does not create missing evidence.
Choose the delegation journey
User-managed delegation
The standard journey is for the user to approve the chosen agent through the AIR app. Your product should make clear which agent is being connected and why it needs identity access. AIR app link: coming soon.Delegation within your application
For a more integrated experience, contact the AIR team about enabling delegation within your own app. Your application collects the user’s explicit approval and uses the supported partner binding flow. The bind request itself does not display an approval screen. Choose this route when your product can identify the user, explain the access clearly, and manage the connected agent on their behalf. See Delegation and consent. The current Agent APIs bind scopes such ascredentials.read and credentials.verify. Your application must also enforce any narrower task rules it promises; those scopes do not encode a per-merchant or per-claim grant.
Who holds the agent key?
For a partner-operated agent, the backend can hold the API key returned by the binding flow. For an agent that controls its own P-256 key pair, the supported API route can bind its public key and authenticate sessions using signed messages. Choose the key model that fits the operator identified above; neither model removes the user’s consent requirement. See Use a public key instead of an API key.Choose the verification method
- Agent API verification: the agent’s backend creates an authenticated session and runs the agreed verification program for the user’s credentials. Follow Using Agentic Identity.
- Presentation verification by the receiving service: agree the format and trust model, then have the recipient check issuer signatures and the required claims. For SD-JWT, use the existing Verify with SD-JWT guide.
Compliant status alone is not a signed proof for an unrelated third party. See What a verification result proves.
Agree how the handoff authenticates the agent-user relationship and records consent. Checking a credential’s issuer signature establishes that claim; the recipient still needs the agreed evidence of who is presenting it and under what authority.
Example: a member discount
A user asks a personal assistant to find a product. The merchant wants to check a membership tier from an issuer it accepts. The user approves identity access for that assistant, its backend runs the agreed program, and the merchant checks the supplied evidence before returning a member price. The identity flow establishes eligibility for the discount. Ordering and payment follow their own approvals.Not yet available
Wallet delegation for Web3 use cases is planned. The current identity binding does not grantwallet.sign, a spending mandate, or automatic access to the user’s assets. Fine-grained delegation credentials and user-bound proof handoff are also not yet released.
Once the roles, evidence, and consent journey are clear, follow Using Agentic Identity. Talk to the AIR team if you need help scoping the flow.