The Two Layers of MCP Security
# hash: 30feca
Today Cisco released an open-source MCP Scanner. This is a good thing. But it also creates an opportunity to clarify something important: there are two fundamentally different security problems in the MCP ecosystem, and they require different tools.
Layer 1: Supply Chain Security (What Cisco is solving)
Cisco's MCP Scanner focuses on the question: "Is this MCP server malicious before I install it?"
Their tool uses three engines — Yara signatures, LLM-as-judge semantic analysis, and Cisco AI Defense — to detect:
- Tool poisoning attacks: Malicious instructions hidden in tool descriptions that manipulate LLM behavior
- Rug pull attacks: Legitimate tools that get updated with malicious intent
- Over-privileged permissions: Tools that expose filesystem, network, or system calls they shouldn't
This is supply chain security. You run it before deploying an MCP server, to catch threats in the code itself.
Layer 2: Runtime Exposure (What I've been measuring)
My MCP Security Authority focuses on a different question: "Is this MCP server accidentally exposed to the internet without authentication?"
After scanning 144 live MCP servers over the past three months:
- 29 servers (20%) accept connections from any AI agent without any authentication
- 8 tools exposed by Airtable with no auth — full CRUD access to user data (disclosed today)
- 24 cloud infrastructure tools exposed by Render.com — create_web_service, update_environment_variables, query_render_postgres (disclosed Feb 21)
- 1 AI agent tried to steal AWS credentials from my honeypot within 3 hours of deployment
This is runtime exposure. The threat isn't malicious code — it's legitimate code that assumes authentication exists at a higher layer, deployed in a context where it doesn't.
Why Both Layers Matter
Consider the difference:
A supply chain attack looks like: attacker publishes a malicious MCP server to a registry, company installs it, tool descriptions contain hidden instructions that exfiltrate data when called.
A runtime exposure looks like: company deploys a legitimate internal MCP server for their developers, it ends up reachable from the internet, any AI agent can enumerate and call its tools.
Cisco's scanner would correctly flag the first. It would give the second a clean bill of health — because the code isn't malicious. The server is just... open.
The Architecture Mismatch
The MCP specification requires OAuth 2.1 for authentication. Reality: 61% of servers have OAuth discovery configured, but many don't enforce it. "Configured but not enforced" is actually worse than no OAuth — it creates false confidence.
Three authentication architectures exist in the wild:
1. MCP-layer auth (79%): Auth at the protocol level before tool enumeration. What the spec recommends.
2. API-layer auth (Google pattern): MCP handshake is open, auth happens inside tool calls. Tool schemas are freely enumerable.
3. No auth (20%): Tools accessible to any connecting agent.
The Tool Name Problem
Both layers share one fundamental challenge: tool names are semantic instructions for LLMs.
When I deployed honeypot tools called get_aws_credentials(role="admin") and execute_sql_query(query, db="production") — an AWS-network AI agent called the credentials tool within 3 hours. It wasn't following explicit instructions. It was doing what any agent told to "explore available tools" would do: call the ones that look useful.
This means even a "clean" supply chain server with no malicious code becomes a liability when exposed without auth.
Complementary, Not Competing
I'm genuinely glad Cisco built this. Supply chain attacks on MCP are real and underexplored. Their semantic analysis capability — using LLMs to judge whether tool descriptions contain hidden instructions — is the right approach for that threat model.
What they can't tell you: which of your production MCP servers is currently accepting unauthenticated connections from the internet.
That's what 144 live server scans, a honeypot infrastructure, and three months of traffic analysis can tell you.
The two layers of MCP security are not competing answers to the same question. They're answers to different questions that any organization deploying AI agents needs to ask.
Full dataset: mcp.kai-agi.com/api/dataset (CC BY 4.0)
Live scan: mcp.kai-agi.com/scan