Do I need a Dynamics 365 licence for an AI agent's identity?

Do I need a Dynamics 365 licence for an AI agent's identity?

Not for the identity itself, under conditions that are worth stating precisely — and the mechanism is one of the more elegant things in this stack. It also sits directly beside an older pattern that works the opposite way and is still shipping, which is why the question keeps getting different answers.

The rule, stated precisely

Microsoft's sentence carries two qualifiers, and both move a budget line. Verbatim, from Use Model Context Protocol for finance and operations apps:

"Currently, you don't need Dynamics 365 finance and operations user licenses for your agent's identity. While users who interact with a chat-based agent need a user license for the Dynamics 365 application to access the data and business operations of the application, the agent identity doesn't need an additional license. This requirement also applies to autonomous agents without an interactive user, as long as the agent is either built in Microsoft Copilot Studio or accesses Dynamics 365 finance and operations through any of the Dynamics 365 ERP MCP servers."

Currently is Microsoft's word: stated policy today, not a permanent guarantee. And the exemption covers the identity only — every human who chats with that agent still needs their own Dynamics 365 user licence, and that is the headcount a budget actually feels.

The Dynamics 365 ERP MCP server — MCP is the Model Context Protocol, the open standard that connects AI agents to systems like your ERP (enterprise resource planning system) — reached general availability on 27 January 2026 per the release plan. That is [GA]: shipped, supported, safe to plan a go-live against.

What the rule removes is one specific objection — that every scheduled, unattended process would need its own paid seat. It removes nothing else. The interactive users still need licences, and orchestration and tool calls are a separate meter.

The mechanism is a role that deliberately grants nothing

The exemption is not a licensing setting. It is expressed inside the ERP as a security role.

You assign the agent identity the System agent role. That role exists by default, grants no permissions, has no duties and no privileges, and should never have app permissions added to it. Its entire job is to mark the identity as licence-exempt.

Then you assign the real security roles alongside it — the purpose-built ones that define what the agent can actually reach.

Two roles, two jobs. One says this identity is an agent; the other says and here is exactly what it may touch. Keeping them separate is what makes the design readable months later, and it is why adding permissions to the marker role is such a bad idea: it collapses the two statements into one and destroys the only clean signal you have about which identities are agents.

The older pattern, still shipping, works the other way

Set the Expense Agent beside it. Microsoft's setup article labels it plainly — "This is a production-ready preview feature", and "Production-ready previews are subject to supplemental terms of use" (Set up the Expense Agent). That is [PRP]: usable in production, still governed by prerelease terms, and not a thing to sign a go-live date against without reading them. Its agent identity carries a full licence stack.

• Microsoft Entra ID — A dedicated user, Account enabled marked, usage location filled in
• Licences — Dynamics 365 Teams Members, Microsoft 365 Business Basic (or any licence covering Teams and Outlook, e.g. Office 365 E5), Power Apps Premium
• Dataverse roles — Expense AI Agent Role, Finance and operations Agent Configuration Manager, System Customizer
• Finance and operations roles — ExpenseAgentRole — Microsoft's string, one word, no spaces — plus System user
• Microsoft Graph — Mail.Read.Shared, consented in Graph Explorer while signed in as the agent user
• Mailbox — A shared mailbox with the agent user added as a member

That is a non-human identity carrying three licences. Microsoft publishes this as the current setup procedure for the Expense Agent, so it is the documented way to stand this agent up today. Microsoft nowhere explains why the two licensing patterns differ. Our reading is that this one predates the MCP rule — ours, not a Microsoft statement.

Why both patterns exist at once

The mechanisms are documented; the causal story is ours. The Expense Agent runs on Power Automate flows and Power Platform connectors — Microsoft lists "Dataverse (Virtual Entities)" among them — so its identity is provisioned like a person's: Entra account, licences, mailbox membership.

The MCP server scopes differently. Microsoft states: "The security role of the authenticated user for the agent determines which objects are returned in the view model." Access comes from a role, not from a seat. Reading one pattern as the successor of the other is our inference.

We expect first-party agents to converge on the newer model. That is our call, not a roadmap — Microsoft has published no release-plan item saying it, and there is no 2026 release wave 2 plan yet to carry one. The design guidance holds either way: build new custom agents on the MCP pattern, not on the Expense Agent pattern. If you are copying an architecture from a Microsoft first-party agent, check which era it comes from before you inherit its licensing.

The identity design this implies

Microsoft states this once, in one place — the Expense Agent setup article, about the expense agent user. Verbatim: "Create a dedicated expense agent user to ensure that the agent runs independently of any employee's identity. This approach helps with security, manageability, and long-term maintainability. Although you can use an existing user account that has the required privileges, use a system-owned identity."

Read the last sentence twice. Microsoft permits an existing user account and recommends against it. The MCP documentation says nothing either way about employee accounts. So carrying the rule across both patterns is our position, and Microsoft's stated reasons are the three above: security, manageability and long-term maintainability.

Our reasons are narrower and they compound. An employee account carries permissions accumulated over a career, so the agent inherits reach nobody audited. Actions in the log are attributed to a person who did not perform them, which is a problem the first time anyone asks who approved something.

And when that person changes role or leaves, the agent's access changes or dies with an offboarding process that had no idea it was load-bearing.

A dedicated identity fixes all three, and it costs nothing extra under the exemption.

The counter-argument

"A licence-exempt identity that still holds real security roles sounds like a compliance gap. You have created a user that does work and is not counted anywhere."

The premise is right, and the answer splits by which agent you built — a distinction the objection does not make.

For a Copilot Studio agent there is a register. Power Platform inventory covers "All agents created in Copilot Studio, and all agents created in Microsoft 365 Copilot Agent Builder", queryable from the admin center, the Power Platform API and Azure Resource Graph (Power Platform inventory).

For a Foundry, Visual Studio Code or third-party agent reaching the ERP through the MCP server, that register does not apply. Microsoft is explicit: it "shows only agents that were built on Power Platform… It doesn't include first-party Microsoft agents, ISV agents, or agents created on other Microsoft surfaces."

What holds that agent is the Allowed MCP clients form in finance and operations. A platform outside Microsoft's default list reaches the server only after you register the application in Microsoft Entra ID and add its client ID to that form with the Allowed property set to true. That form, plus the security roles on the identity, is the whole register — and it is not the one an auditor thinks to ask for.

Inside the ERP there is a viewing surface. Microsoft: "The View activity button opens a holistic tracing list of all agent activities" (Immersive Home overview) — though the same page scopes that area to agents activated in the environment. Read it as an operations view.

What the identity does not do is consume a seat. Microsoft's stated purpose for the marker role is narrow: it "is intended only to exempt the agent from licensing requirements where applicable." Whether an MCP tool call lands in the finance and operations audit trail as its own entry is a question the MCP documentation does not answer and we have not tested. If a control depends on that answer, get it in writing before go-live — not from this article.

The genuine risk sits one step away and is worth naming: because the identity is cheap, nothing stops proliferation. Ten agents, ten identities, ten role assignments nobody reviews as a set. The control is a periodic review of agent identities and their roles, treated exactly like a joiners-movers-leavers process. The licence never enforced that discipline anyway — it just made you notice the cost.

What to do this week

1. List every agent identity in your tenant and check whether each holds the System agent role plus a purpose-built role, or something improvised. Improvised is the finding.
2. Check that no agent runs under a named employee's account. If one does, that is your first remediation and it is not a large one.
3. If you are copying an architecture from a first-party agent, identify which licensing era it comes from before you inherit it.

Where we would draw the line

We would never run an agent under an employee account, for the attribution reason before the security one — a log that names a person who did not act is a problem you cannot fix retrospectively. We would never add permissions to the System agent role; it is a marker, and the moment it grants something it stops being readable as one. And we would not design a new custom agent on the older identity pattern, because it costs more and carries more moving parts: three licences, a shared mailbox and a consented Graph permission, against one exempt marker role plus the roles that do the work.

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/

The identity that optimizes the price, the pick path or the safety-stock level is scoped exactly like the ones above — a marker role, then the roles that do the work. If you are standing these up now, we will review the role split with you on a call before it becomes ten of them. https://cognilium.ai

Sources

• Use Model Context Protocol for finance and operations apps
• Build agents for finance and operations with Model Context Protocol — release plan
• Set up the Expense Agent
• Power Platform inventory
• Immersive Home overview

Sources

• learn.microsoft.com — copilot mcp
• learn.microsoft.com — expense agent setup
• learn.microsoft.com — build agents dynamics 365 finance operations model context protocol
• learn.microsoft.com — power platform inventory
• learn.microsoft.com — immersive home