Govern Copilot Credit consumption for agents powered by the GitHub Copilot harness

Note

Features in this article are used by agents or workflows powered by the GitHub Copilot harness.

Usage-based billing applies to using, building, testing, and evaluating agents. These actions might consume Copilot Credits. Learn more in Manage costs for agents powered by the GitHub Copilot harness.

Agents powered by the GitHub Copilot harness consume Copilot Credits while makers build, preview, and evaluate them, before those agents enter a formal production lifecycle. An environment used for maker exploration can incur consumption even if its agents are never published for production use.

Use this article to operationalize Copilot Credit governance for such agents. Classify the environments that contain these agents, record the approved controls for each classification, and use the Power Platform API to detect and remediate configuration drift.

Before you implement this process, review which activities consume credits, the available cost controls, monitoring options, and procedures described in Manage costs for agents powered by the GitHub Copilot harness.

Important

Govern at the environment level, not just the published agent. An agent is built, previewed, and evaluated within an environment—the environment is the right unit to govern from day one.

Power Platform admin center capacity and consumption controls apply across Copilot Studio. They aren't exclusive to agents powered by the GitHub Copilot harness. Review all agents, workflows, prompts, and other credit-consuming features in an environment before changing its allocation or overage settings.

Before you begin

To manage licensing and capacity, you need the Power Platform administrator or Global administrator role in Microsoft Entra ID, or an equivalent administrative role.

This article assumes familiarity with the following concepts:

  • GitHub Copilot harness: One of the harnesses available in Copilot Studio. It powers agents and workflows designed for reasoning-heavy, multistep work and uses Copilot Credits for usage-based billing.
  • Copilot Credits: Copilot Credits power AI experiences across the Microsoft ecosystem. Usage by agents powered by the GitHub Copilot harness isn't included with a user's Microsoft 365 Copilot license.
  • Power Platform environments: The containers that hold agents, data, and resources. Each agent belongs to one environment, and capacity controls are configured at the environment and agent levels.
  • Service admin roles: The Power Platform administrator role in Microsoft Entra ID that is required to manage licensing and capacity.

Important

Developer and trial environments moved to usage-based billing on September 1, 2026. Usage recorded before that date can provide a directional view of consumption, but it isn't a billing estimate or a guarantee of future cost. Review these environments and configure controls to help manage costs.

How to approach governance

Follow this repeatable baseline:

  1. Discover: Find agents, the harness they use, and the environments that contain them.
  2. Classify: Label each environment as exploration and prototyping, test and validation, or funded production.
  3. Review controls: Check environment allocation, tenant-pool draw, pay-as-you-go, and enforcement.
  4. Apply limits: Set agent-level limits where a use case needs a tighter boundary.
  5. Repeat and automate: Detect newly created environments and agents on a recurring cadence.

Governance operates at four layers:

Layer What is controlled
Tenant Purchased and available capacity; who can allocate capacity
Environment Prepaid allocation, draw from unallocated tenant capacity, and pay-as-you-go billing
Agent Monthly limit, notification threshold, usage based hard stop, and explicit stop state
Operating process Cost owner, alert triage, exception approval, and owner notification

Choose controls based on environment purpose

Classify environments as exploration, test and validation, or funded production. Define the approved capacity posture and exception process for each classification.

Scenario Governance posture
Exploration and prototyping Assign an accountable owner, contain access to shared capacity, and apply an organization-defined development limit to each agent through a recurring or automated process. Provide a documented path to request more capacity.
Test and validation Allocate enough capacity for representative evaluation, define the test period and owner, and set agent limits that prevent unexpected consumption without invalidating the test. Review the controls when testing ends.
Funded production Confirm the cost owner and funding model, configure capacity for expected demand and continuity, and set limits based on service criticality. Monitor for consumption that could interrupt the service.

Power Platform admin center doesn't provide a tenant-wide default agent limit. If your organization defines a standard limit for new agents, use a recurring or automated process to apply it to individual agents.

Discover and classify agents and environments

For each agent powered by the GitHub Copilot harness, identify:

  • The environment that contains it.
  • Whether that environment supports exploration and prototyping, test and validation, or funded production usage.
  • The agent owner and the person accountable for its consumption.
  • Whether its current allocation, overage settings, and consumption match that purpose.

Start with the Power Platform inventory to find Copilot Studio agents and their environments. Use the count agents by harness sample query for a quick aggregate view. At scale, use the Power Platform inventory API to make the review repeatable.

The properties.harness field identifies which harness an agent uses. Filter Copilot Studio agent resources on this field using GitHub Copilot as the value, and use the project clause to return the agent name, display name, environment ID, owner ID, and harness value. Configure the query options for the required page size and follow each returned skip token until the response has no continuation. Otherwise, a single response might not include every matching agent.

Inventory returns the technical relationship between the agent, its owner, and its environment. Your environment naming, environment groups, governance metadata, or approval records supply the business context you need to classify it. If you already use the Copilot Agent Kit and tools such as the Compliance Hub, extend that inventory with the scenario and cost-ownership information your process uses.

Apply environment controls

After you classify an environment, choose one of these capacity postures:

  • Prepaid boundary: Allocate a defined amount of prepaid capacity, turn off Draw from the available capacity in my tenant, and don't connect the environment to pay-as-you-go billing.
  • Continuity through Azure billing: Configure pay-as-you-go billing, assign a cost owner, and use Azure budgets and alerts for cost visibility. Budgets and alerts notify administrators but don't stop Copilot Studio consumption. Set agent-level limits where a workload requires a stopping point.

Learn how to configure these controls in Manage costs for agents powered by the GitHub Copilot harness. To apply controls programmatically, use the current allocationsV2 operations and examples in Manage Copilot Credit allocations programmatically.

Important

Environment capacity controls apply to all Copilot Studio workloads in the environment, not only agents powered by the GitHub Copilot harness. Review standard-harness agents, GitHub Copilot harness agents, agent flows, workflows, prompts, and other credit-consuming features before changing allocation or overage settings.

The tenant's add-on capacity assignment setting controls who can allocate credits. Allowing environment administrators to manage allocations doesn't restrict them to the environments they administer. It gives them allocation control across every environment in the tenant. Keep allocation restricted to tenant administrators unless that tenant-wide access is intentional.

Review controls for new and existing environments

New environments can appear with tenant-capacity draw turned on, and existing environment configuration can drift from approved controls. A recurring review and remediation process closes both gaps.

  1. Query Power Platform Inventory for microsoft.powerplatform/environments. Adapt the Inventory API request by changing its resource-type filter.
  2. Compare the results with your governed environment register.
  3. Classify a new or unclassified environment and record its approved controls. For an existing environment, retrieve its recorded classification and approved controls.
  4. Read the environment's current allocation and overage settings by using the operations described in the programmatic allocation tutorial.
  5. Compare the current configuration with the approved controls.
  6. Preserve approved exceptions. Otherwise, remediate any mismatch.

Apply agent-level limits

Environment controls set the boundary for shared capacity. An agent-level limit adds a monthly boundary for a single use case, whether its environment uses prepaid capacity or pay-as-you-go billing.

For exploration and prototyping agents, an organization-defined limit can prevent overconsumption. Power Platform admin center doesn't apply this limit automatically. A recurring or automated process can:

  1. Detect a newly created agent powered by the GitHub Copilot harness.
  2. Confirm whether the agent sits in an exploration and prototyping environment.
  3. Apply the organization's development limit to the individual agent.
  4. Notify the agent owner of the limit and what happens as it approaches or reaches.
  5. Route requests for more capacity through the appropriate approval process.
  6. Review or replace the development limit when the agent moves into funded production usage.

This process lets makers explore while keeping consumption within limits. Because limits apply to agents instead of users, consider how many agents each maker can create when you define the organization-defined limit and escalation process.

Production agents can also use limits to protect shared capacity. Set the value from expected usage and service criticality rather than inheriting the organization-defined development limit.

Note

Agent limits don't cap aggregate environment consumption. To contain prepaid consumption, allocate a defined amount and turn off Draw from the available capacity in my tenant. If the environment uses pay-as-you-go, Azure budgets provide alerts but don't stop usage. Use agent-level hard stops or change the billing plan only after assessing all workloads in the environment.

Monitor and notify owners

Use Manage Agents and the downloadable Copilot Studio consumption report in the Power Platform admin center to review agent consumption and configured limits. Learn more in Manage monthly consumption limits for Copilot Studio agents. At scale or when using automation, use the entitlement insight operations in the Power Platform API to retrieve consumption data programmatically.

Define who reviews built-in limit notifications, who contacts the owner when context is needed, and who can approve a limit increase or let the agent stop. To customize the logic around notifications further, use consumption data from the API to inform your own notifications logic.

Don't use environment entitlement consumption to infer that an individual agent reached a percentage of its limit. Environment entitlement data is aggregate and doesn't provide per-agent threshold consumption.

Coordinate capacity across admin centers

Use the Power Platform admin center to manage Copilot Studio environment capacity and agent limits. Use Copilot > Cost Management in the Microsoft 365 admin center for supported Microsoft 365 usage-based experiences and spending policies.

Prepaid Copilot Credits can be shared across eligible products. If your organization uses both product families, review consumption in both admin centers. Learn more in Managing AI experiences enabled by usage-based billing.

Key takeaways

Governing Copilot Credit consumption is an ongoing process, not a one-time configuration. Classify each environment by purpose, apply the right controls for that purpose, and repeat the review as new environments and agents appear.

Follow these principles:

  • Govern the environment, not just the agent. Consumption starts at design time, before an agent is published.
  • Match controls to purpose. Exploration and prototyping environments need a deliberate boundary, test and validation environments need time-bound controls, and funded production environments need an accountable owner and intentional funding.
  • Layer your controls. Tenant-level settings govern tenant visibility and environment allocation. Environment-level capacity settings establish the shared boundary. Agent-level limits add precision for individual use cases.
  • Automate what you can. A manual review of a small estate scales poorly. Use Power Platform Inventory and supported allocation operations to detect, classify, and remediate environments and agents programmatically.
  • Last updated on