What actually happens to your code when you connect Parry.
A security scanner that touches your source code is itself a security boundary. This page is the boundary's spec — written for the engineer reviewing it before signing, not for the marketing funnel. If a claim isn't here, we don't make it.
Where your code lives, second by second
- 01
Push event arrives
A signed push event arrives from your code host. Parry verifies the signature and queues a scan. No code has crossed yet.
- 02
Short-lived access token
Parry mints a short-lived, repo-scoped access token. Used for one clone, then discarded. Never written to disk; never logged.
- 03
Hardened clone
Your repository is cloned into a per-scan workspace, with strict protections against hostile metadata, symlinks, submodule recursion, and credential-prompt hangs.
- 04
Sandboxed fan-out
Each scanner runs in its own isolated container. Your code is mounted read-only. No network egress unless that engine genuinely needs it. No privileges. Bounded memory, processes, CPU. Hard per-engine deadlines.
- 05
Findings persisted
Findings, matched-line snippets, and raw scanner output land in your tenant. Used for lifecycle, re-export, and audit evidence.
- 06
Workspace destroyed
The cloned source and ephemeral artifacts are removed from disk within seconds of scan completion. Only the durable rows above remain.
What every scanner runs with
Scanners parse attacker-controlled repository content and have historically had parser bugs. Without a real sandbox, a single bug can be ten minutes of free compute and outbound network. Parry treats every engine as untrusted — even the well-known ones.
- No network egress by default
Scanners run in isolated containers with outbound network disabled. The few engines that genuinely need outbound (vulnerability databases, package registries, dynamic-application targets) are explicitly opted in — most are not.
- Minimum privilege
Every scanner runs with the smallest possible privilege set. No host capabilities. No privilege escalation. A bug inside one scanner cannot reach into the host or another scan.
- Read-only access to your code
Your repository is mounted read-only into the scanner. The scanner can analyze it; nothing inside the container can modify it.
- Bounded resources
Per-engine memory, process, and CPU caps. A misbehaving scanner cannot starve other scans or the host.
- Hard time limits
Each engine has a per-run deadline. On timeout or cancel, the scanner is forcibly stopped — not just signaled. Hung scanners cannot run forever.
What protects the worker from a hostile repo
- Hostile-repository protections
The clone step refuses extension protocols, blocks unsafe local-path tricks, ignores in-repo symlinks, and skips submodule recursion. Hostile metadata files cannot redirect the clone or escape the workspace.
- No interactive credential prompts
A manipulated repository URL cannot hang the scanner waiting for input.
Stored after the scan
- Findings
Rule, severity, title, and a stable fingerprint. Required for the open / fixed / suppressed lifecycle that distinguishes Parry from a one-shot scan.
- Code snippets — only the matched lines
Rendered in the finding drawer so you can decide without leaving Parry. Not the full file. Never the whole repository.
- Raw scanner reports
Required for re-export to standard formats (SARIF, SBOM), AI re-runs, and audit evidence. Bounded in size; oversized reports are dropped.
- Software bill of materials
One per scan. Hand to procurement; satisfies the supply-chain question without exporting from N tools.
Removed within seconds
- The cloned source code
The full repository is removed from disk within seconds of scan completion. The only thing that outlives the scan is the matched-line snippets above.
- Your repository access token
Used only inside one scan, then discarded. Never written to disk.
- Files outside the matched lines
Only the lines a scanner flagged become snippet rows. Everything else is dropped with the workspace.
What crosses, when, and with what redaction
- When does code cross the AI boundary?
- Only when the org owner has explicitly opted into AI Review for that org. Off by default. The opt-in screen names the AI provider so you can verify their current data-handling policy yourself.
- What gets sent?
- The diff under review, plus surrounding context lines from the changed files. Whole repositories are not sent.
- What is stripped before transmission?
- Detected secrets and environment files are redacted before the payload leaves Parry. The AI engine reviews code, not credentials. The redaction is unit-tested.
- Are AI providers training on your code?
- Parry uses provider APIs configured for no-training (zero-data-retention where the provider supports it). Because the provider is named on the opt-in screen, you can re-verify their current policy at any time.
Where Parry runs and who can reach your data
- Tenant isolation
Every API path scopes by organisation at the gate layer. Roles are typed (owner / admin / member); destructive actions — billing, configuration changes, finding acceptance — require the matching role. Any open / development mode refuses to start unless bound to local-only access.
- Transport
TLS everywhere — webhooks, sign-in, API. Session tokens are random; the database stores only a hash, so a snapshot leak cannot replay live sessions.
- Audit trail
Mutations — suppress, accept, configuration edits, billing changes, role grants — are recorded for owners to inspect. Read-event logging and tamper-evidence are roadmap.
The honest gap list
If your security policy depends on any of these, do not sign with us yet. Each item is on the roadmap; none are shipped.
- Single-tenant / customer-cloud deployment
On the roadmap; not shipped. For organisations whose policy forbids source code from touching shared infrastructure, this is the only honest answer — and it isn't ready yet. Don't sign with us before this lands if your policy requires it.
- Automatic data retention policy
Findings, scans, raw reports, and audit log accumulate today. Per-organisation retention controls (default 90 days, configurable) will land before retention is charged for as a feature.
- SOC 2 / ISO 27001 certification
Not yet. The controls many auditors check for — role enforcement, audit log, hardened sandbox, no public open-mode, dependency-health probes — are in place; the formal report is not. Engagement-mode buyers should treat this page as the security questionnaire response in lieu of the report.
Procurement walkthrough
Reviewing Parry as part of a security questionnaire? Most of the answers are above. For the rest — penetration test summaries, sub-processor list, current data-handling attestations, customer references — reach out at hello@parryai.dev.