Security

When you run an audit, nittim fetches a source snapshot from GitHub over HTTPS. The snapshot is held in server memory for the duration of the analysis — it is never written to disk, never stored in our database, and never logged. As soon as the analysis pipeline completes, the snapshot is gone.When you run a check, nittim pulls a copy of your project's code from GitHub over an encrypted connection. That copy is held in server memory only for as long as the check runs — it is never written to a hard drive, never stored in our database, and never logged. The moment the check finishes, that copy is gone.nittim fetches your source from GitHub over HTTPS, holds it in server memory for the run, then discards it. Never written to disk, never stored, never logged.

To keep a single pass focused and fast, each pass is bounded: up to 500 files and 5 MB of content. Binaries, build output, and dependencies are excluded before analysis begins. A full-scan audit can run more than one pass to cover a larger repository beyond that bound; a standard audit (the default for the web app, a zip upload, or the API) stops at one.To keep each pass focused and fast, every pass is capped: up to 500 files and 5 MB of content. Compiled files, build output, and ready-made packages your project depends on are excluded before the check begins. Full Audit can run more than one pass to cover a bigger project past that cap; a standard check (the default for the website, a zip upload, or the API) stops after one.Each pass is bounded to 500 files and 5 MB, excluding binaries, build output, and dependencies. Full Audit can run more than one pass on a larger repo; a standard audit stops at one.

Auditing a private repository requires a GitHub token. That token is forwarded to the GitHub API for the single HTTPS call that downloads the source snapshot. After that call completes, the token is discarded from memory. It is:Checking a private project requires a GitHub token — a temporary key that proves you have access. That token is forwarded to GitHub for the single call that downloads your code. Once that call finishes, the token is thrown away. It is:A private repository needs a GitHub token. It's used once, for the call that downloads your source, then discarded. It is:

• —Not stored anywhere.
• —Not logged in any request or application log.
• —Not passed to Anthropic or any other downstream service.Not passed to Anthropic (our AI provider) or any other outside service.Not passed to Anthropic or any other service.
• —Not retained between requests — each audit that needs a token must supply one.Not kept between requests — every check that needs a token must supply its own.Not retained between requests — each audit supplies its own token.

The audit report — findings, scores, verdict, and the repository name — is stored in Supabase (managed Postgres, us-east-1) so you can retrieve it later via a shareable link or the API. Data is encrypted in transit (TLS 1.2+) and at rest.The report — findings, scores, verdict, and the project name — is stored in Supabase (a managed database service) so you can come back to it later through a shareable link or the API. Your data is encrypted both while it travels (TLS 1.2+) and while it sits stored.Reports — findings, scores, verdict, repo name — are stored in Supabase (us-east-1), retrievable later via a link or the API. Encrypted in transit (TLS 1.2+) and at rest.

Private repository reports are access-gated. Only the account that requested the audit — or a member of that account’s organization — can retrieve the report. Requests from anyone else receive no information, including no confirmation that an audit for that id exists.Reports for private projects are locked down. Only the account that requested the check — or someone else on that account's team — can pull up the report. Anyone else gets nothing back, not even a confirmation that a check with that id exists.Private repository reports are gated: only the requesting account or its org can retrieve them. Anyone else gets nothing back, not even confirmation the id exists.

Service credentials (Supabase service-role key, Anthropic API key, GitHub token) live exclusively in Vercel environment variables. They are never committed to source control and never included in any client bundle. The audit pipeline runs entirely server-side.Our own passwords and keys — the Supabase service-role key, our Anthropic API key, a GitHub token — live only in Vercel's environment variables (a secure settings store, never in the code itself). They're never checked into our source code, and never shipped down to your browser. The whole check runs on our servers, never in your browser.Service credentials live only in Vercel environment variables — never committed to source, never shipped to the client. The pipeline runs entirely server-side.