Almanac
Microsoft/dataversePower Platform

Consultant KB for Microsoft Dataverse, the data layer under Dynamics 365 and the Power Platform: data model, security model, business logic, APIs and integration, search and queries, analytics and Fabric, ALM and solutions, administration, governance and compliance, and Dataverse as an agent data platform, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Dataverse release plans, docs repo and product blog, plus the author's own consultant notes.

feature-copilot-and-dataverse-security.mdv1 · history
CurrentApplies to AllUpdated last monthSource Microsoft Learn

What it does

Dataverse's row and column security applies to Copilot and agent access the same way it applies to a model-driven app — but only when the request carries the end user's identity. The oversharing risk in Power Platform agents comes almost entirely from the paths where it doesn't: maker-owned connections, service identities and knowledge copied out of Dataverse into somewhere with weaker access control.

Key facts

  • Copilot Studio tailors responses to who is speaking to it and the permissions that person holds. That's the documented default posture, and it holds for Dataverse knowledge sources because those require Authenticate with Microsoft.
  • Where an agent uses a connection the maker created, the agent authenticates as the maker, not the end user. Everything reachable through that connection is reachable by everyone who can chat to the agent.
  • Column-level security still applies. A secured column the user can't read is a column the agent can't return — which shows up as an unhelpful answer rather than an error.
  • Dataverse search backs retrieval for Dataverse knowledge sources, and search results are trimmed to the caller's access.
  • Copilot Studio doesn't support tenant isolation. Cross-tenant connections are allowed by default unless the Power Platform tenant isolation setting is turned on.
  • Data policies in the Power Platform admin centre can restrict which knowledge sources makers may use, at environment or tenant level — SharePoint, public websites and uploaded documents are individually controllable.
  • Copilot Studio supports customer-managed keys; when CMK is on for the environment, Copilot Studio data is encrypted with the customer's key.
  • Sensitivity labels and DLP endpoint filtering for SharePoint knowledge sources are the documented anti-oversharing controls; they're strongest on Microsoft 365 content, not on Dataverse rows.

When to use / skip

The question clients actually ask is "will the agent leak data". For Dataverse specifically, the reassuring answer is broadly true — retrieval runs as the user and inherits row-level security, which is a better story than most competing platforms can tell. Say so, and then immediately qualify it, because the qualifications are where every real incident lives.

The three that matter: connections owned by makers, agents configured with a shared service identity for convenience, and content that was exported out of Dataverse into a file or a SharePoint library and added as a knowledge source there. The third is the one nobody plans for. A well-secured Dataverse table becomes a spreadsheet in a document library, the document library becomes an agent's knowledge, and the security model you spent three weeks designing is gone.

Configuration decisions

  • User authentication mode per agent. Authenticate with Microsoft is the setting that makes Dataverse security apply; the alternatives are a deliberate decision to give up row-level enforcement.
  • Whether maker-provided credentials are permitted, or whether connections must be environment-level and reviewed.
  • Which knowledge sources makers may use, set through data policies rather than convention.
  • Whether tenant isolation is on, since Copilot Studio itself doesn't provide it.
  • Whether the security model as designed actually survives the agent's questions — a role that's fine for a form-by-form app can look very permissive when something can ask a hundred questions a minute.

Gotchas

  • Column-level security failures are silent. The agent doesn't say "you can't see that", it just answers without the field, and the user reads the answer as complete.
  • An agent's own creator is the worst possible test user. Makers have broad roles, so the agent looks perfect in testing and reveals nothing about what a sales rep sees.
  • Copying Dataverse data anywhere else for grounding purposes discards the security model completely. Treat any proposal to "just export it for the agent" as a security change requiring sign-off.
  • Business unit and team-based access work exactly as they do elsewhere, which means agents inherit any existing over-permissioning. Agents are a good excuse for the security review the client has been deferring.
  • Sensitivity labels and DLP protect Microsoft 365 knowledge well. There isn't an equivalent row-level label story for Dataverse — Dataverse security is the control, so it has to be right.

Consultant notes

  • Lead with the honest version: the platform enforces access properly on the supported path, and the risk is in the shortcuts. Clients trust that framing more than an unqualified reassurance.
  • Run a UAT pass with three different personas at three privilege levels. It's the cheapest way to find over-permissioning and it demonstrates enforcement to a sceptical security team.
  • Where a client insists on an unauthenticated or service-identity agent, get the data scope written down and signed. That configuration is a decision, not an accident, and it should look like one in the record.
  • Use the agent programme as the lever to get the security model fixed. It's the first time in years most clients have a business reason to review roles properly.

Sticky note: re-test the maker-connection behaviour after any Copilot Studio authentication change — that's where the oversharing keeps coming from

Was this accurate?