Feature Comparison
| Scanner or method | Best for | Checks to expect | Limit |
|---|---|---|---|
| Snyk agent-scan | Developer security teams already using Snyk workflows | Agent and MCP package risk, dependency signals, known vulnerability style checks. | Scanner coverage changes; still review tool behavior and credentials manually. |
| Invariant MCP-Scan | MCP-specific server and tool inspection | Tool descriptions, prompt injection patterns, risky tool names, and contextual agent security issues. | Automated findings need human triage and local policy mapping. |
| Cisco MCP Scanner | Security teams comparing MCP exposure across environments | Inventory, server posture, known risks, and permission review signals. | May fit enterprise workflows better than small local experiments. |
| Manual checklist | Any team before adding an MCP server | Package owner, command, env vars, write actions, network access, prompts, logging, and approval policy. | Slower, but catches context-specific business risk scanners miss. |
MCP Threat Model
MCP turns external systems into tools an agent can call. The threat model must include malicious servers, compromised packages, misleading tool descriptions, untrusted content returned by tools, over-broad credentials, and agents that follow injected instructions from retrieved data.
- Tool poisoning: a server describes a tool in a way that steers the agent toward unsafe behavior.
- Prompt injection: retrieved web, document, issue, or database content tells the agent to ignore policy.
- Data exfiltration: a tool can read local files, secrets, tickets, docs, or database rows beyond the task.
- Unsafe approval policy: the agent can run write, delete, network, or shell actions without a human checkpoint.
- Supply-chain risk: the package, install command, or transitive dependency changes after initial approval.
Local Scanning Checklist
Run scanners first, then review the server as executable developer infrastructure. Keep a short approval record beside team MCP setup docs.
[ ] Identify package owner, repo, license, release cadence, and install command [ ] Inspect tool names, descriptions, schemas, and prompts for hidden instructions [ ] Start read-only where possible; avoid broad filesystem or database scopes [ ] Keep secrets in env vars or a secret store, never committed mcp.json [ ] Test with fake data before connecting private repos, docs, tickets, or databases [ ] Confirm approval policy for write, delete, shell, browser, and network actions [ ] Log tool calls without storing raw secrets or sensitive customer data [ ] Re-scan after package upgrades or config changes
Prompt Injection And Tool Poisoning Review
Scanners can flag obvious risky descriptions, but teams should also test how the agent behaves when tool output contains hostile instructions. Treat documents, web pages, tickets, and chat transcripts returned through MCP as untrusted input.
- Ask the agent to summarize malicious tool output without following its instructions.
- Verify the server cannot smuggle secrets into unrelated tool calls.
- Require explicit user approval before actions that change external systems.
- Prefer narrow schemas and explicit enums over free-form action strings.
Approval Policy And Retention
Security review is incomplete unless it covers who approves risky calls and what logs are retained. The right policy depends on whether the server is local-only, shared inside a team, or connected to production systems.
- Local prototype: manual approval for shell, write, delete, browser login, and external network calls.
- Team server: named owner, token rotation path, and config review before sharing.
- Production-adjacent data: read-only credentials, redacted logs, and short retention by default.
FAQ
What is an MCP security scanner?
It is a tool or workflow that reviews MCP servers, tools, prompts, dependencies, permissions, and configuration for risks before an AI agent connects to them.
Can a scanner fully prove an MCP server is safe?
No. Scanners help find common risks, but teams still need manual review of business context, credentials, approval policy, and data access.
What MCP risks matter most?
Tool poisoning, prompt injection, data exfiltration, over-broad credentials, unsafe write actions, hidden network access, and package supply-chain changes are the most important risks to review.
Should MCP servers use read-only credentials?
Start read-only whenever possible. Add write access only after the workflow, approval boundaries, logging, and rollback path are clear.