16.4 Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory
Key Takeaways
- Power Platform data policies configured in the Power Platform admin center govern Copilot Studio agent capabilities including maker and user authentication, knowledge sources, actions, connectors and skills, HTTP requests, publication to channels, Azure Monitor Application Insights, and triggers.
- Governing triggers is how autonomy is governed: Microsoft positions data policies as the mechanism for managing agent capabilities with triggers to protect against data exfiltration and other risks.
- In the Default environment all users in the tenant are granted the Environment Maker role, which is why environment routing into personal developer environments is a first-order governance control rather than a convenience feature.
- Copilot Hub in the Power Platform admin center provides agent usage and adoption visibility and pay-as-you-go Copilot credit caps, while maker audit logs flow to Microsoft Purview and alerting flows to Microsoft Sentinel.
- Customer Lockbox does not cover all outbound data from Copilot Studio: Copilot Studio security audit logging and Microsoft Agent 365 governance and audit events are both excluded, so presenting Lockbox as blanket coverage misstates the control.
Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory
Quick Answer: Governance for agents is a control plane, not a policy document. Designing it means placing every agent inside an environment perimeter and then attaching enforceable controls to that perimeter. In Power Platform the primary instruments are data policies configured in the Power Platform admin center, which govern maker and user authentication, knowledge sources, actions/connectors/skills, HTTP requests, publication to channels, Azure Monitor Application Insights, and triggers; environment routing, which gives makers a safe default place to build; maker welcome messages; customer-managed encryption keys (CMK); and the tenant-level ability to turn off publishing of agents that use generative AI features and to disable data movement across geographic locations for Copilot Studio generative AI outside the United States. Visibility comes from the Copilot Hub in the Power Platform admin center for usage and Copilot-credit governance including pay-as-you-go credit caps, from maker audit logs in Microsoft Purview, and from audit logs in Microsoft Sentinel for alerting. Makers get agent runtime protection status, an automatic security scan that raises a pre-publish warning when security defaults are modified, and real-time risk assessment while configuring knowledge, tools, and actions. Microsoft Agent 365 acts as a central control plane where Copilot Studio agents can be represented as Microsoft Entra identities governed with Conditional Access, role- and attribute-based access control, and access-governance workflows. Microsoft 365 Copilot agents are separately governed in the Microsoft 365 admin center.
Security answers "can this agent be attacked?" Governance answers a different question: "does the organisation know this agent exists, who owns it, what it can reach, and what it is costing?" An organisation can have hardened every agent and still have no governance, because nobody can enumerate them.
Designing governance for agents is a distinct blueprint bullet, sitting alongside designing security for agents and designing model security. The exam tests the distinction.
1. The Perimeter: Environment Strategy First
Environments are the containers for every resource used by Power Apps, Power Automate, Dataverse, and Copilot Studio agents. Every governance control worth having attaches to an environment or a group of them, which makes environment design the first governance decision rather than an infrastructure afterthought.
Two facts shape the design:
- In the Default environment, all users in the tenant are granted the Environment Maker role. Left alone, the Default environment becomes the place where ungoverned agents accumulate.
- Users with the Power Platform Administrator role have admin access to all environments.
The standard remediation is environment routing, which Microsoft positions explicitly as a way for admins to give makers a safe space to build agents — new makers are routed into a personal developer environment instead of Default. A maker welcome message can be configured to inform makers about privacy and compliance requirements at the moment they start building, which is the only moment most of them will read it.
Environment strategy should separate at minimum: personal developer environments (routed, disposable), team development, test/UAT, and production — with production restricted so that agents arrive only through a pipeline.
2. Data Policies: The Primary Enforcement Instrument
Power Platform data policies (historically called DLP policies) enforce rules about which connectors can be used together by classifying them as Business, Non-Business, or Blocked. A connector in the Business group can only be used alongside other Business connectors in the same application. Administrators can define policies scoped to all environments, or scoped to include or exclude specific ones. Some connectors cannot be blocked.
For agents specifically, Microsoft states that data policies in the Power Platform admin center govern the use and availability of Copilot Studio features and agent capabilities including:
- Maker and user authentication
- Knowledge sources
- Actions, connectors, and skills
- HTTP requests
- Publication to channels
- Azure Monitor Application Insights
- Triggers
That last item is the autonomous-agent control. Microsoft calls it out directly: admins manage agent capabilities with triggers using data policies, protecting against data exfiltration and other risks. An autonomous agent is defined by its trigger; governing triggers governs autonomy.
Connector dependency insights let admins review the connector dependencies an agent uses, so data-movement risk can be understood and controls applied before deployment rather than after an incident.
3. Tenant-Level Switches
Three tenant-level controls appear repeatedly in expert scenarios:
| Control | Effect |
|---|---|
| Disable agent publishing | The Power Platform admin center can turn off the ability to publish agents that use generative AI features for the tenant |
| Disable cross-geography data movement | Blocks data movement outside the United States for Copilot Studio generative AI features |
| Microsoft 365 admin center agent governance | Governs which conversational and AI actions and agents appear in Microsoft 365 Copilot |
The third is the one architects miss. Copilot Studio agents surfaced into Microsoft 365 Copilot cross a governance boundary: Power Platform governs how they are built and what they connect to, while the Microsoft 365 admin center governs whether users see them. A complete design names both.
4. Maker-Side Guardrails
Governance that only exists in the admin centre is discovered too late. Copilot Studio pushes controls to the point of authoring:
- Agent runtime protection status — makers see the security status of their agents from the Agents page.
- Automatic security scan — makers see a security warning before publishing when security and governance default configurations have been modified.
- Real-time risk assessment — continuously updated risk findings while configuring knowledge, tools, and actions, so makers can remediate potential data exfiltration or security issues before publishing.
- Sensitivity labels for SharePoint knowledge — makers and users can see the highest sensitivity label applied to sources used in a response, plus individual reference labels in the chat.
- Run tools with user credentials — makers can configure tools to use the invoking user's credentials by default, so the agent cannot exceed what the user could do unaided.
5. Inventory, Observability & Cost
Governance needs an answer to "what exists". The Power Platform admin center provides Copilot Hub for monitoring agent usage and Copilot adoption trends and for setting pay-as-you-go Copilot credit caps to manage spend. Cost governance belongs here rather than in finance, because an uncapped pay-as-you-go environment is a governance failure with a bill attached.
Audit coverage has two destinations with different purposes:
| Destination | Purpose |
|---|---|
| Microsoft Purview | Full visibility into maker audit logs — who built and changed what |
| Microsoft Sentinel | Monitoring and alerting on agent activities — detection and response |
Microsoft Agent 365 extends this materially. For organisations that onboard it, Copilot Studio agents can be represented as identities in Microsoft Entra, governed with Conditional Access, role-based and attribute-based access controls, and access-governance workflows, with centralised observability, agent inventory, ownership telemetry, and policy enforcement — and Microsoft Entra network egress and ingress controls applied to Copilot Studio agents. This is the shift from governing agents as resources to governing them as principals.
Source control is part of governance too: GitHub integration and deploy-from-Git give admins and makers auditable deployment history rather than untraceable maker-portal edits.
5.1 A Customer Lockbox Caveat
Copilot Studio supports Customer Lockbox, but Microsoft is explicit that it does not cover all outbound data. Two categories are excluded:
- Copilot Studio security audit logging — agent invocation events, tool and action calls, policy enforcement decisions, and runtime activity signals are processed by the Microsoft Purview audit logging pipeline rather than the Copilot Studio service.
- Agent 365 governance and audit events — certain governance, telemetry, and audit events flow through Microsoft Agent 365.
An architect presenting Lockbox as blanket coverage to a regulated customer has mis-stated the control.
6. Alert, Action & the CoE
Beyond the built-in surfaces, Microsoft's governance guidance points to programmatic control: Power Apps admin PowerShell cmdlets, the Power Platform for Admins and Power Automate Management connectors, subscribing to Microsoft 365 audit events via webhook or polling to drive Power Automate alerting, and the Center of Excellence (CoE) Starter Kit for inventory and adoption dashboards. Activity logging for Power Apps integrates with the compliance centre and is exposed through an API that SIEM vendors consume.
The design principle: every governance rule should map to a mechanism that produces evidence. A rule enforced by a data policy produces a block event. A rule enforced by a documented standard produces nothing.
7. A Governance Design Checklist
- Perimeter — environment strategy defined; environment routing configured; Default environment contained.
- Connectivity — data policies classify every connector; policies scoped deliberately to environments; trigger capabilities governed for autonomous agents.
- Publication — tenant setting for generative-AI agent publishing decided; Microsoft 365 admin center governance defined for agents surfacing in Microsoft 365 Copilot.
- Residency — cross-geography data movement decision recorded; CMK evaluated.
- Identity — tool authentication default set; Agent 365 adoption decided for Entra-identity governance and Conditional Access.
- Inventory — Copilot Hub monitored; CoE Starter Kit or Agent 365 inventory in place; every agent has a named owner.
- Cost — pay-as-you-go Copilot credit caps set per environment.
- Audit — Purview maker audit logs reviewed; Sentinel alerting configured; Lockbox exclusions documented.
- Change control — GitHub-backed source control and deploy-from-Git; production maker-portal editing prohibited.
AB-100 Exam Tip: Distinguish the three governance planes by what is being governed. What an agent may connect to and publish through is a Power Platform data policy. Whether users see an agent in Microsoft 365 Copilot is the Microsoft 365 admin center. Who or what the agent is, and what it may access as a principal is Microsoft Entra, reached through Microsoft Agent 365 with Conditional Access and access reviews. Scenarios that describe agent sprawl, unknown ownership, or uncontrolled spend are inventory and Copilot Hub questions, not security-hardening questions — answers proposing content filters or prompt shields are solving the wrong problem.
A bank has hardened every production agent with content filters, prompt shields and groundedness checks, yet the chief information security officer cannot answer how many agents exist, who owns them, or what they connect to. Which characterisation and remedy are correct?
An architect must prevent a newly built autonomous agent from being triggered by events that could cause data exfiltration, while leaving the same agent available for user-initiated conversations. Which control is designed for this?
A regulated customer asks whether Customer Lockbox gives it approval rights over all Microsoft access to data flowing out of its Copilot Studio agents. What is the accurate answer?
You've completed this section
Continue exploring other exams