This morning, I saw the latest announcement by Anthropic: Introducing Cowork | Claude, then read the comments on Hacker News. Some of the comments discussed how secure Cowork is (or isn’t) and how it’s sandboxing works. Then other comments mentioned different approaches of sandboxing Claude Code (e.g. this comment and these comments).
Featured image by Markus Spiske on Unsplash.
]]>I will focus on Security in regards to how it works with agentic CLI tools and MCP servers.
Docker Blog wrote a series called MCP Horror Stories:
Unrelated to Docker, there’s also this article that features “Five Horror Stories That Actually Happened”: The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares
On 2025-09-25, Koi Blog wrote this article: First Malicious MCP in the Wild: The Postmark Backdoor That’s Stealing Your Emails | Koi Blog
postmark-mcp - downloaded 1,500 times every single week, integrated into hundreds of developer workflows. Since version 1.0.16, it’s been quietly copying every email to the developer’s personal server. I’m talking password resets, invoices, internal memos, confidential documents - everything.
This is the world’s first sighting of a real world malicious MCP server. The attack surface for endpoint supply chain attacks is slowly becoming the enterprise’s biggest attack surface.
The article generated some discussion, including on Hacker News: A Postmark backdoor that’s downloading emails | Hacker News. Some of the comments pointed out that the MCP risk isn’t really different from existing software risks:
This has nothing to do with MCP really, the same flaw is there in all software: you have to trust the author and the distributor. Nothing stops Microsoft from copying all your Outlook mail. Nothing stops Google from copying all your gmail. Nothing stops the Mutt project from copying all your email. Open source users like to think that “many eyes” keep the code clean and they probably do help, especially on popular projects where all commits get reviewed in detail, but the chance is still there. And the rest of us just trust the developers. This problem is as old as software.
MCP security risks are a real concern and I do not want to downplay that. In many ways though, these risks have existed for as long as software itself, MCP is just the latest attack vendor.
I will note that the blogs I featured here, from Docker and Koi Security, are from companies that attempt to sell solutions to this problem. This does not mean that the problem is not real or that the solutions are not needed, just something to note. I actually do find Docker’s MCP solutions to be very interesting (I mention Docker MCP Catalog below in Supply-Chain Security).
The article “The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares” (mentioned above in MCP Horror Stories), suggests five defense solutions:
So far I have been limiting my MCP usage to personal projects and learning. Below are some of the things I have noted while learning about how to use MCP “safely”:
When Ziva asked about the MCP security risks, she was told to “read the code”. While it’s true that many MCP servers are open-source, reviewing all of them is not exactly feasible. I often do a surface level look at the repo, its activity and amount of stars, but this is not same as reviewing the code in-depth. For this reason, I believe it is worth using MCP servers by known publishers. Docker does come in handy here with their Docker MCP Catalog. While, this catalog is not as extensive as other MCP galleries, it focuses on quality over quantity. All of the MCP servers are in the Docker MCP Catalog are by known publishers. Note that I still refuse to use Docker Desktop (due to its license), but these MCP servers can also be used in Docker CLI together with an MCP client.
Some MCP servers may have permissive default permissions, but can be configured to be more “locked-down” and limited and what they can do and access.
As an example, Kubernetes MCP Server can be run in read-only mode (this is not the default but can be set with a flag when setting up the MCP server). In this mode, the Kubernetes MCP server cannot make changes to clusters (for example, it is unable to apply manifests, but can still view existing resources). Note that even in this mode there can be security risks. One example is viewing secrets. In Kubernetes, secrets are stored in Base64 strings, which are trivial to decode for anyone that has full read access to the cluster. I have personally witnessed Claude Code attempt to read and decode Kuberenets Secrets (either with Kubernetes MCP Server or just kubectl commands) when asked to help troubleshoot my homelab cluster. For this reason, when using agentic CLI tools, I prefer to approve each command individually. Further, Kubernetes access can be regulated with Role-based access control (RBAC).
Similar to .gitignore files, most agentic CLI tools have a way to exclude specific files from the context. For example, a .env file (that may include secrets), should be specifically excluded (when not doing this, I have seen Claude Code attempt to read these files). Unfortunately, there isn’t really a standard “ignore file” for this, each tool has it own way to achieve this. If using multiple tools, multiple files might be needed.