§ DOCUMENTATION
Agent Identity
Execlave issues short-lived, cryptographically signed RS256 credentials for AI agents — enabling downstream services to verify "is this really agent X, issued by my org, not revoked?" via a public JWKS endpoint, with no shared secrets.
What an agent credential is
An agent credential is a short-lived RS256-signed JWT prefixed exe_agt_, issued on demand for a specific agent. The default TTL is approximately 15 minutes. The JWT is signed with a private key that never leaves Execlave — any relying party verifies it using the corresponding public key fetched from the public JWKS endpoint, with no shared secret to distribute or rotate.
The credential answers the machine-identity question for non-human workloads: "which agent is this, which org issued the credential, and has it been revoked?" — verifiable by any downstream service without calling back to Execlave at verification time.
| JWT claim | Meaning |
|---|---|
| iss | Issuer — Execlave API origin |
| aud | Audience — intended relying party scope |
| sub | Subject — agent ID (agt_…) |
| org | Organisation ID the credential was issued under |
| kid | Key ID — identifies which JWKS key to verify with |
| jti | Unique token ID — used for revocation lookup |
| iat | Issued-at timestamp (Unix seconds) |
| exp | Expiry timestamp (Unix seconds, ~15 min from iat) |
The public JWKS endpoint & offline verification
GET /.well-known/jwks.json returns the RSA public keys Execlave uses to sign agent credentials. The endpoint requires no authentication and is safe to call from any verifier — including services that have no Execlave API key.
A verifier fetches the JWKS once (and caches per standard JWKS rotation conventions), selects the key matching the kid in the JWT header, and verifies the RS256 signature locally. No round-trip to Execlave is needed for signature verification — only for revocation checks, which require calling the credential verify path.
# Fetch the public JWKS — no auth required, safe to call from any verifiercurl https://api.execlave.com/.well-known/jwks.json # Response{ "keys": [ { "kty": "RSA", "use": "sig", "alg": "RS256", "kid": "key_01j...", "n": "0vx7agoebGcQSuuPiLJXZptN9...", "e": "AQAB" } ]}Issuing & revoking credentials
POST /api/v1/agents/:id/credential. Requires Developer or Admin role. The response includes the signed JWT, its expiry, and the jti and kid for your records. Use POST /api/v1/agents/:id/credential/revoke to immediately invalidate a credential by its jti.# Issue a short-lived RS256 credential for an agent (Developer or Admin role)curl -X POST https://api.execlave.com/api/v1/agents/agt_01j.../credential \ -H "Authorization: Bearer $EXECLAVE_API_KEY" # Response{ "data": { "token": "exe_agt_eyJhbGciOiJSUzI1NiIsImtpZCI6ImtleV8wMWoifQ...", "expiresAt": "2026-06-02T10:29:00Z", "jti": "cred_01j...", "kid": "key_01j..." }}# Revoke a credential — effective immediatelycurl -X POST https://api.execlave.com/api/v1/agents/agt_01j.../credential/revoke \ -H "Authorization: Bearer $EXECLAVE_API_KEY"Revocation & expiry semantics
Verification checks two conditions in order: expiry (exp claim vs. current time) and revocation (jti lookup against the agent_credentials table). A token fails verification if either condition is not met — an expired token cannot be un-expired by revoking it, and a revoked token cannot be reactivated.
Revocation takes effect immediately with no cache TTL. The revoked_at timestamp is stamped on the credential record and all subsequent verification calls will reject the token. This makes short-lived credentials plus on-demand revocation the recommended pattern for high-sensitivity agents.
| Credential state | exp in future | revoked_at set | Verification result |
|---|---|---|---|
| Valid | yes | no | Pass |
| Expired | no | no | Fail — expired |
| Revoked | yes | yes | Fail — revoked |
| Expired + revoked | no | yes | Fail — expired |
Stamping identity onto traces
Beyond on-demand issuance and JWKS verification, Execlave can bind a verified identity to every execution trace. When an agent presents its credential on trace ingest, the platform verifies the signature, confirms the credential has not been revoked or expired, and checks that the credential's org and subject match the ingesting org and the attributed agent. The outcome is recorded on the trace as an agent_identity field: { agentId, jti, kid, verified }.
The SDKs attach the credential automatically when you opt in — set stampIdentity: true (TypeScript) or stamp_identity=True (Python) in the client config. The SDK issues and caches a short-lived credential per agent and attaches it to each trace at flush time.
Stamping is additive and non-breaking: a trace sent without a credential is accepted unstamped, exactly as before. A presented-but-invalid credential never blocks ingest — it is recorded with verified: false and a reason, so a forged or stale credential surfaces as an audit signal instead of silently dropping the trace. Credentials issued for a different org or a different agent are treated as unverified and never trusted.
Related: agent credentials complement the Agent Passport (behavioural identity over time) and Runtime Guardrails (A2A authentication enforcement at call time).