Security

Security

How we plan to run code we do not trust, what the audit agent cannot do, and the risks we cannot fully remove.

Status of this page. This describes the design. It has not been audited or certified, and no certification is claimed. Each control carries a status; it moves to Implemented only when the matching security test passes in the release pipeline. Status as of 2026-10-25: nothing on this page is marked Implemented yet.

The threat we design for

A repository can contain instructions meant for the AI tools reading it, malicious build scripts and oversized archives. We assume the analysis step will be fooled sooner or later, so we build it to have nothing to steal and nowhere to send it.

The pipeline

Audit pipeline: fetch, build, analyze with no network, reportFour stages in sequence. Only the analyze stage is isolated from the network; it talks to a gateway that accepts one kind of request.FETCHread-only cloneBUILDcompile, no secretsANALYZEno networkREPORTschema-checkedGATEWAYone request type, with a budgetEach audit runs in a fresh container that is deleted afterwards.

What the agent cannot do, and what enforces it

Enforcement is by system controls, not by a prompt.

Status labels: Designed (specified, not yet built or tested), Implemented (built and covered by a passing test), Planned (not yet specified in detail).
The agent cannotEnforced byStatus
Reach the internetNo network in the analysis sandbox; one gateway socket that accepts one request type.Designed
See real API keysKeys live only in gateways; the sandbox holds a short-lived run token.Designed
Read the repository access tokenThe token exists only in the fetch step.Designed
Read other customers’ dataA new container per run, no shared volumes or caches.Designed
Escape to the hostSandbox with dropped privileges, read-only root and resource limits.Designed
Pick up settings from your repo (hooks, MCP configs, agent instructions)Agent config files are stripped before analysis and the tools run with fixed settings.Designed
Smuggle data out through the reportReports are parsed against a schema and rendered with no external resources.Designed
Spend without limitBudget and time limit per run, enforced at the gateway.Designed
Run on a dedicated analysis hostAnalysis moves off the shared demo host.Planned

Your account and your money

Sign-in is by email code. Balance entries are an append-only ledger. Whether two-factor sign-in or passkeys will ship at launch is not decided, so none is claimed here.

What we cannot fully close

  1. The demo is planned to run on a shared host: a sandbox escape would be serious. We plan to move analysis to a dedicated host.
  2. An attacker can try to make the tools skip a bug. Controls reduce this but cannot remove it; the coverage section of every report is the check.
  3. The text of your code goes to the AI model provider to produce findings. Provider terms and retention are not final yet.
  4. Zero-day bugs in our dependencies (git, the container runtime, the tools themselves).
  5. The RPC provider sees the addresses queried in fork mode.
  6. Dependencies pulled during the build step carry supply-chain risk.

Report a vulnerability

A dedicated security address is pending. Until then, use the contact page and mark the message as a security report. Do not include exploit details in the first message.

How to read a report · Audit tools