MCP Security Scanner: Prove What a Clean Scan Covers

An MCP security scanner can answer a valuable preflight question: what agent components did I discover, and what risks did the scanner find in the version it inspected? It cannot answer the whole operational question: is the connected agent healthy now, and did its tool call produce the intended result? Use a clean scan as one bounded receipt. Before trusting it, verify four things separately: 1. the scanner covered every relevant configuration and component; 2. running the scanner did not execute an untrusted local server outside a sandbox; 3. the scanned manifest is still the manifest the client will use; 4. a live session and a destination specific outcome check pass after the scan. That boundary matters because scanning is not necessarily passive. The documentation for Snyk Agent Scan v0.5.15 says that scanning an MCP configuration starts the stdio commands defined in it so the scanner can retrieve tool descriptions. Its default interactive flow asks for consent first. The same documentation marks the CLI output fields and issue codes as experimental. The reasonable default is therefore: inventory broadly, scan in a disposable environment when a configuration is not already trusted, preserve a content minimized receipt, and require live evidence before changing an agent's health state. Start with a coverage receipt, not one green line A scanner report needs a denominator. “No findings” means little if a project level configuration, an extension bundled server, or a declined local command never entered the scan. The v0.5.15 Agent Scan documentation publishes two useful matrices: supported agents by operating system and detection coverage by configuration scope. The scope matrix explicitly distinguishes system, user, project/workspace, and extension/plugin locations. It also contains gaps. That is healthier than an undocumented promise of universal discovery, but it means the operator must compare the scanner's coverage with the actual installation. Build a receipt with identifiers and hashes, not prompts, credentials, tool arguments, or results: expectedConfigs must come from your deployment inventory, not from the scanner's own discovery count. Otherwise an undiscovered file reduces both numerator and denominator and still looks complete. Pin the scanner release as well. The Agent Scan v0.5.15 release, published July 16, 2026, includes platform binaries, checksums, a signed checksum file, and an SBOM. Those artifacts let you record exactly what executed. They do not certify future versions, a locally rebuilt binary, or the security of an MCP server. Treat a declined server as an inventory gap, not as a passing server. The decline may be the correct safety decision. The resulting aggregate verdict is still incomplete because the server's tools and descriptions were not inspected. Treat scanner execution as a privileged test The current MCP Security Best Practices describe local servers as downloaded or authored binaries that can run with the client's privileges. For one click local configuration, the guidance requires showing the exact command and obtaining explicit approval before connection. It also recommends sandboxing and restricting filesystem, network, and process access. Apply the same caution to a scanner that starts configured servers. A malicious or simply overprivileged command does not become harmless because its parent process is called a scanner. For an unknown configuration: copy only the configuration and required fixture data into a disposable VM or container; remove production credentials and replace destinations with local test doubles; deny network access unless a specific test requires it; mount the filesystem read only where practical; review the exact command and arguments before consent; record which servers were declined, timed out, or failed initialization. Do not solve non interactive automation by blindly enabling a “run every configured server” flag on a developer laptop or production host. The scanner may need such a mode for controlled CI, but the trust decision belongs to the environment and manifest, not to the convenience of the flag. There is also a data boundary question. Agent Scan documents that component names and descriptions can be sent to its analysis service, while it says MCP tool call contents and results are not stored or logged. Review the policy and actual configuration of whichever scanner you choose. A content free operational receipt should retain issue codes, counts, versions, hashes, coverage gaps, and timestamps; it should not copy sensitive descriptions or server output into a health dashboard by default. Separate scan evidence from live health A scanner works mainly before or around connection. Agent health continues after that point. Keep three receipts: Scan receipt: inventory coverage, scanner version, findings, safe execution, and manifest hash. Live session receipt: successful initialization, negotiated protocol and capabilities, current authorization, fresh tool discovery, and bounded request/response correlation. Outcome receipt: deterministic evidence from the destination that the intended change or deliverable exists. The distinction prevents two false green states. First, the configuration can change after the scan. A tool description, command argument, package version, server URL, or scope can drift while the old report stays green. Compare a normalized manifest hash at scan time and immediately before connection. A mismatch means STALE SCAN ; it does not mean “probably safe.” Second, a scanner can pass while the runtime is unreachable, unauthorized, or unable to complete a tool call. Even a successful MCP tools/call response does not prove the external effect. A file may be written to the wrong directory, an API may accept but later reject a job, or a message may never reach its destination. Verify the artifact or state the user actually requested. The following precedence gives each failure one bounded next action: The 24 hour age in this example is a policy input, not a protocol constant. A frequently changing development configuration may need a much shorter window. An immutable, signed deployment could use the hash match as the decisive freshness check. Replay the inconvenient cases before adoption I replayed eight content free receipts against that classifier: an untrusted command scanned directly on the host; a server declined during discovery; a critical finding; a manifest changed after scanning; a clean, current scan with no live check; a clean scan followed by a failed live session; a successful tool return with no destination evidence; a current scan, passing live session, and verified outcome. All eight produced the expected state. More importantly, the scanner only case produced SCANNER PASS ONLY , not HEALTHY BOUNDARY . The first healthy verdict required all three evidence layers. This is not a benchmark of scanner detection accuracy. I deliberately did not execute third party MCP configurations on the host: the source documentation establishes that doing so can start local commands. To compare detection engines, create safe representative fixtures for the risks you care about, run each scanner in an isolated environment, and measure false negatives, false positives, unsupported scopes, and output stability. That limitation is operationally useful. It stops a team from turning an unverified scanner comparison into a security claim. Use a scanner for the decision it can support Adopt an MCP security scanner when it gives you a better component inventory, catches relevant configuration or manifest risks, exposes its coverage limits, and can run inside your safety boundary. Reject or contain it when the scan itself needs privileges or data transfer you cannot justify. After adoption: 1. pin and verify the scanner artifact; 2. define the expected configuration inventory outside the scanner; 3. scan untrusted local commands only in a disposable environment; 4. block on critical findings and explicit coverage gaps; 5. compare the manifest hash again at connection time; 6. run a minimal live initialization and authorization check; 7. verify one representative destination outcome before declaring health. The scanner is not diminished by this rule. It becomes more trustworthy because its verdict is attached to the evidence it actually observed. Sidewisp is an AI agent health platform intended to make evidence, freshness, uncertainty, and the next safe action visible across existing runtimes. Sidewisp is currently in private preview. Production MCP scanning, live agent health collection, and recovery adapters are not shipped today.