AI Agents20 April 2026Updated 6 September 20268 min read

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

Two-colour linocut in black and ochre: a young South Asian British woman with shoulder-length hair, in a plain top, turns a key to lock a tall steel filing cabinet in a bare office while a ring of keys hangs from her other hand, lit from one side. — Editorial illustration.

Hermes Agent is not GDPR-compliant by default, and it is not non-compliant by default. The deployment decides. A self-hosted agent can be a defensible part of a UK business system when its tools, data sources, model route, logs, retention and approvals are scoped. The same agent with broad shell access, unbounded file access and customer data in prompts is a liability.

This guide is a practical security and UK GDPR checklist for Hermes deployments. It does not replace legal advice or the ICO's AI guidance. It gives the technical and operational controls a UK business should have in place before Hermes touches personal data or live customer workflows.

Last updated: 6 September 2026. Refreshed against current Hermes install/service/update behaviour and ICO AI guidance.

TL;DR:

Treat Hermes as part of your processing environment, not as a compliance product.
Start read-only, with narrow tools and a named owner.
Use a dedicated service user, scoped file paths, limited network egress and a managed gateway service.
Log enough to investigate prompts, tool calls, outputs and approval decisions, but set retention from the actual data and legal purpose.
Use hermes backup/hermes import and tested restore drills as security controls, not just convenience features.

For install details, use How to Deploy Hermes Agent. For live recovery, use Hermes Agent Down?. For moving a deployment, use Hermes Agent Backup & Restore.

The security model

Hermes security has six layers:

Layer	Control	Risk reduced
Service account	Dedicated unprivileged user	Limits blast radius if the process is compromised
Tool scope	Disable unused tools; expose narrowly validated scripts or APIs	Reduces arbitrary action risk
File access	Allow only named directories	Protects secrets and unrelated business data
Network egress	Allow only required providers/APIs	Reduces data exfiltration paths
Logging and approval	Record prompts, tool calls, outputs and decisions	Supports audit, debugging and accountability
Backup and recovery	Native backup/import plus restore drill	Reduces availability and data-loss risk

Do those before arguing about model choice. A strong provider route cannot compensate for an agent that can read secrets, run shell commands and send messages without review.

1. Run Hermes as a dedicated user

For a server deployment, use a dedicated non-root account such as hermes. The current Hermes installation docs support installation as an unprivileged user and separate the administrative browser-dependency step where needed.

The goal is simple:

the agent should not have sudo by default;
the agent should not share a home directory with a human operator;
credentials should be readable only by the service account and admins;
logs and backups should have deliberate permissions.

If the workflow needs root-level work, that is a separate approved script or operational action. Do not give the agent broad sudo because one future workflow might need it.

2. Start with a narrow toolset

A sensible starting point is a written allowlist rather than a broad "agent can do everything" setup. Record the exact tools, accounts, files, commands and outbound services the first workflow needs, then leave everything else unavailable until the workflow proves a need.

Capability	Default stance	Safer pattern
Shell commands	Off	Narrow script with fixed arguments and logging
File writing	Off	OS/container-enforced output directories only
Browser automation	Off	Enable only for named sites/tasks
External sending	Draft/review first	Human approval before customer contact
Model invocation	On only for intended workflow	Keep deterministic work in scripts

The agent should orchestrate the messy judgement work. Deterministic reads, validations and writes should be scripts or APIs with checks.

3. Scope file access

Do not let a production agent roam a server. Decide where workflow inputs, outputs, logs, skills, backups and credentials live, then enforce those boundaries with the controls available in your Hermes version, operating system, containers, permissions and scripts.

At minimum:

keep SSH keys and cloud credentials outside the agent workflow area;
keep config.yaml readable only by the service account and admins;
write outputs to a named directory;
keep temporary files in a disposable scratch directory;
do not put unrelated business archives under the same account;
review actual file permissions after setup rather than trusting the plan.

If the agent only needs a CRM export and an output folder, design the host so that is all it can practically reach.

4. Restrict network egress where the data justifies it

At minimum, document which external services Hermes can reach:

model provider;
messaging provider;
approved business APIs;
update source;
monitoring endpoint;
backup destination.

For personal data, customer conversations, regulated work or high-value records, use firewall/security-list controls so the server can reach only the services it needs. Oracle Network Security Lists, cloud security groups and host-level ufw can all be part of that boundary.

Do not publish a fake universal allowlist. The correct list depends on the workflow.

5. Log the right events

For operational debugging, keep gateway logs, update logs and workflow logs. For governance, record:

who or what triggered the run;
source data timestamp;
prompt or instruction version;
tools called;
output generated;
approval decision;
external action taken;
error and recovery action.

Set retention deliberately. FCA, healthcare, legal and ordinary SME workflows may have different retention needs. The ICO's AI guidance expects organisations to assess data protection risks, explain processing and apply appropriate safeguards; logging helps only when it supports those purposes.

Do not keep personal data forever because logs feel useful. Do not delete logs so quickly that you cannot investigate an incident.

6. Choose the model route from the data

The model-provider question is a data-flow question:

Data type	Typical route
Non-personal public data	Direct model API may be acceptable after policy review
Customer or staff personal data	Check DPA, retention, subprocessors and transfer terms
Sensitive or regulated data	Prefer enterprise cloud routes, region controls or self-hosted models where appropriate
Data that should never leave the business	Do not send it to an external model

Hermes can be self-hosted while still sending prompts to a third-party model. That is often the point people miss. The server location and model-processing location are different questions.

DPIA: when to do it

For UK personal data, a Data Protection Impact Assessment may be required when AI processing is likely to create high risk. Use the ICO's guidance and your DPO/legal route to decide.

A practical Hermes DPIA should cover:

the specific workflow, not "AI assistant";
personal data categories;
data sources and recipients;
model provider and transfer route;
access controls;
tool permissions;
human approval points;
retention and deletion;
failure/recovery process;
residual risk and owner.

If you cannot complete those ten lines, the deployment is not ready for personal data.

PECR: when messaging changes the risk

Daily internal summaries to the owner are one thing. Customer WhatsApp, email or SMS messages are another.

If Hermes sends or drafts marketing messages, PECR may apply alongside UK GDPR. Design for:

consent or another lawful route;
opt-out;
suppression lists;
human approval;
audit logs;
rate limits;
clear sender identity.

Keep the first production workflow internal unless there is a strong reason to do otherwise.

Backups are part of security

Availability is a security property. If the host disappears, the disk fills, a credential is rotated badly or an update breaks state, the business still needs a recovery path.

Use native Hermes commands:

bashhermes backup
hermes import <backup-file>

Then test restore. The backup and restore guide covers the full migration sequence.

For updates, use the current Hermes update safety rails:

bashhermes update --check
hermes update --plan
hermes update --backup

Read ~/.hermes/logs/update_receipts/latest.json after updates. It is the evidence of what changed and which gateways restarted.

Security review checklist

Before production:

dedicated service account exists;
SSH access is controlled;
gateway installed as one clear service type;
unused tools are disabled;
file read/write paths are allowlisted;
external sending requires approval;
secrets are outside prompts and repositories;
model-provider data route is documented;
logs capture the events needed for review;
retention is documented;
backup and restore have been tested;
owner and incident path are written down.

After production:

review tools monthly;
rotate credentials on a schedule and after staff/provider changes;
inspect update receipts;
test alerts;
test restore;
review whether the first workflow should stay, shrink or expand.

Frequently asked questions

Hermes is software. Compliance depends on the deployment: data purpose, lawful basis, providers, access, retention, security, rights handling and governance.

Can I use Hermes with customer data?

Yes, if the data flow and controls are designed properly. Start with a DPIA-style map before connecting CRM, inbox, support, finance or WhatsApp customer data.

Should I disable shell access?

Yes by default. If a workflow needs commands, expose narrowly validated scripts with appropriate operating-system or container controls. A skill can describe the procedure, but it does not restrict shell access by itself.

Does self-hosting keep all data in the UK?

No. The host can be in the UK while the model provider processes prompts elsewhere. Check both the server region and the model-provider route.

How often should I review permissions?

Monthly during the pilot. After that, set a cadence based on risk, data type and incident history. Review immediately after adding a workflow, channel or provider.

What should you do next?

Map the first workflow, data sources, tools, model route, approval points and recovery owner before connecting live business systems.

Get unstuck →