Security & trust
Reviews without write access to your code.
Forseti reads your pull requests with read-only access to code and holds patches in memory. It never clones or keeps your repository, and never trains on your code. It stores only the few lines each finding quotes, and you can switch that off. Here is exactly how, and what we have not done yet.
- Code access
- Read only
- No write access to your code, ever
- Repository copies
- None
- Findings keep only the lines they quote; switch off in Settings
- Training
- None
- Your code never trains a model
- Rules read from
- Base branch
- A PR cannot change its own review
GitHub App permissions
Five permissions. Code is read only.
These are the permissions Forseti asks for when you install it, and the same list the Settings page checks live against your installation.
Deliberately not requested
- Contents write: we never push code; you commit a suggestion yourself, under your name
- Workflows and Actions
- Administration
- Commit statuses (the check run replaces them)
- Members and any organisation permission
Because we ask for no organisation permission and no Administration, a repository admin can install Forseti without waiting for an organisation owner.
| Permission | Access | Why we need it |
|---|---|---|
| Pull requests | Read and write | Read the PR and its changed files. Post one review with inline comments, edit our summary in place, reply to and resolve our own threads, and request the reviewers you choose. |
| Contents | Read only | Read files around the diff and the base-branch .forseti.yaml, and compare commits for re-reviews. We never write code. |
| Checks | Read and write | One check run per head SHA, carrying the verdict and annotations, with a re-run button. |
| Issues | Read and write | Read is how @forseti commands in PR comments reach us. Write lets us acknowledge a command with a reaction instead of a noisy reply. |
| Metadata | Read | Required for every GitHub App: repository names and repository events. |
- Pull requestsRead and write
- Read the PR and its changed files. Post one review with inline comments, edit our summary in place, reply to and resolve our own threads, and request the reviewers you choose.
- ContentsRead only
- Read files around the diff and the base-branch .forseti.yaml, and compare commits for re-reviews. We never write code.
- ChecksRead and write
- One check run per head SHA, carrying the verdict and annotations, with a re-run button.
- IssuesRead and write
- Read is how @forseti commands in PR comments reach us. Write lets us acknowledge a command with a reaction instead of a noisy reply.
- MetadataRead
- Required for every GitHub App: repository names and repository events.
Each review job narrows its token further, to one repository and only the permissions that job needs. A review held for your approval runs with a read-only token. When you sign in with GitHub we also receive your verified email address, to create your account.
Data flow
From webhook to review, in memory.
Your code travels from GitHub to Forseti to the model provider and back as a review. It is never written to disk.
The same flow, in words
- 1Verify the signatureGitHub signs every webhook. We check the HMAC-SHA256 of the raw body with a constant-time compare. A bad signature is rejected and nothing is recorded.
- 2Record and queueThe delivery is recorded and the job queued in one database transaction, so a redelivered event never queues twice. Pushes within 30 seconds become one review.
- 3Fetch the diffA GitHub token scoped to this one repository, read-only on code, fetches the changed files. Secrets and credential files are redacted before any model call.
- 4AI model providerA commercial AI model API, named in our sub-processor list. PR text and code are treated as data, never as instructions, and the model’s output must match a fixed schema. The provider’s commercial API terms exclude training on this data.
- 5Verify the findingsA verification pass checks each finding against the code before anything is posted.
- 6Post back to GitHubOne review with inline comments, the summary edited in place, and one check run with the verdict for the head SHA.
Retention
What we keep, and for how long.
We keep what the Review Ledger needs to follow a finding across pushes, and nothing of your repository.
Workspace settings
- storeSnippetson (default) or off
- retentionDays7 to 3,650 (default 90)
Owners and admins change these in Settings. Every change is audit-logged. See sub-processors for who else touches data.
- Your code
- Never cloned or stored as a repository or a diff, and never used to train a model. Patches are fetched live from GitHub each time they are needed. Review jobs hold them in memory only; the dashboard’s diff view keeps at most 50 patches for at most 2 minutes, in memory.
- Findings
- Each finding keeps its file path, line numbers, message and severity, plus the few lines it quotes (secrets redacted) and its suggested fix, so the Review Ledger can follow it across pushes. This is on by default. Switch snippet storage off and only a hash of the anchored lines is kept, with no quoted code or suggestion; the dashboard links to GitHub for the code.
- How long
- Findings, Ask Forseti conversations (an answer can quote a line of code) and release notes are deleted after the retention period you set for your workspace: anything from 7 to 3,650 days, 90 by default.
- Your account
- Name, email, GitHub login, workspace membership, settings, spend records and the audit log, kept while your workspace exists.
Threat model
What could go wrong, and what stops it.
An AI reviewer reads untrusted code for a living. These are the controls in the product today.
Prompt injection
- Review rules and .forseti.yaml are read from the base branch only, so a PR cannot change its own review.
- PR titles, descriptions and code are treated as data, never as instructions; the model’s output must match a fixed schema.
- Commands are accepted only from repository owners, members and collaborators, and only from real comments.
- Forseti can never approve, merge or push.
Over-reaching access
- Read-only on code. Each job mints a GitHub token narrowed to one repository and only the permissions it needs; every token minted is written to the audit log.
- The model is given no tools: it cannot run commands, browse or write anywhere. Our code gathers context through that read-only token.
Forged or replayed webhooks
- Every webhook’s HMAC-SHA256 signature is checked against the raw body in constant time; a bad signature is rejected and nothing is recorded.
- Each delivery ID is recorded once, so a replay never queues a second review.
Secrets in a diff
- Keys, tokens, passwords and credential files (.env and similar) are redacted before any model call, and reported to you as a finding.
One customer seeing another’s data
- Every query is scoped to the workspace from your session membership, never from the request.
- An installation is linked only after your own GitHub token proves you can reach it.
- Members who join through GitHub see only the repositories GitHub shows them; if GitHub cannot confirm, access is refused.
Account takeover
- OAuth tokens are encrypted at rest. Session cookies are httpOnly and SameSite.
- Rate limits on sign-in and magic links; cross-origin requests without a trusted origin are rejected.
- Invites are single-use, expire after 7 days and can be revoked.
Unnoticed changes
- An audit log records workspace, member, settings, policy, cap and repository changes, finding feedback, manual reviews and token minting.
Debug tools left on
- Developer tools fail closed: anything other than an explicit development setup runs with production behaviour, and development endpoints answer only on the local machine.
Sub-processors
Who else touches data.
Apart from GitHub, where your code already lives, only the model provider receives code.
- GitHub, Inc.Your code host: sends webhooks, serves pull-request content, receives the review we postLive
- Anthropic, PBCAI model provider that writes and verifies findingsLive
- StripePayments, credit top-ups and invoicesPlanned
- VercelHosting: the website and dashboard, the API's server functions and the background review workersLive
- NeonPostgres databaseLive
- ResendSign-in links and invitation emailLive
- Amazon BedrockOptional EU route for model inferencePlanned
Full list, with what each receives and where: sub-processors.
Not done yet
What we have not done, plainly.
Forseti is new. We would rather tell you than let you assume.
- SOC 2
- Not yet. We do not hold a SOC 2 report today.
- ISO 27001 or other certifications
- Not yet. We hold none today.
- Zero data retention with the model provider
- Being arranged with our AI model provider before general availability; not yet in place.
- EU-only model inference
- Not yet. An EU route is planned.
- SSO / SAML and SCIM
- Not yet.
- Bring your own key, self-hosting
- Not yet; on the roadmap.
Found a problem? Tell us.
Security questions, questionnaires and vulnerability reports go straight to the team. Read the draft DPA and privacy policy.