The agent identity model

Every AI agent is a first-class identity: an OAuth 2.1 client with a human owner, an expiry date, a computed lifecycle status and an attested access review.

Obexal gives every AI agent an identity of its own, governed with the same rigor as a human account: a named owner, a lifetime, an activity trail and a periodic review. This page describes the model; the following pages show how to register an agent, delegate on behalf of a user and constrain it with a policy.

Why not a shared API key

A shared API key is the anti-model of agent governance: it has no owner (nobody is accountable when it misbehaves), no expiry (it outlives the project it was created for), no scopes (it can do everything its issuer could), no attribution (downstream logs show the key, never the person the agent acted for), and revoking it breaks every consumer at once. An Obexal agent is the opposite on each point: individually credentialed, owned, expirable, scoped, attributable and revocable on its own, without collateral damage.

One agent, one OAuth client

An agent is a confidential OAuth 2.1 client that carries at least one machine grant: client_credentials (the agent acts as itself) or urn:ietf:params:oauth:grant-type:token-exchange (the agent acts on behalf of a user). Everything that applies to clients applies to agents: a client_id, a client_secret (only its SHA-256 is stored, the clear value is shown once at creation), a scope perimeter, and strict tenant isolation.

The admin inventory, GET /v1/admin/agents (permission apps:manage), lists every client of your organization carrying at least one of these grants, together with its identity, its effective governance policy and its computed status.

A human owner and an expiry date

PUT /v1/admin/agents/{clientId}/identity assigns the two identity attributes (permission apps:manage, and a fresh MFA step-up when done from the console):

• owner: the email of a user of your organization. It is resolved against the directory and stored as a database reference to that user, not as free text. If the owner is later removed from the directory, the reference is cleared and the agent becomes an orphan.
• expiresAt: an RFC 3339 date. The expiry is enforced fail-closed at token issuance: once the date is past, every token request by the agent is refused with invalid_grant, whatever the grant, and each attempt is recorded as an expired_agent anomaly. An empty value means no expiry.

Computed lifecycle statuses

Every token issuance touches the agent's lastUsedAt timestamp. From it, the inventory derives a status, in this priority order:

Dormant and orphan agents are exactly the ones access reviews exist to catch: still able to authenticate, with nobody watching.

Attested access reviews

POST /v1/admin/agents/{clientId}/review timestamps a human attestation: an administrator confirms having reviewed what the agent is, who owns it and what it can do. The inventory exposes reviewedAt and a needsReview flag, true when the agent has never been attested or when the last attestation is older than 90 days. Every attestation is written to the audit log, which gives you the evidence trail that periodic review programs expect.

One registry for every identity

GET /v1/admin/identities (permission users:view) returns the unified registry of the organization: every identity, whatever its nature, in one list. Each entry carries a kind (human, service for machine clients without agent grants, or agent), a label, its owner, its status, its last activity and its count of open anomalies. Humans, services and AI agents are reviewed through the same pane of glass.

Next steps

1. Register an agent: create the client, set the identity, issue a first token.
2. Delegation with Token Exchange: let the agent act on behalf of a user, attributably.
3. Per-agent governance policy: kill switch, TTL ceiling, scope ceiling, audience allowlist.