The short version
ControlClaw hosts AI agents for teams. Each organisation gets its own machines: one box per agent, plus a firewall box that sits between those agents and the internet. Most of what you would think of as your data lives on those machines rather than in our database, and the architecture is built so that we cannot read it.
- What you say to an agent, the files it works on and its memory stay on your box. The console talks to your box directly. That traffic does not pass through us.
- Your agents’ credentials live on your firewall box — model provider keys, channel logins, app connections, your Google account’s tokens. An agent only ever holds a placeholder; the firewall swaps in the real secret as the request leaves.
- We do hold your account and your organisation’s settings, billing references, and a metadata-only log of which hosts your agents connected to.
- We do not sell personal data, and neither your data nor your agents’ Google data is used for advertising or to train models.
The rest of this page is the detail, including the places where the boundary is not absolute.
Who we are
ControlClaw is operated by [legal entity name], registered at [registered address]. For the personal data described here we are the controller, and for the content your agents handle on your behalf we are a processor acting on your instructions.
Privacy questions, requests and complaints: [privacy contact email].
What we store
This is what is in the control plane — the web app at controlclaw.com and its database.
- Your account. Name, email address, a profile picture if you upload one, and the records behind sign-in: a password hash if you set one, and the one-time tokens for sign-in links and email verification.
- Sessions. A session token, plus the IP address and browser user-agent of each sign-in.
- Your organisation. Its name, its members and their roles, and the invitations you send, which include the invited person’s email address.
- Billing. Plan, subscription status, seats, usage counters, and the Stripe customer and subscription ids. Card details never reach us — Stripe handles the payment and holds the card.
- Your agents and firewall. Each box’s name, hostname, size, region, status, the software version it reports, and the public keys it uses to prove who it is.
- Activity. One row per outbound request your agents made, holding a one-line summary such as
GET api.github.com/repos/xand whether it was allowed, blocked or held for your approval. It never holds request bodies, header values, query strings, tool arguments or message text. - Audit events. Who changed what in the console, and when.
- Secrets we pass on. When you paste a model provider key or connect a channel, that secret is encrypted before it is written and is delivered to your firewall over a queue; for most kinds the copy in our database is wiped as soon as the firewall has collected it. Where we keep one, it is encrypted at rest, and the console only ever shows a fragment of it back to you.
- Backups. Your backups are encrypted on your box, with a key we do not hold, before they are uploaded. We store the resulting bytes, their size and a manifest hash. We cannot read them.
- Support conversations, if you use the chat widget in the console.
What stays on your own machines
None of the following is in our database, and a compromise of our control plane would not produce it.
- Your agents’ conversations. When you click Open, we sign a one-minute, single-use ticket for that specific box; your browser then talks to the box. The agent’s own pairing token lives in a file on the box and never leaves it.
- Files and memory. Everything an agent writes, downloads or clones, and what it remembers of past work. When you browse files in the console, the bytes go from the box to your browser — we see the hostname and nothing else.
- Credentials. Model provider keys, channel logins, app connections and Google tokens are held by your firewall box and swapped in as a request leaves it. Taking access away from an agent happens on the firewall, so it takes effect even if that agent’s box is offline.
- Prompts. On the included-tokens plan, a request goes from your agent box to your firewall and out to the model gateway. It does not pass through us. We can create, re-budget and delete your organisation’s gateway key; we cannot read what your agents say.
The honest exceptions to all of this are Who at ControlClaw can see what. They are two, they are narrow, and both are visible to you.
Where it is hosted
- Control plane — Vercel (United States, plus its global edge network).
- Database — Neon Postgres, provisioned through Vercel, in [database region].
- Your agent, firewall and proxy boxes — Hetzner Cloud, Nuremberg, Germany. A US region is planned and is not live.
- Encrypted backups — Amazon S3, eu-west-1 (Ireland). Ciphertext only.
Several of the companies below are outside the EEA and the UK, so using ControlClaw involves an international transfer of personal data. We rely on [transfer mechanism].
Who else processes it
- Vercel — hosting for the control plane, plus its analytics and performance measurement, and the AI Gateway behind the included tokens.
- Neon — the Postgres database.
- Hetzner Cloud — the machines your agents and firewall run on.
- Amazon Web Services — DNS for controlclaw.com and the object store holding your encrypted backups.
- Stripe — payments and card handling.
- Inngest — the queue behind the work that runs on a schedule or in the background: provisioning a box, daily backups, pruning old activity, expiring a shell grant. Its events carry organisation, user and box identifiers.
- Resend — the transactional email listed under What we use it for.
- Sentry — error monitoring. Session replay only when an error happens, with text and inputs masked and media blocked, and without your IP address, headers or cookies. See Cookies and analytics.
- Intercom — the support chat widget, loaded only if you accept the banner. When you are signed in and it loads, it receives your user id, email address, name and sign-up date.
- Google — the tag manager, analytics and advertising tags, loaded only on our home page and only if you accept the banner. They are never loaded in the console.
- Model providers — reached through the Vercel AI Gateway when you use the included tokens, or directly with your own key. Their terms govern what they do with a prompt. We are not on that path.
- Tailscale — only if you choose to join a box to your own tailnet.
We do not publish a data processing agreement yet. If you need one, or an up-to-date subprocessor list under contract, ask at [privacy contact email].
Google user data
You can give your agents a Google account, so they can work with its mail, calendar, files, contacts and documents. Two things about how that is built matter more than anything else on this page.
The OAuth app is yours, not ours. You create a client in your own Google Cloud project and paste it in. The consent screen names your project. The account’s refresh and access tokens are held by your firewall box and are handed only to the agents you tick.
ControlClaw never holds or reads that data. We have no copy of the tokens, and the mail, events, files and contacts your agents read travel between your box and Google. Nothing about a Google call reaches us except the one-line activity summary described above — the host and the path.
Limited Use
ControlClaw’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:
- Google user data is used only to provide or improve the features you switched on.
- It is not transferred to anyone except as needed to provide those features, with your consent, or where the law requires it.
- It is not used for advertising.
- It is not used to develop, train or improve generalised AI or machine learning models.
- No human reads it, other than with your consent, for security, or where the law requires it.
Two things to be clear about
Your own agents do send it to a model. If you ask an agent to summarise an email, the text of that email goes to whichever model provider you configured, because that is what you asked for. That is your choice and your provider relationship, not a transfer by us — but it is worth knowing, and it is why the account you connect should be a separate one made for your agents rather than your own.
A support shell reaches the credential. If you grant the time-boxed session described under Who at ControlClaw can see what on your firewall box, whoever takes it can read what that box holds, including the Google tokens, for the length of the window. It takes your confirmation code, every owner is emailed, and it closes itself. The console says so in those words before you press the button.
Disconnecting in ControlClaw makes your firewall forget the account, which stops every agent at once. To make Google forget the app as well, remove its access at myaccount.google.com/permissions.
What we use it for
- Running the service: creating and managing your boxes, drawing the console, routing you to your own machines.
- Signing you in: sign-in links and email verification.
- Billing you, and counting the usage your plan includes.
- Telling you things that matter: an invitation, an allowance nearly spent, a firewall put back from a backup, a shell granted on one of your boxes.
- Keeping it working: error reports, rate limits, and stopping abuse.
- Understanding how the marketing site is used.
There is no marketing mail, no bulk mail and no mailing list. Every email we send is triggered by something you just did.
Who at ControlClaw can see what
An internal admin panel. Staff with a system role can list every organisation, user, agent and box, and run a short set of repair actions. It shows metadata — names, statuses, versions, quotas — not your agents’ conversations or files. Every write action is logged.
No standing way onto your boxes. No key of ours ships with a production box, provisioning adds none, and port 22 is closed at the firewall. Nothing we hold — not the database, not our signing key — can put a key on a box. The configuration that builds every box is a public repository, so this is checkable rather than a promise.
Support access, when you grant it. You can open a time-boxed shell session on one of your boxes. It takes a six-digit code that your firewall sends over a channel you approved, the key is generated on the box itself, the box closes the window with its own timer, every owner of the organisation is emailed before the key is handed over, and it appears on your Activity page. On a firewall box that session can read the credentials that box holds; the console says so before you confirm.
Operator snapshots, and an honest caveat. To recover a box after a bad update or a mistaken delete, an operator with the highest system role can image the whole machine at the cloud provider. Disks are not yet encrypted, so such an image is a readable copy of that box’s disk. It is never taken automatically unless that is switched on, it is limited to three per box and fourteen days, and every one is logged and scoped to one organisation. Full-disk encryption with a key only the box can unseal is planned, and it removes this.
How long we keep it
- Activity rows — 30 days, then deleted by a nightly job.
- Backups — the last seven days and the last four weeks. Older ones are deleted, and deleting a box deletes its backups.
- A support-access private key — deleted when the window closes.
- Account, organisation and agent records — while your account is open. There is no self-serve delete button yet: ask at [privacy contact email] and we delete the account, its organisations and the rows that hang off them. Deleting an organisation also destroys its boxes.
- Billing records — kept for [billing retention period], because tax and accounting law requires it.
- Error reports and support conversations — held by Sentry and Intercom under their own retention, which is [retention at Sentry and Intercom].
How it is protected
The design principle is that we should not be able to read your data even if we wanted to, and that you should be able to check that rather than take our word for it. In practice: every box generates its own signing key on first boot and the private half never leaves it; the control plane can only send a fixed, enumerated set of signed commands, with no shell and no file read among them; the configuration that builds a box comes from a public repository, pinned to a commit at least a day old; secrets are encrypted before they are written; every agent’s outbound traffic goes through your own firewall box, which logs it and can hold a risky request for your approval.
The security section of our homepage is the short tour. No system is perfect, and the caveats above are there because we would rather write them down than have you find them.
Your rights
Depending on where you live you can ask us for a copy of your personal data, ask us to correct or delete it, object to or restrict what we do with it, ask for it in a portable form, or withdraw a consent you gave. Email [privacy contact email] and we will answer within 30 days. If you are in the EEA or the UK you can also complain to your data protection authority.
We do not sell personal data. Whether the advertising tags on our marketing pages count as “sharing” under some US state laws is one of the questions the legal review will settle; until it does, assume they might and treat [privacy contact email] as the way to opt out.
Children, and changes to this page
ControlClaw is sold to organisations and is not intended for anyone under 16. We do not knowingly collect their data.
When this changes we update the date at the top. If a change matters to you we will also tell the owners of each organisation rather than leaving it here to be found.
Questions, or something on this page that does not match what you see in the product: [privacy contact email].