AIEGIS ID

AIEGIS Identity

Cryptographic agent passports · Ed25519-signed · Hardware-bound · Human-anchored · W3C VC 2.0

AIEGIS Identity is the cryptographic-identity layer of the AIEGIS harness. Every autonomous AI agent receives an Ed25519-signed W3C Verifiable Credential (VC 2.0), rooted at did:web:aiegis.ie, with hardware-attested principal binding at issuance. The passport binds three things into one cryptographic identity: the AI agent's signing key, the hardware it runs on (TPM 2.0 on Windows/Linux or Apple Secure Enclave on macOS), and the human who controls it (captured via biometric — Face ID, Touch ID, fingerprint via TPM).

Move the agent to a different machine → passport invalid.
Different human at the keyboard → passport invalid.
Tamper with the hardware → passport invalid.

The problem

An agent acting on your behalf signs a contract, moves money, queries a database. Who was it? Who issued it? Who's accountable when it goes wrong?

AIEGIS Identity binds an agent to a real human, on real hardware, attested by a real biometric. We mint the passport, anchor it to the operator's TPM or Secure Enclave, and bind it to the jurisdiction and runtime policy the agent operates under.

The result: every action an agent takes is traceable to a real, accountable identity.

Issue · Verify · Revoke

Issue. POST /api/agent/issue mints an Ed25519-signed passport binding agent → machine fingerprint → biometric-attested human → jurisdiction → policy bundle.

Verify. Any party can verify the signature against the published key. Designed for real-time decisions on customer infrastructure.

Revoke. POST /registry/revoke propagates revocation through the SQLite revocation store. Stale passports fail verification immediately.

How to start

  1. Quick chat. We confirm fit — you're deploying autonomous AI, need accountability, have a hardware root (TPM / Secure Enclave / FIDO2) available.
  2. 30-day pilot. One operator key, up to 10 agent passports. Your infrastructure, our spec.
  3. Contract. By-contact pricing scaled to fleet size. Design-partner contracts before 2026-08-02 lock 24-month pricing.

DID · VC · Ed25519 · JWS

The AIEGIS agent passport is not a proprietary token. It is a stack of standardised primitives, each chosen so that the credential is verifiable by any party with public-key access and so that the cryptographic chain stays defensible to a regulator.

  • W3C Decentralized Identifiers (DIDs). Every agent passport names a DID under the did:web:aiegis.ie method. The DID document carries the agent's public key, the operator binding, and the policy-bundle reference.
  • W3C Verifiable Credentials (VC 2.0). The passport export envelope is a VC. The credential subject is the agent, the issuer is the operator key, and the credential schema names the AIEGIS passport schema by URI. Verifiers can consume the VC with any standards-compliant VC library.
  • Ed25519 signatures. Modern elliptic-curve signature scheme with deterministic signatures, 32-byte public keys, 64-byte signatures. NIST AI Agent Standards Initiative default; composes cleanly with TPM 2.0 and FIDO2 hardware-resident keys.
  • JWS encoding. RFC 7515 (JSON Web Signature) using EdDSA per RFC 8037. Portable, line-noise-safe transport that travels through HTTP headers, message queues, and audit logs without re-encoding hazards.

Hardware root

A cryptographic agent identity is only as strong as the place its private key lives. AIEGIS Identity refuses to issue passports against software-resident keys. Every operator key sits inside a hardware root, and every signature is produced inside that hardware boundary.

  • TPM 2.0 (Windows + Linux). ISO/IEC 11889 — discrete or firmware-resident security chip holding the operator key in a sealed slot. Key generation happens inside the TPM, the private key never leaves the chip, signing is gated by a TPM policy session that requires explicit user presence. Windows 11 ships TPM 2.0 by default; Linux uses tpm2-tss.
  • Apple Secure Enclave (macOS + iOS). Operator key generated inside the Secure Enclave Processor, bound to the device by a hardware UID fused at manufacture. Constraint: SE is P-256 ECDSA only at the hardware layer; AIEGIS Identity handles the curve translation so the published credential still reaches Ed25519. Empirically verified on every Mac enrolment.
  • FIDO2 / WebAuthn. Platform authenticator (Touch ID, Windows Hello, Android biometric) or roaming authenticator (YubiKey 5, Titan key) as portable hardware root. The WebAuthn flow gives biometric attestation in the same step as the signature.

Principal attestation

The hardest property in agent identity is proving that a specific human authorised the agent's enrolment and remains the responsible principal behind every action. AIEGIS Identity does this with a biometric-attested signature at issuance, captured inside the hardware authenticator and bound into the passport as a non-extractable claim.

At issuance, the operator presents a biometric (Touch ID, Windows Hello, FIDO2 biometric) to release the operator key for a single signing operation. The signature itself does not leak the biometric — that stays inside the hardware authenticator — but the act of producing the signature is gated by the biometric check, and the resulting credential carries a User Verification (UV) bit that proves the biometric step happened.

Downstream, every time the agent acts under the passport, the verifier can require the UV bit to be present in the signature chain. Regulators call this "human-anchored autonomous agency" — the agent runs on its own, but every action ladders back to a human who can be named in an audit.

Revocation flow

Revocation is the part of identity most agent-identity schemes get wrong. A passport without a revocation flow is a credential that cannot respond to incident. AIEGIS Identity treats revocation as a first-class capability with three properties: operator-controlled, real-time, registry-propagated.

The operator initiates revocation through /registry/revoke with a biometric-attested call from the original operator key. The revocation record is written to the registry's SQLite store, mirrored to the public revocation list, and timestamped. Verifiers walk the revocation list before returning a positive result, so a revoked passport fails verification immediately on the next call.

Revocation reasons are structured: key compromise, operator request, superseded, cessation of operation, privilege withdrawn. Downstream auditors map AIEGIS revocations onto the conventional PKI revocation taxonomy.

The revocation receipt is itself Ed25519-signed and retained on the operator's infrastructure for five years per EU AI Act Article 12.

Why human-IAM does not work for autonomous agents

OAuth, SAML, and the major cloud IAM systems (AWS IAM, Azure AD, Google Cloud IAM) were designed for humans logging in to systems, with service-account extensions bolted on later. Autonomous AI agents break that model in three ways:

  • The agent acts continuously, not in a session.
  • The agent reasons and chooses its own actions, so the "what is this principal allowed to do" question is not answered by a static permission set.
  • The agent may delegate to other agents, which means accountability has to traverse a delegation chain.

AIEGIS Identity treats the agent as a first-class principal with its own cryptographic identity, bound at issuance to the human operator. Delegation is a signed claim, not a transitively-shared session token. The accountability chain — agent action → agent passport → operator passport → biometric attestation → real human — survives any number of delegation hops, because each hop is itself a signed claim.

OAuth tokens, SAML assertions, and IAM roles can still play a role alongside AIEGIS Identity. The agent might hold an OAuth token to access a specific SaaS API; AIEGIS Identity is the layer above, providing the operator-side accountability that OAuth was never designed to give.

Deployment patterns

  • Single-operator, single-agent. One operator key, one hardware root, one agent passport. Common in early experiments.
  • Single-operator, multi-agent. One operator key issues many child agent passports, each scoped to a distinct capability or jurisdiction. Common for a small team running several agents under one accountable human.
  • Multi-operator, fleet. Federated model — each business unit or jurisdictional entity holds its own operator key, each operator key issues its own agents, and a parent enrolment authority cross-signs the operator keys. Revocation at the agent, operator, or authority level.
  • Cross-organisation delegation. When an agent from organisation A needs to act on behalf of organisation B, the delegation is a signed claim from B's operator key to A's agent passport, with explicit scope and expiry.

POST /api/agent/issue

Mints an Ed25519-signed passport. Called by the operator's enrolment tooling after the biometric-attested key release.

POST /api/agent/issue
{
  "agent_id":     "did:agent:aiegis:my-fleet:scribe-001",
  "operator_id":  "did:web:aiegis.ie",
  "machine_fingerprint": "tpm-spki-sha256-...",
  "biometric_uv": true,
  "jurisdiction": "EU",
  "policy_bundle": "eu-ai-act-26",
  "validity_seconds": 86400
}

Returns the signed VC envelope.

POST /api/agent/verify

Verifies a passport signature, checks the revocation list, and enforces the policy bundle. Designed for real-time decisions in the request path.

POST /api/agent/verify
{ "credential": <VC envelope> }

Returns: {"verified": true|false, "reason_code": "...", "policy_decision": "ALLOW|WARN|BLOCK"}.

POST /registry/revoke

Biometric-attested call from the original operator key. Revokes the passport and propagates to the public revocation list. Stale passports fail subsequent /verify calls.

POST /registry/revoke
{
  "agent_id":       "did:agent:aiegis:my-fleet:scribe-001",
  "reason":         "key_compromise",
  "operator_sig":   "<hex Ed25519 over canonical bytes>"
}

POST /v1/enrol/start

Begins a hardware-attested enrolment. Server returns an enrolment token + a fresh nonce that the installer binds into the TPM quote (qualifyingData) and the biometric signature payload. Defeats captured-quote replay.

POST /v1/enrol/submit

The six enrolment gates fire here. The submission carries: TPM EK certificate + chain (G1), TPM quote with the server nonce (G3), AK signature (G4), platform attestation (G5), biometric envelope (G6), and the legacy declared-machine-fingerprint envelope (G2). Each gate is fail-closed.

GET /registry/pubkey

Returns the current registry-signing public key as PEM. Verifiers pin this for signature checks. Key rotation publishes a new key with a generation counter; old generations remain valid for verification of pre-rotation credentials.

Passport schema

The credential subject names the agent and binds it to operator + machine + biometric + policy. Schema documented under did:web:aiegis.ie + linked from each credential's credentialSchema field.

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://aiegis.ie/contexts/agent-passport-v1"],
  "type": ["VerifiableCredential", "AgentPassport"],
  "issuer": "did:web:aiegis.ie",
  "credentialSubject": {
    "id": "did:agent:aiegis:my-fleet:scribe-001",
    "machineFingerprint": "tpm-spki-sha256-...",
    "operator": "did:web:aiegis.ie",
    "biometric_uv": true,
    "jurisdiction": "EU",
    "policyBundle": "eu-ai-act-26",
    "substrate_tier": "TPM_ROOTED"
  },
  "validFrom": "2026-06-09T...",
  "validUntil": "2026-06-10T...",
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", ... }
}

did:web:aiegis.ie method

W3C-compatible DID method. The DID document for the registry itself lives at https://aiegis.ie/.well-known/did.json. Per-agent DIDs are resolvable via the registry's verification endpoint. The method spec describes key rotation, revocation propagation, and the W3C-conformant resolver behaviour.

KERI pre-rotation

Long-lived agent identities use KERI (Key Event Receipt Infrastructure) pre-rotation. Each key event commits to the digest of the NEXT key — so an attacker who compromises today's key cannot pre-empt tomorrow's rotation. Rotations are witnessed by a 2-of-3 federation quorum and the receipt chain is anchored at /v1/keri/kel/{agent_id}.

Six enrolment gates

Every /v1/enrol/submit request runs through six fail-closed gates server-side:

GateWhat it checks
G1EK chain walks to a pinned vendor root (Infineon, NationZ, etc.)
G2Declared machine fingerprint matches EK SPKI sha256
G3TPM quote signed by AK with server nonce bound in qualifyingData
G4AK signature chains back to the EK
G5Platform attestation (Apple AACA / Windows DeviceID / Linux TPM2 root)
G6Biometric envelope signed by a hardware-resident operator key with UV=true

Standards alignment

AIEGIS Identity tracks emerging standards rather than inventing in isolation:

  • NIST AI RMF — agent identity guidance.
  • OWASP Agentic Apps Top 10 — AAA-01 Identity primary mapping.
  • CSA Agent Top Threats — identity + revocation coverage.
  • EU AI Act Articles 13 and 50 — transparency obligations.
  • W3C VC 2.0 + DID 1.0 — credential + resolver compatibility.
  • IETF ACME draft-acme-device-attest-05 — device-attested certificate issuance.
  • IETF SCITT SCRAPI-10 + architecture-22 — supply chain integrity transparency receipts.
  • IETF WIMSE WPT — workload identity in multi-tenant environments.
  • IETF RATS AR4SI — remote attestation results for secure interactions.
  • W3C Bitstring Status List v1.0 — revocation list format.

EU AI Act Articles 13 & 50

Articles 13 (transparency obligations) and 50 (transparency to natural persons) become enforceable on 2026-08-02 for new high-risk deployments. AIEGIS Identity contributes the agent-identity primitives to both: a verifiable credential proving who is acting, an audit chain proving who authorised the action, and a revocation surface that responds to incident in real time.

Penalties for non-compliance reach 7% of global revenue.

OWASP AIVSS Issue #32

AIEGIS holds active co-author engagement on AIVSS Issue #32 (Multi-Agent Governance). Issue #32 covers the trust roster, cross-organisation delegation, and the audit-pack signing primitives that AIEGIS Identity contributes upstream.

Enrol on Windows / Linux (TPM 2.0)

  1. Install the AIEGIS enrolment tool: Windows MSI or Linux DEB/RPM.
  2. Run aiegis-enrol start. The tool calls POST /v1/enrol/start, receives an enrolment token + server nonce.
  3. The tool produces a TPM quote with the server nonce bound into qualifyingData, plus the EK certificate + chain.
  4. Operator unlocks the AK with biometric (Windows Hello or FIDO2). Tool packages G1–G6 evidence and calls POST /v1/enrol/submit.
  5. On success, the registry returns the signed agent passport. The tool writes it to %PROGRAMDATA%\aiegis\agent.vc (Windows) or /var/lib/aiegis/agent.vc (Linux).

Enrol on macOS (Apple Secure Enclave)

  1. Install the notarised PKG.
  2. aiegis-enrol start → server returns token + nonce.
  3. Tool produces an Apple App Attest assertion + a Secure-Enclave-signed session binding over sha256("aegis-macos-g2-session-binding\0" || token || nonce || pubkey_spki). UV=true required.
  4. Tool submits via POST /v1/enrol/submit with the AACA chain (G5) and the SE session-binding proof.
  5. On success, the agent VC lands at ~/Library/Application Support/aiegis/agent.vc.

Enrol with FIDO2 authenticator

  1. Plug in YubiKey 5 / Titan key or use a platform authenticator (Touch ID, Windows Hello).
  2. WebAuthn ceremony at https://aiegis.ie/enrol — the browser triggers the biometric and produces a credential with UV=true.
  3. The WebAuthn attestation feeds gate G6 of the enrolment submit.

Rotate operator keys

KERI pre-rotation is the canonical path for long-lived agent identities. For operator keys, rotation is a signed event from the current key committing to the digest of the next key. Witnessed by 2-of-3 federation quorum; the receipt anchors the rotation in the public KEL.

POST /v1/keri/rotate — fail-closed unless the request comes from the current key with a 2-of-3 quorum present and the new-next-key-digest matches the pre-committed value from the last event.

Frequently asked questions about AI identity

What is an agent passport?

An agent passport is a cryptographic credential that names an autonomous AI agent, binds it to a real human operator on real hardware, and references the policy bundle the agent operates under. The AIEGIS agent passport is Ed25519-signed, W3C VC-compatible, and resolvable as a did:web:aiegis.ie DID.

What is AI identity?

AI identity is the cryptographic, hardware-anchored layer that makes an autonomous AI agent verifiable, accountable, and revocable. It answers "who is this agent, who is responsible for it, and what is it allowed to do" with a signed credential rather than a contractual claim.

How is an agent passport different from an API key?

An API key is a shared secret with no built-in accountability and no real revocation surface beyond rotation. An agent passport is a signed credential with a named operator, a hardware-anchored signing key, a biometric attestation at issuance, and a structured revocation flow.

Does AIEGIS Identity require a TPM?

Hardware-rooted keys are required for issuance. On Windows and Linux that is typically TPM 2.0; on macOS it is the Secure Enclave; on portable enrolments a FIDO2 platform or roaming authenticator works. Software-only key storage is refused.

How is the passport revoked?

Through /registry/revoke with a biometric-attested call from the original operator key. The revocation record propagates to the public revocation list and verifiers walk that list on every verify call, so a revoked passport fails verification immediately.

Is the passport compatible with W3C Verifiable Credentials?

Yes. The passport export envelope is a W3C VC 2.0. Verifiers can use any standards-compliant VC library to consume the credential; AIEGIS-specific tooling is not required.

What is the did:web:aiegis.ie DID method?

A W3C-compatible DID method describing how AIEGIS-issued DIDs resolve to DID documents, how keys rotate, and how revocation propagates. The method document lives at https://aiegis.ie/.well-known/did.json.

Does the passport carry biometric data?

No. The biometric stays inside the hardware authenticator. The passport carries the User Verification (UV) bit proving that the biometric check happened, but no biometric template ever leaves the device.

How does the passport differ from OAuth or SAML?

OAuth and SAML were designed for humans logging in. The agent passport names the agent as a first-class principal, binds it cryptographically to a human operator, and supports signed delegation chains rather than transitive token sharing.

How long is a passport valid?

Configurable per deployment, with periodic biometric re-attestation for long-lived passports. Substrate-tier-keyed ceilings: software=24h, tpm=7d, apple-se=47d.

Can passports be issued offline?

Issuance requires the hardware root and the biometric, both of which work offline. Registry publication and revocation propagation require connectivity, so a fully-offline enrolment is possible but the credential becomes verifiable to third parties only once the registry update lands.