Article
yesterday
Putting Copilot Agents into Production in Dynamics 365: Security Roles, Data Boundaries, and the Day-2 Work Nobody Demos
The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a…
The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a chat pane, and the AI agent finds the item, picks the vendor, fills the form, and submits the workflow. But three weeks later, that agent is in production, and the questions start: Why can this thing see payroll? Who approved it, touching the ledger? It just edited a record nobody asked it to; was that allowed?
I've now deployed enough Copilot agents for Dynamics 365 Finance & Operations to say the quiet part out loud. Building the agent is only 20% of the journey. The remaining 80%, which entails deploying, governing, monitoring, and running it safely at scale, is where the real complexity begins. This article is about the 80%.
The Demo Problem
Demos optimize for the happy path. A scripted prompt, clean data, one user, no edge cases, and a presenter who knows exactly what the agent will do because they rehearsed it. Production is the opposite of all of that. You get prompts nobody anticipated, users with wildly different permissions, dirty data, and an agent that's now allowed to act, not just answer.
The business challenge isn't "can the agent do the task?" It demonstrably can. The challenge is ownership: who is accountable for what the agent is permitted to see and do, who watches it, who gets paged when it misbehaves, and who can prove to an auditor that it stayed inside its lane. That's an operations discipline, and it's one most teams haven't built yet because the technology only made autonomous action practical very recently.
What Actually Changed
If you wired an agent to F&O over the last year, you probably used the static Dynamics 365 ERP MCP server, a fixed set of 13 tools built on the Dataverse connector framework. It worked, but it was rigid, and Microsoft is retiring it during the 2026 calendar year. The replacement, the “dynamic” Dynamics 365 ERP MCP server, went generally available in February 2026.
Instead of a frozen tool list, it exposes living tool categories: data tools for create/read/update/delete against entities, action tools that invoke business logic, and metadata tools the agent uses to discover your schema, including custom entities and extensions. Per Microsoft's documentation, this surfaces hundreds of thousands of ERP operations across tens of thousands of forms, without a custom connector or bespoke API. The data tools also moved off chatty form-level interactions toward direct, optimized entity operations, which is why agent responses got both faster and more reliable.
Here's the line from Microsoft Learn that matters more than any of that: when you add the MCP server to an agent, it gets access to data and business logic that matches the agent's security role and environment context. This means it gets exactly the permissions you assign it, no more, no less.
The Security Role is the Whole Ballgame
Treat the agent like a new employee on day o…
