Your AI coding agent runs with your permissions. All of them.
If it can read a file, it reads with your account. If it can run a shell command, that command can touch everything you can touch. Most of us set up these tools in five minutes, click "allow" a few times to make the prompts stop, and never look at the resulting config again.
This week we audited our own.
The idea came from a 246,000-star repo
We spent an evening reviewing ECC, the viral agent-harness kit. Our verdict on installing it was no — for our setup, ~90 scripts executing on every tool call is more supply-chain surface than we'll accept, and its flagship learning system is a documented no-op on native Windows, which is what we run.
But buried in it was one idea worth more than the whole repo: your agent tooling is part of your threat model. The settings files, the hooks, the MCP server definitions, the permission allowlists — that's an attack surface, and almost nobody audits it.
We ship a security scanner for a living. We had audited our web apps relentlessly. We had never audited our own agent configs.
What we found in our own house
Five parallel audit passes over every harness config on our build machine. Findings, in descending order of embarrassment:
-
One repo's local settings contained
"Bash(*)"— a blanket shell allow. Any prompt injection reaching a session in that project could run arbitrary commands with zero approval prompt. It had been sitting there since some long-forgotten session where someone (fine: we) allowed it to make a prompt go away. -
Another repo's settings allowed unprompted
Readof the entire user profile — SSH keys, token caches, browser profiles, password-manager stores. Plus apython -callow, which is arbitrary code execution wearing a lab coat. - OAuth token caches were readable and writable by every local account on the machine — inherited NTFS permissions nobody had ever looked at.
- A global allow rule contradicted our own database doctrine — granted once in some session, applying forever, in every project.
The one that made us laugh: when our agent tried to fix the global permission file, the permission classifier blocked the agent from editing its own permissions. Correct behavior. The guard guarded the guardian, and the fix went through a human paste instead.
Everything above is closed now. Total time from "let's audit" to "all HIGHs fixed": about two hours. The Bash(*) had been live for weeks.
We turned the checklist into a free tool
The rule set from that audit is now a scanner you can run in your browser: redcapra.com/agent-scan.
Paste your settings.json, .mcp.json, or hooks config and it grades what it finds:
- blanket and
sudoshell wildcards, arbitrary-exec allows (python -c,sh -c,eval…), destructive-command allows - profile-wide
Readgrants and root-leveladditionalDirectories - missing
.envread-deny nets - unpinned auto-installing MCP servers (
npx -y something@latestexecutes whatever the registry serves next) - credentials sitting inline in MCP/env config
- hook commands that interpolate tool input into shell strings, post to external hosts, or pipe downloads into
sh
It's a few hundred lines of plain JavaScript running entirely in the page. Nothing you paste is uploaded, logged, or stored — credential-shaped values are masked before they even appear in the findings text. No account, no email gate.
Three things to check tonight, no tool required
-
Grep your settings files for
Bash(*)— and for interpreter allows likepython -corsh -c, which are the same thing in disguise. -
Look at every
npx -yin your MCP config. Pin versions.@latestmeans "whatever ships next runs on my machine automatically." -
Read your hooks like an attacker. Anything interpolating
${...}tool input into a shell string is command injection waiting for a crafted filename. Anything posting to a non-localhost URL is an exfiltration channel — transcripts contain secrets more often than you think.
Your agent is probably fine. Its config might not be. Ours wasn't — and we do this for a living.
RedCapra is a local-first security workbench: a real 47-check scan on your site, free, findings tracked in your browser. If the agent scanner is useful, the workbench is the same philosophy pointed at your web app.
Top comments (0)