Security
Hyrax reads your source code and holds the credentials to do it. This page is the plain-language summary of how your code and data are protected. Your security team can request deeper detail — controls, sub-processors, and our data-processing agreement — through your account contact; see also Compliance.
How your data is protected
- Your workspace is isolated. Each workspace's data lives in its own database schema, reached through its own database role that is granted access to that schema and nothing else — so for the bulk of your data Postgres itself rejects a cross-workspace query before it reaches a table, rather than relying on application code remembering to filter. A smaller set of platform-wide records — the ones that by nature span workspaces, like scheduling work and billing for it — sits outside those schemas, and your workspace's database role holds no access to them either; the separate privileged path that reads them is scoped per workspace in application code, under code review and automated static-analysis gates. One workspace can't read another's data: even two workspaces auditing the same public repo get completely independent findings and history.
- Hyrax reads your code with short-lived access. Private repos are connected through the Hyrax GitHub App. Each job mints a token that expires within the hour; Hyrax never stores long-lived personal access tokens. Public repos added by URL are cloned with no token at all.
- Clones are ephemeral. A job clones your repo into isolated, throwaway compute, analyzes it, and deletes the working directory when the job ends — on success, failure, or cancellation. Raw source is not kept. When a job runs your tests or the build/lint checks behind a fix, that happens in a locked-down sandbox with no credentials and no network; everything else a fix executes (its shell commands, dependency installs, the project's formatter) runs on the job's own single-customer, throwaway container with cloud credentials scrubbed from the environment and only a repo-scoped token in reach — see Execution environment.
- Secrets stay out of logs. Credentials are redacted from logs and error output, kept out of subprocess environments, and cleared at job end. Per-workspace integration keys (such as a ticketing key) are encrypted before they're stored.
- Encryption everywhere. All traffic is TLS; data at rest is encrypted with managed keys.
- Your data is backed up and recoverable. The production database is continuously backed up and replicated across multiple availability zones, with encrypted point-in-time recovery. We keep a documented restore procedure and test our ability to recover on a recurring cadence.
- Sign-in is hosted, password-free single sign-on. You authenticate with your Google account or a one-time code sent to your email, and existing GitHub sign-ins keep working — there's no Hyrax password to leak. Two-factor authentication is a mandatory floor on every account, satisfied automatically by your verified login email with no setup burden; you can additionally add an authenticator app (TOTP) or passkey.
- AI output is screened. Before Hyrax writes any AI-authored text to a PR, comment, ticket, or doc, it runs through a fail-closed validator that blocks prompt-injection and exfiltration attempts. This is layered defense, not an absolute guarantee.
What Hyrax stores
Hyrax keeps the metadata of what an audit found — finding titles, descriptions, priorities, categories, and the file locations they point at — plus your repository and discovery context. It does not keep your source files or code snippets long-term. Staged copies of your source on the processing infrastructure auto-expire within 7 days as a backstop — the working clone itself is deleted the moment a job ends, on success, failure, or cancellation; per-job execution records — job checkpoints, including captured build and test output — are retained with your job history and erased when your workspace is purged.
Data retention at a glance
| What | How long it's kept |
|---|---|
| Your source code / clones | Deleted when the job ends — on success, failure, or cancellation. Never retained. |
| Staged working copies on processing infrastructure | Auto-expire within 7 days as a backstop; deleted at job end in normal operation. |
| Finding metadata & job history (titles, descriptions, priorities, file locations, job checkpoints, captured build/test output) | Kept with your workspace for as long as it's active; erased when you purge the workspace. |
| Model-processing logs | Request metadata and token counts only — never your code, prompts, or model output. |
| Encrypted database backups | Up to 35 days, then rotated out automatically. |
| Tamper-evident security & deletion records | Kept for as long as your workspace exists and, for the deletion receipt, after it. These records are append-only and hash-chained, and an hourly cryptographic anchor of that chain is written to write-once storage held for 2 years, so the integrity of the trail — and the fact that your deletion happened — stays provable. The write-once copy is the anchor, not the record contents. |
Deleting a workspace stops all processing immediately, but a small number of these records (encrypted backups and tamper-evident audit entries) age out on their own retention cycle rather than vanishing instantly. None of them contain your source code.
Where your code is processed
Audits, fixes, and reviews run on Hyrax-paid, AWS-hosted AI models, and your code is sent to a model only to perform the job you asked for. Whether a model provider retains inputs is governed by that provider's data policy — Hyrax does not make an independent "never used for training" claim, so if that matters to your review, the model provider's data terms are the relevant commitment.
Hyrax runs in the United States: your code and data are processed and stored on Amazon Web Services in the US West (Oregon) us-west-2 region, and that is the only region any of it is stored in. Some infrastructure necessarily sits outside it. The content delivery network in front of the app terminates connections at edge locations across North America and Europe before passing each request through to us-west-2; responses carrying your code, findings or account data are never cached there, so no copy of them rests at the edge. Its TLS certificates must live in AWS's us-east-1 region, which AWS requires of any CDN certificate. Model requests ride AWS's cross-region routing, which stays inside the United States.
Deleting your data
Removing a workspace is a deliberate, staged flow:
- Deleting your workspace is reversible for about 30 days. The workspace is paused — writes are blocked and data becomes read-only — but everything, including your sign-in, API keys, and integrations, is preserved so you can restore it yourself with one click. At the end of the grace window the workspace is fully disabled: sign-in sessions and API keys are revoked, integrations are paused, and running jobs are cancelled. If you need access cut off immediately, revoke API keys and remove members directly rather than relying on workspace deletion.
- Purge is the permanent step. A workspace that holds data is purged by Hyrax rather than self-serve: you request it from workspace settings, we verify the request and run it on our audited deletion path. (An empty workspace — no repos, no invited members — can be removed outright by its owner, since there is no data to protect.) It erases your workspace's data, job artifacts, and stored secrets. A minimal, tamper-evident deletion receipt is retained so the deletion itself is provable.
Public repositories
You can add a public repository by URL without installing the GitHub App. Those repos are cloned anonymously and are read-only — Hyrax can audit, profile, and review them, but can't open pull requests or comment until the App is installed on the org. See Public & private repositories.
Reporting a security issue
Found a vulnerability? Report it to security@hyrax.dev. We acknowledge reports within one business day and give an initial assessment within five. Please hold public disclosure until a fix ships.