Executive Safe-Install Guide — OpenClaw Security Research

Audience: a single executive/CEO (and their IT/admin) running OpenClaw locally or on a small VPS, with access to Gmail/Google Workspace.

Goal: get real utility while keeping blast radius small, network exposure minimal, and Google access least‑privilege.

Sources (primary): OpenClaw documentation (Security, Wizard/Setup/Pairing, Authentication/OAuth, Tool policy, Sandboxing, Logging/Redaction, Web/Control UI, Tailscale/Remote, Google Chat, Gmail Pub/Sub). See links in References.

External/neutral security sources used for principles (prompt injection & agent risks): OWASP Top 10 for LLM Apps; Microsoft guidance on prompt injection; NIST AI RMF + GenAI Profile overview.

1) Executive summary

Running an AI assistant that can read messages, browse the web, and execute tools is equivalent to operating a new privileged employee that can be tricked by hostile inputs.

OpenClaw’s own Security guide emphasizes that “access control before intelligence” is the real defense: who can talk to the bot, what tools it has, and where those tools run matter more than which model you pick. OpenClaw also ships a built‑in security audit command to flag common footguns (open DM policies, network exposure, browser control exposure, risky file permissions, plugins, etc.).

A safe executive setup is:

Loopback‑only Gateway (not exposed to LAN/internet).
Token/password auth ON, even locally.
DM policy = pairing/allowlist, and group mention gating.
Sandboxed tools by default, with no host execution unless explicitly approved.
Minimal tool profile (start read‑only; add capabilities gradually).
Separate “work” vs “personal” agents (separate sessions + credentials) when Gmail/Workspace data is involved.
Google integrations exposed only on a narrow path (e.g., /googlechat, /hooks/gmail) and only when truly necessary.

2) Threat model (single‑user executive)

Assets you must protect

Email contents (Gmail/Workspace), contact lists, internal documents.
Authentication material stored on disk (OpenClaw state, OAuth tokens, service account JSON keys).
Your identity/voice (messages the assistant can send “as you” in chat channels).
Corporate confidentiality (board decks, M&A discussions, legal material).

Likely attackers & risk scenarios

Prompt injection via inbound messages
- A stranger (or a compromised colleague account) sends “ignore previous instructions” + a convincing request to export data, click links, run commands, or approve something.
- OWASP calls this “Prompt Injection” (LLM01) and highlights downstream risks like insecure outputs and excessive agency.
Account takeover of a chat surface
- If a public DM or group can trigger OpenClaw, an attacker can induce actions: file reads, web fetches, or commands.
Network exposure & UI auth downgrade
- Exposing the Gateway UI to the internet (or misconfiguring reverse proxy headers) risks unauthorized access.
- OpenClaw explicitly warns about insecure Control UI auth fallbacks and reverse proxy header spoofing; it provides gateway.trustedProxies and audits exposure.
Google Workspace integration mis-scoping
- Over‑broad OAuth scopes or a powerful service account key can turn a single compromise into org‑wide compromise.
Supply‑chain/plugin risk
- Plugins run in‑process with the Gateway; installing plugins from npm can run code at install time. Treat plugins as “trusted code only.”
Local disk/log exposure
- OpenClaw stores session logs on disk (~/.openclaw/agents/<agentId>/sessions/*.jsonl). If the machine/user account is compromised, transcripts can be exfiltrated.

What “success” looks like

A malicious message can at worst cause a benign response or a blocked tool call.
It cannot cause:
- host command execution,
- unrestricted browsing/logins,
- bulk email/document exfiltration,
- or public exposure of your Control UI.

3) Safe‑by‑default setup checklist

A. Install + baseline verification

Install OpenClaw (preferred) and run the onboarding wizard:
- openclaw onboard --install-daemon
- QuickStart defaults are intentionally conservative (loopback gateway, auth token generated, Tailscale exposure off).
Immediately run a security check:
- openclaw security audit
- openclaw security audit --deep
Lock down local file permissions (OpenClaw audit can fix common ones):
- openclaw security audit --fix

OpenClaw’s security audit explicitly checks DM/group policies, tool blast radius, network exposure, browser control exposure, and local permission hygiene.

B. Keep the Gateway private

Keep the Gateway bound to loopback:
- Do not bind to 0.0.0.0 unless you have a strong reason.
Keep Gateway auth enabled (token/password):
- The wizard generates gateway.auth.token by default even on loopback.
If you need remote access, prefer:
- SSH port-forwarding (universal) or
- Tailscale Serve (tailnet‑only, HTTPS) while keeping the Gateway on loopback.

OpenClaw’s Web and Remote docs strongly recommend loopback + SSH/Tailscale rather than a public bind.

C. Lock down “who can talk to the bot”

DM policy: keep pairing (default) or allowlist.
- Pairing sends a short code; you approve explicitly (openclaw pairing approve …).
- Pairing/allowlists are stored under ~/.openclaw/credentials/ and should be treated as sensitive.
Groups: require mention by default and use allowlists.
- Avoid “always-on” bots in large rooms.
Consider DM session isolation if more than one person can DM the bot:
- OpenClaw supports session.dmScope: "per-channel-peer" to prevent cross-user context leakage.

D. Minimize tools (start read‑only)

Start with a restrictive tool profile and add tools only when needed.

OpenClaw supports: - tools.profile (base allowlist) - tools.allow / tools.deny - sandbox-only tool policy via tools.sandbox.tools.*

E. Sandbox tools (reduce host blast radius)

Enable Docker sandboxing with no workspace mount as the default:

agents.defaults.sandbox.mode: "non-main" (or "all" for maximum isolation)
workspaceAccess: "none"
Prefer no network for sandbox containers unless a specific workflow requires egress.

OpenClaw’s Sandboxing docs describe how tool execution can be run in Docker and how bind mounts can pierce the boundary.

F. Treat browser control like operator access

Do not expose browser control endpoints publicly.

OpenClaw explicitly warns that “browser control exposure” should be treated like operator access. If you need a browser on another machine, prefer a tailnet‑only node paired deliberately.

G. Google Workspace access: isolate and minimize

Use separate agents for “work” vs “personal”:

openclaw agents add work
openclaw agents add personal

OpenClaw recommends separate agents when you want strong separation between credentials and sessions.

For Google Chat:

Use a dedicated service account JSON key stored with strict permissions.
Expose only /googlechat publicly (not the whole dashboard).
Verify webhook audience settings; OpenClaw verifies bearer tokens against the configured audience.

For Gmail automation (Pub/Sub → webhook):

Prefer OpenClaw’s supported Tailscale setup.
Keep webhook handling narrow and authenticated (hook token).
Keep inbound email bodies limited (--max-bytes) and treat them as hostile content.

OpenClaw’s Gmail Pub/Sub guide notes that Gmail hook content is wrapped with external-content safety boundaries by default, and that disabling it is dangerous.

4) “Do not do this” (high‑risk shortcuts)

Do not set DM policy to open for an executive account.
Do not set groupPolicy to open in public or large rooms.
Do not expose the Gateway dashboard/UI to the public internet.
- If you must expose a webhook path, proxy only that path.
Do not enable insecure Control UI auth fallbacks except for temporary break‑glass debugging:
- gateway.controlUi.allowInsecureAuth and especially gateway.controlUi.dangerouslyDisableDeviceAuth are security downgrades.
Do not run with filesystem permissions that allow other users to read ~/.openclaw.
Do not install unreviewed plugins.
- Plugins run in‑process; installing from npm can execute code during install.
Do not mount sensitive host paths into the sandbox (e.g., SSH keys, password stores, docker.sock) unless you intentionally accept the consequences.
- Binding docker.sock effectively gives host control.
Do not treat LLM output as “commands”.
- OWASP highlights “Insecure Output Handling” and “Excessive Agency” as top risks.

5) Recommended configuration patterns (copy/paste)

Notes - OpenClaw reads ~/.openclaw/openclaw.json (JSON5 allowed) and validates strictly; unknown keys will prevent the Gateway from starting. - Prefer environment variables for secrets (token/password/API keys); don’t commit them into config files.

5.1 Minimal “executive safe” baseline (loopback + auth + minimal tools)

// ~/.openclaw/openclaw.json
        {
          gateway: {
            bind: "loopback",
            port: 18789,
            auth: {
              mode: "token",
              token: "${OPENCLAW_GATEWAY_TOKEN}",
              // If using Tailscale Serve identity auth, consider setting allowTailscale:false
              // to require explicit credentials.
              // allowTailscale: false,
            },
            controlUi: {
              enabled: true,
              // Keep these OFF (security downgrade)
              // allowInsecureAuth: false,
              // dangerouslyDisableDeviceAuth: false,
            },
            trustedProxies: [
              // Only if you run behind a reverse proxy; otherwise omit.
              // "127.0.0.1"
            ],
          },
        
          // Start restrictive and open up deliberately.
          tools: {
            profile: "minimal",
            // Example: allow only messaging/session tools (no shell, no browser)
            // profile: "messaging",
            deny: [
              // Explicitly deny high-risk tool groups until you need them
              "group:runtime",   // exec/process/bash
              "group:ui",        // browser/canvas
              "group:web"        // web_search/web_fetch
            ]
          },
        
          logging: {
            level: "info",
            consoleLevel: "info",
            redactSensitive: "tools" // OpenClaw default; keep it on
          },
        }

Why: - Loopback + token auth limits network and local-process exposure. - Minimal tools prevents prompt injection from becoming execution. - OpenClaw’s logging redaction helps keep tokens out of console output (note: file logs still exist).

5.2 Sandbox tools by default (recommended once Docker is available)

Build the sandbox image once:

scripts/sandbox-setup.sh

Then enable:

{
          agents: {
            defaults: {
              sandbox: {
                mode: "non-main",   // or "all" for maximum isolation
                scope: "session",
                workspaceAccess: "none" // safest default
              }
            }
          },
        
          // Optional: even when sandboxed, keep tool policy tight
          tools: {
            sandbox: {
              tools: {
                deny: ["group:runtime"]
              }
            }
          }
        }

Key security point from OpenClaw Sandboxing docs: - Bind mounts and workspaceAccess can pierce isolation. Treat any docker.binds as a deliberate security exception.

5.3 Separate “work” agent for Google Workspace (recommended)

Create an isolated agent (separate sessions, workspace, auth profiles):

openclaw agents add work

Then route your Google Chat / Gmail hooks to that agent (conceptually): - keep “work” data out of your personal agent’s session history.

5.4 Google Chat: expose only `/googlechat` (not the dashboard)

OpenClaw’s Google Chat channel requires a public HTTPS endpoint. Your objective is to expose only /googlechat while keeping the Control UI private.

Option A: Tailscale Serve (private UI) + Funnel (public webhook path)

Serve dashboard privately (tailnet): :8443 → gateway.
Funnel only the path /googlechat publicly.

OpenClaw provides commands/examples in the Google Chat docs.

Option B: Reverse proxy path‑only (example from docs)

your-domain.com {
          reverse_proxy /googlechat* localhost:18789
        }

Then configure OpenClaw:

{
          channels: {
            googlechat: {
              enabled: true,
              serviceAccountFile: "/path/to/googlechat-service-account.json",
              audienceType: "app-url",
              audience: "https://gateway.example.com/googlechat",
              webhookPath: "/googlechat",
        
              dm: {
                policy: "pairing",
                // Keep allowFrom narrow; pairing approvals add to local allowlist store.
                allowFrom: ["your-email@company.com"]
              },
        
              groupPolicy: "allowlist",
              groups: {
                // Explicit allowlist of spaces; require mention
                "spaces/AAAA": { allow: true, requireMention: true }
              }
            }
          }
        }

5.5 Gmail Pub/Sub automation: keep it narrow + authenticated

OpenClaw’s Gmail Pub/Sub guide uses: - OpenClaw hooks endpoint + mapping - a separate watcher/handler (gog gmail watch serve)

Example (from docs, adapted):

{
          hooks: {
            enabled: true,
            token: "${OPENCLAW_HOOK_TOKEN}",
            path: "/hooks",
            presets: ["gmail"],
        
            // Optional: map Gmail to a separate agent/sessionKey
            mappings: [
              {
                match: { path: "gmail" },
                action: "agent",
                name: "Gmail",
                sessionKey: "hook:gmail:{{messages[0].id}}",
                deliver: false,
        
                // Strongly consider redacting/limiting body content in messageTemplate
                messageTemplate:
                  "New email from {{messages[0].from}}\nSubject: {{messages[0].subject}}\n{{messages[0].snippet}}"
              }
            ]
          }
        }

Operational advice: - Keep --max-bytes low and avoid full‑body ingestion unless necessary. - Treat email as hostile content (links, “instructions,” embedded prompts).

6) Incident response (executive playbook)

Indicators you should treat as a security incident

OpenClaw responds to an unrecognized DM or a room you didn’t intend.
Unexpected tool activity: exec/browser/node actions you didn’t request.
Suspicious outbound messages sent “by the assistant.”
A new plugin appears or was enabled without your explicit action.
Gateway/UI became reachable from unexpected networks.

Immediate containment steps

Disconnect exposure
- If on a VPS: block inbound at firewall/security group immediately.
- Disable Tailscale Funnel/Serve if misconfigured.
Stop the Gateway
- openclaw gateway stop (or stop the daemon/service).
Revoke access paths
- Rotate OPENCLAW_GATEWAY_TOKEN / password.
- Remove/disable the affected channel (Google Chat webhook, WhatsApp/Telegram tokens, etc.).
Preserve evidence (do not wipe first)
- Save logs (openclaw logs --follow / log file path) and session JSONLs.
Review pairing/allowlists
- Inspect ~/.openclaw/credentials/-allowFrom.json and remove unexpected entries.
Run OpenClaw checks
- openclaw security audit --deep
- openclaw doctor
Google Workspace response (if Gmail/Chat involved)
- Rotate/revoke service account key if used.
- Audit GCP project IAM + key creation logs.
- If user OAuth was used, revoke tokens at provider, then re‑authorize.

Recovery (after containment)

Restore from a known-good configuration backup.
Re-enable channels one-by-one.
Keep tools on minimal profile until confidence is restored.

7) FAQ

Q1: Should I run OpenClaw on my laptop or a VPS?

Laptop: best for minimal exposure (loopback-only), but sleeps/offline.
VPS: always-on, but higher exposure risk. If you use a VPS, prefer:
- loopback bind + Tailscale tailnet access, and
- strict firewall rules.

OpenClaw’s Remote/Tailscale docs position “one Gateway host owns state; other devices connect.”

Q2: Is “pairing” enough to stop prompt injection?

Pairing reduces who can deliver hostile prompts. It does not eliminate injection risk from: - compromised trusted contacts, - malicious email bodies, - hostile links/attachments, - or poisoned group conversations.

Use pairing plus minimal tools plus sandboxing.

Q3: Why separate agents for work/personal?

OpenClaw stores session transcripts on disk per agent. Separate agents give you: - separate auth profiles, - separate session histories, - lower risk of cross-context leakage.

OpenClaw explicitly recommends separate agents when you want strong separation.

Q4: If I must expose a webhook (Google Chat / Gmail), what’s the safest way?

Expose only the needed path.
Keep the dashboard/UI private (tailnet/SSH).
Use strong auth checks (audience validation for Google Chat; hook token for Gmail hooks).
Keep the bot’s tool policy minimal for webhook-triggered sessions.

Q5: What is the single most important security habit?

Run openclaw security audit --deep after: - changing config, - exposing any network surface, - adding a channel/plugin, - or enabling tools.

References

OpenClaw docs (primary)

Security (audit, DM policies, proxy safety, Control UI auth): https://docs.openclaw.ai/gateway/security
Getting started (wizard, auth locations, sandboxing note): https://docs.openclaw.ai/start/getting-started
Wizard (default posture, tokens, channels): https://docs.openclaw.ai/start/wizard
Pairing (DM + node device pairing, file locations): https://docs.openclaw.ai/start/pairing
Gateway configuration (strict validation, includes, auth storage): https://docs.openclaw.ai/gateway/configuration
Authentication / OAuth pointers: https://docs.openclaw.ai/gateway/authentication and https://docs.openclaw.ai/concepts/oauth
Tools policy / profiles / allow/deny groups: https://docs.openclaw.ai/tools
Sandboxing: https://docs.openclaw.ai/gateway/sandboxing
Sandbox vs Tool Policy vs Elevated: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated
Exec approvals (host/node safety interlock): https://docs.openclaw.ai/tools/exec-approvals
Logging + redaction knobs: https://docs.openclaw.ai/logging
Web/Control UI + security notes: https://docs.openclaw.ai/web
Tailscale (Serve/Funnel + auth details): https://docs.openclaw.ai/gateway/tailscale
Remote access (SSH/tunnels): https://docs.openclaw.ai/gateway/remote
Google Chat channel: https://docs.openclaw.ai/channels/googlechat
Gmail Pub/Sub automation: https://docs.openclaw.ai/automation/gmail-pubsub

External / neutral guidance (prompt injection & agentic risk)

OWASP Top 10 for LLM Applications (includes Prompt Injection, Insecure Output Handling, Excessive Agency): https://owasp.org/www-project-top-10-for-large-language-model-applications/
Microsoft (Azure OpenAI) prompt engineering guidance (includes discussion of prompt injection): https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/prompt-engineering#prompt-injection
NIST AI Risk Management Framework overview + GenAI profile announcement: https://www.nist.gov/itl/ai-risk-management-framework

Document version: 2026-01-30 (UTC)

Download the source PDF: openclaw-exec-safe-install-guide.pdf