How does Hermes Haven protect access to a Hermes Agent?
Hermes Haven puts an HTTPS gateway in front of hosted agents. nginx terminates TLS and routes inbound traffic to the appropriate agent rather than presenting the agent through a raw public IP. The audited configuration enables TLS 1.2 and TLS 1.3; it does not enforce TLS 1.3 exclusively. [C05][C22]
Agent dashboard sign-in uses an OIDC identity provider operated by HermesHaven. The default account flow enforces 2FA, although the implementation contains a configuration toggle that must remain enabled for the “2FA on every account” statement to stay true. [C09][C17]
Are hosted agents isolated from one another?
Each agent receives a separate Docker overlay network. The evidence supports the statement that agents cannot communicate directly with one another. It does not support the broader phrases “zero cross-traffic” or “no internet access”: shared platform services exist, and agents have outbound connectivity. [C06][C07]
| Control or limitation | Publishable statement | Evidence status |
|---|---|---|
| Inbound gateway | Inbound traffic is routed through the platform HTTPS gateway. | Verified [C22] |
| Per-agent networking | Agents cannot communicate directly with one another. | Qualified [C06] |
| Outbound access | Agents can reach the internet for tools and external providers. | Verified limitation [C07] |
| Dashboard identity | HermesHaven operates the OIDC provider used by agent dashboards. | Verified [C17] |
| Account 2FA | Enforced in the default flow; production configuration must be checked. | Verified with note [C09] |
| Non-root runtime | Not verified from the upstream Hermes Agent image in the audit. | Not demonstrated [C08] |
Is agent data encrypted?
Traffic through the public gateway supports TLS 1.2 and TLS 1.3. The audit found no evidence of disk-level encryption for agent persistent volumes and no implementation supporting claims of AES-256 at rest or envelope encryption. Agent files on the audited RBD/ext4 storage must therefore not be described as encrypted at rest. [C05]
Where is data stored and processed?
The audited storage layer uses persistent Ceph/RBD volumes with storage-layer redundancy. That is a durability architecture statement, not an encryption or compliance statement. [C25]
Inference is a separate path. Premium models and user-configured providers may process requests outside the EU, so “no data leaves the EU” is false. The provider selected for a model determines where that inference request may be processed. [C03]
Read the routing explanation on Models.
Does the architecture prove GDPR compliance?
No. The audit found no privacy policy, processing records, processor contract or other legal documentation sufficient to establish GDPR compliance. Architecture can document controls and data flows; it cannot by itself establish a legal compliance conclusion. [C01]
Which security claims should not be used?
Do not publish these claims under the current evidence:
- “AES-256 at rest” or “envelope-encrypted”. [C05]
- “No data leaves the EU”. [C03]
- “No internet access”. [C07]
- “Zero escape vectors”. [C08]
- “GDPR compliant by design”. [C01]
- “All infrastructure is in Grenoble”. [C02]
For the managed operational context, see Platform. To compare responsibilities with a VPS, see Compare self-hosting and VPS.
What should a security reviewer request?
Ask for the current network diagram, provider data-flow inventory, backup policy, restore evidence, access-control configuration, secret-handling design and encryption roadmap. Availability targets, recovery objectives and legal compliance must come from reviewed documents.