Data leak prevention for OpenClaw: pairing, allowlists, and sandboxing

In January 2026, security researchers reported 42,665 exposed OpenClaw instances, and 93.4% of them were vulnerable to exploitation. That number is ugly because it turns an abstract fear into something concrete. People are not scared of AI agents in the abstract. They are scared of an agent reading the wrong folder, sending the wrong file, or getting turned against them by a prompt hidden in a web page.

That fear is not irrational. OpenClaw can read files, run commands, browse the web, and act through your accounts. If you give it broad access and weak boundaries, you are not running a clever assistant. You are running a small, very confident insider threat.

The good news is that OpenClaw already gives you a decent defense model. You just have to use all of it. Pairing controls who can reach the agent. Allowlists control what the agent can touch. Sandboxing limits the damage if the first two layers fail.

That is the real model for ai agent data leak prevention. No single setting saves you. The combination does.

What is the three-layer model for ai agent data leak prevention?

The three-layer model is simple: control access, restrict reach, and contain damage.

Most OpenClaw mistakes come from treating one layer like a complete solution. Someone enables pairing and assumes they are safe, while the agent still has unrestricted shell access. Someone locks down file paths but leaves direct messages open to anyone who finds the bot. Someone runs in Docker and forgets the workspace is mounted read-write with network access.

Think about the layers this way:

Layer	Question it answers	Main control
Access control	Who can talk to the agent?	Pairing, allowlist, DM policy
Data boundaries	What can the agent reach?	File, domain, binary, and API allowlists
Containment	What happens if the agent is compromised?	Sandbox, read-only mounts, no network

If you only remember one line from this article, make it this: pairing keeps strangers out, allowlists shrink the blast radius, and sandboxing gives you one last wall when the first two fail.

How does OpenClaw pairing allowlist reduce who can reach your agent?

OpenClaw pairing allowlist settings reduce risk by forcing you to decide who gets to talk to the bot before the bot does anything useful.

OpenClaw’s default DM policy is pairing, and that is a good default. Unknown senders get a short pairing code, their message is not processed, and you explicitly approve them. According to the current docs, pairing codes expire after 1 hour and pending DM pairing requests are capped at 3 per channel. That cap matters more than it sounds. It keeps your pairing queue from becoming an unreviewed pile of noise.

For most people, the progression should look like this:

1. Start with pairing while you are testing.
2. Move to allowlist when you know exactly who should have access.
3. Avoid open unless the bot is intentionally public and heavily constrained.
4. Use disabled when the channel should never accept DMs.

A safe Telegram example looks like this:

{
  "channels": {
    "telegram": {
      "dmPolicy": "pairing",
      "allowFrom": ["tg:123456789"]
    }
  }
}

That setup does two useful things at once. Pairing blocks unknown senders. allowFrom pins known users explicitly. If you are the only operator, you can go stricter:

{
  "channels": {
    "telegram": {
      "dmPolicy": "allowlist",
      "allowFrom": ["tg:123456789"]
    }
  }
}

The trap is dmPolicy: "open". Open mode means anyone can message the bot, which is fine only if the bot has almost nothing dangerous attached to it. If your bot can browse authenticated sessions, read local files, or run shell commands, open DMs are not generous. They are reckless.

Channel differences matter too. A Telegram bot handle is easier to stumble across than a private iMessage setup. A Discord bot in a community server has a different threat model than a WhatsApp bot used by one family. You do not need one global policy. You need the right policy per channel.

How should you build allowlists that actually stop leaks?

A good allowlist blocks the obvious path and the annoying side path too.

This is where a lot of security advice gets a little fake. People say “use an allowlist” as if that is one setting you flip once and forget. It is not. In practice you need at least four of them.

First, restrict filesystem access. Your agent should not be able to wander your entire home directory unless you have made a very deliberate choice to allow that.

Second, restrict browser destinations. If the browser tool can visit any hostname on the public internet and any private host on your network, prompt injection is only half the problem. The agent can also exfiltrate data to whatever host it is tricked into trusting.

Third, restrict executable commands. If exec can invoke anything in PATH, you have given the model a universal adapter to your machine.

Fourth, restrict API endpoints. An agent that can call arbitrary webhooks is one typo away from shipping your secrets somewhere you will never notice.

Here is the practical version of that idea:

{
  "tools": {
    "fs": {
      "allowPaths": ["/workspace", "/tmp/openclaw-exports"]
    },
    "browser": {
      "hostnameAllowlist": ["github.com", "docs.openclaw.ai", "api.stripe.com"]
    },
    "exec": {
      "security": "allowlist",
      "allow": ["git", "pnpm", "node", "python3"]
    }
  }
}

The principle underneath all of this is simple: deny always wins. If a path, hostname, or binary is not explicitly needed, do not make it available just because it feels convenient.

Test your allowlists like you do not trust them yet. Ask the agent to read ~/.ssh. Ask it to curl a random webhook. Ask it to open an internal admin panel hostname. If those attempts succeed, the allowlist is not doing its job. It is just making you feel better.

What does an OpenClaw sandbox setup actually protect?

An OpenClaw sandbox setup protects the host by making the agent operate inside a smaller, disposable environment instead of directly on your machine.

The official configuration reference is pretty clear on the basics. Sandboxing in OpenClaw can run per session, per agent, or shared. You can mount the workspace as none, ro, or rw. You can make the root filesystem read-only. You can disable network access with network: "none". Those are not cosmetic choices. They decide whether a compromised agent can simply shrug and keep going.

A high-security baseline looks like this:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "session",
        "workspaceAccess": "ro",
        "docker": {
          "readOnlyRoot": true,
          "network": "none",
          "capDrop": ["ALL"]
        }
      }
    }
  }
}

That configuration does three useful things.

It gives each conversation its own container. It makes the main filesystem read-only. And it cuts outbound network access entirely. If the agent gets tricked by malicious content, the attacker is stuck in a much smaller box.

A medium-security setup might loosen one or two of those knobs:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main",
        "scope": "agent",
        "workspaceAccess": "rw",
        "docker": {
          "readOnlyRoot": true,
          "network": "bridge"
        }
      }
    }
  }
}

That is useful when the agent needs to write files and reach approved services, but it is a real downgrade. Once network is back and the workspace is writable, you are relying much more heavily on your allowlists.

There is also an uncomfortable point worth saying plainly: sandboxing is not perfect. CVE-2026-24763, fixed in OpenClaw 2026.1.29, was a command injection flaw in the Docker sandbox execution path. That does not make sandboxing pointless. It means you should not treat the sandbox like magic. Containers reduce damage. They do not remove the need to patch, monitor, and restrict inputs.

When should you skip sandboxing?

You should skip sandboxing only when you fully understand what you are giving up.

There are legitimate reasons. Some workflows need host tools, hardware access, or a real desktop session. Some people are still debugging local setups and want fewer moving parts. That is fine for a short period.

But if you skip sandboxing, compensate aggressively elsewhere:

• Keep dmPolicy on pairing or allowlist
• Cut the browser hostname list down hard
• Restrict exec to a short binary allowlist
• Keep the agent on a separate machine or separate user account
• Patch quickly when OpenClaw ships a security fix

What you should not do is run unsandboxed, with open DMs, broad file access, and unrestricted outbound network because “it is just for me.” That is how people become incident reports.

What are the safest default settings for most people?

The safest default OpenClaw settings for most people are dmPolicy: "pairing", a short allowFrom list for known users, a narrow file and hostname allowlist, and a session-scoped sandbox with a read-only root filesystem.

If you want a quote-friendly baseline, start here:

• Use dmPolicy: "pairing" on every channel that accepts direct messages
• Move to allowlist when you know the exact user IDs or phone numbers
• Keep filesystem access limited to one workspace like /workspace
• Keep browser access limited to the few domains the workflow really needs
• Use network: "none" in the sandbox unless the task truly needs outbound access
• Keep readOnlyRoot: true and drop Linux capabilities with capDrop: ["ALL"]
• Patch OpenClaw quickly when a security release lands, especially anything like 2026.1.29 that closes a sandbox or gateway issue

That setup is not perfect, but it is a strong starting point. More importantly, it is understandable. You can explain what the agent can do, who can reach it, and what happens if it misbehaves.

What should your secure configuration look like in practice?

Your secure OpenClaw configuration should match your risk level, not your ambition.

If you are handling client documents, company code, or anything you would hate to see on the wrong screen, use the strict profile.

Profile	Best for	Core choices
High security	Sensitive work, regulated data, team environments	Pairing or allowlist, session sandbox, read-only workspace, no network
Medium security	Personal productivity, research, light automation	Pairing, agent sandbox, restricted network, narrow allowlists
Low security	Experiments only	Separate machine, fresh accounts, no sensitive data

A high-security mental model looks like Claire Vo’s setup from Every’s OpenClaw coverage. She treated the agent like a new employee with its own Google Workspace account, scoped calendar access, and documents shared explicitly. That pattern matters because it keeps identity separation outside the model itself. Even if the agent behaves badly, it is still operating inside a smaller trust zone.

That is the goal. Not some fantasy where the agent becomes perfectly safe. Just a setup where its mistakes stay small, legible, and annoying instead of expensive.

How do you detect leaks before they become disasters?

Leak detection starts with watching for behavior that does not fit the agent’s normal job.

You do not need a giant security program to catch useful signals. Start with a short list:

• File access outside the expected workspace
• Sudden outbound traffic to unknown domains
• API key usage spikes
• New pairing approvals you do not recognize
• Repeated attempts to execute blocked binaries
• Browser sessions visiting domains outside your approved list

The key is to log enough to answer a simple question later: what did the agent try to do, and did it succeed?

Without logs, an incident becomes a horrible guessing game. You revoke keys, rotate tokens, and still do not know whether anything actually left the box.

Regular review helps more than fancy tooling here. Once a week, skim the logs. Look at pairing files. Check allowlist changes. Confirm the running version. It is boring work. That is why it saves people.

What should you do when one of the layers fails?

When one layer fails, assume the others are now under pressure and respond fast.

If you suspect a leak, do the boring emergency steps first:

1. Stop the gateway or pause the agent.
2. Revoke API keys and session tokens.
3. Remove or disable risky tools.
4. Check logs for outbound requests, file reads, and command execution.
5. Patch OpenClaw if you are behind on security releases.
6. Rebuild the sandbox or machine if you cannot explain what happened.

If the breach came through messaging access, clear pending pairings and review approved senders. If it came through a browser or tool path, tighten the relevant allowlist before you bring the agent back. If it came through the sandbox, treat the host as potentially touched and respond at the host level, not just the container level.

This is the part people skip because they want certainty before acting. Do not wait for certainty. An AI agent can move faster than your postmortem.

What is the simplest safe takeaway?

The simplest safe takeaway is that data leak prevention in OpenClaw works best when you combine pairing, allowlists, and sandboxing instead of arguing about which one matters most.

Use pairing to make access explicit. Use allowlists to make reach narrow. Use sandboxing to make mistakes survivable.

If you are setting up a new agent this week, start here: keep DMs on pairing, allowlist only the paths and domains you truly need, and enable a session-scoped sandbox with a read-only root filesystem. That alone will put you in a much better place than the people who ended up in that 42,665-instance headline.

OpenClaw is useful because it can actually do things. That is also why bad boundaries matter so much. The moment it can act, it can leak.