Your agent needs a zone

Before you decide what an agent can do, decide where it is allowed to live.

Sounds boring, I know. But when you let people build agents you create a placement problem. Agents come in at least three sizes — a personal helper, a team tool, something the business depends on — and forcing them under one set of rules leaves you choosing between two bad outcomes. Either you govern everything like production and small ideas get stuck, or you govern everything like experimentation and important agents outgrow the place they were built in.

A zone strategy gives you a third option: a safe place to start, a clear path to grow, and a line that says this agent has crossed into a different kind of responsibility.

What a zone decides

A zone is a promise about risk. It says that if you build here, these are the rules — who can build, who can use it, what data and tools are allowed, and how far the agent can go before it needs another review.

Agents can read knowledge, call tools, use channels, trigger workflows, and sometimes act without a person writing every step, so the container they live in matters. For Copilot Studio agents that container is a Power Platform environment: a separate space with its own data, its own users, and its own permissions and policies. The environment is where the agent's architecture starts.

The three zones to start with

You do not need a perfect taxonomy to begin. Start with three zones.

The names don't matter. Every agent needs somewhere to go, and every zone needs a promotion trigger — the moment an agent must move up. For example:

• It needs to be shared beyond the maker.
• It reads sensitive or business-critical data.
• It uses write actions, HTTP, premium connectors, MCP servers that let it call outside tools, or external services.
• It becomes part of a recurring business process.
• It needs a named support path.
• It affects customers, suppliers, finance, HR, compliance, safety, or other high-stakes work.

Triggers matter because risky agents rarely start risky. They get riskier as they get more useful to more people.

Zone 1 still needs rules

A personal sandbox is not a permission slip. In regulated tenants, even the green zone needs a fence.

The point of Zone 1 is to let people explore without every experiment piling up in the default environment — the one every tenant gets automatically, where everyone can already build. Makers get somewhere safe to try things without accidentally publishing to the world, connecting to the wrong data source, or turning a small helper into a team tool nobody owns.

If everything lands in the default environment instead, the design can't answer basic questions:

• Who can build here?
• Who can share?
• Which policies apply?
• Which agents are experiments, and which are production?

When people can't get those answers from the environment design, they answer them from habit — and habit means building in the first place they can.

Without routing, a maker who opens Copilot Studio for the first time lands in that default environment. If they know enough to go looking, they pick from a list of environments that tells them nothing about which one is safe for what.

Environment routing changes where that first click puts them. You turn it on in the Power Platform admin center, choose which portals it covers — Copilot Studio, Power Apps, Power Automate, Power Automate for desktop — and write a rule: everyone, or a named security group. A maker who matches gets a personal developer environment, a single-user space where they hold the admin role, and it joins the environment group you name in the rule. If no rule matches, they land in the default environment as before. If they already own a developer environment, routing sends them there instead of creating one, which means switching routing on does not retrofit the sandboxes people made for themselves last year. You add those by hand, and they become managed environments when you do.

The environments routing creates are managed environments, the tier where an admin can set rules on the environment itself, and they arrive with a few defaults like Solution Checker set to warn on risky patterns. The controls that matter for agents are the ones you publish as group rules: whether an agent can be shared as an editor or a viewer, whether it can go to a security group at all, and how many viewers it can reach. That covers the small helper that turns into a team tool nobody owns.

Connectors are a separate question. There is now a connector policy you can set at group level, still in preview, but the Copilot Studio controls — channels, unauthenticated chat, knowledge sources — come from your tenant data policies, the rules that decide which connectors and channels an agent is allowed to use. Makers can also still switch environments, and they can create their own outside the group unless you restrict developer environment creation in tenant settings.

A Copilot Studio licence already covers managed environments, so the agent path adds no licence cost — but the free Developer Plan does not cover running what gets built in a managed environment, so a maker relying on it needs a real licence once routing makes their sandbox managed. Routed environments also expire: sixty days without activity and the environment is disabled; fifteen days after that it is deleted, with a seven-day window to recover it; and there is no setting to turn any of that off. Activity resets the clock and admins get warned twice before each step, but a maker who builds something in March and comes back in June will find it gone.

Who can open Copilot Studio, and who can build safely

Access to Copilot Studio is one gate. Permission to build in the right environment is another.

Power Platform tenant settings include a Copilot Studio authors setting where you name a security group. It grants access to that group under pay-as-you-go licensing. It does not revoke access from anyone else. Someone outside the group who holds a Copilot Studio licence, a trial, or a Microsoft 365 Copilot licence can still open the product, so closing the gate means controlling licence assignment, not just group membership.

A maker also needs a security role in the environment itself — the permission set that decides what they can do inside it. Environment Maker is the role for authoring agents.

This is how you set it up:

1. Create an approved maker group, for example Copilot Studio Authors.
2. Use that group together with licence assignment to control who can reach the authoring experience.
3. Use environment routing to drop those makers into their own sandbox.
4. Give the group the Environment Maker role in the Zone 2 team build environment.
5. Remove the person from the group when they should no longer build.

Let one group carry the chain as far as it can, because access granted by hand stops being tracked.

Environment groups let you set rules once

Set a rule on an environment group and it applies to every environment in it, instead of clicking through each one. A tenant won't have thousands of agents on day one, but it can easily have dozens of maker sandboxes before anyone has time to clean them up, which is exactly the problem group rules solve.

For a personal sandbox group, the rules might say:

• Show maker welcome content so people know what they can build.
• Limit how far an agent can be shared, and whether it can go to a security group at all.
• Restrict external models.
• Control which generative AI settings are allowed.
• Enforce Solution Checker where relevant.

Check the status of each rule before you lean on it. Some are still in preview, which means Microsoft can change or withdraw them. Use preview features deliberately, label them in your own documentation, and re-check them before they become part of a production standard. Set rules at the zone level, not one environment at a time.

The middle zone is where most real work appears

Zone 2 is the awkward one. Personal sandboxes are easy to understand and Zone 3 is easy to take seriously; the team zone is where it gets messy.

This is where someone builds an agent for the department. It reads a shared SharePoint site, helps with case handovers, answers questions about internal process, calls a flow. It becomes useful enough that people ask, "Can we share this with the whole team?"

That is not automatically a production system, but it is not personal anymore either. The middle zone needs a different deal: makers can still build, but not in isolation. Data sources should be approved; sharing should go to named users or security groups rather than everyone because it was easier; ownership should be visible; and the agent should get a basic review before it becomes part of a team workflow.

If the only path out of a personal sandbox is a heavy production review, people will keep team agents in the wrong place. Give them a clear team zone and they have somewhere to go.

Enterprise means the agent is now a system

An agent reaches Zone 3 when it serves a broad audience, touches sensitive data, writes back to business systems, uses autonomous triggers, carries compliance impact, or supports a process people rely on. That is where named sponsorship, proper deployment, monitoring, identity review, data protection review, and a retirement path belong.

There is also a critical-infra habit that belongs here: contain the risky exception instead of loosening the rule for everyone. Say one agent needs an open web channel — a Direct Line channel that lets people reach it from a public website, sometimes without signing in. Most agents in a regulated tenant should never have that.

The wrong fix is to relax the tenant-wide data policy so the channel is allowed everywhere. The right fix is to carve out one environment: exclude it explicitly from the tenant policy, give it its own tight policy in place of that, and put the agent there. An environment policy cannot override a tenant one, so the carve-out is the step that makes this work, and it leaves the exception named and auditable rather than widening the rule for everybody. The channel and the sign-in requirement are two separate controls, so allowing Direct Line does not by itself allow anonymous access.

The EU AI Act is a useful mental model here, even when your internal agent is not automatically a high-risk system. The Act is risk-based: for high-risk systems it puts weight on risk management, logging, human oversight, and obligations on the organisation running the system. A couple of duties don't wait for that classification, though. Telling people they are interacting with an AI rather than a person is one, and it lands squarely on the public-website example above.

Do not argue about whether every internal agent belongs in a legal category before you design the basics, ask the architecture question instead: can we show who owns it, what it can reach, what it did, who approved it, and how we stop it? If the answer is no, it is not ready for Zone 3.

Where to start

Sketch your zone map. Open the Power Platform admin center, go to Manage → Environment groups, and sketch three groups:

1. Zone 1 — Agents | Personal sandbox
2. Zone 2 — Agents | Team build
3. Zone 3 — Agents | Enterprise managed

For each one, answer these questions:

If you only do one thing this week: create the personal sandbox group, turn routing on for a pilot group of makers, and add a welcome message. Routed environments already arrive with sharing limits applied, so check those and tighten them if you need to. Anything to do with channels, authentication or connectors is a data policy rather than a group rule, and lives under Security → Data and privacy.

Then get one maker to try it. Can they land in the right environment, build, see the welcome message, and tell you when their agent would need to move up? That, rather than how the diagrams look in a 50-page governance document, is what tells you the zone map works.

A zone strategy tells the maker: you are allowed to build here, and here is what happens when "here" stops being enough.