How to design a DLP strategy for Microsoft 365 Copilot and agents

Published on 5 October 2026. Feature status, licensing and product names checked that day against Microsoft’s official documentation.

In this guide I use “DLP strategy” in the broad sense in which it is usually requested: keeping sensitive information from ending up where it should not. Microsoft Purview Data Loss Prevention is one of the pieces, and not the first. The others are permissions, labels, agent governance, identity and logging, and each one is configured somewhere different.

A note on names: in its 2026 documentation Microsoft talks about Microsoft Copilot and Copilot Chat, while the full licence is still called Microsoft 365 Copilot and the DLP location is “Microsoft 365 Copilot and Copilot Chat” (what Microsoft Copilot is). Here I use Microsoft 365 Copilot for the experience that works with organisational data.

Five agents in production and nobody looking at the whole picture

A company rolls out Microsoft 365 Copilot to a large part of its workforce. Within a few months five agents appear: an HR agent answering questions about holidays and payroll, an internal support agent, a sales agent that drafts proposals, one connected to the CRM and another that searches technical documentation. They work, people use them and nobody has complained.

The problem appears when someone asks about the whole. Nobody has reviewed, all at once:

• what information each agent can query, and with which identity;
• which connectors it uses and where they send data;
• which SharePoint sites are shared with more people than they should be;
• which documents are labelled and which are not;
• which answers or actions should be prevented;
• what happens when an agent calls an external system.

I would not start with the policy. First I would map the journey of the information: who asks, which agent answers, where it gets the data from, what it does with it and which system it can move it to. That map shows which controls already exist, which are missing and which have little to do with DLP.

Copilot and agents work on information that already exists in the organisation. What changes is speed: they find, combine, summarise and move in seconds what used to require knowing where to look. If permissions were too open, or sensitive documents were never classified, that problem already existed; now it shows up sooner.

The map: how information travels when Copilot or an agent is involved

This is the journey worth mapping for Copilot and for each agent. Next to each step are the controls that can act at that point.

Eight layers, and not all of them are DLP

Calling all of the above DLP makes conversations between security, compliance and administration harder. I prefer to separate eight layers and say what kind of control each one is.

Only the third layer is DLP in the strict sense. For years Power Platform called the fourth “DLP policies”; Microsoft now calls them data policies, and they act on connectors and features without analysing content.

First mistake: thinking Copilot bypasses permissions

Microsoft documents this unambiguously: Copilot only surfaces organisational data for which the user has at least view permission (Copilot data, privacy and security). Queries run in the security context of the person writing the prompt, and that includes permissions granted to people outside the organisation, for example in Teams shared channels.

Copilot respecting permissions has a less comfortable consequence: it also inherits the excessive ones. A site shared with “Everyone except external users”, a link valid for the whole organisation or the folder of a closed project with its old permissions all remain accessible. Before, you had to know the path or get lucky with search; with Copilot, asking is enough.

This is called oversharing: people or groups with access to information they do not need for their work. Copilot amplifies the oversharing that already existed, because it makes it visible and easy to exploit. That is why I treat it as a data governance problem: the fix goes through permissions first, and DLP comes afterwards.

With agents the question widens. An agent’s tool can use the credentials of the person asking or those of the person who built the agent. In the second case, users can reach data they would not see on their own. I cover this in the identity and autonomous agents sections.

Layer 1 · Permissions and oversharing

Before any DLP rule I would review the permissions of the repositories Copilot and agents can query. If a person can open a document, Copilot can use it in its answers, within the limits the service supports.

What to review in SharePoint, OneDrive and Teams

Tick what you have checked. The ticks only help your reading: they are not stored or sent anywhere.

SharePoint Advanced Management, included with Copilot licences, provides data access governance reports, access reviews by site owners and site ownership and inactive site policies (SharePoint Advanced Management). In Purview, DSPM adds risk assessments that flag overshared sites containing sensitive information.

Temporary controls while you fix it

Cleaning up permissions takes weeks. In the meantime, Microsoft’s deployment guidance suggests two interim measures (secure and governed foundation for Copilot):

• Restricted Content Discovery removes specific sites from organisation-wide search and from Copilot answers, and takes AI entry points off those sites. It does not change permissions, only works with SharePoint sites (not OneDrive) and Microsoft positions it as a temporary measure (Restricted Content Discovery).
• Purview DLP for Copilot excludes content with specific labels from answers. I explain it in layer 3.

Both measures should come with a removal date. Once a site has been cleaned up, the restriction is lifted; if it stays, Copilot loses useful content and the underlying problem remains unsolved. As permanent protection, the same guidance recommends applying Restricted Access Control by default to critical sites and restricting “Anyone” links and company-wide groups.

Layer 2 · Classification and sensitivity labels

Sensitivity labels in Microsoft Purview Information Protection indicate what is sensitive and can apply markings, encryption and usage restrictions. With Copilot they play three roles: they inform users, they limit what the assistant can summarise when there is encryption, and they act as conditions in DLP policies.

Applying a label does not, on its own, stop Copilot reading a file. The effect depends on configuration: whether it encrypts, which rights it grants and to whom, and whether any DLP policy uses that label.

VIEW, EXTRACT and encryption

• If the label encrypts, the user needs the VIEW and EXTRACT rights for Copilot to return the content (Purview and Microsoft 365 Copilot).
• With VIEW but without EXTRACT, Copilot can link to the item but cannot summarise it (usage rights).
• Labels must be enabled for SharePoint and OneDrive. Without that, the encrypted files Copilot and agents can reach are limited to those the user has open in Office apps on Windows.
• Content protected with Double Key Encryption is not accessible to Copilot, either at rest or open in the app (Double Key Encryption).
• S/MIME-protected emails are not returned, and password-protected documents are only used if the user already has them open.
• Copilot Chat shows the highest-priority label among the sources it used, and Copilot in Word, PowerPoint and Outlook inherits the source document’s label when creating new content.

Agents add nuance. In Copilot Studio, labels are honoured when the knowledge source is SharePoint (or Dataverse with Data Map auto-labelling), and encryption is only supported through labels and with SharePoint as the source (Purview and Copilot Studio). Agent 365 agent instances need files to be explicitly shared with them and encryption to grant them VIEW and EXTRACT; a label granting rights to all users in the organisation is not enough, and the content they create does not inherit the source labels (Purview and Agent 365).

What should Copilot be allowed to do with each label?

This scale is a proposal to guide the conversation with the business. The names and number of labels depend on each organisation’s taxonomy.

For labelling at scale, Purview auto-labelling in SharePoint and OneDrive has just raised its daily limit (30-second note on auto-labelling); it requires E5-level licensing.

Layer 3 · Purview DLP for Copilot: what it actually does

Microsoft Purview Data Loss Prevention has a dedicated location for Copilot, called “Microsoft 365 Copilot and Copilot Chat”. Its policies act on the interaction with the assistant: which content it can use to answer, which prompts it processes and when it can go out to the web (DLP for Microsoft 365 Copilot).

Four controls and their status

Microsoft has also created a default policy, “Default DLP policy - Protect sensitive M365 Copilot interactions”, which detects sensitive information types in prompts and starts in simulation mode: it logs but does not block (default policy). Before creating another, I would review that one: which types it detects, who receives the alerts and when to switch it to enforcement.

Limits worth knowing before designing:

• A rule cannot combine labels and sensitive information types; you need separate rules within the policy.
• The location only exists in the custom template and, once selected, all other locations in that policy are disabled.
• Changes can take up to four hours to apply. Alerts, notifications and simulation mode are supported, administrative units are not.
• DLP does not scan files the user uploads to the prompt; only the text they type.
• For email, the label restriction covers messages sent on or after 1 January 2025, and calendar invitations are not covered.
• In Word, Excel and PowerPoint, the policy is evaluated when the file is opened. If the label changes while the document is open, it applies the next time it is opened.

What it covers: Copilot, Cowork and agents

The label restriction applies to Microsoft 365 Copilot, Copilot Chat, Cowork and Copilot in Word, Excel and PowerPoint. For agents, precision matters:

• Copilot Studio agents: a policy in the Copilot location can stop them processing content with a specific label when their knowledge source is SharePoint and they are published to Teams, SharePoint or Microsoft 365 Copilot (Purview and Copilot Studio).
• Agent 365 agent instances: they are included in DLP policies as if they were users, or through a security group, to block or audit exchanges between people and agents in Teams, SharePoint, OneDrive and email. The agent does not know it has been blocked, so its owner needs to watch the effect on downstream workflows (Purview and Agent 365).
• Third-party AI: on devices onboarded to Purview, Endpoint DLP can warn or block when someone pastes sensitive data into a generative AI site from the browser, which is the technical side of what is often called shadow AI. In the web version of Copilot Chat it can block pasting sensitive content and files with specific labels.

Example: excluding “Highly confidential” content

DLP adds a barrier on what Copilot can use. Permissions still decide who reaches the data, and labels decide what is sensitive. Agents also have capabilities this location does not govern: connectors that take data out of the tenant and actions that change other systems. The next layers deal with those.

Layer 4 · Copilot Studio and Power Platform data policies

Copilot Studio agents live in Power Platform environments and are governed with data policies, configured in the Power Platform admin center. Since early 2025 they apply to every tenant. The exemptions that used to leave agents out no longer exist, and previously exempted agents became subject to the policies (data policies for agents).

What they govern

Enforcement happens in real time: makers see the capability disabled, get an error and cannot publish while there are violations.

Groups, endpoints and advanced policies

• Connectors are classified as Business, Non-business or Blocked, and an agent cannot combine connectors from different groups. New connectors fall into the default group, which many organisations block.
• Endpoint filtering allows or denies specific URLs for HTTP, public websites and SharePoint as knowledge. In Power Platform it is still in preview, and it does not evaluate dynamic endpoints, environment variables or custom inputs (endpoint filtering).
• Custom connectors are classified at tenant level by host URL patterns. In new policies the “*” wildcard rule defaults to “Ignore”: with no other rule, a custom connector can be used alongside connectors from any group (custom connectors).
• Advanced connector policies flip the model: everything blocked unless allowed, per environment or environment group, with blocking at MCP server level. They do not yet cover custom or HTTP connectors, and Copilot Studio’s own controls stay in classic data policies until Microsoft publishes dedicated rules (advanced connector policies).
• Changes propagate with a delay: usually within an hour and, in large estates, up to 24 hours. Non-compliant resources are quarantined and fail at runtime (Power Platform data policies).

Are they the same as Purview DLP?

No. An organisation using Copilot and Copilot Studio needs both, because they answer different questions.

One protects content; the other limits what the agent can do.

Layer 5 · Connectors, HTTP, MCP and tools

Every connection extends what an agent can read and do: a connector to a CRM, an HTTP request to an API, an MCP (Model Context Protocol) server, a skill or a third-party tool. For risk analysis, what the connection allows matters more than its type.

Six questions before approving a connection

1. What data can it read, and from which systems?
2. What can it write, create or delete?
3. Which actions does it run, and does it ask for confirmation first?
4. Which identity does it connect with: the user’s, the maker’s or its own?
5. Can it call external systems or endpoints we do not control?
6. Can it send information outside the tenant, and is that logged?

MCP: three routes governed in different places

MCP reaches the Microsoft 365 ecosystem through at least three routes today. They share the protocol, but each one is governed from a different console.

One detail with real impact: if an MCP server or API authenticates with an API key, access does not go through Microsoft Entra and Conditional Access cannot apply (Conditional Access for agents). For connections to sensitive data I would prefer OAuth with the user’s identity.

Layer 6 · Identity: an agent should only have what it needs

Least privilege applies to agents as well. The difference is that an agent can act in three ways, and each one is controlled in a different place (Conditional Access for agents):

• On behalf of the user (delegated access): it uses the permissions of the person asking, and policies target users.
• With its own identity and no user present (app-only): this is typical of autonomous agents, and policies target the agent identity or its blueprint.
• With its own agent user account, which can have a mailbox, licences and group memberships. Policies targeting “all users” do not include these accounts.

Microsoft Entra Agent ID is available to all Entra customers, and since July 2026 Copilot Studio creates one for every new agent, with no environment-level opt-out (what’s new in Copilot Studio). Applying Entra security controls to agents (Conditional Access, identity protection and governance) requires Microsoft Agent 365 (what Microsoft Entra Agent ID is).

The accounts of people who build and administer agents deserve the same protection as admin accounts; passkeys are the phishing-resistant option (passkeys in Entra ID manual).

Layer 7 · Observability: what you can see, where, and what you cannot

A DLP strategy that only blocks and does not log loses context: you will not know what was attempted, who did it or whether the policy was well designed. With Copilot and agents, evidence is spread across several tools.

Purview Audit

Interactions with Copilot, Cowork and Copilot Studio agents are logged in Audit (Standard) with no extra configuration, as long as auditing is on (Copilot audit logs). Each CopilotInteraction record includes, among other data:

• the resources accessed, with their label, whether the action succeeded and which policy blocked or restricted it;
• whether indirect prompt injection was detected in a resource, or a jailbreak attempt in the prompt;
• the agent involved, with its identifier, name and version, and the app where it happened.

The audit record does not contain the conversation text. Prompts and responses are stored in the user’s mailbox; they can be viewed from DSPM with the right role and searched, preserved or exported with eDiscovery.

Copilot Studio also audits what makers and administrators do: creating, publishing and sharing agents, authentication changes, components and environment variables (Copilot Studio audit logs). Agent ID authentication is recorded in Microsoft Entra logs, and third-party AI apps are audited under pay-as-you-go billing with 180 days of retention.

DSPM: the posture view

Purview Data Security Posture Management (DSPM) shows where the risk is and proposes policies; blocking is then done by DLP or labels. The current version replaces DSPM for AI, which Microsoft keeps as “classic”, and includes an AI observability page listing apps and agents with activity, the high-risk ones and interactions with sensitive data (DSPM).

It helps you discover real usage, review interactions with sensitive information, run oversharing assessments and create its recommended policies in one click. Those policies are DLP, Insider Risk or labelling policies, and each keeps its own licensing requirements.

Insider Risk and Adaptive Protection

The Risky AI usage template in Insider Risk Management detects prompts and responses containing sensitive information in Copilot and in agents, as well as visits to generative AI sites, and feeds each user’s risk score. The Risky Agents template, in preview, watches the behaviour of Copilot Studio and Foundry agents: access to sensitive files, visits to risky sites or external sharing (Insider Risk Management templates).

Adaptive Protection turns that risk into stricter controls. For example, a policy can block a user with elevated risk who tries to paste sensitive data into a third-party AI tool, while only warning everyone else. It is worth being precise about where it acts: in DLP for Exchange, Teams, devices and unmanaged cloud apps, and in preview with Conditional Access and retention (Adaptive Protection). The Copilot location in DLP does not currently offer the risk-level condition (DLP policy reference).

Neither is essential to get started. Both require E5-level licensing and, before switching them on, it is worth involving legal counsel and the DPO, informing employee representatives and carrying out an impact assessment, as with any monitoring of people’s activity.

Microsoft Defender

Defender covers runtime threats. Since 1 July 2026, its security capabilities for Copilot Studio and Foundry agents require an Agent 365 licence (transition to Agent 365). Real-time protection evaluates tool invocations before they run; for Copilot Studio agents it is in preview, and the default rule only audits until blocking rules are created (real-time protection).

What you will and will not see

Layer 8 · Governance: inventory, owners and lifecycle

You cannot apply DLP to an inventory you do not have. Before deciding on policies you need to know which agents exist, who is accountable for each one, what data they use and where they are published.

Agent registry and Agent 365

The agent registry in the Microsoft 365 admin center brings together Microsoft agents, partner agents, agents published by the organisation and those shared by their makers. It flags agents left ownerless when their maker is deleted and those managed outside Agent 365, and lets you block, delete or reassign them (agent registry). Per-agent risk signals require a Microsoft 365 E7 or Agent 365 licence.

Microsoft Agent 365 has been available since 1 May 2026 for the commercial segment, licensed per user, and Microsoft presents it as the control plane to observe, govern and secure agents (Agent 365). It provides a unified inventory with telemetry, Entra identities for agents, integration with Purview for auditing and data protection, and with Defender for detection. Microsoft states that it works best on top of E5. For organisations without E5, the starting point is still the agent registry and the consoles they already have.

From development to retirement

Every agent should have a minimal record, reviewed at each step:

Owner

The person and department accountable for the agent.

Purpose

Why it exists and who uses it.

Data

Knowledge sources and their highest label.

Connectors and actions

What it reads, what it writes and with which credentials.

Policies

Environment, zone, data policies and DLP that apply.

Testing

What was tested before publishing, including prompt injection attempts.

Approval

Who gave it, and when.

Review or expiry

The date when it is reviewed or retired.

With Power Platform application lifecycle management (ALM), changes go through solutions and pipelines between development, test and production; Copilot Studio also supports source control with GitHub and deployments with an auditable history (Copilot Studio security and governance). If nobody in the organisation owns this record, agent governance ends up belonging to nobody; where there is no in-house team, it is a task that fits a CISO as a Service. For the wider AI governance framework, ISO/IEC 42001 and an AI policy provide the structure.

Zones: not every agent deserves the same control

Microsoft proposes governing Copilot Studio in zones based on who builds: citizen development, partnered development and professional development (zoned governance). I prefer to organise them by what the agent touches, meaning data and actions. What follows is an ACBSEC proposal, inspired by Microsoft’s but different from its official classification.

Training the people who build agents is part of the control. Article 4 of the AI Act also requires AI literacy measures proportionate to how each person uses AI.

Matrix: what to allow by data type and use

This matrix is an example to adapt. It crosses data types with four ways of using them, and each organisation should fill in its own with the business, security and compliance.

Autonomous agents: when nobody writes the prompt

A reactive agent waits for someone to write to it. An autonomous agent acts when something happens: an email arrives, a file is created in SharePoint, a Dataverse record changes or an hour passes. That change of model changes the risk too.

Microsoft warns about this in its documentation: if a published agent has authenticated triggers, its users might access information or trigger actions with the maker’s credentials. In addition, the trigger payload can contain sensitive data that the agent ends up writing somewhere else; Microsoft’s example is an agent that uses incoming emails to create rows in Dataverse (event triggers).

Before approving an autonomous agent I would ask five questions:

• Which event fires it, and who can cause that event from outside?
• What data arrives in the trigger payload, and what does it query afterwards?
• Which action does it run, and with which credentials?
• What limits does it have on frequency, volume and destinations?
• What happens if the input is wrong or malicious, for example an email with hidden instructions?

Data policies can block triggers through the Microsoft Copilot Studio connector, and in my zone proposal autonomous agents only exist in zone 3. In Cowork, event-driven tasks prepare actions for the user’s approval by default, and each task runs with that user’s permissions (Cowork FAQ).

An exfiltration case: where you can cut the flow

A confidential document, an agent with SharePoint knowledge, a connector to an external service and a third-party SaaS. The agent summarises the document and sends the summary to the SaaS to prepare a proposal. Nobody acted in bad faith, and yet the information has left.

None of the eight cuts is enough on its own. Permissions fail when someone overshares, DLP cannot see what is not labelled and data policies do not know what the document contains. Protection comes from combining them.

DLP for Copilot in 7 levels

This is how I would combine the layers in a project. Each level builds on the previous one: without an inventory you cannot classify with judgement, and without clean permissions DLP policies only mask symptoms. It is ACBSEC’s working method and not part of Microsoft’s documentation.

Worked example: a company with 600 employees

Ten controls I would review before rolling out

Priority 1: before extending Copilot or publishing more agents. Priority 2: during the rollout. It is an indicative order of work.

Mistakes I would avoid

• Creating DLP rules before classifying data. Without a taxonomy, rules either block too much or protect nothing in particular.
• Assuming Copilot ignores permissions. It respects them, which is exactly why it inherits oversharing; the work lies in permissions.
• Relying only on Secure Score. It helps prioritise, but it does not tell you what data Copilot and agents can see, as I explain in the Microsoft 365 security assessment guide.
• Labelling everything as confidential. If everything is confidential, the label stops informing and exceptions multiply.
• Blocking every connector. Makers look for workarounds; an approved list per zone works better.
• Allowing HTTP without control. It is the most direct way to send data to any endpoint.
• Not separating development, test and production. Experiments end up with real data and changes arrive unreviewed.
• Forgetting old agents. Their makers leave and the agents stay shared.
• Monitoring people but not agents. Many actions are run by agents with their own identity or the maker’s.
• Buying licences before defining the policy. First decide what to protect and where; then, which capability is missing.

Licensing: what each capability requires

This table summarises what Microsoft documents as of 5 October 2026. Plans change often, so always check the Product Terms and current documentation before deciding. For the rest of Purview, see the Purview licensing guide and the licensing simulator.

Frequently asked questions

Does Microsoft Copilot respect Microsoft 365 permissions?

Yes. Microsoft 365 Copilot only surfaces organisational data for which the user has at least view permission, and every query runs in the security context of the person writing the prompt. That includes permissions granted to external people, for example in Teams shared channels. The practical consequence is that Copilot also inherits excessive permissions: if a SharePoint site is open to the whole organisation, anyone can get its content by asking. That is why reviewing permissions and links comes before any DLP policy. With agents you also need to check which credentials their tools use, because some can act with their maker’s.

What is DLP for Microsoft 365 Copilot?

It is a Microsoft Purview Data Loss Prevention location, called “Microsoft 365 Copilot and Copilot Chat”, that applies policies to the interaction with the assistant. It can stop Copilot using files and emails with specific sensitivity labels, processing prompts that contain sensitive information types or sending them to web search and, in preview, using emails from external senders. It only exists in the custom policy template and cannot be combined with other locations in the same policy. It does not replace a permissions review, nor does it govern Copilot Studio agent connectors, which depend on Power Platform data policies.

Can you stop Copilot using sensitive information?

Yes, by combining several measures. DLP policies in the Copilot location exclude content with the chosen labels from answers, although the item can still appear in citations. Labels that encrypt require the VIEW and EXTRACT rights for Copilot to summarise; with VIEW only, the assistant links to the document but does not summarise it. Content protected with Double Key Encryption is not accessible to Copilot. While permissions are being reviewed, Restricted Content Discovery removes specific SharePoint sites from answers. None of these measures removes direct access from someone who could already open the document; that is fixed in permissions.

How does Purview DLP work with Copilot when a policy matches?

It depends on the condition. If the item carries a label included in the policy, Copilot does not use its content to answer and, in Word, Excel or PowerPoint, disables its features on that file. If the prompt contains sensitive information types and the action is processing prompts, Copilot does not answer or use the prompt to search. With the web search action, it answers from internal data without querying the web. Policy changes take up to four hours to apply, and files uploaded to the prompt are not scanned. Simulation mode lets you measure the impact before blocking.

Does Copilot Studio use DLP?

It uses two different mechanisms. Power Platform data policies, previously called DLP policies, have applied to every Copilot Studio agent since early 2025 and no longer allow exemptions: they decide which connectors, knowledge sources, channels, HTTP, skills and triggers an agent can use. In addition, Purview DLP in the Copilot location can stop an agent processing content with a specific label when its knowledge is in SharePoint and it is published to Teams, SharePoint or Microsoft 365 Copilot. For agents published to non-Microsoft channels, Purview requires pay-as-you-go billing.

What is the difference between Purview DLP and Power Platform data policies?

Purview DLP looks at content: labels, sensitive information types in the prompt or an email’s sender, and decides whether Copilot can use it. Power Platform data policies look at the agent’s configuration: which connectors, sources, channels, HTTP or triggers it can use, and they block publishing or execution when it does not comply. The first is configured in the Purview portal and usually run by security or compliance; the second, in the Power Platform admin center. An organisation using Copilot and Copilot Studio needs both, because neither covers what the other does.

How do you protect Copilot Studio agents and prevent data leaks?

With controls in several layers: environments separated by risk zone, data policies limiting connectors, HTTP, channels and triggers, knowledge sources with clean permissions and labels, user credentials instead of the maker’s, and confirmation before write actions. For labelled content, Purview DLP can stop the agent processing it if its knowledge is in SharePoint. On top of that comes auditing of maker actions and interactions, and a periodic review of each agent with its owner. With Agent 365 you also get Conditional Access for agents and Defender real-time protection.

What role do sensitivity labels play in Copilot?

Three. They inform users: Copilot Chat shows the highest-priority label among the sources used, and Copilot in Word, PowerPoint and Outlook inherits the source label when creating new content. They restrict access when they encrypt: without the VIEW and EXTRACT rights, Copilot does not summarise the document. And they act as a condition in DLP policies in the Copilot location. For them to work with stored encrypted files, labels must be enabled in SharePoint and OneDrive. A label without encryption or an associated DLP policy informs, but it does not stop Copilot using the content.

Can Copilot read encrypted files?

Yes, if the user asking holds the VIEW and EXTRACT rights on the file and the encryption comes from the Azure Rights Management service, with or without a label. With VIEW but without EXTRACT, Copilot can link to the document but not summarise its content. Content protected with Double Key Encryption is not accessible to Copilot. S/MIME emails are not returned, and password-protected documents are only used if the user already has them open. Encryption with Customer Key or your own key (BYOK) is supported. In Copilot Studio agents, encryption is only supported through labels and with SharePoint as the source.

How do you control connectors in Copilot Studio?

Through data policies in the Power Platform admin center. Each connector is classified as Business, Non-business or Blocked, and an agent cannot combine connectors from different groups. Custom connectors are classified by host URL patterns, and the wildcard rule, which defaults to “Ignore” in new policies, is worth reviewing. Endpoint filtering, in preview, covers HTTP, public websites and SharePoint as knowledge. Advanced connector policies allow an allow-list model per environment, with blocking per MCP server, although they do not yet cover custom or HTTP connectors.

How do you protect agents that use MCP?

First, work out which route the MCP comes through. In Copilot Studio, an MCP server comes in as a Power Platform connector, so data policies govern it, and blocking that connector blocks its tools. Microsoft 365 Copilot federated connectors use MCP with the user’s identity and are managed in the Microsoft 365 admin center. Servers registered in Agent 365 are approved or blocked on the Tools page. In every case, prefer OAuth over API keys, because with a key access does not go through Entra or Conditional Access, and limit which write tools are exposed.

What logs does Microsoft Copilot generate?

Every interaction generates a CopilotInteraction record in Purview Audit (Standard), with no extra configuration if auditing is on. The record includes who, when and where, the resources accessed with their labels, the policies that blocked or restricted access, the agent involved and whether jailbreak attempts or indirect prompt injection were detected. It does not include the text: prompts and responses are stored in the user’s mailbox and viewed with DSPM or eDiscovery. Copilot admin actions and maker actions in Copilot Studio are audited too. Audit (Premium) extends retention.

How do you audit Microsoft agents?

By combining sources. Purview Audit records interactions with agents, with their identifier, name and version, and in Copilot Studio also creation, publishing, sharing and authentication changes. Agents with an Entra Agent ID leave their authentication in Entra logs. In Agent 365, agent instances are audited as users, including their interactions with tools and other agents. DSPM shows agents with activity and high-risk agents on its AI observability page, and Defender adds advanced hunting and runtime alerts, which have required Agent 365 since July 2026.

What role does Microsoft Agent 365 play?

Microsoft presents it as the control plane to observe, govern and secure agents, both its own and third-party ones. It has been available since 1 May 2026 with a per-user licence and is included in Microsoft 365 E7. It provides a unified registry with telemetry, Microsoft Entra identities for agents with Conditional Access and identity protection, integration with Purview for auditing and data protection, and integration with Defender for detection and real-time protection. Copilot Studio agents integrate automatically. It works alongside data policies and Purview DLP, which are still needed.

Which licence do I need for DLP in Copilot?

It depends on the capability. Stopping Copilot processing files and emails with specific labels requires Microsoft 365 E5, Office 365 E5, Microsoft Purview Suite or Microsoft 365 E5 Information Protection and Governance; it is not in Business Premium or Microsoft 365 E3. Protecting prompts that contain sensitive information types is available to all users of Microsoft Copilot and Copilot Chat. Copilot Studio data policies are managed in Power Platform. Agent identities and agent security in Entra and Defender require Agent 365. Always check the current Product Terms.

What I would do this week

1. Check whether the default DLP policy for Copilot is in simulation and what it has logged.
2. Export the agent registry and find the agents with no owner.
3. Confirm auditing is on and search for CopilotInteraction records from the last week.
4. Run an oversharing assessment in DSPM, or the SharePoint Advanced Management access reports.
5. Check whether labels are enabled in SharePoint and OneDrive.
6. Review which Power Platform environments allow HTTP, chat without authentication and unclassified custom connectors.
7. Review which federated connectors are enabled in the tenant.

With those answers you can decide where the first DLP policy makes sense. If you want support, the Data Loss Prevention service starts from that diagnosis and the Microsoft environment security service connects it with identity and licensing. If the focus is AI governance as a whole, AI cybersecurity consulting also covers the AI Act.