The Model Context Protocol (MCP) is having a moment. GitHub repos implementing MCP servers are multiplying weekly. Major companies are adopting it as their standard for tool integration. What started as Anthropic’s protocol for connecting Claude to external tools has quickly become the de facto standard for how AI agents interact with the world.
And that’s exciting. MCP solves a real problem: it gives AI agents a standardized way to access filesystems, query databases, call APIs, and interact with tools. Developers love it because they can write a server once and it works with any MCP client. The abstractions are clean. The implementations are straightforward.
But there’s something we need to talk about.
The Pattern We Keep Seeing
Developers building MCP servers often encounter the same security pitfalls. A developer builds an MCP server with filesystem access, doesn’t properly validate paths, and suddenly has an arbitrary file read vulnerability. Another team exposes database credentials in their MCP configuration. Someone else discovers prompt injection through tool parameters. Each time, it’s like discovering fire for the first time.
There’s no checklist. No shared knowledge base. No “here are the common mistakes people make when building MCP servers.”
The security knowledge exists. It’s just scattered across Discord messages, GitHub issues, and individual blog posts. There’s no central place to learn from each other’s mistakes.
Why MCP Security is Different
Traditional security frameworks cover a lot of ground, but they weren’t built for AI agents calling tools. MCP introduces attack surfaces that don’t fit neatly into existing categories:
AI agents have broad access. An MCP server isn’t just another API endpoint. It’s often connected to filesystems, databases, cloud resources, and internal tools.
Prompt injection takes new forms. When user input flows through an AI model and into tool parameters, traditional input validation isn’t enough.
The trust model is complex. Who do you trust: the AI model, the MCP server, the tool being called, or the user prompt?
Implementations are diverse. MCP servers are written in Python, TypeScript, Go, Rust. They run in Docker containers, on cloud functions, as local processes. Each implementation has its own security considerations.
We can’t just apply web security best practices and call it a day. We need threat documentation built specifically for this ecosystem.
💡 The Trust Boundary Problem: In traditional web apps, the trust boundary is clear: user input is untrusted, server code is trusted. With MCP, there are multiple layers: the user prompt (untrusted), the AI model (partially trusted, it follows instructions but can be manipulated), the MCP server (should be trusted but often isn’t properly hardened), and the tools it calls (trust varies). Each boundary needs different security controls, and the interactions between layers create novel attack vectors.
The Case for Community-Driven Security
Here’s the thing: no single company or security team can map out all the ways MCP implementations can go wrong. The protocol is too new, adoption is too rapid, and innovation is happening in too many places at once. Your side project, a startup’s production deployment, and an enterprise integration are all exploring different parts of the attack surface.
But collectively? We’ve probably encountered most of the major vulnerabilities already. Someone on your team might have found that config file exploit. A red teamer at a security conference demonstrated that credential extraction technique. A developer at a hackathon stumbled onto that prompt injection vector.
The knowledge exists. It just needs to be shared.
This is why security has always worked better as an open effort. The CVE database, OWASP, the Linux kernel’s security patches: these succeeded because people contributed what they learned. Transparency builds trust. Collective intelligence beats any individual security team. Network effects kick in: your contribution protects not just your deployment, but everyone’s.
For MCP, this matters even more. We’re still in the early days. The threat documentation we create now will shape how developers think about MCP security for years to come. If we build a shared knowledge base now, while the ecosystem is still forming, we can help developers avoid entire classes of vulnerabilities before they become widespread.
Introducing SAFE-MCP
This is why we created SAFE-MCP: a community-driven threat knowledge base specifically for the Model Context Protocol.
Think of it as the OWASP Top 10 for MCP, or the MITRE ATT&CK knowledge base adapted for AI agent security. It’s an open-source project that documents threats, attack techniques, and mitigations (when known) in a structured, actionable way.
The project is built on battle-tested methodology. We adapted the MITRE ATT&CK approach, which security teams already know and trust. This means:
- Structured documentation: 14 tactics covering the full attack lifecycle, from Initial Access to Impact
- Specific techniques: 78+ documented attack techniques (and growing), each with descriptions, detection methods, and mitigation strategies
- Compliance-ready: Maps to MITRE ATT&CK, making it easier to integrate with existing security processes
- Developer-friendly: Each technique is a GitHub markdown file. Found a vulnerability? Submit a PR.
Here’s what this looks like in practice. Let’s say you’re building an MCP server with filesystem access. You could dig through security blogs and hope to find relevant advice, or you could check SAFE-MCP’s Initial Access tactics and find documented techniques like:
- SAFE-T1007: Path traversal exploitation in tool parameters
- SAFE-T1102: Malicious server registration through compromised configs
- SAFE-T1104: Environment variable injection during server initialization
Each technique includes descriptions, and when known, detection strategies and practical mitigations. Not theoretical advice, but actual knowledge gathered from real implementations.
💡 Why the ATT&CK Format Works: MITRE ATT&CK became the industry standard for threat modeling because it’s both comprehensive and practical. By adopting the same structure for MCP, we make it easy for security teams to integrate MCP threat modeling into their existing processes. If your organization already uses ATT&CK Navigator for threat mapping, you can now include SAFE-MCP techniques alongside traditional network and endpoint threats. This isn’t just documentation, it’s integration-ready threat intelligence.
How This Grows
Right now, SAFE-MCP documents 78 techniques across 14 tactical categories. That’s a solid foundation, but the real power comes from what happens next.
Every time someone discovers a new MCP vulnerability, it should be documented. Every time a security team develops a new detection rule, it should be shared. Every time a developer finds a creative way to exploit an MCP server, that knowledge should become part of the collective defense.
This is where you come in.
If you’re building MCP servers, you’ve probably encountered security considerations others would benefit from learning. If you’re red teaming MCP deployments, you’re discovering attack techniques that could help defenders. If you’re running MCP in production, you’re developing monitoring and detection strategies that others need.
Contributing is straightforward:
- Found a vulnerability? Open an issue describing it
- Want to document a technique? Fork the repo, follow the template, submit a PR
- Building security tooling? Use SAFE-MCP as your threat reference
The project is designed to be accessible. You don’t need to be a security researcher to contribute valuable knowledge.
💡 The Network Effect of Security Knowledge: Security vulnerabilities follow a power law distribution: a small number of technique categories account for most real-world exploits. If even 10% of MCP developers document the vulnerabilities they’ve encountered, we’d likely cover 80-90% of the exploitable attack surface. Your single contribution might be the exact technique that prevents a critical breach in someone else’s production deployment. This is why open security frameworks work: the marginal cost of sharing is low, but the collective benefit is enormous.
The math is simple: if even a small percentage of MCP developers document the vulnerabilities they’ve found, we’d have comprehensive coverage of the threat landscape. Your contribution today becomes the security guide someone else reads before launching their server tomorrow.
What This Means for the Ecosystem
MCP is becoming foundational infrastructure for AI agents. The servers we build today will handle increasingly sensitive operations: accessing private data, making financial transactions, controlling real-world systems. Getting security right matters.
But we have an advantage: we’re early enough to establish good patterns before bad ones become entrenched. We can build the security commons now, while the community is still forming, and create a culture where sharing security knowledge is just what you do.
This isn’t about any one company or project. It’s about raising the security floor for everyone building with MCP. When we share what we learn, everyone’s deployments get safer. When we document threats openly, defenders have better knowledge. When we contribute to SAFE-MCP, we’re investing in collective security that protects our own work.
The knowledge base is live, it’s growing, and it’s open to contributions. Whether you’ve found one vulnerability or a dozen, whether you’re a security researcher or a weekend hacker, your knowledge has value here.
Let’s build MCP’s security playbook together.
Ready to Contribute?
→ GitHub: SAFE-MCP/safe-mcp → Check out the documented techniques → Found something? Open an issue or submit a PR → Star the repo to stay updated as the knowledge base evolves → New contributor? Read the SAFE-MCP Contributor Guide
The security of the MCP ecosystem is a collective effort. Let’s make sure we get it right.