Every generation of identity protocols answers the same question

Identity technology is thirty years old. Compress those thirty years into one sentence, and they keep answering a single question, over and over: this new kind of subject — why should anyone trust it?

In the LAN era, the question was "who is the person at this machine?" AD/LDAP put every member of an organization into a directory; Kerberos handed them tickets to move freely across the intranet. Identity became enterprise infrastructure for the first time.

In the web era, the question became "why should this app act on my behalf?" SAML carried identity beyond the intranet — single sign-on across organizations and data centers. OAuth then did something quietly radical — it separated authorization from authentication — and OAuth 2.0 made that separation the common standard of the entire web. You could let an app act for you without ever surrendering your password.

In the mobile-and-cloud era, the question was "one me, across countless apps and devices." OIDC completed the authentication layer on top of OAuth 2.0, and "Sign in with ..." became the default front door of the entire internet.

Thirty years, five generations of protocols, each more elegant than the last — even the newest decentralized-identity (DID) experiments still issue credentials to people. They share one assumption, buried so deep almost nobody thinks of it as an assumption at all: 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.

The web has new residents

Now, for the first time in thirty years, that assumption is breaking.

There's a new actor inside companies: the AI agent. It queries data, files requests, calls internal systems — work that used to belong exclusively to employees. It isn't a user, and it isn't an app; it's a third kind of digital subject. Yet the identity stack built for humans has no seat for it. Machine-to-machine credentials do exist — but the assumptions baked into the stack are still human-shaped: one subject, one login, one durable set of permissions.

And an agent simply doesn't grow into that shape. It decides its next step at runtime — which system to touch, which tool to call — 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: whether each step should be allowed has to be judged at the moment that step happens.

So today, most agents act on borrowed identity: an employee's API key, a shared service account, or one over-privileged master credential.

In a demo, none of this shows.

The three questions your security team will ask

The moment an agent heads for production, security puts three questions on the table:

1. When something goes wrong, can you tell who did it? A call happened; the log says "user." Was it the person, or an agent acting for them? Which agent? On whose behalf?
2. It only needed to do one thing — why does it hold a person's entire permission set? Handing a user credential to an agent hands over everything that user can do, all at once.
3. Can you answer "what allowed this call"? Traditional audit logs speak in the grammar of human subjects. Swap in an agent, and the question hangs unanswered.

These aren't tech debt you can defer. They're the ticket price for production.

Academia has already named the problem precisely. Researchers distill the attribution layer of agent infrastructure into three propositions (Infrastructure for AI Agents, Chan et al., 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. Hold those against thirty years of protocol history and a gap appears: OAuth lets a human authorize an app, OIDC lets an app recognize a human — but no widely adopted protocol built for agents yet lets the world recognize one.

And the gap is structural. The same paper runs through the alternatives already at hand: OAuth tokens and API keys can aid attribution, but they are bound to a single service by construction — 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. At the protocol layer, even the newest agent-to-agent protocols (A2A) only answer what an agent can do — the AgentCard handles capability discovery and interop — while who stands behind it, and why it should be trusted is still left hanging.

Qoni's answer: a passport

GenAuth is Qoni's identity layer. It isn't "one more account system" — it's the next generation of the identity stack, completed for agents this time. Its answer fits in one sentence:

Give every agent a passport of its own — the agent holds zero standing permissions, and every capability it exercises comes from an explicit, revocable grant made by a specific person at a specific moment.

Unpack that passport:

• Agent ID: the passport itself. Every agent gets an independent identity and credentials, with a full lifecycle — issuance, rotation, revocation. No more borrowed shadows.
• Identity binding: the issuer on the passport. 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.
• The delegation chain: the visa pages inside. No new protocol invented — instead, delegation semantics for agents extended along the existing rails of OAuth 2.0 / OIDC: short-lived credentials whose scope only ever narrows, never widens. Your existing identity infrastructure stays; the new layer grows on top of the standards.

One more piece: an agent's capabilities come 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 — whether an agent's behavior can be trusted is no longer a matter of faith, but a matter of record.

Not lending your identity to the agent — letting the agent act as itself, inside boundaries a human has drawn.

The big picture first: an identity hub with no root authority

Put the passport into an architecture, and GenAuth sits as the identity hub between users, agents, and enterprise resources. A user initiates a delegation through an approval flow; GenAuth issues the agent a short-lived, scoped credential on that basis; the agent accesses resources with it; and the whole path emits audit events. The model's first-principles constraint fits in one sentence: an agent owns an identity, but owns no inherent permissions — no root authority. Every permission it ever exercises comes from an explicit delegation by a specific person at a specific moment, revocable at any time.

One detail you can verify on the spot: an agent's dedicated credentials support a full lifecycle — create, rotate, disable, delete — and 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.

Authorization that works like a visa

Every grant on that passport behaves like a visa:

• Scoped and time-boxed. Each grant states exactly what it can — and cannot — touch; it expires after an hour by default, and can be as short as a minute. When the task ends, the permission evaporates. Security engineering has a name for this state: zero standing privileges — an agent with no task in hand holds no standing business authority.
• It only ever narrows. To reach a new class of systems, the agent must exchange its grant for a narrower one. However clever the model, it does not get past these two gates — an out-of-scope request is stopped before it ever reaches your business systems.
• Revocable, instantly. The user or an admin can withdraw a grant at any time, and it takes effect immediately — the exact effectivity boundaries get a section of their own below.
• Everything leaves a trail. Every grant, every access, every denial is recorded. Afterwards you can always answer five questions: who, authorized whom, to do what, when, and on what authority. Even the attempted overreach is on the record.

These four visa rules map to GenAuth's four core principles: predictable, governable, revocable, traceable.

Security engineering has a name for this narrow-only design: the principle of least privilege. Game theory has a more intriguing one: a commitment device. The way to make a promise credible isn't to phrase it better — it's to limit your own future options. Scoping and time-boxing every permission an agent holds makes exactly that kind of promise on its behalf. The boundary isn't there because we distrust the agent; the boundary is what makes it trustworthy.

Discipline, minted into the token

The visa analogy is for intuition. The real constraints live at the protocol layer.

Start with the first-principles design. GenAuth's entire permission model compresses into one line of set arithmetic:

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

Three sets, one intersection. It means authority can only narrow as it travels down the chain, never widen (authorization-system design calls this property attenuation; the agent-authorization drafts under discussion at the IETF treat it as a core requirement). The source of all permission is always a person, and what the agent holds is the intersection of three sets — so however capable the model, it is constitutionally incapable of out-ranking the human who delegated it.

The designs below are that formula, enforced at the protocol layer:

A two-token architecture: the delegate token "can exchange, but can't open doors." GenAuth splits authorization and action into two kinds of tokens. When a user approves a delegation, the agent receives a delegate token — its audience points permanently at GenAuth's exchange service (fixed to genauth:token-exchange), never at any business resource. It opens no doors. To reach a resource, the agent must perform an RFC 8693 Token Exchange (the standard 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. Which means: 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: no exchange can ever mint a permission the delegation didn't contain. In the event stream, 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.

The delegate token deliberately has no act. RFC 8693 uses the act (actor) claim to say "who is acting on whose behalf." GenAuth's design discipline: the delegate token doesn't carry it, because at authorization time, no action has happened yet. act is minted only at the moment of exchange, into the access token. And it's an extended structure with a type discriminator — the docs will tell you plainly that a stock RFC 8693 library will silently fail to parse it: validation appears to pass while checking nothing. So the resource side must explicitly check the delegation type, and fail closed. Admitting where we deviate from the standard's default shape, and telling you why you must handle it explicitly — that's what we mean by engineering honesty.

Time-to-live is a first-class citizen. Delegate tokens live from 60 seconds to 24 hours, one hour by default; for single-task delegations we recommend 5 to 15 minutes. And the clock runs on more than one layer: the interactive-authorization window is 10 minutes, the approval session 10 minutes — every layer's window is squeezed to the minimum that step needs. Expiry isn't an exception — it's the norm. The task ends; the permission should end with it.

Consent inherits the OAuth authorization-code discipline. Interactive authorization returns a one-time callback code: the server stores only its hash, consumption happens inside a database transaction, and a state machine guarantees each code is used exactly once. Issuing passports to agents runs on the same security choreography this industry has hardened for over a decade.

Audit is a dual-ID chain. Every delegation mints a grant_id (which authorization) and an audit_id (what happened under it), both generated by GenAuth and embedded in the token itself, traveling wherever it goes. Even an attacker holding a stolen token cannot book their actions under someone else's grant.

And the system's 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.

Rules in one place, enforcement at the edge

Tokens answer "is this credential trustworthy?" That's only half the problem. The other half: should this particular request go through?

GenAuth follows the classic separation in access control: the policy decision point (PDP) is centralized, the policy enforcement point (PEP) is pushed down. How the rules are written is managed in one place — GenAuth. Where the traffic gets stopped is wherever it arrives: at the gateway edge, or inside the business service.

On the decision side sits a four-layer permission model: roles (RBAC) answer who, policy conditions answer under what circumstances, resource namespaces answer which class of resource, and data permissions answer down to which row. Each layer works alone or stacked. 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.

For the operations team, the payoff is immediate: tightening a policy means changing no business code and waiting for no release train. Adjust the policy in the console, and newly issued tokens carry the new scope at once (with one honest exception: if your enforcement point is the gateway, its plugin configuration is still yours to update — we'd rather write that down than round it away).

This split also answers a very practical objection: agents move far faster than people, and if every step popped a confirmation dialog, "confirm" would decay into a mindless click within days. GenAuth divides the labor differently: what a human approves is one scoped, time-boxed delegation — not each individual action; every exchange and access inside that delegation 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.

A delegation's life: an object with a lifecycle

In GenAuth, a delegation isn't a config entry — it's an object with a full lifecycle. The agent initiates a request and the delegation sits pending; only when the user signs in on the approval page and confirms (a 10-minute approval window) does it get issued; while in use, the resource side can query its live status via introspection at any moment; it expires on its own, or gets revoked by the user or an admin at any point. And every delegation object records its approver and approval time: "on what authority does this agent hold this permission" always has a definite answer.

"Revocable at any time" is a sentence every identity vendor writes. The engineering question that actually 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.

Both boundaries are given by design, with no gray zone in between. This is also the deeper reason GenAuth insists on short lifetimes: when a credential leaks, the blast radius is set by the token's lifespan. And even in the worst case, three lines of defense remain: the agent's dedicated credentials can be disabled and rotated instantly; the credentials themselves carry zero business permissions — actual access rides on delegations and exchanged access tokens, all short-lived and revocable; and enforcement-side checks keep running throughout. Trip any one of them, and a leaked credential's usable window collapses to the credential's own short lifetime.

Tools go through security, too

Half of an agent's capability comes from tools, and MCP is a widely adopted protocol for plugging them in. But as tools multiply, a new management black hole opens up: every tool with its own keys, its own logs, and "who may use which tool" scattered across each tool's own configuration.

GenAuth pulls MCP into the same identity plane, and splits management from execution: the management plane lives in GenAuth — instances, templates, OAuth2 configuration, user-to-tool connections, call logs, all explicit objects you can bulk-import or unbind one by one; the execution plane — the gateway actually carrying tool traffic — stays with the gateway you already run. "Which user may connect to which MCP tool" becomes a visible, governable record; and every tool call's four facts (who, which agent, called what, when) flow into the same audit chain as delegations and exchanges.

Two roads into your stack

The most complete passport system is worthless if it can't plug into what you already run. GenAuth offers two integration paths, matching 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 and still carries a passport. Built for agents running on a user's machine or inside an agent workbench.
• Enterprise agents: OpenAPI. The authorization flow is internalized into your own business logic: 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.

The only difference between the two roads is where the authorization flow lives — bolted on, or built in. Past the entrance, it's the same permission checks and the same audit trail. Your existing identity foundation stays untouched, too: GenAuth federates with your current IdP over OIDC / SAML — employees keep authenticating against your system, and the agent identity and delegation layer grows on top. Your API gateway keeps its place as the single entry point for agent traffic. Adopting agents doesn't mean rebuilding your infrastructure.

What it looks like inside an enterprise

Enforcement also comes in two shapes — pick the one that matches your architecture:

• The gateway as the enforcement plane. Gateways like APISIX, Kong, or Higress validate the token with their JWT / OIDC plugins, then call GenAuth via forward-auth for a live permission decision, forwarding or rejecting accordingly. An out-of-scope request dies at the gateway — it never touches business logic. Built for companies with a unified entry point that want permissions enforced at the edge.
• 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 business logic.

The two shapes also compose: north-south traffic gets stopped uniformly at the gateway, while individual services add data-level decisions in-process via the SDK.

How fine is "fine-grained"? It stacks in two places: inside the token, the audience and permission list are doubly narrowed at issuance — by what the resource registered and by what the user delegated; outside the token, the enforcement point re-checks the agent, the credential, the grant, the data policy, and revocation status live, before every pass. Fail any one condition, and the request dies at the enforcement point without touching business logic.

Here's what one call looks like at runtime:

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 a visa 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.

"Which people are using AI agents?" — one question, two layers of answers

The first question leadership asks is rarely about protocols. It's this plain one. And it properly splits in two.

The first layer is agent-level: which agent made how many calls, burned how many tokens, at what latency. Your gateway answers this natively: each agent binds one-to-one to a gateway consumer (the caller credential), so per-consumer call volume and consumption is a ready-made dashboard (no central gateway? this layer falls to the business system's access logs, or GenAuth's verification records).

The second layer is person-level: who, when, through which agent, touched what, under what authority. The gateway can't answer this — and shouldn't be asked to: multiple users' delegations can flow into the same agent, and aggregate consumer metrics cannot be split back out to individual people. The person-level answer lives in GenAuth's delegation and audit records: 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.

Put the layers together, and "which people are using AI agents" has a visualizable answer for the first time: the agent level shows cost and load; the person level shows ownership and boundaries.

Audit: two sources, each vouching for the other

Who, authorized whom, to do what, when, on what authority: the five audit questions draw their answers from two sources that vouch for each other. The authorization side is recorded by GenAuth: delegation approvals (with the approver), 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 was called, when, with what result.

The two sides are recorded independently by different systems, joined by correlation keys like request_id, jti, and grant_id. The value of that design only shows under adversarial conditions: an anomaly on one side leaves the other side's records intact, and tampering with a single behavior record means breaking into two systems at once. Sample any call, and the correlation keys walk you back to complete answers for all five questions. 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 your broader data-governance program).

And every capability above lands as a line item you can check off on a POC acceptance sheet:

• A valid credential requesting outside its scope is rejected at the enforcement point, with a record;
• After a user revokes a delegation, introspection-validated paths fail immediately;
• After a policy change, newly issued credentials carry the new scope at once, with no business-service redeploy;
• Sample any single call, and request_id / jti walk you back to complete answers for all five questions;
• Pick any employee and any time window, and you can list every delegation they granted and the agent activity under each.

The three things enterprises actually evaluate an agent platform on now each have a section of their own: usage accounting (the two-layer answer), fine-grained permissions (the PDP / PEP four-layer model), and audit traceability (dual sources, five questions).

This isn't a concept

The identity 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.

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

GenAuth is in private build and will roll out with Qoni in phases — you can join the waitlist on the website.

You shouldn't have to choose

Companies shouldn't have to choose between letting agents work and holding the security line.

Every time identity technology answered "why should this new subject be trusted," the world gained a new layer of productivity: directories and tickets carried the enterprise intranet, SAML and OAuth carried SaaS and open platforms, OIDC carried the mobile internet. This time, it's the agent's turn.

Don't lend your agent the keys. Issue it a passport you can revoke at any time.

Identity technology took thirty years to get here. This time, the subject is finally the agent.