MCP security model
How Plur-e MCP servers handle identity, MCP roles, audit and data — per-user Entra ID sessions, entities and actions granted per role, deny-by-absence, full logging, no training on customer data.
Quick answer
Every tool call runs under the signed-in user (Microsoft Entra ID), so Business Central and Dataverse permissions apply unchanged. On top of that, every tool is gated by the user's MCP roles: without a role that grants the entity/area and the action, the call denies instantly — nothing is queued for approval. All calls are logged. Customer data is not used to train models.
Identity
- Users sign in with Microsoft Entra ID (the same app registration as the Admin Center). Only accounts that already exist as users of the tenant in the Admin Center can connect; the server never creates users.
- The tenant is resolved from the token — a tenant user's Entra tenant must match the Plur-e customer — never from a tool argument. Plur-e staff and partners pick the tenant with
select_tenant. - The server calls Business Central with Plur-e's application credentials, limited to the one environment and company the tenant administrator configured in the Admin Center (AI & MCP → Settings). On-premise environments are excluded unless the administrator opts in.
- Per-user delegated access (Business Central seeing the real user) is on the roadmap.
Connector authentication (OAuth 2.1)
mcp.plur-e.com is its own OAuth 2.1 authorization server
(/.well-known/oauth-authorization-server), sitting in front of Microsoft Entra ID, so MCP
clients (a web AI platform, a desktop or IDE client, the Plur-e plugin) can connect without anyone
configuring a client id or secret:
- Dynamic Client Registration (RFC 7591,
POST /oauth/register) is open: any client can register and receive aclient_id. Registered clients are public (no client secret) and must use PKCE with S256 on every authorization request. Redirect URIs must behttps://, except loopback addresses (http://localhost/127.0.0.1) for desktop and CLI clients. - Sign-in happens against Microsoft Entra ID with Plur-e's own application; the user never
sees or handles Plur-e's client secret. The authorization server resolves the signed-in
account to a Plur-e user and issues the connection under that user's tenant (or asks staff and
partners to
select_tenant); accounts that do not exist in the tenant get a clearaccess_deniederror instead of a token. - Tokens: access tokens are short-lived (1 hour); refresh tokens are opaque, rotate on every use (reuse is detected and revokes the whole chain) and expire after 30 days of inactivity or when an administrator revokes the connection.
- Auditing: registration, authorization, token refresh and revocation are recorded in the
MCP audit log (
oauth.*actions); token values themselves are never stored or logged. - Direct Entra ID tokens issued to existing integrations continue to be accepted, so nothing that already authenticates that way needs to change.
Administrators manage connected clients per tenant in AI & MCP → AI connections in the Admin Center (see Connect your AI client).
Roles
Every tool declares the entity (CRM table) or area (Business Central section) it touches and the action it performs — Read, New, Update, Delete for CRM; Read, Write, Post for Business Central. A user's MCP roles, assigned in AI & MCP → Roles, decide whether a call runs:
| Destination | Grants | Default |
|---|---|---|
| Business Central | Area × Read / Write / Post | Default access role (read-only) created when the tenant enables Business Central |
| Dynamics 365 CRM | Entity × Read / New / Update / Delete | Default access role (read-only) created when a connection is verified |
A role belongs to one destination — Business Central, or one specific CRM connection — and
is assigned to specific users; the Default access role applies to every user of the tenant
in addition to whatever else they are assigned. Without a role that grants the entity/area
and the action, the tool denies immediately with a clear message (scope_denied) that
tells the user what is missing and where to ask for it — there is no pending state, no
approval queue and no confirmation prompt. See MCP roles for the full
model, the default entities and the exact denial messages.
Audit
Each call logs user, tool, arguments (secrets redacted), result summary, duration and outcome. Logs are available to the customer's administrators.
Data handling
- Data flows from the MCP server to the client (your AI assistant) only for the current request.
- AI providers typically do not train on API data submitted under commercial terms.
Log retention period and the list of subprocessors are available on request.
Related: MCP roles · Site security · Product page
Last updated on
Edit on GitHubDocs MCP
A public, read-only Model Context Protocol server over the Plur-e documentation with search_docs, get_page and list_sections. Live at plur-e.com/api/mcp/docs.
MCP roles
How MCP roles control what your AI assistant can do on the Plur-e Business Central and Dynamics 365 CRM servers — entities, actions, the default role and the exact denial messages.