A plausible, well-evidenced, wrong finding is worse than no finding.

A scanner locates candidates and ranks them by pattern confidence. Assay uses scanners and LLM agents for exactly that reach, then adds the step they cannot do: a human confirms every high-severity finding in the primary source before it enters the report. Each finding ships with an evidence tier saying how it was established, and retracted findings stay visible in the report.

Yes — it is one of the two things it is built for. A due-diligence assessment covers security, code quality and long-term supportability, and joins every finding to the commit that first introduced it, so an acquirer can see whether the risk arrived in one bad quarter or accumulated over years. The deliverable is a Word or PDF report a deal team can circulate.

That is what the verification gate is for. Every finding is labelled live-exploited, source-verified or agent-reported, and the report carries a verification attestation showing critical/high coverage and the number of retractions. An auditor can see which claims were confirmed against the source rather than taking a tool's word for it. Findings also export as SARIF 2.1.0 for GitHub code scanning or Microsoft Defender.

It does not have to. The toolkit's own code calls no LLM and is locked to no provider. The deterministic half — measurement, scanner orchestration, readiness scoring, report building and the dashboard — runs entirely locally, and "audit-kit scan --offline" makes provably zero network calls and can be run air-gapped. If you point the agent half at a self-hosted model, nothing leaves the building at all.

Node, Python, .NET and Go are supported out of the box, and any other language through lizard complexity analysis. Anything the toolkit cannot run itself you pass in as data — LCOV coverage, SARIF findings, or npm, pip and dotnet audit JSON — so an unusual stack does not block an assessment.

A branded Word document with a cover page, live table of contents, index and page numbers; the same report as a bookmarked PDF and as self-contained print-ready HTML; findings as SARIF for your code-scanning pipeline; an interactive finding-history dashboard that is a single HTML file with no server, build step or CDN behind it; and a ledger carrying one record per finding, so the next engagement can report what became of each one. The PDF is exported from the same laid-out document rather than re-rendered from markdown, so the hyperlinked contents survive as PDF bookmarks and the index stays clickable.

Not by default, and that is the part most tooling ignores. An assessment runs with the untrusted tree as the working directory of a session holding shell and file-write authority, and part of that tree is consumed by the agent harness rather than read by a model: CLAUDE.md and AGENTS.md reach the system prompt, .claude/settings.json supplies pre-authorised permissions and hook definitions, .mcp.json declares tool servers and the commands that start them. Assay ships a preflight command that enumerates all twelve of those channels before you open the tree — plus anything unmodelled it finds beside them — and fails closed when execution is already pre-authorised, or when a channel could not be read at all. An unreadable channel is refused outright; a pre-authorisation can be accepted deliberately, with a flag or at a terminal, so the decision is always somebody’s. Separately, every prompt in the method binds the auditor to treat everything inside the target as evidence, never instruction.

Yes, and it separates two things most re-audits merge. Status is what somebody wrote down when they closed a finding; whether the fix still holds is a different question and a different command. Assay keeps a ledger with one record per finding, reports what the previous engagement raised and what became of it, and then re-runs every probe that names a closed finding. Results land in three buckets: held, broken, and unproven -- no probe names it, so the evidence is a sentence written on the day of the fix. Unproven is reported as a fact about the evidence, never scored as a pass.

With the supply-chain option, yes, and the two halves are kept apart because only one of them is a measurement. The judged half asks whether each direct dependency is the package anyone meant: a name one edit away from a widely-used package is flagged, and the suggested alternative is confirmed on the registry before the suggestion is made. The measured half compares every hash pinned in your lockfile against the digest the registry records for that exact name and version -- no tarball is downloaded or hashed. It is a slopsquat and takeover defence, not a safety score, and it needs network access, so the offline mode refuses it outright.

It answers three questions about a codebase you did not write: what is wrong with it, how long it has been wrong, and how hard it will be to keep running. Assay covers it through nine specialist lenses — authorisation and isolation, injection and uploads, the LLM surface, backend correctness, frontend, infrastructure and CI/CD, leaked secrets and confidential data, OWASP cryptography, design and integrity, and maintainability — alongside deterministic metrics measured straight from git.

A depth flag scales the scope: --light for a first read, --thorough for a normal engagement, --full for the deepest pass. The lenses run in parallel, so wall-clock time is driven mostly by the human verification gate, which is never skipped at any depth. Reconnaissance on an unfamiliar repository is typically well under an hour.