Knowledge Governance

TL;DR: You will design safe knowledge sources for a declarative agent across SharePoint, Dataverse and Copilot connectors, then enforce sensitivity labels and Data Loss Prevention so the agent honours least-privilege and cannot surface data the user is not entitled to see.

What you will learn

How to scope SharePoint, Dataverse and Copilot connector knowledge so an agent only reasons over data the signed-in user can already access.
How sensitivity labels flow through to agent responses to keep classified content protected.
How to configure Data Loss Prevention (DLP) data policies in the Power Platform admin center to block risky connectors and channels.
How to verify least-privilege behaviour and read DLP violation reports before an agent reaches production.

Prerequisites

Microsoft 365 Copilot licence for every user who will consume the agent (SharePoint, OneDrive, Dataverse and connector knowledge require it).
Copilot Studio access and an environment in which you can author and publish agents.
A Power Platform admin or Environment Admin role to create and apply data policies; tenant-wide policies require a tenant administrator.
Microsoft Purview sensitivity labels already published in your tenant, and labelled test content to validate against.
Microsoft Entra ID P2 is recommended where you want Conditional Access and access reviews around the maker and consumer identities.
Recommended earlier reading: a foundational agent-building tutorial so you are comfortable creating a declarative agent before you govern one.

Design least-privilege knowledge sources

The first control is the knowledge source itself. A declarative agent always runs in the context of the signed-in user, so it can only retrieve content that user is already permitted to see. Your job is to make sure each source is scoped tightly rather than pointed at everything.

Step 1: Scope SharePoint to specific sites or folders

In Microsoft 365 Copilot, choose New agent, then Skip to configure.
In the Knowledge section, add SharePoint as a source using one of these methods:
- Enter URL for a specific site, folder or file, for example a single policies site rather than the whole tenant root.
- Browse with the Attach cloud files picker to select up to 100 SharePoint files per agent.
Prefer a curated site or folder over a broad root URL. A root URL also matches its subpaths, which widens exposure.
Note that if Restricted SharePoint Search is enabled in your tenant, SharePoint cannot be used as a knowledge source at all.

The agent respects existing SharePoint and OneDrive permissions and sensitivity labels on those files, so correct underlying permissions are your primary least-privilege boundary.

Step 2: Scope Dataverse and Copilot connectors

For Dataverse, add the source through Microsoft 365 Agents Toolkit, where you can scope the knowledge to specific tables rather than the whole environment.
For Copilot connectors, confirm your admin has enabled and configured the connector in the Microsoft 365 admin center first.
On the Configure tab, under Choose other data sources, select the connector and add only the connections relevant to your scenario.
Return to the Knowledge section, expand the connector, and select a scoping attribute, for example a project, space, folder or Azure DevOps area path, so the agent reasons over only that slice of data.

If a scoping attribute does not appear, it is usually because the admin did not configure scoped content or the maker lacks permission to it. That gap is itself a least-privilege signal worth investigating.

Apply sensitivity labels and protect classified content

Sensitivity labels published through Microsoft Purview travel with your content. When labelled files are used as knowledge, the agent honours the label’s protection, so classification work you have already done is reused rather than rebuilt.

Step 1: Confirm labels and access alignment

Verify that the SharePoint and OneDrive files you added as knowledge carry the correct published sensitivity labels.
Confirm that any encryption or access restriction on a label maps to the audience that should use the agent. A user who cannot open a labelled document directly will not receive its content through the agent either.
Use a labelled test document containing recognisable text, then query the agent as a low-privilege user to confirm the protected content is not returned.

Step 2: Keep classified data out of broad sources

Avoid adding broad, all-content sources such as all Teams chats or an entire mailbox when the agent only needs a narrow knowledge base. Broad sources increase the chance of surfacing labelled or regulated data unintentionally.
Where a knowledge feature cannot be scoped, for example email which always uses the whole mailbox, weigh whether the agent genuinely needs it.
Document, per source, which classification levels are expected so reviewers can spot drift later.

Enforce Data Loss Prevention with data policies

Sensitivity labels protect content; DLP data policies govern how the agent connects to data and services. Since early 2025, data policy enforcement applies to all tenants and agents can no longer be exempted, so this step is mandatory, not optional.

Step 1: Create a data policy

Sign in to the Power Platform admin center .
On the sidebar, select Security, then Data and privacy, then Data policy.
Select New Policy and give it a clear name, then select Next.
On Add an environment, add the environments this policy should cover.

Step 2: Block risky connectors and configure endpoints

On the Assign connectors page, search for a connector you want to control.
Select the three dots next to the connector, then choose Block to prevent makers from using it.
To allow or deny specific endpoints for SharePoint, public websites or HTTP requests used as knowledge, choose Configure connector, then Connector endpoints, add your allowed patterns, and Save.
Select Next, then define the scope. Use stricter policies in development environments and relax them only for reviewed test and production environments.

Step 3: Read violation reports before publishing

In Copilot Studio, open the Channels tab. If an agent violates a policy, a warning appears and publishing is blocked until it is resolved.
Select Download to retrieve an Excel workbook with two worksheets: DLP violations and Blocked channels.
Use the policy name, policy ID and blocked connector details in the report to decide whether to adjust the agent or have an admin adjust the policy.
Remember that if all channels are blocked by policy, the agent cannot be published at all, which is the intended fail-closed behaviour.

Governance call-outs

Least-privilege is inherited, not configured: the agent can only return what the signed-in user can access, so audit the underlying SharePoint, Dataverse and connector permissions before trusting the agent boundary.
Data leakage through broad sources: prefer narrow, scoped sources over all-content options like an entire mailbox or all Teams chats to reduce the blast radius for labelled or regulated data.
Compliance gates are mandatory: DLP enforcement applies to every agent with no exemptions, so treat blocked publishing as a control working as designed rather than a defect to bypass.
Identity hygiene: secure both maker and consumer identities; Conditional Access and access reviews (Microsoft Entra ID P2) limit who can author agents and who can be entitled to sensitive knowledge.
Audit trails: retain DLP violation workbooks and review them as part of every release so you can evidence why a connector or channel was blocked or allowed.

Next step

Continue with the next tutorial.

Sources

Licensed under CC BY 4.0 by Educ4te .