Security
Secrets are redacted on the developer's machine before a session is uploaded. Redacted transcripts are stored encrypted, separately for each org, and deleted after the org's transcript retention (30 days by default). Or keep them in your own bucket.
What Verity reads
The GitHub App has no Contents permission. It sees what a pull request changes, and it reads your rules through GitHub's Single file permission, which covers one path.
| Permission | What it reads | Why |
|---|---|---|
| Pull requests | The PR's diff, commits and labels | read & write: to post the comment |
| Checks | Nothing: it only writes | read & write: to post the check run |
| Single file | One file, .verity/rules.yml | read: your rules |
| Metadata | Repository names and settings | read: required by GitHub |
| Members (org) | Whether you are an org owner | read: for the Settings page |
| Contents | Not requested | no access to your code |
Sessions come from the capture hooks on developers' machines, not from GitHub.
Redaction
Secrets are redacted three times:
- On the developer's machine, before upload. The capture worker redacts the session as it is saved.
- On upload, before storage. Verity's server redacts it again before writing it to the org's transcript store.
- Before any model sees text. A final check runs before analysis.
Server logs hold ids, counts and error names only. No log line or database column holds transcript text.
Retention
| Data | Where it lives | Kept for |
|---|---|---|
| Redacted transcripts | Verity's storage, encrypted and kept separately for each org, or your own S3 bucket | 30 days by default (owners choose 7 to 180), or your bucket's rule |
| Reports | Verity's servers, encrypted and kept separately for each org. They include excerpts of flagged steps, command output and diffs | 90 days by default (owners choose 7 to 365) |
| Session index | Ids, repo, branch and times. No content | Until the reports expire |
| Model prompts | Not logged, and model providers keep no copy | Not kept |
| Server logs | Verity's log provider. Ids, counts, timings and error names: no session text, code, or repo and user names | 30 days at most |
| Product analytics | PostHog, sent by our server: which features are used, keyed by pseudonymous ids. No browser tracking, no session text, code, or repo and user names | PostHog's retention |
Who can see a report?
Only people signed in with GitHub who can read the code repository. Access is checked against GitHub on every view, so removing someone from the repo removes their access.
What do models see?
Only redacted text, after the final check, and never the PR description. They answer yes-or-no questions and write the report's short summaries; the rules decide every result. Their prompts and outputs are not logged, and every request goes only to model providers that keep no copy of it (zero data retention, set on our account and asked for on each request).
What does Verity record about overrides?
The GitHub login and account type (user or bot) of whoever added the override label, and when. Nothing from the session.
Can developers opt out of capture?
Capture is an org decision, and the hooks are committed to the repo so everyone can see them. They do nothing for a developer who hasn't installed verity, and a developer who is signed out keeps sessions on their own machine. Their pull requests are still checked against the org's rules, without a brief, and a rule that needs the session fires unless it sets no_session: pass.
Can we self-host?
Not today. Verity is hosted only.
Report a vulnerability
Email security@veritypr.dev. Please include:
- what you found, and where (the URL, the command or the file);
- the steps to reproduce it;
- what an attacker could do with it.
Test only against your own organization and repositories, never against another customer's data. There is no bug bounty for now.
Machine-readable contact details are in /.well-known/security.txt.