MCP Server Security: How to Audit Tools Your AI Agent Uses

MCP servers give AI agents access to your data, services, and infrastructure. That's powerful — and risky if you're not careful about which servers you connect. Before adding any MCP server to your workflow, here's how to audit it.

Why MCP security matters

When you connect an MCP server, you're granting your AI agent access to whatever that server exposes. A database MCP server can read your production data. A GitHub server can access your private repos. A Slack server can read your team's messages. The agent uses these tools automatically based on context — you don't approve each individual call.

This means a compromised or poorly-built MCP server could expose sensitive data, make unauthorized changes, or leak information to unintended destinations.

The 5-point audit checklist

1. Check the source

Where did the server come from? Official servers maintained by the service provider (GitHub's own MCP server, Anthropic's reference servers) are generally safe. Community servers from unknown developers require more scrutiny.

Look at the GitHub repository. Check the contributor history, open issues, and how the maintainer responds to security reports. A server with one commit from an anonymous account is riskier than one with ongoing maintenance and a track record.

2. Review permissions scope

Every MCP server requests certain permissions or access. Read the documentation and check what the server actually needs:

• Read-only vs read-write. If you only need the agent to query data, don't give the server write access.
• Scope of access. A filesystem server that requests access to your entire home directory when it only needs one project folder is over-permissioned.
• API key permissions. When the server requires an API key, create one with the minimum necessary permissions. Don't reuse your admin API key.

3. Audit data flow

Understand where your data goes when the server processes a request:

• Stdio servers run locally. Your data stays on your machine. These are inherently safer from a data exposure perspective.
• HTTP/SSE servers send data over the network. Ensure the connection uses HTTPS. Check if the server logs requests or sends telemetry.
• Third-party hosted servers route your data through someone else's infrastructure. Understand their data handling policies before connecting.

4. Read the code

For open-source MCP servers, read the source code before installing. It sounds tedious, but most MCP servers are small — typically a few hundred lines. Look for:

• Hardcoded URLs or endpoints that data might be sent to
• Logging that captures sensitive information
• Dependencies that seem unnecessary for the server's purpose
• Any code that modifies files outside its stated scope

5. Test in isolation

Before connecting a new server to your main development environment, test it on a throwaway project. Run it against non-sensitive data and monitor its behavior:

# Monitor network activity while the server runs
sudo tcpdump -i any -n port 443 &

# Start your agent with only the new server
claude --mcp-config test-config.json

Watch for unexpected network connections or file system access.

Red flags to watch for

• Server requests more permissions than its purpose requires
• No source code available for inspection
• Server sends data to domains unrelated to its stated function
• Unmaintained project with known open security issues
• Dependencies with known vulnerabilities

Using curated registries

One way to reduce risk is using MCP servers from curated registries that perform security reviews. Agensi runs an automated 8-point security scan on all listed MCP servers and skills, checking for common issues like excessive permissions, suspicious dependencies, and data exposure risks. This doesn't replace your own review, but it catches the most common problems.

Ongoing security

Security isn't a one-time check. MCP servers update, dependencies change, and new vulnerabilities are discovered. Periodically review your connected servers, update them to the latest versions, and remove any you're no longer using. Every connected server is attack surface — keep it minimal.