A verifiable, governed identity for every AI agent.

Your AI agents reach into your systems just like your people do. Obexal gives each one a first-class identity: a human owner, an expiry date, capped permissions and a full audit trail of every action taken in your name.

At a glance

Identity	One confidential OAuth 2.1 client per agent; a named human owner; an expiry date
Statuses	Active, dormant, expired, orphaned; attested access review every 90 days
Delegation	Token Exchange (RFC 8693), chained act claim; audience binding (RFC 8707)
Ceilings	Scopes, token lifetime, audience allowlist; all fail-closed
Detection	6 deterministic rules; automatic containment on extreme drift
Kill switch	Immediate; tokens already issued become inert at introspection
Audit trail	Forensic delegation log: who acted, when, on whose behalf
Plan	Business

An agent is an identity

An agent that reads your CRM, files tickets or moves money is a non-human identity with real reach. Too often it authenticates with a shared API key pasted into a vault or an environment variable. That key has no owner, no expiry date and leaves no attributable record of what the agent does. When an incident hits, nobody knows whose key it is, or how to cut it without breaking something else.

Obexal closes that gap. Each agent becomes a first-class confidential OAuth 2.1 client with its own credentials, tied to a named, accountable human owner. It carries an expiry date, so a forgotten agent stops working instead of lingering forever. Its status is legible at a glance: active, dormant, expired or orphaned (owner gone). An attested access review comes round every 90 days: an agent left unreviewed surfaces on its own for a decision.

All of it lives in one unified registry alongside your users and services. Humans, service accounts and AI agents sit in a single inventory, held to the same standards of ownership, expiry and review. When an owner leaves, their agents do not vanish into the gaps between systems: they show up as orphaned and wait for a decision, so a departure never leaves a live credential with nobody watching it.

Attributable delegation: acting on a user's behalf

An agent rarely acts alone: it acts for someone. When Sarah's assistant queries the CRM on her behalf, the token must not erase Sarah in favour of the bot. Obexal relies on Token Exchange (RFC 8693): the agent swaps the user's token for a delegated token in which the user stays the subject (sub) and the agent is named in the act claim (act.sub). You always know who acted, and on whose behalf.

The act claim chains: when one agent delegates to another, every link stays visible in the token. The requested scope is narrowed by intersection (downscoping): never more than the user holds, never more than the agent may carry, never more than the ceiling allows. Each token is also bound to its recipient through an audience (RFC 8707), so a token delegated for the CRM is worthless anywhere else. And the delegating user gives explicit consent, bounded to precise scopes and revocable at any time. Everyone can see, in their own portal, which agents act in their name, with a button to cut them off.

Governance enforced per agent

Governance does not live in a wiki page: it applies at the very moment a token is issued. Each agent carries a policy that defines what it can obtain, and that policy is fail-closed. If it cannot answer, issuance is refused rather than granted by default.

• Scope ceiling: the agent can narrow its scope, never exceed the ceiling set for it.
• Token lifetime (TTL) cap: every token gets a maximum lifetime, short by default, so a leaked token is not exploitable for hours.
• Audience allowlist: the agent only obtains tokens for the resource servers explicitly allowed, keeping any compromise contained to the apps it was meant to reach.

These ceilings are the agent's contract with your systems, and they hold whatever the agent asks for. The agent's secret rolls over in one call or one click. The new secret is shown only once and the old one stops being accepted immediately. You can give it a lifetime, and authenticating with an expired secret is refused and flagged. Rotating and expiring agent secrets becomes a logged routine, not a risky operation nobody dares to run.

Detect drift, then contain it

Six deterministic, explainable rules watch every agent, with no opaque statistical model:

• Dormant agent waking up: an agent that had gone silent suddenly starts issuing again.
• Use of an expired agent: the agent keeps authenticating past its expiry date.
• Use of an expired secret: authentication relies on a secret whose lifetime has run out.
• Use despite a kill switch: attempts keep coming while the agent is switched off.
• Unusual hours: activity falls outside the hours seen in the agent's own history.
• Volume spike: issuance climbs far above the agent's average.

On extreme drift, the agent is contained automatically, without waiting for a human. Every delegation is also written to a forensic log: who acted, when, on whose behalf, exportable for your audits.

When something looks wrong, you do not need a migration: a switch is enough. The kill switch is immediate, and it is a pause, not a demolition. It blocks all new issuance, client_credentials and Token Exchange alike, and makes the tokens already in circulation inert: at introspection they answer inactive, so APIs that validate through introspection reject them at once. The agent's policy (ceilings, allowlist) is preserved, and you re-enable it in one click once the incident is closed. Every toggle is logged.

Built on open standards

No proprietary SDK, no lock-in: an Obexal agent is a standard OAuth 2.1 client your stack already speaks. The client_credentials grant gives it its machine identity; Pushed Authorization Requests (PAR) push authorization parameters server-side before issuance; DPoP proof-of-possession stops a stolen token from being replayed from another machine. Your APIs verify tokens through introspection (RFC 7662), and the response exposes the act claim, so your service sees both the subject (the user) and the actor (the agent), even across chained delegation.

Registering an agent and setting its policy go through the administration API, authenticated by a scoped token of the form obx_ and described by a public OpenAPI 3.1 contract. Any framework that can POST to the token endpoint works, whether LangChain, an MCP server or a plain script. Discovery is served at /.well-known/openid-configuration and signing keys at /.well-known/jwks.json, so a client configures itself from the issuer alone. The documentation details every call.

Traceability and the AI Act

Let us be honest: no identity provider makes an AI system compliant on its own, and we will not promise you that. Obexal contributes to your obligations by providing the technical controls they rest on: an attributable identity for every agent with a named accountable human, a delegation log that records who acted and on whose behalf, immediate revocation through the kill switch, and an exportable audit log. The compliance work stays yours; Obexal gives you the evidence.

This governance sits on a sovereign foundation. Obexal is hosted in France, in a datacenter in the Paris region, with data residency in the European Union and no dependency outside the EU in the request path. Agents belong to the same identity core as the rest of your organisation: see identity and access management for your workforce, CIAM for your customers, and AI agent governance for the security and compliance reading. Agent identity and governance are part of the Business plan: see the pricing page.

Frequently asked questions

---

Continue: IAM, your workforce identity · CIAM, your customers' identity · AI agent governance for your SOC