Why can't I see my ERP agent's permissions in Entra?

Because it is not a misconfiguration. Microsoft's documentation says that today, the MCP (Model Context Protocol — the open standard that connects AI agents to data and business logic) path sits outside the connector-permission model.

That is current scope, not stated design intent, and the distinction matters if you are writing it into a control narrative. Until you know it, you are looking at an empty permission list in Entra and drawing the wrong conclusion from it.

6 minute read.

**Dynamics 365 ERP MCP server (dynamic)** — Status: [GA] · Date: 27 January 2026 · Why it matters here: The path this article is about
**Static Dynamics 365 ERP MCP server** — Status: [DEPR] · Date: retired 1 October 2026 · Why it matters here: A different server — do not reason from it
**Microsoft Entra Agent ID** — Status: [GA] · Date: rolled out July 2026 · Why it matters here: New agents get one; opting out is no longer available
**Immersive Home** — Status: [GA] · Date: 13 March 2026 · Why it matters here: Where agent activity is observed, not controlled
**Connector endpoint filtering** — Status: [PP] · Date: preview · Why it matters here: Not the MCP control — a named list of connectors only

What the agent identity does give you

Copilot Studio creates a Microsoft Entra Agent ID [GA] for each new agent.

Connector permissions and data loss prevention (DLP — the tenant policy that classifies which connectors an agent may use) then scope to that agent rather than to a shared app registration.

Agents created before the July 2026 rollout continue on app registrations, and Microsoft says they will be migrated to Agent IDs in the future.

When you publish an agent, Copilot Studio attaches API permissions to that identity representing "the Power Platform connectors the agent is configured to use". Microsoft narrows that on the same page: "Today, this behavior applies to first-party and certified Power Platform connectors."

Then there is the limit a CISO should know before building a review step on it. Scope visibility in Entra applies to all agents. Scope enforcement at runtime — "including Microsoft Entra Conditional Access on the agent identity — currently applies only when the agent runs in Microsoft Teams".

An ERP (enterprise resource planning system) agent that is not running in Teams does not have that enforcement. Admins "can see the scopes but Conditional Access on the agent identity isn't yet evaluated for those calls".

The gap, stated precisely

Here is the sentence that explains your empty list, from Microsoft's app registration and agent identities article:

Today, this behavior applies to first-party and certified Power Platform connectors; custom

connectors, MCP servers, and REST API tools added to agents don't add API permissions to the

Entra Agent ID.

Read the first word. That is Microsoft describing current scope, not a stated design decision — so build the review around the documented behaviour and re-read the page at the next release wave.

So an agent whose only ERP access is the Dynamics 365 ERP MCP server [GA] carries no connector API permissions on its Entra identity. The identity is still there — with its sponsor, its sign-in logs and its lifecycle in the Entra admin centre.

The permission view is not wrong and nothing failed. That view describes connector permissions, and the MCP path is not a connector.

Where MCP governance actually runs: connector classification, not endpoint rules. In a data policy you classify each Copilot Studio connector as Business, Non-business or Blocked.

Microsoft's note on that page is the one that does the work here: "Blocking Power Platform connectors also blocks access to tools in connected MCP servers, which rely on Power Platform connectors for connectivity."

If you were told the control is endpoint allow and deny rules, that is a different feature. Connector endpoint filtering [PP] is in preview.

Microsoft describes it as "exclusively available" for a named list — HTTP, SQL Server, Azure Blob Storage, SMTP and four others. Custom connectors are not on that list, and it is not the MCP control.

So where does the control actually live

Three places, and it is worth being able to recite them.

**The data policy on the connector — Where it lives: Power Platform admin center → Security → Data and privacy → Data policy** · What it decides: Whether the agent reaches the MCP server's tools at all
**Allowed MCP clients — Where it lives: The Allowed MCP clients** page in your finance and operations environment · What it decides: Which agent platforms may call the server, by registered client ID
**Security roles on the agent's identity** — Where it lives: The ERP, on the identity the agent authenticates as · What it decides: What the agent can see, read, change or invoke

Microsoft publishes that data-policy path on the data policies article.

It publishes no navigation path for Allowed MCP clients. The MCP article names the page and the step — add the registered client ID, set Allowed to true — and nothing more. If a path is quoted at you, ask which page it came from.

One policy decides whether the tools are reachable, one grid decides who may knock, and the roles decide what they find inside. None of the three appears in the Entra connector-permission view, which is why a reviewer who looks only there concludes — reasonably and incorrectly — that the agent has no ERP access.

There is also a place to look afterwards, and it is observation rather than control. In Immersive Home [GA] the View activity button opens a tracing list of agent activities and View agents opens a repository of the agents currently running.

Tenant-wide, the same agents appear in Power Platform inventory, readable from the admin center, the Power Platform API or Azure Resource Graph.

One thing we have not verified. Whether individual MCP tool calls land in the F&O (Finance and Operations) audit trail as distinct, attributable entries is not stated on any Microsoft page read for this article. If that matters to your controls, test it in a sandbox before you commit.

What this does to a review process

A review that visits one surface will pass an agent it should have questioned. The process has to visit four:

Entra — does this agent have its own identity, and what does its API permission list show? Expect it to be empty for a pure MCP agent. That is the expected result, not the finding.
The data policy in Power Platform admin center — how is the connector the MCP server's tools ride on classified? Business, Non-business or Blocked is the switch that decides whether those tools are reachable at all.
The Allowed MCP clients page in the ERP — is the calling platform on it, and can anyone say why each other row is there?
The security roles on the identity the agent authenticates as — this is the one that answers "what can it reach?", and it sits furthest from where a cloud security team normally looks.

Step four is the structural weak point: the control lives in an ERP form owned by a different team from the one running the review. That organisational seam is the real risk here, more than any technical gap.

The counter-argument

"If MCP tools bypass the connector-permission model, then the MCP path is less governed than the connector path. Use connectors."

Less visible in one particular console, not less governed — and the data policy still applies on both paths. On the connector path, reach is the union of permissions granted to each connector, and reasoning about it means reading several permission sets and inferring what the combination allows.

On the MCP path, reach is set by the security roles assigned in the ERP to the identity the agent authenticates as. Microsoft is direct about the shape: the agent "works with the application like a human with the same security access would perform the actions".

Read the roles, not "the role" — plural. Microsoft's System agent role, which exempts an agent identity from finance and operations user licensing, "provides no permissions and has no duties or privileges assigned to it"; the guidance is to "assign other security roles" for what the agent does.

That is why "it has a role" is not an answer. The context is rebuilt with each tool call, and Microsoft states the system "rejects any explicit calls to actions or objects to which the user role doesn't have access".

The ERP role model is the one your organisation already knows how to read — a reviewer who can read a role assignment for a person can read it for an agent. The problem is not the strength of the control. It is that the control moved to a form most cloud security teams have never opened.

What to do this week

Open your agent in the Entra admin centre and look at its API permissions. If the list is empty and the agent talks to the ERP through MCP, you have confirmed the documented behaviour rather than found a problem.
In Power Platform admin center, go to Security → Data and privacy → Data policy and find how the connector your MCP server's tools ride on is classified.
Ask your finance and operations team to open the Allowed MCP clients page and read every row with you.
Write the four-surface check into whatever review template your organisation uses for a new integration. That is the durable fix; the other three are one-off checks.

Where we would draw the line

We would not sign off an agent whose control surfaces cannot all be named in a review. The failure here is not a missing control but an unread one.

We would not let a security review conclude at the Entra console for an MCP-based agent. That console answers a different question well and this one not at all.

And we would not describe the MCP path as ungoverned to a CISO. It is not true, and it argues for the weaker architecture. Dynamics stays the system of record for what the agent may reach — the role assignment is that record, and it is readable.

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 your security review is stalling on an ERP agent, book a 15-minute call and we will walk the four surfaces with you. https://cognilium.ai

Why can't I see my ERP agent's permissions in Entra?