OpenClaw Hardening Reference: Network Isolation, Identity Scoping, and Input Trust Boundaries for Autonomous Agent Deployments

OpenClaw is the clearest exemplar of the shadow AI exposure class enterprises are now contending with. An autonomous orchestration layer on top of hosted LLMs, with first-class tools for filesystem access, shell execution, browser control, and outbound API calls, reachable through consumer messaging platforms. A default install, run from a walkthrough video, produces a system that holds production-grade credentials inside a consumer-grade security boundary.

This reference is a deployment architecture for OpenClaw that closes the most common gaps practitioners are finding in the wild: public SSH with password authentication, root-level agent execution, primary-identity account integrations, uncapped API keys, and unaudited skill installation. The target reader is a security architect, platform engineer, or technical lead responsible either for their own agent deployment or for defining the acceptable-use pattern their organization will sanction when “ban all personal agents” stops being a tenable policy.

The architecture presented here is intentionally minimal. Every control has a defined threat it addresses. The goal is not to make OpenClaw enterprise-grade (that requires organizational governance the operator cannot provide alone) but to bound the blast radius so a compromise at this layer does not cascade into the operator’s broader identity footprint.

1. Threat Model

OpenClaw deployments fail along three axes. Each section of this reference maps back to one or more of them.

Network exposure. The default deployment pattern places an SSH-reachable host on a public IP. Authentication is typically password-based, with root login enabled. This is the exposure class most easily automated against, and the one most likely to be exploited before the operator has finished configuring the agent.

Identity and credential over-scoping. The agent process frequently runs as root. Integrations commonly use the operator’s primary Gmail, primary Drive, and primary browser profile. API keys are configured without spending caps. Bot tokens sit in chat history. Each of these decisions converts a local compromise into a federated one.

Input trust boundary violation. The agent reads content produced outside its trust boundary (email bodies, shared documents, web pages) through the same prompt channel it receives operator instructions. Prompt injection against an agent holding first-class tools is the emerging incident class, and it does not require the attacker to compromise any infrastructure. It requires only that the agent reads attacker-controlled content.

Map these to OWASP LLM Top 10 and the relevant categories appear: LLM01 (prompt injection), LLM02 (sensitive information disclosure), LLM06 (excessive agency), and LLM08 (vector and embedding weaknesses) where memory features are enabled. Traditional enterprise controls (EDR, DLP, SWG) do not see most of this activity because it occurs inside a process the operator explicitly installed and authenticated.

2. Reference Architecture

The deployment pattern is a single-tenant VM on a reputable VPS provider, placed behind a mesh VPN, with the agent running as a non-root user, reachable only through authenticated messaging and port-forwarded admin interfaces. At a glance:

• Compute isolation: dedicated VM, not the operator’s primary workstation

• Network isolation: mesh VPN (Tailscale, WireGuard-native) as the sole ingress path

• Edge control: provider-level firewall denying all inbound traffic except the VPN port

• Runtime privilege: agent runs as a non-root user; sudo requires a password the agent does not possess

• Control plane: dedicated messaging bot identity, not operator’s primary messaging account

• Admin interface: localhost-bound UI reached via ad-hoc SSH port forwarding

• Model credentials: API keys with hard spending caps, or OAuth handoffs with token lifecycle management

• Integration scope: dedicated accounts per integration, with human-forwarded content as the primary input path

The controls below implement this pattern.

3. Compute Isolation

The first architectural decision is where the agent runs. Personal workstation deployments are non-viable for any operator with any sensitive material on the machine. Browser sessions, SSH keys, password manager state, and enterprise SSO tokens share the process namespace with a long-running autonomous process that reads untrusted input and makes outbound calls. Containment is not achievable on a shared host.

A small VPS (two to four GB RAM, single vCPU, any reputable provider) provides physical separation, stable networking, snapshot capability, and a bounded failure domain. If the agent is compromised, the VM is destroyed and rebuilt. The operator’s primary environment is unaffected.

Provision a clean Debian 13 or Ubuntu LTS image. Do not use provider-offered “one-click OpenClaw deployment” options; these frequently pre-configure public exposure that this reference explicitly removes.

4. Network Isolation

4.1 Initial Access

After provisioning, the operator holds root credentials and a public IP. Initial SSH:

ssh root@<vps-public-ip></vps-public-ip>

This reachability is the exposure to be eliminated. All subsequent network access will transit an authenticated mesh VPN.

4.2 Mesh VPN Installation

Tailscale is the reference choice: WireGuard-based, identity-gated, with a control plane that supports device revocation. The same pattern applies to Headscale (self-hosted) or native WireGuard with stricter operational overhead.

Install on the server:

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --ssh

The command prints an authentication URL. Authenticate from the operator workstation’s browser using an identity under MFA. This identity becomes a control-plane credential for the deployment; scope it accordingly.

Install the Tailscale client on the operator workstation and authenticate with the same identity. Confirm bidirectional reachability from the server:

tailscale status

Record the server’s tailnet IP from the admin console (100.x.x.xrange). All subsequent administrative traffic uses this address.

4.3 SSH Hardening

Edit the SSH daemon configuration:

nano /etc/ssh/sshd_config

Three changes:

1. Uncomment ListenAddress and set it to the server’s tailnet IP. The daemon now binds only to the VPN interface, not the public interface.

2. Set PasswordAuthentication no. Eliminates credential brute-force as an attack path.

3. Set PermitRootLogin no. Eliminates privileged remote access.

Before restarting the daemon, provision a non-root administrative user:

adduser claw
usermod -aG sudo claw

Verify sudo membership is active:

su - claw
sudo whoami

The second command should prompt for the new user’s password and return root. Exit back to the root shell.

Restart SSH:

systemctl restart ssh
logout

Validation: from the operator workstation, attempt SSH to the public IP. The connection should fail. Attempt SSH to the tailnet IP as the new user:

ssh claw@<tailscale-ip></tailscale-ip>

Access should succeed without a password prompt (Tailscale SSH authenticates via tailnet identity). Disconnect Tailscale on the workstation and retry. The connection must fail. The server is now unreachable from any device not present on the authenticated tailnet.

4.4 Edge Firewall

Host-level controls are insufficient defense-in-depth. A misconfiguration, a skill installation that opens a port, or a package update can re-expose services. The provider-level firewall is a control plane the agent process cannot modify.

In the provider dashboard, configure the firewall:

• Default inbound policy: deny

• Rule: allow UDP port 41641, source anywhere (Tailscale mesh establishment)

• Do not open TCP 22, 80, 443, or any other port

Apply the rule. Validate with an external ping or port scan against the public IP. All traffic should be dropped at the edge.

If the deployment later requires public-facing services (a webhook endpoint, a TLS-terminated dashboard), add specific allow rules at that time with operator-managed rate limiting and authentication. Do not pre-open ports for hypothetical future use.

5. Runtime Privilege Scoping

Install OpenClaw as the non-root user. The installer typically uses a shell-piped one-liner; the operator should download it to disk first, review it, and then execute. curl | sh patterns against untrusted sources are a supply chain anti-pattern that applies here as much as anywhere.

During the setup wizard, the following answers implement this reference:

• Configuration mode: manual (exposes every decision explicitly)

• Gateway bind: loopback (127.0.0.1), not any public or tailnet interface

• Token authentication: enabled

• Tailscale exposure: disabled (port forwarding is tighter than service exposure)

• Gateway token: left blank for installer-generated random token

• Privilege escalation during install: declined; the agent runs unprivileged

The runtime privilege decision is the single most important runtime control. A root-level agent has the ability to rewrite sshd_config, modify firewall rules, install persistence, and undo every network control above. A non-root agent encounters sudo prompts for any privileged action, and those prompts require a password the agent does not hold. Operator-in-the-loop authentication at the sudo boundary is the control that makes containment stable over time.

6. Model Credential Scoping

Two credential patterns apply, with different risk shapes.

6.1 Raw API Key

Configure a hard monthly spending cap on the provider console before pasting the key into the agent. Not a budget alert. A cap that stops charges. Route notifications to a mailbox the operator reads. The cap bounds damage from credential leakage, runaway loops, and injection attempts that operate by calling the API repeatedly.

6.2 Subscription-Bounded OAuth Handoff

Both Anthropic and OpenAI support OAuth flows that authorize the agent against an existing subscription, capping dollar spend by plan rather than by explicit key policy. The credential risk is account impersonation rather than billing.

For OpenAI Codex, the wizard prints an authorization URL. Authenticate in-browser, then paste the authorization code from the redirect URL. The code is the substring between code= and the first & character.

For Anthropic, run on any workstation with Claude Code installed:

claude setup-token

Authenticate in-browser and paste the returned token into the OpenClaw configuration.

In either pattern, the model provider sees every prompt and tool result in context. Any secret the agent processes should be assumed known to the provider. Deployments that cannot tolerate this constraint move to a local-model architecture, with the hardware and operational cost that implies.

7. Control Plane: Messaging Bot Identity

The operator needs a low-friction channel to issue instructions. Consumer messaging platforms fill this role, with the critical constraint that the bot identity must be distinct from the operator’s primary messaging account.

Telegram is the reference choice because BotFather produces isolated bot identities with their own bearer tokens. The same hygiene applies to Discord, WhatsApp, or iMessage bridges.

From the Telegram client, message @BotFather (verified account) and initiate bot creation:

/newbot

Provide a display name and a username ending in bot. BotFather returns a bot token. Paste it into the OpenClaw wizard when prompted, then delete the token from Telegram message history. The token is a bearer credential; possession grants command authority.

Continue the wizard: DM policy pairing, skills deferred, gateway service enabled (node runtime), hatch in terminal UI.

Exit the terminal UI with /exit. Open the new bot in Telegram and press start. The bot returns a pairing command:

openclaw pairing approve telegram <pairing-code></pairing-code>

Execute on the server. Validation: send a test message from the paired Telegram account; the bot should respond. Send from any other account; the bot should refuse.

8. Admin Interface: Local-Only with Port Forwarding

OpenClaw ships a gateway UI bound to localhost. Expose it to the operator workstation only through ad-hoc SSH port forwarding, never through a listening service.

Retrieve the gateway port from the server:

openclaw gateway

Default port is 18789. From the operator workstation, establish the forward:

ssh -N -L 18789:127.0.0.1:18789 claw@<tailscale-ip></tailscale-ip>

The -N flag suppresses shell execution. The tunnel lives for the duration of the SSH connection and terminates on close. The operator’s workstation reaches the UI at http://localhost:18789.

The UI prompts for a gateway token. The token can be retrieved by asking the bot through Telegram (the bot knows the command to print its current gateway token). Authenticate via query parameter:

http://localhost:18789?token=<gateway-token></gateway-token>

The same port-forwarding pattern generalizes to any service the agent runs locally. A FastAPI instance on port 5000, a dashboard on 3000, a Jupyter server on 8888: each requires a dedicated forward, established on demand:

ssh -N -L 5000:127.0.0.1:5000 claw@<tailscale-ip></tailscale-ip>

No service on the server listens on any interface reachable from outside the host without an operator-initiated tunnel.

9. Operational Recovery

A hardened deployment is only useful if the operator can recover from routine operational faults without loosening the security posture. The following runbook covers the scenarios that occur most often.

SSH session disconnect. Reopen terminal, verify Tailscale client connected on workstation, reissue ssh claw@<tailscale-ip></tailscale-ip>. Re-establish any admin port forwards with their original ssh -N -Lcommands.

Workstation reboot. Tailscale auto-reconnects on login on most platforms. Verify in system tray or menu bar. SSH back in as before; tailnet identity persists.

Tailscale client disconnect. Reopen the app and connect. If authentication fails, sign out and re-authenticate with the setup identity. If the server is absent from the admin console device list, use the provider’s browser-based console to reach the server, then run tailscale up --ssh to rejoin. Never modify ListenAddress back to 0.0.0.0 to recover reachability.

Bot token loss. Message @BotFather, send /mybots, select the bot, choose API token, revoke and regenerate. Update the OpenClaw configuration with the new token.

Gateway token loss. Ask the bot through Telegram to retrieve or rotate the token. Rotation on a scheduled cadence is good practice regardless.

Sudo password loss. Authenticate as root through the provider’s browser console (hypervisor-level access, independent of SSH), run passwd claw, log out. Do not restore password SSH or public root login.

Full lockout. Provider browser console remains available at the hypervisor layer regardless of SSH state. Typical causes are malformed sshd_config or a killed tailscaled service. The recovery commands are systemctl restart tailscaled followed by tailscale up --ssh. Reboot if needed.

Second device enrollment. Install Tailscale on the phone, tablet, or secondary workstation. Authenticate with the same identity. Approve from the admin console. SSH to the server’s tailnet IP as the non-root user.

Admin tunnel collapse. Browser returns connection refused. Re-run the ssh -N -L forward in a fresh terminal.

None of these recovery paths re-open public SSH, loosen the edge firewall, or move credentials out of the password manager. Any recovery procedure that does any of those things is the wrong procedure.

10. Input Trust Boundaries

Every control above addresses network, runtime, or credential exposure. None of them address the harder problem: the agent reads content that originates outside the operator’s trust boundary and that content can contain instructions.

Prompt injection is not solved at the protocol level. It is not solved in any shipping agent framework, OpenClaw included. The architectural response is to minimize what enters the agent’s context from untrusted sources and to scope what the agent can do with that input.

10.1 Integration Account Isolation

The agent must not be integrated with the operator’s primary email, primary Drive, primary calendar, or primary browser profile. Any of these integrations extends the agent’s trust boundary to include every entity that can reach the operator through that channel, which is effectively the internet.

The reference pattern: create a dedicated account per integration. For email, a secondary Gmail or Fastmail address used only by the agent. For document storage, a dedicated Drive or Dropbox workspace. For calendar, a separate calendar that the operator explicitly shares content into.

The operator, acting as a trusted filter, forwards content into the agent’s inbox from the primary account when specific content merits agent processing. This sacrifices convenience for a defensible trust boundary.

10.2 Minimum Necessary Scope

Every OAuth grant and token should be scoped to the least authority that enables the task. Read-only where writes are not required. Single-folder Drive access rather than full-drive. Label-filtered Gmail rather than full mailbox. Per-service scope rather than umbrella grants.

This is the Minimum Necessary Information principle applied at the integration layer. It is also the principle most frequently violated when the operator’s default posture is to accept the broadest scope the consent screen offers.

10.3 Skill Audit

OpenClaw ships with an extensive catalog of skills and streamlines bulk enablement. The architectural posture is the opposite: enable each skill explicitly, after the operator has documented three things:

1. What data does this skill ingest?

2. What actions does this skill enable?

3. What is the worst-case misuse pattern?

If any of the three cannot be answered, the skill is deferred. The right number of enabled skills for most deployments is small and specific.

10.4 Egress Constraints

A skill that performs arbitrary outbound HTTP requests is an exfiltration primitive. Injected instructions can encode data as query strings to attacker-controlled endpoints without sending an email or writing a file. Where such skills are required, the defensible posture is an egress allowlist at the VPS level, constraining outbound HTTP to domains explicitly approved by the operator.

Egress allowlisting is operational work. It is also the single highest-leverage control against exfiltration through injected instructions. Deployments that process sensitive context should treat it as mandatory.

10.5 Reversibility

The architectural assumption is that the agent will eventually follow a malicious instruction. The deployment should be designed such that when this happens, the damage is bounded and recoverable. Scoped accounts. Capped spending. Read-only tokens where permissible. Snapshots of anything the operator cannot afford to lose. Audit logs the operator reviews.

11. Governance and Drift Prevention

Initial configuration is not the failure mode. Configuration drift is. Deployments that pass every check at install time fail months later because a skill was added without audit, a port was opened for debugging and not reclosed, a decommissioned laptop remained on the tailnet, or an integration was upgraded from a scoped account to a primary one “temporarily.”

Operational disciplines that preserve the initial posture:

Credential rotation. Gateway token, bot token, and API keys on a defined cadence (quarterly for individual operators, monthly or shorter for sensitive contexts).

Device hygiene. Monthly review of the Tailscale admin console device list. Revoke anything unrecognized or decommissioned.

Spend monitoring. Weekly review of LLM provider spending dashboards. Unusual spikes are frequently the earliest detectable signal of either a runaway loop or an active injection attempt.

Snapshot cadence. Provider-level snapshots on a schedule. Rollback capability to a known-good configuration is the recovery mechanism of last resort when the operator suspects manipulation.

Skill gating. Documented review before enablement. Write down the three questions from Section 10.3.

Periodic self-review. Every few months, read the deployment’s current configuration against this reference. Drift is invisible in the moment and obvious in hindsight.

12. Posture Summary

A deployment implementing this reference ends at a defensible posture across three domains.

Network. No public SSH. No public admin UI. Mesh VPN as sole ingress. Edge firewall behind host controls. The agent process runs unprivileged and cannot rewrite its own containment.

Identity and credentials. Dedicated bot identity for control plane. Capped or subscription-bounded model access. Scoped tokens for each integration. Dedicated accounts for every integration the agent reads from or writes to.

Input trust. Operator-mediated content forwarding as the primary ingestion path. Skill catalog curated explicitly. Egress allowlisting where stakes warrant. Reversibility designed into every credential and integration decision.

What this posture does not provide: certainty that the agent will never follow an injected instruction, centralized audit for enterprise compliance, or a substitute for the identity architecture work that multi-agent enterprise deployments require. Those are governance problems that individual deployment patterns cannot solve. The architecture here bounds blast radius; it does not eliminate it.

For operators whose deployments will expand toward multi-agent topologies, cross-vendor handoffs, or enterprise data integrations, the next architectural concerns are trust budgeting between agents, protocol-level identity propagation, and the maturity assessment framework for evaluating where the deployment sits on the enterprise readiness curve. Those are covered in adjacent frameworks on this publication.

If readers identify gaps, failure modes, or operational edge cases not addressed in this reference, the feedback channel is open. Reference architectures improve faster when the community that operates them pushes back.