What it does

Controls which Service Agent Copilot tools a user can discover and run, using ordinary Dataverse privileges rather than a separate permission model. Each tool the Service Agent exposes — provided by the Dynamics 365 Customer Service MCP Server — is mapped to the Dataverse privileges a user needs before that tool becomes discoverable in Microsoft 365 Copilot.

Key facts

• To discover a tool, the user needs all the privileges listed against it. close_case, for example, needs prvReadIncident, prvWriteIncident and prvCreateActivity together.
• Discovery is fail-open: if a privilege lookup fails, the tool can still appear. But Dataverse enforces the underlying entity privilege at execution, so a visible tool can still return HTTP 403 when run.
• Tools not in the privilege map are ungated at discovery and always show — this covers the generic entity tools (get_entity_record, list_entity_records, etc.), environment-management tools, and synthesised external tools (ext_{prefix}_{name}, mcs_{name}) whose target isn't known until call time.
• Maker/admin tools (registrations, tool selection, agent config) all gate on prvmsdyn_ServiceAgentMakerCustomize; user-preference tools gate on prvmsdyn_ServiceAgentUserCustomize.
• Privilege checks are cached with a TTL, so role changes don't take effect immediately.

When to use / skip

This is the reference you reach for whenever you're scoping who can do what with the Service Agent. You don't "turn it on" — it's how access already works. Use it to design role bundles up front rather than discovering gaps in UAT.

Configuration decisions

• How to bundle privileges into roles — Microsoft's own suggestion is Agent, Knowledge Author, Maker Admin and User Preferences as separate bundles. Decide which of your existing security roles map to those.
• Who gets prvmsdyn_ServiceAgentMakerCustomize — this is the keys-to-the-kingdom privilege for registrations (MCP, Copilot Studio), tool selection and profile config. Keep it tight.
• Whether knowledge-authoring tools (draft_knowledge_article, publish_knowledge_article, harvest_knowledge_article) should sit with agents or with a separate knowledge-author role.

Gotchas

• A tool being visible does not mean it will run. Because discovery is fail-open and execution is enforced by Dataverse, users hit 403s at runtime that look like bugs but are just missing entity privileges. Test both visibility and execution.
• After changing roles, wait for the cache TTL to elapse before re-testing, or you'll chase a stale result.
• Some tools depend on non-obvious entities — query_cases_by_sla_status needs prvReadQueue and prvReadQueueItem on top of the SLA and incident reads, so a user with case access can still fail if queue access was never granted.
• The ungated entity tools (get_entity_record and friends) show for everyone, but the entity they touch is still privilege-checked server-side — don't assume "ungated at discovery" means "no access control".

Consultant notes

• Clients scope Service Agent access as if it's a single on/off switch and are surprised it's really a matrix of Dataverse privileges. Map the tool list to security roles during design, not go-live, or you'll be reverse-engineering 403s in production.
• The split between ...MakerCustomize and ...UserCustomize matters for governance: makers can register external MCP and Copilot Studio bots, which is a data-exfiltration surface. Treat the maker privilege as an admin-tier grant and review who holds it.
• Build a small test matrix of representative roles and walk each tool for both visibility and execution before UAT. It's tedious but it's the only way to catch the fail-open-then-403 pattern before an agent does.
• Remember the cache TTL when validating. More than one "the role change didn't work" ticket is just someone testing inside the TTL window.

---

Worth revisiting after the next release wave, and whenever new Service Agent tools are added to the MCP server