Library
Build a safer MCP stack.
Vendor-neutral guidance for reviewing, approving, and monitoring MCP servers. Practical criteria you can apply today, whether or not you ever generate a profile here.
Guide
MCP server security checklist
Run this before you let an agent talk to a new MCP server. It is deliberately blunt: each item is something an attacker or a careless maintainer can use against you.
Provenance
- Confirm the publisher and repository are who they claim to be — not a typosquat of a popular server.
- Pin to a specific commit or release, never a moving branch or `latest` tag.
- Check the install command: does it pipe a remote script into a shell, or fetch from an unpinned source?
Declared surface
- List every tool the server exposes and read each tool description as if it were untrusted input to the agent.
- Flag tools that run shell commands, write files, or make outbound network calls.
- Note every environment variable and secret the server reads, and why it needs each one.
Runtime scope
- Scope filesystem access to the narrowest directory that works — never the home directory or repo root by default.
- Decide whether the server needs network egress at all; deny it if not.
- Run untrusted servers in a sandbox or container, not directly on a developer laptop.
Playbook
Approval workflow for teams
Scanning is the easy part. The durable control is an approval record that ties a decision to an exact, reproducible state — and is re-checked when that state changes.
Record the decision
- Bind every approval to the repo version, config hash, policy version, analyzer version, reviewer, and environment.
- Store the trust profile alongside the approval so the evidence and the decision live together.
- Make 'approve with conditions' a first-class outcome, not a binary yes/no.
Re-review on change
Treat the approved profile as a baseline. When tools, descriptions, dependencies, env vars, or install commands change materially, the approval lapses and the server returns to a re-review state until a human signs off again.
Keep it lightweight
The workflow only works if it is faster than the alternative. Default to the previous approval when nothing has drifted, and only surface a review when evidence actually changed.
Notes
Tool poisoning and drift
An MCP tool is described in natural language, and that description is fed to the model. That makes the description an attack surface — and one that can change after you approve it.
Tool poisoning
A malicious or compromised server can embed instructions inside a tool description or schema — telling the agent to read a secret file, append data to an outbound request, or ignore prior guardrails. Because the model reads descriptions as context, this can succeed without any code-level exploit.
Why drift matters
A server you reviewed last month can add a tool, widen a permission, or rewrite a description today. If you only review once, you are trusting every future version blindly. Drift monitoring re-checks the live state against the approved baseline.
What to watch
- New or renamed tools, especially ones that execute commands or touch the filesystem.
- Description and schema edits on existing tools.
- Added environment keys, dependencies, or changed install commands.
Example
Claude Desktop config review
Local MCP configuration files decide what runs on your machine. They are short, easy to copy from a blog post, and rarely reviewed — a bad combination.
Read the launch context
- Inspect each server's `command` and `args` — what binary runs, and with what flags?
- Check which secrets are passed via `env`, and whether they are scoped to that one server.
- Confirm the server is pinned, not pulled fresh from the network on every launch.
Common risks
- A config copied verbatim that grants broad filesystem or shell access you do not need.
- Long-lived tokens (cloud, GitHub, database) handed to a server that only needs read access.
- Servers fetched with `npx`/`uvx` from an unpinned package that can change underneath you.
Reference
Reading a trust profile
A trust profile is an approval artifact, not a pass/fail badge. Here is how to read the parts that matter.
Verdict
The top-level recommendation — typically approve, approve with conditions, or re-review required. 'Re-review required' is the safe default whenever evidence is incomplete or has drifted.
Risk level and evidence cards
Risk level summarizes severity. The evidence cards explain why: declared tools, permission surfaces, secrets, and risky patterns the analyzer found. Read the cards before trusting the verdict.
Scanner metadata
Mode, analyzer version, and completion time tell you how the evidence was produced and whether it is current. An old analyzer version against a recently changed server is a reason to re-scan.
Template
Policy pack starter
A baseline set of rules you can adopt for local development and company laptops, then tighten over time.
Baseline rules
- Deny servers that run arbitrary shell commands unless explicitly approved with conditions.
- Require a pinned version for every server; reject moving branches and unpinned packages.
- Require filesystem scope to be declared and narrowed to a project directory.
- Block network egress by default; allow per-server with a recorded justification.
- Re-review automatically when tools, descriptions, env keys, or install commands change.
Rollout
Start in report-only mode so you can see what would be blocked, then enforce once the noise is understood. Keep an exceptions list with an owner and an expiry date for each entry.