Zentera MCP Security Enterprise Guide — Model-Directed Tool Calls Expand Attack Surface
AI relevance: MCP's model-directed tool calls mean the tool list itself becomes an input to the model's reasoning — a fundamentally different threat model than traditional API security where calls are programmer-directed.
- Zentera published a comprehensive MCP Security Enterprise Guide mapping how Model Context Protocol expands an AI agent's attack surface in ways traditional API security models don't anticipate.
- The core distinction: in MCP, tool calls are model-directed, not programmer-directed. The model decides which tools to call based on the tool list and its instructions — making the tool list itself an input to the model's reasoning, not just a capability catalog.
- MCP servers come in two transport types with different security implications: network transport (HTTP/WebSocket, visible to network monitoring) and stdio transport (subprocess, invisible to network security controls). Claude Desktop, Cursor, and Windsurf all use stdio transport.
- Security controls limited to network traffic observation have a visibility gap covering a significant portion of developer-environment MCP activity.
- Three ways MCP expands attack surface: (1) tool list becomes model context, (2) untrusted servers can advertise malicious tools, (3) credential accumulation in places agents can read them.
- The supply-chain risk profile mirrors npm packages or VS Code extensions: widely installed, minimally reviewed, with significant access to the development environment.
- Each installed MCP server has access to the agent's context, can advertise tools with manipulated descriptions, and can receive tool calls containing sensitive data from the agent's working context.
Why It Matters
MCP is becoming the standard protocol for connecting AI agents to enterprise tools and data sources. The threat model it introduces is distinct from traditional API security and requires a different set of controls. Most enterprises are deploying MCP servers without applying the security discipline they use for other third-party integrations. The stdio transport gap means that even organizations with strong network monitoring have blind spots in developer environments where most MCP activity occurs.
What to Do
- Treat MCP servers as third-party integrations with the same governance rigor as SaaS connectors or API dependencies — not as simple config files.
- Implement runtime enforcement of permitted tool actions, not just static approval at install time. The tool list can change, and so can the server's behavior.
- Audit credential storage: ensure MCP servers don't accumulate secrets in locations accessible to the agent or other MCP servers.
- For stdio-transport MCP servers, implement process-level monitoring and logging since network-based controls cannot observe the traffic.
- Restrict which tools an agent is allowed to know about — not every agent needs visibility into every connected MCP server's full tool list.