Security

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

Written for the person who has to approve this internally. Every claim below is one the code supports; the last section is the list of things it doesn't yet.

No autonomous writes

The model proposes. A human approves. The server executes and verifies. Every function that can change Cloudflare is reachable from the execution core alone, 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 SQLite database per customer. One data-encryption key per customer, itself wrapped under a deployment master key — so a stolen database file decrypts nothing without both. Every request runs inside its workspace's context and the database layer fails closed: a request with no bound workspace gets an error, not somebody else's data.

Credentials

Cloudflare tokens encrypted at rest with AES-256-GCM, a fresh random IV per record, authenticated, versioned envelope. The application refuses to start without a valid key; there is no default.
Decrypted tokens never leave the server. API responses serialise tokens through one allow-listed shape carrying metadata only.
Write permissions are never discovered by writing. Capabilities are learned from observed responses, token introspection and read-only probes, in that order of trust. We will not create a test record in your zone to see if we can.
The connection wizard builds a pre-filled Cloudflare token-creation link with exactly the permission groups needed, in three tiers, then introspects what you pasted and tells you what's missing. Start with 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, because an Entra admin can otherwise set any email on any user.
Roles: owner, admin, user, viewer. Viewers are blocked from every mutating route at the middleware and again at the execution core. DNS and bulk operations are admin-only, enforced independently at the HTTP layer, the tool dispatch, and the model's tool list.
Share links are backed by a synthetic user, revocable, optionally time-limited, and validated against a SHA-256 hash of a 192-bit secret.
Full audit trail: every mutation attempt, successful or not, with actor, payload, Cloudflare's response, IP and user agent.

Transport and origin

Enforcing first-party Content-Security-Policy; no third-party scripts. frame-ancestors 'none', HSTS with a one-year max-age set by the application itself, Permissions-Policy denying camera, microphone, geolocation, payment and USB.
The origin accepts TLS only from Cloudflare's client certificate (Authenticated Origin Pulls with an operator-issued CA). Connecting to the server's IP directly is refused at the handshake, so nothing — including the access rules this product creates — can be bypassed by going around the edge.
Session cookies carry the __Host-/__Secure- prefixes with HttpOnly; Secure; SameSite=Lax.

Backups

Nightly at 03:15 UTC. Consistent SQLite snapshots of every workspace and the control plane, integrity-checked, encrypted with AES-256, kept 14 days on the box and pushed to Cloudflare R2 off-box. The job decrypts and unpacks its own output before it reports success, so a backup that can't be restored fails loudly rather than sitting there looking fine. Restore tested end to end, including from R2 alone as though the server were gone, on 21 September 2026.

Sub-processors

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. We never mark usage up.
Cloudflare — your zones' API, and the edge in front of the product and this site.
OVHcloud — the server the product runs on.
Resend — account emails: sign-in links and invitations.

Alert channels — email, Slack, Teams, SMS, PagerDuty, webhooks — go to providers you configure with your credentials, stored the same way tokens are.

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. No third-party analytics or tracking runs in the product.

Known limitations

These are tracked and prioritised. They're listed so the model above isn't overstated — publishing what isn't finished is the only way a page like this earns trust.

The approval card is enforced by role, not bound to a proposal

A signed-in non-viewer could post a well-formed action directly to the execute endpoint without going through a card. Impact classification, the drift check, read-back and the audit row all still apply server-side, so this is a bypass of the UI, not of the pipeline — but it should be bound, and it will be.

Some ownership checks are role-based

Alert rules and token-metadata routes check your role rather than whether you own the specific object. Within one workspace, that means an admin can edit another admin's alert rule. Across workspaces it is not reachable.

The master key lives on the server's disk

The per-workspace keys are wrapped under a master key held in a root-only file, not in a hardware module or cloud KMS. Moving it is planned before general availability.

CSP still allows `'unsafe-inline'` and `'unsafe-eval'`

Required by the framework's bootstrap and the WebGL globe. Nonces and eval removal are planned.

Reporting a vulnerability

Email security@zonesteward.com with reproduction steps. You'll get an acknowledgement, and a fix or mitigation plan, as fast as the severity warrants. Please don't open a public issue.