The Critical Role of Governance in the MCP Wild West Era

AI MCP Wild West need for governance

TL;DR:

Marketing teams are racing to deploy AI agents for bid management, lead scoring, and ABM dashboards, but IT departments are increasingly blocking these requests — and this article argues that’s a good thing. It explains why IT’s caution is a fair response to explosive, ungoverned AI-connector growth, breaks down three integration architectures (bring-your-own, agent-as-a-service, data-layer-as-a-service), and closes with a practical checklist: read-only capped access, role-based scoping, a documented semantic layer, and audit trails.

Table of Contents

Right now, marketing teams are sharing things they’re doing with AI that sound incredible. Bid-management agents adjusting LinkedIn ad spend in real time. Design studios that turn a one-line brief into on-brand collateral in minutes instead of days. Event leads that get scored, routed, and followed up on before the attendee has left the parking lot. Full ABM dashboards, built from a single prompt, that used to take a BI team a sprint.

You hear all this and you. want. in!

But you hit a wall: your IT department. Connectors require approval, and they’re being flooded with requests for connector approvals faster than they can keep up with, with nuanced responses like,”We can’t connect Claude to Salesforce.” “HubSpot access needs security review.” “Not until we understand what it can see.”

It’s tempting to read that as friction for friction’s sake. It isn’t.

The MCP wild west is real

The Model Context Protocol has gone from a few thousand servers to upwards of 50,000 in about a year — the exact number depends entirely on which registry you count, and it climbs weekly regardless of which one you pick. That growth is the whole story. Anyone can publish an MCP server. Almost no one is checking what it actually does before it ends up connected to potentially sensitive company data.

The research backing this up isn’t reassuring. Scott Brinker’s State of Martech 2026 report found MCP agent integrations reached roughly 29,000 in about eighteen months — a pace that dwarfs the fifteen years it took the commercial martech industry to reach half again as many products. The same report found 91% of marketing organizations already running AI in production, while the most neglected item on the survey — vendor selection and stack management — had the majority of respondents doing effectively nothing about it.

Much of the MCP security conversation around this exploding marketplace is fixated on whether an attacker can exploit a server, when the more basic question, “What does this thing do with your data by design?” goes largely unasked. Registries don’t help: official vendor servers and unverified third-party wrappers sit side by side with the same listing format, no badge or disclosure distinguishing one from the other.

None of that is a reason to avoid AI tooling. It’s a reason why IT caution is appropriate. “Connect this to everything” is a genuinely reasonable thing to hesitate about.

What IT is actually worried about

It’s rarely “AI is scary.” Ask most IT and security teams directly, and the real concern is narrower: most connector requests show up with no answer to three basic questions. What can this see? What can it change? And if something goes wrong, can we reconstruct exactly what happened?

That reframes the standoff. IT is just asking for accountability.

Why that’s a fair ask, not obstruction

If a number from an AI-generated report ends up in a board deck, someone eventually asks where it came from. If a number is questioned or lacking context, “Claude grabbed it” was never going to be a satisfying answer— a traceable path back to a real query you can audit is… and that path can’t disappear the moment your context window expires.

We’ve made a version of this case before, when a marketer in a Slack community asked how to get buy-in for AI-powered analytics tools he’d built himself: the internal battle isn’t about the tool, it’s about whether the org can defend the number the tool produces. Worth a read if you haven’t seen it — the TL;DR version is that governance is a prerequisite, not a bureaucratic afterthought.

Not all connectors are the same request

Here’s the part that gets flattened in most of these conversations: “can we connect AI to our data” isn’t one question with one answer. Under the single “MCP server” label, there are at least three fundamentally different architectures, and they carry very different risk profiles.

Bring-your-own-integration. Your team wires up raw access to a warehouse or platform, and the AI sees the raw schema — it infers what a column means from its name and writes its own queries against it. This is exactly the “we don’t know what it can access” scenario IT is right to flag. Nobody defined the boundaries; the AI is guessing at them in real time.

Agent-as-a-service. A local wrapper around a vendor’s own agent. You send a question, you get back a finished answer — but there’s no data or schema visibility in between. Opaque in the opposite direction: you can’t see what it touched to get there, only what it says it found.

Data-layer-as-a-service. A governed, pre-modeled query layer sitting in front of the AI. The tool gets scoped, read-only access to tables that are already defined, joined, and reconciled against your source of truth — and every query it runs is logged.

These are three very different answers to “what can this actually do with our data.” IT’s yes or no should depend on which one is actually being requested.

What an approvable request actually looks like

Strip away the buzzwords and “governed” comes down to a short, concrete list:

  • Read-only, capped access – not a standing credential that can write, delete, or export at will.
  • Scoped by group or role – not all-or-nothing per user, so a rep and a CFO aren’t working from the same access grant.
  • A defined semantic layer – so the AI isn’t inferring what mkt_rev_elig or pre_opp means from the column name, it’s working from an actual data dictionary.
  • A real audit trail – the specific query behind an answer is retrievable, not just the answer itself.

We’re not just talking the talk on this. CaliberMind’s own MCP server, for instance, works this way by design: Claude gets read-only, capped queries against a governed schema, with SOC 2 controls and a full audit trail underneath every answer. The point isn’t that this is the only way to do it; it’s that “governed” is a specific, verifiable set of properties.

Bring IT the governance story, not the use case

A scoped, auditable request gets a faster yes than “can I connect Claude to HubSpot” ever will — because it answers the question IT is actually asking before they have to ask it.

Before your next access request, know which of the three architectures above you’re actually asking for. And be ready to answer what happens if the AI gets it wrong. 

Picture of Mary Batchelder
Mary Batchelder
Mary is the Director of Revenue Marketing at CaliberMind. With over 10 years experience in marketing operations, demand generation, and social media marketing, and ABM, she has a unique perspective on everything from links in comments to attribution models.

Recommended Resources

Let's make this medium=email.

Sign up for our once-a-month newsletter with insights on everything attribution, operations, and go-to-market.