Security and data handling

What CrossCheck reads, where it runs, and what it never does.

What CrossCheck sees

When a review fires, CrossCheck clones the PR's head commit into an isolated sandbox and gives the reviewer agent read access to the working tree. The agent can:

• Read files anywhere in the repo.
• Run shell commands (read-only by default; write_file and apply_patch are off unless you opt in per check).
• Call out to a curated, vetted list of MCP tools your org admin has enabled.

The agent cannot:

• Reach the internet from inside the sandbox. pip install, curl, npm install — all fail. Network is --network=none at the container level.
• Touch your databases, your staging environments, or any of your other infrastructure.
• See other repos in your org. Each review is scoped to one repo at a time.
• See other customers' code. The sandbox is fresh per review and torn down after.

Sandboxing

Reviews run inside a hardened syscall-isolated sandbox — the same class of isolation cloud providers use to run untrusted workloads. The reviewer agent cannot see the host kernel, the worker process, or any state from other reviews.

In addition:

• The sandbox is a fresh container per review. State doesn't carry between reviews.
• The repo working tree is the only writable filesystem; everything else is read-only or absent.
• A per-statement bash timeout (5 min) and a per-statement total bash budget (10 min) cap how long any single check can run.
• A per-statement step limit caps how many LLM iterations the agent gets before being cut off.
• The container is removed within 10 min of starting regardless of state, even if the review process orphaned it.

Secrets

CrossCheck mints every credential the agent needs at review start, with the shortest practical TTL, and revokes them at review end.

The worker doesn't hold provider API keys. Anthropic / OpenAI keys live on the LiteLLM gateway only; the worker calls the gateway with a virtual key that the gateway translates upstream. A compromised worker can't exfiltrate your provider keys because it never has them.

Secret scrubbing inside the sandbox. Before any bash tool call runs, CrossCheck strips a known set of credential environment variables (OPENAI_API_KEY, ANTHROPIC_API_KEY, GITHUB_TOKEN, internal CrossCheck tokens). If a check description happens to be "find all API keys in this repo," the agent can't accidentally surface CrossCheck's own keys.

Data handling

What's stored long-term:

• The text of your check descriptions, repo config, and cross-check.yaml cache.
• Per-run results: pass/fail/needs-review verdicts, evidence text, file:line references, credit cost.
• LLM traces (model calls, latencies, token counts) for cost and quality monitoring, stored in our self-hosted observability stack.

What's not stored:

• Your source code. We clone per-review into a sandbox; the sandbox is destroyed at run end.
• GitHub access tokens. Minted per-request, never persisted.
• PR diffs as standalone artifacts (the agent reads them at review time; we keep evidence excerpts, not full diffs).

Retention: Per-run data is kept for the life of your subscription plus 30 days after cancellation, then deleted. Customer-uploaded config (check groups, repo settings) is kept until you delete it.

Sub-processors

CrossCheck routes LLM calls through a self-hosted gateway in front of a small number of commercial model providers. Every provider we use is configured under enterprise terms that prohibit training on customer data.

For a current sub-processor list, or an enterprise contract that pins or excludes specific providers, email [email protected].

Access controls

Org membership. Every CrossCheck user belongs to one or more orgs. Within an org, all members can see all runs, check groups, and repo settings. There is currently no per-repo permission model — if you need one, let us know.

Operator access (CrossCheck staff). CrossCheck staff have a separate operator dashboard for fleet, queue, and cost monitoring. Staff do not see customer source code, check evidence, or PR contents through normal operation. In the rare case where an operator needs to debug a specific failed review (e.g. you've reported one in support), we'll ask first.

Audit log. Stripe events (subscription, plan changes, cancellations) are logged on the Stripe side and visible in your portal. CrossCheck-side audit logging (who changed which check, who attached which group) is on our roadmap.

Reporting a vulnerability

If you find a security issue, email [email protected]. We aim to acknowledge within one business day and remediate critical issues within five.

Please don't open a public GitHub issue or PR for security-sensitive reports.

Compliance

For procurement questionnaires or a security review packet, email [email protected].