MCP Solved Who Can Call Your Customer Data. It Didn't Solve What Comes Back.

An agent presents a valid token. Role-based access control confirms it can read account health. The server returns a number: at risk, confidence 0.81.

Every control in the stack worked. Auth passed. Scope was correct. The call was logged.

And the agent now holds a conclusion it has no way to evaluate, from a system that told it nothing about where the conclusion came from.

That gap is the next accountability problem in customer data, and almost nobody is naming it.

The integration question is settled

Model Context Protocol went from an Anthropic proposal in late 2024 to a vendor-neutral standard under the Linux Foundation by the end of 2025. Public figures put it past 97 million monthly SDK downloads and more than 10,000 active production servers in early 2026. OpenAI, Google DeepMind, and Microsoft all ship against it.

Whatever agent your team deploys next year will be able to reach your systems. That question is answered.

The open question is what it gets back.

Every governance answer so far is a permissions answer

Read the current guidance and one pattern repeats. Treat agents as digital deputies. Secure them with OAuth 2.1. Constrain them with role-based access control. Issue scoped, revocable credentials. Log every call. There are academic papers now on what agent interoperability protocols cannot express about governance.

All of it is necessary. All of it describes the request.

Who is calling. What they can reach. Whether the token is still valid. Which tenant they belong to.

Almost nobody is specifying the response.

A permission is not a justification

Go back to the agent holding at risk, confidence 0.81.

It acts. It drafts the outreach, opens the ticket, escalates to the AE, flags the account before the pipeline review. Four actions across three systems, every one permitted, every one logged.

Not one of them checkable afterward, because the reasoning was never in the payload to begin with.

Your audit log will confirm the agent was allowed to do that. It will not tell you whether it should have.

What the human was quietly doing

Hand the same number to a CSM and something happens that never appears in a spec.

They stop.

They scan the last few tickets. They remember the call from two weeks back. They notice the renewal date is close. And in about four seconds, inside their own head, they decide whether the number is believable or whether it’s noise.

Break that pause apart and it’s three checks:

• Provenance. Where did this come from? Which conversation, which ticket, which call?
• Recency. Is it still true? A signal from six weeks ago and a signal from Tuesday are not the same signal, even when they produce the same number.
• Contradiction. Does anything else in this account disagree? The score says at risk and the last three tickets closed clean. One of those is wrong.

A person runs all three from memory and context. An agent has neither. It has the payload, and the payload is the entire world.

In most customer operations, that four-second pause is the last error check in the system. It’s invisible because nobody ever wrote it down. Autonomy removes it.

Fragmentation costs a person ten minutes. It costs an agent the whole basis for the decision.

Support knows one thing. Success knows another. Sales remembers the promise that got made on the call. Every piece exists, scattered across the help desk, the CRM, and the call recordings. This is the fragmentation problem, and it was always the real problem.

For a person, that scatter is friction. They ping a colleague. They open a second tab. They assemble the picture badly and late, but they assemble it.

An agent can’t ping a colleague. Whatever isn’t in front of it doesn’t exist, and nothing in the response says anything was missing.

The failure mode is a diligent agent, not a rogue one

The worry people voice is that an agent might do the wrong thing.

The likelier problem is an agent doing exactly the right thing with the wrong input, faster than a person would and every time, while every downstream system treats the result as deliberate.

Receipts, not verdicts

The standard we hold for human readers is three words: show me where. Every signal links back to its source conversation and its timestamp. Not a score, but the moment the account changed and the sentence it changed in.

We built traceable evidence for people. A machine reader needs it more, and for a harder reason.

A person can act on a verdict and audit it later. An agent that acts on a verdict has no later. The action is taken, the reasoning was never captured, and reconstructing why it happened means guessing.

Evidence with receipts changes what an agent is able to do:

• It can weigh a signal instead of accepting it.
• It can cite the source in whatever it produces, so the person reading the output can check the work instead of trusting the machine.
• It can decline to act when the evidence underneath is thin.

That last one is the behavior a bare verdict makes impossible, and it’s the one worth the most.

What this looks like in the product

Our MCP server is live.

An agent connects with a personal access token, scoped to the person who created it and to their tenant and role, and queries the same customer evidence layer the product has always exposed to people. It can ask a question in plain language, get account health, list at-risk accounts, pull the evidence behind a signal, or get a coaching summary.

The tool list isn’t the point. The point is that account health doesn’t come back as a number. It comes back with the conversations underneath it, each one carrying its source and its timestamp, so the agent holding the answer can also show you how it got there.

Nothing about the evidence layer changed to make this work. It already refused to hand people conclusions they couldn’t follow. Agents are the second reader, and they were always going to be the stricter one.

Access is rolling out by plan while we work through which tiers get it.

The question to ask your vendors

When you evaluate anything that will sit between an agent and your customer data, the permissions questions are the easy half. Every serious vendor will have an OAuth and RBAC answer ready.

Ask the other half.

When my agent calls you and gets an answer, what comes back with it? Can it tell where the answer came from? Can it tell how old it is? Can it explain, in its own output, why it did what it did?

If the answer is a number and a confidence interval, you haven’t bought governance. You’ve bought a permission slip.