docs.security_model()

what happens to your code

you are handing a security tool your source code, so this page is specific about what that code touches. the short version: read, never executed; scanned in a sealed container; secrets scrubbed before storage or any model prompt; audit-only output.

## your code never executes

virgil is static analysis. nothing in your repo is run, imported, or installed on our hosts — no build step, no dependency install, no test execution. the repo snapshot is mounted read-only into a scanner container and read.

## the sandbox

every scanner invocation runs in a container with:

--network=none                 # no internet, no internal network
--read-only                    # immutable filesystem
--cap-drop=ALL                 # no linux capabilities
--security-opt=no-new-privileges
--pids-limit / --memory / --cpus   # bounded resources
--user 65534:65534             # non-root (nobody)
/repo mounted read-only

a hostile repo can't phone home, escalate, or exhaust the host — the scanner sees the snapshot and a scratch output directory, nothing else.

## secrets are redacted before anything else happens

scanners find secrets; virgil makes a point of not keeping them. before findings are persisted — and separately, before any text reaches an llm — these patterns are replaced with redaction markers:

+aws access keys and secret keys
+github personal access tokens
+jwts, slack tokens, google api keys
+private-key blocks (pem)
+generic secret= / token= / api_key= assignments
+rfc1918 / link-local ips and host filesystem paths

a finding about a leaked aws key tells you where the key is — the key itself is stored as AKIA…<redacted>. the ~30-line code slice kept with each finding (for grounded chat and evidence) goes through the same scrubbing first.

## audit-only output, enforced

every llm response — rationales, report narrative, chat — passes a validator that rejects exploit payloads, unified diffs, and step-numbered reproduction instructions before it's stored or rendered. rejected output degrades to a generic explanation rather than slipping through. virgil tells you what's wrong and how to think about fixing it; it does not write attacks.

## transport + accounts

everything moves over tls. accounts are google sign-in only — virgil never sees a password. the cli authenticates via a device-code flow you approve in the browser; tokens live in ~/.config/virgil/credentials.json and can be overridden with VIRGIL_TOKEN in ci.

## no telemetry in the cli

the cli contains no analytics, no usage pings, no crash reporting. it talks to the virgil api to run your scans and nothing else — you can read exactly what it sends: the package on pypi ships its full source.

questions this page doesn't answer: ask directly or see the privacy policy.