What is GenAuth
GenAuth is an Agent Identity platform: it gives every AI agent in your company a first-class identity, and lets people delegate permissions to it explicitly, narrowly, and revocably.
It does not replace your existing identity system. People and their permissions still live in your Human Identity stack (a self-built IdP, a commercial IAM, or any standard OIDC provider). What GenAuth adds is the layer missing above it: safely lending an agent the permissions a person already has, for a little while.
First, one clarification: GenAuth and Qoni
GenAuth is the identity layer of Qoni. Qoni is a set of agent infrastructure that, beyond identity, also covers memory (GUMem) and action (Web Agent) — all three share one SDK, one console, and one set of access keys.
So the SDK uses Anima naming, while domains and endpoints keep the legacy identifier eak — GenAuth's capabilities hang under this unified entry point:
| What you'll see | What it is |
|---|---|
npm install @eazo/anima | The unified Qoni SDK — every code sample in these docs uses it |
dashboard.qoni.ai | The Qoni console, where workspaces and access keys are managed |
anima.delegateToken(...) / anima.genauth.* | GenAuth's delegation and identity capabilities |
/api/v3/eak/... | The HTTP endpoint prefix |
When you see eak in a domain or endpoint, don't second-guess it — it's Qoni's street address.
Permissions always originate with a person
This is the first principle of the whole site, and the starting point of every design decision in GenAuth:
An agent has its own first-class identity — registrable, approvable, owned, and disableable. But every bit of power it exercises is explicitly ceded by a person out of the Human Identity system: narrowable (attenuation), auditable, short-lived by default, and recallable (layered controls and their timings are in Revocation and emergency response).
The "person" shows up in two ways. Both count as explicit authorization, and these docs dodge neither:
| How the person shows up | Who is consenting | Typical scenario |
|---|---|---|
| User-level consent | The end user clicks approve on the consent page in person | An employee lets an agent fetch data for them; a consumer authorizes an agent to check an order |
| Organization-level consent | An org admin consents in advance on the organization's behalf, and a trusted server-side integration initiates the delegation | Batch jobs, scheduled tasks, first-party apps that already have a mature login system |
Both are auditable and both can be withdrawn. The only difference is who spoke for the person — details and boundaries are in Consent and approval.
Capabilities: four answers to four questions
GenAuth's capability list isn't a pile of features. It answers, one by one, the four questions from the previous page. Every capability maps to a question you have to be able to answer — and the ones you can't answer are your gap.
The last column is current release status: Available means use it today; Beta means usable but the interface may still shift; Roadmap means the design is settled but it hasn't shipped. We don't write plans as if they were facts.
| The question you need to answer | Capability | What it actually is | Status |
|---|---|---|---|
| How many agents do I have, and who is responsible for each? | Registration and governance | Agent registry, templates and agents, registration approval, Owner and Sponsor, lifecycle and kill switch (Agent identity model, Register and manage your agents) | Roadmap |
| Whose identity is it acting under right now, on whose authorization? | Explicit delegation | Consent (user-level and organization-level), Delegate Token issuance, token exchange (Delegate Token and attenuation, Quickstart) | Beta |
| What can it access, and what can't it? | Access control | Minimal scope, attenuation that only subtracts, resource-side sub / act / scope intersection checks (Three access patterns, Protect your APIs) | Beta (resource-side integration: Roadmap) |
| How do I pull permissions and trace accountability after an incident? | Revocation and audit | Layered permission pull-back, full-chain traceability via audit_id (Revocation and emergency response, Audit and accountability chain) | Beta |
| What if the agent needs a user's third-party account? | Credential custody and token dispatch | Raw credentials never leave custody; the agent only ever holds a short-lived token (Token Dispatcher, Access third-party services) | Roadmap |
| How does this connect to my existing identity system? | Human Identity integration | OIDC identity federation, permission reads, scope mapping; MCP Server authorization (Integration principles, Integrate your existing identity provider) | Beta (some providers: Roadmap) |
On "how fast can I take it back"
This is the question security review asks first, so here's the answer straight: stopping new issuance is instant (disable the access key); a token already in the agent's hands cannot be invalidated individually, so its validity window governs — which is why task-level delegations should be given lifetimes measured in minutes. The full four layers and their respective timings are in Revocation and emergency response.
How it relates to your existing Human Identity system
In one line: Human Identity is the source of permissions, Agent Identity is the instrument of delegation.
GenAuth connects to Human Identity systems through one uniform provider interface — identity federation answers "who the user is," permission reads answer "what the user can do," and together they set the upper bound of any delegation. Implemented and planned providers are listed in Integration principles; the onboarding path is in Integrate your existing identity provider.
Deployment models and trust boundaries
GenAuth governs delegation issuance and also holds third-party credentials in custody — it is a high-value component in your architecture, so the boundaries have to be explicit:
- Two models: a managed service, or a component deployed into your own Kubernetes environment (same domain as your existing identity system).
- In the self-hosted model, delegation data, audit logs, and credentials in custody all stay inside your environment and never leave your domain.
- Access keys are the thing to protect hardest: whoever holds one can initiate delegations on the organization's behalf. Storage requirements are in Security considerations.
The data boundary matrix, service-to-service authentication, and air-gapped offline mode are in Deployment models; the four-party trust relationships are in System overview and trust boundaries.
Next steps
- The full journey of one delegation — 8 moments that string all of the above into one line.
- Your first delegation in 30 minutes — hands on keyboard.
- System overview and trust boundaries — the architect's view.