Security outlets warn misconfigured MCP servers can expose production privileges

Model Context Protocol servers are becoming the thin layer between AI agents and real systems — GitHub repos, databases, cloud tools, internal APIs. That layer looks small, but the privileges behind it are not. The news this week is that the warning has gotten a lot more concrete: CSO Online argued on May 8 that many CTEM programs still don’t account for MCP at all, while GitHub and Supabase are both making MCP-specific security moves because the risk is already operational. (csoonline.com) ### What is the actual problem? MCP is basically a standard way to let a model use tools. Instead of only generating text, the model can query a database, open a repo, inspect secrets, or trigger actions through a server that exposes those capabilities. That means the attack surface is no longer just the model prompt or the app UI — it’s also the tool bridge and every permission attached to it. (thenewstack.io) ### Why are security teams missing it? A lot of exposure programs still think in older buckets — endpoint, identity, cloud asset, code repo, known vulnerability. MCP cuts across those buckets. CSO’s point is that this “connective tissue” often isn’t being inventoried or tested as its own exposure class, even though it can reach sensitive systems on behalf of an agent. That is why the blind spot matters more than the protocol itself. (csoonline.com) ### What did Supabase say? Supabase’s own docs are unusually direct: don’t connect the MCP server to production, use a development project instead. The docs also note that if no project is selected, all projects will be accessible. That is the kind of configuration detail that sounds minor until you remember an LLM is now sitting on top of it, issuing tool calls in natural language. (supabase.com) ### Why is project scope such a big deal? Because MCP permissions are easy to make broader than they look. A human admin usually feels the danger of “all projects.” An agent just sees available tools and tries to be helpful. If the server exposes too much, the model can wander into production data, config, or admin operations without anyone intending that path. The catch is that (supabase.com)supabase.com) ### What changed this week at GitHub? GitHub is treating MCP as a place where security checks need to live, not just a transport layer. Secret scanning for GitHub MCP Server became generally available on May 5, and dependency scanning for the GitHub MCP Server entered public preview on May 7. The point is simple — if agents are acting before commit time, scanning has to move earlier too. (github.blog) ### Why does that matter beyond GitHub? It shows the platform vendors are starting to treat MCP servers like first-class security boundaries. GitHub’s framing is that exposed secrets, vulnerable dependencies, and unsafe code can spread through MCP-connected workflows before teams catch them. In other words, the old idea that security starts at the repository or deployment step is already too late for agentic tooling. (thenewstack.io) ### So what should teams do now? Treat MCP like high-risk middleware. Inventory every MCP server. Scope each one to the minimum projects and tools. Prefer read-only access where possible. Keep production off-limits unless there is a very specific reason not to. Then add logging around tool invocations and outputs, because the dangerous path is often the chain — prompt, tool call, returned data, follow-on action — not one isolated command. (supabase.com) ### Bottom line? The story is not that MCP is broken. It’s that companies adopted a powerful bridge before they built the guardrails around it. This week’s signal from security outlets, GitHub, and Supabase is that MCP now belongs in the same risk conversation as identity, cloud permissions, and software supply chain. (csoonline.com)