Local-First Security: Why Your Scanner Shouldn't Phone Home

Here's an uncomfortable question: when you run a security scanner on your MCP configuration, where does that configuration go?

If the answer is "to someone else's server," you have a problem. Your MCP configurations contain database connection strings, API keys, internal service URLs, authentication tokens, and architectural details about your infrastructure. Uploading them to a cloud service for analysis means handing your attack surface to a third party.

That's not security. That's a different kind of exposure.

The Cloud Scanner Paradox

Most security scanning services follow a familiar model: upload your data, we'll analyse it, we'll send you a report. For source code analysis, dependency scanning, and vulnerability assessment, this model has become normalised. Developers routinely upload their codebases to cloud services without thinking twice.

MCP configurations are different. They're not source code — they're operational infrastructure definitions. They describe what your AI agents can access, how they authenticate, and where your sensitive systems live. A leaked MCP configuration is a roadmap for an attacker.

When a cloud-based scanner analyses your MCP config, several things happen that should concern you:

Your credentials transit the internet. Even with TLS, your API keys and connection strings are now on someone else's server.
Your infrastructure topology is exposed. Internal hostnames, port numbers, service architectures — all visible to the scanning provider.
Your data is subject to their security posture. If the scanning provider is breached, your configurations are part of the breach.
Your data is subject to their jurisdiction. Depending on where the scanner operates, your data may be accessible to foreign governments or legal processes you can't control.

Compliance Implications

For organisations subject to GDPR, the Data Protection Act 2018, or sector-specific regulations, uploading MCP configurations to cloud scanners raises serious compliance questions.

Data residency: If your MCP configs contain references to EU personal data systems, uploading them to a US-based scanner may constitute a data transfer that requires appropriate safeguards under GDPR Chapter V.

Data minimisation: GDPR's data minimisation principle requires that personal data processing is adequate, relevant, and limited to what is necessary. Uploading your entire MCP infrastructure to a third party for analysis is difficult to justify as "limited to what is necessary" when local alternatives exist.

Processor obligations: If the cloud scanner processes data that includes personal data references (and MCP configs connected to CRM, HR, or customer databases almost certainly do), the scanner becomes a data processor with all the contractual and compliance obligations that entails.

None of these issues arise when scanning happens locally.

The Local-First Approach

MCPScan was designed from the ground up as a local-first tool. The entire scanning engine runs on your machine. No data is uploaded, transmitted, or shared with any external service. No API keys required. No accounts to create. No telemetry.

This isn't just a privacy feature — it's a security architecture decision. A scanner that requires your sensitive configurations to leave your environment is, fundamentally, introducing a new attack surface in the name of reducing attack surfaces. The irony isn't subtle.

Local-first scanning also means:

Air-gapped environments: MCPScan works in environments with no internet connectivity — ideal for sensitive government and financial deployments.
No vendor lock-in: Your scan results are yours. No subscription, no data hostage, no "upgrade to see full results."
Deterministic results: Same input, same output, every time. No cloud-side model updates silently changing your risk assessment.
Speed: No upload/download latency. Scanning a configuration takes seconds, not minutes.

Choosing the Right Scanner

When evaluating MCP security tools, ask these questions:

Where does my data go? If the answer isn't "nowhere," ask why it needs to leave your machine.
What network access is required? A scanner that needs internet access to function should explain exactly what it's sending and receiving.
Is the scanning logic transparent? Open-source tools let you verify exactly what the scanner does. Proprietary cloud services don't.
Can it run in my CI/CD pipeline? Security scanning should be automated and integrated, not a manual step that gets skipped under deadline pressure.
What happens to my scan results? Are they stored on someone else's infrastructure? For how long? Under whose jurisdiction?

Try MCPScan

MCPScan is open source, local-first, and free. Install it, scan your configs, and see what it finds — without sending a single byte of your infrastructure data to anyone.

pip install mcpscan
mcpscan scan --config ~/.config/claude/claude_desktop_config.json

Your configurations belong on your machine. Your security tooling should respect that. Get started with MCPScan →