On 23 September Microsoft published its agentic ERP roadmap for Dynamics 365, running through March 2027. It is the first substantial roadmap post since release waves gave way to the AI at Work roadmap, and it is worth reading carefully — not for the roadmap, but for the two things in it that are already live.
What actually shipped
The Dynamics 365 ERP MCP server is generally available. So is the Dynamics 365 ERP apps plugin for Copilot Cowork, which reached general availability on 16 June. Copilot Cowork itself is now GA worldwide, with plugins for Fabric, Sales, Customer Service and the ERP apps.
Together they put finance and operations data into the same conversation as mail, documents and spreadsheets. The MCP server exposes three categories of tool, and the distinction between them is the whole article:
- Data tools — read, create, update and delete records in finance and operations data entities.
- Form tools — navigate application pages, set field values and select actions, in Microsoft's words, "just as you would in the application".
- Action tools — invoke custom business logic that your developers choose to expose.
A handful of other things are in public preview now: procurement agent impact analysis, which traces a supplier's proposed purchase order change through to the sales, production and transfer orders it touches; a supplier engagement portal; the Commerce MCP server; and the scheduling operations agent in Field Service.
Most of the rest of the post is roadmap through March 2027. That includes the things an ERP lead would most want: role-based access controls for agents, a Business Skills Framework with its own security role management, HR business skills for Copilot, a candidate assessment agent.
What that changes
It moves the agent from reading your ERP to writing to it.
Microsoft's own documented example is a sourcing manager handing Copilot Cowork a single instruction: evaluate the bids on an RFQ, pull the details out of vendor emails and PDF attachments, update the RFQ replies in finance and operations, score them against the configured criteria, recommend a supplier, and — after approval — create the purchase order and draft the award email.
That is a real day's work compressed into a prompt. It is also four write operations into a production ERP, initiated in a chat window. Microsoft is direct about it: "Copilot Cowork can perform write operations in Dynamics 365... Review your prompts and the agent's proposed actions carefully before proceeding."
What it does not change
Here is the line that decides your exposure, quoted in full because paraphrasing it loses the point:
All data access through Copilot Cowork respects the security roles and privileges assigned to the user in the finance and operations environment. Users can't access data through Copilot Cowork that they can't access through the application.
That is the correct design. An agent that could exceed the permissions of the person driving it would be indefensible. But read it the other way around, because that is the direction the risk runs: the agent is exactly as privileged as the role it inherits. Not more. Also not less.
In a finance and operations estate that has been live for a few years, that is an uncomfortable sentence. Security roles accumulate. Someone moves from procurement to payables and keeps both duties because removing one broke a month end. A role gets widened for a go-live and never narrowed. Segregation of duties is enforced on paper, and a handful of composite roles quietly violate it.
None of that has mattered very much, because a human being with an over-broad role still only opens the three forms they need. Habit was doing a job that permissions were not. An agent has no habits. Ask it to "sort out the vendor record" and it will use everything the role allows, competently and at speed.
Your role design has just been promoted from a compliance artefact to a runtime control, without being redesigned for the job.
Where the work has moved
Into four places, in our experience of the last few weeks.
Into the role and duty audit. Not the annual access review that ticks a box, but a specific question: for every role a user of this plugin holds, what can it create, update and delete? That is the agent's reach, and it is probably wider than anyone has looked at recently.
Into scoping. Action tools only expose the business logic a developer chooses to expose. That is a control, and it is one you own entirely. The same discipline belongs on the entities and processes the agent is pointed at: the ones the process needs, not the whole estate.
Into keeping the write review a control. Copilot Cowork shows a summary of what it plans to write before it commits. That step is worth exactly as much as the attention paid to it. A reviewer approving a well-written summary nine times will approve the tenth without reading it. Decide which writes can be approved in-flight and which have to leave the chat window entirely.
Into the unglamorous prerequisites. The plugin requires finance and operations version 10.0.45 or later with quality updates, and is not supported on Cloud Hosted Environments. Legal entity matters too: Microsoft's guidance is to name the company in the prompt when an environment has several. An agent that silently picks the wrong legal entity is not a security problem, it is a correctness one, and it is harder to spot.
One practical caution
Do not design around the roadmap. Role-based access controls for agents and the Business Skills Framework are listed as coming through March 2027, and Microsoft's own disclaimer on these posts is that timelines and scope can change. Whatever you deploy this quarter has to be governed with the controls that exist this quarter.
There is also a question worth putting to whoever implements this for you, before it goes live rather than after: when an agent uses a form tool to act "just as you would in the application", how does that write appear in the audit trail, and can you tell it apart from the same person doing it by hand? If the answer is vague, that is the answer.
What we would do first
Pick one process where being wrong has a known cost — vendor invoice matching, purchase order creation, a sourcing workflow. Audit the roles behind it properly. Scope the entities and action tools to that process alone. Then run it for four weeks on production data, with the write reviews logged and read, and agree in writing beforehand what a good outcome looks like.
The tooling is ready. It became ready faster than most role structures did, and that gap is the whole project.
If the answer at the end of four weeks is no, that is still the answer.