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 or a mission step, that happens in a locked-down sandbox with no credentials and no network; everything else such a job 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. Once you do, Hyrax asks for it, rather than an email code, as your second step when you sign in and when you confirm a sensitive action.
• AI output is screened. Before Hyrax writes any AI-authored text to a PR, comment, or ticket, 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, and the work you track in Hyrax: your Areas, Spaces, Projects and issues, Team context entries, and the plans and history of any missions. It does not keep your source files long-term. Portions of your code can appear in what it does keep — up to whole files, briefly, in copies of AI model responses, and excerpts for the life of your workspace in job history such as captured build and test output — as the table below sets out. 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. The clone itself is never retained; portions of your code, up to whole files, can remain in the model-response copies, and excerpts in the job history, described below.
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.
Projects, issues, Team context, and missions	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.
Model responses	Copies of AI model responses, which can include portions of your code, up to whole files, are kept for about a day so a retried request is not run or billed twice — a scheduled cleanup normally deletes each copy within 30 hours — and can remain in encrypted database backups for up to 30 days after that. These copies are not tied to your workspace, so purging it does not delete them early; they expire on this schedule. For some jobs that change your code, the instructions the job was given and the model's rewritten version of them are kept with that job's history and erased when you purge the workspace.
Encrypted database backups	Up to 35 days, then rotated out automatically.
Tamper-evident security & deletion records	Kept for as long as your workspace exists. After a purge they are retained, so the deletion itself stays provable. 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, short-lived copies of AI model responses, and tamper-evident audit entries) age out on their own retention cycle rather than vanishing instantly. The tamper-evident audit entries contain no source code; the backups and model-response copies can contain portions of it, up to whole files, until they expire.

Where your code is processed

Audits, fixes, reviews, and missions 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. About 30 days after a deleted workspace is disabled, Hyrax permanently erases its data, job artifacts and stored secrets on our audited deletion path. An unpaid usage (overage) invoice holds the purge until it's settled. (An empty workspace, with no repos and no invited members, can be removed outright by its owner, since there is no data to protect.) To delete sooner, contact support. Its tamper-evident security and deletion records are 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 comment on pull requests until the App is installed on the org. They can't open pull requests either, and installing the App later doesn't change that: the repo has to be removed and added again with the App installed. 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.