In the last article, I covered how to design and configure your knowledge layer – the data and permissions foundation that determines what your agent can retrieve.

This article covers the final dimension of Stage 3 readiness before you move into solution design.

Environment strategy and governance foundations.

Part One : The Concept

Why environment strategy is a readiness decision not a deployment detail

In Power Platform, an environment is not just a container. It is a governance boundary. It determines what data agents can access, what connectors are available, who can build, who can publish, and what policies apply.

Building agents in the wrong environment or treating environment strategy as something to figure out later creates problems that compound over time. Agents built in the default environment share data, connectors, and governance policies with every other solution in that environment. What starts as a quick proof of concept becomes a production dependency with no isolation, no controlled deployment path, and no meaningful way to apply different governance rules to different agents.

Environment strategy is not an IT concern that happens after design. It is a readiness decision that shapes everything built on top of it.

What most teams have versus what good looks like

The minimum viable environment foundation before any agent goes to production: separate Prod environment, managed environments enabled, DLP policy in place, maker access to Prod restricted.

Maker versus IT ownership – drawing the boundary

This is the most politically charged decision in enterprise Power Platform governance and the one most often avoided until it causes a problem

Business users and functional consultants should own agent design and configuration in development environments. They understand the business process, the user need, and the knowledge domain. Constraining them too tightly in Dev kills the speed and business alignment that makes Power Platform valuable.

IT should own production. Not the agent design – the environment, the DLP policies, the deployment pipeline, and the governance controls. An agent that a maker builds in Dev should be promoted to Prod through a managed solution deployment that IT controls. Not copied manually. Not rebuilt. Promoted through a repeatable, auditable process.

The failure mode is one of two extremes: makers with no guardrails building directly in production, or IT lockdown so tight that the platform cannot be used effectively. The boundary is not about who is more trusted it is about who owns what layer.

Part Two : Implementation

Order of operations

1. Design your environment structure before creating environments Decide how many environments you need, what each one is for, and what the promotion path between them looks like. Creating environments without this design leads to environment sprawl that is harder to govern than the problem you were trying to solve.

2. Create environments with the right settings from the start
Region, currency, and language settings cannot be changed after environment creation. Get these right before anything is built.

3. Enable managed environments in Prod and Test before agents are deployed
Managed environment features cannot be applied retroactively to agents already built with unmanaged solution dependencies. Enable managed environments before the first managed solution is deployed.

4. Design and apply DLP policies before makers start building
DLP policies applied after connectors are already in use can break existing agents. Design the DLP policy architecture first, apply it to environments, then invite makers in.

5. Configure the Copilot Control System before M365 Copilot is enabled
Tenant-level Copilot settings default to permissive. Review and configure them before users start interacting with Copilot not after the first governance incident.

6. Establish the maker access model and communicate it
Define who can build in which environment, who approves production deployments, and what the promotion process looks like. Document it. Communicate it before makers start building.

Environment structure : the decision

Note: the following are practical design patterns based on common enterprise deployment scenarios – not official Microsoft-defined environment tiers. Microsoft’s guidance is to establish an environment strategy that matches your organisational structure and governance requirements. These patterns are a starting point, not a prescription.

Pattern 1 : Single programme, small team

Dev (unmanaged)  →  Test (managed)  →  Prod (managed)

One development environment shared by the team. Agents built and iterated in Dev, tested in Test, promoted to Prod via managed solutions. Appropriate for a single AI programme with a small, coordinated team.

Pattern 2 : Multiple programmes, shared Prod

Programme A Dev  →  |
Programme B Dev  →  | Shared Test  →  Shared Prod
Programme C Dev  →  |

Separate development environments per programme or team, shared Test and Prod. Each programme maintains its own DLP policies in Dev, shared governance in Test and Prod. Appropriate for organisations with multiple parallel AI programmes using the same Prod tenant.

Pattern 3 : High-governance or regulated environments

Dev  →  SIT  →  UAT  →  Prod

Full environment promotion path with system integration testing and user acceptance testing stages. Each environment fully isolated with its own DLP, managed environment settings, and access controls. Appropriate for government, financial services, or healthcare deployments where audit and change control requirements are strict.

The decision rule: start with Pattern 1. Move to Pattern 2 when you have more than one team building simultaneously. Move to Pattern 3 when regulatory or audit requirements mandate it – not before.

Managed environments : what they give you and when to enable them

Managed environments unlock governance controls that are not available in standard Power Platform environments. For any environment where agents will be used in production, managed environments should be enabled.

Key capabilities that matter for AI agent governance:

Sharing controls : restrict who can share agents with whom. Prevent makers from publishing agents to the entire organisation without approval. Define maximum audience scope per environment.

Solution checker enforcement : require solutions to pass quality checks before they can be imported into the environment. Catches common build problems before they reach production.

Usage insights : surface agent usage telemetry at the environment level. Who is using which agents, how often, with what outcomes.

Maker welcome content : configure what makers see when they first access the environment. Use this to communicate governance expectations, DLP boundaries, and deployment process before they build anything.

Enable managed environments in the Power Platform admin centre at the environment level before the first production deployment. The decision to enable managed environments after agents are already deployed is significantly more complex existing unmanaged solutions may need to be restructured.

DLP policy design for agent environments

Data Loss Prevention policies in Power Platform control which connectors can be used together in the same flow or agent. For AI agent deployments the key design decision is the Business / Non-Business / Blocked connector classification.

The principle: connectors that handle sensitive organisational data should sit in the Business tier. Connectors that should never be used in production agent flows should be Blocked. Everything else sits in Non-Business usable but not combinable with Business connectors in the same solution.

For agent environments, classify at minimum:

Business tier – Dataverse, SharePoint, Microsoft 365, Teams, Outlook, Dynamics 365, Azure services used in production.

Blocked tier – consumer social connectors, any connector not approved for enterprise use, HTTP connector in production environments where arbitrary outbound calls are not appropriate.

The connector conflict that catches most teams

The HTTP connector is classified as Non-Business by default. Many Copilot Studio agents use HTTP connector actions to call external APIs. If your DLP policy places Dataverse in Business and HTTP in Non-Business, agents that combine both will break when the policy is applied. Additionally, child flows share an internal dependency with the HTTP connector – the grouping you choose for HTTP in your DLP policy may affect whether child flows can run in that environment at all. Design the DLP policy with your planned connector combinations in mind not just individual connector classifications.

Test DLP policies against existing agents in a non-production environment before applying to production. DLP policy violations surface as errors at runtime not at build time.

The Dataverse constraint

One constraint that shapes DLP design for agent environments specifically: the Dataverse connector cannot be blocked. Dataverse is an integral part of Power Platform and Microsoft does not permit it to be placed in the Blocked tier. If your governance requirement is to prevent agents from accessing specific Dataverse tables, DLP is not the right control. Dataverse security roles and table-level column security profiles are. Design your Dataverse access controls at the data layer, not the DLP layer.

Copilot Control System – what to review before deployment

The Copilot Control System in the Microsoft 365 admin centre controls what Copilot features are available to which users across the tenant. The defaults are permissive. For enterprise deployments, review these settings before M365 Copilot is enabled for users.

Settings worth reviewing before go-live:

Copilot in Teams meetings – access to meeting transcripts and recordings for Copilot is governed through the Teams admin centre, not directly through the Copilot Control System. In the Teams admin centre, review intelligent meeting recap and transcript settings before M365 Copilot goes live. The Copilot Control System in the M365 admin centre controls broader Copilot access and agent management = Teams meeting-specific features have their own governance path and should be reviewed in parallel.

Copilot web search – controls whether M365 Copilot can search the public web to supplement responses. If not configured, web search is available by default. In regulated environments such as healthcare, government, financial services review whether web search is appropriate before enabling. When web search is on, search queries are handled under the Microsoft Services Agreement rather than the Data Protection Addendum, which has implications for regulated industries.

Copilot for specific apps – individual app-level controls allow you to enable M365 Copilot in specific Microsoft 365 applications before a full rollout. Use this to run a controlled pilot rather than enabling everything simultaneously.

Agent publishing controls – in the Power Platform admin centre, controls whether makers can publish agents to Teams or the organisation. Restrict this in production environments – publishing should go through the managed solution promotion process, not directly from a maker’s development environment.

The Copilot Control System is not a one-time configuration. It is an ongoing governance tool. Assign ownership of these settings to a named person or team before go-live not a shared admin account with no clear owner.

Business users versus IT – the ownership table

Define this before anyone starts building:

Shared decisions , connector governance should have a defined proposal and approval process. Makers identify what they need. IT evaluates the governance implications and approves or rejects with a documented reason.

Dataverse security roles and table-level permissions are explicitly IT-owned. As established above, DLP cannot be used to restrict Dataverse access -the data layer controls must be designed and owned by IT before agents go live.

Without this table, every governance decision becomes a negotiation. With it, the boundary is clear before the first agent is built.

Pre-build checklist

Environment structure:

• Environment structure designed before environments created
• Separate Dev, Test, and Prod environments in place
• Region, currency, and language set correctly at environment creation
• Managed environments enabled in Test and Prod before first deployment

DLP policies:

• Business / Non-Business / Blocked connector classification designed
• Connector combinations validated against planned agent architecture
• HTTP connector classification decision documented – child flow dependency considered
• Dataverse access controls designed at data layer – security roles and column security profiles, not DLP
• DLP policy tested against existing solutions before applying to production

Access and ownership:

• Maker access model defined per environment
• Production deployment process documented – managed solutions only
• Ownership table agreed between maker and IT teams
• Dataverse security role design completed before agents go live

Copilot Control System:

• Teams admin centre transcript and meeting recap settings reviewed
• Web search setting reviewed for regulated environments
• Agent publishing controls restricted in production environments
• Named owner assigned for ongoing Copilot Control System governance

What comes next

Stage 3 : Validate Readiness is now complete across all three dimensions:

• Organisational readiness : Blog 4
• Data, knowledge, and permissions : Blog 5
• Environment strategy and governance foundations : Blog 6

The next article moves into Stage 4 : Design Solution. With the foundation in place, the focus shifts to how you actually design agents that work reliably in the environment you have just built – solution architecture, layered design patterns, human-in-the-loop placement, and where to draw the boundary between AI reasoning and deterministic process execution.