Can an AI agent in Dynamics 365 give itself more…

Can an AI agent in Dynamics 365 give itself more permissions?

No — not through the administration forms, and not to anything its security role does not already reach. The reason that answer is worth reading is that it comes as a list of form names you can check, rather than an assurance you have to trust.

It is the question that decides whether an agentic ERP (enterprise resource planning — the system that runs finance, supply chain and operations) deployment clears security review, and the CISO (chief information security officer) asking it deserves a concrete answer rather than a posture.

7 minute read.

The short version, then the mechanism

The Dynamics 365 ERP MCP server — MCP is the Model Context Protocol, the open standard that lets an AI agent discover and call functions exposed by another system — reached general availability on 27 January 2026 [GA].

It excludes the system-administration forms an agent would have to reach to widen its own access. It has no route through those forms to add itself to a security role, edit the security configuration, create or alter users, register a Microsoft Entra ID application (Entra ID is Microsoft's cloud identity directory), or switch features on.

That is a design decision with a published artefact behind it, which is a far better security answer than a statement of intent.

How scoping works before we get to the exclusions

The server re-derives the agent's context on every tool call. Microsoft's wording: the server "dynamically updates the context it provides to the agent with each tool call based on the agent's security permissions and application configuration, extensions, and personalization".

`form_find_menu_item` — Returns only menu items the role can access
The form view model returned — Contains only the data, fields and actions the role can access
`data_find_entity_type` — Returns only entities the role can access
`api_find_actions` — Returns only APIs the role can access
Any explicit call to an out-of-role object — Rejected by the system

Read the last row carefully, because it closes the obvious hole. An agent that somehow learns the name of an object it cannot see does not gain anything by naming it. Discovery is filtered and direct access is refused.

Microsoft's stated reason for narrow roles is worth quoting to a sceptical architect, because it is a security argument and a performance argument in the same breath:

Limiting the menu items, entities, and APIs by using roles is important for limiting the scope of

the agent. It also improves agent orchestration by limiting the context the agent needs to

orchestrate over to find the right form, data, or actions.

A narrower role gives the model a smaller candidate space. Smaller space, better tool selection, fewer calls, lower bill. Security, accuracy and cost move in the same direction, which almost never happens and is the single most useful thing to say in a design meeting.

The forms that are excluded by design

This is the answer you hand to a security architect. Microsoft's own framing is that the server "doesn't provide access to some forms related to system admin tasks, like feature management, user management, and managing security" — and then publishes the list.

Security — Form label: Security configuration · Form name: SysSecConfiguration
Security — Form label: User role assignment · Form name: SysSecUserAddRoles
Security — Form label: Separation of duties config · Form name: SysSecSegrationOfDuties
Security — Form label: Temporary roles · Form name: UserSecGovTemporaryRole, UserSecGovTemporaryRoleAddRoles, UserSecGovTemporaryRoleAssignOrg, UserSecGovTemporaryRoleUser
Security — Form label: Privileged access control · Form name: UserSecGovPrivilegedUserManagement, UserSec
User setup — Form label: Users · Form name: SysUserInfoPage
User setup — Form label: User groups · Form name: SysUserGroupInfo
Integrations — Form label: Microsoft Entra ID applications · Form name: SysAADClientTable
Features — Form label: Feature Management · Form name: FeatureManagementWorkspace

What this list covers, and what it does not. These are forms — the pages a user works in. The server also exposes data tools (record create, read, update and delete through data entities) and action tools (X++ classes a developer has published; X++ is the programming language of finance and operations apps). The exclusion list does not touch either family.

Those two families are governed by the role, not by the list. Microsoft is explicit that the server arrives whole: "When you add the MCP server to your agent, you give the agent access to all the tools available on the server. This access includes data and business logic that matches the agent's security role and environment context."

Each exclusion closes a specific route. Without SysSecUserAddRoles and SysSecConfiguration, an agent has no form on which to grant itself a role or edit what a role means. Without SysUserInfoPage, it has none on which to create a second identity to act through.

Without SysAADClientTable, it cannot register a new application there to reach the ERP from somewhere less supervised. Without FeatureManagementWorkspace, it has no form on which to switch on the capability it was denied.

Separation of duties deserves its own line. Excluding that form closes the route an agent would use to quietly dismantle the control that stops one identity holding two conflicting privileges — which is the control your auditor actually cares about.

The part these exclusions do not cover, and it is the bigger risk

The exclusions stop escalation. They do nothing about over-permission.

If you assign an agent identity a broad role on day one, every capability inside that role is legitimately available to it, and no exclusion list will help. The agent does not need to escalate because it was born with too much. That is not a platform gap; it is the design decision the platform hands to you.

So the security question is never "can it escalate?" — that answer is published. The question is: what is the name of the role you gave it, and can you read what that role contains in one sitting?

Microsoft's illustration of the role filter uses a Purchasing Agent security role: an agent assigned to it "only has access to the objects assigned to the duties and privileges for that security role". That is Microsoft stating a mechanism. The preference is ours: build the role for the agent, never hand it one that was built for a person.

We build optimization apps that sit beside Dynamics rather than inside it, and the security role is the first artefact we design — the role is the app's API surface, and scoping it takes someone who reads finance and operations (F&O) security and model behaviour equally well. Dynamics stays the system of record; the app optimizes one decision — the safety-stock level, the pick path, the price — and reaches nothing else.

The second control, and it is one grid

Alongside the role sits the **Allowed MCP clients** form in your finance and operations environment. It is the allow-list of the Microsoft Entra application (client) IDs permitted to call the server at all.

Microsoft publishes the default client list on that page. Adding another platform means registering its application in Microsoft Entra ID and adding its client ID here with the Allowed property set to `true` — a step it is easy to complete three-quarters of and believe you are done.

One grid, and it is where client-side governance for agentic ERP access is configured. A security review that does not start by reading it is starting somewhere less useful.

One honest gap. Microsoft's launch blog claims each function "inherits ERP's existing controls for permissions, auditing, and security". That is a vendor blog, not the documentation, and the documentation does not carry it.

What we have not found on any Microsoft page is whether individual MCP tool calls land in the F&O database log as distinct, attributable entries — separately from the agent activity trace in Immersive Home [GA] (generally available 13 March 2026), whose View activity button Microsoft describes as opening "a holistic tracing list of all agent activities".

If your control depends on per-call audit evidence, treat that as an open question to test in a sandbox rather than an assurance to rely on. We would rather flag it than let you assume it.

The counter-argument

"A list of blocked forms is a denylist. Denylists are the weakest form of control, because the list is only as good as the imagination of whoever wrote it."

That is a fair objection and it would be decisive if the exclusion list were the only control. It is not. The primary control is the allow-list built into the role filter: the agent sees only what the role permits, and Microsoft states that the system rejects explicit calls to anything else.

The excluded forms are a second layer, closing the specific paths that would let an identity change its own allow-list.

Layered that way round, the denylist criticism loses most of its force. It would regain it if Microsoft shipped a new administration surface and forgot to exclude it — which is exactly why the role, not the exclusion list, should be the control you actually depend on.

What to do this week

Open the **Allowed MCP clients** page in your finance and operations environment and read every row. If you cannot say why each entry is there, that is your finding.
For every agent identity you have, write down the security role it holds and open that role. If reading it takes more than a few minutes, it is too broad to reason about.
Ask whoever owns your audit controls whether they need per-call evidence of agent activity. If yes, test it in a sandbox before it becomes a commitment — see the open question above.

Where we would draw the line

We would not deploy an agent whose reachable surface cannot be named in a sentence. We would not reuse an existing human role because it happens to have the right access — human roles accumulate permissions for reasons nobody remembers, and inheriting that history is how an agent ends up with access no one intended.

And we would not present the excluded-forms list to a CISO as the security design. It is the answer to one question; the role is the answer to the rest.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are designing the security role for an ERP agent now, we will review it with you on a call — the reachable surface, the write path and the audit question. https://cognilium.ai

Can an AI agent in Dynamics 365 give itself more permissions?