Privacy & security
What happens to your code during a scan, what RedNest keeps, and who can see it.
RedNest never stores your source code. Every scan runs in a temporary environment that's deleted when the scan finishes. Model inference runs with zero data retention. We keep only your findings and the minimum code excerpts needed to explain them.
This page explains how that works. The Privacy policy is the formal version.
During a scan
- RedNest clones with a short-lived GitHub token that can only read the contents of the one repository being scanned. Its other GitHub calls during the scan, such as reading a pull request's files and posting the Check, use the installation's own short-lived token.
- It makes a shallow clone of that one commit into a temporary workspace: in the hosted service, an isolated virtual machine created for this scan alone.
- The scan reads the code there. Nothing in the repository is executed.
- When the scan ends, whether it succeeded or failed, the workspace is destroyed. There are no snapshots and no cache of your code.
Scans are orchestrated in steps that pass only IDs between them, so your code never enters the system that tracks running scans.
Model inference
Code is sent to the model only for the duration of a scan. Our policy is to use model inference with zero data retention: the provider we use is set up not to keep prompts or outputs.
RedNest adds no account, repository, organization or user identifiers to prompts. Your code itself goes to the model, though, so anything written in it does too, such as names, email addresses or URLs in comments. Repository content is passed as clearly marked untrusted data, and the model is told to report text in it that tries to instruct it, rather than follow it.
What RedNest keeps
| Kept | Why |
|---|---|
| Findings, with short code excerpts for each step of the attack path | To show you the vulnerability and build its fix prompt |
| Each repository's threat model: a structured summary of entry points, trust boundaries and risky code | So every scan starts from what is already known |
| Scan records: status, timings, counts, and the live feed's progress messages | To show scan history and settle scan allowances |
| Your account: GitHub user ID, username, display name, email address and avatar | To sign you in and send notifications |
| Each sign-in session, with your browser's user agent | To keep you signed in |
| Your GitHub sign-in token, encrypted | To check which repositories you can access |
| API keys and agents' OAuth tokens, as SHA-256 hashes only, with each one's name and when it was last used | To let your agents act as you, and show them in Settings |
| Verified Solana wallet bindings (public key and verification timestamps) | To support planned $RED holder eligibility |
| Entitlement usage (free scan and monthly holder quotas) | To enforce scan allowances |
| Legacy billing state, when that module is enabled for an account | Historical credits/plan data for accounts that still use it |
Your email address is the primary one on your GitHub account, even if it is private on GitHub, because the App may read email addresses. A no-reply placeholder is used only when GitHub returns no address at all.
RedNest doesn't keep your source code, clones or diffs, and sign-in doesn't record IP addresses.
When code excerpts are deleted
A finding's code excerpts, together with the stored fix prompt that quotes them, are deleted when:
- the finding is fixed or dismissed, and a dismissed finding stays without code if a later scan finds it again
- its repository is removed from the installation
- the GitHub App is uninstalled or suspended
The findings themselves stay, without code, so your history survives. Uninstalling stops new scans from starting; a scan already running may still finish.
Who can see findings
- A person can see a repository's findings only if GitHub says they have push access or higher to it. RedNest checks with GitHub using their own sign-in, and re-checks at least every five minutes.
- On public repositories, nothing about a finding is posted to GitHub beyond a count by severity, because Checks and comments there are public. See PR reviews.
- Organization sponsorship and App settings can only be changed by admins of the GitHub organization, or the owner of a personal account. Wallet verification is done by the signed-in person in Settings.
- Agents act as the person who connected them, with the same access, re-checked with GitHub the same way. Connecting always needs that person's approval in their browser, signed in with GitHub: an MCP client's OAuth consent (with PKCE), or a device code they confirm. Revoke any agent in Settings → Agents. See Use it from your agent.
GitHub App permissions
RedNest asks for the least GitHub lets it.
| Permission | Access | Why |
|---|---|---|
| Contents | Read | Clone and read code |
| Metadata | Read | Required by GitHub for every app |
| Pull requests | Write | Post review comments |
| Checks | Write | Report each review as a Check |
| Issues | Read | Receive the /sandchest review command from pull request comments |
| Members | Read | Know who the organization's admins are, for billing and settings |
| Email addresses | Read | Your sign-in email, for notifications |
RedNest never writes to your code and never opens issues.
Analytics, email and payments
- Analytics are first-party. Usage events (page views with IDs removed from the address, time on page, clicks, sign-up steps and actions) go to RedNest's own database. A random ID in a cookie ties them to a browser, and to an account after sign-in. They record opaque IDs, counts and categories, never code, finding contents, repository names, names, email addresses or IP addresses. The hosting provider's cookieless web analytics count page views and measure page speed. There are no advertising or tracking scripts.
- Finding emails cover new critical findings and finished deep scans. They go to people who have signed in and had push access to the repository when RedNest last checked, within the past 30 days. An admin can turn these emails off for the account in Settings.
- Operational emails go to account admins when a scan stops because the model provider refused it, and (when the legacy credits module is enabled) when credits run low or an auto top-up fails. Admins are people GitHub confirmed as admins in the last 30 days; if there are none, RedNest asks GitHub before sending.
- There is no marketing email.
- Public hosted access does not require a fiat subscription for the free scan or planned $RED holder model. Legacy card billing, when enabled for an account, is processed by Stripe through Autumn; RedNest never sees card numbers.
The list of subprocessors that handle data for the hosted service is available on request from the contact address in the Privacy policy.
Self-hosted
A self-hosted RedNest sends nothing to us: no telemetry, no usage data. It talks only to GitHub, your own model endpoint, and the OSV vulnerability database (package names and versions only). See Self-hosting.
Reporting a vulnerability in RedNest
Please report security issues in RedNest itself privately, to the security contact on the Privacy page, rather than in a public issue.