What Forge reads, stores, and never stores
The deep read fetches your source files to analyze them. What it keeps is a different, much smaller thing — and the difference is the entire trust question, so this page states it without the reassuring vagueness these pages usually have. What individual engineers are protected from has its own page.
What Forge reads
- A connected repository: the file tree, commit history, pull requests and reviews, and — on the deep read — the contents of eligible source files, through a GitHub App grant that is read-only and scoped to the repositories the installer selected. Merge and review webhooks keep the review-tax read current.
- A public scan: public repositories only, tree and metadata, through a shared token. A private repository is refused rather than read. The ownership scan of a repository nobody connected stores nothing at all.
- The CLI: nothing. It walks the git-tracked files on your own machine and sends nothing anywhere — which is also how you can verify the determinism claim yourself.
What a stored reading contains
File contents are fetched, analyzed in memory, and discarded. What a reading keeps is the report: counts over a stated sample, example paths, line numbers, and — for some finding types — a single normalized line as located evidence, length-capped, and withheld entirely whenever the line matches a credential pattern. No file, no function, no diff is ever stored. The repository’s HEAD commit id is kept so an unchanged repository can reuse its own reading instead of being re-fetched.
The cross-repository benchmark is fed by an anonymous row per reading — sizes, per-detector counts, primary language. No organization id, no repository name, no paths. Public front-door scans contribute nothing to it.
Where credentials live
A repository connected through the GitHub App stores no repository credential at all — access tokens are minted per request and expire within the hour. Connections that predate the App hold an OAuth token encrypted at rest (AES-GCM), and reconnecting through the App deletes that token and revokes it at GitHub. Tracker connections (Linear, Jira, GitHub Issues, ClickUp) hold the OAuth tokens the export seam files issues with; disconnecting a tracker removes its token.
What leaves Forge
- Exports you file: the issue carries the finding’s brief — what was measured, example paths, the acceptance criterion — into the tracker you chose. That is the product working as sold.
- Share links you create: a link publishes one pinned reading — repository name, example paths, line numbers, no lines of source (evidence text is stripped server-side before the shared document is built). Links are revocable, every creation and withdrawal is written to the audit trail, and disconnecting a repository withdraws its live links.
- The optional wording layer: the worded synthesis and the proposal sanity-check send the reading’s measured sentences and counts to Anthropic’s API — never source-file contents. No model produces a number anywhere in Forge; without an API key these features simply do not exist.
Disconnecting, and deleting
Disconnecting a repository removes the webhook and the stored credential and withdraws its live share links. Its readings and filed record stay by default — the audit’s value is its memory, and a reconnect picks the history back up — and the disconnect dialog offers deleting them instead, permanently. Rescue purchase receipts are billing records and stay either way.
An account can be deleted from its own settings: the account deactivates immediately, signs out everywhere, and a nightly job purges its data after a 30-day grace window — along with any workspace where it was the only member. Workspaces with other members name a new owner or write to hello@ambera.app for org-wide deletion, which is handled on request as the privacy policy states.