Security · Trust
How VeriFlow protects your source code, end to end
Encryption in transit and at rest, per-repo and per-review-run isolation, the exact GitHub App permissions and webhook subscriptions the agent requests, audit logs scoped per repository, and a candid SOC 2 Type II readiness timeline — the same security story the FAQ tells, on a page you can hand to your security team.
Encryption
Encryption in transit and at rest
PR diffs and review payloads are encrypted at every hop the platform makes — from the webhook delivered by GitHub, through the diff read, to the managed disk the review is staged on, and through the backups that protect the corpus.
Every request the agent makes back to GitHub is over TLS with HSTS, and every webhook GitHub delivers to the agent is HMAC-verified against a shared secret rotated through your App configuration. Deliveries that do not originate from the configured GitHub endpoint are rejected before any code is read, so a forged webhook cannot trigger a review run.
PR diffs and review payloads are encrypted at rest on managed disks in the same region they cross the wire through, so the bytes between a GitHub webhook and an inline review are covered at every hop the platform makes the disk. Disk-level keys are managed by the platform and rotated on the underlying provider cadence.
Backups of the review corpus are encrypted with the same managed-disk posture as the live data, retained for the same window as the in-product retention, and never decrypted outside the production runtime. Restoring from a backup reuses the same per-tenant isolation as the live read path.
Isolation
Tenant and review-run isolation
Each GitHub App install is the boundary — the App sees only the repositories you granted at install time, and the grant list you set at install is the boundary the agent never crosses. Nothing else in your GitHub workspace is reachable from the agent: organizations, packages, actions secrets, and unrelated repositories stay outside the App’s grant list.
Every review run is scoped per repository, retained only for the time required to render the review and surface the inline comments, and isolated from the runs that came before it and the runs that run in parallel. There is no cross-tenant data sharing: the diff payload from one install never enters the read path of another install, and the audit trail for one install is not visible from any other install.
Code access scope
The exact GitHub App permissions and webhook subscriptions
This is the same list the FAQ publishes, not a marketing summary — the byte-for-byte permission map so the trust page and the FAQ cannot drift apart.
The VeriFlow GitHub App requests the minimum set of scopes needed to read the diff, post a review, and surface status on the PR timeline — and no more. Contents (read & write) and Pull requests (read & write) are the two write scopes; Checks (read & write) and Issues (read & write) cover the per-commit status check and tracking-issue workflow; Metadata (read-only) is the GitHub-required identifier scope and is used solely to name the connected repository. The install flow fits on a single screen — pick the scopes you are comfortable with, choose the repositories the agent should watch, and confirm.
The App subscribes to three webhook events on every granted repository: pull_request, pull_request_review, and check_run. That set covers every transition the review loop reacts to, and no other events are subscribed to — so a workflow_dispatch, a release publish, or a star on the repository does not enter the agent's read path.
See the FAQ entry on GitHub App permissions for the post-install verification steps.
Secrets handling
Webhook signing keys, review.yml, and customer-side secrets
The webhook signing key is rotated through your App configuration — not stored as a static secret in the agent codebase — so a compromise of any single signing key can be remediated without re-issuing the App. The same rotation cadence applies to the shared secrets the platform uses for webhook delivery to the agent.
review.yml is a configuration file only — VeriFlow does not execute it as code, does not spin up a runner, and does not touch your test suite or build pipeline. It lives at .github/review.ymlon the default branch and owns the per-repo shape of the review (depth, paths, ignore patterns, comment volume, per-language overrides). Customer-side secrets — repository secrets, environment secrets, GitHub Actions secrets — never leave your repository: the agent’s read path is scoped to the diff and the repository the App was installed on, and the agent does not read the secrets store.
Audit logging
What the agent logs, and what the security team can pull
Every webhook delivery, every review run, and every App install event lands in the audit log — the same surface the Enterprise rollout brief references.
Every GitHub webhook delivered to the agent is logged with its event type, repository, delivery id, and HMAC verification outcome — accepted deliveries and rejections both, with the delivery id the platform assigned. The log lets the security team reconstruct the review run that produced any specific commit.
Every review run is logged with the diff version it consumed, the review payload it produced, and the comment volume it posted. A reviewer on the security team can match a specific commit on a specific branch to the comments the agent surfaced, and walk back through what the agent saw at the time.
Every GitHub App install, repository scope change, and App upgrade is logged with the actor and the timestamp. Default retention is 12 months; Enterprise customers can request extended retention and a customer-export path through the contact form so the audit trail lives in the team's own log store, not just on the agent platform.
SOC 2
SOC 2 Type II readiness — candid timeline
The cards below describe the live control state today, the in-flight milestones, and what we will not claim until the report exists. No auditor name, no certification date, and no trust-mark badge ships here — each lands when the underlying report exists.
Candid status — not yet SOC 2 certified
No certification has been issued yet. The wording below is the candid state of the controls today, not a marketing claim about a finished audit — every line is verifiable in the live system or in the policy documentation linked here.
Candid status
Access control, encryption in transit and at rest, the audit-logging posture described in the band above, and change management with a two-person approval policy on every production change are already operational. Internal reviews run quarterly; the gap from those reviews to a Type I report is the one this readiness timeline is closing.
Candid status
Control scoping is complete; the formal Type I readiness target is being tracked against the public roadmap. The Type II observation window opens after a clean Type I — the milestone slate below is illustrative in the same way the team grid on /about is illustrative, with concrete dates landing as the audit window is committed.
Candid status
No auditor name, no certification date, and no trust-mark badge appears here yet — each of those lands when the underlying report exists. Customers running a security review today can ask for the live-control walkthrough under NDA through the contact form below; customers scoping a procurement decision get the same walkthrough alongside the readiness timeline.
The milestone dates are illustrative in the same way the team grid on /about is illustrative — concrete dates land as the audit window is committed.
Running a security review?
We answer the questionnaire your security team fills out — SSO, data residency, audit-log shape, retention, and the SOC 2 readiness timeline. Pick the Security subject on the contact form so the inquiry lands with the right team.