Free, open source, read-only
Find what your agent can do on its own, before anyone can stop it.
mc scan reads your agent’s tools and flags every call it can make with no human checking, each one named against a real incident where exactly that went wrong. It runs read-only and offline by default. No signup, no server, no telemetry. The calls no one is checking are the ones you gate first.
One command
Point it at your tools. It does the rest.
Give it a JSON file of your agent’s tool definitions, or a directory to search. It reads OpenAI function and tools schemas, MCP tools/list output, and bare name, description, parameters arrays. Then it classifies every tool by how much harm it can do with no human checking.
Run it
npx @makerchecker/scan <path>
One command, and you see it. The source is open, so you can read every rule it applies before you run it.
Terminal
npx @makerchecker/scan . Scanning tool definitions in /usr/src/app... [CATASTROPHIC] Tool 'transfer_funds' has no preceding approval gate. Resembles: AID-2026-0004 (Morse Code Prompt Injection Grok Wallet Drain) Fix: Add approval_gate control in mc-policy.json [HIGH] Tool 'delete_database' has no preceding gate. Resembles: AID-2025-0008 (Amazon Q VS Code extension database-wiping prompt injection) Fix: Add limit_violation or approval_gate Scan failed. Found 1 CATASTROPHIC and 1 HIGH risk ungoverned capabilities. To fix the build, run: npx @makerchecker/scan init .
Findings and incident references shown are the tool's real output format and real catalogued incidents.
Why it is different
A scanner you can trust, because it never asks you to trust it.
It runs on your machine, it names real incidents instead of generic warnings, and the fix it writes is the same file the self-hosted engine enforces later. Nothing here phones home.
Incident-backed
Every finding names a real disaster, not a generic warning
It cross-references the Agent Incident Database: 41 real, sourced, reproduced agent failures. A finding does not say "this looks risky." It says which incident your setup resembles, from database wipes to money movement to runaway billing loops.
Local only
Read-only, and nothing leaves your machine
It reads your tool definitions and exits. No signup, no account, no server, no telemetry. The default scan is deterministic and offline. The one exception is opt-in: pass --llm and the ambiguous tools are sent to the Anthropic API for a second opinion, and every such finding is labeled so you know which is which.
Policy as code
The fix is one file, and the engine enforces the same one
Run scan init and it writes a deny-by-default mc-policy.json where every dangerous tool starts gated. The scan reads that file and shows those tools as governed. The self-hosted MakerChecker engine enforces the exact same file in production. One file is both your scan config and your live policy.
Every finding points at the incident it resembles. Read the catalogue those references come from: the Agent Incident Database →
In your pipeline
Fail the build the moment your agent gains an ungoverned catastrophic capability.
Add the GitHub Action, or run the one-liner. It exits non-zero on an ungoverned catastrophic tool, so a pull request that gives the agent a new way to do irreversible harm cannot merge quietly. The job also writes a results card to the run summary.
There is an opt-in status badge too. It is a plain GitHub Actions workflow badge that goes green only when your own scan job passes. No MakerChecker server is involved, and nothing phones home.
.github/workflows/mc-scan.yml
- uses: makerchecker/scan@v0
with:
path: .
fail-on: CATASTROPHICOr one line, no action
- run: npx --yes @makerchecker/scan . --fail-on CATASTROPHIC
To turn a red build green, run npx @makerchecker/scan init . to write a deny-by-default policy, then gate what you meant to gate.
Honest scope
What it does not catch, said plainly.
mc scan reads tool definitions, not your live runtime policy. It does not find prompt injection in your data, and it does not find logic bugs in your code. It finds what your agent is capable of doing on its own, with no one checking. That is a narrow claim on purpose, and it is the claim most teams have never actually tested.
Finding the ungoverned action is the scan’s whole job. Stopping it in production is a different job. That one belongs to the engine, which refuses the action in code and records a signed log your own auditor can verify offline.
From scan to enforcement
The scan finds the ungoverned action. The engine stops it.
The free scan and the self-hosted engine read the same policy file. The scan tells you which actions your agent can take with no one checking. The engine then makes the agent that proposes an irreversible action unable to approve it, a hard refusal in code, and writes every step to a signed log your own auditor verifies offline. When you are ready to enforce it in production, we build and run the first governed agent with you in a paid pilot.
Keep reading
See it for yourself
See an agent get stopped.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.