security & privacy
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 under per-scan keys wrapped by an HSM-backed KMS; feature names and metrics are readable metadata in today’s Standard mode. Everything marked roadmap below is exactly that.
Your repositoryread-only clone
Scanner memory~30 s, never on disk
Source codediscarded
Feature mapencrypted at rest
- 0 bytesof source code at rest
- AES-256-GCMone data key per scan
- HSM-backed KMSevery unwrap audit-logged
- Read-onlygit access, never writes
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.
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.
encryption architecture
Envelope encryption, stage by stage
- 01Scan timeyour machine or our scanner
- Engine reads files in memorynever written to disk on our side
- Builds the feature map with stable UUIDslineage matching survives renames
- AES-256-GCM encrypts the payloadrandom, one-shot data key per scan
Plaintext source stays in memory for ~30 s, then is discarded. - 02Storageour database
- Ciphertext stored as BYTEA in Postgres
- Data key wrapped by our HSM-backed KMS key
- Names and counts stored separatelyplaintext in Standard · encrypted in Private (roadmap)
Without a KMS unwrap call, the ciphertext is noise. - 03Read timean authorised teammate opens the dashboard
- Server asks KMS to unwrap the data keyaudit-logged event
- Decrypts the ciphertext in memory only
- Streams to the browser over 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 Customer-Managed Keys are designed to change.
runtime integrations
Sentry + PostHog — what we pull and how we match
Sentry
- Connect
OAuth or auth tokenevent:read · project:read · org:read - Read
symbolicated frames + release SHA - Match
frame.filename → path_index[sha] - Write
feature_uuid + flow_uuids
Zero SDK changes. We don't host or read source maps — Sentry symbolicates before we see frames.
PostHog
- Connect
API key or OAuth - Read
$current_url + $app_version - Match
URL → routes_index[sha] - Write
feature_uuid
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 other two show which metadata is readable by our servers in each privacy mode.
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
Readable metadata · Standardtoday
- Feature & flow names (LLM-suggested, you can rename)
- Relative file paths (src/api/users.ts)
- Commit counts, timestamps, author names
- Versioned metric outputs, evidence counts, confidence and availability
- Account metadata (email, org name, plan)
- Sentry / PostHog event counts per feature
Readable metadata · Privateroadmap
- 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 Standard-column fields would become ciphertext too, and PR comments and Slack notifications would render outside our servers. Nothing in the Private column is available today.
privacy modes
Same data flow, 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, source-labelled test evidence, 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
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
PaddleMerchant 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 to security@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
- 48 hAcknowledgement
- 5 daysTriage and fix plan (business days)
- JointPublic disclosure, coordinated with the reporter
- CreditResearcher credit on request