HermesBridge Request Signing Protocol — v0.1 (Draft)

1. Introduction

Existing LLM gateway authentication models rely on static bearer tokens that identify a billing account but not the entity making the request. This model is insufficient for autonomous agent deployments, where individual agents *must* be independently identifiable, revocable, and auditable.

HBRSP specifies a per-request signature scheme in which each request carries a signed attestation of the agent's identity. The signature is verified against key material resolved from a DID registered in HermesVault. Requests without a valid signature are rejected before any routing occurs.

2. Terminology

Agent

An autonomous software process that makes requests to HermesBridge on behalf of an operator or another agent. An agent is not a human user.

DID

Decentralized Identifier. A persistent, resolvable identifier of the form did:hermes:<hex>, registered in HermesVault and controlled by the agent operator.

Attestation

Evidence of the agent identity verification mechanism: self-attested, runtime-signed, or TEE-verified. Attestation tier determines pricing and access scope.

Bridge

The HermesBridge gateway. The system described in this specification.

The key words must, should, and may in this document are to be interpreted as described in RFC 2119 when they appear in lowercase italics.

3. Authentication flow

The authentication flow proceeds as follows:

1. The agent constructs the request body and computes its SHA-256 hash.
2. The agent constructs the signing payload (Section 4) and serializes it canonically.
3. The agent signs the serialized payload with its bound private key.
4. The agent attaches the signature in the X-Hermes-Signature header.
5. HermesBridge receives the request and extracts the agent DID from the signature header.
6. HermesBridge resolves the DID document from HermesVault and retrieves the key material for the specified key ID.
7. HermesBridge verifies the signature. If verification fails, the request is rejected with SIGNATURE_INVALID.
8. HermesBridge checks the timestamp and nonce for replay prevention.
9. HermesBridge evaluates the agent's capability claims against the requested operation.
10. If all checks pass, the request is routed to the appropriate provider.

4. Signature construction

The signing payload is a JSON object containing the fields specified in Section 2.3 of the identity specification. The payload *must* be serialized using RFC 8785 JSON Canonicalization Scheme (JCS) before signing to ensure deterministic byte representation.

The X-Hermes-Signature header *must* take the form: v1.<base64url(payload)>.<base64url(signature)>

# Signature construction — Ed25519 example

import json, hashlib, base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

def build_signing_payload(method, path, body_bytes, agent_did, key_id, nonce, timestamp):
    payload = {
        "request_id": generate_ulid(),
        "timestamp": timestamp,          # ISO 8601, UTC
        "method": method.upper(),
        "path": path,
        "body_sha256": hashlib.sha256(body_bytes).hexdigest(),
        "agent_did": agent_did,
        "key_id": key_id,
        "nonce": nonce,                  # 12 random bytes, hex-encoded
    }
    # Canonical JSON serialization (RFC 8785)
    return json.dumps(payload, sort_keys=True, separators=(',', ':')).encode()

def sign_request(private_key: Ed25519PrivateKey, payload_bytes: bytes) -> str:
    signature = private_key.sign(payload_bytes)
    return base64.urlsafe_b64encode(signature).rstrip(b'=').decode()

# Attach to request header:
# X-Hermes-Signature: v1.<base64url(signing_payload)>.<base64url(signature)>

5. Verification rules

HermesBridge *must* reject any request that does not satisfy all of the following conditions:

1. The X-Hermes-Signature header is present and parses according to the v1 format.
2. The agent DID in the payload resolves to a valid, non-revoked DID document in HermesVault.
3. The key ID in the payload matches an active key in the resolved DID document.
4. The signature verifies against the serialized payload using the resolved public key.
5. The timestamp in the payload is within 5 minutes of the Bridge's current UTC time.
6. The nonce has not been seen from this DID within the timestamp window.
7. The body_sha256 in the payload matches the SHA-256 of the received request body.
8. The agent's capability claims include the requested operation.

Implementations *should* short-circuit at the first failure to minimize response latency for invalid requests. Implementations *may* include additional metadata in error responses to aid debugging.

6. Error codes

Authentication errors are returned as JSON with a top-level error object.

{
  "error": {
    "code": "SIGNATURE_INVALID",
    "message": "Request signature failed verification against DID key material.",
    "did": "did:hermes:0x7a3f9b2e4c1d8a6f",
    "key_id": "primary",
    "timestamp_received": "2026-05-19T12:00:05Z"
  }
}

7. Security considerations

Key material storage. Private keys *must* not be embedded in source code, environment variables, or configuration files accessible to untrusted processes. Keys *should* be stored in hardware security modules or TEE-backed key stores where deployment architecture permits.

Nonce generation. Nonces *must* be generated using a cryptographically secure random number generator. Sequential or time-derived nonces are not acceptable. A minimum of 96 bits (12 bytes) of entropy is required.

Transport security. All requests to HermesBridge *must* use TLS 1.3 or later. The signature scheme provides message integrity but does not replace transport encryption.

Delegation scope. Delegating agents *should* apply the principle of least privilege when constructing delegation records. Delegation scope *must not* exceed the delegator's own capability set. Delegation records *should* carry the shortest feasible expiry consistent with operational requirements.

Prompt injection. Agent identity does not protect against prompt injection attacks in content processed by the agent. Operators *must* treat all external content as untrusted input. Agent capability claims limit the blast radius of a compromised agent but do not prevent the agent from being manipulated into acting within its authorized scope.

8. References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC7515]

Jones, M. et al., "JSON Web Signature (JWS)", RFC 7515, May 2015.

[RFC7519]

Jones, M. et al., "JSON Web Token (JWT)", RFC 7519, May 2015.

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curves for JOSE", RFC 8037, January 2017.

[RFC8785]

Rundgren, A. et al., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020.

[DID-CORE]

W3C, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022.