Draw from Tenant Credit Pool: The Environment Group Rule That Makes Copilot Credit Allocations Real

There is a single checkbox in the Power Platform admin center that decides whether a maker’s sandbox can quietly spend the Copilot Credits your organization bought for everyone else. It lives inside environment group rules, it is labelled Cost controls – Draw from tenant credit pool, and since developer and trial environments moved to usage-based billing on September 1, 2026, it has become one of the most consequential settings a Power Platform admin can publish.

Microsoft’s new guidance, Govern Copilot Credit consumption for agents powered by the GitHub Copilot harness, makes one principle very clear: govern the environment, not just the published agent. This rule is where that principle stops being advice and becomes something the platform enforces.

Why this setting matters now

Three changes have shifted Copilot Credit consumption from a production concern into a day-one concern.

• Consumption starts at design time. Agents powered by the GitHub Copilot harness consume Copilot Credits while makers build, preview, and evaluate them. An exploration environment can incur consumption even if none of its agents is ever published.
• The license does not cover it. Harness agent usage is not included in a user’s Microsoft 365 Copilot license. Creation and runtime activity is billed regardless of who the maker is.
• Sandboxes are now billable. Developer and trial environments moved to usage-based billing on September 1, 2026. Consumption recorded before that date is directional only, not a billing estimate.

Add one more fact and the stakes become organizational rather than departmental: prepaid Copilot Credit capacity packs are shared across the Power Platform admin center and the Microsoft 365 admin center. Capacity consumed by Copilot Studio reduces the prepaid capacity available to Microsoft 365 usage-based experiences such as Cowork and Work IQ. An uncontained experiment in one environment is not just a line item. It can reduce what the rest of the business has to work with.

What the setting actually does

The environment group rule controls whether environments in the group can use unallocated Copilot Credits from the tenant pool. When the rule is enabled, an environment can draw from the tenant pool after it exhausts its own allocation, or when no allocation is set at all. When it is disabled, the environment is confined to what was explicitly allocated to it.

The same behavior exists at the individual environment level. Under Licensing, Copilot Studio, Manage Copilot Credits, each environment has a Draw from the available capacity in my tenant option under Capacity overages. The group rule is the governed, at-scale version of that option.

The default that turns allocations into suggestions

Here is the detail that catches organizations out. For eligible Copilot Studio environments, Draw from the available capacity in my tenant is selected by default when no allocation configuration exists. A brand new environment with no allocation can therefore consume from the entire unallocated tenant pool.

Microsoft’s own cost controls table states the consequence plainly: an allocation is not a boundary if the environment can continue drawing from tenant capacity or a pay-as-you-go billing plan. You can carefully allocate a modest amount to a prototyping environment and still have no effective ceiling, because once that allocation is gone the environment simply moves on to the shared pool.

Why publish it at the group level

Clearing the checkbox on each environment works for a handful of environments. It does not survive a real estate of maker, test, and production environments that change every week. The group rule solves three problems that per-environment configuration cannot.

It applies uniformly. When you publish the rule, it governs every environment in the group. There is no environment-by-environment checklist to fall out of date.

It locks the setting. The environment-level option becomes read-only in the Power Platform admin center, and programmatic requests cannot override it. Microsoft’s guidance describes a recurring loop that uses the Power Platform API to detect and remediate configuration drift. For environments inside a governed group, the rule prevents that drift from occurring at all, which is a stronger control than detecting it after the credits are spent.

It narrows the blast radius of allocation permissions. The tenant’s add-on capacity assignment setting controls who can allocate credits. If environment administrators are allowed to manage allocations, that permission applies across every environment in the tenant, not only the ones they administer. The group rule does not replace keeping that permission restricted, but it does ensure the draw behavior of governed environments cannot be changed through that route.

Removal is also predictable. If an environment is removed from the group, it keeps the last value the group applied, and the setting becomes editable again. To keep environment-level control for a specific case, either do not publish the rule for that group or move the environment out of it.

What the rule does not do

A published, unchecked rule is a strong prepaid boundary. It is not a complete cost control on its own, and treating it as one is the most likely way to be surprised.

• It does not stop pay-as-you-go. If the environment is linked to a pay-as-you-go billing plan, usage continues through the linked Azure subscription. Azure budgets and alerts notify finance and service owners but do not stop Copilot Studio consumption.
• It does not cap individual agents. The rule sets the shared boundary for the environment. To stop one runaway agent, set an agent-level monthly limit with Stop usage turned on. Equally, agent limits do not cap aggregate environment consumption. The two controls are complementary, not interchangeable.
• It is not specific to the GitHub Copilot harness. Environment capacity controls apply to every Copilot Studio workload in the environment: standard harness agents, agent flows, workflows, prompts, computer use, and other credit-consuming features. Review all of them before publishing.
• It can stop things on purpose. With the rule unchecked and no allocation in place, an environment cannot consume prepaid capacity from the tenant pool. When an environment has no available credits, experiences that require credits can stop working for both makers and end users. That is exactly what you want in a sandbox and exactly what you do not want in a production environment you forgot to allocate.

Match the rule to environment purpose

Microsoft’s guidance asks admins to classify each environment as exploration and prototyping, test and validation, or funded production, and to record the approved capacity posture for each. Environment groups are a natural home for that classification: one group per purpose, with the rule set once for everything inside it.

Exploration and prototyping. This is where the rule earns its keep. Allocate a small, defined amount, publish the rule unchecked, do not link pay-as-you-go, and apply an organization-defined development limit to each agent. The Power Platform admin center does not provide a tenant-wide default agent limit, so that last step needs a recurring or automated process. Because limits apply to agents rather than users, factor in how many agents each maker can create.

Test and validation. Allocate enough for representative evaluation, keep the tenant pool closed for the test window, and set agent limits that prevent surprises without invalidating the test. Assign an owner and an end date, and review the controls when testing finishes.

Funded production. Here the rule is a deliberate continuity decision rather than a default. Checking it lets a production service keep running on shared prepaid capacity after its allocation is used. Leaving it unchecked and linking pay-as-you-go routes overage to a named cost owner’s Azure subscription instead. Either choice can be right. What is not acceptable is an unexamined default, and whichever you choose, the cost owner and funding model should be confirmed and recorded.

A practical rollout sequence

1. Find the harness agents. In the Power Platform admin center, go to Manage, Copilot Studio, and filter the Harness column to GitHub Copilot. At scale, use the Power Platform inventory API and the properties.harness field, following every skip token so no agents are missed.
2. Classify and group. Map each environment to exploration, test, or production, and place it in the matching environment group. Inventory gives you the technical relationships. Your naming conventions, approval records, or Copilot Agent Kit data supply the business context.
3. Allocate before you close the pool. Any environment without an allocation loses access to prepaid capacity the moment an unchecked rule is published. Review every credit-consuming workload in the group and set allocations first.
4. Publish the rule. Configure Cost controls – Draw from tenant credit pool on the group and publish. Confirm that the environment-level option now shows as read-only.
5. Add agent limits. Under Licensing, Copilot Studio, Manage Agents, set monthly limits, notification thresholds, and Stop usage where a workload needs a hard stop.
6. Publish a request path. Document who approves more capacity, what justification a maker must provide, and who reviews consumption afterwards. A restrictive boundary without an escalation path simply pushes makers toward workarounds.
7. Close the gap for new environments. The rule only governs environments inside the group. On a recurring cadence, query inventory for microsoft.powerplatform/environments, compare the results with your governed environment register, and move anything unclassified into the right group.
8. Look across both admin centers. Because prepaid capacity is shared, review consumption in the Power Platform admin center and in Copilot, Cost Management in the Microsoft 365 admin center.

Key takeaways

• An environment allocation is only a boundary when drawing from the tenant pool is turned off, and it is on by default for eligible environments without an allocation.
• Publishing the rule at the environment group level applies it uniformly and makes it read-only at the environment level and through the API, which prevents drift rather than chasing it.
• The rule contains prepaid consumption only. Pair it with agent-level limits and treat any linked pay-as-you-go plan as a separate, owned decision.
• Close the pool for exploration and test groups by default, and make production a documented continuity choice.

Sources

• Govern Copilot Credit consumption for agents powered by the GitHub Copilot harness, Microsoft Learn
• Manage costs for agents powered by the GitHub Copilot harness, Microsoft Learn
• Environment groups, Microsoft Learn
• Manage Copilot Credits and capacity for Copilot Studio, Microsoft Learn
• Manage Copilot Credit allocations programmatically, Microsoft Learn