On October 28, 2026, an account posted a free scanner called Zero Breach Toolkit that "detects over 12,100 traces" of spyware on Windows, Linux, macOS, Android and iPhone, and said it "never writes to disk, never connects to the internet, or ask for admin perms." The post passed half a million views in a day.
Those are exactly the claims worth checking before you hand a stranger's script access to your browser history and your phone's backups. We cloned the repository (v0.1.7, dated the same day) and read the README, PRIVACY.md, the methodology and coverage docs, and the network guard. We did not run it against a compromised device, and we did not benchmark its detection.
This post covers what it checks, where the announcement and the documentation differ, and how to vet any script like it. Spyware is sold by vendors in many countries and the tool matches indicators, not nationalities, so that is how we treat it here.
TL;DR: questions and answers
| Question | Answer |
|---|---|
| What does it detect? | Published indicators of known mercenary and commercial spyware, plus stalkerware lists, from Amnesty, the MVT project, Echap and Citizen Lab-style research |
| Is the "12,100 traces" figure verifiable? | Not by us. The repo bundles about 658 indicator lines; the rest depend on feeds you download at update time |
| Does it never write to disk? | No. PRIVACY.md says it writes temporary database snapshots and any report you request |
| Does it never touch the network? | A scan blocks Python sockets. Updating indicators and Android collection do use the network, by design |
| Does it need admin rights? | Not on Windows. On macOS you grant Terminal Full Disk Access so Safari data is readable |
| Does a clean scan mean I'm safe? | No, and the README says so |
| Should I run it? | If you have a real reason to check, yes, after verifying the release. If you think you are being targeted, contact a helpline first |
What it actually checks
The README describes it as "a free, open-source check for traces of known mercenary spyware (Pegasus, Predator, Graphite, Candiru and others) on computers, Android phones and iPhone backups." The method is string and fingerprint matching against published research:
- Computers: browser history, cookies, HSTS records and caches across Chrome, Edge, Brave, Firefox and others; downloaded-file origins; the Windows Win+R box and PowerShell log; DNS cache and hosts file; startup and persistence entries; and exact-hash fingerprints of candidate files up to 120 MiB.
- Android: a guided collection with the pinned AndroidQF tool, then checks of apps, settings, logs and SMS.
- iPhone: an encrypted local backup, which you point the tool at.
Each match carries an evidence grade, from "on-disk" (a file has the fingerprint of a published sample) down to "referenced" (the address appears in saved content, which the methodology notes "is usually not contact"). That grading is the most useful design choice in the project: the same indicator means very different things on disk and in a saved news article.
Claimed vs verified
| Claim in the announcement | What the repository says | Status |
|---|---|---|
| Detects over 12,100 traces | Bundled files hold roughly 600 ad-network indicators and 58 curated mercenary-spyware ones; the update step downloads more from named feeds | Not verified; count depends on feeds |
| Never writes to disk | "It writes only temporary database snapshots and the reports you ask for"; interrupted runs can leave snapshot copies in the temp directory | Differs |
| Never connects to the internet | "No network requests during a scan"; --update downloads from raw.githubusercontent.com; Android collection downloads AndroidQF; the optional ad-block test opens a web page in your browser | True for the scan, not for the whole workflow |
| Asks for no admin permissions | No admin needed on Windows; macOS needs Full Disk Access for Terminal; Android needs USB debugging | Mostly true |
| Takes 10-15 minutes | README says about 15 minutes for the standard check | Consistent |
| Open source | Apache-2.0 licensed; source and build scripts in the repo | True |
None of the differences look like concealment. The README and PRIVACY.md state them openly, and the project is more careful than the tweet. The practical lesson is to trust the documentation over the headline.
What the network guard does, and doesn't
The design rule is that a scan must never contact an indicator, because resolving a spyware operator's domain could signal a possible victim. netguard.py enforces this by making name-resolution and connection functions in Python's socket module raise an error during a scan, so a bug would crash loudly rather than leak.
The project is careful about the limit: "This is not an operating-system network sandbox." It does not block subprocesses, and PRIVACY.md recommends operating-system network isolation if you need strict offline execution. If that matters to you, disconnect the machine after running the update step and before scanning.
The update step is one explicit network operation. It fetches from a fixed allow-list of owners and, by default, pins each feed to a commit and requires a recorded SHA-256. It also refuses an update that would cut a source's indicator count by more than half. The docs add that the sources "are not signed by their publishers", so the hash pinning detects change, not authenticity.
How to vet a script like this
The same checks apply to any security tool you run with access to your home directory. This is the habit that also protects you from fake installers and malicious agent skills.
- Use a tagged release, not the main-branch ZIP. The README's easiest path is "Download ZIP" from the main branch. The releases page carries signatures; main is whatever was pushed last.
- Verify the signature.
docs/VERIFYING.mdpublishes an Ed25519 key fingerprint (C24E C92B 12D6 670A 2516 065F 9B4D 5754 99AF A53C) and tells you to compare it with a second record you already trust before importing the key. Then verifySHA256SUMS.txtand the files. - Rebuild the single file. The project says its single-file scanner is generated deterministically, so you can run
git checkout v0.1.7,python build/bundle.py, hashdist/zero-breach-toolkit.pyand compare. - Read the risky paths. Search the code for
subprocess,socket,urllib,open(..., "w")and anything that writes outside the report folder. For this project that is a short list:netguard.py,feeds.pyand the Android collector. - Use a throwaway Python environment and keep reports out of cloud-synced folders.
PRIVACY.mdwarns that a report can contain your username, browsing details and SMS excerpts, and that OneDrive or iCloud would upload it.
git clone https://github.com/interplains/Zero-Breach-Toolkit
cd Zero-Breach-Toolkit
git checkout v0.1.7
grep -rnE "subprocess|urllib|requests|socket" scan/zbtriage | head -40
python build/bundle.py && shasum -a 256 dist/zero-breach-toolkit.py
Limits worth knowing
- Known indicators only. A clean result means nothing in published lists matched, in places the tool could read. The README says "a clean result is never presented as proof that you are safe", and every report lists checks that could not run.
- A match means look closer. The docs say it "means look closer, not you are infected", and advise you not to delete anything or visit the address it names.
- Computers are not phones. The coverage notes say computer checks "cannot tell whether a phone is infected"; phones need the collection or backup flow.
- It is brand new. v0.1.7 shipped the day it went viral, with a changelog of Windows Android collection fixes and Pixel false-positive fixes. Expect rough edges and false matches.
- Detection rates are unmeasured.
docs/COVERAGE.mdstates it "is not a measure of real-world detection or false-positive rates." We have no independent numbers either.
If you think you are being targeted now, the README itself says to get expert help first. Journalists, activists and human-rights defenders can contact the Access Now Digital Security Helpline or Amnesty International's Security Lab before running anything.
Why this matters if you run AI coding agents
A developer's laptop holds browser sessions, cloud credentials and agent configuration, which is why infostealers now go after them directly (see Aokigahara) and why fake installers target the same people (InstallFix). A tool that reads browser databases and shell history needs the same scrutiny as a skill an agent installs: who published it, what it can read, what it can send, and whether you can rebuild it. The sequence above is the one we use for agent skills too, covered in NVIDIA's SkillSpector write-up and Cloudflare's security-audit skill.
How Beam handles this
Beam does a smaller, different job. It watches what your coding agents do on your machine and scans skills and MCP configs before you run them, with everything staying local. Its scan is heuristic: 11 patterns plus an MCP version-pin check, not a spyware forensics engine. It will not tell you whether your phone has Pegasus; a tool like Zero Breach Toolkit or MVT is built for that. Beam's part is narrower: seeing which files and secrets an agent touches, and flagging risky actions such as credential exposure. See Beam security skills and subagents and the October 2026 supply chain incidents tracker.
Related reading
- Aokigahara: an infostealer that targets Claude Code, Codex and Cursor credentials
- InstallFix: fake Claude Code installers aimed at developers
- NVIDIA SkillSpector: an open-source agent skill scanner
- Cloudflare's security-audit skill: run it on your coding agent safely
- Beam security skills and subagents
- October 2026 software supply chain incidents
- Sources: Zero Breach Toolkit repository, its PRIVACY.md and VERIFYING.md, Access Now Helpline, Amnesty Security Lab
Details are accurate as of October 28, 2026, based on the repository at v0.1.7 and the announcement thread. We read the code and docs but did not run the tool against an infected device or verify the 12,100 figure. The project is new and changes quickly; check the repository for current behavior.