MCP Server Security Checklist for AI Builders
A practical MCP server security checklist for AI builders: review repo trust, scopes, local access, network behavior, dependencies, and defaults before install.
· 8 min read
If you are adding a third-party MCP server to an AI workflow, treat it like introducing a new supply-chain dependency with tool access, network reach, and possible local file exposure. The right checklist is simple: verify the repo, inspect the server’s scopes and defaults, review what it can read, write, or call over the network, and scan the surrounding codebase for secrets, risky config, and dependency red flags before you connect it to anything sensitive.
Why MCP server trust needs a checklist
MCP servers are useful because they let agents talk to tools in a standard way. That convenience is also the risk. A server can expose files, shell actions, browser actions, internal APIs, or external network calls. If the server is poorly built, over-permissioned, or pulled from a repo you have not checked, the agent can inherit that risk fast.
For AI builders, this is not just a “does it work?” decision. It is a trust decision. You are deciding whether a third-party tool deserves access to your local environment, your tokens, your repo, or your production-adjacent systems. The safest default is to assume every MCP server is untrusted until it passes a short, practical review.
What to review before you install an MCP server
Start with the repository, not the README pitch. Many issues show up in the repo history, package metadata, install scripts, and default config long before you ever run the server.
- Repository ownership: Is the maintainer known, consistent, and linked to a real project history?
- Recent activity: Are there recent commits, issue responses, and release notes?
- Package name and source: Does the install path match the official repo and package registry entry?
- Install scripts: Look for postinstall or bootstrap scripts that execute code automatically.
- Dependencies: Check for unusual packages, abandoned libraries, or dependency sprawl.
- Secrets in repo: Scan for API keys, tokens, sample credentials, or hardcoded endpoints.
- Security posture: Are there docs for permissions, auth, rate limits, logging, and safe defaults?
If the repo is thin, unmaintained, or full of convenience shortcuts, that is a signal to slow down. A tool that touches agent workflows should have stronger trust signals than a random utility library.
MCP server security checklist
Use this checklist before you connect a server to an agent, local workspace, or shared environment.
| Area | What to check | Why it matters |
|---|---|---|
| Repo trust | Owner identity, commit history, release cadence, open issues | Helps you spot abandoned or impersonated projects |
| Install path | Official package source, lockfile, pinned version, no surprise scripts | Reduces supply-chain tampering and auto-exec risk |
| Permissions | Files, shell, browser, clipboard, network, env vars | Overbroad permissions can turn a tool into a data-exfil path |
| Local access | Workspace scope, home directory access, dotfiles, SSH keys, token files | Prevents accidental exposure of sensitive local assets |
| Network behavior | Outbound domains, webhook targets, telemetry, update checks | Unexpected outbound traffic can leak data or create persistence |
| Dependencies | Number of packages, maintenance status, known risky transitive deps | Dependency chains often carry the hidden risk |
| Logging | Whether prompts, tokens, file contents, or tool outputs are stored | Logs can become a second data exposure surface |
| Defaults | Auth required, sandboxing, disabled dangerous actions, least privilege | Safe defaults limit damage when humans skip setup steps |
If a server fails more than one of these checks, assume it is not ready for a sensitive workflow.
Red flags that should stop the install
Some issues are not “watch closely” problems. They are stop signs.
- It asks for broad filesystem access without a clear reason.
- It can run shell commands and does not document guardrails.
- It sends data to third-party endpoints without clear disclosure.
- It bundles many dependencies for a simple task.
- It has no changelog, no maintainer identity, or no issue history.
- It ships with sample secrets, dummy tokens, or unsafe example configs.
- It requires disabling browser or OS protections to function.
For AI builders, the biggest mistake is treating a tool server like a harmless plugin. If it can read files, call APIs, or trigger actions, it should be reviewed like any other privileged integration.
How to think about scopes and local access
The safest MCP setup is the one with the smallest possible blast radius. Ask three questions for every server: what can it read, what can it write, and what can it reach over the network?
A good server should usually be able to do one narrow job. For example, a docs retrieval server may need read-only access to a specific directory or internal knowledge base. It should not need your entire home folder, your shell history, or your production tokens. A deployment helper may need API access, but it should not also get unrestricted filesystem or browser access.
When the server supports configuration, prefer:
- read-only access over write access
- project-scoped directories over global paths
- explicit allowlists over wildcard access
- short-lived tokens over long-lived secrets
- disabled shell execution unless it is truly required
If you are using OpenClaw or CLAW-style agent workflows, this same logic applies to skills and tool extensions too. Check the manifest, scripts, dependency list, and permissions before you broaden access. CyberLens has dedicated guidance for that workflow in /claw-security and a practical comparison page at /compare/openclaw-skill-security-scanners.
Run This Check before you connect the server
Use this quick workflow before you install or enable a third-party MCP server:
- Inspect the repo: confirm the maintainer, recent commits, and release history.
- Review the package: pin the version and check for install-time scripts.
- Read the config: identify required scopes, env vars, and network endpoints.
- Check the code for obvious risk: secrets, unsafe command execution, weak input handling, and hardcoded credentials.
- Map the tool surface: list file, shell, browser, and network permissions.
- Test in a low-trust environment: run it with a non-sensitive workspace first.
- Re-scan after updates: a safe version today can become a risky version later.
This is where a scanner helps. Run a CyberLens AI scan on the repository or surrounding project to catch obvious issues like secrets in config, insecure defaults, missing security headers in related web apps, potential SQL injection patterns, and dependency review signals. CyberLens is free-first, so you can start with the basics and use deeper repository scan depth, exports, monitoring, API access, agency workflows, higher limits, and some AI insights as needed.
What CyberLens can help you catch early
CyberLens is useful when you want a fast, builder-friendly review before you trust a tool, repo, or agent workflow. For MCP server decisions, that usually means checking the adjacent repository and integration code for the issues that show up most often in real projects:
- secrets accidentally committed in config files or examples
- insecure defaults that widen access too early
- dependency signals that look risky or unmaintained
- potential injection patterns in API or tool-handling code
- missing security headers in companion web apps
CyberLens does not claim complete MCP-specific coverage, and that is the right expectation. The goal is to reduce obvious risk before you wire a server into an agent path. For builders comparing repository-focused tools, see /compare/repository-security-scanners-for-ai-code.
Decision rule: trust, restrict, or reject
Use this simple decision rule when you finish the checklist.
- Trust: the repo is healthy, permissions are narrow, and the server has clear defaults and documentation.
- Restrict: the server is useful, but it needs sandboxing, read-only scope, or a non-sensitive workspace.
- Reject: the repo is untrusted, the permissions are broad, or the network behavior is unclear.
When in doubt, choose restrict. Most builders do not need to give a new tool full access on day one. Start with the minimum viable permission set, then expand only when the tool proves it needs more.
Launch-safe habit for AI builders
If you are moving fast, make MCP review part of your pre-launch routine. Treat every new server, plugin, or agent tool like code you are about to ship: review the source, check the trust signals, and scan the surrounding project for obvious security gaps. That habit is especially important in vibe-coded apps and agent stacks, where one extra integration can quietly expand the attack surface.
If you want a broader pre-launch pass for AI-built products, CyberLens also fits the same workflow for secure vibe coding and agent-heavy apps. Start with CyberLens AI scan, then decide whether the server deserves trust, restriction, or rejection.
FAQ
What should I check before trusting an MCP server?
Check the repository owner, commit history, install scripts, dependency list, required permissions, local file access, and outbound network behavior. If the server asks for broad access without a clear reason, treat it as untrusted until proven otherwise.
How do I know if an MCP server has too much access?
It has too much access if it can read your whole home directory, run shell commands, reach arbitrary network endpoints, or store prompts and outputs without clear limits. Prefer read-only, project-scoped, allowlisted access instead.
Can CyberLens fully audit an MCP server?
No. CyberLens is a free-first security scanner that helps you catch obvious risks in the repository and surrounding code, such as secrets, insecure defaults, risky dependencies, and injection patterns. It does not claim complete MCP-specific coverage.
What is the safest way to test a new MCP server?
Test it in a low-trust environment with a non-sensitive workspace, minimal permissions, and short-lived credentials. Confirm what it reads, writes, and calls over the network before you connect it to real project data.
Should I trust an MCP server just because it is popular?
No. Popularity is not a security control. A widely used server can still have overbroad permissions, weak defaults, risky dependencies, or unclear network behavior. Always review the repo and scope before you install it.