legal
Privacy
Effective: June 2026
What we collect
When you run an audit, nittim records the repository URL, the generated report (findings, scores, verdict), and — when you are signed in — your user ID so you can retrieve the report later. Nothing else.
Source code is fetched from GitHub into server memory for the duration of the analysis. It is never written to disk, never stored in our database, and never retained after the audit completes. The only thing we persist is the report we generated.
GitHub tokens
If you supply a GitHub token to audit a private repository, that token is used once to call the GitHub API for the source snapshot. It is not stored, not logged, and not passed to any third party. It is discarded as soon as the snapshot is downloaded.
What we store
- Audit reportFindings, scores, verdict, repo name — stored in our database.
- Source codeNever stored. Fetched into server memory during analysis, discarded when the pipeline finishes. Two deliberate exceptions: a finding's evidence includes the offending lines it points at, and — where it concluded something was missing — names the places it looked for it; those excerpts and paths live in your report (access-gated for private repos), because a finding without evidence is an opinion; and the uploaded zip below, if you ask us to hold it while an audit runs. A multi-pass or batch audit also parks its own working state on the report row while it runs, and those same lines sit in it. That working state is cleared the moment the run finishes — done, failed, or refunded — and does not linger with the finished report.
- GitHub tokensNever stored.
- Your email / identityOnly if you sign in via GitHub OAuth.
Private repos
Reports generated from a private repository are themselves private. They are only accessible to the account that requested the audit (or members of that account’s organization). Anonymous viewers receive no information about a private report’s existence.
We do not train on your code
nittim does not use your source code or your audit report to train any model. The source code never leaves the analysis pipeline. The report is stored solely to make it retrievable by the person who requested it.
Checking your dependencies
To flag known vulnerabilities, nittim checks the public names and versions of your open-source dependencies — the packages listed in your manifests and lockfiles — against OSV, the industry-standard vulnerability database run by Google. OSV never sees your source code — only the public package names and versions in your dependency files. That’s the same lookup every major dependency scanner performs. (Your source code itself does reach other subprocessors during an audit — see the table below for exactly which ones, and why.)
Analytics and error tracking
nittim uses Vercel Web Analytics to see how many people visit the site and which pages get used. It’s cookieless and aggregate — there’s no per-visitor profile, and nothing that follows you to another site.
When something breaks, Sentry receives the crash report — the error message and which route failed — so we can fix it. It never records your session, and request headers, cookies, and anything that looks like a key or token are stripped before a report is sent (see the Sentry row in the table below).
Neither tool sets a cookie, and neither stores your IP address. The basis for both is nittim’s legitimate interest in keeping the service working and secure. There’s no separate switch to turn them off — if you’d rather not be measured at all, your browser’s own tracking-protection or script-blocking settings will stop it.
Data retention and deletion
Reports remain accessible until you delete them. You can delete any report you own via the API:
DELETE /api/v1/audit/<id>
After deletion, a 30-day grace window begins. At the end of that window, the report is permanently deleted — for good, the next time our cleanup sweep runs. During the grace window the report is invisible to all callers; it is not surfaced in any read path.
We also keep a nightly encrypted backup of the database for disaster recovery. A deleted report’s data can remain inside that backup for up to 120 days after the 30-day window closes — even though it is already gone everywhere we or you can query. Nobody restores a single report out of a backup; backups themselves expire on a fixed schedule and are only ever used to recover the whole system, never one record.
Uploaded source, when you ask us to hold it. An uploaded zip is normally never written to disk — it lives in server memory for one request and is gone when that request ends. One case changes that, and only with your consent: to read past what a single run reaches, you can ask nittim to hold the zip you uploaded while the audit runs. It is stored encrypted at rest in a private bucket that no browser and no public URL can reach; the audit pipeline is the only reader. It is erased as soon as the audit finishes — at most 24 hours from upload — and an hourly sweep removes anything still present. Deleting the report erases it immediately, and so does deleting your account. Each deletion is recorded in nittim's audit log. If you do not consent, nothing is stored and the audit reads what one run can reach.
Subprocessors
nittim does not sell your data. The table below lists every vendor we’ve identified that processes data on our behalf — each one does a specific job for us, on our instructions, under its own privacy terms.
| Processor | Purpose | Data touched | Region |
|---|---|---|---|
| Stripe | Payments — checkout, subscriptions, credit-pack purchases | Billing email, transaction metadata. Card details go straight to Stripe; we never see or store them. | Stripe's global payment infrastructure |
| Supabase | Database and sign-in | Account identity (email, OAuth provider), audit reports, credit balances, and — only with your consent — an uploaded zip held while its audit runs, erased when it finishes. | AWS us-east-1 |
| Anthropic | Audit reasoning — the Claude model that performs your audit | Your repository's source snapshot, sent for the duration of one audit call | Anthropic's API (direct, or via Amazon Bedrock in AWS when that routing is enabled) |
| OpenAI | A second, independently-vendored model used as a cross-check on audit findings (the judge_output tool) | The finding text submitted to that tool for grading — never a score or verdict, and never run against your audit automatically | OpenAI's API |
| OSV.dev | Known-vulnerability lookup for your repository's dependencies — runs on every audit tier (the free scan, the paid audit, the brain path, and MCP module tools), with no opt-out | The package names, ecosystems, and versions found in your repository's dependency manifests | OSV.dev is a public, Google-run service; this integration does not contractually pin a processing region |
| Vercel | Hosting and request routing, plus (behind a default-off flag) ephemeral sandboxed builds that verify a dependency manifest | All traffic in transit; application logs. When the sandbox-build flag is on: a public repository’s source code, for the few minutes needed to run its install/build inside an isolated Vercel Sandbox — never a private repo, no credentials are injected, and nothing but a short package manifest comes back out. | Vercel's global edge network |
| Upstash | Rate-limit counters for the programmatic surfaces (API keys) and anonymous endpoints — guards against a leaked key or scripted abuse draining a prepaid balance | An internal API-key ID, account ID, or IP address, plus a request count per time window — never the API-key secret itself, and never audit content | Set by the Upstash Redis database's configured region — not pinned in application code |
| GitHub | Fetching your repository's source, and GitHub sign-in | Repository source (read-only, never stored — see above), OAuth identity | GitHub's API |
| Sentry | Error reporting, so we notice and fix bugs | Error messages and the route that failed — deliberately never request headers, so an API key or GitHub token in a header can't leak into an error report | Configured only where enabled; not active on every deployment |
| Resend | Transactional email — contact-form confirmations, account notices | Recipient email address, message content | Resend's infrastructure (US) |
| Amazon SES | Inbound mail routing for @nittim.com addresses (e.g. support@nittim.com) | Message content of mail sent to an @nittim.com address | AWS |
Audit reasoning is subject to Anthropic’s privacy policy.
Your rights: getting a copy of your data, or deleting your account
You can ask for a copy of everything we hold on your account, or ask us to delete it, at any time.
Do it yourself — from your account’s Billing page, or by calling the API directly:
- Export your dataClick Download export under “Export my data” in Billing, or call
GET /api/v1/account/exportfor a JSON copy of everything tied to your account: every audit and free scan (the full report, not just the summary), your complete credit ledger, org membership and any invites you sent, contact messages you sent us, finding disputes, share links you created, GitHub App installations, promo redemptions, your billing plan, and your account’s own activity log. Two things it can’t include: API key secrets (only the name and prefix are ever stored in readable form), and per-finding 👍/👎 feedback, which is stored as an anonymous hash of your IP and browser with nothing that links it back to an account. - Delete your accountClick Delete my account in Billing, or call
POST /api/v1/account/delete. Either way it starts a 30-day grace period, during which clicking Cancel deletion in Billing (or callingPOST /api/v1/account/delete/cancel) undoes it. After 30 days, your personal data is purged. Money and anti-abuse records (credit ledger, promo redemptions, an accepted bounty’s award trail) are anonymized and kept — never deleted — for accounting and audit integrity.
Either way, you can always reach us at support@nittim.com — that address is monitored, whether or not the self-serve endpoints above are turned on.
Contact
Questions about your data? Email support@nittim.com, or reach us through the nittim homepage.