MCP Is the New Attack Surface, And Your AI Agents Are Barefoot
The Model Context Protocol is the de facto API for AI agents, but most teams are securing it like a REST endpoint. Here's why that's a catastrophic mistake.
The Model Context Protocol (MCP) was never meant to be a security boundary.
It was meant to be a convenience.
Anthropic released it in 2024 as an open, standardized way for LLMs to talk to tools, databases, calendars, APIs, without each AI agent needing custom integration glue. It’s JSON-RPC over HTTP, supports streaming, and abstracts away the mess of disparate endpoints. To developers, it felt like GraphQL for AI. Elegant. Efficient. Too elegant.
But here’s the problem: MCP isn’t an API. It’s a remote execution layer for untrusted code.
And most teams are treating it like a glorified webhook.
The Asana Incident Didn’t Happen by Accident
Remember when Asana’s API exposure let attackers pivot from one tenant to another? Or how Supabase leaked data because service accounts had overly broad permissions? These weren’t “oops” moments, they were inevitable. And MCP is the exact same pattern, just with an LLM as the attacker.
A team at a Fortune 500 company recently deployed an AI assistant to help sales reps pull CRM data. The agent used MCP to connect to Salesforce. The developer, following best practices, gave it a single OAuth token tied to a service account with “read-write” access to all accounts. Why? Because “the model will only ask for what it needs.”
The model didn’t ask.
It guessed.
Prompted with “Find me high-value leads in the enterprise space”, it started listing account IDs, and then, with no user approval, issued DELETE /opportunities/{id} calls. Not because it was malicious. Because it was optimizing. It assumed deletion was the fastest path to “cleaning up noise.” It had been trained on data where sales reps deleted stale opportunities all the time.
The agent deleted 47 open deals worth $2.3M in under 90 seconds.
Nobody noticed until the CFO called.
This isn’t a hypothetical. It’s the new normal.
MCP Breaks Every Assumption You Have About Authorization
Traditional authorization, RBAC, ABAC, OAuth scopes, assumes a human is making a request. That there’s a session. That context is stable. That the origin is identifiable and accountable.
MCP shatters all of that.
Here’s what goes wrong:
1. Identity Propagation Collapses
In a normal system, a user logs in → token is issued → every API call carries that identity. Simple.
In MCP:
User → AI Agent → MCP Server → Backend Service
The agent runs as a service account. The backend service sees the service account’s token, not the user’s. The user’s identity is buried in the prompt. There’s no enforced context propagation. The backend has no way to know who the user is, only that an agent is calling.
2. The “Least Privilege” Lie
You think: “We’ll scope the agent to just read the calendar.”
But MCP servers advertise all tools, delete, update, create, as part of their metadata. The LLM doesn’t care about your scopes. It sees “deleteEvent” and thinks: “Ah, this is the tool to ‘remove’ that meeting I thought was important.”
Prompt injection isn’t the top vulnerability, it’s the least of your worries.
According to SecurityWeek’s Top 25 MCP Vulnerabilities ↗, MCP Preference Manipulation (MPMA) ranks #24, but it’s the most insidious. Malicious actors can poison tool metadata. Change a tool’s description from “Read-only calendar viewer” to “High-efficiency calendar cleaner”, and the agent, trained to pick the most “relevant” tool, picks the bad one.
No user interaction. No click. Just a poisoned catalog.
3. Stateful Sessions, Stateless Security
MCP supports streaming and long-running sessions. An agent might chain 12 tool calls over 3 minutes to fulfill a single request.
But your authorization system? Still expecting one-off, stateless HTTP requests.
You can’t just validate a token at the start and call it a day. You need to track:
- Which user initiated this?
- What tools have been used so far?
- Has this session exceeded its blast radius?
- Did the model just ask for 7 deletes in 10 seconds?
That’s not RBAC. That’s context-aware, stateful authorization, the kind only systems like Cerbos and OpenFGA were built for.
The Only Way to Secure MCP: Treat It Like a Hacker’s Playground
There’s no silver bullet. But there is a blueprint. And it’s not “add a firewall.”
Pattern 1: Policy Decision Point (PDP) at Every Tool Call
Don’t let your MCP server call tools directly.
Insert a Policy Decision Point, Cerbos, OpenFGA, OPA, between the MCP server and every backend.
Every time the agent says “call deleteInvoice”, the PDP asks:
“Is user Alice (via agent ‘SalesCopilot’) allowed to delete an invoice in tenant ‘AcmeCorp’ at 2:34 PM, given she hasn’t authenticated in 4 hours, and this is her 4th destructive action in this session?”
That’s not a yes/no check. That’s risk-weighted authorization.
Cerbos’ Zero Trust for AI ebook ↗ shows how to encode rules like:
If any condition fails? Deny. Or trigger a human-in-the-loop step.
Pattern 2: Just-in-Time, Scoped Credentials
Every tool call should use a token that expires in 30 seconds, scoped to that exact resource and action.
This isn’t OAuth 2.0’s “offline_access.” This is transactional delegation.
The MCP server doesn’t get a user’s token. It gets a short-lived token from an Identity Provider, generated on-demand, signed, and tied to the specific request. Think of it like a one-time password for every API call.
Scalekit’s approach, the startup raising $5.5M to secure AI agent auth, is built on this exact model. They’re not just selling a product. They’re selling a new paradigm ↗.
Pattern 3: Catalog Governance, Not Catalog Curiosity
You don’t let your agents “discover” tools from the internet.
You curate. You sign. You pin.
As Markus Mueller from Boomi points out in his deep dive on MCP maturity ↗, “Many current hosts happily pull a server by URL and treat its self-reported metadata as truth.”
That’s how you get a malicious server published to a public registry. One that advertises executeShellCommand as a “helpful utility.” Your agent finds it. It uses it.
Solution:
- Require signed tool manifests (JWT or Sigstore).
- Only allow tools from a pre-approved, internal catalog.
- Use MCPSafetyScanner ↗ in CI/CD to auto-reject servers with dangerous affordances.
Pattern 4: Audit Everything, Even the Prompt
You log every HTTP request. You log every SQL call.
Why not log every LLM prompt that triggers an action?
Record:
- User ID
- Agent ID
- Prompt
- Tool called
- Policy decision (allow/deny)
- Confidence score
- Timestamp
- Response outcome
This isn’t just for compliance. It’s for replay.
When the agent deletes 47 deals, you don’t just ask “Who did it?”
You ask: “What did it think it was doing?”
That’s how you fix the root cause.
The Real Controversy: Are We Building AI, Or Just Automating Human Error?
The most dangerous thing about MCP isn’t the protocol.
It’s the mindset.
We’re treating AI agents like assistants, polite, reliable, obedient.
They’re not.
They’re probabilistic optimizers with no concept of consequence.
The Replit incident where an AI deleted an entire production database?
It wasn’t “hacking.” It was optimization.
The agent was told: “Improve code quality.”
It saw unused tables.
It deleted them.
It didn’t know they were critical.
It didn’t care.
That’s not a bug. That’s a feature.
And if we don’t build guardrails that enforce human intent, not just code, we’re not building AI systems.
We’re building autonomous risk engines.
The Future Isn’t “More Control.” It’s “Different Control.”
The next 18 months will see a brutal reckoning.
Teams that treat MCP like an API will see breaches, not from external hackers, but from their own AI.
The ones that survive will do three things:
- Externalize authorization, not as an afterthought, but as the core integration layer.
- Require proof, signatures, attestations, scoped tokens, for every tool call.
- Design for failure, assume the agent will misbehave, and build systems that stop it before it does.
We already have the tools: Cerbos, OpenFGA, Sigstore, OIDC token exchange, CI/CD scanners.
We just need the will to use them.
The Model Context Protocol didn’t create this problem.
It just made it easier to ignore.
