You can run a security scanner without shipping your source code anywhere

When you build an AI agent, you end up with a folder of things you do not want to upload to a stranger's server: an MCP config full of API keys, a node_modules bundle with third-party skills, and — if you ship an SDK or an MCP server to clients — source code that is literally your product.

The usual "free online scanner" flow asks you to either paste your code into a box or zip up the repo and upload it. That is fine for a public demo project. It is a non-starter for closed-source, unreleased, or commercially sensitive code.

It turns out you do not need a backend to do this. A static-analysis scanner can run entirely in the browser tab. Here is how we built ours, and the one architectural decision that makes it trustworthy.

The constraint: the bytes must never leave the machine

The goal was simple to state and surprisingly easy to get subtly wrong:

• drop in an mcp.json / MCP config, or a JS bundle / node_modules folder
• get a report mapped to OWASP AISVS 1.0 (the AI security verification standard)
• zero upload, zero account, zero telemetry

"Zero upload" is not a marketing line here, it is an enforced property. There is no server endpoint to receive files. The page is static HTML + one inlined JavaScript bundle. fetch is never called with file contents. The scanning engine reads files through the browser's own File / FileReader API (drag-and-drop or the file picker), analyzes them in memory, and renders the report into the DOM. Close the tab and the data is gone.

You can verify this the honest way: open DevTools → Network, drop in a file, and watch nothing leave.

How a CLI scanner becomes a browser scanner

The scanner already existed as an npm CLI (npx correctover-scan) and a GitHub Action. The trick to the browser version was that the engine was already pure static analysis — no network calls, no model dependency on the hot path. The core verification logic runs in sub-millisecond time on the core verification hot path, which matters because the browser tab has to stay responsive while you drag in a few hundred files.

The build step (tools/build-browser.js) bundles the same core/ modules the CLI uses into a single scan-bundle.js and exposes them on window.CorrectoverScan. The HTML page calls:

• scanConfig(text) for MCP config files — 14 checks covering things like MCP transport TLS, tool auth, tool-allowlist pinning, kill-switch / budget limits, SSRF guards, credential exposure, sandboxing, version pinning, and logging.
• scanBundle(files) for JavaScript — a set of checks over the bundled code, with a semantic pass instead of naive keyword matching.

That last part is where naive scanners fall over. A grep for child_process or eval will flag every build tool, test runner, and bundler in existence. The engine classifies intent: is that exec() argument a hardcoded constant or attacker-controlled? Is the eval inside a known code-execution sandbox, or is it running LLM-controlled input? Is the credential-looking regex part of a detection rule (the scanner contains a few of those itself)? Benign contexts get suppressed; genuinely dangerous patterns — dynamic eval of model output, unguarded shell execution, secrets passed to an unauthenticated MCP transport — get surfaced.

Some checks are marked semi-automated: the engine flags the pattern, but a human has to confirm whether the control is actually enforced in deployment. The report says so explicitly.

Mapping to a standard instead of inventing one

Rather than hand you a pile of red/yellow dots, every check maps to an AISVS 1.0 control (for example, tamper-evident logging under the orchestration/agentic security chapter). The mapping page is deliberately honest about coverage: the automated scanner covers parts of 8 of the 12 AISVS chapters, and the chapters it cannot cover statically — training-data integrity, adversarial robustness, model lifecycle change control — are marked as not covered, not silently skipped.

That honesty matters. An automated scan is a fast first pass; it is not an audit, a certification, or a compliance verdict. The printed report carries that disclaimer, and the pages that reference AISVS note that OWASP® and AISVS are trademarks of the OWASP Foundation, which does not endorse or certify products.

Why this changes the workflow

For a team shipping agents or MCP-based products, the practical difference is:

1. You can scan the thing you were going to ship. Unreleased SDK, internal agent config, client code under NDA — none of it touches a server.
2. You get a shareable artifact. The report prints/saves as PDF from the browser, so you can attach it to a vendor response without anyone needing an account.
3. The same engine runs in CI. The browser scanner, the CLI, and the GitHub Action share the core modules and the rule identifiers, so a finding has the same name wherever it shows up.

The free scan deliberately does not try to do everything. It cannot produce a signed audit opinion, it cannot sign off on your supply chain, and a clean report does not mean "no vulnerabilities" — static analysis has false negatives by construction. For a vendor-acceptance or compliance trail you still need a manual audit. What it gives you is a five-minute, privacy-preserving first look at the configuration and bundle mistakes that cause the worst agent incidents: over-permissive tool allowlists, MCP servers without auth or TLS, unbounded agent budgets, and model output flowing into a shell.

Try it, and watch the Network tab

The scanner is here — a static page, no signup:

https://dshcorrectover.github.io/agent-audit/scan.html

Drop in an mcp.json or a JS bundle, open DevTools → Network first if you are the skeptical type (you should be), and watch the bytes stay put.

If you build agent tooling, I would be curious to hear what it flags in your own config — especially the semi-automated checks, where a human reading the context still beats any rule.

---

This article references OWASP AISVS 1.0 as an external, independently maintained community standard; Correctover is not affiliated with or endorsed by OWASP, and automated scanner output is not an audit or certification. Work on the related conformance receipt protocol is documented in an individual Internet-Draft (draft-correctover-ccs), which is an IETF work-in-progress, not an RFC and not an IETF endorsement.