OpenClaw on Cloudflare: Complete Deployment Security Checklist

OpenClaw is an autonomous personal AI agent: it can connect to chat platforms, maintain conversation state, browse, and invoke tools. That flexibility is also its security boundary. If an attacker reaches the gateway, steals an OAuth token, poisons a skill, or tricks the model through an indirect prompt injection, the attacker may inherit the permissions you gave the agent.

This guide explains how to deploy OpenClaw with Cloudflare and how to harden the complete path from remote browser to agent runtime. It covers Cloudflare Tunnel for private remote access, the Cloudflare Workers and Sandbox architecture used by Moltworker, authentication, secrets, OAuth tokens, prompt injection, malicious skills, and exposed admin-panel response. For a dedicated Docker hardening guide, see OpenClaw Docker Deployment Security.

Important: Cloudflare Access, Tunnel, Workers, Sandboxes, and Docker reduce exposure and blast radius. None of them makes an autonomous agent automatically safe. Treat Moltworker as experimental, verify its current README before deployment, and test every control in your own environment.

What to Remember

• Tunnel is not authentication: Cloudflare Tunnel removes the need for a publicly routable origin, while Cloudflare Access decides which identities may reach the application.
• Workers are the control plane: In the Moltworker pattern, a Worker receives requests and coordinates a Cloudflare Sandbox or Container where OpenClaw runs.
• Use layered authentication: Protect administrative routes with Access, protect remote gateway access with the gateway token, and approve devices through pairing.
• Secrets are high-impact permissions: API keys, R2 credentials, channel tokens, OAuth refresh tokens, and browser/CDP secrets should be scoped, rotated, and kept out of logs and URLs.
• Prompt injection is an authorization problem: A model can follow malicious instructions contained in a web page, message, document, or skill. Limit what tools can do even when the model is manipulated.
• Docker is not a complete boundary: If you run OpenClaw yourself, follow the dedicated OpenClaw Docker security hardening guide.
• An exposed admin panel is an incident: Follow the dedicated OpenClaw exposed admin-panel response checklist to contain access, rotate credentials, investigate, rebuild, and verify recovery.

OpenClaw on Cloudflare Workers: Architecture, Limits and Security

Cloudflare Workers are the edge control plane: they receive HTTP and WebSocket requests, apply application logic, and connect to Cloudflare services through bindings. They are not equivalent to a general-purpose VPS and are not where a full Linux agent process should be assumed to run.

Moltworker uses a Worker with a Cloudflare Sandbox/Container for the OpenClaw gateway. In simplified form:

• Worker: Receives requests, proxies the gateway, validates Access credentials, and coordinates lifecycle operations.
• Sandbox or Container: Runs the OpenClaw process in an isolated managed execution environment.
• R2: Optionally stores backups of configuration, paired devices, and conversation state. The current Moltworker implementation uses backup/restore synchronization; R2 should not be described as a native local filesystem mount.
• Browser/CDP integration: Provides browser automation capabilities when explicitly configured. Treat CDP as a privileged interface requiring a separate secret and strict exposure controls.
• Access: Protects administrative routes and the identity boundary before requests reach the application.

The Worker and the Sandbox have different limits. Cloudflare documents Workers Paid limits such as a default 30-second CPU limit that can be increased up to five minutes, 128 MB per isolate, request/subrequest limits, and environment-variable limits. Sandbox or Container memory, CPU, disk, sleep behavior, cold starts, and cost are separate concerns. Do not promise that a Worker can host an unlimited long-running process merely because an HTTP request can stream.

Moltworker’s README documents a Workers Paid requirement for Sandbox containers, additional container charges, and cold starts that may take one to two minutes. Configure an idle sleep timeout only after testing reconnects, scheduled jobs, device pairing, and R2 restore behavior. A sleeping container may reduce cost but increases recovery latency.

OpenClaw Security Hardening Checklist

Before production access, verify each item:

• The exact OpenClaw/Moltworker version and image digest are recorded.
• The Control UI, gateway, WebSocket, admin, API, debug, and CDP routes are inventoried.
• No origin port is publicly reachable outside the intended Cloudflare path.
• Tunnel uses a named configuration with explicit ingress rules, when Tunnel is used.
• Cloudflare Access protects administrative and sensitive routes.
• MFA or an appropriate strong identity provider is required.
• Gateway token is random, stored as a secret, and absent from logs and bookmarks.
• Device pairing is enabled and unknown devices are removed.
• DEV_MODE is disabled outside local development.
• Debug routes are disabled or separately protected.
• R2 credentials are scoped to the required bucket and permissions.
• Provider, channel, OAuth, CDP, and Cloudflare credentials are inventoried and rotatable.
• Skills, dependencies, images, and configuration changes are reviewed and pinned.
• Shell, browser, filesystem, and messaging tools are allowlisted.
• Destructive actions require human approval.
• Container execution is non-root where supported and has no dangerous host mounts.
• Egress, cost, cold-start, log, and backup behavior is monitored.
• An incident procedure exists for credential revocation, device removal, R2 review, and redeployment.

Cloudflare Deployment Workflow

The exact Moltworker command set can change. The current repository documents a flow similar to this:

1. Clone the official repository and install dependencies.
2. Choose direct provider authentication or the current AI Gateway configuration.
3. Create a random gateway token and store it with Wrangler.
4. Deploy the Worker with the repository’s documented deployment command.
5. Enable Cloudflare Access for the Worker hostname or create a self-hosted Access application.
6. Set CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD, then redeploy.
7. Pair only known devices through /_admin/.
8. Configure R2 with a bucket-scoped Object Read & Write token if persistence is required.
9. Add chat channels, browser automation, or skills one at a time and test each boundary.
10. Record the resulting architecture, versions, routes, secrets, policies, and rollback procedure.

Do not paste live secrets into a tutorial or commit .dev.vars. Cloudflare’s documentation recommends .dev.vars or .env only for local development, with those files excluded from Git. Use the current repository README and Cloudflare documentation for the exact command and variable names at deployment time.

Cloudflare Workers hardening

• Use a dedicated Cloudflare account or project boundary for the agent where possible.
• Keep Worker secrets out of vars, source control, build output, and client-side code.
• Declare required secrets when supported so deployment fails early when configuration is incomplete.
• Restrict Access policies to administrative users and protect sensitive routes explicitly.
• Keep debug routes disabled unless they are required and protected by Access.
• Monitor Worker logs, Access events, container lifecycle events, R2 writes, and unusual egress.
• Treat R2 backups as sensitive copies of the agent, not as harmless operational data.

Cloudflare Tunnel Setup: Secure Remote Access

Cloudflare Tunnel connects an origin to Cloudflare through outbound-only connections created by cloudflared. The origin does not need a publicly routable IP, and a firewall can deny unsolicited inbound connections while allowing the tunnel connector to reach Cloudflare.

Tunnel is useful when OpenClaw runs on a private VM, home server, or Docker host and you need remote access without forwarding a port from the Internet directly to the host. The secure request path is:

1. A user requests an OpenClaw hostname.
2. Cloudflare Access evaluates the user, identity provider, device and policy context.
3. Cloudflare sends permitted traffic through the Tunnel.
4. cloudflared forwards only the configured hostname and service to the private OpenClaw origin.
5. The origin accepts traffic only from the intended tunnel path and still enforces its own application authentication.

Tunnel does not replace Access

A Tunnel provides connectivity; it does not by itself prove that the person opening the Control UI is authorized. Put an Access application in front of the OpenClaw hostname and restrict it to a small allowlist or group. Configure MFA or a phishing-resistant identity provider where practical, and protect only the routes that need remote administration.

Avoid publishing the gateway directly with a broad 0.0.0.0 bind, a forwarded router port, or an unauthenticated trycloudflare.com URL. For a long-lived deployment, use a named tunnel, a controlled hostname, explicit ingress rules, and a service account with only the permissions needed by the connector.

Tunnel deployment checklist

• Keep the OpenClaw listener private to the Docker network or loopback where possible.
• Allow outbound traffic required by cloudflared; block unrelated inbound traffic.
• Put Access in front of /_admin/, /api/, /debug/, the Control UI, and WebSocket paths as appropriate.
• Do not place gateway tokens in bookmarks, screenshots, analytics, referrer headers, or chat messages.
• Log tunnel and Access events, but redact query strings, authorization headers, and token values.
• Test the origin directly from an external network; it should not be reachable without the intended Cloudflare path.

Authentication: Access, Gateway Tokens and Device Pairing

A robust remote deployment uses several distinct controls:

1. Cloudflare Access authenticates a human or approved identity before administrative routes are reachable. Cloudflare One supports identity providers including OIDC, SAML, and email OTP.
2. Gateway token authenticates remote access to the OpenClaw Control UI and gateway. Moltworker documents MOLTBOT_GATEWAY_TOKEN for this purpose; verify the current name before deployment.
3. Device pairing requires a new browser, CLI, or channel device to be explicitly approved through the admin UI. A valid gateway token does not necessarily remove the pairing requirement.
4. Channel policies control whether messaging integrations use pairing or an unsafe open mode. Keep pairing as the default unless there is a documented reason to change it.

For the Moltworker Access validation flow, the documented secrets are CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD. Configure the Access application first, copy the application audience tag, set both secrets with Wrangler, and redeploy. Protect administrative paths such as /_admin/*, /api/*, and /debug/* in the Access application.

Do not confuse authentication with authorization. Passing Access and the gateway token should not automatically grant an agent unrestricted shell, filesystem, browser, messaging, or cloud permissions. Apply least privilege to the tools and integrations after the user is authenticated.

Secrets, OAuth and Token Security

Cloudflare Workers secrets are encrypted values intended for API keys and authentication tokens. Use wrangler secret put or the dashboard’s secret settings; do not put sensitive values in plaintext vars, committed .env files, Docker image layers, shell history, or public configuration.

Typical Moltworker secret groups include:

• Provider access: ANTHROPIC_API_KEY, OPENAI_API_KEY, or the current AI Gateway configuration.
• Gateway and Access: MOLTBOT_GATEWAY_TOKEN, CF_ACCESS_TEAM_DOMAIN, and CF_ACCESS_AUD.
• Persistence: R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, and CF_ACCOUNT_ID.
• Integrations: Telegram, Discord, Slack, CDP, and worker URL secrets.

Use one credential for one purpose. For R2, prefer an Object Read & Write token scoped to the single persistence bucket instead of an account-wide administrator token. For OAuth integrations, request the smallest useful scopes, store refresh tokens as secrets, rotate them after an incident, and revoke grants when an integration is removed. A refresh token can be more valuable than a short-lived access token because it can create new sessions.

The safest secret is one the agent cannot read or use for unrelated tasks. Do not give the model direct access to the Worker secret environment, Docker socket, Cloudflare API token, R2 administrative API, or personal SSH keys. If OpenClaw needs an API, create a narrowly scoped intermediary service rather than exposing a master credential.

AI Gateway and provider keys

Cloudflare AI Gateway can provide routing, analytics, caching, rate controls, and cost visibility, but it does not eliminate the provider credential. Verify whether the current Moltworker version expects CLOUDFLARE_AI_GATEWAY_API_KEY, CF_AI_GATEWAY_ACCOUNT_ID, and CF_AI_GATEWAY_GATEWAY_ID, or direct provider variables. Do not blindly copy configuration from an older Clawdbot or Moltbot deployment.

Prompt Injection and Malicious Skill Security

Prompt injection occurs when untrusted content is interpreted as an instruction. An OpenClaw agent may encounter hostile text in a web page, email, document, issue, chat message, skill README, or tool response. The attack does not need to break the model; it only needs to influence the next action.

A malicious skill is a related supply-chain risk. A skill may contain instructions, scripts, dependencies, or requests for credentials. Review its source, pin its version, inspect install and update behavior, and run it with the smallest tool and filesystem permissions possible.

Use these controls together:

• Separate untrusted content from trusted instructions with clear boundaries and explicit source labels.
• Treat web pages, messages, documents, and skill output as data, not authority.
• Allowlist tools, domains, commands, paths, and API operations.
• Require human approval for deletion, sending messages, financial actions, credential changes, deployments, and shell commands with irreversible effects.
• Prevent arbitrary skill installation and automatic updates in production.
• Restrict outbound network access and alert on unusual destinations or data volume.
• Keep the runtime sandboxed, but assume the agent can still exfiltrate any credential or data it is allowed to reach.
• Test with prompt-injection fixtures before enabling a new integration.

System prompts help establish behavior but are not access-control mechanisms. The enforcement point must be the tool gateway, policy layer, container, network, or human approval step.

Exposed Admin Panel: Detection and Remediation

If an OpenClaw, Clawdbot, or Moltbot admin panel was exposed to the Internet, treat the deployment as potentially compromised. Use the dedicated OpenClaw Compromised? What to Do After a Security Incident article for the complete incident-response runbook.

At a minimum, immediately restrict public routing, preserve relevant Access, Tunnel, Worker, origin, and Gateway logs, rotate every credential reachable by the agent, remove unknown paired devices, rebuild from reviewed and pinned sources, and test unauthenticated access before restoring integrations.

Limitations and Security Boundaries

Cloudflare Tunnel does not inspect model intent. Access does not prevent an authorized user from asking the agent to perform a dangerous task. Workers do not automatically isolate every integration. Sandboxes reduce host exposure but can still contain sensitive data and credentials. R2 persistence preserves state and therefore preserves compromised state if you restore it blindly. Docker limits process isolation but does not make a privileged container trustworthy.

The objective is not to claim that OpenClaw is risk-free. The objective is to create independent controls so that a stolen token, manipulated prompt, compromised skill, or vulnerable dependency does not immediately become access to your laptop, private network, cloud account, or all connected services.

Conclusion

OpenClaw can be remotely useful without placing an unauthenticated autonomous gateway on the public Internet. A hardened design combines a private origin or Cloudflare Sandbox, outbound-only Tunnel connectivity where appropriate, Cloudflare Access, gateway authentication, device pairing, scoped secrets, reviewed skills, controlled tools, and a tested incident plan.

The names Clawdbot, Moltbot, and OpenClaw may change as the project evolves. The security fundamentals do not: verify every access request, minimize permissions, isolate execution, protect credentials, control egress, and assume untrusted content can manipulate the model.

For the original Cloudflare deployment overview, see Deploy OpenClaw securely on Cloudflare. For the broader agent threat model, read Building Secure Agentic Applications and Clawdbot Security.

To further enhance your cloud and AI-agent security, contact me on LinkedIn or [email protected].

Frequently Asked Questions (FAQ)

Is Cloudflare Tunnel required to run OpenClaw on Cloudflare Workers?

No. The Moltworker reference deployment uses a Worker URL and Cloudflare Access. Tunnel is most useful when OpenClaw runs on a private VM, home server, or Docker host and you need remote access without exposing an origin IP or inbound port.

Does Cloudflare Tunnel replace OpenClaw authentication?

No. Tunnel provides the network connection. Cloudflare Access authenticates users before they reach protected routes, while the gateway token and device pairing provide additional OpenClaw authentication controls.

What is the difference between OpenClaw, Moltbot and Clawdbot?

They are names used by the same evolving personal AI-agent project and related deployments. Check the current OpenClaw and Moltworker documentation for migration notes, package names, configuration variables, and security changes instead of assuming an older deployment is current.

How should I secure OpenClaw secrets and OAuth tokens?

Use Worker or platform secrets rather than plaintext variables or committed files, scope R2 and provider credentials to the smallest useful permissions, avoid putting tokens in URLs and logs, and revoke and rotate credentials whenever an instance, skill, device, or integration may have been compromised.

Can prompt injection bypass a Cloudflare Sandbox?

A prompt injection can still manipulate an agent inside a sandbox. Sandboxing reduces access to the surrounding host and network, but it does not prevent the agent from misusing tools, reading permitted data, or exfiltrating credentials that were made available to it.

What should I do if an OpenClaw admin panel was exposed?

Treat it as a potential security incident: contain access, preserve logs, rotate reachable credentials, remove unknown devices, rebuild from trusted sources, and test the recovered deployment externally. See the dedicated exposed admin-panel response checklist for the complete runbook.

Is Docker alone enough to secure OpenClaw?

No. Docker should be hardened with non-root execution where supported, minimal pinned images, dropped capabilities, resource limits, restricted mounts, controlled egress, secret isolation, and a protected network entry point. The agent still needs least-privilege tools and human approval for high-impact actions.

Official Resources

• OpenClaw project
• OpenClaw documentation
• Cloudflare Moltworker
• Cloudflare Tunnel
• Cloudflare Workers
• Workers platform limits
• Workers secrets
• Cloudflare Access identity providers
• Cloudflare Sandbox
• Cloudflare R2 authentication and permissions
• Cloudflare AI Gateway