16 Feb 2026

Governing MCP in Dynamics 365 F&O: turning “agent power” into safe, auditable execution

Author: Roman Abilkhatov, D365 Finance Solution Architect

If you’re enabling the Dynamics 365 ERP Model Context Protocol (MCP) server, you’re not just “adding an AI feature.” You’re opening a standardised, tool-based doorway into ERP data and actions - including actions that look a lot like what a real user can do in the UI.

What MCP is in D365 F&O terms (and why it’s different)

Microsoft describes MCP as a standard that connects agents to enterprise data and business logic, replacing brittle point-to-point integrations with a governed framework.

In F&O, the “Dynamics 365 ERP MCP server” provides three tool families:

1. Data tools: CRUD via data entities/OData (typically faster and fewer calls than “UI-driving”).
2. Form tools: server-side form interactions (the agent can effectively “operate” the application like a user).
3. Action tools: explicitly invoke enabled business logic via AI tools built on ICustomAPI with proper security.

Two details should immediately change how you think about risk:

1. The MCP server dynamically updates context based on the agent’s security permissions and configuration - i.e., what it can do is shaped by roles, duties, and privileges.
2. When you add the MCP server to an agent, you’re granting access to all tools the server exposes, constrained by that identity/context.

Also, there’s an older “static” ERP MCP server (13 fixed tools) that Microsoft says will be retired in calendar year 2026 - plan migration to the dynamic server now to avoid a nasty surprise.

Why is MCP governance non-negotiable in ERP?

Microsoft’s own CISO org put it bluntly: one misconfigured MCP server can “give the AI the keys to your data.”

ERP makes that worse because:

1. The “blast radius” isn’t just about data leakage; it’s about incorrect postings, supplier master corruption, inventory misstatements, payment changes, and audit failures.
2. Segregation of duties is already hard with humans; agents can accidentally (or via prompt injection) bridge duties at machine speed.
3. Toolchains themselves can have vulnerabilities (real-world MCP server flaws have been reported in the ecosystem, reinforcing the need for strong vetting and isolation).

So the right stance is: treat MCP as both a production integration surface and a privileged automation runtime - not a “chat feature.”

The governance model: architecture, vetting, inventory (mapped to D365 F&O)

Microsoft Inside Track frames scalable MCP governance around three intentionally “boring” pillars: architecture, vetting, and inventory. Here’s how that translates into a D365 F&O operating model.

1) Architecture: create choke points

Inside Track’s principle: put MCP behind a controlled perimeter (authN/authZ, rate limiting, logging), minimise egress, isolate runtimes, and require consent for risky actions.

In D365 F&O, you already get some strong “built-in choke points” - use them deliberately:

1. Allowed MCP clients = your first allowlist. By default, only Copilot Studio and VS Code client IDs are allowed; anything else must be explicitly added.
2. Entra ID is the identity backbone for non-Microsoft clients (register an app, then allow its Client ID).
3. Environment tiering matters: MCP server is supported Tier 2+ / UDE and not supported on Cloud Hosted Environments (CHE).

Practical implication: your “front door” decisions are who can connect and under which identity, then enforce conditional access patterns around those identities.

2) Vetting: don’t let “any tool” become “any power”

Inside Track stresses vetted/attested servers, contract verification (block drift), and consent gates (“ask before edits”) for write/delete/config changes.

For F&O MCP, vetting is mostly about controlling what actions you expose, and how:

1. Prefer data entities for CRUD when possible (more efficient and predictable); coach agent instructions accordingly.
2. Treat form tools as “privileged”: they can mimic broad UI capability. Only allow them for tightly-scoped scenarios with explicit guardrails.
3. For action tools, expose business logic through AI tool classes (ICustomAPI) with proper security on the associated menu action item - and apply code review + test + approval just like you would for a posting routine.

3) Inventory: if you miss a server, you miss the conversation

Inside Track calls inventory the foundation - a living catalogue with ownership, scope, and policy application.

For D365 programmes, “inventory” must include:

1. Every agent (name, owner, purpose, environments, go-live state)
2. Every MCP connection (which MCP client, which app registration, which identity)
3. Every high-risk tool/action exposed (including custom ICustomAPI tools)
4. Data domains touched (AP, vendor bank, inventory, GL posting, etc.)
5. Audit/telemetry location and retention policy

If you can’t answer “which agents can change vendor bank details in Prod?”, you don’t have governance - you have hope.

An MCP governance checklist that actually works

Use this as your minimum viable control set.

Based on Microsoft Inside Track guidance

A concrete example: Vendor onboarding agent (safe-by-design)

Target outcome: reduce AP admin time without creating supplier/payment fraud risk.

How you scope it:

1. Reads: vendor master, bank accounts, duplicates, tax/VAT IDs, approval status.
2. Writes: create vendor + submit for approval (but does not “auto-approve”).
3. Posts: none (no postings in v1).

How governance applies:

1. Identity: agent acts on-behalf-of the requester for creation; approvals remain human.
2. Least privilege: custom role can create vendors but cannot edit bank details after approval.
3. Consent: agent must show a “diff” summary and require confirmation before creating records.
4. Vetting: any special logic (duplicate detection, IBAN validation) exposed via ICustomAPI with reviewed security.
5. Inventory: catalogue the agent as “AP domain / master data / medium risk” with an owner and runbook.

Don’t ignore the platform roadmap: static MCP retirement

If you have anything built on the older static ERP MCP server, treat 2026 as a forced migration window - Microsoft explicitly states it will be retired in the 2026 calendar year. Your governance approach should assume dynamic tools (data/form/action) and be robust to changing tool surfaces over time.

Close: the “ERP agent” mindset shift

MCP is the first time many D365 teams will expose ERP actions to a general-purpose reasoning layer without the need for custom connectors or APIs. That’s powerful - and it’s why governance has to look like production engineering: allowlists, least privilege, consent, contracts, inventory, and operational telemetry.