Summary
Microsoft's June 2026 Product Terms update is the third consecutive monthly rewrite of its licensing terms governing AI services. March simplified Azure Arc. April tightened the guardrails for high-risk AI content. May broadened multiplexing to cover AI agents and banned RPA outputs from AI training. June goes further. A new umbrella definition pulls all Azure AI services under a single compliance framework. The individual model-provider terms are consolidated into an external documentation page, and the Enterprise AI Services Code of Conduct now applies to every model deployed through Foundry, including third-party ones.
Alongside the announced changes, Microsoft silently removed the Customer Copyright Commitment designation from Copilot Studio, dropped Customer Lockbox from the Compliance Services list, and added an undocumented "Microsoft Discovery" service to the Limited Access register.
Key takeaways:
Microsoft Power Platform: Copilot Studio "Covered Product" designation under the Customer Copyright Commitment silently removed from the Product Terms (coverage continues through the CCC documentation page); new liability clause for Copilot Studio Query Data
Microsoft Azure: Azure Hybrid Benefit for Azure Local now explicitly limited to hyperconverged deployments only; new "Microsoft Azure AI Services" umbrella definition
Agent 365: licence prerequisites published (requires Microsoft 365 E5, F5 Defender and Purview, or Business Premium; E3, Business Basic, and Business Standard are not eligible)
Services Provider Use Rights (SPUR): new "Use for Training AI Models" prohibition added to Office Suites, Project, and Visio, extending the Robotic Process Automation (RPA) training ban from May to Service Provider Licence Agreement (SPLA) hosting providers
Copilot Studio: Copyright Protection Designation Silently Removed
When an AI service generates text, code, or images, there is always a question of who bears the legal risk if that output infringes someone else's copyright. Microsoft's answer to this question is the Customer Copyright Commitment, an IP indemnification programme that protects customers from third-party copyright infringement claims arising from AI-generated output. The commitment applies to products Microsoft designates as "Covered Products" in the Product Terms, provided customers use the built-in content safety systems: guardrails, metaprompts, and content filters. The commitment has been a selling point for enterprise adoption of Microsoft's AI services, because it shifts the legal risk of AI-generated content from the customer to Microsoft.
Until the June update, the Power Platform Service Specific Terms explicitly designated Copilot Studio as a Covered Product:
"Microsoft Copilot Studio is a Covered Product with configurable Metaprompts or other safety systems and is subject to clause 5 of the Customer Copyright Commitment for those capabilities documented at Customer Copyright Commitment Required Mitigations".
This paragraph has been silently removed. Microsoft's change description for Power Platform mentions only the Query Data liability clarification. The Customer Copyright Commitment removal is not mentioned.
Coverage itself has not been withdrawn. The CCC Required Mitigations page, last updated 20 March 2026, still names Copilot Studio as one of only two "Configurable GAI Services" (the other is GitHub Copilot) and maintains a dedicated "Required Mitigations for Microsoft Copilot Studio" section. Under that section, customers who connect an external model to Copilot Studio lose CCC coverage for that model's output unless the model runs in Azure OpenAI and meets the Azure OpenAI mitigations. For all other Copilot Studio usage, the CCC applies as long as the service-specific mitigations are in place.
The Power Platform terms no longer mention the CCC or direct the reader to the mitigations page. If your compliance or procurement process treats the Product Terms as the single governing document, update it to reference the CCC Required Mitigations page directly.
Azure Hybrid Benefit for Azure Local: Scope Now Explicit
Azure Local is Microsoft's on-premises hybrid cloud platform, formerly called Azure Stack HCI. Organisations deploy it to run virtualised workloads, AI inferencing, and Azure Arc services on their own hardware while managing everything through the Azure portal.
How Azure Local Costs Work
Azure Local hyperconverged deployments with cloud-connected management have two published recurring costs, both billed per physical core per month through the customer's Azure subscription. Non-hyperconverged deployments (disaggregated, multi-rack, disconnected) use separately negotiated pricing not on the public price list.
The first is the host service fee at $10 per physical core per month. The second is the optional Windows Server guest subscription at $23.30 per physical core per month, which gives you unlimited Windows Server virtualisation rights on the cluster. If you already have your own Windows Server licences, you do not need the guest subscription; you can bring your own licences instead.
On a 64-core cluster, the host fee alone comes to $7,680 per year ($10 × 64 cores × 12 months). Add the Windows Server guest subscription and the annual cost reaches $25,574 (($10 + $23.30) × 64 × 12). The guest subscription covers unlimited Windows Server VMs on the cluster, so the cost does not increase with the number of virtual machines you run. These fees apply before any VM workload consumption, Azure services, or storage costs.
What Azure Hybrid Benefit Does for Azure Local
Azure Hybrid Benefit for Azure Local waives both the host fee and the Windows Server guest subscription if you have qualifying licences. You allocate one Windows Server Datacenter core licence with active Software Assurance (SA) per physical core on the cluster, and both fees drop to zero.
If you know how Azure Hybrid Benefit works for regular Azure VMs, two conditions differ for Azure Local. First, only Windows Server Datacenter qualifies. Standard licences, which do qualify for AHB on Azure VMs, do not qualify for Azure Local. Second, the benefit is restricted to customers on an Enterprise Agreement with active SA, or a Cloud Solution Provider (CSP) subscription. At launch in October 2022, the benefit was Enterprise Agreement (EA) only; CSP eligibility was added later. Both restrictions remain in the June 2026 Product Terms.
What Changed in June
The June update inserts one new sentence into the Azure Hybrid Benefit section, directly before the existing EA/CSP restriction:
Microsoft's own description of this change says it "Clarified Azure Hybrid Benefit terms to reflect that only one of the Azure Local SKUs is available for Azure Hybrid Benefit". Microsoft uses the word "SKU" deliberately here. The different deployment types of Azure Local are registered as different Azure billing SKUs, and the Product Terms are now explicitly tying Azure Hybrid Benefit to one of them.
The Five Deployment Types
Azure Local has grown from its original single-cluster architecture into five deployment types.
Hyperconverged deployments are the original and most common model. Compute and storage run together on the same cluster nodes using Storage Spaces Direct, in clusters of 1 to 16 machines. The cluster connects to Azure for management, billing, and updates. Microsoft calls this arrangement "cloud connect management", as opposed to disconnected deployments that run a locally hosted control plane.
Disaggregated deployments separate compute from storage. The compute nodes connect to an external Storage Area Network (SAN) instead of using built-in storage. This allows compute and storage to scale independently and supports clusters of up to 64 machines, four times the hyperconverged maximum.
Multi-rack deployments are datacentre-scale installations spanning hundreds of machines in preintegrated racks with built-in fault tolerance.
Disconnected deployments run a local instance of the Azure control plane for environments that cannot maintain an internet connection, such as classified government facilities or critical infrastructure sites that operate in isolation.
Microsoft 365 Local deployments host Microsoft 365 workloads on-premises for sovereign requirements.
A Codification or a New Restriction?
Microsoft calls this a clarification. Our research found supporting evidence for that position, but also a reason to read it more carefully.
The Azure Local pricing page already states at the bottom of the pricing table:
"The above pricing is for Azure Local hyperconverged deployments with cloud connected management. For SAN-attach, larger scale Azure Local deployments with disaggregated storage, or fully disconnected operations with a locally hosted control plane, please contact your account representative".
The published $10 per core per month host fee applies only to hyperconverged clusters with cloud connectivity. Disaggregated, multi-rack, and disconnected deployments are not on the published price list; the pricing page directs customers to "contact your account representative" for those deployment types. Since Azure Hybrid Benefit waives the published host fee, and non-hyperconverged deployments use separately negotiated pricing, the benefit as implemented on the pricing page has only ever applied to hyperconverged clusters.
Microsoft's AHB documentation for Azure Local has never mentioned disaggregated, multi-rack, or disconnected deployments. The Windows Server AHB page describes Azure Local AHB only in terms of allocating core licences for "all physical cores on servers in the Azure Local cluster", language consistent with the hyperconverged model.
All of that supports the "codification" reading. The pricing page and the documentation both describe AHB only in the context of hyperconverged clusters.
However, the Product Terms themselves were broader. Before June, the AHB section referred to "an Azure Local Cluster" without any deployment type qualifier. A disaggregated deployment is an Azure Local cluster. It is deployed as Azure Local, managed through Azure, billed through Azure, and listed by Microsoft as an Azure Local deployment type. A careful reader of the Product Terms, reading only the legal document and not cross-referencing the pricing page, would have seen no reason to exclude their disaggregated Azure Local cluster from AHB eligibility. The Product Terms simply said "Azure Local Cluster" and imposed two restrictions: EA or CSP only, and not with Microsoft 365 Local.
Only one group is materially affected: customers running disaggregated, multi-rack, or disconnected Azure Local clusters who read only the Product Terms and assumed Azure Hybrid Benefit applied. The pricing page and AHB documentation always described hyperconverged-only — June simply makes the legal document agree.
The June update resolves this conflict by restricting the Product Terms to match the pricing page. The legal document now says what the pricing page already said. For organisations that relied on the unqualified Product Terms wording, the June update narrows the scope of the governing legal document, even if the pricing page and documentation always implied this boundary.
Agent 365: Prerequisites Published and Data Terms Expanded
Agent 365, which launched in the May Product Terms, receives two updates.
Licence Prerequisites
The Product Terms now publish a licence prerequisites table for Agent 365 for the first time. Purchasing an Agent 365 User Subscription Licence requires one of the following:
Microsoft 365 E5
Microsoft 365 F5 Defender and Purview
The prerequisites table formalises what was implied by the E7 bundle composition. Microsoft 365 E3, Business Basic, and Business Standard are not on the list. Agent 365 at $15 per user per month requires E5 or one of the qualifying security bundles as a starting point. If you are on E3 and interested in Agent 365, the path goes through E5 first, or through E7 which bundles everything together at $99 per user per month.
Data Privacy Notices Expanded
The Data Privacy Notices wording has been rewritten. The previous text stated that Agent 365 integrates data between "Microsoft Products, including Microsoft Defender, Entra, Purview and other Online Services". The new text restructures this to "Online Services such as Microsoft 365, Copilot Studio or Microsoft Foundry, including Microsoft Defender, Microsoft Entra or Microsoft Purview".
More significantly, the June version adds an explicit authorisation clause that was absent in May:
The May version placed the compliance burden on the customer but did not include an explicit grant of permission. The June version adds that grant. If you enable Agent 365, you are explicitly authorising Microsoft to move your data between the integrated services. Review this against your organisation's data governance policies, particularly if you operate under the General Data Protection Regulation (GDPR) or sector-specific data residency requirements.
Power Platform: Microsoft Now Liable for Copilot Studio Search Queries
When you build an AI agent in Copilot Studio and enable it to search the web for answers, the agent sends search queries to Bing. The Product Terms call these queries "Query Data" and already commit that Microsoft will not use them to improve Bing, build advertising profiles, track user behaviour, share them with advertisers, or train AI models. These are strong promises, and they exist because organisations rightly worry about what happens to their data when it passes through a consumer search engine.
What the Product Terms did not previously state was what happens if Microsoft breaks those promises. The protections existed, but there was no defined contractual consequence for violating them.
The June update fills that gap:
In plain language, if Microsoft mishandles your Copilot Studio search queries, the contractual remedy is now the same as if Microsoft mishandled your Customer Data. Customer Data liability under the volume licensing agreement carries the strongest protections Microsoft offers, including the Data Protection Addendum. Tying Query Data to that same standard gives organisations a concrete contractual basis if they need to enforce the search query protections.
Azure AI Services: Framework Restructured
The largest section of this month's update by volume is a top-to-bottom restructuring of how Microsoft defines and governs AI services within the Azure Product Terms. Microsoft's own description says the update "introduced a 'Microsoft Azure AI Services' definition to ensure certain cross-cutting terms apply to all Azure services incorporating AI". The restructuring does not change costs or entitlements, but it does change which compliance obligations apply to which services and where to find the governing terms for third-party AI models.
New "Microsoft Azure AI Services" Definition
Previously, Microsoft's AI-related terms in the Azure Product Terms were scattered across separate sections for Azure AI Services, Azure OpenAI, and the Foundry platform. Each had its own requirements for product documentation compliance, Limited Access registration, and Bing grounding.
The June update introduces a new "Microsoft Azure AI Services" umbrella definition that sits above the individual services. The cross-cutting terms that now apply uniformly include the requirement to follow Microsoft's technical documentation, the Limited Access Services registration and eligibility framework, and the Bing grounding terms.
For customers, compliance obligations that applied only to specific AI services before June now apply consistently across all Azure services incorporating AI. If you are using any Azure AI service, you are contractually obligated to follow the product documentation and comply with the Limited Access framework, even if the specific service was not previously listed under those headings.
"Azure Direct Models" Renamed to "Foundry Models Sold by Azure"
The term "Azure Direct Models" has been replaced throughout the Product Terms with "Foundry Models sold by Azure", aligning with Microsoft's broader rebranding of its AI platform, which has been renamed three times since November 2024. Azure AI Studio became Azure AI Foundry at Ignite 2024, then Microsoft Foundry in the January 2026 Product Terms. The June update pushes the Foundry branding further by renaming the models themselves.
The same renaming cascades through Agent 365 and Power Platform, where references to "Azure Direct Models" in the Windows 365 for Agents sections have been updated to "Foundry Models sold by Azure".
Individual Model Provider Terms Consolidated
In January 2026, Microsoft added detailed, model-specific licensing terms for Grok (xAI), Llama (Meta), Black Forest Labs, and Mistral directly into the Azure Product Terms. Each provider's terms ran to several thousand words covering intellectual property, indemnification, export controls, content filtering obligations, and California-specific liability waivers. The Llama terms alone covered commercial use thresholds, EU multimodal restrictions, and an attribution requirement. The Black Forest Labs terms included a sweeping California liability waiver.
Five months later, the June update removes all of those individual provider sections and replaces them with a single provision directing customers to a documentation page for model-specific terms. The product-terms text now states that Foundry Models sold by Azure are subject to the Universal Licence Terms for Online Services and Azure service terms, supplemented by the terms at the linked documentation page.
The consolidation reduces the length of the Azure Service Specific Terms substantially. The model-provider terms are no longer embedded in the Product Terms document. They live in documentation that Microsoft can update at any time without going through the Product Terms change cycle. While model-provider restrictions were in the Product Terms, any change appeared on the monthly change log with an effective date and a description. Now those restrictions can change between Product Terms updates with no formal notification. If you are deploying third-party models through Foundry, you should monitor that documentation page independently.
Non-Microsoft Products and the Code of Conduct
The scope of models classified as Non-Microsoft Products has also changed. Third-party models in the Foundry Model Catalog that are not designated as Foundry Models sold by Azure remain Non-Microsoft Products, subject to their own licence terms. Even Non-Microsoft Products are now subject to the Microsoft Enterprise AI Services Code of Conduct.
Until June, the Code of Conduct applied only to Microsoft's own AI services and Azure Direct Models. Any model you deploy through Foundry, regardless of its provider, must now comply with Microsoft's acceptable use standards. Violation could result in service suspension.
"Azure AI Services" Split into Two Sections
The old "Azure AI Services" section in the Product Terms combined two functions. It set compliance requirements (product documentation, Limited Access, biometric data) and it contained operational terms (text-to-speech, containers, translation, content safety). These two functions are now separated into distinct sections.
The compliance framework moves to a new "Microsoft AI Services" section (note: "Microsoft", not "Azure"), which houses the umbrella definition, the Limited Access Services list, the Bing grounding terms, and the Foundry Models terms. The operational terms move to a new "Foundry Tools and Content Safety" section, which covers text-to-speech, containers, translation attribution, and the prohibition on using service output to build competing products.
Under the new structure, the "limit on customer use of service output" clause (which prohibits using the services to create a competing product) applies specifically to Foundry Tools, not to the broader "Microsoft Azure AI Services" umbrella. Similarly, the containers terms now reference "Foundry Tools and Content Safety" rather than the old "Azure AI Services" umbrella.
"Microsoft Discovery" Added as Limited Access Service
The Limited Access Services list gained a new entry called "Microsoft Discovery". This addition is not mentioned in Microsoft's change description.
The Limited Access Services list has been growing steadily. In April, Microsoft added "Guardrails for High-Risk Content" to the existing content filtering and abuse monitoring restrictions for Azure Direct Models (now Foundry Models sold by Azure). The June update adds Microsoft Discovery on top of that, but unlike the April addition, the Product Terms do not describe what Microsoft Discovery is, what it does, or why it requires Limited Access gating. Limited Access Services require registration and are restricted to customers meeting Microsoft's eligibility criteria, which as of June 2026 means being managed by a Microsoft account team.
Bing Grounding Scope Expanded
This restructuring is organisational, not commercial: costs and entitlements are untouched. What shifts is the compliance surface: one umbrella definition pushes documentation, Limited Access, and Bing grounding obligations onto every Azure service with AI, and the Code of Conduct now binds every Foundry model, third-party ones included.
The Bing grounding clause has been broadened. The previous text applied when customers used "Web Knowledge Source, which uses Grounding with Bing Search". The new text applies when customers use "Grounding with Bing Search and/or Grounding with Bing Custom Search (including use as part of Web Search Tools or Web Knowledge Source)". The clause now covers direct use of Bing grounding and adds "Web Search Tools" as a new trigger alongside the existing "Web Knowledge Source".
Privacy & Security Terms: Unannounced Changes
The Privacy & Security Terms section contains changes that Microsoft did not describe in its summary. These changes determine which services carry Microsoft's data protection, compliance, and audit commitments under the Core Online Services table.
Customer Lockbox Removed from Compliance Services
The Microsoft 365 Compliance Services list in the Core Online Services table has been modified. The May version included "Microsoft Purview Customer Lockbox" as the first item in the list. The June version removes it. Customer Lockbox, which allows organisations to control Microsoft engineer access to their data during support incidents, is no longer listed as a Microsoft 365 Compliance Service.
Customer Lockbox still appears elsewhere in the Privacy & Security Terms as a standalone service (listed under "Office 365 Services" as "Customer Lockbox") and remains in the EU Data Boundary Services list for Microsoft 365. The question is whether its removal from the Compliance Services list affects which compliance framework commitments, audit certifications, and Data Protection Addendum (DPA) sections apply to it.
Organisations that reference the Compliance Services list in their own compliance documentation, vendor risk assessments, or Data Processing Impact Assessments should verify whether the reclassification affects their compliance posture.
Azure Core Services List Restructured
The Microsoft Azure Core Services list, which determines which Azure services are covered by Microsoft's strongest contractual protections (System and Organisation Controls (SOC) 1/2 compliance, DPA Appendix A security measures, data residency commitments), has been substantially restructured. The changes include service renames, additions, and removals.
Services renamed:
Former name | Current name |
|---|---|
Azure AI Document Intelligence | Azure Document Intelligence |
Computer Vision | Azure Vision |
Face | Azure Vision - Face |
Speech Services | Azure Speech |
Text Analytics | Azure Language |
Azure AI Translator | Azure Translator |
Azure AI Custom Vision | Azure Custom Vision |
Microsoft Foundry Models (includes Azure OpenAI) | Foundry Models sold by Azure |
Services added:
Azure Content Understanding |
Content Safety (standalone entry, replacing "Azure AI Content Safety") |
Foundry Agent Service |
Observability |
Services removed:
Azure AI (previously listed as a standalone Core Service; removed without explanation) |
Azure AI Content Safety (replaced by standalone "Content Safety" entry) |
Language Understanding (LUIS, a deprecated service) |
QnA Maker (retired service) |
The additions and renames do not change the level of protection. If your contracts, vendor assessments, or internal security documentation reference specific service names from the previous list, update them to match the new names.
Agent 365 Added to EU Data Boundary
Two unannounced reclassifications anchor this section: Customer Lockbox dropped from the Microsoft 365 Compliance Services list, and the Azure Core Services list renamed and reshuffled. The renames change no protection level, but the Lockbox move leaves an open compliance question. Either way, any vendor assessment or DPIA that cites these services by name now needs updating.
Microsoft Agent 365 has been added to the EU Data Boundary Services table. For customers with tenants provisioned in the EU or the European Free Trade Association (EFTA), Agent 365 data will be stored and processed within the EU Data Boundary, aligning it with the other Microsoft 365 services already covered by that commitment.
GitHub Copilot: Data Handling Section Removed
The GitHub Offerings Service Specific Terms previously contained a dedicated "GitHub Copilot" section with detailed data handling terms. This section specified how prompts and suggestions are processed, when prompts are retained, and how data flows between the user's editor and GitHub's infrastructure. Microsoft's own description states these terms "are no longer needed" because, as of 5 March 2026, GitHub now uses a global "Generative AI Services" term set similar to the Microsoft Generative AI Services Terms.
The removed section covered three data handling scenarios: prompts retained for command-line interface (CLI) and non-editor tools, prompts retained for private language model fine-tuning, and prompts retained when customers configure third-party extension interactions. None of these scenarios are replicated verbatim in the new global terms.
The practical effect is that GitHub Copilot data handling is now governed by GitHub's own Privacy Statement and the broader Generative AI Services terms, rather than by product-specific clauses in the Microsoft Product Terms. If your organisation's data governance or procurement review referenced the Product Terms section specifically for Copilot data handling assurances, you should update your documentation to reference the new governing terms.
SPUR: RPA Training Ban Now Covers Hosting Providers
The SPUR is a separate document from the Product Terms. It governs what hosting providers and their customers may do with Microsoft software licensed under SPLA. If you run a hosting operation that provides Office, Project, or Visio to your customers through SPLA, the SPUR is your governing document, not the Product Terms.
In May, we tracked how a new "Use for Training AI Models" restriction expanded from the narrow Unattended Licence population to every Microsoft Customer Agreement (MCA) and EA customer of Microsoft 365 Applications and Office Applications. That update applied to end-customer licences. It did not touch the SPUR.
The June SPUR update closes that gap. Office Suites and Multilanguage Pack, Project, and Visio have all gained the same prohibition:
The wording is identical to the May Product Terms version. With this update, the prohibition is now universal across MCA, EA, and SPLA. A restriction that applied only to the Unattended Licence before May 2026 now covers every programme family Microsoft offers.
Microsoft's change description uses the same "clarifies existing intent" framing it used in May. As we noted at the time, the enforceable scope has expanded regardless of the stated intent. Hosting providers using Office, Project, or Visio under SPLA should review any workflows where RPA bots or automation tools generate outputs from these products and confirm those outputs are not being fed into AI model training, whether by the provider or by the provider's customers.
Get in Touch
Microsoft often changes its licensing and pricing rules, and some of the most commercially significant changes arrive without fanfare. If you need help interpreting how these updates affect your agreements, get in touch. We don't sell Microsoft licences or cloud services, so our advice is independent.