Ask your business in your own AI chat: how governed MCP actually works

Here is the question every company leader asks me after the demo: "Okay – but how do I give the whole organization AI answers in their own chat without losing control of a single number?"

That's the real question. Not whether the demo was impressive or not, but whether it survives the contact with your data team, your auditors, and your least technical VP. 

We have the answer. And here's the honest, mechanism-level answer. 

The rollout question is "how", not "whether"

If you own AI at your company, you're past the "should we?" conversation. 

The board has seen ChatGPT; they expect a plan on their desk, not a philosophy.

And there are exactly two ways an AI analytics rollout dies. Loudly – you ship an ungoverned tool, it hallucinates a number into a decision, and trust never recovers. Or quietly – you lock everything down so hard that people go back to pinging the data team, and six months later the licenses lapse unused.

Governed MCP is the narrow path between those two failure modes: answers in everyone's own AI chat, on a data surface one person you already employ fully controls. The rest of this piece walks the chain of control, link by link.

What MCP actually is, in plain terms

MCP – Model Context Protocol – is an open standard introduced by Anthropic that lets an AI chat talk to external systems. 

Three parts: a client (the AI chat you already use – Claude, for instance), a server (the controlled connector in the middle), and a resource (your business data, living where it already lives).

Here's the sentence that matters more than any diagram: MCP defines how an AI connects. It says nothing about what the AI may touch. 

The protocol is a doorway standard, not a security policy. Any vendor can say "we support MCP" – that phrase alone tells you nothing about whether the model will be improvising SQL against your raw tables on the other side of the door.

Governance is a layer you choose to put behind the doorway. Some MCP servers expose your whole schema and let the model explore. A governed one exposes only an authored, audited surface. Same protocol, opposite risk profiles. (If you want the hands-on version first, here's how connecting BigQuery data to Claude via MCP works – then come back for the control story.)

The analyst defines the surface: data marts and joins

Link one in the chain of control: nothing is discoverable, everything is authored.

Your data analyst publishes governed data marts – named, documented datasets with the metric definitions and quality checks they wrote – and, critically, the joins between them. Which tables relate, on which keys, with which business logic: authored by a human who knows that `campaign` in one table and `campaign` in another are different animals. That's data mart architecture doing what it was always meant to do: turning tribal knowledge into an explicit, reviewable artifact.

The AI's entire world is this surface. Not your warehouse, not your raw events, not the tables someone forgot to clean up in 2023. If the analyst didn't publish it, it does not exist for the model.

‍

The LLM only reads what's allowed

Link two, and the one that kills hallucinated numbers: the model never writes SQL.

When a question comes in, the LLM composes a structured request from governed building blocks – this data mart, these dimensions, this date range, these analyst-authored joins. Deterministic SQL your analyst already approved computes the result. The model narrates it and draws the chart.

Walk through one request to see the division of labor. A CMO types: "Show me ROAS by channel for Q2, and flag anything that dropped versus Q1." The model's job is interpretation: it maps "ROAS by channel" to the marketing performance data mart, "Q2 vs Q1" to two date ranges, "flag drops" to a comparison it will narrate. What it assembles is a structured query against named, governed objects – closer to filling in a form than writing code. The SQL that actually runs was written by the analyst weeks ago, reviewed, and attached to that data mart. The model chose which approved question to ask, not how to compute the answer. To be precise, because precision is the whole point: the AI can still phrase a sentence imperfectly – what it cannot do is invent a join, guess a column's meaning, or fabricate a figure, because it never touches the arithmetic. That's the difference between this and the "chat with your data" tools that generate SQL on the fly.

And when someone asks something outside the governed surface? The request fails, explicitly: "I don't have that data." A loud no instead of a plausible lie. Your analyst sees the gap and decides whether to publish the next data mart. The system's failure mode is a feature request, not an incident.

Run History: every query, logged

Link three: verification, not trust.

Every request the AI executes – who asked, which data mart it read, what SQL ran, when – lands in Run History. Including the requests that were denied. Your data person doesn't have to believe the AI behaved; they can open the log and check, the same way they'd review a colleague's pull request. That's data governance as a daily practice instead of a policy PDF.

For the AI lead, this log is your compliance story written automatically: when someone upstream asks "what exactly can the AI see, and what has it done?" you answer with a screen, not a promise. Auditors like screens.

‍

One click for everyone else

Link four, and the one that decides adoption: for everyone who isn't the analyst, the entire setup is one OAuth click.

A business user opens the AI chat they already use, connects with their work account, and asks their question in plain language. No SQL, no BI training, no new tab to remember. This is where every previous generation of self-service analytics quietly failed – it demanded people come to a new tool. Governed MCP goes to where they already are.

The adoption math follows: the rollout you're accountable for doesn't stall on training sessions, and the data team's queue shrinks without hiring. The whole org gets a Senior-Analyst-shaped capability; your one data person gets leverage instead of a longer backlog.

One more adoption detail that matters in practice: nobody has to know the governance exists. The CMO asking about ROAS doesn't see data marts, joins, or quality checks – she sees an answer with a chart in the chat she already had open. The entire control apparatus from the previous three sections is invisible at the point of use. That's the standard the rollout should be judged by: maximum governance underneath, zero governance friction on top.

The boring hero of the five-minute story

I've told the story of the CEO of a US ecommerce brand who fired his weekly report after pulling ten years' worth of answers in five minutes, in his own chat.

Here's the part of that story nobody claps for: the reason he could act on those answers was invisible in the demo. Under every five-minute answer was a join his analyst had authored, a metric his analyst had defined, a quality check his analyst had put in place. The magic on the screen was governance doing its job quietly underneath. When he compared connections side by side, the ungoverned one produced a plausibly wrong figure – and got disconnected mid-call. The governed one had a boring explanation for every number. Boring won.

The proof is a set of screens, not a set of promises

At MOF depth you shouldn't accept adjectives – ask to see the surfaces where governance physically lives. There are three.

Quality checks on data marts – the analyst's rules run against the data before any answer is built on it, catching the quality issues that silently corrupt reporting. The visual model canvas – the map of data marts, joins, and definitions; we ship a free standalone version at model.owox.com, no signup wall, because the authoring craft matters beyond our product. Run History – the audit trail you just saw. Ask any vendor in this category to show you their equivalent of these three screens. The length of the pause is your answer.

"I'll lose control" – the objection, taken seriously

Your data person's pushback deserves a mechanism-level answer, because at first glance "everyone can query data through AI" sounds like the end of their control. It's the opposite, and here's the precise accounting:

‍

Before governed MCP, the analyst's control was implicit – it lived in their head, and every report request queued through them. After, it's explicit: an authored surface plus an audit log, while the answering happens without them in the loop. Control went up; the bottleneck went away. That's the gatekeeper role, and it's a promotion, not a demotion. If your team is comparing this against AI analytics tools generally, make "who authors the SQL" the first row of your matrix.

The one-week rollout recipe

You don't pilot this with a committee. One analyst, one governed data mart, one MCP connection, one real executive question – that's a week, not a quarter, because there's no semantic-layer project standing between you and the first answer.

Then let the chain of control do the selling: the exec gets an answer they can act on; the analyst opens Run History and sees exactly what happened; the next data mart gets published because someone asked a question the surface couldn't answer yet. Start free – and start your analyst at model.owox.com. In a governed rollout, they're not the obstacle. They're the architecture.

‍