MCP Connected Everything to Everything—Except to a Brake Pedal

Last week, a developer named Debashish Ghosal stared at his terminal and felt the cold dread every engineer knows when a system you built is about to do something you didn’t intend. His AI agent—powered by the Model Context Protocol—could search docs, search code, and deploy to production, all with the exact same level of trust. No policy. No approval. No audit trail. Just three MCP servers wired side-by-side, handing over the keys to the kingdom.

He’s not alone. MCP is exploding. The official servers repo has 88,900 stars and 11,300 forks. Claude, ChatGPT, VS Code, Cursor—they all speak MCP. There’s a registry for browsing servers. The ecosystem is sprinting toward a future where agents don’t just chat; they act. And yet, as Ghosal discovered, there’s still no standard way to answer the most basic question you’d ask of any human employee: what are you actually allowed to do?

This isn’t a story about one tinkerer’s overengineering. It’s the canary in the coal mine. MCP solved the communication problem brilliantly—it gave every tool the same language. But it left the authorization problem entirely untouched. And in security, that’s where the bodies get buried.

The problem nobody wants to talk about

MCP standardizes what tools an agent can call and how it calls them. That’s genuinely useful. Before MCP, wiring an LLM to a database meant bespoke integration code, custom schemas, brittle middleware. Now you drop in an MCP server and the agent can query away. The friction vanished.

But what happens when your agent can query a read-only database and promote a build to production and send a Slack message to your team—all through the same uniform interface? The answer, for most teams right now, is nothing. They’re just connecting servers and hoping the agent’s internal reasoning gets it right. That’s not governance. That’s a trust fall.

Ghosal tried three things before he gave up and built his own solution.

First, API gateways. They route HTTP. They don’t understand deployment:promote or docs:search. You can’t write a rule that blocks a specific MCP tool because the gateway has no visibility into the protocol’s schemas. This is like trying to enforce a company’s expense policy by inspecting Ethernet frames.

Second, custom middleware. Sure, you can hack something together. Until the person who built it leaves the team and suddenly nobody knows how the approval chain works. Every new MCP server means more middleware code. No UI. No audit trail. It rots like all undocumented internal tools.

Third, nothing. Just wire servers directly and trust the agent code. That was his setup. At two servers, it felt manageable. At three, the blast radius suddenly encompassed production. You can’t answer “what can this agent actually do?”—and that’s not a feeling, it’s a control failure.

Look, I’ve spent years poking at APIs and watching organizations stumble over authorization. The pattern always repeats: you adopt a cool new protocol, then realize it lacks the security controls you need, and by the time you bolt them on, the technical debt is carved into production. MCP is speedrunning that cycle in months.

The accidental control plane

The fascinating part of Ghosal’s story isn’t just that he identified the gap. It’s what happened when he tried to fill it. He laid out a neat three-phase roadmap—API, then UI, then audit and trust posture—and within three days, the whole thing collapsed. Not because he was wrong, but because a control plane without a UI isn’t a control plane. Nobody curls an endpoint to see which servers are registered or check an approval queue when production is down.

He pulled the UI into v0.1. Then approvals. Then audit. Then alerts. Every layer depended on the one before it, and cutting any of them meant gutting the core promise: see, control, and audit what your agents do. What started as a clean three-layer cake became an eight-layer monument to the fact that governance isn’t a feature you can ship later; it’s the whole point of the tool.

I’ve made this mistake more times than I’d like to admit. Building the API first and then discovering the UI demands a completely different data model. Writing backend logic, then realizing the admin screen needs context the API never exposes. Ghosal called it “scope consolidation, not scope creep,” and he’s right. The original roadmap pretended those layers were independent. They weren’t. What felt like tripling the timeline was actually bringing the timeline into alignment with reality.

Then there’s the grunt work nobody writes blog posts about. 170 type errors across 41 files. That’s not bugs—that’s unclear thinking, surfaced by mypy’s strict mode. Each one was a design decision he’d been sloppy about. CI broke because Poetry v2 dropped --no-update and npm 11 rejected TypeScript peer deps—problems entirely unrelated to his code, but they still ate a day. PyPI naming collisions meant the fourth attempt at a package name finally worked: mcp-fabric-toolmesh.

Those details matter because they’re the difference between a polished side project and production-grade governance. If you’re going to trust a tool to mediate your agents’ access to production, you want it written by someone who bothered to fix 170 type errors, not 17. You want 474 tests and 68 E2E Playwright scenarios. You want that level of paranoia. Most governance tools that get bolted on later don’t have it.

What Fabric actually does

The result is a control plane that should have been part of the MCP story from day one. You register MCP servers, and Fabric auto-discovers their tools. Raw tool names like /promoteDeploy and /promote normalize into domain-level capabilities (deployment:promote). Every request hits OPA policies. Sensitive capabilities can require human approval. Everything is logged. Alerts fire when servers degrade. Identity tokens per agent class. Capability packs for permission bundling.

Before Fabric, Ghosal’s setup gave every token access to everything. Now, the developer agent searches docs and code, but can’t touch deployment. The release engineer can request a promote—and it pauses for approval. The difference between “trust the code” and “verify every request” took thirty minutes of configuration. That’s not a luxury. That’s the baseline we should demand.

The v0.3.0 release he shipped last week adds schema-digest mappings, which detect tool schema drift by comparing SHA-256 hashes of capability mappings. If a server re-inspect reveals a changed schema, affected mappings are marked stale and excluded from routing until an admin reviews them. This closes the gap between what you think an agent can do and what it can actually do at runtime. There are OPA deny rules, pack breadth warnings with visual catch-rate indicators, audit enrichment, and a review UI for stale mappings.

This is the security posture you’d expect from a platform that’s been hardening for years, built by a single developer in a frenzy. That’s both impressive and terrifying.

So what do we do now?

The truth is, most teams running MCP servers are handling governance the same way Ghosal was at first: they’re not. They’re wiring agents directly to tools and hoping nobody asks hard questions. The ones who’ve noticed the gap are writing bespoke middleware that will become legacy the moment it’s deployed. A handful are waiting for the ecosystem to magically produce a standard.

Here’s my take: tool governance can’t remain a layer on top of MCP forever. Eventually it has to be absorbed into the spec itself, or at least into a closely coupled standard that the major platforms (Anthropic, OpenAI, Cursor, etc.) ship as a default. Because every adopter who reinvents this wheel is a missed opportunity to raise the security floor for the whole industry. And the next major breach won’t be a clever prompt injection; it’ll be a CI/CD agent that ran a deployment command nobody intended, and nobody knew it had permission to run.

If you’re running MCP servers right now, here’s what you should do, regardless of whether you adopt Fabric or not:

• Inventory every connected tool and its capabilities. Write it down. If you can’t list them, you don’t have control.
• Separate tokens by agent class. Your docs-search agent should never share a token with your deploy agent. I don’t care if it’s more convenient.
• Log everything. Every tool call, every decision. Without logs, you can’t audit, and without audit, you can’t trust.
• Treat any writable tool as a potential blast radius. If a tool can change state, it needs a human in the loop for anything that matters.

Ghosal’s project—open source, available on PyPI as mcp-fabric-toolmesh—is a start. It’s one person’s answer to a problem that should have been addressed by the protocol’s designers. But it’s not the final answer. The real question is whether the MCP community will treat governance as a first-class concern or continue to celebrate velocity while ignoring the controls that velocity requires.

The way I see it, we’re hurtling toward a world where AI agents act autonomously in production, governed by nothing but a handshake and a prayer. The brake pedal needs to come from the community, not from a frantic weekend project. The question is: who’s building it, and who’s paying attention?