A free browser-based linter checks MCP and AI agent configs for risky settings
A developer released an open-source scanner that flags over-powered agent setups, such as exposed root folders and hardcoded keys, without sending your files anywhere.
The short version
- The MCP & AI Agent Security Scanner is free and open source, according to its author.
- It checks JSON, YAML or plain-text prompts and produces a Markdown audit report.
- Rules cover shell access, root folder mounts, hardcoded secrets, database writes, URL fetching and missing human approval.
- Checks are mapped to OWASP LLM06 (Excessive Agency) and LLM01 (Prompt Injection).
- The author claims zero telemetry and zero network requests; we have not verified that.
Why it matters
Agent config files decide what an AI assistant can touch: your files, databases and accounts. Reviewing them like code is becoming a basic habit, and a free checker lowers the effort. Just vet any checker before you give it a real config.
A spell-checker for agent permissions
As dev.to reported, a developer has published a free, open-source tool called the MCP & AI Agent Security Scanner. It is a linter, meaning a checker that reads a configuration file and flags risky settings before you rely on it.
The target is MCP, the Model Context Protocol, a standard way of plugging tools and data into AI assistants. It also covers agent frameworks the author names, such as LangGraph and AutoGen. The author's worry is that developers now connect language models straight to local files, databases and production tools, and that it is easy to hand an agent far too much power.
The scanner reads JSON, YAML or plain-text prompts and gives feedback right away. It then calculates an exposure rating, which the author calls CVSS-AI scoring, and can generate a Markdown audit report in one click.
Six risky patterns it looks for
The post lists rules that carry identifiers starting with ARL-MCP. Each one maps to a plain-language mistake:
- Unrestricted shell access (001): tools that launch a shell such as bash or sh, or run npx with an --allow-all flag, with no container or microVM (a small, isolated virtual machine) around them.
- Broad folder mounts (002): exposing sensitive paths such as /etc/, / or C:\ to a filesystem server.
- Hardcoded secrets (003): plaintext API keys, GitHub tokens or AWS keys sitting in a config's environment block.
- Unconstrained database changes (004): raw SQL tools, or database roles with write access (readOnly: false) and no parameterization.
- Arbitrary URL fetching (005): unrestricted web-fetch tools, which the author says can open routes for data theft through indirect prompt injection.
- Missing human approval (007): high-impact tools marked alwaysAllow, which skip a human confirmation step before they change anything.
Prompt injection means hidden instructions inside content an AI reads, such as a web page, that try to steer what it does. The author maps the checks to two entries in the OWASP LLM Top 10, a widely used list of AI security risks: LLM06, Excessive Agency, and LLM01, Prompt Injection.
Why it runs in your browser
Config files often hold exactly what you would not want to share: server commands, internal paths, database addresses and sometimes credentials. Uploading them to an outside security service is, in the author's words, a non-starter for security-conscious teams.
So the scanner does its work in your browser's memory using static analysis, which means inspecting a file without running anything. The author says this makes it fully air-gapped, with zero telemetry and zero network requests.
That is the author's claim, and we have not tested it. A careful reader can still check it: open your browser's developer tools and watch network activity while you scan the built-in sample. Masking real keys first is a sensible habit with any tool you have not vetted.
The fixes it suggests, and the limits
The post ends with a short remediation checklist. Run MCP servers in short-lived microVMs, with Firecracker or gVisor named as examples, instead of exposing programs on your own machine. Restrict filesystem servers to dedicated workspaces with strict read-only defaults. Inject tokens and API keys at runtime from a secrets manager rather than writing them into mcp.json.
The scanner is also built on pattern matching. The author invites contributions of additional regex rules, which are text patterns that match risky lines, and asks what rules people want next. A rule-based checker can only catch what its rules describe, so a clean report is not proof that a setup is safe.
It also lines up with another story in today's issue: an audit of 10,659 public MCP configs that reported two thirds of the servers were unpinned. Unpinned means following whatever the latest version is rather than a fixed, reviewed one. The linter post flags unpinned npx use as part of the same worry, so checking for it is a good first pass on any config you copied from a blog or repository.
What to watch
- Can independent testers confirm the claim of zero network requests?
- Which rules will the community add beyond the current six?
- Will linters like this become a normal step before agent configs are shared or deployed?
Try it
Open the scanner, load its built-in vulnerable sample, and see what it flags. Then mask any real keys in your own mcp.json and scan that, watching your browser's network tab to confirm nothing is sent.
Sources and links
- Reportingdev.to: the article we sourced
Liked it? Say why
Add a line for other readers.
No account needed. We never show your email. Comments with links, ads or abuse are held and not shown. Your comment shows after a quick check.
Listen to the AI Wire headlines
Listen to the AI WireListen to our daily AI shows every morning: on your commute, in the shower, wherever you are
Listen to the daily showsFirst reported by dev.to · Read the original. Written by the SI Agent News Desk from the reporting above.Written with AI from the source above. Every number is checked against the source. Spot a mistake? Corrections.
