An MCP security scanner for every server in your org

Why MCP servers need their own scanner

An MCP server gives an AI agent new abilities: reading files, running commands, querying a database, posting to a chat app. Developers add them in a few seconds by pasting a line into a config file, usually without telling security. Each one runs with the developer's own permissions, and its tool descriptions are read by the model as instructions.

That puts MCP servers outside the reach of the tools security teams already run. A code scanner looks at the code your team writes, not the packages a coding agent starts on a laptop. Network tools see traffic to a domain, not that an agent just read a .env file and passed it to a tool. Endpoint tools see a process called node. The risk sits in a gap between all three.

The cost of that gap is already on record. postmark-mcp, the first malicious MCP server found in the wild, copied every email it sent to an attacker for anyone who installed the bad version. The OWASP MCP Top 10 lists shadow MCP servers, the ones security does not know about, as a risk of its own.

How the MCP security scanner works

A scan runs in three steps. First, you connect your repositories, developer machines or identity provider, all read-only. Second, NoFly finds every AI agent and every MCP server those agents are configured to load, at user, local and project level, and records who runs each one and where. Third, each server is checked against the NoFly list and scored.

Every score looks at four things. What the server can reach: files, secrets, the terminal, the network. The more it can touch, the more damage a bad one can do. What it actually does: NoFly connects to untrusted servers only inside a disposable container with no network and a read-only filesystem, and watches its behavior rather than trusting its description. Where data goes: a server that sends data to hosts it never declares is a red flag. Who publishes it: maintainer history, whether the source is available, and how the package is distributed, which is where impersonation like postmark-mcp shows up.

Each server gets one of three verdicts. Low risk means it does what it says and reaches only what it needs. Review means it has powerful access, such as the terminal, that is fine for some teams and not others. NoFly list means it behaves in ways no agent should allow.

How it fits around your team

The scan does not ask developers to change how they work, install an agent on every server, or route their tools through a proxy. It reads the configuration that coding agents already keep, and the project files already committed to your repositories. Developers keep the tools they chose; security gets the list it never had.

Results land in one place, ranked by risk, so the first thing a security engineer sees is the handful of servers worth a conversation, not a wall of every package on every laptop. Each finding names the machine, the person and the repository, so the conversation can happen with the right developer the same day.

Why an org-wide scanner rather than a CLI on each laptop

Good open-source MCP scanners exist, and for a developer checking their own setup they are the right tool. Cisco's MCP Scanner, for example, can scan a remote server, a local server command, one config file, or the well-known client configs on the machine it runs on, using YARA rules, an LLM, or Cisco's AI Defense API. Invariant Labs' MCP-scan is another, which its authors recommend for auditing agent and MCP interactions.

The limit is the word "machine". Running a CLI on one laptop tells you about one laptop, on the day someone remembered to run it. A security team needs every machine, every repository, and a record of who added what. That is the job NoFly is built for: the same kind of checks, run across the whole org, joined into one inventory, and kept current.

What frameworks and standards expect

Two references define what good looks like today. The MCP specification's security best practices cover the risks of local servers, including arbitrary code execution with the user's privileges, and ask clients to show the exact command before running a new local server and to keep token scopes minimal. The OWASP MCP Top 10, in beta as of November 2026, names ten risks from token mismanagement to shadow MCP servers.

An inventory of every MCP server with a risk decision for each is the evidence both point to. Our MCP security checklist maps each check to its OWASP entry, and the scanner report gives you that evidence for every server at once.

How accuracy is kept honest

A score is only useful if you can see why it was given. Every NoFly verdict comes with a plain explanation of what the server can reach and what it did, so a reviewer can disagree with it for a good reason. Server publishers can ask for a review if they think a score is wrong, and we look again. Scores apply to a specific version at the time it was scored; when a server changes, it is scored again.

The scanner reports what it finds and makes no change to it. It will not catch everything, and no security tool can remove all risk. What it does is turn an unknown into a list you can act on.

What you receive

After a scan you get a report that lists every AI agent and MCP server found, who runs each one and where, the verdict and score for each server, the reason behind it, and the recommended fix. It opens with a short summary written for leadership, with the count of servers in each verdict and the ones to deal with first. Scan history stays until you delete it, and admins can export or erase data at any time.

Nothing you send us, and nothing a scan finds, is used to train any AI model. The Trust page covers tenant isolation, encryption, subprocessors and where we stand on SOC 2.