Giving AI agents real identity

The credential story for most agent fleets is a shared API key in a Kubernetes secret — long-lived, bearer-style, invisible in logs until it leaks. Here is the shape of the alternative, using apd (the lab's AAuth Agent Provider) as the issuer.

The three roles

apd issues. A single self-hosted binary (~11 MB image) that mints short-lived agent tokens binding an Ed25519 public key to a stable identity like aauth:billing-agent@your-domain, and publishes a JWKS.

The agent proves. Each outbound request carries an RFC 9421 HTTP message signature made with the agent's private key — which never leaves the workload.

The relying party verifies — without calling anyone. Fetch the JWKS (cacheable), check the signature and the token. Stateless: no introspection endpoint, no shared secret, no session store.

Enrollment without secrets

The bootstrapping problem — how does a workload get its first credential? — is solved by federation, not by another secret. A pod proves itself with its Kubernetes service-account token; a CI job with its OIDC token; a VM with its PKI cert; a mesh workload with SPIFFE. apd validates that native proof and issues the agent identity. Nothing to provision, nothing to rotate, nothing to leak in a .env file.

What revocation becomes

Mostly: waiting. Tokens live minutes, so a compromised context expires on its own; hard revocation exists for the exceptional case. Compare the incident-response runbook for a leaked eternal API key, and this is the argument in one line: the best secret is one that stops working before the attacker finishes reading it.

Honest label: apd is a sandbox project tracking a moving IETF draft (currently -09). The pattern, though, is where agent auth is heading — worth adopting the shape even while the spec settles.