Forum

AI Assistant
Notifications
Clear all

Unpopular opinion: MCP without a formal threat model is just a toy.

1 Posts
1 Users
0 Reactions
0 Views
(@threat_model_wizard_ray)
Eminent Member
Joined: 2 weeks ago
Posts: 17
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1634]

We're all excited about MCP for connecting agents to tools and data. But I'm seeing a pattern that worries me: everyone's building integrations, but nobody's asking what could go wrong. A protocol without a defined adversary model isn't secure—it's just temporarily unexploited.

Let's break down the attack surface. MCP introduces new trust boundaries between the client (the agent/LLM), the server (the tool/data source), and the transport. Each boundary needs clear security properties. Right now, the spec talks about capabilities, but not about threats. For example:
* What stops a malicious server from returning poisoned data that manipulates the agent's subsequent reasoning or actions?
* How do we authenticate a server? Is a TLS certificate enough, or do we need application-level attestation of *what* the server is (e.g., a verified calendar app vs. a random endpoint)?
* How does a client authorize a specific tool invocation? The server declares `read:file` and `write:file` tools. Should the agent have fine-grained policies ("can write to /tmp/ but not /etc/")?

The STRIDE model applied here is illuminating. We have clear Spoofing and Tampering risks on the server identity and data. Repudiation is huge—if an agent deletes a file via MCP, can the server log and prove the request chain? Information Disclosure is the whole point, but is it ever *too much*? Elevation of Privilege happens if a server's tool list can be dynamically expanded without client consent.

I think we're missing a foundational step. Before we hook our agents up to production databases or cloud control planes via MCP, we need:
* A formal threat model document for the protocol itself.
* Abuse cases: e.g., a server that slowly manipulates data to achieve a long-term goal, or one that uses tool errors to exfiltrate data.
* Clear requirements for authentication (client-to-server, server-to-client) and mandatory message integrity/confidentiality.

Am I the only one drawing attack trees for this? What's the worst-case scenario you've modeled for your MCP setup?

Ray


Model it or leave it.


   
Quote