Security · Architecture

Isolation by default, a gate on every channel.

How a ControlClaw deployment is laid out, who holds which keys, and what each party can and cannot see. Written for the person who has to sign off on it.

Last reviewed November 2026
Principles

Security by architecture, not by policy.

Guardrails that live in the firewall VM and the enclave, not in a system prompt the agent is asked to follow.

Get started

Vaulted credentials

Passwords, OAuth tokens and model keys live in the firewall and are injected per request. Agents never hold them.

Human approval

Your Allow / Ask / Block rules decide; anything marked Ask waits for your yes before it leaves the enclave.

Not readable by us

Disks are encrypted with your passphrase and there is no SSH or console access, so ControlClaw staff cannot read agent memory or files.

Isolated machines

One VM per agent with no inbound ports. A compromised agent cannot reach another's machine, only the firewall.

Overview

Three zones, one way out.

Your agents run on their own machines inside an encrypted enclave. The only route to the internet passes through a dedicated firewall VM that applies your policy and writes the log.

Your encrypted enclave
AgentsIsolated VMs
Dedicated firewall
  • AllowEmail @yourcompany.com
  • AskPayments over $50
  • BlockExternal meeting invites
  • BlockUploads to unknown sites
  • AllowWeb research with Perplexity
LogsTrack every action
InternetSites, apps, APIs
  • One machine per agent, encrypted disk, hosted in the US, EU or UK.
  • No SSH or console access to the machines, so not even ControlClaw staff can log in.
  • The enclave key is generated on signup and held only by you.
  • The Firewall holds passwords and logins; agents never see them.
  • Private shell over your own Tailscale network when you want to look inside.
  • ControlClaw Firewall is open source, written in Rust.
Trust boundaries

Who holds which keys.

From the outside in. Each layer only sees what the layer above hands it.

01

Control plane

Operated by ControlClaw

Your account, billing, team members and policies. It sends policy and update instructions into your enclave and receives health signals and the log index. It never holds your enclave key, so it cannot read agent memory, files or backups.

02

Encrypted enclave

Key held by you

A private network created on signup, one per account. Disks inside are encrypted with a key derived from your passphrase. Nothing inside the enclave is reachable from the public internet.

03

Agent machines

One VM per agent

Standard OpenClaw with your skills, plugins and memory. No inbound ports, no credentials on disk. A compromised agent cannot reach another agent's machine: they only share the firewall.

04

Firewall

Separate VM, inside the enclave

Every outbound request from every agent passes through it. It injects credentials, applies your Allow / Ask / Block rules, scans content, and writes the action to the audit log before forwarding.

05

Internet

Your model keys, your OAuth apps

Model providers, email, calendars, websites. All traffic arrives from the firewall under credentials you own, so revoking access is a change in your provider, not a ticket with us.

Visibility

What ControlClaw can and cannot see.

We can see

  • Account, billing and team membership
  • Which templates and policies you have enabled
  • Machine health: up, down, disk, last update
  • Log metadata: timestamps, verdicts, domains, counts

We cannot see

  • Agent memory, files, conversations
  • Your emails, calendar, documents or browser sessions
  • Passwords, OAuth tokens or model API keys
  • Backup contents, which only open with your key
Threat model

What it protects against, and what it doesn't.

Designed for: prompt injection that tries to exfiltrate data through a tool call; a plugin or skill that misbehaves; an agent that takes an irreversible action without a human; one compromised agent pivoting to another; a ControlClaw employee or a subpoena to ControlClaw trying to read your data.

Not designed for: a model provider misusing prompts you send it (that relationship is under your keys and their terms); a user with your enclave passphrase; actions you have explicitly set to Allow; vulnerabilities in the websites your agent is allowed to reach.

Details and open issues live in the public repository. If you find something we missed, see responsible disclosure.

Read enough? Spin one up and inspect it yourself.