Agent identity

Creating an agent DID

Agent DIDs are registered through HermesVault at vault.hermesbridge.ai. Each DID is a persistent, resolvable identifier of the form did:hermes:0x<hex>, where the hex suffix is derived from the agent's initial public key and is content-addressed to prevent collisions.

Registration requires a valid HermesVault account (any attestation tier), a public key in a supported format, and a capability declaration specifying which HermesBridge operations the agent is authorized to request. The DID document is stored in HermesVault and resolved by HermesBridge edge nodes at verification time.

A DID persists independently of key rotations, provider changes, and SDK upgrades. It is the stable identity anchor for the agent across its operational lifetime.

Key formats

Three key formats are supported. Ed25519 is the default for new registrations. Keys are stored in HermesVault and referenced by key ID in signing operations.

# Ed25519 — default for new registrations
# Compact, fast, strong (128-bit security)

# Generate via HermesVault CLI
hermesbridge vault keygen \
  --did did:hermes:0x7a3f9b2e4c1d8a6f \
  --algorithm ed25519 \
  --key-id primary \
  --output keys/primary.jwk

# Or ECDSA P-256 for environments requiring NIST curves
hermesbridge vault keygen \
  --algorithm p256 \
  --key-id primary

# Or RSA-PSS 4096 for regulated environments
hermesbridge vault keygen \
  --algorithm rsa-pss-4096 \
  --key-id primary

Signing payload structure

The signing payload is a JSON object serialized canonically (RFC 8785 JSON Canonicalization Scheme) before signing. The body_sha256 field commits the signature to the exact request body, preventing request body substitution. The nonce prevents replay within the 5-minute timestamp window.

{
  "request_id": "01J8XMVK2P4Q7R9STWYZ3ABCDE",
  "timestamp": "2026-05-19T12:00:00Z",
  "method": "POST",
  "path": "/v1/chat/completions",
  "body_sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "agent_did": "did:hermes:0x7a3f9b2e4c1d8a6f",
  "key_id": "primary",
  "attestation_tier": "runtime-signed",
  "capabilities": ["chat.completions"],
  "nonce": "c7d4e9f2a1b8"
}

Revocation and rotation

Revocation targets a specific DID, not a shared secret. Revoking a compromised agent does not affect other agents, even those sharing an orchestrator. Revocation takes effect within 30 seconds across all HermesBridge edge nodes.

Key rotation preserves the DID. The agent registers a new public key in HermesVault under a new key ID, then updates its signing configuration to reference the new key ID. The previous key ID can be retired with a grace period to allow in-flight requests to complete. Historical usage logs remain attributed to the DID regardless of key rotation.

Emergency revocation (compromise suspected) is immediate with no grace period. Post-compromise, the agent must re-register with a new key material before it can make further requests.

Cross-agent delegation chains

An orchestrator agent can grant a sub-agent scoped, time-bounded authority to make requests on its behalf. The delegation record is signed by the delegator and included in the sub-agent's request JWT. HermesBridge verifies the entire chain before routing. Delegation scope cannot exceed the delegator's own capability set.

{
  "delegation": {
    "delegator": "did:hermes:0xorchestr8r4a2f",
    "delegate": "did:hermes:0xsubagent1b3c9",
    "scope": ["chat.completions"],
    "cost_ceiling_usd": 1.00,
    "not_before": "2026-05-19T00:00:00Z",
    "not_after": "2026-05-19T23:59:59Z",
    "revocable": true
  },
  "signature": "base64url(Ed25519Signature)",
  "issuer_key_id": "primary"
}

Delegation chains are logged separately from direct-agent requests. Audit logs show both the delegating DID and the acting DID for every request made under delegation. Revocation of the delegator cascades immediately to all active delegations.