The missing primitive of the autonomous-agent era. Hardware-bound. Principal-attested. EU-sovereign.
The phrase AI identity showed up in vendor decks before it meant anything. It was a synonym for "user account" in the early generative-AI products, then a synonym for "service account" in the early LLM-platform APIs. Neither captures the real shape of the problem. An autonomous AI agent acts on behalf of a principal — a human, an organisation, sometimes another agent. The relying party needs to know who is calling, who authorised the call, what hardware the agent runs on, and whether the authorisation has been revoked. That is AI identity. Anything less is a username string.
Single sign-on, OAuth, and service-account API keys were designed for a different problem. They authenticate a human in front of a tab, or a process calling a microservice. None of them carry the principal attestation an agent needs to transact under governance:
The thing AI identity needs is a portable, hardware-bound, revocable, principal-attested identifier that is verifiable offline. That is the agent passport.
| Field | Purpose |
|---|---|
| DID (did:key or did:web) | Globally unique identifier, controlled by the agent's signing key, resolvable without a central registry |
| Principal reference | The human or organisation the agent acts for, signed by the principal at issuance |
| Hardware attestation | TPM 2.0 quote on Windows/Linux, Apple Secure Enclave attestation on macOS, FIDO2 biometric on issuance |
| Issuance epoch | Wall-clock time of issuance, signed; used to detect post-revocation activity downstream |
| Capability claims | What the principal authorised the agent to do, scoped by rule pack (EU AI Act, GDPR, NIST RMF, MGAIF, POPIA) |
| Revocation pointer | URL of the public revocation list the relying party must check |
| Signing key | Ed25519 (RFC 8032), held in hardware, never exported |
The passport is encoded as a W3C Verifiable Credential and the runtime bearer form is a JWS (RFC 7515) with EdDSA (RFC 8037). Relying parties verify offline against the public key published at /.well-known/aegis-evidence-pubkey.pem and the JWKS at /grid/.well-known/jwks.json.
If the private key sits in a file, anyone who can read the file is the agent. That is the entire history of stolen-credential incidents in cloud security; importing the same failure mode into the AI-agent era would be a choice. AiEGIS Identity binds the signing key to:
The signing key is generated inside the hardware element and never leaves it. The agent process can request signatures; it cannot extract the key. Lose the device and the agent goes with it. Steal the key and you get nothing.
Identity systems that cannot revoke are bookkeeping; they describe a state that may or may not be current. AiEGIS Identity publishes a public revocation list per organisation at /.well-known/aegis-agent-revocation/{org}/. The list is signed. Relying parties cache it with a short TTL and check on each call. Revocation latency is the cache TTL, not a quarterly directory sync.
Receipts produced after a revocation event are still verifiable as signatures but are flagged as post-revocation by any auditor with the revocation list and the receipt's issuance epoch. The receipt format includes both fields by design.
The EU AI Act, in force since 2024, requires deployers of high-risk AI systems to keep automatically-generated logs and to ensure the system is used in accordance with instructions. The deployer obligation is unmet if the deployer cannot prove which agent acted when and who authorised it. An EU-hosted, EU-issued AI identity stack removes the cross-border transfer question entirely: the issuance, the revocation list, and the verifier all live inside the EEA. The full Article 26 deployer-obligation mapping is at /article-26-walkthrough.
/api/protect as the X-AEGIS-Tag header, which means the identity layer composes with the 15-layer governance stack without a second issuance step.If you're evaluating AI identity for a deployment: read /identity for the product surface, /what-is-passport for the explainer, /blog/agent-passport-did-key-explained for the DID:key path, and /governance for how the passport composes with the rule packs. Issue request: /identity.