Graduated environments are what make promotion gates real. A gate is a zone transition with a border to enforce, and without separate zones a “gate” is a meeting that changes nothing an agent can actually do.

The mechanism

A review that does not change what an agent can reach is a review of a document. The zone pattern exists so that passing a gate moves the agent across a boundary where its credentials, its data scope, and its reachable destinations are all different. The environment is the enforcement container: it defines data boundaries, security roles, data policies and lifecycle separation, and it is the thing an administrator can actually configure.

Microsoft’s shipped model is the clearest worked example, and it is product documentation rather than a whitepaper’s aspiration. Zone 1, citizen development: anyone can build personal or team agents over content they already have access to, read-only, private, restricted to first-party connectors, running in the user’s own security context. Zone 2, partnered development: trained makers working with a coach build for other teams, with admin-approved environment provisioning, scoped sharing, ALM pipelines, and IT approval required to publish. Zone 3, professional development: IT-led only, mission-critical, organisational ALM, the strongest controls, and agents that can carry service-level agreements.

Zones sort agents by how much review the agent has survived rather than by importance, and the data policy gradient is the tell. Strictness runs backwards from what most engineers expect: strictest in personal development environments, where unauthenticated agents and most channels and connectors are blocked, and relaxing through dedicated development to test and production. An unreviewed agent gets a small blast radius no matter how trivial it looks; a reviewed agent earns reach.

The pattern is convergent rather than a vendor invention. Shell’s DIY programme plotted criticality against complexity with green, amber and red bands in 2019; PMI’s and Gartner’s citizen-development models use the same two axes; Microsoft’s 2026 zone diagrams plot risk against technical complexity. Unrelated parties, seven years apart, keep drawing the same chart. Precedent for Zone 1 predates the agent wave: a 2024 multi-case study of low-code programmes describes “playground” environments where initial access is unrestricted and advanced capabilities activate only on request, against a restrictive alternative gating entry behind certification.

Segmentation itself is ordinary practice: payments firms isolate cardholder-data systems, hospitals separate networks by data category, routers ship guest networks. State the payments analogy precisely, because the loose version is wrong: PCI DSS does not mandate segmentation. Its guidance treats segmentation as the recommended way to reduce the scope of what has to be assessed. That is the better argument anyway, because zones shrink the blast radius and the review surface at once, which makes governance affordable rather than merely stricter.

What to do

The cheap version is two zones, carved from the environment separation most firms already have: personal sandboxes where anyone can build against data they already hold, and one governed zone that anything shared has to enter. Two zones with a real border beat three zones on a slide.

The thorough version is three, with per-zone credentials, per-zone egress policy, ALM pipelines between them, and automated demotion for agents that go idle. The process and authority at each transition belong to promotion gates; which zone an agent starts in comes from risk tiers.

Three configuration facts decide whether a firm has the pattern or a diagram of it:

1. Personal environments have to be turned on. On Power Platform, environment routing lands makers in an auto-provisioned personal developer environment instead of the shared Default Environment, but routing is off by default and needs an admin plus premium licensing. Until someone switches it on, there is no Zone 1.
2. The control’s failure mode is the thing it prevents. If no routing rule matches, or provisioning fails, makers fall back to the Default Environment. The ungoverned bucket is where the pattern lands when it breaks, so monitor for the fallback rather than assuming it.
3. The strict personal-dev policy has to be authored. Developer environments get no environment-specific data policies; they inherit tenant-level ones. If nobody writes the restrictive Zone 1 policy, the gradient described above never appears, and Zone 1 becomes the loosest zone rather than the tightest.

How you’d know it’s working

Test the border rather than trusting it. Take a Zone 1 agent and attempt, deliberately, to reach production data and an external destination. Both should fail, and the denial should appear in an environment or egress log. A zone nobody has ever tried to escape is an assumption.

Two counts are worth putting on a dashboard. Agents residing in the Default Environment should trend to zero, and that single number is the best available health metric for this pattern. Every Zone 3 agent should trace to a recorded gate transition, with no exceptions that only the platform team remembers.

Watch the demotion path too. Zones tend to ratchet upward because promotion has an owner and demotion does not, so an estate where no agent ever moves down has a one-way gradient.

What this doesn’t solve

Zones bound blast radius without judging quality. A badly built agent that passes the gate runs with Zone 3 scope, and nothing in the environment model will notice that its output is wrong. That is what evals and unreliable output are for.

Lateral movement inside a zone is untouched. Two Zone 2 agents sharing an environment share its data boundary, and the pattern says nothing about one reaching the other. See multi-agent cascades.

Vendor prevalence claims are advice rather than measurement, and a firm reading them as a benchmark is measuring itself against nothing. Microsoft’s statement that editor access is “rarely permitted” in production and that most Zone 3 environments are run-only describes a recommended default; no data exists on how tenants actually configure it.

Zones also do nothing about agents built outside the platform entirely. An analyst running an agent on a personal API key has left the environment model without touching it, which is shadow agents, not a zoning problem.

The evidence base is also thinner than the pattern’s ubiquity suggests: the strongest citizen-development precedents are pre-agent low-code studies, and the convergence claim rests partly on one trade book’s summary of PMI’s and Gartner’s models. The incident most often cited for it — Replit’s agent deleting a production database in July 2025, which OWASP attributes first to insufficient test/production separation — could not be traced to a primary in this build, so use OWASP’s characterisation and skip the specifics that circulate in press retellings.

See also

• Promotion gates — the process and authority at each zone transition.
• Risk tiers and trust zones — the model that decides which zone an agent belongs in.
• Sandboxing and isolation — the enforcement primitive under the personal zone, and what it leaves open.
• Egress control — the border control that should differ per zone.
• Shadow agents — what accumulates when no personal zone is worth using.
• Day 3 sequencing — when the second and third zones earn their cost.