November 9, 2026
0 mins read When we announced that MCP Governance is generally available in Evo Agentic Development Security (ADS), the most common follow-up was practical: "Great. Where do I start on Monday?"
It’s a fair question; across 10,000 developer environments, Snyk found 4,524 unique MCP servers in active use, and 1 in 12 developers with an MCP server installed had a confirmed high or critical finding. Most of those servers were added in seconds, by a developer trying to get their agent to do something useful, with no review behind them.
Here’s our answer: four steps can take you from a first inventory to policies that block only the servers that are risky. Evo ADS now provides a risk score for MCP servers so you can govern by risk, with or without an allowlist, instead of reviewing every server by hand or blocking broadly and slowing developers down. Everything runs on the endpoint where agents already work, through lightweight hooks with no proxy in the way. Discover what's there, define what's acceptable, observe what your policy catches, and enforce with confidence.
Step 1: Discover what’s already running #
MCP servers don't pass through CI or dependency reviews. A developer edits one config file, and their agent has a new set of tools. So the first step is to find out what’s already there. You can’t govern what you can’t see, so Evo ADS gives you two views:
-
MCP servers on developer machines: Deploy theEvo ADS installer across your fleet. It surfaces the MCP servers agents are actually connecting to, including one-off local installs that never touched a repo.
-
MCP servers in code repositories :Evo AI-SPM , set up through Snyk's SCM integration, finds MCP servers referenced in your code. Together, these answer two different questions: what is configured in code, and what is running on laptops. Both land within the Evo UI, in Inventory → MCP servers.
You can also use the Evo MCP Server to access this data using your own agentic workflow. This gives you one view of your MCP estate, with nothing blocked and no disruption to developers. With this one step, you can now answer a question most security teams can’t: what are our agents connected to?
Step 2: Define what "acceptable" means #
Deciding whether server number 47 is okay shouldn't take a Slack thread and a web search. Evo ADS puts the evidence next to every server, so you can approve or reject faster, with confidence.
Read the inventory
A high-risk, widely installed, unofficial server is a very different problem from a high-risk one on a single machine. Each row answers the questions you’d otherwise chase down by hand: who built this server, where it’s installed, whether anyone approved it, and how risky it is:
- Server: name, origin (for example, NPM), transport (SSE or STDIO), and whether it is local.
- Vendor origin: whether the server is Official. Unknown is a signal too.
- Source: how many times it appears in code, on machines, and at runtime.
- Allowlist status: Allowed or not allowed.
- Risk score: one unified score per server, sortable and filterable.
- Issues by severity: critical, high, medium, and low counts.
Sort by risk score, then scan across.
Open the Risk profile #
Click a server for the detail view. The header adds authentication methods, and three cards show where it lives: declared in code, on how many machines and when last scanned, and how often agents called it in the last seven days.
Then open the Risk profile tab. This is the tab that replaces the Slack thread and the web search.
In one server we examined, Evo found tool descriptions containing ‘ignore previous instructions’ in 8 of 12 instances. That’s prompt injection you’d only catch by reading every tool description yourself.
Scores run from 0 to 1000:
- Low (0 to 249)
- Medium (250 to 499)
- High (500 to 749)
- Critical (750 to 1000)
The tab breaks the score into attributes such as prompt injection in tool description, destructive capabilities, and untrusted content, each scored out of 1000. Expand one for a description and a "Why this risk?" explanation with evidence.
This server was already on the allowlist. Someone approved it, and it still scores 931, firmly Critical. An allowlist records a decision made at one point in time; the risk score tells you when that decision needs another look. You can move it to “Not allowed” from this page, or block it at runtime.
How servers get scored #
The MCP risk score combines three signals: server behavior (the instructions and tool descriptions it sends to agents), trust (the reputation of its URLs and the identity of its maintainers), and, for local servers with source available, implementation, maintenance, and dependencies. One limitation is that Evo can't confidently identify servers without a signature. That is fewer than 20% of servers, and they don't get a score. Plan for them in your review process.
Set your baseline
The allowlist is your record of which MCP servers you have approved. Each server has a toggle: approved or not. Flip it, and the decision appears in the Allowlist status column of the inventory (Allowed or Not allowed), so everyone viewing the inventory sees the same state. View the allowlist in a server's detail view to see the full list.
Start with what you already trust; you don't need to build it from scratch. Seed it from an existing inventory, a curated list, or the servers Evo ADS has already discovered. Toggle servers manually in the inventory, or just ask Evo in the chat.
For each candidate, check what you learned above: the score band, whether the vendor is Official, how it authenticates, and, for anything High or Critical, the "Why this risk?" evidence. A low-scoring, official, authenticated server is an easy yes. A critical one deserves a reason before you approve it, and a rejection is a perfectly good answer. Remember, the allowlist records decisions. It doesn't block anything by itself. Policies act on those decisions, which is where the next steps come in.
Step 3: Observe before you block #
Turning on blocking on day one breaks developer workflows you haven’t seen yet. Monitor mode shows you exactly what your policy would block before it blocks anything. Create your first policy from the Monitor not allowed MCP servers template on the Policy page (Policies → Issues → Create policy). It raises each risky server as an issue to review, without blocking anything. This way, developers and agents keep working, and you get a running list of everything your policy would catch.
Then work that list in Inventory → MCP servers, using the row and Risk profile you learned in Step 2. For each flagged server, check the score, whether it is official and how it authenticates, and which attributes drove the score. Then decide: approve it onto the allowlist, or reject it. Do this for a week or two and watch for patterns. A server that shows up once is a curiosity, but a server that shows up across fifty machines is a decision you need to make deliberately.
By the end of the second week, you have a policy that reflects your risk appetite, tested against your real estate, with your security and developers having seen it working before it ever stops them.
Step 4: Enforce, starting with what's risky #
Once you trust what the policy catches, switch on enforcement. The Block not allowed MCP servers policy template (Policies → Policies → Create policy) prevents coding agents from calling servers that are not on your allowlist and are rated high or critical risk at runtime on the endpoint. If the template doesn't match your appetite, use Start from scratch and build a custom policy on your own criteria.
The policy blocks a server only when it’s both off your allowlist and rated High or Critical. Everything else keeps running in log mode, so a low-risk server that nobody has approved yet won’t stop a developer, and you still keep an audit trail. Additionally, enforcement happens locally at runtime on the developer’s machine, through lightweight hooks that sit alongside the agent, rather than as a proxy or gateway in its path. You set policy once, centrally. Hooks enforce it on each machine at the moment the agent calls the server, whether that’s Claude Code, Cursor, Codex, or GitHub Copilot.
Say yes to MCP, with control #
So, Monday you deploy the installer and connect your SCM; by Friday, you have an inventory and a seeded allowlist. With Evo ADS, you can say yes to MCP and still know what your agents connect to, decide quickly, and block what's risky. This is the first use case under Govern Agent Behavior, and we're just getting started: over the rest of the year, the same discover, classify, and enforce model extends to agent skills, sensitive data access, prompt injection protection, and secret exposure.
Want to see what your agents are connected to? Schedule a demo or explore Evo Agentic Development Security. SNYK RESEARCH
Inside the Agentic Development Supply Chain #
Anonymized telemetry from nearly 10,000 developer environments, plus agent skill analysis across enterprise environments