Dynamics 365 ERP Agent RBAC: Microsoft Plans Narrower AI Permissions for Finance and Operations

Put simply, Microsoft is planning a separate, smaller set of permissions for agent work.

What the roadmap entry says​

According to the roadmap description, Dynamics 365 ERP security administrators will be able to:

• Add agent-only restrictions on top of a user's normal access. These restrictions take effect only for agent-initiated requests.
• Build them with the existing security model. Administrators assign roles, duties and privileges, so there is no new permission language to learn.
• Limit them by legal entity, so an agent session can be confined to particular companies in a multi-entity deployment.
• Give the agent session less access than the same user has when working directly in the ERP.

The roadmap metadata shows these details:

Treat these dates as estimates. Microsoft's roadmap page says its dates are estimated, that all information may change, and that entries can be removed once a feature ships, is canceled or is postponed. The entry also doesn't say whether the October and December targets apply equally to all three clouds. GCC High administrators have seen that question go both ways before.

Section summary: This is a planned feature that is still in development. It would let administrators give agent sessions their own narrower permissions using the familiar roles, duties and privileges, limited by legal entity.

Why this matters: how agent access works today​

The current Model Context Protocol (MCP) documentation shows the problem this item addresses. Microsoft Learn says the Dynamics 365 ERP MCP server lets developers build agents that work with data and perform nearly any function that's available to a user through the application interface, without the need for custom code, connectors, or APIs.

That is very capable. Access control in the current model is just as direct. Microsoft's guidance on building agents in Copilot Studio says adding the MCP server gives the agent all of the server's tools, and that this access includes data and business logic that matches the agent's security role and environment context. The Microsoft Foundry setup guide follows the same pattern. Administrators register the application and, in the User ID field, select a user that has the appropriate security role for permissions required for your agent to access in Dynamics 365 finance and operations apps. The analytics side works the same way. For the ERP Analytics MCP server, Microsoft states that the security role of the authenticated user determines which data the agent can access.

The practitioner blog D365 FO Advice & Tips stated the risk plainly: by default the agent is not read-only. It can CREATE, UPDATE, and DELETE data in your D365 environment — exactly like a signed-in user. The same blog noted that the agent inherits the security role of the service account connected to the MCP server.

Microsoft has already set some hard limits. The MCP documentation states that the MCP server doesn't provide access to some forms related to system admin tasks, like feature management, user management, and managing security. The excluded forms include security configuration, user role assignment, separation-of-duties configuration and temporary roles. So an agent can't currently give itself a promotion. Outside those forms, though, the agent's reach is roughly the user's reach.

Consider a common example: an accounts payable manager with broad posting and vendor-maintenance rights in five legal entities. That user might want an agent that only reconciles invoices in one entity. Under a simple "the agent gets whatever the user has" model, the agent session carries the manager's full access. The roadmap item would let administrators narrow that session without removing anything from the human user.

Section summary: Agent access today is governed by the security role of the user or account the agent runs as. The roadmap item adds a separate, narrower layer that applies only to agent work.

Built on the familiar roles, duties and privileges model​

Microsoft is building on the existing security model rather than creating a new one. Experienced administrators will know how it works:

• Roles are how users get access. Users are never granted access individually.
• Duties represent parts of a business process and contain privileges.
• Privileges contain permissions to application objects such as menu items, fields and tables.
• Permissions control access to the individual securable objects behind each entry point.

Microsoft's role-based security documentation recommends assigning duties to roles rather than privileges directly, because grouping privileges into duties makes them easier to maintain. It also says segregating duties can help organizations comply with frameworks such as SOX and IFRS, and can reduce fraud risk. Data security policies can already limit a role to data from a single organization, which makes the roadmap's legal-entity scoping a natural extension.

Analysis based on general industry knowledge: Reusing this model gives administrators existing duties to build from and existing segregation-of-duties thinking to apply. A new, separate permission system would have meant learning and auditing a second rulebook alongside the first.

What the roadmap does not say​

The entry is short. Before planning a rollout, note what it leaves out:

• How the restrictions are enforced. It doesn't say whether they apply at the MCP server, in a broader agent framework or somewhere else. It refers only to users accessing the ERP "through an agent."
• Which agents are covered. "Cross-app" shouldn't be read as covering every Dynamics 365 application or every agent route into the ERP.
• How agent and user grants combine. The description says the agent session can be narrower, but doesn't explain how overlapping grants are resolved.
• Setup screens, prerequisites, licensing and audit events. None of these are documented yet. Don't expect existing security reports to show agent restrictions until Microsoft says they will.

Some caution is reasonable. Agent governance is clearly a focus for Microsoft, and the roadmap page itself promotes Agent 365 as a control plane for agents. A narrower permission profile is good practice, but it doesn't make agents safe by default or guarantee compliance on its own terms.

How to prepare before the preview​

These are planning steps based on general industry practice, not a documented setup procedure for this feature:

1. List your current agent connections. For every MCP client on the Allowed MCP Clients page, record which user or account it runs as and what roles that account holds.
2. Map agent tasks to duties. For each workflow you plan to automate, write down the minimum duties and privileges it needs. Those lists will become your agent-restriction sets.
3. Decide the legal-entity limits now. Note which companies each agent workflow actually needs to touch.
4. Check segregation of duties for agent sessions. Make sure the agent's permission set doesn't create combinations you would reject for a human user.
5. Record your baseline with existing reports. The out-of-box security reports under System administration > Inquiries > Security show user role assignments with legal-entity restrictions, effective permissions per role and duty assignments per role. Use them to document your current position.
6. Test in a sandbox. When the preview arrives, test both agent-initiated and direct user activity, and confirm the agent is actually blocked where you expect.

Section summary: Start least-privilege planning for agents now, using the reports and duty structures you already have, so you're ready to test when the preview lands.

The bigger picture​

When the dynamic ERP MCP server arrived, Microsoft promoted it as a way to keep data access, permissions and auditability consistent across agent integrations. ERP Today described the approach as giving agents controlled access under the same security boundaries that govern human users. Identical boundaries for a person and their agent may not be what an organization wants, though. A person can use judgment about when to use broad access. An agent working through many steps on its own has no such instinct. This roadmap item suggests Microsoft accepts that an agent session may need tighter limits than the person behind it.

If the October preview arrives on schedule, Finance and Operations administrators will be able to test that model. Until then, assume any agent can reach everything its connected account can reach, and set up that account accordingly.