Glossary and migration
This page is the canonical source for terminology across the GenAuth Agent Identity documentation. When a concept appears under more than one name anywhere, this page wins. Each term gets a one-sentence definition and a link to the page where it formally debuts — to go deeper on a concept, follow its "first appears" link.
Glossary
Identity and accountability
| Canonical term | One-sentence definition | First appears |
|---|---|---|
| Agent Identity | A first-class identity system for AI agents as a new kind of actor — making every agent identifiable, authorizable, accountable and revocable. | What is Agent Identity |
| GenAuth | The Agent Identity platform: gives every AI agent in your enterprise a first-class identity, and lets people delegate authority to it explicitly and revocably. | What GenAuth is |
| Human IAM | A generic term for your existing human identity and permission system — the source of every authority that can be delegated. | What GenAuth is |
| Agent template | A reusable definition of a class of agents: default permissions, configuration and accountability requirements. | The agent identity model |
| Agent (instance) | The running entity created from a template that actually holds credentials and performs tasks. | The agent identity model |
| Owner | The person fully accountable for an agent's development, configuration and credential rotation. | The agent identity model |
| Sponsor | The person who answers "whose books does this agent belong to"; sponsorship transfers automatically on personnel change, so no agent is ever ownerless. | The agent identity model |
Delegation and authorization
| Canonical term | One-sentence definition | First appears |
|---|---|---|
| delegation | A person granting part of their own authority to an agent explicitly, with an expiry, and revocably. | What GenAuth is |
| on behalf of | The state in which an agent acts in the name of a specific user — the token and audit trail always keep "who delegated this". | The full journey of one delegation |
| consent | The act of a human approving before authority is released, at two levels: user-level (the end user approves personally) and organization-level (an administrator approves in advance on the organization's behalf). | Consent and approval |
| grant | The authorization record produced by one consent; its grant_id spans issuance, exchange and audit end to end. | Consent and approval |
| attenuation | The principle that authority can only narrow, never widen, along a delegation chain (the term used in the IETF attenuating-tokens draft). | Delegate Token and attenuation |
| scope intersection | Effective authority = requested scope ∩ the delegator's real permissions ∩ what organization policy allows — the smallest of the three. | Delegate Token and attenuation |
| scope | The smallest unit of authorization, shaped service.capability:action (for example webagent.web_search:manage). | Delegate Token and attenuation |
| async authorization | A human-in-the-loop flow: when an agent attempts a sensitive operation, the accountable person is notified out of band and the operation proceeds only after approval. | When a human must approve: async authorization |
Tokens and credentials
| Canonical term | One-sentence definition | First appears |
|---|---|---|
| Delegate Token | The authorization record for one delegation: delegator, agent, scope and lifetime. It is exchanged at GenAuth and never used to reach a resource directly. | Delegate Token and attenuation |
| Token Exchange | Exchanging a delegate token for a short-lived access token bound to a target resource, per RFC 8693. | Delegate Token and attenuation |
| access token | The post-exchange token actually used against a resource, carrying aud resource binding and the act actor claim. | Delegate Token and attenuation |
| Token Dispatcher | Custody for credentials, dispatch for tokens: a user's third-party credentials stay in custody and never leave, and an agent can only request short-lived, attenuated, recallable access tokens against a delegate token. | Token Dispatcher |
| access key (AK/SK) | The tenant-level credential between your server and GenAuth, used for server-side calls such as starting a delegation; leaking it is an organization-level risk. | First delegation |
| introspection | The mechanism an integrator or resource server uses to verify a token's validity and contents online. | API reference |
Governance and audit
| Canonical term | One-sentence definition | First appears |
|---|---|---|
| kill switch | The emergency control that cuts off one agent's — or a batch of grants' — ability to reach resources. | Revocation and incident response |
| audit chain | The audit record that spans delegation, exchange and access, tracing every action back to "which agent, on whose behalf, under which grant". | Audit and accountability chain |
| audit_id | The audit identifier for one delegation end to end — the same audit_id travels from issuance through exchange to resource access. | Audit and accountability chain |
| grant_id | The unique identifier of one grant record; the anchor for revocation and audit. | Consent and approval |
Writing discipline
Introduce each term with its definition on first use, then stay with the canonical form. One concept, one name: never write Delegated Token, Delegation Token or "sub-token". To change a canonical term, change this page first and every referencing page second.
Migration
GenAuth's terminology went through one round of consolidation. If you have read early material or used an early SDK, use the two tables below.
Old terminology
| Old term | Canonical term today | Why it was retired |
|---|---|---|
| Sub-Agent Token | Delegate Token | Ambiguous — it reads as "a sub-agent's token" — and it conflicts across the board with the current SDK and server contract (delegateToken). |
| Delegated Token / sub-token | Delegate Token | Aliases from the Sub-Agent Token era; retired with the main term. |
| Agent OAuth / Agent-first Identity | Agent Identity | Two early names (protocol-side and product-side) merged into one, removing cross-page confusion. |
| Human → Agent Mapping | delegation | Adopts the industry-standard word and anchors to RFC 8693 delegation semantics. |
SDK contract migration
The migrations below were checked against the current @qoniai/qoni v0.4.1 package. The left side shows early @eazo/anima usage. Compatibility aliases still compile today, but new code should use only the right side.
1. delegateAgent() → delegateToken() (method renamed, arguments unchanged):
- const { data } = await anima.delegateAgent({ agent: "report-agent", ... });
+ const { data } = await qoni.delegateToken({ agent: "report-agent", ... });2. Top-level userId → user: { id } (argument restructured):
- await anima.delegateToken({ agent: "report-agent", userId: "usr_demo_0001", ... });
+ await qoni.delegateToken({ mode: "silent", agent: "report-agent", user: { id: "usr_demo_0001" }, ... });3. accessKeyId → accessKey (initialization field renamed):
- const anima = new Qoni({ host, accessKeyId: process.env.ANIMA_ACCESS_KEY!, secretKey });
+ const qoni = new Qoni({ host, accessKey: process.env.QONI_ACCESS_KEY!, secretKey });A two-track compatibility window
The SDK has deprecated the top-level userId, but the server still accepts the old parameter during the compatibility window. This is not merely a style issue — the old form carries a surface that can be misused as a confused-deputy entry point, so migrate sooner rather than later. Risk analysis and defenses: Security considerations.
Next steps
- What is Agent Identity — why this vocabulary exists, from first principles
- First delegation in 30 minutes — write your first line against the current contract
- SDK reference — every method signature and deprecation detail