Security & compliance, in the open
An AI agent with access to your files, inboxes and APIs is only as safe as the server it runs on. A default install is not enough. Here is exactly how we harden every deployment, the risks OpenClaw documents about itself, and the legal frame we operate in.
13 measures applied to every deployment
Dedicated non-root user
The agent runs under a purpose-built, unprivileged account with no sudo rights, so a compromise can’t take over the machine.
UFW firewall, closed ports
Deny-by-default firewall: only the strictly necessary ports are open, everything else is closed to the internet.
SSH key-only + fail2ban
Password login disabled, key-based authentication only, and fail2ban bans IPs after repeated failed attempts.
TLS / HTTPS everywhere
All traffic encrypted in transit with valid certificates and auto-renewal. No plaintext endpoints exposed.
Encrypted secrets vault
API keys and tokens live in an encrypted secrets store, never in plaintext .env files or source code.
Least-privilege API scopes
Every key and integration gets the narrowest scope it needs, so a leaked token has minimal blast radius.
Automatic security updates
Unattended security patching keeps the OS and dependencies current without manual intervention.
Isolated container / VM
The agent runs inside a dedicated, isolated container or VM, separated from other workloads and the host.
Encrypted, tested backups
Regular, encrypted, off-instance backups so you can restore quickly, and restores are actually tested.
Audit logging
Actions, access and key events are logged for traceability, incident review and accountability.
Rate limiting
Request rate limits protect the agent and its APIs against abuse, runaway loops and brute-force attempts.
No data outside Switzerland/EU
Processing and storage stay within Swiss/EU jurisdiction. No data is silently shipped to third-party regions.
Your server, your name
The server stays in your name: you keep ownership and control of the infrastructure and the data on it, throughout.
The audit we run is open source. You can read it and run it yourself.
We published our 12-point hardening audit under the MIT licence. Two scripts: audit.sh is read-only and scores a host against the 12 points without changing anything; harden.sh applies the fixes, is idempotent, and backs up every file it touches. Nothing to take on trust: the code is readable before it is run.
Delta117-117/openclaw-hardening
MIT
- audit.sh
- Read-only. Scores your host against the 12 points, changes nothing, safe to run anytime.
- harden.sh
- Applies the hardening. Idempotent, backs up every file it changes, safe to re-run.
Provided as-is under MIT, with no warranty. Hardening is necessary but not sufficient: keep OpenClaw patched and only install skills you have reviewed.
OpenClaw 12-point hardening checklist
Delta-One Capital Sàrl · openclawpro.ai · github.com/Delta117-117/openclaw-hardening · MIT
12-point hardening checklist
Exactly the list audit.sh checks. Print it, tick it off, or run the script: the result should be the same.
- Dedicated non-root userThe agent runs unprivileged, with no sudo.
- Deny-by-default firewall (UFW)Only strictly necessary ports open.
- SSH key-only + fail2banPassword login disabled, brute force banned.
- TLS everywhereNo plaintext endpoints; certificates auto-renewed.
- Encrypted secretsAPI keys in an encrypted store, never in a plaintext .env in the repo.
- Least-privilege API scopesEvery token gets the narrowest scope it needs.
- Automatic security updatesUnattended upgrades for OS and dependencies.
- Isolated container / VMThe agent is sandboxed from the host and other workloads.
- Audit loggingActions and access are logged for traceability.
- Rate limitingProtects the agent and its APIs from abuse and runaway loops.
- Encrypted, tested backupsOff-instance, and restores are actually verified.
- No public gateway, data residencyThe OpenClaw gateway is never exposed publicly; data stays in your jurisdiction.
The risks are not our claim. The countermeasures are.
Every line below comes from the security guide published by the OpenClaw project itself. We do not talk them down: we quote them, then state the measure we apply.
Tools run on the host unless a sandbox is configured
Sandboxing is opt-in. With sandbox mode off, an implicit host=auto resolves to the gateway host, so tool calls execute on the machine itself.
What we do
We never leave that to the default. The agent runs in a dedicated isolated container or VM, under a non-root account with no sudo, behind a deny-by-default firewall (points 1, 2 and 8).
Everything the agent reads is untrusted input
Prompt injection does not require public DMs: any untrusted content the agent reads (web results, browser pages, emails, documents, attachments, pasted logs) can carry adversarial instructions. The content itself is the threat surface, not just the sender.
What we do
Inbound stays locked to pairing and allowlists, high-risk tools are limited to what the use case actually needs, and audit logging plus rate limiting make abuse visible and bounded (points 6, 10 and 11).
A tool-enabled agent can reach your shell, files and network
The upstream threat model is explicit: the assistant can execute shell commands, read and write files, reach network services and message anyone it has channel access to.
What we do
Secrets live in an encrypted store outside the agent’s reachable filesystem, every key carries the narrowest scope that works, and backups are encrypted, off-instance and restore-tested (points 5, 6 and 9).
One gateway is one trust boundary, not a multi-tenant wall
OpenClaw states it is not a hostile multi-tenant security boundary: mutually untrusted users sharing one gateway share that agent’s delegated tool authority. Split trust boundaries instead.
What we do
Every deployment is one instance for one client, on its own isolated server, in the client’s own name. We do not put two customers behind one gateway (points 8 and 13).
Source: docs.openclaw.ai/gateway/security (OpenClaw Gateway security guide, read 7 August 2026).
A Swiss entity you can look up, a named applicable law.
- Data controller
- Delta-One Capital Sàrl, Geneva, Switzerland. UID CHE-443.465.421, entered in the Commercial Register of the Canton of Geneva.
- Applicable law
- Revised Swiss Federal Act on Data Protection (nLPD/FADP, in force since September 2023) and the GDPR (EU Regulation 2016/679).
- Data residency
- Processing and storage in Switzerland and/or the European Union. Client agents run on infrastructure in the client’s own name.
- Sub-processors
- Stripe (card payments), Resend (transactional email), Cloudflare (CDN, DNS, security). US-based, bound by Standard Contractual Clauses. Named and linked on our privacy policy.
- Card data
- Handled entirely by Stripe, a PCI-DSS compliant processor. We never store card numbers on our servers.
- Your rights
- Access, rectification, erasure, portability, objection and restriction (GDPR Art. 15 to 22 and the nLPD). Complaints go to the FDPIC in Switzerland or your national supervisory authority.
- What we are
- A software installation and hosting service. We do not hold client funds, we do not manage assets and we do not act as a financial intermediary.
Privacy policyLegal noticeTerms of serviceFull security guide
14-day money-back guarantee on Starter and Advanced installs and your first Managed month.
Your data stays in Switzerland/EU, under nLPD/GDPR.