Control 2.27: Consumption-Entitlement Governance
Control ID: 2.27 Pillar: Management Regulatory Reference: SOX 404, GLBA 501(b), FINRA 4511, SEC 17a-4(b)(4), OCC Bulletin 2023-17 (Third-Party Relationships) Last UI Verified: June 2026 Governance Levels: Baseline / Recommended / Regulated
Metered Copilot consumption billing — availability and licensing context
This control governs who may incur metered Copilot spend (Copilot Credits and pay-as-you-go consumption). Microsoft's Copilot Credits consumption-billing model becomes the operative metering path for several agent surfaces from June 16, 2026 — scheduled per the Microsoft 365 roadmap (feature 559017) and Microsoft Learn ("use-work-iq"), verified June 2026 — and the standalone credit-policy mechanism is Chat-only today — SharePoint-grounded consumption is funded through a pay-as-you-go (PAYG) Azure-backed policy (prepaid-pack credits reach SharePoint only when paired with a PAYG configuration). Two policy objects back metered spend: a PAYG billing policy (Azure subscription, tenant ceiling of 50, budget alerts only — not a hard-stop) and a prepaid credit policy (no Azure subscription, tenant ceiling of 10, with a standalone hard-stop). Pricing context is $0.01 per credit, and the prepaid pack is 25,000 credits per month, non-rolling. The June 2026 Microsoft Copilot Studio Licensing Guide (footnotes 6 and 7) — verified June 2026 and corroborated on Microsoft Learn ("billing-licensing") — resolves the base zero-rating question: Copilot Studio–built agents surfaced on Teams, SharePoint, and Microsoft 365 Copilot are included with the Microsoft 365 Copilot user license at no additional charge when invoked under the licensed user's own identity, subject to fair-usage limits. Verify the current ceilings and per-feature credit rates against Microsoft licensing documentation before wiring enforcement — Microsoft consumption-billing surfaces are changing rapidly during this window.
How This Control Differs from Related Controls
Scope Boundaries — Read Before Implementing
Consumption entitlement is a distinct governance domain. Drawing the boundary clearly against adjacent controls prevents both duplication and gaps.
Control 2.27 vs. Control 2.26 (Entra Agent ID — Identity Governance for Agents): Control 2.26 governs the agent identity lifecycle — the named human sponsor, governed access packages, time-bound resource assignments, and controlled decommission of the agent identity object. Control 2.27 governs a different question entirely: which users are entitled to incur metered or premium consumption on an agent, under which billing or credit policy, on which surface. An agent can have a fully governed identity (2.26) while no one has decided who may spend metered Copilot Credits through it (2.27). Identity provisioning and consumption entitlement are separate objectives.
Control 2.27 vs. Control 1.18 (Application-Level Authorization and RBAC): Control 1.18 governs functional authorization — who may author, publish, or invoke an agent, applying least privilege and segregation of duties. Control 2.27 adds a cost dimension on top of functional access: a principal who is functionally authorized to invoke an agent (1.18) may still need to be scoped to a billing or credit policy before they may incur metered spend through it. 1.18 is a necessary input to the entitlement decision, but it does not express billing-policy scope, surface-aware spend scope, or zero-rating semantics.
Control 2.27 vs. Control 3.5 (Cost Allocation and Budget Tracking): Control 3.5 (Reporting pillar) provides cost visibility — chargeback ledgers, budget alerting, and per-agent spend reporting. Control 2.27 (Management pillar) provides the runtime entitlement decision that determines whether metered spend is permitted in the first place. Pair them: 3.5 reports on the consumption that 2.27 governs. Neither substitutes for the other — reporting without entitlement enforcement observes uncontrolled spend, and entitlement enforcement without reporting cannot evidence the result to examiners.
Objective
Establish governance over who is entitled to consume metered and premium Microsoft Copilot capabilities, enforcing a defined entitlement contract per agent consumption pathway, applying per-agent spend caps, and running a pre-enforcement coverage-gap analysis before any spend control is activated. This control supports compliance with expectations that consumption and spend authorizations are intentional, attributable, reviewable, and retained — and that the population of users who would be affected by an entitlement decision is understood before enforcement begins. This control governs the entitlement decision; it does not, on its own, satisfy any regulation, and organizations should verify their configuration meets their specific obligations.
Why This Matters for FSI
When agents begin consuming metered Copilot capabilities, two governance questions need a documented answer: which billing or credit policy backs an agent's spend, and which users are entitled to incur that spend. Left ungoverned, metered AI consumption becomes an uncontrolled, hard-to-attribute cost flowing through financial-reporting-relevant systems — exactly the condition that IT general controls and safeguards programs are designed to address.
Regulatory Exposure Without Consumption-Entitlement Governance
SOX 404 requires effective IT general controls (ITGC) over systems that are relevant to financial reporting, including controls over who can authorize spend and how that authorization is reviewed. Metered Copilot consumption with no entitlement contract, no per-agent caps, and no approval of spend appetite represents a gap in the ITGC posture that external auditors assess. Documenting the entitlement decision and the approval of cap thresholds is required to support that ITGC narrative.
GLBA 501(b) (Safeguards Rule) requires reasonable administrative safeguards and oversight of the service relationships that process customer information. An agent incurring metered spend against a Microsoft consumption policy without a governed entitlement scope is a service-consumption relationship operating without administrative safeguard — a gap institutions should be prepared to evidence to OCC or FDIC examiners.
FINRA Rule 4511 requires firms to make and preserve books and records. Entitlement decisions (who was permitted to consume, under which policy, on which surface) and the pre-enforcement coverage-gap evidence are governance records that should be retained for the applicable examination period — generally six years for FINRA member firms.
SEC Rule 17a-4(b)(4) requires preservation of records relating to the firm's business, including records that evidence financial and operational controls. Retaining the materialized entitlement decisions and coverage-gap aggregates helps meet this preservation expectation for the consumption-control record.
Third-party / vendor AI spend oversight — addressed in Control 2.7 (Vendor and Third-Party Risk Management) and informed by the Interagency Guidance on Third-Party Relationships (OCC Bulletin 2023-17 / FRB / FDIC, June 2023) — expects institutions to oversee spend incurred through third-party platforms. Metered Copilot consumption is third-party AI spend; governing entitlement to it contributes to that oversight obligation. Pair this control with Control 2.7 for the vendor-risk view.
Model-risk guidance is adjacent context, not the primary spend authority
OCC Bulletin 2026-13 (formerly OCC 2011-12) and Federal Reserve SR 26-2 (formerly SR 11-7) are model-risk-management guidance and, in their 2026 restatements, expressly exclude generative and agentic AI from scope. They are cited here only as adjacent context for the broader technology-risk framing of metered AI usage; they are not the primary regulatory authority for a consumption-entitlement/spend control. Do not represent this control as satisfying SR 26-2 / OCC 2026-13 model-risk obligations.
Beyond regulatory exposure, an ungoverned consumption path is an operational cost risk: a single broadly-shared metered agent can draw down a prepaid credit pack or accumulate PAYG charges faster than budget alerting can react, because the PAYG policy provides budget alerts only — not a hard-stop.
Control Description
| Capability | Description |
|---|---|
| Switch-on-pathway entitlement contract | The entitlement engine classifies each agent's consumption pathway first, then applies pathway-specific eligibility — rather than denying by default. An explicit none → Allow (eligibility N/A) arm intentionally permits the large population of agents that consume no metered features, and a bounded block decision exists only inside a metered pathway. This design helps avoid blocking the agent majority while still gating genuinely metered consumption. |
| Pathway classification | Each agent is mapped to one consumption pathway — none, mcp-cs (Copilot Studio MCP agent), mcp-agentbuilder (Microsoft 365 Copilot Agent Builder), api-direct (direct API / declarative agent), metered (other metered path), or unmapped. The Work IQ usage tier (configuredTier) is the authoritative signal and is evaluated first; the environment-of-origin signal (createdIn, from Azure Resource Graph) is consulted only as a last-resort fallback. |
| Decision outcomes | Each (agent, user) evaluation resolves to one auditable decision: Allow, Block, Allow - Eligibility N/A (the non-metered majority), Fail-open - Anomaly (an unmapped pathway permits the user but records an anomaly for follow-up, because a detection defect must not deny a user), or Fail-closed - Zero-rating Unresolved (a licensed Copilot Studio user not covered by zero-rating and not in credit scope). |
| Zero-rating resolution | Per the June 2026 Copilot Studio Licensing Guide (footnotes 6 & 7) — verified June 2026 and corroborated on Microsoft Learn — Copilot Studio billing and licensing — a Copilot-licensed user on a Microsoft 365 surface acting under their own identity is included in the Microsoft 365 Copilot User SL — the license is sufficient and no credit scope is required (ZeroRatingResolved defaults to true). Unlicensed users, non-Microsoft-365 surfaces, and the generative-answer-with-tenant-grounding / beyond-fair-use refinements remain credit-metered and should be confirmed per tenant. Setting ZeroRatingResolved = false reverts to the conservative fail-closed posture. |
| Per-agent spend caps | Metered agents carry a per-agent cap record (monthly credit cap, enforcement mode, zone classification). As of June 2026, the public Billing Policy write API exposes no credit-cap or spend-ceiling field, PAYG budgets are alert-only, and per-agent monthly credit caps are configured in the Power Platform admin center UI (Licensing > Copilot Studio > Manage Agents) with no public write API (per Microsoft Learn — manage Copilot Studio message capacity) — so there is no public way to set an enforceable credit cap or hard spend-stop. Enforcement is therefore designed to degrade to detect-and-alert where a hard-stop cannot be applied programmatically — the cap is recorded and monitored rather than silently assumed to block. |
| Pre-enforcement coverage-gap analysis | Before any enforcement is activated, the control runs a per-agent coverage-gap aggregate in monitor-only mode: for each agent it records the classified pathway, the count of eligible users, the count of intended users who would be blocked, a capped sample of blocked UPNs, the dominant block reason, and the surface-aware spend scope (Chat vs SharePoint). Aggregating per agent (not per agent × user) keeps the output bounded and investigable. This is the load-bearing "who would be blocked" deliverable that should be reviewed and signed off before enforcement. In the would-be-blocked tally (engine Test-DecisionIsAllow), a Fail-open - Anomaly decision counts as eligible (an unmapped-pathway user is permitted) while a Fail-closed - Zero-rating Unresolved decision counts as blocked — Finance / BU sign-off should read the gap counts with that rule in mind. |
| Two policy objects, three configurations | Spend is backed by a PAYG billing policy (Azure-backed, ceiling 50, budget alerts only, covers all metered surfaces including SharePoint grounding) and a prepaid credit policy (no Azure subscription, ceiling 10, standalone hard-stop). The standalone credit-policy hard-stop is Chat-only today — SharePoint grounding requires a paired PAYG policy, and prepaid-pack credits fund SharePoint only via that paired PAYG configuration. Three supported configurations — credit-only, credit + PAYG, and PAYG-only — are scoped through an admission-gated security-group registry. |
| Audit, materialization, and retention | Entitlement decisions are materialized with a time-to-live so they are auditable without replaying inputs, and coverage-gap aggregates carry a retention horizon. Decision and coverage-gap records should be forwarded to the SIEM and retained to align with FINRA 4511 / SEC 17a-4 expectations. |
Key Configuration Points
Prerequisites
Configuring metered consumption entitlement requires Microsoft 365 Copilot licensing for in-scope users, at least one configured Microsoft Copilot consumption-billing policy (PAYG and/or prepaid credit), and the AI Administrator role to manage Copilot billing policies and Entra security-group scope. The companion Copilot Billing Governance solution implements the entitlement contract, per-agent caps, and coverage-gap analysis described below.
-
Confirm licensing and billing prerequisites. Verify that in-scope users hold a Microsoft 365 Copilot license and that at least one Microsoft Copilot consumption-billing policy exists. Confirm the operating admin holds the AI Administrator role (prefer it over Entra Global Admin for least privilege; use Entra Privileged Identity Management for just-in-time elevation where a one-time Global Admin action is unavoidable).
-
Establish the two policy objects and choose a configuration. Create the PAYG billing policy using the two-step add → connect flow against an Azure subscription, and/or the prepaid credit policy as a standalone object. Record the tenant ceilings (PAYG 50 / credit 10) and select the configuration — credit-only, credit + PAYG, or PAYG-only — that matches the surfaces in use. Note that the standalone credit-policy hard-stop is Chat-only today; SharePoint-grounded consumption requires a PAYG policy (prepaid-pack credits reach SharePoint only via a paired PAYG configuration).
-
Register the admission-gated security-group registry. Populate the registry of approved Entra security groups used for entitlement scoping — credit-scope groups, API-audience cohorts, and billing-policy groups. Each registered group must be
securityEnabledand notmailEnabled(a mail-enabled group is rejected by admission gating). This registry is the source of the "who is in credit scope / eligible cohort" checks. -
Classify each agent's consumption pathway. Run pathway classification so every in-scope agent is mapped to
none,mcp-cs,mcp-agentbuilder,api-direct,metered, orunmapped. The Work IQconfiguredTieris authoritative and evaluated first; the Azure Resource GraphcreatedInsignal is a last-resort fallback. Treat anyunmappedresult as an anomaly to investigate, not a reason to block users. -
Apply the entitlement contract per pathway. Evaluate
(agent, user)eligibility per pathway:noneallows (eligibility N/A);mcp-agentbuilderandmcp-csrequire a Copilot license;mcp-csadditionally requires that the surface is zero-rated (whenZeroRatingResolved = true) or the user is in credit scope;api-directandmeteredrequire membership in the eligible cohort. SetZeroRatingResolvedto true for the footnote-6/7 included case, or to false to adopt the conservative fail-closed posture for your tenant. -
Configure per-agent metered spend caps (Zone 3). For each Zone 3 metered agent, record a per-agent cap (monthly credit cap, enforcement mode, zone classification). Where a programmatic hard-stop write API is unavailable, set the enforcement mode to detect-and-alert so the cap is monitored and breaches are surfaced; do not represent detect-and-alert as a hard-stop enforcement.
-
Run the pre-enforcement coverage-gap analysis in monitor-only mode. Before enabling any enforcement, produce the per-agent coverage-gap aggregate (eligible-user count, would-be-blocked count, capped blocked-UPN sample, dominant block reason, surface-aware spend scope). Review and obtain sign-off on the coverage gap — the count of intended users who would be blocked — before activating enforcement. Use the per-feature Copilot credit rates (reference constants — confirmed per Microsoft Learn (requirements-messages-management) as of June 2026; pricing is time-sensitive, so re-confirm against current Microsoft licensing documentation as it changes) to produce a coverage-gap spend estimate, reconciled against the Microsoft 365 admin center and Azure cost reporting. These figures support cost estimation; they do not produce a billing-accurate invoice.
-
Retain decisions and forward evidence. Persist materialized entitlement decisions (with their pathway, decision, block reason, spend scope, and source policy) and coverage-gap aggregates, apply a retention horizon aligned to FINRA 4511 (six years minimum), and forward the records to the organization's SIEM so entitlement and coverage-gap evidence is examination-ready.
Zone-Specific Requirements
| Requirement | Zone 1 — Personal | Zone 2 — Team | Zone 3 — Enterprise |
|---|---|---|---|
| Entitlement evaluation | Not required; non-metered personal experimentation | Entitlement contract evaluated for shared metered agents; pathway recorded per agent | Mandatory entitlement evaluation for every metered (agent, user) population; decisions materialized and auditable |
| Billing/credit policy scoping | Not required | Policy scoping via the admission-gated security-group registry for shared agents | Mandatory registry-based scoping; all scope groups securityEnabled and not mailEnabled; configuration (credit-only / credit+PAYG / PAYG-only) documented |
| Per-agent spend caps | Not required | Recommended for shared metered agents | Mandatory per-agent caps on all metered agents; enforcement mode (enforce vs. detect-and-alert) recorded |
| Coverage-gap analysis | Not required | Coverage-gap analysis run in monitor-only mode before any enforcement | Mandatory coverage-gap analysis with documented sign-off on the would-be-blocked population before enforcement is activated |
| Spend-appetite approval | Not required | Business Unit Owner approves entitled cohorts for their agents | Finance / Controller approves cap thresholds and spend appetite; approval documented for SOX 404 ITGC |
| Audit log retention | Standard tenant retention | Minimum 1 year | Minimum 6 years per FINRA 4511; entitlement decisions and coverage-gap evidence forwarded to SIEM |
| Anomaly handling | Not applicable | unmapped pathways recorded as anomalies and triaged |
unmapped pathways fail open with anomaly, triaged within the governance cadence; zero silent denials |
Roles & Responsibilities
| Role | Responsibilities |
|---|---|
| AI Governance Lead | Owns this control. Sets the entitlement policy and spend-appetite framework, convenes the coverage-gap review, approves activation of enforcement, and produces governance evidence for examination readiness. |
| AI Administrator | Creates and maintains the Microsoft Copilot PAYG and prepaid credit billing policies, assigns the Entra security groups used for entitlement scope, and produces Copilot usage exports. Privileged role — prefer over Entra Global Admin for day-to-day operation. |
| Entra Global Admin | Performs the one-time tenant-wide setup of Copilot billing policies where required; subsequent operations delegate to the AI Administrator under Privileged Identity Management. |
| Power Platform Admin | Owns the Dataverse schema for the entitlement, cap, and coverage-gap tables, the evaluation flows, and the per-agent cap records. |
| Entra User Admin | Maintains the admission-gated security-group registry (credit-scope, API-audience, and billing-policy groups), keeping each group securityEnabled and not mailEnabled. |
| Finance / Controller | Approves per-agent cap thresholds and spend appetite, signs off on the cost-estimate basis, and maintains the SOX 404 ITGC documentation for consumption authorization. |
| Compliance Officer | Confirms that entitlement decisions and coverage-gap evidence are retained per FINRA 4511 / SEC 17a-4(b)(4) and evidences the retention configuration during examinations. |
| Business Unit Owner | Approves the entitled cohorts (which users may incur metered spend) for the agents their unit sponsors, and responds to coverage-gap findings affecting their users. |
Related Controls
| Control | Relationship |
|---|---|
| 3.5 — Cost Allocation and Budget Tracking | Paired — enforcement vs. reporting. Control 2.27 governs the runtime entitlement decision that permits or blocks metered spend; Control 3.5 reports on, allocates, and budgets the spend that results. 3.5 observes what 2.27 governs. Both are required for a complete consumption-governance posture. |
| 1.18 — Application-Level Authorization and RBAC | Dependency — functional access is an input. Control 1.18 determines who may functionally invoke an agent. Control 2.27 adds the cost/billing entitlement dimension on top of that functional access. 1.18 is a necessary input but does not express billing-policy scope or zero-rating. |
| 2.26 — Entra Agent ID — Identity Governance for Agents | Complementary — identity vs. consumption. Control 2.26 governs the agent identity lifecycle (sponsor, access packages, decommission). Control 2.27 governs who may consume metered capabilities through that agent. A governed identity does not imply a governed consumption entitlement. |
| 1.14 — Data Minimization and Agent Scope Control | Complementary — surface-aware scope. Control 2.27's surface-aware spend scope (Chat vs SharePoint) keeps metered entitlement within the agent's declared data scope governed by Control 1.14. |
| 2.7 — Vendor and Third-Party Risk Management | Complementary — third-party AI spend oversight. Metered Copilot consumption is third-party AI spend. Control 2.7 provides the vendor-risk and third-party oversight framing (informed by OCC Bulletin 2023-17); Control 2.27 governs the per-agent entitlement to incur that spend. |
| 2.1 — Managed Environments | Dependency — governance surface. Managed Environments provide the governed boundary within which metered agents operate and within which entitlement scoping and cap records are administered. |
Implementation Playbooks
| Playbook | Description |
|---|---|
| Portal Walkthrough | Step-by-step configuration of the Microsoft Copilot PAYG and prepaid credit billing policies, the admission-gated Entra security-group registry, agent pathway classification, the entitlement contract, per-agent caps, and the monitor-only coverage-gap analysis. |
| PowerShell Setup | PowerShell and Microsoft Graph commands to inventory billing/credit policy state, register and validate scope groups, run the entitlement evaluation across the (agent, user) population, configure per-agent caps, and export coverage-gap aggregates and entitlement decisions for evidence. |
| Verification & Testing | Test procedures to validate pathway classification, confirm the decision outcomes for each pathway (including the none allow arm and the zero-rating resolution), verify per-agent caps and detect-and-alert degradation, and confirm the coverage-gap analysis produces a bounded, reviewable result. |
| Troubleshooting | Resolution guidance for common issues: agents resolving to unmapped, mail-enabled groups rejected by the registry, missing-license blocks, zero-rating posture (resolved vs. fail-closed), and reconciling coverage-gap spend estimates against the Microsoft 365 admin center and Azure cost reporting. |
Verification Criteria
The following criteria constitute the minimum evidence set required to attest this control as implemented. All criteria must be evidenced for Zone 3 compliance attestation. Criteria 1–4 and 6 apply to Zone 2. Criterion 1 applies to Zone 1 at a documentation level only where metered consumption exists.
- Both Microsoft Copilot consumption policy objects in use are inventoried; the selected configuration (credit-only, credit + PAYG, or PAYG-only) is documented, and the tenant ceilings (PAYG 50 / credit 10) and per-feature credit-rate basis are recorded. Evidence: policy inventory export and configuration note.
- The admission-gated security-group registry is populated for all entitlement scope groups; every registered group is
securityEnabledand notmailEnabled. Evidence: registry export plus a Microsoft Graph group-property check showing zero mail-enabled scope groups. - Every Zone 2 and Zone 3 metered agent is classified to a consumption pathway; the count of
unmappedagents is either zero or eachunmappedagent is recorded as an anomaly with a follow-up owner. Evidence: pathway classification report. - The entitlement contract has been evaluated across the in-scope
(agent, user)population; decisions are materialized and auditable, and theZeroRatingResolvedposture is recorded per agent. Evidence: materialized decision export showing pathway, decision, and block reason. - Per-agent metered spend caps are configured for all Zone 3 metered agents, with the enforcement mode (enforce vs. detect-and-alert) recorded for each. Evidence: cap-record export. No Zone 3 metered agent is documented as having a programmatic hard-stop where the underlying cap-enforcement write API is unproven.
- A pre-enforcement coverage-gap analysis has been run in monitor-only mode for all metered agents; per-agent gap rows are present with eligible-user count, would-be-blocked count, a capped blocked-UPN sample, and the dominant block reason. Evidence: coverage-gap export showing
monitorOnly = truefor all rows prior to enforcement activation. - The would-be-blocked population has been reviewed and signed off before any enforcement was activated; a coverage-gap spend estimate has been produced from the per-feature credit rates and reconciled against the Microsoft 365 admin center / Azure cost reporting, with the caveat that the figures are estimates and not a billing-accurate invoice. Evidence: documented sign-off and reconciliation note.
- Entitlement decisions and coverage-gap evidence are retained under a policy aligned to FINRA 4511 (six-year minimum) and SEC 17a-4(b)(4), and are forwarded to the organization's SIEM. Evidence: retention policy configuration and SIEM ingestion confirmation.
Additional Resources
- Microsoft Copilot Studio — licensing and billing (Microsoft Learn) 🔎 verify current title/URL — Copilot consumption-billing documentation is changing during the June 2026 rollout
- Microsoft Copilot Studio — manage capacity and messages / Copilot Credits — per-feature credit rates and the $0.01/credit, 25,000-credits-per-month ($200 per tenant per month, non-rolling) figures confirmed here as of June 2026; pricing is time-sensitive — re-confirm against current Microsoft licensing documentation as it changes
- Power Platform — pay-as-you-go overview (Microsoft Learn)
- Microsoft Copilot Studio Licensing Guide (June 2026), footnotes 6 & 7 — zero-rating of Copilot Studio agents on Teams/SharePoint/Microsoft 365 Copilot under the Microsoft 365 Copilot User SL (PDF; footnote numbering and fair-usage language verified June 2026, corroborated on Microsoft Learn — billing-licensing)
- Copilot Billing Governance — companion solution (FSI-AgentGov-Solutions) 🔎 preview solution; verify availability
- FINRA Rule 4511 — Books and Records Requirements
- SEC Rule 17a-4 — Records to Be Preserved by Broker-Dealers
- SOX Section 404 — Internal Control Over Financial Reporting (PCAOB AS 2201)
- OCC Bulletin 2023-17 — Third-Party Relationships: Interagency Guidance on Risk Management
Updated: June 2026 | Version: v1.6 | UI Verification Status: Needs Review