MCP server · in the free CLI since v0.7.0 · scans run on your machine

Let your coding agent run the security scan.

shield mcp turns the Shield CLI into a Model Context Protocol server. Your agent scans the repository, reads findings in priority order with the flagged line and the fix guidance the engine has for it, and checks a gate, using the same 341-rule engine as shield scan. No account.

1. Install the CLI

curl -sSL https://zennoxa.com/install | sh

Or brew install zennoxa/tap/shield. More options on the CLI page.

2a. Claude Code

claude mcp add shield -- shield mcp

Then ask it to scan the repository with Shield. Add --root . after mcp to confine scans to the project directory.

2b. Other MCP clients (mcp.json)

{ "mcpServers": { "shield": { "command": "shield", "args": ["mcp"] } } }

Any client that starts a stdio server from a command and arguments.

Six tools

All six only read from disk; shield_scan with deps=true also makes outbound requests (see below). Scan results stay in memory for the server session (the last 8 scans), so the agent scans once and asks follow-up questions.

`shield_scan`	Scan a directory. Returns a scan id, severity counts and the top 25 findings by priority.
`shield_findings`	Page and filter the findings of a scan: severity, rule, file, minimum priority, reachable only.
`shield_finding`	One finding in full: file and line, the flagged snippet, the recommendation when the engine has one and, for catalogued SAST rules, the rule description plus a before/after example where the rule ships one.
`shield_rule`	Look up a catalogued SAST rule by id: what it detects, CWE, languages, fix hint.
`shield_gate`	Pass/fail on a scan with a severity, grade or score threshold. Same semantics as the CLI gate flags.
`shield_sbom`	CycloneDX or SPDX components from the dependency manifests, paged.

What a scan returns

Trimmed from a real shield_scan response: the release binary against appsecco/dvna, a public deliberately-vulnerable Node app.

{
  "scan_id": "scan-65eaedf366de",
  "summary": { "total": 12, "critical": 3, "high": 5, "medium": 4, "low": 0, "info": 0 },
  "findings_preview": [
    { "id": "f001", "rule": "SHIELD-TAINT-SQL", "severity": "high", "priority": 41.4,
      "reachable": true, "file": "core/appHandler.js", "line": 11,
      "title": "SQL injection via tainted variable (cross-line data flow)", "cwe": "CWE-89" }
  ],
  "next": "Call shield_finding with a finding id for the flagged code and fix guidance before editing."
}

Each finding has a per-scan id and a fingerprint: a hash of the rule, file path and flagged line text, the same value the CLI writes to SARIF and uses for --baseline. It survives line-number shifts and changes when the file is renamed or that line is edited.

What touches the network

shield_scan (default)	Nothing. No network access.
shield_scan with deps=true	Package names and versions go to OSV.dev; CVE ids go to FIRST EPSS; the CISA KEV feed is downloaded. Source code is not sent.
shield_findings, shield_finding, shield_rule, shield_gate, shield_sbom	Nothing. They read the scan held in memory or local manifests.
What the agent receives	Finding metadata and the flagged source line. Your agent forwards tool results to its model provider, as with any tool.

Limits, stated up front

Priority uses CVSS and reachability, so code, secret and configuration findings top out at 45 out of 100. EPSS and CISA KEV are added for dependency CVEs when deps=true. Findings whose rule has no CVSS value (container-config and Terraform rules today) are not scored.
Secret masking is pattern-based and best effort. Treat agent transcripts of a scan as sensitive.
Shield does not edit code. Your agent does, and should scan again afterwards.
Rule lookups cover the catalogued SHIELD-<LANG>-nnn rules. Taint and dependency findings carry a recommendation in the finding itself; secret, Terraform and most container findings currently return only a title, CWE and the flagged line.
One scan at a time per server and a scan timeout (--scan-timeout, default 10 minutes). /, /proc, /sys, /dev, /run and /boot are refused as scan roots. shield mcp --root DIR rejects scan paths outside DIR; it is a path check, so symlinks inside DIR are still followed.
The detection limits of the engine apply unchanged: rule-based with taint tracking inside a file, no AST, cross-file flows can be missed. See the CLI page and the benchmark.
The CLI binary is MIT-licensed; the engine source is not public.

Questions

Does my source code leave my machine?

The scan itself runs locally and uploads nothing. With deps=true, package names and versions are sent to OSV.dev, CVE ids to FIRST EPSS, and the CISA KEV feed is downloaded. The tool results (finding metadata and the flagged source line) are returned to your agent, which sends them to its model provider like any other tool output.

Are secrets shown to the agent?

For secret-class findings the snippet is masked before it is returned: quoted strings of 8 or more characters and tokens of 16 or more characters keep their first 4 characters and the rest is replaced. It is pattern-based, best effort, and applies to the MCP tools only.

Which agents does it work with?

It is a standard MCP server over stdio. We have run the scan and finding tools end to end with Claude Code 2.1 and with the official MCP Go SDK client. Any client that launches a stdio server with a command and arguments should work; we have not tested other clients ourselves.

Why do priority scores look low?

Code, secret and configuration findings have no CVE, so they top out at 45 out of 100 everywhere: CVSS gives up to 30 and reachability 15. Only dependency CVEs can score higher, through EPSS and CISA KEV with deps=true. The hosted dashboard keeps EPSS and KEV fresh for findings that have a CVE. Findings whose rule has no CVSS value (container-config and Terraform rules today) are not scored.

Does Shield fix the code?

No. Shield reports findings and fix guidance; your agent edits the code. After an edit, scan again and compare fingerprints (a hash of rule, file path and flagged line text) to see what was fixed.

Is it open source?

The CLI binary is free and MIT-licensed. The engine source is not public. Releases, checksums, docs and the issue tracker are on GitHub.

Install the CLI Setup in the docs Report an issue