How we handle your data.

Account authentication is handled by Clerk. Passwords are never stored on, transmitted through, or visible to SaturnOS — they don't exist in our database, our logs, or our application memory at any point. When you sign in, Clerk issues a session that we read on each request via httpOnly, SameSite cookies, which means the token is invisible to client-side JavaScript and won't leak to extensions or third-party scripts.

Two-factor authentication is available through Clerk for any account that wants it (TOTP authenticator apps and SMS), and we recommend enabling it for accounts that own production projects. Sign-in attempts, password resets, and session revocations all flow through Clerk's audit log.

Your projects, drafts, plan answers, and build outputs live in a Postgres database hosted on Supabase in the US-East region. Connections from our application servers to the database are encrypted in transit using TLS 1.2 or higher; we don't accept unencrypted connections. Data is encrypted at rest on Supabase's managed infrastructure.

Database backups are taken automatically and retained for 7 days, which gives us a recovery window for accidents and data-corruption events without keeping personal data around indefinitely. If you delete an account, your row-level data is removed promptly; backup snapshots that pre-date the deletion roll off on the same 7-day cadence.

Every project, workspace, run, and user-scoped table is gated by Postgres row-level security policies that pin reads and writes to the authenticated user's `userId`. The application can't ask the database for someone else's project even if a bug or a misconfigured query asked it to — the database refuses at the row level, not at the application layer.

Service-role access (which bypasses RLS) is restricted to a small, audited set of server-side admin operations exposed through a single client we call `dbAdmin`. That client never runs in response to untrusted user input and is reserved for things like scheduled cleanup jobs, billing webhooks, and the auth-redirect lookup on the root path.

The web application runs on Vercel, deployed across their edge regions so requests terminate close to wherever you are. Application and edge logs are retained for 30 days for debugging and abuse-detection purposes, then rotated out. Logs are scoped to operational metadata (request paths, status codes, latency) — we don't log request bodies or AI prompt content.

Billing is handled by Stripe. Card numbers, CVCs, and bank details are entered directly into Stripe's iframe and never touch SaturnOS servers; we only ever see a Stripe customer ID and a redacted last-four. We don't store, log, or proxy raw payment data.

When Saturn calls an AI model on your behalf — whether you're answering a Plan question, dispatching a Build run, or chatting with the assistant — the request goes outbound to Anthropic's API. Per Anthropic's commercial policy, prompts and outputs sent through their API are not used to train models.

Model context (the conversation, file attachments, tool results) lives only for the duration of the request. Once the response is streamed back to you, the upstream context is discarded; we keep a record of the input and output in your project (so you can re-read your own runs), but the model provider does not retain it.

Every account-level action — sign-ins, billing changes, project creates and deletes, key rotations, autopilot dispatches — is recorded in an append-only `audit_events` table. Rows in that table are immutable; we never `UPDATE` or `DELETE` them from application code, and the schema doesn't grant the application user permission to do so.

You can review your own audit trail any time at `/settings/runs`. If you ever see an event you don't recognize, that's the first place to look and the fastest way for our team to investigate.

Operational issues, account problems, and bug reports go to support@saturnos.app and are triaged within 24 business hours. Suspected security vulnerabilities go to security@saturnos.app and are routed to an on-call engineer.

If we confirm a security incident that affects your account or data, we will notify the affected users within 72 hours of confirmation, with what we know, what we're doing, and what (if anything) you should do on your end. We follow up with a full post-mortem once the incident is resolved.

Security researchers who find a vulnerability are encouraged to report it to security@saturnos.app. Please give us a reasonable window — typically 90 days — to investigate and ship a fix before publishing details. We don't run a paid bug-bounty program yet, but we're happy to credit reporters by name (or handle) in the changelog if they want recognition.

Out-of-scope: anything that requires a user to install malicious software, social-engineering attacks against SaturnOS staff, denial-of-service from saturated traffic, and reports based purely on automated-scanner output without a working proof-of-concept.

We're working toward SOC 2 Type 1 certification, with a target completion date in late 2026. We treat the SOC 2 control list as a working checklist today even though we're not certified yet — the policies described on this page are written to that bar.

We respect GDPR and CCPA rights including the right to access, the right to deletion, and the right to data portability. To exercise any of these rights, email support@saturnos.app from the address on your account.