Three Key Operational Patterns You Need to Prevent MCP Horror Stories

* Cecilia Liu Senior Product Manager at Docker ---------------------------------------- Cecilia Liu, Product Manager at Docker speaking, at MCP Dev Summit North America 2026 TLDR: Many MCP failures come from weak security architecture or lack of operational guardrails for what the agents can and cannot do. In her talk, Cecilia Liu of Docker examined two real MCP “horror stories” and walked through how to build a three-layer control plane for MCP: an MCP gateway that enforces policy, identity, and audit logging; sandboxed agent runtimes with OS-level isolation; and enterprise deployment integrated with existing identity, secrets, and observability infrastructure. ---------------------------------------- MCP Horror Story One: An engineer needs MCP servers to ship faster, so they search a few directories and find one on Google that looks right and appears to pass the sniff test. They install it without review or approval, straight into their local MCP catalog. There are no support tickets or sign-off. IT and security have no idea it exists. Three weeks later, the security team finds a data leak. The codebase, API keys, and secrets are all exposed, and because there’s no audit log, nobody can tell what happened or when. This is a nightmare scenario that remains all too plausible. MCP Horror Story Two: At a larger company that already maintains an approved list of MCP servers, an experienced developer connects an approved GitHub integration and asks the agent to clean up a repo. The developer is a true believer in autonomous agents, so they let it run without confirmation. The agent merges open PRs, deletes branches and closes issues. A few minutes later, the developer goes to check the results and finds everything gone – including a work-in-progress branch that was never pushed. Nothing malicious happened. Everything the agent did was permitted. But that didn’t prevent serious damage. FOUR QUESTIONS TO ASK ABOUT MCP USAGE PATTERNS As AI usage inside companies scales quickly and MCP servers and infrastructure becomes more common inside of organizations of all stripes, four questions are crucial to consider: 1. Which MCP servers and tools are allowed? 2. Which user called which tool, from which client, and when? 3. What data was flowing through the model context? 4. What actually happened, and is there a record of it? Many organizations are still struggling to answer these questions. This create a gap in security and operational resilience. THREE THINGS THAT CLOSE THE MCP OPERATIONAL GAP In her talk, Liu proposed a clear multi-layered approach to better lock down MCP activity and safeguard code and processes from problems, both malicious and unintentional. THE MCP GATEWAY An MCP gateway sits between your AI agents and your MCP servers, and everything flows through it. That single control point makes governance possible and simplifies discovery for users, who know if it’s in the gateway catalog, its OK to use. An MCP gateway enforces a curated server catalog, so any server not on the approved list is blocked at step zero, the engineer never knows it was stopped, and the security team never has to find out about it three weeks later. In Horror Story One, the MCP server pulled from Google would have been blocked before it was ever deployedIn Liu’s view, a catalog is just the starting point. A proper gateway also manages authentication so secrets never travel to MCP servers directly., The gateway also should enforce role-based access control so different teams get different tool sets, and write a full audit log of every call. That last piece is the one that transforms “something went wrong” into “here’s exactly what happened, who did it, and when.” THE SANDBOX The gateway controls what an agent is allowed to call, but a sandbox controls what it can actually do. A sandbox runs each agent in its own container with isolated file system and network access, enforced at the OS level rather than the application layer. That distinction matters because application-layer controls can be circumvented, while OS-level controls cannot. If the sandbox says an agent has no write access to a directory, the agent cannot write there., Horror Story Two’s agent couldn’t have deleted that branch without OS-level permission to do so in the first place, which means the developer could have let it run with complete confidence. Gateway plus sandbox creates two barriers. Together they make agents trustworthy enough to run in production. EASY DEPLOYMENT The best governance is the kind developers don’t notice, and the only friction they should feel is that they can no longer install random servers from Google. In practice that means the architecture plugs into what organizations already have: their identity provider, their secrets manager and their observability stack. It works on-prem, air-gapped, or across clouds with a single manifest install. The goal is governance that fits easily into your environment without requiring major changes. Without this, the first two will generate friction that degrades the developer experience and reduces their efficiency. MAPPING THE THREE MCP CONTROL COMPONENTS TO YOUR STACK The three elements map cleanly to the four questions: Question Where it’s answered What’s allowed? Gateway catalog + policy Who did what, when? Gateway audit log What flowed through? Gateway secrets URI + interceptors What can the agent actually do? Sandbox capabilities Horror Story One is a catalog problem — solved by making the gateway the only path to any MCP server. Horror Story Two is a capability problem — solved by policy at the gateway and OS-level limits in the sandbox, because neither alone is enough. What’s more, neither approach is likely to scale without simplicity. Taken together, these patterns create a durable and repeatable deployment model that generalizes MCP security across most platform and infrastructure types. ---------------------------------------- Cecilia is a Product Manager at Docker. The Agentic AI Foundation is the home of open agentic standards and open source infrastructure. To learn more about MCP and connect with engineers thinking through these problems, visit aaif.io, join the conversation in the AAIF Discord, or join us at an upcoming AAIF event.