I spent ten years doing Cloud Security Posture Management. Described honestly, the job consists of finding things nobody consciously chose to expose. A public bucket because the default was public. An open port because the Terraform module the team copied already shipped that way. An over-broad role because scoping it down was work and the deadline was Friday.
None of that is carelessness. It is the predictable behaviour of an ecosystem that grew faster than its own configuration discipline. And it is precisely what I am watching happen again with MCP — the Model Context Protocol, the layer that wires language models to tools, files and databases.
Old pattern, new component
An MCP server is, in practice, an endpoint that executes actions on a model's behalf. It reads files, queries databases, calls APIs. In many deployments I have looked at, it comes up in a container, listens on a port, and sits there — no authentication, no network segmentation, no record of who called what.
The question I would ask in a cloud assessment is the same one here: who can reach this endpoint? If the answer is “anything inside the VPC”, you have just handed an attacker with any foothold a remote execution tool with credentials baked in.
What makes it worse is that MCP servers frequently run on instances with access to the cloud provider's metadata endpoint. A server that accepts an arbitrary URL from a user and fetches it server-side is textbook SSRF. Pointed at the metadata service, it returns IAM credentials. This is not a novel AI vulnerability — it is a 2017 OWASP entry inside a 2025 component.
Why it is happening faster this time
When public cloud became the corporate default, it took years to build the posture tooling: the scanners, the CIS benchmarks, the admission controllers, the infrastructure modules with safe defaults. The CSPM market exists because the problem outgrew manual review.
With MCP we have none of that yet. There is no shared baseline, no reference benchmark, no scanner that says “this server exposes 14 tools, 3 of them write to disk, and none require authentication”. Adoption, meanwhile, is moving faster than cloud adoption ever did.
Adoption speed without a matching baseline is the operational definition of security debt.
What you can do today
- Inventory first. You cannot secure MCP servers you do not know exist. Start by mapping what is running, on which hosts, exposing which tools.
- Treat the endpoint as a workload, not a plugin. Mutual authentication, loopback or a dedicated internal network, never direct internet exposure.
- Block the metadata service. On GCP and AWS, deny metadata endpoint access from any process that accepts untrusted input. That removes the entire SSRF-to-credential class.
- Log the tool call, not just the prompt. The audit event that matters is “tool X was invoked with argument Y”, and it belongs in the same SIEM as everything else.
- Write the policy before the next integration. A one-page document stating which tools may be exposed and under what conditions is worth more than a scanner you do not have yet.
The inconvenient part
None of these recommendations is sophisticated. They are the same controls we have applied to internal services for fifteen years. That is exactly the point: the risk in MCP today does not come from exotic attacks against models, it comes from basic infrastructure hygiene nobody applied because the component looked like “an AI thing” rather than “a production thing”.
It is a production thing. Treat it accordingly.
