Kaldune security

This page describes how Kaldune protects your data today. It exists to answer the specific questions procurement and enterprise buyers ask before signing.

Data residency

• All customer data lives in Google Cloud Platform, in the United States (Iowa).
• Kaldune runs one region. Data residency inside the EEA or another territory is a custom engagement for an organisation under contract, wired after that organisation asks for it and pays for it. EU, UK and Swiss data is processed in the United States under the Standard Contractual Clauses; see the sub-processor page.
• Data does not leave GCP infrastructure except for outbound API calls to the vendors listed under Vendor sub-processors below. Those calls carry only the specific content required to produce your deliverable and are subject to each vendor's own data-handling terms.

Encryption

• In transit: TLS 1.2+ on every public-facing endpoint. HSTS enforced (two years, subdomains included). Certificates are provisioned and renewed automatically.
• At rest: Google-managed encryption keys on every stored object (GCS buckets, Cloud SQL Postgres, Secret Manager).
• In-application: passwords are not stored. Kaldune is passwordless-only: Google sign-in or a six-digit code sent to your email. There is no password field in the product.

Authentication

• End users: sign-in is passwordless, two lanes. Google sign-in rides Google Identity Platform, and the ID token is verified against Google's published signing keys at the handshake. The email lane sends a six-digit code that Kaldune itself mints and verifies. Both lanes mint the same Kaldune-issued session.
• Sessions: opaque 90-day rolling tokens, HttpOnly / Secure / SameSite=Lax cookies. Sign-in never rides an ID token past the initial handshake; all subsequent requests use the Kaldune-issued session cookie, which can be revoked instantly server-side.
• Sign-in code limits: email codes expire after 10 minutes and are rate-limited per email address and per client IP, with hourly and daily caps and signup velocity walls.

Authorization

Two roles at the workspace level: owner and member.

• Owner: the plan, seats, invites, and spending visibility for the workspace
• Member: their own briefs, drawing on the workspace's shared wallet; no billing surface

Briefs are private to the person who started them. Room content is isolated per owner. One writer per room, ever — enforced at the storage layer with epoch fencing (see Architecture below).

Company accounts

2-step verification is enforced on every Kaldune company Google account.

Architecture (in one paragraph)

Kaldune runs on Google Cloud Platform: traffic enters through an edge network (Cloudflare) and terminates at a Cloud Run gateway which authenticates every request, resolves the target room, and multiplexes WebSocket connections to a fleet of studio pods on GKE Autopilot. Studio pods carry a single writer per room; room content lives on the pod's ephemeral SSD as the working copy, with a write-through journal to Cloud Storage as the authoritative durable copy. Postgres (Cloud SQL, regional HA) is the fleet directory — placement, accounts, wallets, briefs. If a pod dies mid-work, the room is re-placed on another pod, rehydrated from Cloud Storage + journal, and any interrupted work is journaled as a stopped event (never silently resumed).

Compliance

• Provider certifications: Each provider's own certifications are its own, not Kaldune's.
• GDPR: The Data Processing Addendum is part of the Terms for every business and workspace customer, with the EU Standard Contractual Clauses and the UK addendum incorporated by reference. A countersigned copy is available from enterprise@kaldune.ai.
• CCPA: In scope. User rights (access, deletion, opt-out of sale — none applicable, we do not sell data) supported.
• HIPAA: Not currently in scope. Do not use Kaldune to process protected health information.
• PCI DSS: Payment processing is handled by Stripe (PCI DSS Level 1 certified); Kaldune never sees or stores payment card details.

Data handling

Content you create in a Kaldune brief (chat messages, files you upload, deliverables Kaldune generates):

• Stored in your room in Cloud Storage, in the United States (Iowa)
• Encrypted at rest with Google-managed keys
• Accessible only by you, the pod running your room, and, for a specific brief, the AI vendors actually producing the work (see Vendor sub-processors below)
• Never used to train Kaldune's own models. Kaldune has no in-house model.
• Vendor training exposure: we route model calls to vendors whose default is no training on customer data (Anthropic API, Google, fal.ai). We do not opt any customer traffic into training.

Metadata about your use (brief titles, timestamps, wallet balance, ledger of actions):

• Stored in Cloud SQL Postgres, in the United States (Iowa)
• Encrypted at rest
• Used only to run Kaldune (routing, billing, receipts). Not sold, not shared.

Data retention:

• Active briefs: retained as long as your account is active
• Deleted briefs: removed from your studio immediately; recoverable for 30 days by contacting support, then hard-deleted from Postgres + GCS
• Closed accounts: hard-deleted within 30 days (except billing records, which are retained per US tax law, currently 7 years, in encrypted archive)
• Backups: nightly encrypted Postgres backups with 7-day point-in-time recovery; deleted data cycles out of backups within 40 days of active-system deletion
• Log data (Cloud Logging): 30 days
• Wallet ledger (transactions): retained for the life of the account plus 7 years post-closure (US tax + accounting)

Data export:

• Any delivered file can be downloaded from its brief the moment it exists; a whole delivery downloads as one kit
• Account export from Settings: your list of briefs, wallet history, and invoices, in one file, self-serve

Data deletion:

• Any single brief: user can delete from the brief's menu
• Full account: user can delete from Settings. Active subscriptions are canceled and the account and its work are permanently deleted within 30 days (see retention above)
• Billing records excluded (see retention above)

Vendor sub-processors

The authoritative, build-checked list lives at kaldune.ai/legal/sub-processors.html (every https host the code calls must have a row there, or the build fails). Summary:

New sub-processors are announced 30 days before they begin handling customer data; customers with a Data Processing Agreement may object under it.

Vulnerability handling

• Responsible disclosure: security@kaldune.ai. Please give us 90 days before publishing.
• In-scope: kaldune.ai, kaldune.site, and their subdomains.
• Out-of-scope: third-party services (report to those vendors directly), social engineering of Kaldune staff, physical attacks, DoS.
• Bug bounty: no formal program today. Validated reports are credited publicly if the reporter wishes.

Incident response

• Any confirmed incident affecting customer data is disclosed to affected customers within 72 hours of confirmation, per GDPR breach-notification standard (whether or not GDPR applies to that customer).
• Notification goes by email to the account holder, and to the workspace owner for workspace accounts.

Enterprise-specific

Every door into Kaldune carries the same security posture described on this page; an enterprise contract buys contract shape, not a different class of protection. Enterprise contracts (negotiated for teams above the self-serve seat range) include:

• Data Processing Agreement (DPA): our standard processing terms, signed for your organization
• Commercial and data-handling terms beyond this page are negotiated per contract

Contact enterprise@kaldune.ai to discuss.

Contact

• General security questions: security@kaldune.ai
• Enterprise / procurement / DPA: enterprise@kaldune.ai
• Vulnerability disclosure: security@kaldune.ai
• General support: support@kaldune.ai

This page is versioned in the Kaldune repository.