Hermes Agent Security & GDPR: A UK Business Guide (2026)

A self-hosted AI agent with broad access to your systems is a compliance landmine. The same agent with a properly scoped toolset, network egress allowlist, audit logging, and a documented DPIA is a defensible part of your stack — even for FCA-regulated firms, NHS suppliers, and law firms handling sensitive client data. This guide covers the Hermes Agent security posture that makes the difference. Most of this work is done once at install time and then maintained — it is not ongoing toil.

Last updated: May 2026 · Covers Hermes Agent v0.13 security model + UK GDPR + PECR posture · Based on production hardening patterns from Ampliflow client deployments

• Hermes Agent itself is not GDPR-compliant or non-compliant — your deployment configuration is
• Five hardening layers turn a default install into a defensible deployment: toolset lockdown, scoped file access, network egress allowlist, audit logging, model-provider data residency
• For FCA / NHS / legal work, the model provider matters more than the agent: route through Bedrock (AWS eu-west-2) or Vertex AI (London) for UK data residency
• A 2-page DPIA covers most Hermes deployments; the template is at the end of this guide
• Self-hosting is a compliance advantage, not a burden — you control where data goes, who has access, and what gets logged

The four-layer security model

Hermes Agent security is a stack. Each layer mitigates a specific risk.

The default Hermes install is permissive (no toolset lockdown, broad file access, open network egress). For development on a developer's laptop with no real data, that's fine. For production with any business data, the five layers above become non-negotiable.

Layer 1 — Toolset lockdown

The single most important security control. A default Hermes install has shell execution, file write, browser automation, and a handful of other capabilities all enabled. Most production deployments need three or four of those, not all of them.

Edit ~/.hermes/config.yaml:

`yaml tools: enabled:

• web_fetch
• file_read
• whatsapp_send
• cron
• skills

disabled:

• shell_exec # Disable until a specific use case requires it
• file_write # Re-enable explicitly per scoped path
• browser_automation
• sudo

`

The principle: enable nothing by default, add tools as use cases require them, scope each tool as narrowly as possible.

`shell_exec` is the highest-risk tool. If an attacker tricks the agent into running shell commands (via prompt injection from a hostile WhatsApp message, an MCP server response, or a compromised tool), you have arbitrary code execution as the user running Hermes. For most UK SME deployments, the right answer is to disable shell_exec entirely and wrap any specific shell needs inside a skill with a narrow interface.

A skill that runs git status and reports back is safe. The same agent with raw shell_exec is not.

Layer 2 — Scoped file access

The second-largest risk vector after shell access. A default install lets the agent read and write anywhere the running user can. A non-root user with sudo access can still read /etc/, write to ~/, and access the shell history of every other user on the same box.

Scope file access explicitly:

`yaml tools: file_read: enabled: true allowed_paths:

• /home/ubuntu/hermes-data/
• /home/ubuntu/hermes-skills/
• /tmp/hermes-scratch/

forbidden_paths:

• ~/.ssh/
• ~/.hermes/config.yaml
• ~/.aws/
• /etc/

file_write: enabled: true allowed_paths:

• /home/ubuntu/hermes-outputs/
• /tmp/hermes-scratch/

forbidden_paths:

• ~/.ssh/
• ~/.hermes/config.yaml
• /etc/

`

Combine with operating-system-level controls: run Hermes as a dedicated non-privileged user (hermes, not ubuntu), set the home directory permissions to 750, never share the box with other workloads.

For higher-risk deployments (financial services, healthcare), wrap Hermes in a container with a read-only root filesystem and only the necessary directories mounted as writable. Adds operational complexity but reduces blast radius.

Layer 3 — Network egress allowlist

The defence that matters when the other layers fail. Even if an attacker gets shell or file-write access, they need somewhere to send the data they exfiltrate. A network egress allowlist removes that destination.

The hosts Hermes legitimately needs:

Implement via:

• Oracle Cloud: Network Security List with explicit egress rules to the allowlist
• AWS / GCP: Security Group + VPC Flow Logs
• Hetzner / DigitalOcean: ufw on the server itself, or Cloudflare Tunnel as an outbound proxy

A simple ufw config on Ubuntu:

`bash sudo ufw default deny outgoing sudo ufw allow out 53 # DNS sudo ufw allow out 22 # SSH (for outbound git etc.) sudo ufw allow out 443 to api.anthropic.com

sudo ufw enable `

Cloudflare Tunnel adds another layer — you can require all outbound traffic to go through Cloudflare's edge with WAF rules + bot protection.

For most UK SME deployments, the OS-level firewall is enough. For regulated environments, add a network appliance (Zscaler, Palo Alto, etc.) and route through a corporate egress proxy.

Layer 4 — Audit logging

Required for FCA, NHS, legal. Useful for everyone. Hermes' default logging is operational (errors, restarts, gateway state). For audit purposes you need more: every prompt the agent receives, every tool call the agent makes, every output the agent produces, with timestamps + user attribution.

Configure in ~/.hermes/config.yaml:

`yaml logging: audit: enabled: true path: /home/ubuntu/hermes-audit/ rotate: daily retain_days: 365 # 7 years for FCA-regulated firms events:

• prompt_received
• tool_called
• response_sent
• skill_invoked
• permission_check
• error

`

Then ship the logs somewhere immutable — your SIEM, an S3 bucket with versioning + object-lock, or at minimum a write-only directory on a separate server. The point is that an attacker who compromises the Hermes server cannot silently delete the audit trail.

For FCA-regulated firms, the FCA's SYSC requirements on systems and controls apply — your auditor will want to see the logs cover at least 7 years of retention with integrity protection.

Layer 5 — Model-provider data residency

The DPO question for any UK deployment touching personal data. When Hermes sends a prompt to a model provider, that prompt becomes a data processing event. The provider's data-handling terms determine your compliance posture.

For UK businesses processing personal data (customer PII, employee records, financial data, health information), the options:

For most UK SMEs, the cleanest path is Hermes on Oracle Cloud Free Tier (UK region) → Anthropic via AWS Bedrock (eu-west-2 London). That keeps the agent + the model + the data all in UK data centres with proper DPAs in place.

The model-provider routing is configured in Hermes via the model-provider plugin you choose. For Bedrock specifically:

`yaml model: provider: bedrock region: eu-west-2 default_model: anthropic.claude-sonnet-4-6:0 fallback: anthropic.claude-haiku-4-5:0 `

You'll need an AWS account with Bedrock access enabled in eu-west-2 + a properly-scoped IAM role for the Hermes process. AWS bills per million tokens at standard API rates.

DPIA — what to write

For UK deployments processing personal data, a Data Protection Impact Assessment is required by Article 35 of UK GDPR. A 2-page DPIA covers most Hermes setups. The template:

1. Description of the processing

• What does Hermes do (specific use cases, not "AI assistant")
• What personal data does it process (categories: contact details, transaction history, support conversations, etc.)
• Where does the data come from (your CRM, your email, your WhatsApp, etc.)
• Where does it go (model provider, output channels, audit logs)

2. Necessity and proportionality

• Why is each category of data needed for the purpose
• Could the purpose be achieved with less data
• Are you using the minimum data necessary

3. Risks identified

• Confidentiality (data exposed to model provider)
• Integrity (agent modifies data incorrectly)
• Availability (agent goes down at critical moment)
• Re-identification (synthesised outputs reveal individuals)
• Bias (agent behaviour differs by protected characteristic)

4. Mitigations in place

• Toolset lockdown (above)
• Scoped file access (above)
• Network egress allowlist (above)
• Audit logging (above)
• Model-provider data residency (above)
• Human-in-loop approval for sensitive actions
• Regular review of agent decisions for drift/bias

5. Residual risk and acceptance

• What risk remains after mitigations
• Who is the risk owner
• When will this DPIA be reviewed

For most Hermes deployments at UK SME scale, the residual risk after the five mitigations is low and acceptable. For higher-stakes deployments (clinical decisions, lending decisions, HR decisions), the DPIA gets longer and may require ICO consultation under Article 36.

The full Hermes use cases — and which ones require a DPIA vs which don't — are covered in our Hermes Agent use cases guide.

PECR — when does it apply

PECR governs electronic marketing communications. If Hermes is sending WhatsApp / email / SMS messages to your customers, PECR applies on top of GDPR.

The relevant rules:

• Soft opt-in under PECR (Reg 22) covers marketing to existing customers about similar products, with opt-out at collection + every message
• Consent is required for prospective customers (cold outreach) — and PECR's consent definition is the GDPR definition (freely given, specific, informed, unambiguous)
• B2B exemptions apply to messages sent to corporate subscribers (a company's info@ email, not an individual employee's personal email)

For Hermes use cases that send messages on your behalf — daily ops briefs to YOU don't trigger PECR; reactivation messages to YOUR CUSTOMERS do — design the workflow with explicit human approval before any external send.

The deeper PECR posture for cold outreach specifically is in our is cold email legal in the UK guide.

Frequently asked questions

Is Hermes Agent itself GDPR-compliant?

Hermes Agent the software is neither compliant nor non-compliant — the question doesn't apply at the framework level. Compliance depends on your deployment configuration, your model-provider routing, your data-flow design, and your governance processes. The five hardening layers in this guide make a defensible deployment.

Can I deploy Hermes for FCA-regulated work?

Yes, with appropriate hardening. The minimum viable posture: toolset lockdown + scoped file access + network egress allowlist + audit logging + model provider via AWS Bedrock eu-west-2 with the AWS DPA in place. Plus a written DPIA. Plus regular reviews of agent outputs. The FCA's Operational Resilience requirements (PS21/3) also apply — document the recovery procedures from our Hermes deployment guide.

What about NHS Data Security and Protection Toolkit (DSPT)?

NHS suppliers must complete the DSPT annually. A Hermes deployment with the five hardening layers + model-provider routing through AWS Bedrock UK + audit logging meets the relevant DSPT controls (data flow mapping, access controls, incident response, supplier management). The DSPT specifically asks about "AI/ML systems used to process patient data" — Hermes deployed with the patterns above satisfies that question.

Should we encrypt the Hermes data directory at rest?

Yes for any deployment touching personal data. On Oracle Cloud, Block Volume encryption is on by default. On a self-managed server, use LUKS on the data partition or cryptsetup. The performance overhead is negligible for Hermes' I/O profile.

Does Hermes' memory feature have GDPR implications?

Yes — Hermes' persistent memory stores fragments of past interactions. If those interactions contained personal data, the memory store contains personal data. Subject Access Requests (SARs) and erasure requests apply: you need a way to find all data about an individual in the memory store and delete it on request. Worth designing the memory schema with this in mind from day one.

How often should we review the Hermes security configuration?

Quarterly is reasonable for non-regulated workloads. Monthly for regulated work. Re-review after any material change to the use cases, the toolset, or the model provider. Annual penetration testing is recommended for regulated deployments.

Does Hermes support encrypted communications with model providers?

Yes — all model-provider APIs (Anthropic, OpenAI, Bedrock, Vertex AI, Z.AI, etc.) require HTTPS. Hermes uses the standard Python SSL stack which validates certificates by default. Don't disable certificate validation under any circumstances.

What happens if the model provider has a data breach?

Your business is the data controller; the model provider is the data processor. Under GDPR Article 33, you must notify the ICO within 72 hours if the breach affects UK personal data + notify affected individuals if there's high risk. The provider DPA defines who is responsible for what notifications. Build a list of which agents send what data to which providers — when a breach happens, you need to know what was at risk in 72 hours, not 72 days.

Related reading

• ↑ How to Deploy Hermes Agent — UK Business Complete Guide — the foundational deployment pillar
• ↔ Hermes Agent on Oracle Cloud Free Tier — UK Guide — the underlying server platform
• ↔ Hermes Agent Monitoring, Uptime & Reliability in Production — the operational posture that complements the security posture
• ↔ GDPR-Compliant Database Reactivation — for the marketing-side of the GDPR + PECR conversation
• ↔ Is Cold Email Legal in the UK? — for outbound message PECR rules

What should you do next?

The hardening patterns above are the difference between a Hermes deployment your DPO blocks and one your DPO signs off on the same week. Most of the work is configuration + documentation, not engineering.

See how Ampliflow uses Hermes-style agents in client work →

Or to scope your specific compliance posture — DPIA template, audit log routing, AWS Bedrock setup — book a free Hermes deployment review.

Book a free Hermes deployment review →