Notes from a product team on putting an MCP trust boundary around a frontend/ops agent: allowlists, approval gates, and ...

Notes from a product team on putting an MCP trust boundary around a frontend/ops agent: allowlists, approval gates, and a gate on the read path.Our first MCP integration felt like magic. We had an agent that could look at a failing preview deploy, check feature flag state, read the related issue, and tell you what was wrong. Every capability came from an MCP server, and the agent discovered tools by reading their names and descriptions.That discovery step is the whole point of MCP, and it was also where we got careless. We treated tool descriptions as documentation. They are actually input to the model, which makes them instructions. What went wrong1. Everything was over-permissioned by default.We connected servers the way you install npm packages: add the config, see the tools appear, move on. If a server exposed twenty tools, the agent got twenty tools. Nobody had decided that a "look at the deploy" agent should be able to touch config, flags, or tickets. It could, so it did.A few sp...