🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.
Agent identity model
In GenAuth, an agent is a first-class identity: not a borrowed user account, not a shared service key, but its own identity record — registrable, approvable, owned, with a lifecycle, and killable in one move when something goes wrong (kill switch).
Why an agent needs it
Start with what happens without it. Agents usually sneak into production one of two ways: running under some employee's account, or sharing one long-lived API key. The first blinds your audit — the log always says "Zhang San did it," and nobody knows an agent was actually at the keyboard. The second loses control of permissions — the key is static, too broad, and unowned, so after a leak you don't even know whose door to knock on.
A CISO's first question is "how many agents do I have, and who is responsible for each" (see Why Agent Identity). Without a first-class identity, that question has no answer: an agent that isn't in any registry can't be authorized, audited, or shut off.
The identity model is the foundation for everything after it. Once every agent is on the books, owned, and state-managed, delegation (Delegate Token and attenuation) and accountability (Audit and accountability chain) have something to hang from.
Three building blocks
Agent templates and agents: define policy once
An agent template carries the policy: what this class of agent is for, the maximum scopes it may request, the default token lifetime, and the level of approval required. An agent is created from a template, inherits every constraint on it, and can only narrow further inside the template's boundary — never exceed it. This is the same philosophy as attenuation in delegation: every layer only subtracts (see Delegate Token and attenuation).
Templates have one more critical property: disable the template and you kill every agent under it. When a class of agent turns risky — say the underlying framework discloses a vulnerability — an admin doesn't have to work through dozens of agents one at a time. One disable at the template layer and the entire family immediately stops receiving any new authorization. That is the kill switch in its org-wide form.
Responsible people: someone answers for every agent
Every agent registers two roles:
| Role | Responsible for | Constraint |
|---|---|---|
| Owner | Development, configuration, credential rotation, incident handling | Recommended; can be several people |
| Sponsor | Answering "whose books does this agent go on": business justification, endorsing permission requests, retirement decisions | Required at creation; automatically transfers to their manager on departure |
The Sponsor's two hard rules deserve their own paragraph. Required at creation: an agent without a Sponsor is not allowed into the registry, so there is no such thing as an orphan agent from day one. Automatic transfer on departure: when a Sponsor leaves the organization, sponsorship passes to their direct manager, leaving no vacuum in the accountability chain. Whenever an auditor asks "who is responsible for this agent," there is always a current employee who can answer.
Lifecycle: state determines power
Every state transition is recorded, and state feeds directly into authorization decisions — an agent that is not in the Active state receives no new Delegate Token.
Two points of semantics:
- Disabling is a reversible emergency action — new authorization stops immediately, identity and configuration are preserved, and the agent can come back once the risk is cleared.
- Retirement is terminal — the identity takes no further part in authorization, but registry records and audit history are kept permanently, so retirement never breaks the accountability chain.
Typical scenarios
A support agent fleet. A company runs 30 support agents on one framework, serving different product lines. The admin defines a "support agent" template: order-lookup scopes only, tokens valid for at most 2 hours. All 30 agents inherit the same boundary, and a policy change touches the template in one place. The day the framework discloses an injection flaw, disabling the template kills all 30 at once. Full story in Governing an agent fleet.
A Sponsor leaves. The data assistant agent's Sponsor, Li Si, resigns. The moment the offboarding process takes effect, sponsorship transfers to Li Si's direct manager. Three months later, when an auditor spot-checks this agent's permission requests, the responsible-person field is neither blank nor a name that no longer exists.
Unattended still means owned. A scheduled reconciliation agent has no delegating user at all — it doesn't act for anyone. But it has an Owner and a Sponsor: autonomous action can go without a delegator, never without a responsible person (see Unattended scheduled agent).
How it works
This corresponds to hop ① of the main sequence (full diagram in The full journey of one delegation and End-to-end business sequence):
- Define the template (responsible party: App admin) — declare what this class of agent is for, its scope ceiling, default token lifetime, and approval requirements.
- Create the agent and register its responsible people (App admin) — create from the template; Sponsor is required, and registering an Owner at the same time is recommended.
- Approve into the registry (GenAuth × approver) — run the approval flow the template declares; once approved, the agent enters the Active state and appears in the company's agent registry.
- Verify at runtime (GenAuth) — from then on, before every delegation issuance and every token exchange, GenAuth checks the state of both the agent and its template: if either layer is disabled, the request is rejected.
- Change and retire (App admin × GenAuth) — make policy changes once on the template and they apply to every agent; after retirement the identity is deactivated while registry and audit records are preserved.
Standards and protocols
- RFC 6749 (OAuth 2.0) — at the protocol layer, an agent identity lands as a confidential client that holds its own credentials instead of borrowing someone else's identity; GenAuth layers templates, responsible people, and lifecycle on top of that model.
- RFC 7591 (OAuth 2.0 Dynamic Client Registration) — the direction registration is heading: turning agent registration from a manual action into a programmable flow.
- OpenID Foundation white paper Identity Management for Agentic AI (2025-10) — the industry framing: agents should become first-class citizens of IAM. The identity model on this page follows that direction.
Next steps
- Scenario: Governing an agent fleet — the full loop from discovery to registration, approval, inspection, and kill switch
- Guide: Register and manage your agents — every lifecycle verb, one at a time
- Reference: Glossary and migration — canonical naming for templates, agents, and responsible people