Setting Up Your Copilot Studio Environment
How-to guide for setting up your Copilot Studio environment and getting ready to build, including Power Platform environment creation, prerequisites, dev vs. production separation, and security configuration for government clouds.
Overview
Before anyone in your agency creates their first Copilot Studio agent, the environment needs to be properly configured. This means having the right Power Platform environment in place, security roles assigned, DLP policies configured, and a clear separation between where people build and where agents go live. Getting this right from the start prevents security issues, governance headaches, and rework down the road.
This video walks through the complete setup process, from prerequisites through a production-ready configuration, with specific attention to government cloud requirements.
What You’ll Learn
- Prerequisites: What needs to be in place before you start
- Environment creation: How to create and configure a Power Platform environment
- Dev vs. production: Why and how to separate building from deployment
- Security and access: Roles, DLP policies, and access controls
Script
Hook: Set up right from the start
You’re ready to start building with Copilot Studio. But before anyone creates their first agent, you need an environment that’s properly configured — with the right security, governance, and separation between development and production.
Getting this right from the start saves you from rework and security issues later. In the next eight minutes, we’ll set up everything you need to start building agents on a solid foundation.
Prerequisites
Before you open Copilot Studio, confirm that three categories of prerequisites are in place.
First, licensing. At least one Copilot Studio license needs to be assigned — either a paid per-user license or a trial license for evaluation. You also need Power Platform licensing that allows environment creation. Your Microsoft 365 admin can verify license availability in the admin center.
Second, admin roles. Creating a new Power Platform environment requires the Power Platform admin role or Global admin role. Configuring settings within an existing environment requires the Environment admin role. And the people who will actually build agents need the Copilot Studio maker role. Make sure these roles are assigned before you begin setup.
Third, tenant-level settings. Copilot Studio must be enabled in the Power Platform admin center — it’s possible for tenant admins to have disabled it. AI features and generative capabilities must not be blocked by tenant-level policies. And your existing DLP policies should be reviewed to ensure they won’t block Copilot Studio from functioning. A DLP policy that blocks all HTTP connectors, for example, would prevent agents from calling external services.
Confirm all three categories before proceeding. Missing any one of them will block your setup.
Creating a Power Platform environment
Copilot Studio agents live inside Power Platform environments. If you don’t have an appropriate environment, you need to create one.
A Power Platform environment is a container for Power Platform resources — apps, flows, agents, and data. Each environment has its own security configuration, data storage, and settings. Think of it as a workspace where specific groups of people build and use specific solutions.
To create your first environment, navigate to the Power Platform admin center at admin.powerplatform.microsoft.com. Select Environments from the left navigation, then click New to create a new environment.
Give it a name that follows your agency’s naming convention. Something like “Agency-CopilotStudio-Dev” clearly identifies its purpose. For the type, select Developer if this is for individual exploration, or Sandbox if a team will use it for development. Select the region that matches your government cloud — this is important for data residency. And critically, enable Dataverse when prompted. Copilot Studio requires Dataverse for storing agent configurations, conversation data, and knowledge sources. Without Dataverse, Copilot Studio won’t function. Review your settings and create the environment.
Understanding environment types helps you plan. Developer environments are for individual exploration and learning — each maker gets their own space. Sandbox environments support team development, testing, and iteration. Production environments are for live agents serving real users — these should be locked down.
For government agencies, a few notes. In GCC, environment creation works like commercial — the Power Platform admin center is the same experience. In GCC High, make sure you’re accessing the correct government admin portal, not the commercial one. Available regions are limited to government data centers, which is exactly what you want for data residency compliance.
Create the environment, enable Dataverse, and you have a home for your Copilot Studio agents.
Configuring Copilot Studio prerequisites
With your environment created, configure Copilot Studio itself.
Navigate to copilotstudio.microsoft.com — or access Copilot Studio through a link in the Power Platform admin center. Sign in with your government cloud credentials. Make sure you’re signing into the correct cloud — GCC and GCC High have different authentication endpoints.
The first-run experience walks you through initial setup. Copilot Studio will ask you to select an environment. Choose the one you just created. Accept the terms of service and configure initial settings. The first-run experience handles the basics of getting Copilot Studio operational in your environment.
Next, enable AI features at the environment level. In the Power Platform admin center, navigate to your environment’s settings and find the AI features section. Enable generative AI for Copilot Studio. This is what powers the agent’s ability to reason over knowledge sources rather than just following scripted topics. Review the data movement settings carefully — for government environments, you need to confirm that data processing stays within your compliance boundary.
Configure connector policies next. Review which connectors are available in your environment. In the DLP policy settings, connectors are classified as Business, Non-Business, or Blocked. Make sure the connectors your agents will need — SharePoint, Dataverse, HTTP, and any custom connectors — are in the appropriate classification. Blocked connectors can’t be used by any agent in the environment.
Finally, set the default language and region settings for your agents. Most government agencies will use English (United States), but configure this to match your specific needs.
The first-run experience handles the basics. The admin configurations ensure your environment meets government standards from day one.
Development vs. production environments
This is where governance meets practical architecture. You need separate environments for building and for deployment.
The reason is straightforward. Development environments are where makers build, test, and iterate on agents. They experiment, break things, and refine. Production environments are where approved, tested agents serve real users. If you build directly in production, every mistake and half-finished experiment is visible to end users. That’s unacceptable in any environment, but especially in government.
The recommended environment strategy has three tiers. A development environment is open to makers for experimentation and initial building. A test or staging environment is for validation, user acceptance testing, and final review before deployment. A production environment is locked down — only approved agents that have passed testing get deployed here.
Moving agents between environments uses Power Platform solutions. Solutions are packages that contain agents and all their dependencies — topics, knowledge sources, connectors, and configuration. Export a solution from your development environment, import it into your test environment for validation, and then import the validated version into production. This is the standard Power Platform mechanism for application lifecycle management, and it works the same way for Copilot Studio agents.
For government agencies, align this environment strategy with your existing software development lifecycle practices. Document the promotion process so it’s clear for compliance audits. If your agency handles different classification levels, consider separate environments for each level.
Never build directly in production. Use development environments for building, staging for testing, and production for deployment. This is basic governance hygiene.
Managing security and access
Security configuration should be complete before your first maker opens Copilot Studio.
Start with security roles. Power Platform provides several built-in roles. System Administrator has full control over the environment and all resources. Environment Maker can create resources including agents, apps, and flows. Basic User can interact with published agents but cannot create or modify them. You can also create custom security roles tailored to your agency’s specific needs.
Assign roles through the Power Platform admin center. Select your environment, navigate to Security Roles, and assign roles to users. For scalability, assign roles to Azure AD security groups rather than individual users. Create a security group for your Copilot Studio makers, another for your testers, and manage membership through Azure AD. This scales far better than individual role assignments.
DLP policies control which connectors agents can use. This is critical for preventing agents from connecting to unauthorized data sources. Configure DLP policies at the environment level for environment-specific rules, or at the tenant level for organization-wide policies. A well-designed DLP policy allows the connectors makers need while blocking access to services that are inappropriate for government data.
Agent-level security adds another layer. Control who can access and interact with each individual agent. Authentication settings determine whether users must identify themselves before interacting with an agent. Share agents with specific Azure AD security groups to control access.
Security isn’t an afterthought. Configure roles, DLP policies, and access controls before your first maker opens Copilot Studio.
Government-specific setup steps
A few additional steps apply specifically to government environments.
Verify that your environment is provisioned in the correct government cloud region. Check the environment details in the Power Platform admin center to confirm the region. Confirm that AI features are enabled for your government tenant — some government tenants may have these disabled by default. Review DLP policies specifically for government-appropriate connector access — block connectors that aren’t approved for use with government data. Test agent creation with a simple proof-of-concept agent to verify everything works end to end. And document your configuration thoroughly for ATO documentation and compliance reviews.
Government setup adds a few verification steps. Take the time to confirm everything is in the right cloud with the right policies applied.
Close: Your foundation is ready
Here’s how you know your environment is ready. Your Power Platform environment is created with Dataverse enabled. Copilot Studio is accessible and AI features are turned on. Development and production environments are separated. Security roles and DLP policies are configured.
With this foundation in place, your makers can start building agents knowing that governance, security, and compliance are handled from the ground up. In the next video in this series, we’ll create your first agent.
Your environment is the foundation. Get it right, and everything you build on top of it starts from a secure, governed baseline.
Sources & References
- Copilot Studio first-run experience — Initial environment setup and first-run walkthrough
- Create a Power Platform environment — Creating and managing Power Platform environments
- Microsoft Copilot Studio documentation — Documentation hub for all Copilot Studio features
- Power Platform security — Security concepts including roles, DLP, and environment security