Read the Dataverse MCP Server announcement as a feature and you miss the point. Read it as a warning and it snaps into focus.
Microsoft is telling you, politely, that the contract you define decides whether an AI agent acts safely inside your system of record. Not the platform. You.
That contract has a name in the Model Context Protocol world. It's the tool shape. And it's the most important governance decision you'll make this year that nobody scheduled a meeting about.
What actually changed
Before MCP, an agent reaching Dataverse meant composing queries. FetchXML, SQL, whatever it could assemble from natural language. You were trusting an LLM to author the access pattern, and then trusting your security layer to catch whatever it got wrong.
The Model Context Protocol flips that. Each capability becomes a self-describing tool: a name, a description, a typed inputSchema, a structured result, and behavioral annotations that mark whether the action is read-only or destructive.
The agent no longer writes arbitrary queries. It invokes vetted, schema-bound actions. Metadata discovery, record read, CRUD, prompt and knowledge tools.
This narrows the error surface and the attack surface at the same time. But only if the tools are shaped tightly. A loosely shaped tool gives back everything you just took away.
MCP is Anthropic's open protocol, not a Microsoft invention. That choice is the whole strategy, and we'll come back to it. The short version: the agent UI is being commoditized, the data plane is not.
Tool shape is the first line, not the last
Here is the trap, and it's the one most teams will walk into.
People hear "schema-bound, governed tools" and assume the tool definition is the security boundary. It isn't. Tool shape is a first-line control. It shapes intent and narrows the surface. It is not the authoritative enforcement floor.
The real floor is still Dataverse. Security roles. Row-level security. Column-level security through Field Security Profiles. That machinery has guarded your data for years and it does not stop being the enforcement layer just because an agent is the caller.
But it only works under one condition: the agent has to run in the invoking user's delegated context.
That's the whole game in one sentence.
When the call carries the user's identity, row-level and column-level security travel with it. The agent sees exactly what that human would see. When the call runs under a broadly permissioned service principal instead, every per-user control evaporates. The agent sees everything the app registration can see, which is usually far too much.
Now combine the two failure modes:
- A broadly shaped tool ("execute any query")
- Running under a generously permissioned service principal
That collapses both layers at once. You've handed an LLM the keys to your system of record, and neither tool shape nor Dataverse security is standing in the way. This is the dominant failure mode, and it will not show up in a demo. It shows up six weeks later in an audit.
| Layer | What it enforces | What collapses it |
|---|---|---|
| Tool shape (MCP contract) | What an agent can request; typed inputs; read-only vs destructive intent | A generic query-passthrough tool that accepts arbitrary operations |
| Dataverse security (roles, RLS, CLS) | What a given identity may read or write at row and column granularity | Running under a service principal instead of delegated user context |
| Both together | Defense in depth: narrow intent enforced against per-user permissions | Broad tool + over-permissioned app user. Both fail simultaneously |
Stop trusting the prompt
A predictable instinct is to write the guardrails into natural language. "Only return records the user owns." "Never delete." "Refuse sensitive columns."
Don't. Prompt-level instructions are guidance, not enforcement. They are bypassable by construction, and treating them as a control is how you end up explaining an incident to people who don't care about your system prompt.
Two things are trustworthy: schema-level constraints in the tool shape, and Dataverse-level enforcement under delegated identity. Everything else is a suggestion.
The takeaway is blunt. If a control can be talked out of, it isn't a control.
The new risk class nobody budgeted for
MCP introduces a supply chain. Tools have definitions, definitions have metadata, and metadata flows into the model's context. That opens a category of attack that most Dataverse teams have never had to model.
- Tool poisoning. A malicious or careless tool definition shapes agent behavior in ways the author didn't intend.
-
Prompt injection through tool metadata. The
descriptionfield is not decoration. It's read by the model, and hostile content there can redirect behavior. - Confused deputy. The agent, holding more authority than the request deserves, gets tricked into using it on someone else's behalf.
Treat every tool definition and every input as untrusted. The same way you'd treat a public API endpoint that anyone on the internet can call, because functionally that's closer to the truth than it feels.
The competitive read
Here's the part that makes this strategic rather than just operational.
Microsoft could have built a Copilot-only walled garden. They didn't. They standardized on an open protocol, which means OpenAI, Claude, and your custom agents can all reach Dataverse through the same door.
That looks like giving something away. It isn't. It moves lock-in upward.
The agent and model layer becomes interchangeable, a commodity. The value-accruing assets stay exactly where Microsoft wants them: the tables, the business logic, Entra for identity, Purview for governance. Commoditize the agent UI, own the data plane.
If you're making platform bets, that's the signal. Don't over-invest in any single agent runtime. Invest in the substrate that every agent has to come through. Identity and governed data outlast whichever model is winning this quarter.
What actually breaks when you turn it on
The hard work was never enabling the server. That's a switch.
The hard work is that almost no organization designed its schema or its security model for agent consumption. Your tables assumed a human in a form with a security role. Now the caller is a tireless, fast, occasionally hallucinating process that will invoke whatever you expose.
So the real project is a decision, table by table and action by action: which of these should ever be agent-callable? Most of them shouldn't be, at least not yet, and certainly not for writes.
The first five moves
Do these in order. Each one assumes the previous is in place.
Where this leaves you
The Dataverse MCP Server is genuinely good engineering. It also quietly relocates a security boundary into a place most teams aren't looking: the tool contract, and the identity it runs under.
Get the shape tight and the identity delegated, and you get defense in depth that's better than what most orgs run today. Get either wrong, and you've connected a language model directly to your record of truth with the guardrails switched off.
Microsoft told you which one it is. The contract is yours to define.
This surface is evolving fast. Tool catalog names, GA versus preview status, and the precise delegated-versus-service-principal propagation semantics should be checked against current Microsoft Learn documentation before you design against them. The architecture principle holds; the exact knobs are still moving.
This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.
Top comments (0)