Architecture

How HermesBridge verifies, routes, and audits agent requests.

1. Request flow

HermesBridge request flow: Agent signs request, routed through edge, auth verification, router, cache check, provider API, then response returned with usage log

Every request originates from an agent that has a DID registered in HermesVault. The agent signs the request body and a timestamp with its bound key before transmitting. The HermesBridge edge node receives the request, verifies the signature against the resolved DID document, checks capability claims, then routes to the appropriate provider. Cache hits skip the provider API entirely and return in under 20ms. Every request — hit or miss — produces an immutable usage log entry attributable to the specific agent DID.

2. Identity binding

Agent identity is carried in a signed JWT attached to every request via theX-Hermes-Signature header. The JWT payload includes standard claims plus HermesBridge-specific extensions. The cnf (key confirmation) claim binds the signing key to the token, and the agent_did claim is the resolvable identifier used for audit attribution.

{
  "iss": "did:hermes:0x7a3f9b2e4c1d8a6f",
  "sub": "did:hermes:0x7a3f9b2e4c1d8a6f",
  "aud": "https://api.hermesbridge.ai",
  "iat": 1748952000,
  "exp": 1748952300,
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
    }
  },
  "agent_did": "did:hermes:0x7a3f9b2e4c1d8a6f",
  "attestation_tier": "runtime-signed",
  "runtime": "langchain/0.3.7",
  "capabilities": ["chat.completions", "embeddings"],
  "jti": "01J8XMVK2P4Q7R9STWYZ3ABCDE"
}

3. Attestation tiers

TierVerificationDiscountRequired for
self-attestedAgent declares identity—Development, testing
runtime-signedKnown framework signs agent15%Production agents
TEE-verifiedConfidential compute attestation30%Regulated workloads

4. Supported providers

Last updated: 2026-05-19. Provider list is reviewed weekly.

Anthropic
OpenAI
Google
Mistral
xAI
Alibaba (Qwen)
DeepSeek
Moonshot (Kimi)
Xiaomi (MiMo)
Cohere
Together-hosted open models

5. Routing modes

The model field in a completion request accepts any of the following values. Routing constraints (cost ceiling, latency target) can be passed in the routing object.

enum RoutingMode {
  // Route to a specific model by exact identifier
  ExplicitModelId = "claude-opus-4",

  // Gateway selects optimal model for the request
  Auto = "auto",

  // Route to the lowest-cost model meeting capability requirements
  Cheapest = "cheapest",

  // Route to the model with lowest current latency
  Fastest = "fastest",

  // Balance cost and latency (default for auto)
  Balanced = "balanced",

  // Route to model with specific named capability
  Capability = "capability:<capability_name>",
  // Examples:
  //   "capability:code-generation"
  //   "capability:long-context"
  //   "capability:tool-use"
  //   "capability:vision"
  //   "capability:reasoning"
}