DoneClaw Encryption and Sandboxing Explained

Defense in Depth — The Layered Security Model

DoneClaw does not rely on a single security mechanism. Instead, it uses defense in depth — multiple independent layers where each layer provides protection even if another is bypassed. This is the same principle used in enterprise security architectures and critical infrastructure protection.

The layers, from outermost to innermost, are: TLS encryption for all network traffic, API gateway authentication, Docker container isolation with Linux namespaces, network sandboxing between containers, encrypted storage volumes, and per-container API key isolation. A threat would need to bypass every layer to access your data.

Each layer is described in detail in the sections below. The goal is not just to tell you that DoneClaw is secure, but to show you the specific mechanisms and let you evaluate them on their own technical merits.

Docker Container Isolation

Every DoneClaw user runs inside a dedicated Docker container. Docker containers use several Linux kernel features to create isolated execution environments that are lighter than virtual machines but provide strong process-level separation.

Each container gets its own PID namespace, meaning processes inside the container can only see other processes in the same container. Your agent's processes are invisible to every other container on the host. A compromised container cannot enumerate, signal, or attach to processes belonging to other users.

The filesystem is similarly isolated. Each container has its own root filesystem created from the OpenClaw Docker image, plus a dedicated Docker volume for persistent data. File operations inside the container cannot escape to the host filesystem or access other containers' volumes. Docker's overlay filesystem ensures that even the base image layers are read-only and shared safely between containers without cross-contamination.

Memory isolation is enforced by the kernel. Containers have separate memory spaces with configurable limits. One container cannot read another container's memory, and memory-based attacks like Spectre or Rowhammer are mitigated by the process separation that namespaces provide.

• PID namespace — processes invisible across containers
• Mount namespace — filesystem isolation with overlay FS
• Memory isolation — separate address spaces per container
• Resource limits (cgroups) — one container cannot starve others

Linux Namespaces — Kernel-Level Separation

Linux namespaces are the kernel feature that makes container isolation possible. Docker uses six types of namespaces, and each contributes a different dimension of isolation for DoneClaw containers.

The PID namespace gives each container its own process ID space. Process 1 inside the container is the agent's main process, not the host's init system. The mount namespace gives each container its own filesystem view. The network namespace (covered in the next section) gives each container its own network stack. The UTS namespace lets each container have its own hostname. The IPC namespace isolates inter-process communication. The user namespace maps container users to unprivileged host users.

These namespaces are not application-level constructs — they are enforced by the Linux kernel itself. Bypassing them requires a kernel exploit, which is a significantly higher bar than bypassing application-level access controls. The kernel namespace implementation has been hardened over more than a decade of production use across millions of container deployments worldwide.

Namespace Types Used by DoneClaw Containers

| Namespace | What It Isolates            | Security Benefit                          |
|-----------|-----------------------------|-------------------------------------------|
| PID       | Process IDs                 | Cannot see/signal other containers' procs |
| Mount     | Filesystem view             | Cannot access other containers' files     |
| Network   | Network stack               | Own IP, ports, routing table              |
| UTS       | Hostname                    | Cannot impersonate other containers       |
| IPC       | Shared memory, semaphores   | Cannot access other containers' IPC       |
| User      | User/group IDs              | Root in container != root on host         |

Network Sandboxing

Each DoneClaw container has its own network namespace, which means it gets a completely independent network stack — its own IP address, routing table, firewall rules, and port space. Containers communicate with the outside world through a Docker bridge network with strict rules about what traffic is allowed.

Containers on the DoneClaw host are connected via the openclaw-net Docker network, but inter-container traffic is restricted. Your container can reach the internet (to communicate with AI model providers) and accept connections from the gateway reverse proxy (to receive your messages), but it cannot initiate connections to other containers on the same network.

The gateway reverse proxy uses Nginx with wildcard SSL certificates. Each container is reachable via a unique subdomain (e.g., 19189.gateway.doneclaw.com), and the proxy routes traffic to the correct container based on the subdomain. Direct container-to-container communication bypasses this proxy and is blocked by Docker network policies.

Outbound traffic from containers is not restricted by default, since the agent needs to reach model providers and potentially other web services for skills. However, the container's network namespace means it cannot sniff or intercept traffic from other containers — each container sees only its own network traffic.

• Each container has its own IP address and network stack
• Inter-container communication is blocked by Docker network policy
• Inbound traffic routed exclusively through the Nginx gateway proxy
• Containers cannot sniff or intercept other containers' network traffic

TLS Encryption — No Plaintext Anywhere

All data in transit within the DoneClaw system is encrypted with TLS 1.2 or higher. There are three encrypted hops in every message exchange, and none of them fall back to plaintext.

The first hop is from your device (iOS app or web browser) to the DoneClaw backend API, hosted on Cloudflare Workers. Cloudflare enforces TLS on all connections and provides DDoS protection, certificate management, and edge caching. The second hop is from the backend to your container via the gateway reverse proxy. The gateway uses a wildcard Let's Encrypt certificate for *.gateway.doneclaw.com, renewed automatically via the Cloudflare DNS challenge. The third hop is from your container to the AI model provider (e.g., OpenRouter), which also uses HTTPS.

Certificate management is automated end-to-end. Let's Encrypt certificates renew via certbot with the Cloudflare DNS plugin, requiring zero manual intervention. Certificate pinning is enforced on the iOS app for the backend API connection, preventing man-in-the-middle attacks even if a certificate authority is compromised.

Message Encryption Path

Your Device ──[TLS]──> Cloudflare Edge ──[TLS]──> DoneClaw Backend
                                                        │
                                                   [TLS via gateway]
                                                        │
                                                        ▼
                                                  Your Container ──[TLS]──> OpenRouter API

API Key Security

DoneClaw manages several types of API keys, and each one is handled with appropriate security measures. Understanding how keys are stored and transmitted is critical for evaluating the overall security posture.

Your gateway authentication token is generated during provisioning and stored in DoneClaw's D1 database with a unique partial index. This token authenticates requests from the backend to your container. It is generated using cryptographic random bytes and is unique per user — there is no shared token or default credential.

If you use the bring-your-own-key (BYOK) option with a provider like OpenRouter, your API key is stored inside your container's configuration file at ~/.openclaw/config.yaml. It never passes through or is stored in DoneClaw's backend database. When your agent makes an inference request, the key goes directly from your container to the provider.

For users who rely on DoneClaw's managed API access, requests are proxied through the backend, which uses its own OpenRouter API key. In this case, your messages pass through the proxy, but as noted in the privacy section, they are processed in memory and not retained. The proxy's API key is stored as an encrypted Cloudflare Workers secret, not in source code or environment files.

• Gateway tokens — cryptographic random, unique per user, stored with unique index
• BYOK API keys — stored only inside your container, never on DoneClaw servers
• Managed API keys — stored as encrypted Cloudflare Workers secrets
• No default credentials, shared tokens, or hardcoded secrets anywhere in the stack

Container Lifecycle Security

Security extends beyond runtime isolation to the entire container lifecycle: creation, updates, and deletion all have security implications.

When a container is created during provisioning, it is built from a known-good Docker image. The image is pulled from a controlled registry and verified before deployment. Container configuration is generated per-user with unique tokens, ports, and credentials — nothing is shared or reused between users.

Container updates are applied by recreating the container from the latest image while preserving the user's Docker volume. This means the agent's memory and configuration persist across updates, but the runtime environment is always fresh and patched. There is no accumulation of state in the container's root filesystem that could harbor compromised binaries.

When a user cancels their subscription, the container is stopped and removed, and the Docker volume is deleted. This deletion is permanent — Docker volume removal is a destructive operation that deallocates the underlying storage. There is no trash can, recycle bin, or soft-delete mechanism for volumes.

Threat Model and Limitations

No security architecture is perfect, and being transparent about limitations is part of being trustworthy. Here are the threat scenarios that DoneClaw's architecture addresses and those it does not.

DoneClaw protects against: other users accessing your data (container isolation), network eavesdropping (TLS encryption), unauthorized API access (token authentication), data retention by the platform (stateless proxy design), and cross-container attacks (namespace isolation).

DoneClaw does not protect against: a compromise of the host operating system kernel (which could theoretically bypass namespaces), a compromise of DoneClaw's own backend infrastructure (which could intercept messages in transit through the proxy), or a compromise of your AI model provider (which could log your prompts on their end). These are inherent limitations of any managed service architecture.

For users who need protection against even these scenarios, self-hosting OpenClaw on your own hardware with a local model like Ollama provides maximum isolation. DoneClaw is designed for the majority of users who want strong privacy without the operational burden of self-hosting.

Conclusion

DoneClaw's security architecture is built on battle-tested Linux kernel primitives — namespaces, cgroups, and overlay filesystems — combined with TLS encryption at every network hop and strict API key isolation. Each user gets genuine process, filesystem, and network separation enforced by the kernel itself, not by application-level access controls that can be bypassed with a misconfigured permission. This is defense in depth applied to personal AI: multiple independent layers, each sufficient to protect your data even if another fails.

Frequently asked questions