Agent-Only Security Roles Reach Dynamics 365 F&O: RBAC for ERP Agents Enters Preview in October 2026

TL;DR

Microsoft published roadmap item 571677 on 30 September 2026: role-based access controls for ERP agents in Dynamics 365 finance and operations apps. Security administrators will be able to apply agent-specific roles, duties and privileges that take effect only when a user reaches the ERP through an agent, scoped by legal entity. Status is in development, with preview dated October 2026 and general availability December 2026, across the worldwide, GCC and GCC High clouds. It closes the single largest control gap in agentic ERP: an agent session has, until now, carried the full permissions of the user it runs as.

What Microsoft published

The roadmap entry is short and specific. Dynamics 365 ERP security administrators can apply additional, agent-specific security restrictions that take effect when a user accesses the ERP through an agent. The limits are set with the existing security model, using roles, duties and privileges that apply only to agent-initiated requests, and they are scoped by legal entity. An agent session can therefore have narrower permissions than the same user has when working directly in the client.

That last sentence is the whole change. The item carries no new concepts: no agent identity type, no separate permission store, no new administration surface beyond the security configuration forms administrators already use. It reuses the role, duty and privilege hierarchy and adds a second answer to one question: what may this user do when an agent is acting for them.

Why the gap existed

Microsoft's documentation for the Dynamics 365 ERP MCP server is explicit about how permissions work today. The server returns the same application view model a user would see, filtered by the security role of the authenticated user. Menu items, fields, actions, entities and registered code actions outside that role are not returned, and explicit calls to them are rejected. The design is sound, and it has one consequence that every security review has raised since the server went to general availability in January 2026: whatever the user can do, the agent can do.

A purchasing manager with rights to confirm purchase orders, post product receipts and release payment holds hands all three to any agent that runs under their account. The agent does not need all three to chase a receipt. There was no supported way to give it only the one it needed, short of creating a second user with a narrower role, which breaks the audit trail Microsoft's own model relies on, because the action is then recorded against a service account rather than the person who asked for it.

Microsoft's September roadmap post named the fix without a date: new capabilities would let organisations add restrictions when users work through Copilot Cowork or agents. Item 571677 is that capability, with the dates attached.

What it does not do

Three things are worth being precise about, because the roadmap entry will be read as more than it is.

It does not design your roles. The administrator still has to decide which duties an agent may carry in each legal entity, and that decision is the governance work, not the feature. An agent-only role that mirrors the user's full role changes nothing.

It does not add approval before posting. Agent-only roles bound what an agent can reach. They do not insert a person between the agent and the ledger. Approval before posting is a property of the agent's own design and of the workflow around it, and it remains the control an auditor asks about first. The two belong together: a narrow role limits the blast radius, an approval gate limits the action.

It does not apply to Business Central. Business Central agents already run under a permission set and a profile the administrator assigns to the agent itself, separate from any user, which Microsoft documents for the Payables Agent and the Sales Order Agent. Finance and Supply Chain Management is catching up to a model its sibling product shipped with.

It also does not reach into customized code on its own. Logic a developer has exposed as an Action tool through the ICustomAPI interface is secured on its menu item, the same way it is today. Agent-only duties can include or exclude that menu item, but the menu item has to exist and be secured first.

What to do in October

The preview window is the time to design the roles, not December. Four steps fit the month.

• Inventory every agent that touches Finance or Supply Chain Management, first-party and custom, with the user account and the legal entities each one runs in.
• For each agent, write the duties it needs as a list that is shorter than the user's role. If the list is not shorter, the agent is doing the user's job, not a task.
• Define the agent-only roles per legal entity in a sandbox during the preview, and run the agents against them. The rejected calls are the finding: either the role is too narrow or the agent was doing something nobody signed off.
• Keep the approval gate. Agent-only roles arrive alongside the static MCP server retirement on 1 October 2026 and the Allowed MCP Clients list, and together they are the control architecture Microsoft now expects an estate to have before agents go live.

General availability in December lands inside most organisations' year-end freeze. An estate that has designed its roles in the preview can switch them on in January without re-opening the security review.

Our read

Agent-only roles are the first first-party control that lets a Dynamics 365 security administrator say what an agent may touch, independently of the person it works for. That is the governance gap we have been telling F&O estates to close before turning agents on, and Microsoft has now given it a native form. The design decision still sits with you: which duties, which legal entities, and where a person approves before anything posts. The feature supplies the enforcement. The approval boundary, the audit trail and the last mile into customized code remain engineering, which is why the PO Receipt Chase Agent shows the exact receipt and waits for a yes before it posts anything, whatever role it runs under.

The roadmap item now sits in the Dynamics 365 agent catalog with every first-party and partner agent it will govern, each with Microsoft's own status label and source. We will move its row when the preview ships and again at general availability.