Audit local AI agents with Geiger
Run a read-only local AI agent inventory, verify evidence paths and capability labels, then test runtime boundaries before trusting agents.

Inventory the agents before you trust them
Your laptop may be running more agent helpers than you remember, and each one can reach files, network, or secrets in a different way. Before you paste a prompt into one, you need a list of what it can touch.
The scale is hard to ignore: an open-source agent harness collected over 200,000 GitHub stars during three weeks in August 2026, while the plugin ecosystem passed 13,000 repositories in that same window.
Geiger runs as a read-only command. It lists local AI agents, plus harnesses, MCP servers, plugins, and AI extensions on the machine, then says what each can touch.
Use it without installation, account, or telemetry, and write nothing unless you explicitly name a JSON output file.
Confirm the scan reaches Claude Code's global and per-project MCP servers, plus its hooks, plugins, skills, subagents, and apiKeyHelper, and the MCP hosts: Claude Desktop, Cursor, Windsurf, plus VS Code, Cline, Roo Code, plus Continue and Zed.
If the output is too long, split it by host. Keep one column for the item, one for where it came from, and one for what it can do.
Save the raw output somewhere you can diff later. A before-and-after record is how you notice a new helper after a routine update.
Make the inventory repeatable. Save the command, the date, and the machine name in a note, so the next person can reproduce the same view. That baseline is what you return to. If you cannot rerun the same scan, you cannot compare a normal week with a changed week.
Done looks like a list of named capabilities you can read in one pass.
Verify the evidence path behind every label
Each finding carries its origin, capability labels such as EXECUTES and HOLDS-SECRETS, plus BROAD-FILESYSTEM, BROAD-WEB, and NETWORK, and an evidence path you can open.
Open the evidence path and confirm the setting, script, or server entry actually exists.
Compare the capability label with the real scope: a NETWORK label means outbound calls, BROAD-FILESYSTEM means wide file access, and HOLDS-SECRETS means credentials may be reachable.
Flag entries whose origin is unknown as untrusted until you can trace them.
The origin field is dull but useful: it says whether the item came from a registry, store, git source, local script, remote server, or unknown place.
The mistake happens when a clean inventory is read as a clean bill of health. Treat Geiger as an inventory with honest exposure labels, not a security audit.
Turn the label into a decision. Open the script when a path points to a shell script, and note the endpoint and transport when it points to a remote server.
You are done when you have a short table: item, origin, label, path, and your verdict.
Test the runtime boundaries the inventory cannot prove
Run the agent in a sandbox or disposable directory with sample files, then watch what it reads, writes, and sends.
Ask the agent to summarize a file, then check whether it touched anything outside the allowed folder.
Request a call to a fake endpoint, then confirm whether network traffic is blocked or logged.
Give it a secret-looking string and see whether it stores, echoes, or sends it.
Do not let a static signal replace a behavior test; AI-SLOP-Detector measures static code and documentation signals, but it does not prove runtime correctness.
Record the test in plain language: what you asked, what it touched, and whether the boundary held. A short note is enough if it lets you repeat the test later.
Watch for side effects that do not look like failures: a new temp file, a changed setting, a request to a domain you did not expect.
Repeat the test after every update that changes a plugin, hook, or server, and keep the note next to the inventory before you grant more access.