Series: Governing AI Agents in Microsoft 365 — Part 1 of 5. This post covers the Power Platform governance layer — DLP policies, connector controls, and environment strategy. Part 2 covers Microsoft Purview.
Governing AI agents in Microsoft 365 means answering five questions across five distinct layers:
- Is this agent well-formed before it exists in production? (Design governance)
- Is this agent safe and correct to promote? (Delivery governance)
- Who is accountable for this agent over time? (Process governance)
- What is this agent technically allowed to access? (Policy and control governance)
- What is this agent actually doing in reality? (Observability and lifecycle intelligence)
This five-part series works through each layer in turn. Posts 1 and 2 cover the policy and control layer — the technical boundaries that determine what agents can connect to, publish, and access. Post 3 covers Microsoft Agent 365, the central governance and management layer. Post 4 covers the process governance layer — ownership, approval, and accountability. Post 5 covers design and delivery governance — the decisions made before an agent reaches production that determine how governable it will be once it does.
Throughout this series, 'agent' refers to AI agents built in Microsoft Copilot Studio or through Microsoft 365 agent capabilities, with governance spanning Power Platform, Entra, Purview, and Microsoft 365 admin surfaces. Copilot Studio, Microsoft Agent 365, and Entra Agent ID are distinct capabilities within that ecosystem.
This post covers the Power Platform governance architecture for agents: Data Loss Prevention policies, connector-level controls, environment strategy, and the Managed Environments capabilities that make governance enforceable at scale. As Copilot Studio agents move into production workloads, this is where most of the day-to-day governance happens — where administrators control what agents can connect to, what they can publish, what knowledge sources they can access, and which environments they operate in. Getting this layer right is the foundation everything else builds on.
DLP Policies as the Primary Governance Mechanism
Power Platform Data Loss Prevention policies are the principal mechanism for controlling agent connectivity and data movement at the connector level. They apply to Copilot Studio agents and related Power Platform capabilities used by those agents, including flows and connector-based actions, and they extend to Agent Flows — the automated workflows agents can trigger as part of their actions.
If your organisation already has DLP policies in place for Power Platform, those policies already apply to agents. The important question is whether they were designed with agents in mind, or whether they predate agent adoption and need to be reviewed in that context.
DLP policies work by classifying connectors into groups — Business, Non-Business, and Blocked — and controlling which groups can be used together. An agent that uses both a SharePoint connector and an external HTTP connector, for example, would be subject to whatever rules govern that combination in your active policies.
The practical implication: an agent is only as trustworthy as the connectors it's allowed to use. Reviewing your DLP policies through the lens of agent use cases — rather than just traditional Power Apps and Power Automate flows — is a meaningful governance step before agents reach production.
Copilot Studio Connectors and What They Control
Copilot Studio introduces a set of Copilot Studio-specific connectors and controls within the DLP framework, distinct from the broader Power Platform connector catalogue. These connectors map to specific Copilot Studio capabilities, which means DLP policies can govern agent behaviour at a feature level rather than just at the data connection level.
The capabilities you can control through these connectors include:
Publishing channels
The Microsoft Teams + M365 Channel in Copilot Studio connector and the SharePoint Channel in Copilot Studio connector can be blocked to prevent agents from being published to those channels. This is a useful staging control: agents can be built and tested in a development environment without being deployable to end users until a deliberate decision is made to allow publication.
Authentication and Exposure Controls
Publishing an agent is only part of the governance decision — who can access it matters just as much. Authentication configuration changes the exposure profile of an agent significantly; an internally authenticated agent presents a different governance risk to one accessible anonymously.
Copilot Studio governance controls — including DLP-backed controls for supported capabilities — can be used to restrict configurations that enable anonymous access scenarios, allowing organisations to enforce authenticated access models where required. This becomes particularly important for agents connected to internal knowledge sources or business systems, where broad external exposure may create unnecessary risk.
From a governance perspective, authentication controls should be considered alongside publishing channels: controlling where an agent can be deployed is only part of the question — controlling who can interact with it is equally important.
Knowledge sources
Four connectors map to specific knowledge source types:
- Knowledge source with SharePoint and OneDrive
- Knowledge source with public websites and data
- Knowledge source with documents in Copilot
- Knowledge source with Dataverse
Each can be blocked independently. This means you can allow agents to query internal SharePoint content while preventing public web browsing, or restrict document uploads entirely, depending on your organisation's data handling requirements.
Dataverse knowledge sources follow the same connector-level controls, though access governance also extends to Dataverse security roles and row-level security — an additional layer that SharePoint-based agents don't have.
Endpoint URL controls
Certain knowledge source connectors support URL-based configuration and restrictions, allowing administrators to scope permitted endpoints rather than applying broad allow/block decisions.
This level of granularity matters. Blocking all web access is a blunt instrument; the ability to scope access by URL gives administrators a more proportionate set of options.
Environment Strategy — The Often Overlooked Layer
DLP policies are applied at the environment level, which means your environment strategy directly shapes your governance posture. This is the layer that most organisations don't think through systematically until agents are already in production and the governance gaps become apparent.
A structured environment approach for agent development typically involves at least three tiers:
Development — where agents are built and tested by makers. DLP policies here can be more permissive to allow experimentation, but should still restrict publishing to production channels. Agents in this environment should not be accessible to end users.
Test/UAT — where agents are reviewed before promotion. DLP policies should mirror production. This is where governance checks happen: ownership is confirmed, knowledge sources are reviewed, the agent's behaviour is validated against its stated purpose.
Production — the environment end users interact with. Production environments should have the most tightly governed policies. Organisations should aim to ensure agents reach this environment only through a defined promotion process rather than direct deployment by makers.
The governance value of this structure is that it creates natural checkpoints. A structured environment model makes controlled promotion possible and easier to enforce.
Environment strategy also matters for policy inheritance. Policies applied to the default environment don't automatically apply to custom environments. Organisations that have created environments for specific departments or projects without reviewing the DLP policies in those environments may have governance gaps they're not aware of.
Managed Environments
Standard environments give you the structure — Managed Environments give you the controls to enforce it. Managed Environments is a Power Platform feature that unlocks a set of governance capabilities not available in standard environments, and are increasingly becoming a practical baseline for production-scale agent deployments.
The governance capabilities Managed Environments add include maker controls — restricting who can create and share canvas apps, flows, and agents within the environment; solution checker enforcement — supporting automated quality and best-practice checks that can be integrated into deployment processes; pipeline integration — enabling structured, governed promotion of solutions between environments rather than ad hoc deployment; and usage insights — providing visibility into what's being used, by whom, and how often. Managed Environments also introduce environment routing controls, helping steer makers toward approved development environments instead of default or unmanaged locations. For organisations building agents at scale, enabling Managed Environments on production (and ideally test) environments is a meaningful step toward a governable agent estate rather than just a governed one.
Applying Policies to the Right Environments
A common gap in Power Platform governance is policies that exist at the tenant level but haven't been scoped to the environments that need them. DLP policies can be applied to:
- All environments in the tenant
- All environments except specific exclusions
- Specific named environments only
For agent governance, the recommended approach is to have a baseline policy applied tenant-wide that sets minimum standards — blocking the highest-risk connector combinations — and then environment-specific policies that apply additional restrictions appropriate to that environment's purpose.
For example: a production environment hosting agents that access HR data might have a more restrictive policy than the general production environment, blocking public web knowledge sources entirely and restricting SharePoint access to specific sites. That restriction lives at the environment level without affecting agents in other environments.
What This Layer Doesn't Cover
Power Platform governance controls at the environment and DLP layer determine what agents can connect to, where they can be deployed, and how exposure to users is governed. They don't control how agents use the data they access, how sensitive content in responses is handled, or how agent activity is monitored for compliance. That's the Purview layer — covered in Part 2 of this series.
They also don't address the process layer: who approves an agent before it reaches production, who owns it, what happens when it degrades. That's the governance gap covered in Part 4.
The Power Platform layer is necessary but not sufficient. It sets the boundaries. The rest of the framework determines what happens within them.
Where to Start
If you're reviewing your Power Platform governance posture with agents in mind, the highest-impact starting points are:
- Audit your existing DLP policies and check which environments they apply to — are there gaps?
- Review Copilot Studio-specific connectors in your policies — are knowledge source, publishing channel, and authentication controls configured deliberately?
- Check whether your environment structure supports a dev/test/production separation for agent development
- Confirm that production environments have publishing channel restrictions in place so agents can't go live without a promotion process
- Review whether Managed Environments is enabled on your production environment — and if not, whether the governance capabilities it unlocks are worth enabling
None of this requires building from scratch. Most organisations have DLP policies and environments already. The work is reviewing them through the lens of agent governance and filling the gaps that weren't relevant before agents existed.
Part 2 of this series covers Microsoft Purview — sensitivity labels, DLP for AI responses, Data Security Posture Management, and AI Observability.