Agents and credentials

An agent in Axiom is a stable logical identity inside one customer tenant. Its credentials are separate records with their own lifecycle. Keys rotate, runtimes restart, workloads move; the agent ID, and the authority to resume its own pending actions, stays the same.

The agent record

Field	Meaning
id (agt_…) and tenant_id	Durable identity and its namespace. The agent ID is the OAuth client_id.
owner_user_id or owner_service	The accountable owner. Registering without one makes the registering person the owner: every agent has an owner.
publisher, operator, sponsor_user_id	Recorded separately where they differ: who built the agent, who runs it, and who in the customer tenant sponsors it.
status	active, suspended or retired. Retirement is final; register a new agent instead.
discovery_state	Inventory label (observed, registered, verified, enforced). Binding a credential marks the agent verified.
created_at, last_seen_at	Original registration time, and the last time a token for this agent was used.

Agents are registered by a tenant admin (or an org security admin) with POST /v1/tenants/{tenant_id}/agents. See Registering and admitting agents.

Credentials

Each credential row has a kind, thumbprint, validity window, status and, after rotation, superseded_by. Three kinds exist:

Kind	How it is bound	How the agent authenticates
jwk	The public JWK plus a signed answer to a single-use challenge (proof of possession). Default validity 90 days, at most 365.	private_key_jwt client assertion signed by the key.
x509	As jwk, with issue_certificate: true: the CA port also issues a client-authentication certificate for the key. See Sectigo's CA role.	Same as jwk. The certificate is evidence about the key, not a separate login.
spiffe / oidc	An issuer and subject. The issuer must already be listed in the tenant's trust profile as a workload issuer (with its JWKS URI and audience).	A workload token (SPIFFE JWT-SVID or OIDC ID token) from that issuer as the client assertion, verified against its JWKS.

Proof of possession

Possession is proven twice:

1. At enrollment. POST /v1/agents/{agent_id}/credentials/challenge returns a nonce. The key signs { "agent_id", "nonce", "aud" } (typ: axiom-pop+jws) and the binding call carries the compact JWS. The challenge is single use and expires after 10 minutes. The private key never reaches Axiom; the console generates browser keys with WebCrypto in the tab.
2. On every request. The agent's access token is opaque; Axiom stores only its SHA-256 together with the thumbprint (jkt) of the key that made the token request's DPoP proof, and every call carries a fresh DPoP proof signed by that key, bound to the method, URL and token hash. A replayed proof (same jti) is rejected. See Authentication.

Rotation

Binding a new key moves the agent's currently active key credentials (kind jwk or x509) to rotating: they keep working until the end of an overlap window (rotation_overlap_seconds, default one day, at most seven days, never beyond their own expiry), then expire. Binding a key that is already bound (to this or another agent) is refused with 409 conflict; generate a new key to rotate. The agent ID does not change, so:

• the agent re-authenticates with the new key and keeps resuming its own pending actions;
• an action approved before rotation can still be resumed by the agent after rotation, because the resume check accepts a rotated credential and only refuses a revoked one.

In the SDK, agent.rotateSigner(newSigner) drops the cached token and authenticates with the new key under the same agent ID. From a terminal, axiom agent bind enrolls the CLI's key with proof of possession (see Registering and admitting agents).

Revocation and suspension

• Revoking a credential (POST /v1/agents/{id}/credentials/{cid}/revoke, reason required) revokes every token issued against it. An x509 certificate is also revoked at the CA by serial; a CA outage does not block the revocation in Axiom.
• Suspending or retiring the agent (POST /v1/agents/{id}/status, reason required) revokes all its tokens immediately. A resume of an already-approved action re-checks agent status and moves the action to revoked (agent_suspended). Reactivation needs an authorised person and a recorded reason.

Verifying an old signature and establishing a credential's current status are different questions. Receipts keep the credential kind, thumbprint and issuer used at the time; current status is a separate lookup.

Workload identity

A tenant can trust a workload identity issuer instead of (or as well as) enrolled keys:

PATCH /v1/tenants/{tenant_id}/trust-profile
{
  "workload_issuers": [
    { "issuer": "spiffe://prod.example.com", "jwks_uri": "https://spire.example.com/keys", "audience": "https://api.sectigoaxiom.com/oauth/token" }
  ]
}

The agent's credential is then { "kind": "spiffe", "issuer": "spiffe://prod.example.com", "subject": "spiffe://prod.example.com/billing-agent" }. At the token endpoint the workload token is verified against the issuer's JWKS, issuer and audience, and its sub must be bound to this agent. A DPoP proof is still required, so the access token is bound to a key the workload holds.

Stored, not yet enforced

The trust profile also accepts accepted_issuers and status_freshness_seconds. Both are stored and returned, but no code path enforces them today. Status freshness for gateways is fixed by the policy bundle lifetime (300 seconds); see Relay and status freshness.

Third-party agents and what each assertion proves

A vendor may publish an agent that many customers use. The receiving customer decides which evidence it accepts, verifies the live agent's key possession and grants access to its own tenant. Axiom keeps these assertions separate because they prove different things:

Assertion	What it proves	What it does not prove
Key possession (enrollment)	Whoever bound the credential held the private key at that moment.	Who that is, or that they still hold it.
DPoP proof (each request)	The caller holds the key the token is bound to, now.	Anything about the operator's legal identity.
Operator claimed (agent card)	What the card says. Always self-declared.	That the named company runs the agent.
Domain control	The card is served from the claimed domain's well-known HTTPS location, or the domain is a verified domain of a Sectigo-validated organisation.	Legal identity.
Legal entity validated	An Axiom-signed card binds the agent to an organisation Sectigo validated, with evidence time and freshness.	That the agent behaves well, or holds any business permission.
Grant	The customer tenant authorised these operations on these resources until this time.	That a person approved a specific transaction.

The Agent identity check shows each assertion with its own evidence and freshness. When only the operator and the key have been verified, that is all a receipt can say about the agent: its agent block carries the credential kind, thumbprint, optional issuer, and the recorded operator, publisher and sponsor.