Authority delegated by a human: narrowing-only, short-lived, revocable at any time, audited end to end.

Agents are the new actors in the enterprise, and the identity stack has no seat for them

Identity technology has been at this for three-plus decades. Compress those decades into one sentence, and they keep answering a single question, over and over: this new kind of subject — why should anyone trust it? And every time that question gets a good answer, the world gains a layer of productivity.

In the LAN era, the question was "who is the person at this machine?" Directory services like AD (accessed over protocols like LDAP) registered every member of an organization, and Kerberos used tickets to prove who they were to each service on the intranet — and directories plus tickets carried the enterprise intranet. In the web era, the question became "why should this app act on the user's behalf?" SAML carried identity federation and single sign-on beyond the intranet; OAuth took on authorization and left authentication out of its scope, and OAuth 2.0 made it the common authorization framework of the entire web (an app can act for a person without surrendering their password) — together they carried SaaS and the open platforms. In the mobile-and-cloud era, the question was "one person, across countless apps and devices": OIDC added a standardized authentication layer on top of OAuth 2.0, "Sign in with ..." became the default front door of the internet — and it carried the mobile internet.

Three-plus decades, generation after generation of protocols — and all sharing one assumption buried so deep almost nobody calls it an assumption: the subject is always a human. The directory holds people, the tickets go to people, the grants come from people, the one signing in is a person; even the newest decentralized-identity (DID) experiments still, in mainstream practice, issue credentials to people.

Now, for the first time, that assumption is breaking. The AI agent is the new actor inside companies: it queries data, files requests, calls internal systems — work that used to belong exclusively to employees. It isn't a user and isn't an app — it's a third kind of digital subject. And it doesn't grow into the human shape: an agent decides its next step at runtime, based on the context and on what the last tool returned; before a task starts, nobody can fully write down its execution path. Statically pre-granting such a subject a fixed bundle of long-lived permissions will never be enough.

Academia has already named the gap. Researchers distill the attribution layer of agent infrastructure into three propositions (Infrastructure for AI Agents, 2025, arXiv:2501.10114): Agent IDs — who is this agent; identity binding — which person or organization stands behind it; certification — can its behavior and properties be trusted. The same paper runs through the alternatives already at hand: OAuth tokens and API keys can help with attribution, but they are typically each bound within a single service — they cannot link one agent's activity across services, let alone trace a sub-agent back to whoever created it; IP addresses are unstable and can be shared; even the newest agent-to-agent protocol (A2A) speaks mainly to what an agent can do — its AgentCard centers on capability discovery, while who stands behind it, and why it should be trusted, is left hanging. Meanwhile, the agent-authorization drafts under discussion at the IETF treat attenuation — authority that can only narrow as it travels down a chain — as a core requirement. The direction is clear: agents need an identity layer of their own.

The reality, though, is that most agents today act on borrowed identity: an employee's API key, a shared service account. The moment an agent heads for production, security asks three questions. When something goes wrong, can anyone tell whether a person did it or an agent? It only needed to do one thing — why does it hold a person's entire permission set? And can anyone answer "what allowed this call"? GenAuth is Qoni's identity layer, and its answer fits in one sentence: give every agent a passport of its own. The agent holds no permissions of its own; every capability it exercises comes from an explicit grant made by a specific person, revocable at any time.

A passport unpacks into three things: identity, attribution, delegation

Unpack the passport and it is three things:

• Agent ID: an independent identity. Every agent gets dedicated credentials with a full lifecycle — create, rotate, disable, delete. Enabling or retiring an agent's identity depends on no employee account: people come and go; the agent's identity persists and retires on its own.
• Identity binding: attribution to a person. Every agent is bound to the person and organization behind it, and every action traces back to whoever delegated it. When something goes wrong, it's no longer an unsolved case.
• A delegation chain, built on the standards. No new protocol invented — delegation semantics for agents extended along the existing rails of OAuth 2.0 / OIDC: short-lived credentials whose scope only ever narrows, never widens. The existing identity infrastructure stays.

An agent's capabilities come half from its tools, so MCP tool calls fall under the same identity, policy, and audit governance: which tool, in whose name, within what scope — all on the record. And all of it is one SDK away.

The attribution layer's three propositions now have an engineering answer: Agent IDs and identity binding are answered by the passport itself, and certification gets its rails from verifiable grant boundaries and end-to-end audit. The model's first-principles constraint fits in one sentence: an agent owns an identity, but owns no inherent permissions — no root authority. From it follow four core principles: predictable, governable, revocable, traceable.

GenAuth's permission model: three sets, one intersection

An agent's effective permissions = what the human actually holds ∩ what was explicitly delegated ∩ what the enterprise has approved

Three sets, one intersection: authority can only narrow as it travels down the chain, never widen (authorization-system design calls this property attenuation). However capable the model, by construction it cannot out-rank the human who delegated it.

Every permission is scoped and time-boxed: it expires after an hour by default, can be as short as a minute, and evaporates when the task ends. An agent with no task in hand holds no standing business authority — security engineering calls this state zero standing privileges. The narrow-only design builds the decades-old principle of least privilege into the runtime: the closer a subject's permissions track what it actually needs right now, the more predictable its behavior — and the easier it is to spot a deviation and revoke the grant behind it.

GenAuth's two tokens and Token Exchange (RFC 8693)

At the protocol layer, that formula becomes a split between authorization and action — two kinds of tokens:

• The delegate token can exchange, but can't open doors. When a user approves a delegation, the agent receives a delegate token whose audience points permanently at GenAuth's exchange service (fixed to genauth:token-exchange), never at any business resource. To reach a resource, the agent must perform an RFC 8693 Token Exchange (grant type urn:ietf:params:oauth:grant-type:token-exchange) and trade it for a short-lived access token valid for exactly one resource — a standard JWT that mainstream gateways verify with their stock JWT / OIDC plugins. Every exchange is a live adjudication: is the grant still valid, is the scope in bounds, has the credential been disabled — all re-checked at that moment, instead of issuing one long-lived ticket and waving everything through.
• Scope attenuation has two gates, plus an allowlist. The scopes requested at exchange must fall simultaneously inside what this delegation granted and what the target resource has registered — crossing either line means rejection — and the exchangeable range is governed by a server-side allowlist. Success and rejection are two distinct audit events (token_exchange.success / token_exchange.rejected): even the scopes that didn't make it are on the record.
• act is minted only at exchange time. RFC 8693 uses the act (actor) claim to say "who is acting on whose behalf." The delegate token deliberately doesn't carry it: at authorization time, no action has happened yet. And act here is an extended structure with a type discriminator — the docs say plainly that a stock RFC 8693 library will silently fail to parse it, so the resource side must explicitly check the delegation type, and fail closed.
• Time-to-live is a first-class citizen. Delegate tokens live from 60 seconds to 24 hours, one hour by default, with 5 to 15 minutes recommended for single-task delegations; the interactive-authorization window and the approval session each run 10 minutes. Expiry isn't an exception — it's the norm.
• Audit is a dual-ID chain, minted into the token. Every delegation mints a grant_id (which authorization) and an audit_id (what happened under it), both embedded in the token itself and traveling wherever it goes: even an attacker holding a stolen token cannot book their actions under someone else's grant.
• The default posture is fail-closed. If the policy service is unreachable, the request is denied. However hard the model hallucinates, it does not cross that line.

Consent inherits the OAuth authorization-code discipline: a one-time callback code, stored only as a hash, consumed inside a database transaction, with a state machine guaranteeing each code is used exactly once.

A typical day in production: an employee asks the internal data assistant, "pull last quarter's sales for the east region." The agent initiates a delegation under its own passport; the employee confirms; the agent exchanges it for an access token scoped to read-only access on the reporting system, valid for fifteen minutes; the gateway checks it and the query runs. Midway, the agent reaches for a customer-privacy field it wasn't granted? That request is rejected at the gateway — and logged. Afterwards, the security team sees one unbroken chain: who authorized, which agent, what it did, when, on what authority — including the overreach that never went through.

GenAuth's four-layer permission model: tighten a policy, no code change

Tokens answer "is this credential trustworthy?" The other half of the problem: should this particular request go through? GenAuth follows the classic separation in access control: the policy decision point (PDP) is centralized — rules are managed in one place, GenAuth; the policy enforcement point (PEP) is pushed down — traffic is stopped at the gateway edge or inside the business service.

On the decision side sits a four-layer model: roles (RBAC) answer who, policy conditions answer under what circumstances, resource namespaces answer which class of resource, data permissions answer down to which row. Policy conditions evaluate five operator families — boolean, date, IP, numeric, string — so constraints like "business hours only," "office network only," "within quota only" are expressed as configuration, not code. The operational payoff is immediate: tightening a policy means changing no business code and waiting for no release train — adjust it in the console, and newly issued tokens carry the new scope at once (with one exception: if enforcement lives at the gateway, the gateway plugin configuration still needs a separate update).

This split also answers a very practical objection — approval fatigue. Agents move far faster than people; if every step popped a confirmation dialog, "confirm" would decay into a mindless click within days. GenAuth divides the labor: what a human approves is one scoped, time-boxed delegation, not each individual action; every exchange and access inside it is adjudicated by machine against policy in real time, and anything out of bounds is simply rejected. Humans make few, weighty decisions; machines make many, fast ones.

GenAuth's revocation and audit: effect boundaries and the five questions

"Revocable at any time" is a sentence every identity vendor writes. The engineering question that matters is the next one: revoked — effective when? GenAuth puts both boundaries in plain sight:

• Paths validated through introspection or token exchange fail immediately after revocation, because every check goes back to the issuer and reads the delegation's live status;
• Paths that only verify JWT signatures locally have a hard upper bound: the token's own short TTL. The token cannot outlive its next expiry.

This is also the deeper reason for short lifetimes: when a credential leaks, the blast radius is set by the token's lifespan. In the worst case, three lines of defense remain: dedicated credentials can be disabled and rotated instantly; the credentials themselves carry zero business permissions — actual access rides on short-lived, revocable delegations and access tokens; and enforcement-side checks keep running throughout.

The five audit questions — who, authorized whom, to do what, when, on what authority — draw their answers from two sources that vouch for each other. The authorization side is recorded by GenAuth: delegation approvals (with approver and approval time), exchange successes and rejections, issuance, revocation, policy changes. The execution side is recorded by the gateway's or the business system's access logs: which endpoint, when, with what result. The two sides are recorded independently and joined by correlation keys — request_id, jti, grant_id: an anomaly on one side leaves the other intact, and tampering with a single record means breaking into two systems at once. For compliance teams, this chain provides the audit-data foundation for behavioral traceability under regimes like PIPL and GDPR (the compliance assessment itself still belongs to the broader data-governance program).

A common question from leadership — "which people are using AI agents?" — gets two layers of answers here: the agent level shows cost and load (the gateway reports call volume and consumption per consumer credential, a ready-made dashboard); the person level shows ownership and boundaries (every delegation is, by construction, a structured record of "this person, at this time, put this agent to work within this scope"). The two layers share correlation identifiers and can be checked against each other.

Integrating GenAuth: two paths, two enforcement shapes

Integration follows the two shapes agents actually take:

• User-level agents: CLI + Skill. The authorization flow lives outside the agent, in a toolkit: a Skill orchestrates the user's intent, while the CLI handles login, agent identity, user authorization, and short-lived credentials. The agent itself ships zero authorization code. Built for agents running on a user's machine or inside an agent workbench.
• Enterprise agents: OpenAPI. Identity, user authorization, credential issuance and verification all happen through direct server-side calls to GenAuth's API. Built for existing applications, backends, and automation platforms.

Enforcement comes in two shapes, and they compose:

• The gateway as the enforcement plane. Gateways like APISIX, Kong, or Higress validate tokens with their JWT / OIDC plugins, then call GenAuth via forward-auth for a live permission decision. An out-of-scope request dies at the gateway — it never touches business logic.
• The business system as the enforcement plane. Services verify, introspect, and decide in-process via the SDK. Built for teams without a central gateway, or decisions that need to sit close to the data.

The existing identity foundation stays untouched: GenAuth federates with the current IdP over OIDC / SAML — employees keep authenticating against the existing system, and the agent identity and delegation layer grows on top. MCP tooling follows the same management/execution split: the management plane lives in GenAuth (instances, templates, OAuth2 configuration, user-to-tool connections, call logs — bulk-import or unbind one by one), while the execution plane stays with the gateway already in place.

One quick-reference table to gather everything this piece has covered:

The system is already written up in 37 pages of official documentation, in English and Chinese — concepts, architecture, integration guides, enterprise scenarios; the questions security reviews ask most often already have their own chapters. GenAuth is in private build and will roll out with Qoni in phases — the waitlist is open on the website.

Don't lend the agent the keys. Issue it a passport that can be revoked at any time.