Home › Answers › OpenClaw in a company

OpenClaw on a company VPS: what an auditor will ask — and what to add

Transparency. We maintain Cortex Gateway, an open-source access layer that solves the organizational half of this page. Facts about OpenClaw are taken from its repository and its security documentation, checked 17 August 2026. Corrections welcome as a GitHub issue. Same series: Hermes Agent, Grok Bot. Cette page existe en français.

Why this page exists

OpenClaw is the most-starred agent on GitHub — 385k+ stars, MIT-licensed, messaging-native, the personal assistant that made "always-on agent on a $5 VPS" a normal thing to have. The same service industry that installs Hermes for companies installs OpenClaw for companies: one instance on a VPS, wired to WhatsApp or Slack, connected to company mail and files, the whole team paired to it.

The difference is that OpenClaw's documentation already told the installer not to. Its security page states the trust model plainly and recommends separate instances per user. The gap this page covers is not hidden in the product — it is the distance between what the docs say and what gets deployed.

What OpenClaw secures well — credit where due

For its stated scope — one person and their agent — the security work is serious:

• Credential hygiene: secrets under ~/.openclaw/ with 600/700 permissions; workspace .env files are blocked from overriding provider credentials.
• Inbound gating: DM pairing with approval codes (default), allowlists, mention-gating and per-group controls, context-visibility filters for non-allowlisted senders.
• Tool policy and sandboxing: sensitive tools (exec, browser, process) restricted or disabled by default; opt-in Docker/Podman sandboxes; an owner-only elevated escape hatch.
• Self-audit: openclaw security audit checks network exposure, tool blast radius, permissions and plugin loading, with --fix auto-remediation. More than most agents ship.
• Log redaction: transcripts on disk with pattern-based secret redaction, extensible via logging.redactPatterns.

All of it protects the machine and the inbound surface. The docs are equally clear about what is absent: no per-user authorization (a sessionKey "is a routing selector, not an auth token"), no multi-tenant isolation. For one person, the right scope. For a company, the whole question.

The four questions an auditor asks — plus a fifth OpenClaw raises itself

The fifth row is specific to OpenClaw's defaults and is the one that turns a compliance finding into an incident: cross-employee context bleed needs no attacker, only two colleagues and the default configuration.

"One instance per user" is honest — and doesn't scale

OpenClaw's documented answer for multiple users is separate gateway instances with isolated credentials, ideally separate OS accounts or hosts. As isolation advice, it is correct. As a company deployment model, count what it creates for a 20-person SMB: twenty instances to patch, twenty credential stores to rotate when anything leaks, twenty transcript sets to govern for GDPR retention — and still zero central audit trail, zero single revocation, and downstream systems that see twenty service accounts instead of twenty people.

Isolation between users is necessary. It is not the same thing as organizational access control, and multiplying instances buys the first while leaving the second untouched.

The GDPR angle

Transcripts are personal data. Session transcripts persist on disk — employee and customer conversations included. Redaction patterns catch secrets, not personal data; retention and erasure (Art. 5(1)(e), Art. 17) are the operator's to answer.

Art. 32: shared credentials, a default shared session and no access log on a box reading company mail is a hard position in an incident report — the shared-session default alone is an integrity-and-confidentiality (Art. 5(1)(f)) finding.

Art. 30: unattended jobs against customer data are processing activities; someone must be able to list them.

Art. 28 lands on the installer. Whoever keeps operating the VPS — updates, restarts, SSH — is a processor and needs a DPA. This is the clause most installers discover after the fact, and it carries their liability, not the client's.

The fix keeps OpenClaw

Keep the runtime — the skills, the channels, the sandboxing, one instance per user if you follow the docs. Move company-data access behind an identity layer OpenClaw already speaks. Its MCP client supports Streamable HTTP with managed OAuth tokens (v1.5.0+): three commands, and the agent holds a short-lived token bound to one real person instead of raw API keys scattered in its config.

• Each employee authenticates as themselves — their OpenClaw calls carry their identity; each application enforces the permissions that person already has. The permission layer, not a shared key.
• Least privilege becomes scopes, per user, reviewed when roles change.
• Every tool call writes one attributable audit line, on your infrastructure, exportable.
• Revocation is one act — cut the OAuth grant, every backend is cut, unattended jobs included.

Model-provider keys can stay local; they authenticate the agent to its brain, not to your business. The five-point installer checklist and the controls-to-frameworks mapping are the same as for Hermes: see the installer's checklist and AI agent compliance controls. And whatever else you change, run openclaw security audit --fix — the machine half stays yours to harden.

FAQ