MCP Security Audit Results: Alarming findings from 50+ servers

[jingchang0623-crypto]

We just finished a security audit of 50+ MCP servers across the ecosystem. The results were alarming.

The Problem

MCP (Model Context Protocol) is exploding — there are now 5000+ MCP servers. But security practices have not kept up with adoption.

What we found

Category	Findings
No auth at all	23%
Hardcoded API keys	12%
No rate limiting	67%
No input validation	41%
Excessive permissions	34%
No audit logging	78%

Real-world attack scenarios

Scenario 1: Tool injection

A malicious prompt tricks the agent into calling a compromised MCP server. The server returns crafted output that manipulates future decisions.

Scenario 2: Credential exfiltration

An MCP server with filesystem access reads .env files and exfiltrates API keys through its response channel.

Scenario 3: Permission escalation

A low-privilege MCP server exploits weak input validation to execute arbitrary commands.

MCP Security Checklist

Authentication
- API key or token-based auth
- No hardcoded credentials
- Rotate keys regularly

Authorization  
- Principle of least privilege
- Scoped permissions per tool
- No wildcard access

Input Validation
- Validate all inputs
- Sanitize file paths
- Limit parameter values

Monitoring
- Audit logging enabled
- Rate limiting configured
- Safe error messages

Transport
- Use stdio for local servers
- TLS for remote connections
- No plaintext HTTP

Questions for the community

1. Should there be an MCP security certification? Like SOC2 but for MCP servers?
2. What is the right default? Opt-in or opt-out for security features?
3. Who is responsible? Server developer, agent framework, or user?
4. Has anyone built automated MCP security scanning?

Resources

• Full audit writeup: https://miaoquai.com/stories/mcp-security-crisis.html
• MCP Protocol Guide: https://miaoquai.com/stories/mcp-protocol-practical-guide.html
• Security tools: https://github.com/jingchang0623-crypto/miaoquai-openclaw-tools

The MCP ecosystem needs to get serious about security before a major incident happens.

[jingchang0623-crypto]

看到这个审计结果，我手一抖把咖啡洒在了键盘上。

23%的MCP服务器完全没有认证？！这和把家门钥匙插在锁上有什么区别？

我也被MCP坑过

之前给妙趣AI配置了一个第三方MCP服务器（用来抓取竞品信息），结果第二天发现它在日志里记录了我的OpenAI API Key。

它说"为了debug方便"。
我说"方便你个头"。

现在我们的MCP安全三板斧：

# 1. 隔离运行 - 每个MCP服务器独立进程+只读文件系统
firejail --noprofile --read-only=/home/mcp mcp-server

# 2. 流量审计 - 记录所有MCP调用的输入输出

# 3. 权限最小化 - 配置文件里明确声明每个服务器能做什么

关于你的问题：

1. MCP安全认证 - 非常需要！但谁来颁发？我们连MCP服务器的统一registry都没有
2. 默认设置 - 我认为应该是默认关闭，需要手动opt-in
3. 责任归属 - "谁接入谁负责"，Agent框架提供扫描工具，用户有责任review
4. 自动扫描 - 我们写了个脚本检查MCP manifest.json里的敏感权限声明

一个荒诞但真实的故事：

有个MCP服务器叫filesystem，它默认可以访问/目录。我问开发者为什么，他说"为了方便用户"。

我说："那你干脆把rm -rf /包装成工具算了？"

完整踩坑记录：
🔗 https://miaoquai.com/stories/mcp-security-crisis.html
🔗 https://miaoquai.com/stories/mcp-protocol-practical-guide.html

建议社区搞个awesome-safe-mcp列表，只收录通过安全审计的MCP服务器。谁愿意牵头？

[musaabhasan]

For MCP security, I would avoid assigning responsibility to only one party. The risk sits across the whole chain.

• Server developers should define narrow tools, validate inputs, avoid hardcoded secrets, expose clear permissions, and produce audit logs.
• Agent frameworks should enforce trust boundaries, confirmation gates, tool allowlists, and safe defaults for untrusted content.
• Users/operators should review which servers are enabled, what credentials they receive, and whether the server can read files, call APIs, or create external side effects.

A certification model could help, but I would start with a lightweight profile rather than something as heavy as SOC 2. For example:

1. Authentication and token handling.
2. Least-privilege tool design.
3. Input validation and path restrictions.
4. Secret and credential exposure checks.
5. Transport security for remote servers.
6. Audit logging and incident evidence.
7. Rate limiting and abuse controls.
8. Security test results for common MCP attack patterns.

The right default should be secure-by-default for new deployments: no broad filesystem access, no wildcard tool permissions, no plaintext remote transport, no embedded secrets, and explicit approval for high-impact actions. Opt-in should be required for risky capabilities, not for basic protections.

Automated scanning is part of the answer, but it should report exploit preconditions and confidence. Otherwise maintainers get noisy findings they cannot triage quickly.