Data & Trust

The free deterministic scan never sends your code to any AI at all — the secret scanner and dependency check run inside nittim's own server process, and the only external call is to GitHub to fetch the snapshot.The free rule-based scan never sends your code to any AI at all — the check for passwords or keys, and the check for known security bugs in your packages, both run inside nittim's own server process, and the only outside call is to GitHub to pull your code.The free scan never touches AI — checks run on nittim's own servers; the only outside call fetches code from GitHub.

An AI audit sends a prioritized digest of the code to the Anthropic API for the audit. That is an API relationship under commercial terms that do not use API inputs or outputs to train models — nittim has no data-sharing or training arrangement of any kind, and nittim itself retains nothing from the digest after the audit returns. See An AI check sends a prioritized summary of the code to Anthropic's API to do the check. That's a paid API relationship under commercial terms that don't use what's sent to train any model — nittim has no data-sharing or training arrangement of any kind with Anthropic, and nittim itself keeps nothing from that summary once the check returns. See An AI audit sends a prioritized code digest to Anthropic's API. Commercial terms bar training on it — nittim has no data-sharing deal and keeps nothing after. See Anthropic's commercial terms for their side of that boundary.

Anthropic deletes API inputs and outputs from its systems within 30 days of receipt unless a zero-data-retention agreement is in place. nittim doesn't have one at this stage — so that 30-day window is the vendor's side of the boundary, and the rung above is still the one that asks you to take our word. Anthropic deletes what was sent to it and what it sent back within 30 days of receiving it, unless a special zero-retention agreement is in place. nittim doesn't have one of those at this stage — so that 30-day window is Anthropic's own side of the boundary, and the rung above this section is still the one that asks you to take our word for something. Anthropic deletes API inputs and outputs within 30 days, unless a zero-data-retention deal exists — nittim doesn't have one, so that window is the vendor's own guarantee, not ours. See Anthropic's data-retention policy.

nittim can never modify your code. The nittim-audit GitHub App holds read-only permissions and nothing writable, and subscribes to no events. One of them sounds heavier than it is: administration: read-only lets nittim read your branch-protection settings — which reviews and checks a merge actually requires — and can never change one. GitHub shows you the exact permission list before you approve it and enforces it regardless of what nittim's code does; that screen, not this page, is the live list, and you can confirm it any time at github.com/settings/installations. If you use a pasted token instead, create it fine-grained, read-only, scoped to the one repository you're auditing, and revoke it right after — nittim works identically either way.nittim can never change your code. The nittim-audit GitHub App only ever asks for read permissions — it can look, never write — and doesn't listen for any events. One of them sounds scarier than it is: administration: read-only lets nittim see your repository's settings — like what your main branch asks for before anything can be merged. It can look at a setting. It can't change one. GitHub shows you the exact list before you approve it and enforces it no matter what nittim's own code does; that list is the real one, and you can check it yourself any time at github.com/settings/installations. If you paste in a token instead, make it fine-grained — read-only, limited to just the one project you're checking — and revoke it right after; nittim works the same either way.nittim can never modify your code. The nittim-audit GitHub App holds read-only permissions only, no events. Administration: read-only reads settings, never changes them — it is how nittim sees what your default branch requires before a merge. GitHub enforces it regardless of nittim's code; the exact list is at github.com/settings/installations. Using a token instead? Make it fine-grained, read-only, scoped to one repo, and revoke it after.

Reports are kept until you choose to delete them. There is no automatic expiry for live reports.Reports are kept until you choose to delete them. There's no automatic expiry for live reports.Reports are kept until you choose to delete them. There is no automatic expiry for live reports.

When a report is deleted, it immediately disappears from all read paths — the report link returns not-found and the API returns 404. The underlying row is then permanently removed from the live database on the next hourly retention pass. Rows deleted more than 30 days prior are purged on that pass; a row deleted today will be purged on or after the corresponding date 30 days out.When a report is deleted, it disappears from every read path right away — the report link says not-found, and the API returns a 404 error. The row behind it is then permanently removed from the live database on the next hourly cleanup pass. Rows deleted more than 30 days earlier get purged on that pass; a row deleted today gets purged on or after the matching date 30 days out.When a report is deleted, it immediately disappears from all read paths — the report link returns not-found and the API returns 404. The underlying row is then permanently removed from the live database on the next hourly retention pass. Rows deleted more than 30 days prior are purged on that pass; a row deleted today will be purged on or after the corresponding date 30 days out.

That 30-day window governs the live database — everything a report link, the API, or nittim itself can query. A separate, nightly encrypted backup of the whole database also exists, for disaster recovery only, and a deleted report's data can remain inside that backup for up to 120 more days after the 30-day window closes. Backups are never queried for an individual record — they expire on a fixed schedule and are only ever restored to recover the entire system, never one report.That 30-day window governs the live database — everything a report link, the API, or nittim itself can look up. A separate, nightly encrypted backup of the whole database also exists, for disaster recovery only, and a deleted report's data can remain inside that backup for up to 120 more days after the 30-day window closes. Backups are never looked up for one individual record — they expire on a fixed schedule and are only ever restored to bring back the entire system, never a single report.That 30-day window governs the live database — everything a report link, the API, or nittim itself can query. A separate, nightly encrypted backup of the whole database also exists, for disaster recovery only, and a deleted report's data can remain inside that backup for up to 120 more days after the 30-day window closes. Backups are never queried for an individual record — they expire on a fixed schedule and are only ever restored to recover the entire system, never one report.

You own every report you generate. To delete one:

DELETE /api/v1/audit/<id>
Authorization: Bearer <your-api-key>

Every finding on a report can be disputed — from the report page, or by your own agent over MCP with the evidence it can see in your code. A human reviews every dispute. When one is accepted, two things happen: the finding is corrected on the record, and the account that proved it wrong is paid in credits — more when the dispute exposes a flaw in our pipeline rather than one wrong finding. We pay people to prove us wrong because a verified mistake is worth more to this product than the credits are.Every finding on a report can be challenged — from the report page, or by your own AI assistant, using the evidence it can see in your code. A person reviews every challenge. When one is accepted, two things happen: the finding is corrected on the record, and the account that proved it wrong gets credits — and more of them if the challenge uncovered a flaw in how our checks work rather than a single wrong finding. We pay people to prove us wrong because a confirmed mistake teaches us more than the credits cost.Dispute any finding — on the report page, or via your agent over MCP with evidence from your code. A person reviews every dispute. An accepted one gets corrected on the record, and you're paid in credits — more for a pipeline flaw than a wrong finding. We pay to be proven wrong because it's worth more than the credits.

Public reports and scans — audits of public repositories — are accessible to anyone with the link. This is intentional: the link is the share mechanism. If you want one to stop being accessible, delete it.Public reports and scans — checks of public projects — can be opened by anyone who has the link. That's on purpose: the link is how it's shared. If you want one to stop being reachable, delete it.Public reports and scans are open to anyone with the link — that's the whole point. Delete one to stop it being reachable.

A report or scan of private or posted (uploaded) source is gated to its owner or an organization member by default. That link returns 404 for everyone else — unless the owner or an organization admin explicitly creates a share link for that one item (the Share button always says so first, and names what it hands over). Only the owner or an organization admin — never an ordinary member — can create, see, or turn off that link; an ordinary member can see that one exists but is never handed the link itself. A share link uses its own separate token, not the report's or scan's id, so it never widens what any other page — the public verified wall, the embeddable badge — can show about it. It works for anyone who has it, no account required, and stays live until it's turned off, at which point it stops working immediately, for everyone who has it.A report or scan of private or uploaded code is locked to its owner or a team member by default. That link returns 404 (not found) for everyone else — unless the owner or a team admin deliberately creates a share link for that one item (the Share button always says so first, and names exactly what it hands over). Only the owner or a team admin — never an ordinary member — can create, see, or turn off that link; an ordinary member can see that one exists but never gets handed the link itself. A share link uses its own separate password-like id, not the report's own id, so it can never widen what any other page — the public verified wall, the embeddable badge — can show about it. It works for anyone who has it, no account needed, and stays live until it's turned off, at which point it stops working immediately, for everyone who has it.Private or posted source is locked to its owner or org member by default — everyone else gets 404. Only the owner or an org admin can create, see, or turn off a share link (the Share button always says what it hands over); an ordinary member can see one exists but never gets the link. A share link uses its token, never the report's id, so it can't widen what any other page shows. It works for anyone who has it, no account needed, until it's turned off — then it stops working immediately, for everyone.

When you run an audit inside an organization, all members of that organization can read the report. An organization owner or admin can also delete it. Reports are scoped to a single organization — members of a different organization cannot access them.When you run a check inside a team account, every member of that team can read the report. A team owner or admin can also delete it. Reports belong to a single team — members of a different team can't get to them.Everyone in an organization can read a report run inside it; an owner or admin can delete it. Reports stay scoped to their own organization.

Reports are stored in Supabase (managed Postgres, us-east-1). All data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Access to the database is via a service-role key held in Vercel environment variables — it is never exposed client-side and never committed to source control.Reports are stored in Supabase (a managed database service). All data is encrypted while it travels (TLS 1.2+) and while it's stored (AES-256). Access to the database goes through a service-role key held in Vercel's environment variables (a secure settings store) — it's never sent to your browser and never checked into our source code.Reports live in Supabase (Postgres, us-east-1), encrypted in transit (TLS 1.2+) and at rest (AES-256). A Vercel-held service-role key reaches the database — never sent to your browser, never committed to source.

Over MCP, nittim pulls nothing: only the files your assistant posts arrive, and the server cannot ask for more. Where they land is the same server and the same 6 places as every other path — MCP changes the doorway, not the map.Over MCP (the connector your AI assistant uses to reach tools), nittim asks for nothing extra: only the files your assistant sends arrive, and the server can't ask for more. They land in the same 6 places as every other path — MCP only changes the way in, not where things end up.Over MCP, nittim pulls nothing: only the files your assistant posts arrive, and the server cannot ask for more. Where they land is the same server and the same 6 places as every other path — MCP changes the doorway, not the map.

This list narrows where a copy could be. It cannot prove our code never writes to one of these places — only an independent review of the code path, or running both halves inside your own cloud, can close that. We'd rather say so than let the table imply more than it shows.This list narrows down where a copy could be. It can't prove our code never writes to one of these places — only an independent review of the code itself, or running both halves inside your own cloud, can close that gap. We'd rather say so plainly than let this list imply more certainty than it actually has.This list narrows where a copy could be. It cannot prove our code never writes to one of these places — only an independent review of the code path, or running both halves inside your own cloud, can close that. We'd rather say so than let the table imply more than it shows.

Only the AI tiers send anything to a model. This is what that send contains.Only the AI checks send anything to a model at all. This is exactly what goes.Only the AI tiers send to a model. This is what goes.

• Source files in the languages we read — the repository's own code.
• Dependency manifests and lockfiles — package.json, requirements.txt, go.mod, Cargo.lock and their peers.
• Configuration and infrastructure — Dockerfiles, CI workflows, Terraform, .env files and their examples.
• Documentation the repository ships — Markdown and plain text.
• Executable scripts with no extension, admitted by their shebang line.

Audit · File count500

files fetched from the repository, at most.

Full Audit · File count2000

files fetched in ONE window — and a Full Audit fetches window after window until every eligible file has been read, so this is not a total.

Audit · Per-file size200 KB

per file — a bigger file is skipped, never partially guessed at.

Full Audit · Per-file size4 MB

per file on this tier — the lockfile cap, applied to every file. A big source file an Audit skips is fetched whole here.

Both · Lockfile size4 MB

for a lockfile, which is long by nature and is where the dependency truth lives.

Audit · Total size5 MB

of source in total, across everything fetched.

Full Audit · Total size20 MB

of source per window, not in total — see the sentence under this list for what a Full Audit adds up to.

Audit · Per-file characters16K characters

of any single file reach the model; past that the file is cut and marked as cut.

Full Audit · Per-file characters200K characters

of any single file reach the model on this tier; past that the file is cut and marked as cut.

A Full Audit is sold on reading every eligible file, so the numbers per window above are not a total: it fetches one window, then the next, until every eligible file in the repository has been read. What travels over a whole Full Audit is your repository's own eligible source — the file kinds listed above, at the per-file caps above — and nothing else.A Full Audit is sold as reading everything, so the per-window numbers above are not a total: it reads one window, then the next, until it has been through every eligible file in your repository. Over a whole Full Audit, what travels is your repository's own eligible source — the kinds of file listed above, at the per-file limits above — and nothing else.A Full Audit is sold on reading every eligible file, so the numbers per window above are not a total: it fetches one window, then the next, until every eligible file in the repository has been read. What travels over a whole Full Audit is your repository's own eligible source — the file kinds listed above, at the per-file caps above — and nothing else.

Nothing is stripped. Comments, strings and secrets-looking text travel exactly as they are written in the file — the only changes are the cut at the per-file cap above, and the file markers around each body being escaped so a file cannot forge one. Images, fonts, binaries, vendored dependencies and generated bundles never travel at all.Nothing is stripped out on the way. Comments, text inside your code, and anything that looks like a password travel exactly as written — the only changes are the cut at the per-file limit above, and escaping the markers around each file so one file can't pretend to be another. Images, fonts, program binaries, third-party packages checked into your project and generated bundles never travel at all.Nothing is stripped. Comments, strings and secrets-looking text travel exactly as they are written in the file — the only changes are the cut at the per-file cap above, and the file markers around each body being escaped so a file cannot forge one. Images, fonts, binaries, vendored dependencies and generated bundles never travel at all.

A report is one row. These are its columns, and what each kind of column is about.Your report is stored as a single row in our database. These are all of its columns, grouped by what each one is about.A report is one row. Every column, by what it holds.

3 columns can hold text from your repository: the report itself, because every finding carries the lines it points at, and the two working-state columns a multi-pass or batch audit writes as it goes and clears the moment it finishes. Every other column is an id, a verdict, or machinery.3 columns can hold text from your project: the report itself, because every problem it reports comes with the lines it points at, and the two columns an AI audit uses for its own working notes — written as it goes, and cleared the moment it finishes. Every other column is an id, a verdict, or machinery.3 columns can hold text from your repository: the report itself, because every finding carries the lines it points at, and the two working-state columns a multi-pass or batch audit writes as it goes and clears the moment it finishes. Every other column is an id, a verdict, or machinery.