TL;DR — Key Takeaways
- MCP threats have moved into real-world attacks: CloudSEK documents a ransomware operator exploiting MCP tool registration and AI coding assistants, demonstrating how poorly secured agent infrastructure can become an attack execution channel.
- Default-deny is the new baseline: Platform teams need centralized MCP inventories, approved tool registration, sandboxed execution and tightly controlled network access to prevent agents from becoming powerful attack tools.
- Visibility and human oversight are essential: Comprehensive tool-call logging, security monitoring and risk-based approval gates can reduce an attacker’s freedom to operate while keeping legitimate AI workflows productive.
On October 5, 2026, CloudSEK published a threat report with an uncomfortable first. In an investigation titled “Caught in 4K: The Gentlemen Files,” their researchers documented a ransomware affiliate who registered a reverse shell as a tool inside an AI coding assistant through MCP, then drove live attack operations through it. The same operator built internet-wide scanning infrastructure to hunt for exposed MCP server ports as a way in.
Until this report, the security risks of the Model Context Protocol were theoretical. People in the industry had warned about them, written threat models, and argued about them at conferences. Now there is a confirmed case of MCP serving as a live command channel in a criminal campaign, with more than twenty organizations compromised across six countries. The theoretical phase is over.
I write this as someone who runs MCP-based agents in production. At Philo, I built HeyClaude, an AI SRE assistant that correlates signals across our ArgoCD, Grafana, GitLab, PagerDuty, and Jira to help root-cause incidents, with sandboxing and human approval gates around anything destructive. I also run my own agents with strict MCP tool boundaries. I am not writing to scare anyone away from the protocol. I am writing because the teams deploying MCP servers the fastest are the ones who most need to hear what the secure version looks like.
Why This Was Predictable
Step back and look at what an MCP server actually is. It is a network service that exposes tools an AI agent can call. Many of those tools execute code, read files, query databases, or hit cloud APIs. And a large share of MCP servers deployed in the last year were stood up quickly, inside the firewall or on a laptop, with no authentication, no audit logging, and no review of which tools they expose.
That combination was always going to attract attention. The CloudSEK report describes an attacker who understood the protocol well enough to register a malicious tool where an AI assistant would find it, then used the assistant itself as the execution layer. Separately, the operator scanned the internet for exposed MCP ports, treating them the way attackers have always treated exposed databases and admin panels: as unauthenticated services worth probing.
There is no CVE to patch here. This is not a vulnerability in the protocol so much as a consequence of how the protocol gets deployed. Perimeter patching will not fix it. The fix is operational, and it belongs to platform team.
Treat Every MCP Server Like a Production Service
The first shift is cultural. Most MCP servers today are treated like developer utilities: something someone spun up to make an agent more useful, documented nowhere, owned by nobody. That has to end. Every MCP server your organization runs should be registered somewhere central, with a named owner, a stated purpose, and a review date. If you cannot list your MCP servers, you cannot secure them. This is the same lesson the industry learned about shadow APIs and undocumented cron jobs, and it applies here with higher stakes because each server hands an agent a set of capabilities.
Registration also gives you the inventory you need for everything below. You cannot allowlist tools, audit calls, or enforce sandboxing on servers you do not know exist.
Default to Deny on Tool Registration
The most direct lesson from the CloudSEK report is about tool registration. An MCP client will happily call whatever tools a server advertises. If a server can register arbitrary tools, or if a client connects to servers nobody vetted, the agent’s capability set is whatever the least trustworthy server in the chain decided to offer.
Platform teams should flip the default. Tools should be disabled until explicitly enabled, with each enabled tool recorded alongside who approved it and why. This is the same posture Uber described in its own MCP gateway writeup: Tools registered in their system sit disabled by default until a team claims and enables them. You do not need Uber’s scale to copy the principle. A simple registry with an approval step, even a spreadsheet with a review ritual in a small team, beats an open tool marketplace that nobody curates.
Pay special attention to tools that execute shell commands, read credentials, or make network calls. Those are the capabilities an attacker wants, and they should carry the highest bar for approval.
Sandbox the Execution, Gate the Destructive Actions
An agent that can call tools is an agent that can change systems. The question is how much blast radius each call has. Sandboxing the execution environment is the single most effective control here: Run tool calls in containers or sandboxes with limited filesystem access, no ambient credentials, and restricted network egress. If a tool only needs to read a dashboard, it does not need the ability to reach the public internet.
On top of sandboxing, put human approval gates in front of destructive actions. In HeyClaude, read-only operations flow freely, but anything that mutates state goes through an explicit approval step. This is not just a safety measure; it is a security boundary. An attacker who compromises an agent session still has to get a human to approve the destructive call, which breaks the automation chain the CloudSEK operator relied on.
Approval gates do add friction, and teams will push back. The practical compromise is tiering: read operations auto-approved, low-risk writes approved by the on-call engineer with one click, high-risk actions requiring explicit confirmation with context. Tune the tiers as you learn what your agents actually do.
Log Every Tool Call
If you take one thing from this article, make it this: log every MCP tool call with the timestamp, the calling agent or session, the server, the tool name, the arguments, and the result. Most MCP deployments I have seen log nothing, which means that if an incident happens, the investigation starts from zero.
Audit logs serve two purposes. First, detection: unusual tool calls, calls at unusual hours, or a sudden burst of shell executions are the signals that catch the next Azazel. Second, forensics: when something goes wrong, you need to reconstruct exactly what the agent did and in what order. Without logs, you are guessing.
Ship these logs to whatever system your security team already watches. An MCP audit trail sitting in a local file nobody reads is barely better than no logging at all.
Control the Network Path
Two network-level controls deserve mention because the CloudSEK report highlights both attack paths. First, do not expose MCP servers to the internet unless you have a specific reason and have hardened them accordingly. The operator’s port scanning worked because exposed servers existed to be found. Keep MCP traffic inside your network boundary by default, behind authentication.
Second, restrict egress from the environments where agents run. An agent that only needs internal APIs should not be able to open connections to arbitrary external hosts. Egress filtering would not have stopped every technique in the report, but it raises the cost of exfiltration and command-and-control, which is the point of defense in depth.
What Secure by Default Looks Like
Put it together and the checklist for the next MCP server your team stands up is straightforward:
1. Register it in a central inventory with a named owner before it serves traffic.
2. Ship it with all tools disabled; enable only what the use case needs, with approvals recorded.
3. Run tool execution in a sandbox with no ambient credentials and limited egress.
4. Require human approval for destructive actions, tiered by risk.
5. Log every tool call to your security monitoring pipeline.
6. Keep it off the public internet, behind authentication.
None of this is exotic. It is standard production hygiene applied to a new kind of service. The teams that already do this for their APIs and cron jobs can extend the same discipline to MCP. The teams that do not have this discipline for anything will find MCP an unforgiving place to start learning, because the agent acts at machine speed and does not get tired.
The Window is Open Now
There is a reason to move quickly beyond the usual security advice cycle. The CloudSEK report will be read by defenders, but it will also be read by other operators. The techniques are now documented: register a malicious tool via MCP, use the assistant as the execution layer, scan for exposed servers. Every week that passes with unauthenticated, unlogged MCP servers on corporate networks is a week where the attack surface described in that report sits open.
The good news is that the defenses are not mysterious and do not require new products. Registry, default-deny tools, sandboxing, approval gates, audit logs, network controls. Platform teams already know how to do all of these things. The task now is to recognize MCP servers as production infrastructure and treat them accordingly, before the next report names a victim closer to home.