You're handing over a Cloudflare token. Here is exactly what happens to it.

No autonomous writes

The model proposes. A human approves. The server executes and verifies. Every function that can change Cloudflare is reachable only after approval — there is no path from a chat tool call to a write, so prompt injection through attacker-controlled data (request paths, user agents, rule names) cannot cause one. The full pipeline.

Workspace isolation

One database per customer. One encryption key per customer, itself protected by a key the customer database never holds — so a copy of your data decrypts nothing on its own. Every request runs inside its workspace, and the data layer fails closed: a request with no bound workspace gets an error, never somebody else's data.

Credentials

• Cloudflare tokens and any provider credentials you add are encrypted at rest with authenticated encryption. The application refuses to start without its key; there is no default and no fallback.
• Decrypted tokens never leave the server. Nothing returned to a browser carries more than a token's name and what it can do.
• Write permissions are never discovered by writing. What a token can do is learned from observed responses, token introspection and read-only probes. We will not create a test record in your zone to see if we can.
• The connection wizard builds a Cloudflare token-creation link with exactly the permissions needed, in three tiers, then tells you what the token you pasted can and can't do. Start read-only if you like.

Access

• Sign in with Google, Microsoft or GitHub, or an emailed link. Only provider-verified addresses can create an account — and for Microsoft, only addresses whose domain the tenant has actually verified.
• Roles: owner, admin, user, viewer. Viewers are blocked from every mutating action at more than one layer. DNS and bulk operations are admin-only.
• Share links are revocable, optionally time-limited, and carry the role of the person who made them, no more.
• A full audit trail: every change attempt, successful or not, with who, what, the response, and where from.

Transport

• Everything is served through Cloudflare. The origin refuses connections that don't come from Cloudflare, so the WAF, rate limits and access rules in front of the product — including the ones the product creates — cannot be bypassed by going around the edge.
• Strict transport security, a first-party content security policy with no third-party scripts, and hardened session cookies.
• No third-party analytics or tracking anywhere in the product.

Backups

Nightly, encrypted, kept both on and off the server, integrity-checked. The job restores its own output before it reports success, so a backup that can't be restored fails loudly rather than sitting there looking fine. Restore has been tested end to end from the off-site copy alone.

Who else touches your data

• Anthropic — the model. Your questions and the analytics needed to answer them are sent to the Anthropic API under your key, which is stored encrypted exactly as Cloudflare tokens are. Usage is billed to you at cost and never marked up.
• Cloudflare — your zones' API, and the edge in front of the product and this site.
• Our hosting and transactional-email providers, for the server the product runs on and for sign-in links and invitations. Named in the privacy policy on request.

Alert channels — email, Slack, Teams, SMS, PagerDuty, webhooks — go to providers you configure with your credentials.

What the model sees

Zone names, traffic analytics, attacker IPs, probed paths, rule definitions — whatever it needs to answer the question, scoped to the zone you're working in. The server injects the zone; a question cannot reach a zone outside your active context.