Trust & security

Why RepoSentry itself is safe to trust

RepoSentry's whole purpose is to help you decide whether to trust code you didn't write. That's a hollow promise if RepoSentry itself isn't trustworthy - so here's exactly what it does and doesn't do, in plain terms.

How RepoSentry protects you

Nine specific guarantees, not a vague promise - each one is something you can go verify.

Fetched read-only, never executed

By default, your own browser downloads the repo's file tree and content directly from GitHub's public API and CDN (api.github.com, raw.githubusercontent.com) - no git process touches it, and you can watch every request happen yourself in your browser's devtools. If that can't complete, it falls back to a plain git clone. Either way, the content is only ever read as text - RepoSentry never runs npm install, a build/test script, or any file from it in an interpreter. Scanning a malicious repo should never itself be the unsafe action.

Browser-fetched file paths are never trusted blindly

Every path the browser hands back to the server is checked before anything touches disk - absolute paths, .. segments, and anything that would resolve outside the scan's own workspace directory are rejected outright. A malicious repo can't use its own file names to write somewhere it shouldn't.

Deletes the workspace when the scan finishes

Once a report is written, the fetched or cloned copy is removed from disk - nothing from the target repo sits around afterward.

Redacts every secret it finds

If the scanner matches something that looks like a real credential, only a handful of leading/trailing characters are ever written to the report or shown anywhere. The full value is never persisted.

The AI review step has no shell or file-system access

It's one bounded API call given only the specific file contents a deterministic pattern-match already flagged - not an open-ended agent with Bash/Read/Write tool access to anything. There's no tool-use loop for a malicious repo to try to manipulate.

No telemetry or third-party tracking

No analytics SDK, no ad tracking, no third-party script tag beyond what's disclosed on this page.

A short, fixed list of who sees what

GitHub, for sign-in and to fetch the repo you ask to scan. Anthropic, for the AI review of specifically flagged content - auto-deleted from their systems within 30 days, never used for model training. OSV.dev, the public vulnerability database, no auth required. Stripe, for payment - RepoSentry never sees your card details. See /privacy for the full breakdown.

You never hand over an API key

The AI review runs on RepoSentry's own account, not yours - nothing to create, paste, or manage.

Scan reports are tied to your account, not shared

Stored so you can see your own history, never sold, never used for anything beyond running your scans. See /privacy for exactly what's kept and for how long.

What this isn't

A high score means known patterns weren't found - it doesn't prove the absence of a sufficiently well-hidden attack, and it isn't a replacement for professional review before granting a codebase real production access, credentials, or write permissions.

What the AI review step is actually allowed to do

It reads the specific file contents a deterministic pattern-match already selected, and returns a structured judgement - findings and a summary, nothing else. It has no ability to run commands, write files, or take any action beyond producing that judgement. There's no hidden instruction set influencing it beyond what's described on /methodology.

Verified, not trusted blind

AI findings are checked against the real code

An AI-reported finding is a claim until it's verified. Every finding the AI review step produces must name a real file and a verbatim snippet from it - that snippet gets checked against the actual file content before the finding is allowed anywhere near your score. Anything that can't be verified this way is dropped, not silently kept, and the drop (with its reason) is logged to the scan's activity feed - nothing disappears without a trace.

Private repos - Teams plan

A higher-trust action gets stricter safeguards

Scanning your own private code is a higher-trust action than scanning a public repo, so it gets its own, stricter safeguards on top of everything above.

Your token never reaches our server

You create your own GitHub fine-grained personal access token and paste it in - it's used only by your own browser to call GitHub's API directly. RepoSentry's server never sees it, stores it, or logs it; only the resulting file contents are sent, same as a public scan.

You set the expiry

Create it with a 1-day expiry (or shorter) and it's effectively single-use in practice, not a standing credential sitting around afterward.

Scoped to exactly one repo - you choose that yourself

GitHub fine-grained tokens support restricting access to a single repository, and RepoSentry's token-creation link pre-fills the expiry and permissions for you - but GitHub doesn't expose a way for us to pre-select "Only select repositories" on your behalf, so that one choice is yours to make when the token is created.

See the full private-repo flow

See /methodology for what the scan itself checks against, and /privacy for the full data-handling breakdown.