Threat model

What Qaldy Cloud defends, against whom, with which layers, what an attacker who gets one employee account could reach, and which of this is proven and where. Last reviewed 2026-10-18.

This is written to be read by a customer's security reviewer. It is not an audit, a penetration test or a certification: none of those has happened yet, and nothing here should be read as claiming one. Every row says whether the safeguard is built, planned or an accepted risk, and the proofs say where they ran.

The promise this document defends: app code never sees a secret, can't reach anything its manifest doesn't name, can't be opened by anyone the share graph doesn't allow, every action lands in a tamper-evident log, and data stays in the workspace's cell. The last part is Planned for Kazakhstan; see "Residency".

Where things run today (the pilot cell, since 2026-10-17): the console is a Cloudflare Pages site (app.qaldy.com); the API and MCP server run on one AWS host in eu-central-1 behind a Cloudflare tunnel; the gate runs on its own host in the same account; the runtime host is a Cloudflare Worker; Postgres is RDS; apps are served from a temporary domain. There is one cell and one maintainer. The pilot is invite-only.

1. Layers#

Each layer assumes the one outside it has failed.

2. What we protect#

3. Who we worry about#

4. If one employee account is taken#

The pilot has one maintainer, so this is the honest short answer: the account that can ship code can reach everything the cell holds, including the gate's private key. What that means, by account:

What an attacker with database access only gets: ciphertext for every connection key, hashed tokens (HMAC with a server pepper), sessions, and the audit log. They can rewrite recent audit rows; they cannot do it undetected beyond the last checkpoint, and cannot touch checkpoints already copied to the vault. (The vault is in Governance mode for 35 days: an AWS administrator with the bypass permission could still remove a copy. Compliance mode, which nobody can shorten, is planned.)

5. Operational safeguards#

Four features give an owner control after something goes wrong. All are admin-only, audited and console-only (a personal access token cannot use them).

• Signed checkpoints and a locked copy. Once a day the end of each workspace's chain is signed with a key that is not in the database, and a copy is written to the Object-Locked vault. Verification names a chain that no longer matches a checkpoint. It cannot see events newer than the last one; streaming covers that gap.
• Audit streaming and export. A signed webhook or, in Preview, the customer's own S3 bucket through a role they own; or a download of the whole chain as JSON Lines. pnpm audit:verify-export checks a copy offline.
• Key rotation and expiry. A new key replaces the old one only after it works through the gate; admins record expiry dates and are reminded at 14 days, 3 days and on the day.
• The panic button. Revokes every access token, backend key, other member session, connection key, model provider key, "connect an AI app" sign-in, open invite link, open guest link and inbound webhook secret in one transaction, with a typed confirmation and one audit row of counts.
• Reads are recorded. Opening the audit log, the connection and key inventories, and exporting the chain leave an audit row (who, which view, how many; never the content).

Details and limits: docs/adr/0027-operational-security.md, docs/security/audit-streaming.md.

6. Proofs: what was shown, and where#

A claim in this document that says "proof" names a test that re-runs. Where it ran is part of the record.

The production proofs cannot show anything about code paths that need a write (rotation, the panic button, streaming); those are covered by the API's test suite on an in-process cell, not by a live proof.

Proof ids used below: the T-numbers are claim ids in this document; the ledger ids are in docs/security/trust-ledger.json.

How to read the status columns below. built: in the code, with the named proof; if the proof is not green, PROGRESS.md says so. planned: designed, not built. accepted-risk: known, bounded, reason given; to be revisited before the first paying workspace.

7. Trust boundaries and keys#

8. Components, one table each (STRIDE)#

8.1 qaldy-gate: ingress#

Assets: handoff tokens, per-host session cookies, ingress signing key, FGA decision cache. Boundaries: B2, B3.

8.2 qaldy-gate: egress#

Assets: HPKE private key, plaintext tokens (in memory, per request), policy cache, connector routing table. Boundaries: B5, B6.

8.3 runtime-host (workerd, Dynamic Worker Loader isolates)#

Assets: bundles, isolate memory, egress context key, per-app db binding. Boundaries: B3, B4, B5.

8.3a Agents: published tools and pushed news (ADR 0030)#

Assets: what an agent may start in a workspace; the model's context, which a tool description or a pushed message enters unasked; the feed of what needs a person. Boundaries: B1, B7.

8.4 API and control plane#

Assets: users and emails (PII), sessions, OpenFGA tuples, sealed secrets, audit chain, LLM provider keys, Bifrost virtual keys. Boundaries: B1, B7, B9.

8.4a OAuth for remote MCP clients (ADR 0026)#

Assets: workspace data an agent can read or change as the person who agreed; access and refresh tokens; the consent screen. Boundaries: B1, B7, B9.

8.4c Try it without an account, and Web Push (ADR 0036)#

Assets: the platform's capacity (a stranger gets a sandbox), the operators' links, visitors' network addresses, push subscriptions. Boundaries: B1, B7.

8.4d Replay and dead letters (docs/connectors/replay.md)#

Assets: the input a failed run or a refused webhook call carried (it can hold personal data); the right to run an app again; the app's version history. Boundaries: B1, B7.

8.5 Builder agent#

Assets: user prompt (may hold private data), manifest, generated code, Trust Score, model key. Boundaries: B8 and the virtual app directory.

Static policy rules (each has a failing fixture in BLD): (1) no eval, new Function, Function(), string setTimeout; (2) imports only @qaldy/sdk, @qaldy/sdk/ui and relative files, so no URL imports, bare npm imports or cloudflare:sockets; (3) no raw fetch to a host outside manifest connectors + egress, and non-literal URLs fail; (4) no secret-looking literals (known key prefixes, JWTs, high-entropy strings ≥ 32 chars); (5) declared egress ≡ used egress, unused declarations fail too; (6) tool writes: normalized relative path inside the virtual directory, no .., no absolute path, extensions .ts .tsx .json .md.

8.6 Connectors#

Assets: sealed tokens, routing table (connector id → fixed upstream host + request template), webhook endpoints. Boundaries: B5, B6.

8.6a AI models for apps (BYOK)#

Assets: sealed provider keys, each app's monthly budget and the books behind it, the prompts and replies in flight. Boundaries: B5, B6. Guide: docs/connectors/ai-models.md (Preview).

8.6b Telegram ops (approvals, links, alerts chat)#

Assets: the bot's sealed token (never leaves the gate), the webhook secret_token, one-time link codes, the link between a Telegram account and a Qaldy person, the right to decide an approval. Boundaries: B1 (console), B6 (gate to Telegram), and the webhook POST /v1/telegram/:hookId from Telegram's servers to the API. Guide: docs/connectors/telegram.md, "Approvals and alerts in Telegram" (Preview: not yet run against the live Bot API).

8.6c Ask about this run (model answers, Preview)#

Assets: the sealed Models key, run details sent to a model, the permissions an answer may suggest. Boundaries: B6 (the gate to the provider) and the API to gate call (crates/qaldy-gate/INTERNAL_API.md §16). Guide: docs/ask-run.md.

8.7 Console#

Assets: console session, workspace metadata, share actions. Boundaries: B1.

8.7a Team: roles, invites, handover and company domains#

Assets: who is in a workspace and with which rights, join links, the company-domain rule. Boundaries: B1. Rules in packages/contracts/src/team.ts, enforced in apps/api/src/domain/team.ts; see docs/team.md.

8.7b Guests: one app, a link and an email code (docs/guests.md)#

Assets: an app's data and behaviour, the guest's address, the codes and links. Boundaries: B1 (a person with no account to the gate), B3 (gate to host). Rules in packages/contracts/src/guests.ts, enforced in apps/api/src/domain/guests.ts and guest-access.ts.

8.8 User-content domain#

Assets: per-app session cookies, app-rendered HTML. Boundaries: B2.

8.9 Exposure probe (pre-publish black-box check)#

Assets: the app's real database and connectors (must stay unreachable from a probe), findings (content-free), the publish gate. Boundaries: B3 (API to runtime host), the sandbox isolate.

Code: contracts probe-engine.ts (the questions and the judging, pure), probe-sandbox.ts (the sandbox's modules, planted records, identities), runtime-host probe-host.ts (POST /__qaldy/probe), API domain/probe.ts (records, rate limits, the gate), console ProbePanel and PublicLinkPanel.

What it cannot do. It calls the app directly, the way a public link would, so it shows what a stranger could reach if the gate were not in the way; it cannot prove an app safe. Routes that call a connector fail in the sandbox (the call is refused), so the check records the attempt but cannot see past it. Findings are only as good as the routes it can discover (links, form actions, route literals in the bundle and a short list of common names). The gate applies when the link is turned on: an app that is already public keeps its link when a later version's check finds a high finding (the panel shows "Not ready"); revoking it automatically is planned.

8.10 Static sites (Sites, docs/sites/README.md)#

Assets: a company's site files, other workspaces' files, the host's CPU and memory, the cell's database. Boundaries: B1 (visitor to gate), B3 (gate to host), host to API.

8.11 Backend data API (keys, rules, sign-in tokens)#

Detail: docs/backend/access-policies.md. Proofs: apps/api/src/baas/policy.test.ts, apps/runtime-host/src/baas/guard.test.ts, packages/contracts/src/baas-policy.test.ts.

Not covered: tokens are bearer credentials for up to 24 h (the owner's server decides who gets one); JWKS by URL and Qaldy-issued sign-in do not exist; limits are per API process.

8.12 Custom domains (docs/hosting/custom-domains.md)#

Assets: a customer's hostname and the content served on it, the Cloudflare token, other tenants' claims. Boundaries: B1 (visitor to gate), API to Cloudflare, API to public DNS.

9. Critical data flows#

1. Open an app. Browser → inventory--moss.apps.localhost → gate (B2). No cookie → 302 to console handoff → API signs {sub, host, jti, exp} → gate verifies, consumes the jti, sets the host cookie → can_view → host with signed {user, app, version, exp} (B3) → host verifies, loads the bundle by hash. Every failed check returns 403 before app code runs. Proof: T1, T2, GATE, HOST.
2. App calls a connector. SDK connectors.telegram.sendMessage() → fetch('https://connector.qaldy.internal/telegram/sendMessage') (B4) → host signs {app, version, workspace, run, tainted} (B5) → gate verifies, loads the version policy (cached, invalidated on app.deployed), checks {telegram, sendMessage} → HPKE-opens the token with its aad → builds https://api.telegram.org/bot<TOKEN>/sendMessage → rustls (B6) → zeroizes → audit + run.step. The token exists only in gate memory for one request. Proof: T3, T5, T7, HPKE.
3. Non-allowlisted domain. fetch('https://example.org') → host signs → no manifest match → 403 {"error":"egress_blocked","host":"example.org"} → egress.blocked event + audit → SSE → barrier and U-turn in the City. Raw sockets fail the same way. Proof: T4, T6, T5.
4. Build and deploy. Prompt → plan (manifest + file plan) → human approves the manifest (audited) → codegen in the virtual directory → esbuild → static rules 1–6 → smoke tests (fake connectors, deny-all) → Trust Score → API writes an immutable app_version → publish refused below 60 or without approval → app.deployed. app.build.progress at each step. Proof: BLD, API, AUD.
5. Run → City. Host emits run.started, run.step, run.finished, run.failed with its service credential → API validates with zod and appends to events → LISTEN/NOTIFY → SSE filtered by can_view. The City is a pure projection and never writes state. Proof: API (SSE scope), @qaldy/city determinism tests.

10. AI runs: the lethal trifecta rule#

An AI run that combines private data + untrusted input + external communication needs human approval before each external send. Any one leg on its own is fine; all three together let injected text steal data.

A pure function trifecta(manifest) computes the legs. It applies only when permissions.ai ≠ null.

• Private data: any permissions.data entry, or any connector read action (gmail.read, sheets.read).
• Untrusted input: a webhook, form or external event trigger, or a connector read of content authored outside the workspace (email, messages). Model output always counts as untrusted.
• External comms: any connector write action (telegram.sendMessage, gmail.send) or any permissions.egress entry.

Enforcement:

1. Build time (built, BLD). The flag goes into trust_report. The manifest card says "Reads private data, handles outside input and can send messages. Each send needs approval." Trust Score is capped at 79 (sun plaque) until the app has an approval step.
2. Run time (planned, T8). The host marks a run tainted after its first ai.* call and signs the flag into the egress context. For a tainted run the gate refuses every external-comms action unless it carries an approval id the API signed over {run, step, connector, action, sha256(body)}. Binding the body hash means the message sent is the message approved. The wait is a DBOS recv; in the City it is a person queueing at the Town Hall.
3. The builder agent has private data (prompt, templates) and untrusted input (model output, pasted text) but no external-comms tool: it can only write files in its virtual directory. Deploy still needs the human manifest approval.

10a. Information flow: a sensitive read limits what leaves#

The owner labels tables and connections (pii, financial, secret). The runtime host records which tables an isolate read, in the app's Durable Object, and signs the list into every egress token; the gate also notes calls through a labelled connection itself. A run that holds a label may then send only to destinations the owner allowed for it, within a request limit and a run total, and every decision is an audit row. Interactive apps are keyed on the app and a five-minute window, host-started runs on their bound run id, so an app cannot shed a label by naming another run. Tables a marked run wrote to carry the label forward.

It narrows the manifest and never widens it. It stops a send; it does not ask for approval, so it does not close the trifecta gap (T8) for AI runs. Limits, bypass attempts and the proofs: docs/security/information-flow.md. Status: Preview, proved on a developer's machine only.

11. Residency#

Status: Planned. The pilot cell runs in AWS eu-central-1 and on Cloudflare. No workspace is on a Kazakhstan cell and the provider for one is not chosen, so nothing in this section is true of the pilot today; the pilot's honest statement is "Residency: Planned". What follows is the design a Kazakhstan cell must meet.

• A KZ workspace's cell holds all of its data: user emails, sessions, tuples, audit chain, app SQLite, sealed secrets, events, backups. The global directory stores workspace_id → cell and billing ids only. A schema test that the directory has no name or email columns is planned.
• kz-standard: foreign LLMs only after PII redaction in the Qaldy policy layer, which runs even when Bifrost is down. kz-strict: in-region models only; with none available the builder runs offline and the ai permission is unavailable. Proof: POL (the policy function; no workspace runs under it in production).
• Each cell has its own gate HPKE key; key_id names the cell, so a blob sealed for one cell can't open in another.
• Connectors are the deliberate exit: a Telegram send from a KZ app leaves the country. The profile's allowedConnectors limits which exits exist and the manifest sentence names the destination (accepted-risk, decided by the workspace admin).
• Audit streaming and export are also exits, chosen by an admin: a destination outside the country is the admin's decision, and the destination's address is in the audit log.
• OTel exporters in a KZ cell point at the in-cell collector only; config validation that rejects third-party endpoints under kz-* is planned.
• Sharing doesn't cross cells: the share picker lists only members of the workspace's own cell.

12. Known gaps#

What a reviewer should know is not done. Numbers are stable so a later review can say which closed.

1. Sandbox depth. workerd alone is not a hardened boundary (its README says so). The pilot relies on Cloudflare's isolation layers; a microVM per tenant (ADR 0005) is not built. An isolate escape would reach whatever the Worker can reach: its own secrets, not the database or the gate.
2. Development login exists when no OAuth keys are set and QALDY_ENV is not production. The API refuses to start in production with it forced on, and proof L3 checks the live API does not route it.
3. Connectors. Telegram, HTTP API connections (with presets) and Google Sheets (a service account) work end to end; GitHub, Linear and WhatsApp are presets built from the providers' documentation and have not run against the live services; the rest of the catalog is Preview or Planned and is labelled so in the product.
4. Key custody. The gate's and the API's private keys are in Secrets Manager and injected as environment variables, not in KMS or an HSM. An AWS administrator can read them.
5. One cell, one maintainer. No global directory, no second person to review a deploy, no hardware-key enforcement on the cloud accounts yet (planned; the pilot floor in docs/plan/09-security-compliance.md).
6. Limits. No per-IP or per-host rate limits on the gate, no per-run egress cap, no response token scrubbing for every connector shape.
7. Public Suffix List. qaldy.app is not on it (and not bought); app-to-app requests are stopped by the Sec-Fetch-Site check only.
8. Audit. Signed checkpoints and a locked copy narrow the old gap, they do not close it: events after the last checkpoint can be rewritten by someone with database access unless streamed out, the vault copy exists only where QALDY_AUDIT_VAULT_BUCKET is set and the API has AWS credentials (on the pilot cell its container cannot reach the host role, ADR 0024, so the copy is not on yet), and the vault is Governance mode (35 days), which an AWS administrator can bypass. Compliance mode is planned. The default checkpoint key is derived from the API's own key until a dedicated one is set.
9. Trifecta. Runtime enforcement (T8) is not built; only the build-time flag and score cap.
10. Bifrost is an optional compose profile. Without it the policy wrapper calls providers directly with the same allowed-provider list and redaction (ADR 0016), losing Bifrost's retries and the virtual key's second budget check.
11. Proof coverage. The 17 local proofs run on local origins with development keys (plain HTTP, so __Host- and Secure cookie rules are not exercised). The 15 live proofs are read-only and from outside; nothing shows rotation, streaming or the panic button against the live cell.
12. Rust tooling. clippy and rustfmt run in CI and Docker, not on every laptop (see docs/decisions-log.md).
13. No external test. There has been no penetration test and there is no SOC 2 report. A test is planned before public beta; the plan is in docs/plan/09-security-compliance.md. A bug bounty is not open: see docs/security/disclosure.md.
14. Panic button reach. Sessions belong to a person, not a workspace, so the button signs a member out of every workspace they are in. One admin can press it; two-person approval is planned.
15. S3 export is Preview. The signing code is tested against AWS's published vectors and a stubbed endpoint; it has not been run against a real bucket, and the API role has no sts:AssumeRole statement yet.
16. Information flow is Preview. The policy (§10a) follows tables of the app's own database and labelled Sheets and HTTP connections, not columns. It does not hold what an app returns to a viewer or prints to its logs. The gate keeps marks and totals in memory (a restart forgets them, a second gate would not share them), and a refused send is not escalated to a person. Data read through a labelled connection and written into a table does not carry the label to that table yet. Proofs I1 to I3 ran on a developer's machine only and are not in the ledger. Full list in docs/security/information-flow.md.