What we store, what we never store, and how we protect it.
Written from the actual code, not from a template. Where something has a limit, it's stated below. For the pipeline these controls protect, see how bugweg works and the features page.
Data handling
Never stored
Full diffs and full file contents fetched from GitHub for a review are used in memory for that one review run and are not written to any database table. This is confirmed by reading the pipeline code directly, not inferred from intent.
Stored, and why
What persists: the LLM's written description and suggested fix for each flagged issue (free text that can quote a short line of code, so it is not guaranteed code-free); suggested tests; per-file risk scores; embeddings used for Bug Genealogy, the Recurrence Firewall and Bug Search (for Bug Search, vectors of code chunks stored with the file path, git hash and line number, not the code text); per-developer bug-pattern profiles (Developer Bug DNA) keyed by GitHub login, only if an organization admin has switched the feature on (off by default); admins can see all profiles and other members only their own; and, for incidents from a connected Sentry or Rollbar, an optional stack trace. Integration credentials you paste in (Slack webhook URLs, Jira and Linear tokens) are encrypted at rest with AES-256-GCM. The full breakdown is in the Privacy Policy.
Who processes your code
Beyond our own infrastructure (Cloudflare runs the review pipeline, including a Cloudflare Workers AI model that triages the start of each pull request diff, and Neon hosts the database), three providers receive code from your pull requests. Anthropic runs the language model that writes reviews and tests; Anthropic's commercial terms, which our account is under, state that it does not train on this content. Voyage AI turns code chunks, issue descriptions with their file paths, your Bug Search queries and, if you connect an error tracker, error titles and stack traces into embeddings for Bug Genealogy, the Recurrence Firewall and Bug Search. Voyage AI's default terms let it use customer content to train its models; we opted out on October 2, 2026. Before that date the Service was in private testing: the only content we sent to Voyage AI came from repositories in our own GitHub accounts and from test data, and no customer content was sent to Voyage AI before the opt-out took effect. Fly.io hosts our code-parsing service, which reads changed and related files during a review, and the short-lived virtual machines that run tests, in the United States. The full list of providers is in the Privacy Policy.
Retention and deletion
Deletion runs automatically once a day. When you uninstall the GitHub App or remove a repository, its integration credentials are deleted immediately and the rest of its data after a 7-day grace period; a team's developer profiles and login links are deleted once none of its repositories remain. Developer Bug DNA data is also deleted when an admin switches the feature off, when a developer or admin erases it, after 90 days of inactivity, and 30 days after a member with a linked login leaves the organization. Bug Search embeddings are deleted after 90 days without a search, and job-failure records after 30 days. An organization admin can delete a repository's data, or all of the team's data, at any time from Data & privacy in the dashboard. Review text, bug fingerprints and risk scores have no automatic expiry, because remembering past bugs is the purpose of the service. What we keep after deletion is listed in the Privacy Policy.
How requests are verified
GitHub webhooks
Every inbound webhook's HMAC-SHA256 signature is verified over the raw request body using a constant-time comparison, before the payload is ever parsed. No signature, or a wrong one, gets a flat 401.
Dashboard authentication
Sessions are Clerk-issued JWTs, verified against Clerk's own JWKS with the signing algorithm explicitly pinned to RS256 — alg:none and algorithm-confusion forgeries are rejected by construction, not by convention. Every team-scoped API route resolves the calling team from the verified token's organization claim, never from a client-supplied id.
Stripe webhooks
Signature-verified first, then checked against an idempotency table before any state-changing write — a replayed, validly-signed event is a safe no-op, not a double-charge or a double-upgrade.
Sandbox isolation
What it does
Tests (your own suite for Test Coverage Gap, and generated regression tests for Production Lock) run in one short-lived virtual machine per job at Fly.io, destroyed when the job ends or forcibly destroyed if it never reports back. The machine never contacts GitHub and holds none of our credentials: the files it needs are handed to it by our service. Your code runs as an unprivileged user with caps on processes, open files and file size, under a hard timeout, and reports its result over an internal network path authenticated with a random per-job token.
Network access
Outbound network access from the machine is blocked by default, including DNS. The one exception is dependency installation for Test Coverage Gap: during that step, the machine can reach only the npm package registry (registry.npmjs.org and its mirror registry.yarnpkg.com) and PyPI (pypi.org, files.pythonhosted.org), over HTTPS, through a proxy we control. That access is closed before your tests run, so the tests themselves run with outbound network access blocked. We verified the default block on our live service on October 3, 2026: from inside a job, requests to a public website, a package registry, raw IP addresses and DNS were all blocked.
Limits, stated plainly
Installing Python dependencies can run your project's own setup scripts while registry access is open, so that code can reach those registries, though no other host, and the machine holds no secrets. npm installs skip install scripts. The sandbox protects bugweg and other customers from the code it runs; it does not make that code correct, so review generated tests like any other pull request.
Report a vulnerability
Found something? Email security@bugweg.com. We'd rather hear about a real problem from you first.