auth00 for AI agents
An agent that acts on its own cannot borrow a human account. It needs an identity of its own, a key that expires, and a record of what it did that outlives the conversation it came from. All three run here today.
Three things an agent needs
An agent client is its own kind of client, not a human account with a robot attached.
It authenticates with client_credentials and carries only the
scopes the tenant approved for it.
That is what makes the audit trail readable later: the question "which agent did this" has an answer that is not "someone's login".
Tokens are short-lived and bound to the key that asked for them — DPoP, and the minted token carries the key thumbprint cnf.jkt. A stolen bearer token is useless without the private key it was minted against.
Agent keys rotate. A replayed key is treated as theft: the whole key family is revoked, so a leak ends the family instead of quietly living on.
Whatever the agent produces can be sealed with sign.it — hashed in the browser or in the process, anchored on three independent rails, listed in a registry anyone can check without an account.
Output that proves itself is worth more than a log file only you can read.
The state of every piece
Vendors in this field publish a feature and mark it "coming soon" in small print. We would rather put the state in the table. Every row below was measured against the running engine, not read from a roadmap.
| Capability | State | How you can check it yourself |
|---|---|---|
Agent sign-in (client_credentials) |
running | Listed in /.well-known/openid-configuration under grant_types_supported. |
| Key-bound tokens (DPoP) | running | dpop_signing_alg_values_supported in the same document; the minted token carries cnf.jkt. |
| Rotating agent keys, family revoked on reuse | running | Present a rotated key twice. The second attempt kills the family, not just the key. |
| Pushed authorization requests (PAR) | running | POST /par answers with a field-level validation error, not a 404. |
| Token introspection and revocation | running | introspection_endpoint and revocation_endpoint in discovery. |
| Self-registration (RFC 7591) | built, switched off | POST /register answers 404 by design until a tenant enables it and issues an initial access token. Fail-closed, not missing. |
| Certificate-bound access (mTLS) | built, not advertised | The route exists; it is not yet in the discovery document, so a conforming client will not find it. That is a gap on our side. |
| Measured agent certificates (AATP) | running, separate service | A signed, revocable certificate issued from a measurement of the running service, written into a recomputable transparency log. |
Two of these rows say something is not finished. They stay in the table. A page that only lists what works is a brochure, and you would find the gaps in week three anyway.
The part nobody else has
“Is this agent safe to use?” is asked before every integration and answered by a screenshot. We answer it with a measurement.
A certificate that cannot be withdrawn is a souvenir. That is why this sits next to the identity platform rather than inside it.
Asked before every integration
It can, and it is the reason most agent incidents are hard to investigate. A shared service account answers "was this allowed" but never "which agent did it". When you revoke it, everything using it stops. An agent client is scoped, revocable on its own, and shows up in the audit trail under its own name.
Agent keys rotate. If a key is presented after it was rotated, that is treated as theft rather than as a retry: the entire key family is revoked, so the attacker and the legitimate agent both stop. You then re-issue for that one agent. The blast radius is one agent, not one tenant.
Yes — that is the normal case, and no credential of the user ever reaches the agent. The user authenticates once at the door; the agent receives a scoped, short-lived token bound to its own key. What the agent may do is a property of the token, not of the user's account.
Seal the output. The hash is computed where the output is created and anchored on three independent rails; the asset itself never has to be uploaded anywhere. Later, anyone can check the exact bytes against the registry without an account and without asking us. That is the difference between a log entry and a proof.
Because for this one job, small is not the deciding property and we can show our work. We hold no ISO 27001 and no SOC 2 — that is stated plainly on the trust page, along with what we do instead and what it does not replace. If a certificate is a hard procurement requirement, buy the large vendor. If checkable evidence is what you actually need, this is built for it.
One client, one scope, one rotating key — and an audit trail that still makes sense in six months.