Your source code is never stored. Here’s exactly what is.
Source code is processed in memory and never persisted at rest, on any tier. Scan content is encrypted at rest under per-scan keys wrapped by an HSM-backed KMS; feature names and metrics are readable metadata in today’s Standard mode. Private mode, Customer-Managed Keys and self-hosting are on the roadmap — listed below as roadmap, not as features.
Source code never written to disk
The scanner reads files into memory, builds the feature map, and discards the source. Plaintext code is never persisted on our servers — on any tier.
KMS envelope encryption at rest
Every scan is encrypted with a unique data key, wrapped by an HSM-backed KMS key. Plaintext is decrypted server-side, in memory, only for authorised reads — and every unwrap is audit-logged.
Privacy modes — today and roadmap
Standard (today): feature names and counts are readable metadata, the same trust model Linear uses for ticket titles; everything else is ciphertext. Private mode (roadmap): opaque IDs only. Self-hosted (roadmap): nothing leaves your VPC.
Your LLM, or ours
The source-available engine can run with Claude, OpenAI or a local Ollama endpoint under your own API key; the hosted service uses ours. Wystan does not store prompts or completions.
Customer-Managed Keys — roadmap
Designed: point us at your own KMS endpoint to rotate keys, revoke our decrypt access mid-session, and audit every decryption on your side. Not available today; we publish it when it ships.
privacy modes
Same data flow shape, different visibility window
Each mode controls one knob: how much of your metadata is readable by our servers. Standard is what ships today; Private and Sovereign are the roadmap, shown here so you can see where the design is going.
Standard
All tiers · todayData livesCode structure encrypted on our servers; feature names + counts as metadata
Wystan seesFeature & flow names, file path index, LOC, coverage, error counts
Best forStandard SaaS trust model · same as Linear, Sentry, Vercel
Private
Roadmap · not available todayData livesAll scan content encrypted with your org key; opaque UUIDs + counts on our servers
Wystan seesOpaque feature_uuid + flow_uuid, aggregate counts, commit timestamps
Best forFintech · healthcare · privacy-sensitive codebases · regulatory pressure
Sovereign
Roadmap · self-hostedData livesWystan would run inside your VPC — engine, dashboard, Postgres, all yours
Wystan seesA licence-check ping. Nothing else
Best forBanks · defense · regulated industries · zero-trust mandates
encryption architecture
Envelope encryption with per-org keys
[scan time — your machine or our scanner]
├─engine reads files in memory(never written to disk on our side)
├─generates feature map with stable UUIDs(lineage matching survives renames)
└─AES-256-GCM encrypts payload with random DEK(DEK is one-shot, per-scan)
▲ Plaintext source code stays in memory for ~30s then is discarded.
[storage time — our database]
├─ciphertext stored as BYTEA in Postgres
├─DEK wrapped by our HSM-backed KMS key(HSM-backed)
└─plaintext metadata (names, counts) stored separately(Standard mode) or encrypted (Private mode)
▲ Without KMS unwrap call, ciphertext is mathematical noise.
[read time — authorized team member opens dashboard]
├─server calls KMS to unwrap DEK(audit-logged event)
├─decrypts ciphertext in memory only
└─streams to browser via TLS, discards plaintext
▲ Customer-Managed Keys (roadmap) would move that unwrap under a key you control.
✗ No standing staff access — by policy, not by cryptography: internal access requires explicit customer authorisation and is audit-logged. In Standard mode the service itself can decrypt; that is what Private mode and CMK are designed to change.
runtime integrations
Sentry + PostHog — what we pull and how we match
[sentry → wystan]
├─OAuth or auth token(scoped: event:read, project:read, org:read)
├─read symbolicated stack frames + release commit SHA
├─match frame.filename against scan.path_index[commit_sha]
└─write feature_uuid + flow_uuids to fl_analytics_events
▲ Zero SDK changes. We don't host or read source maps — Sentry symbolicates before we see frames.
[posthog → wystan]
├─API key paste or OAuth
├─read $current_url + $app_version per event
├─match URL against scan.routes_index[commit_sha]
└─write feature_uuid to fl_analytics_events
▲ One env var enables it: NEXT_PUBLIC_POSTHOG_APP_VERSION=$VERCEL_GIT_COMMIT_SHA.
what we store
Exhaustive, not marketing-safe
The first column applies on every tier. The second column splits by privacy mode — column header tells you which mode the field is plaintext in.
Always encrypted (or never stored)
- Source code file contents
- Commit messages and diff hunks
- Secrets, .env files, credentials
- Issue tracker data, PR descriptions
- AI agent prompt bodies
- Anything from the CLI if you skip cloud sync
Metadata · plaintext in Standard mode
- Feature & flow names (LLM-suggested, you can rename)
- Relative file paths (src/api/users.ts)
- Commit counts, timestamps, author names
- Health scores, bug-fix ratios, coverage percentages
- Account metadata (email, org name, plan)
- Sentry / PostHog event counts per feature
Metadata · plaintext in Private mode
- Opaque UUIDs (feature_a3f4..., flow_b8e2...)
- Aggregate counts (LOC, error count, scan count)
- Commit SHA + timestamps
- Account metadata (email, org name, plan)
In Private mode (roadmap) the fields shown above as "Standard plaintext" would become ciphertext too, and PR comments and Slack notifications would render outside our servers. Nothing in this column is available today.
subprocessors
Who else can see your data
If you use the hosted dashboard, your scan metadata passes through the services below. The local CLI by itself talks to none of them — except the LLM you explicitly pick (or Ollama on your machine).
ServicePurposeWhat they see
AWS KMSHSM-backed key management for per-org KEK and DEK wrappingWrapped DEKs only — never plaintext keys
Anthropicopt-inLLM for feature-name clustering (Claude)File paths, commit messages — not file contents
OpenAIopt-inLLM for feature-name clustering (alternative)File paths, commit messages — not file contents
VercelWeb hosting + serverless functions for dashboardRequest metadata, auth sessions, deployed code
SupabaseManaged Postgres for accounts + ciphertext scan storageAccount data, encrypted scan blobs, metadata
Lemon SqueezyMerchant of record — payment processing + VAT for paid tiersPayment method, billing address, invoice history
PostHogProduct analytics on our dashboard (not your scan data)Anonymous usage events — your team's clicks on dashboard.wystan.ai
Google · GitHub OAuthSign-in provider for dashboard accountsOAuth tokens, email, name
Self-hosting (roadmap) would remove every external subprocessor from the data path except the LLM you choose. Email security@wystan.ai for a DPA and the current subprocessor list.
compliance
Where we are on the checklist
Not started
SOC 2
We'll begin a Type I readiness assessment when a customer needs it — ask, and we'll put a date on it
DPA available
GDPR
Designed for GDPR · DPA available on request for EU customers
Supported
CCPA
CA residents can request data export and deletion
US region
Data residency
US default · EU region on the roadmap
Planned
Pen test
Independent pen test planned before the first Enterprise contract
Planned
ISO 27001
Under evaluation · 2027 target if customer demand warrants
Not applicable
HIPAA
Not a covered-entity tool · BAA not offered
We list "in progress" explicitly rather than claim compliance. If your procurement needs an attestation letter, interim security questionnaire, or Vanta Trust Report, reach out tosecurity@wystan.ai.
questions
Compliance & privacy FAQ
What's the difference between Standard and Private mode?
Standard mode (what ships today, on every tier) stores feature/flow names and metrics as metadata on our servers — the same trust model Linear uses for ticket titles. The detailed scan content (line ranges, narrative descriptions, dependency graphs) is encrypted at rest under a per-scan key wrapped by KMS. Private mode is on the roadmap and would go further: feature names, file paths and descriptions encrypted too, with our servers seeing only opaque UUIDs and aggregate counts; PR comments and Slack notifications would then render outside our servers and the MCP would run locally. Nothing in the Private column is available today.
Do you ever store source code at rest?
No. On any tier. The scanner processes file contents in memory only and discards them after analyzing. What we persist is derived metadata — and which fields are plaintext vs ciphertext depends on your privacy mode. In Sovereign mode (Enterprise) we don't touch your code even in memory; Wystan runs entirely inside your VPC.
How will Customer-Managed Keys (CMK) work?
CMK is on the roadmap: you would point us at your own KMS endpoint (AWS KMS, GCP KMS, HashiCorp Vault) and our service would request data-key unwrap from your KMS for each decryption. You control rotation, revocation and audit logging on your side; revoking our access removes our ability to decrypt until you grant it back. Today every scan gets its own data key, wrapped by our HSM-backed KMS key, and every unwrap is audit-logged on our side.
How does Sentry / PostHog attribution work without changing my app code?
We read Sentry events and PostHog events via OAuth or API key (you authorize on the Integrations page). For each event we extract two things: (1) the file path from the stack trace (Sentry) or the URL from $current_url (PostHog), and (2) the commit SHA from event.release ($app_version for PostHog). We look up which feature owns that file (or URL) at that commit using the scan's path index, and attribute the event to that feature_uuid. Zero code changes, zero SDK additions, zero manual tags.
What about Sentry source maps?
Source maps live in Sentry, not in Wystan. You upload them via @sentry/cli during your build (one line in CI — most teams already do this for production debugging). Sentry symbolicates stack frames before we see them, so we get readable file paths. If source maps aren't uploaded, frontend errors come back as bundle.js:1:1234 and we can't attribute them — we'll show 'X% unattributed' in your dashboard with a one-click guide to fix.
Will my AI agent see my data in Private mode?
That is the design: in Private mode (roadmap) the Wystan MCP would run as a local process on your machine, pull encrypted scans from us, decrypt with your key in process memory, and serve rich data to Cursor / Claude Code / Cline / Aider. Today the MCP is hosted and works in Standard mode.
Can I run the engine fully offline?
The engine is source-available (FSL-1.1). Run it with a local Ollama endpoint and nothing leaves your machine — you get the feature map, not the hosted dashboard, PR comments or MCP. The hosted flow is the supported path today.
Do you offer on-prem (self-hosted) deployment?
Not today. Self-hosting — engine, dashboard, MCP and Postgres inside your VPC — is on the roadmap together with SSO and custom retention. If you need it, email security@wystan.ai and we'll tell you honestly where we are.
What happens to my data when I delete a scan or close my account?
Deletion is immediate in the application database. Encrypted backups are purged within 30 days. On Enterprise we can guarantee custom retention windows and provide written attestation of deletion. Deletion of the encrypted blob deletes both the ciphertext and the wrapped DEK — even if we wanted to recover it later we couldn't.
Are LLM prompts and responses stored?
No. When the CLI uses Claude / OpenAI for feature-name clustering, the prompt is sent directly to the provider you chose with your own API key. Wystan never sees the prompt body or the model's response. If you use Ollama, everything stays on your machine.
Report a vulnerability
security@wystan.aiFor suspected security issues, responsible-disclosure reports, or compliance-questionnaire requests. Also published at /.well-known/security.txt.
Disclosure policy
- · Acknowledgement within 48 hours
- · Triage and fix plan within 5 business days
- · Public disclosure coordinated with reporter
- · Researcher credit on request