AI Agent Authorization Glossary
Plain definitions of the terms AgentAdmit works with. Each one answers a real question about giving AI agents scoped, revocable, user-controlled access to the data behind your app.
Self-Describing Credential
A credential that tells the agent where to exchange it, with no preconfiguration.
A connection credential that encodes where it should be exchanged, so an AI agent can determine the exchange endpoint from the credential itself, with no preconfigured knowledge of the application, its APIs, or its authorization infrastructure. This removes the cold-start problem of connecting an agent to an application it has never seen before.
Read the full explainerDiscovery-by-Introspection
One exchange returns the access token plus a scope-filtered, field-level map of what the agent may call.
A connection-level discovery mechanism in which exchanging or introspecting a credential returns not just an access token but scope-filtered operational metadata: the application identity, only the endpoints the agent is authorized to call, and field-level request schemas for each. An agent with read-only scope sees only read endpoints. The agent can construct valid requests directly, without external documentation.
Read the full explainerCaller-Identity Consent
One API, multiple caller classes, each consented to independently by the data owner with no inheritance.
A hosted consent model in which one API surface serves multiple classes of caller and the data owner consents to each class independently, with no class inheriting another’s permission. In a relationship, a client can separately decide whether their trainer may view the client’s data directly, use the app’s in-app AI to review it, or use an external AI agent to review it. The app supplies the relationship and resource context; AgentAdmit stores the switches, computes each verdict, and keeps the trail. Relationship changes can be ceremony-confirmed: the data owner approves the exact change with a passkey on AgentAdmit’s hosted surface, producing verifiable consent evidence.
Verifiable Consent Evidence
A passkey-signed cryptographic commitment to exactly what a user approved, verifiable offline by anyone.
A consent record whose proof does not depend on trusting anyone’s database. During a hosted ceremony, the WebAuthn challenge is derived from a cryptographic commitment to the recorded consent parameters — the scopes, duration, and purpose of a grant, or the exact relationship-consent switches and display labels shown — so the user’s passkey signature covers the decision itself. An auditor can recompute the commitment, match it against the signed ceremony response, and run standard WebAuthn verification with the recorded public key, entirely offline. Biometric data never leaves the user’s device; only the cryptographic proof is recorded. The honest ceiling: it proves a user-verified ceremony signed a commitment to these recorded parameters — never “proof the user read the screen.”
Revocation Boundary
Revocation takes effect at the next /verify call; a call already past verification completes, and a pending confirmation not yet consumed is no longer consumable.
The exact point at which revoking a token or connection takes effect. A revocation (either an individual access token revocation or a full connection revocation) is applied the next time the agent calls /verify. A call that has already passed the verification step completes normally; the revocation does not reach back into in-flight execution. A pending confirm-each-time confirmation that has not yet been consumed at the moment of revocation is permanently non-consumable: no retry with that attestation id will succeed. The individual token's revoked flag and the connection-status check both run before confirmation consumption in the verify path, so either revocation path carries the same guarantee.
See the app owner guideConfirm Each Time
A scope that needs a fresh, user-verified passkey confirmation for every call, even inside a valid grant.
An exercise-time control for high-risk actions. The app owner marks a scope confirm_each_time at registration (per-connection tightening by the user is stored today and gets a user surface in a later release), and a valid grant is no longer enough on its own: when an agent exercises that scope, verification refuses the call with confirmation_required and stages a hosted action session bound to exactly that action (connection, scope, method, endpoint, request digest, and the app’s plain-language summary). The agent relays the link; the human confirms with a user-verified passkey whose challenge is a cryptographic commitment to that action; the agent retries with the single-use attestation id and the call proceeds. The grant does not change, the agent cannot complete the ceremony itself, and each confirmation covers one call.
See the app owner guideThe authorization layer for AI agents
Scoped, revocable, user-controlled access for the agents calling your APIs.
See how it works