Privacy drift, October to November 2026: five changes worth understanding

Why this matters

Most months, the Microsoft and Google agreement stacks change in ways nobody outside a procurement team should care about: a product is renamed, a service is added to a table, an availability credit is adjusted. The October to November 2026 check found plenty of that. It also found five changes worth understanding, some of which move the line and some of which change how it is written, and one that moves it the other way.

The term for this is privacy drift: "the gradual expansion or alteration of privacy-relevant rights and obligations such that privacy conditions and data exposure materially change over time" (CIPPIC/IPC, October 2026). The point is that the baseline you assessed last year is not the baseline you have now, and the movement happens in small increments that never look urgent on their own.

The Microsoft DPA, Google's Cloud acceptable-use policy, and the relevant Cloud terms of service clauses were compared against their earlier editions. The other items rest on the vendors' own change notices, and published endpoint documentation, checked against the current text.

1. Microsoft's DPA now says it may report apparent child abuse material

Microsoft reissued its Data Protection Addendum, the contract that governs how customer data is handled, on 1 November 2026. One new sentence sits under "Disclosure of Processed Data":

If, in the course of providing a Microsoft Online Service, Microsoft becomes aware of apparent child sexual exploitation and abuse material, Microsoft may report such material to the National Center for Missing and Exploited Children (NCMEC) or other authority.

The new sentence says in terms that Microsoft may report such material. Our sources do not show whether such reports were possible under other terms before; what is new is that the DPA now says so. The material reported may be customer content, and the sentence provides for no notice to the customer.

It is narrow as to subject matter, but the recipient is not limited to NCMEC: the text says "or other authority", which it does not define. NCMEC is a United States organisation. The sentence states no monitoring duty.

How Microsoft becomes aware is documented, and the programme is narrow. Microsoft says it deploys hash-matching technology, PhotoDNA and MD5, to images and video shared through its hosted consumer services, and its transparency report names OneDrive, Outlook, Skype, Xbox and Bing. It may also use text and image classifiers and grooming detection on some services. The limits are as important as the mechanism: Microsoft's EU filing for Teams for Life states that it does not deploy classifiers capable of detecting previously unknown child sexual abuse material, and it has told Australia's eSafety Commissioner that it runs no automated content detection on Teams video conferences. The scanning is service-side. We have found no Microsoft document describing comparable scanning of Microsoft 365 tenant content; its published metrics and EU filings are consumer-scoped.

Matches leave the service. Microsoft reports apparent material to NCMEC's CyberTipline, as US law requires, and acts on the accounts behind it: 111,931 reports and 22,651 consumer accounts actioned in 2025, of which about fifteen per cent were restored on appeal. The report carries the Microsoft account ID, username, timestamp, and IP address. NCMEC forwards reports to law enforcement, including outside the United States. Canada has its own mandatory reporting statute for Internet service providers, but it is triggered by being advised of an address or by reasonable grounds to believe, and it states that nothing in it requires or authorises a person to seek out the material.

The commitments about law-enforcement demands and other third-party requests sit in the same section and did not change. The change is one added sentence, not a rewrite of the disclosure rules around it.

2. Zero data retention, and Google's Safety Retention change

Zero data retention is an endpoint promise: the provider processes the prompt, returns the answer, and keeps neither afterwards. OpenRouter now defines it as "no routine storage of prompts or responses after processing", with a stated exception for child-safety screening that reaches even zero-retention traffic. Its own guidance is careful about the limits: the promise governs provider-side storage, not the copies in our own systems, and request metadata such as token counts, latency, and model choice is still retained. For a law firm the attraction is obvious. A prompt that is not stored is a prompt that cannot be disclosed, breached, or subpoenaed, and it answers the data-minimisation question before anyone asks it. The promise is narrower than a confidentiality agreement and it is not a training policy. It is one layer, not a complete answer to client confidentiality.

The routing layer moved on 18 October 2026. OpenRouter reports that Google now requires Safety Retention for Google models served through Vertex, and OpenRouter records Safety Retention as a third data-policy tier alongside zero data retention and retention with training. Google's own abuse-monitoring documentation matches the description: prompts are not logged by default, but prompts flagged by automated safety classifiers may be logged for up to 90 days to examine possible policy violations, may be assessed by authorised Google staff, and are not used to train or fine-tune models. The logged prompts are not encrypted with customer-managed keys. Such endpoints do not meet a strict zero data retention requirement.

Two qualifications follow from the documents. OpenRouter's tier definition is broader than Google's flagged-prompt description: Safety Retention limits why data can be kept, and it does not require a request to be flagged before it can be stored, so the safer reading is the broader one. And this does not impact customers under a Google Cloud Master Agreement: Google notes that they are exempt from this prompt logging by default, so the contract layer still decides how the retention rule lands.

Whether such an endpoint is used at all depends on a routing setting. The "ZDR only" setting excludes Safety Retention endpoints and makes most Google models unavailable; "allow Safety Retention" admits them. Enterprise accounts default to "ZDR only". All other accounts default to allowing Safety Retention, so a self-serve account can be routed to retaining endpoints without anyone having decided to. The checks are unglamorous: confirm the account default, confirm the guardrail settings, and confirm the endpoint's classification in the published endpoint list rather than on a marketing page. A retained prompt is a copy outside the firm's control, in a system the firm cannot search, preserve, or delete on its own schedule, and it enlarges the surface a breach or a third-party demand can reach. This is a routing policy, not a new Google contract term, which is why it can pass unnoticed.

3. Google extends existing terms to AI Agents and system services

Google's Cloud terms now say that the use restrictions apply to "the Services or any AI Agent", and the customer indemnity covers third-party claims arising from use of the services or AI Agents in breach of the acceptable-use policy or the restrictions. Its acceptable-use policy says directly: "If You are using any Agentic AI Services or AI Agents (as defined in the applicable Service Specific Terms), this AUP applies to such use."

Google extended two existing clauses to AI Agents: the clause that bars certain uses of the services, including high-risk activities and breach of the acceptable-use policy, and the customer's indemnity to Google for third-party claims arising from breach of those rules. The allocation of responsibility is not new; its reach is. The clauses we compared line by line allocate responsibility rather than change data handling. Google also updated its Service Specific Terms, which we did not compare.

The Service Specific Terms supply the definitions, and they are broad. An AI Agent is "goal-oriented, AI systems or workflows that perform actions or tasks on behalf of Customer in a supervised or autonomous manner", and an Agentic AI Action captures omissions as well as acts. The customer is solely responsible for any Agentic AI Action, for authorising an agent's access to data and systems, and for supervision in production environments. The indemnity is not a general liability for data going astray. It covers third-party claims arising from a breach of the acceptable-use policy or the use restrictions, and an agent misdirecting data is not necessarily either. What changed is that the rules now name agents explicitly, so the customer's existing responsibility follows the agent.

Nothing in these documents expands what Google may do with customer data. The Service Specific Terms still say that Google will not use Customer Data to train or fine-tune AI models without the customer's permission or instruction, Generated Output remains customer data, and no new retention period, disclosure right, or monitoring duty appears. The drift here is in accountability and reach, not in Google's processing permissions.

The second instrument is the Google Play Terms of Service, effective 17 November 2026. The definition of "Content" now includes "system services (including, but not limited to, those provided by Google Play services)". Google describes the Play change as a clarification. On the text it is definitional rather than a new grant of rights: the Play terms license content to the consumer, they take no rights from the user, and the privacy sentence still points to the Google Privacy Policy. What the change does is move Play services, the Play Store, and operating system updates inside a term that already carries automatic update consent, a reservation of rights, and a list of use restrictions. It sits in the consumer Play terms, not the Cloud or Workspace stack.

The cloud terms took effect on 12 October. Continued use counts as acceptance, so the acceptance timeline runs from that date.

4. Google changed a setting, not a contract, and expanded what it keeps

The clearest example of drift in this batch is not a contract at all. Google began rolling out new Search settings in late May 2026. The rollout replaces the old Web & App Activity and Search personalisation controls, for Search services, with two independent settings, Search services history and Personalised Recommendations, and adds a Save media setting. Save media stores images, files, audio, and video from Search interactions such as Lens and Search Live. In its rollout notice, as reported by 9to5Google, Google says saved media is used "to develop and improve Google services and technologies, including AI models and safety measures."

Save media is an option within Search services history that can be switched off separately. This is a consumer settings change, made in the Search settings of personal Google accounts, not a contract change, and it does not alter the Google Cloud or Workspace terms. Google's help pages say that work or school accounts may depend on administrator access to Search services, and that Search Services History from education accounts is not used to train generative AI. Whether Save media applies to a work account is not established here.

The privacy bargain moved because a product changed, not because a contract did, and a settings screen is much easier to miss than a reissued addendum.

5. Microsoft added a qualifier to its preview clause

The November DPA adds a short qualifier. The listed terms (processing of personal data, GDPR, data security and HIPAA business associate) still do not apply to previews unless the preview allows personal data processing, "except as stated otherwise for that Preview". Microsoft calls this a clarification. The text does not say in which direction a preview may depart from the default. The qualifier is a reminder to read the preview's own terms before relying on the main addendum.

The pattern is well described in the CIPPIC report prepared for the IPC. It defines a new-feature carve-out as "a contractual mechanism under which protections against adverse amendment, or related stability expectations, do not fully apply when the provider characterizes added functionality as a new service or feature rather than as a modification of the existing service" (Beyond the Initial Agreement: How Privacy Drift Affects Modern Third-Party Contracting, p. 15). The report treats that mechanism as a distinct drift pathway: new functionality enters an existing environment under supplemental terms, and a control negotiated for the original service may not cleanly apply to the new feature set (p. 24). The report predates Microsoft's November qualifier, so the fit between the two is our observation rather than the report's.

The preview carve-out was already significant. For previews that do process personal data, the DPA already lets Microsoft store and process Preview Data in the United States or any other country in which Microsoft or its Subprocessors operate, and the retention terms do not restrict Microsoft's right to delete Preview Data. None of that changed in November.

Not every change is a privacy change, and not all drift is bad

The Microsoft service-level agreement was also reissued on 1 November 2026. We found changes to availability commitments and service credits, and no change to data-location or data-handling terms. It does not appear to raise a privacy issue on what we read.

One change moved in the protective direction. Microsoft added Agent 365 to its Core Online Services table, which is the classification that keys the security practices, EU Data Boundary, and data-at-rest location commitments. Adding it extends the Core Online Services commitments to the new service. We did not compare the earlier tables.

Microsoft also reorganised how Windows 365 products are listed in the EU Data Boundary and data-at-rest tables. We could not compare the earlier tables, so we cannot say whether any commitment changed.

One change is a scope reminder: GitHub Copilot Standalone, added on 28 October 2026, falls under the GitHub carve-out, so the GitHub Privacy Statement and GitHub Data Protection Agreement apply rather than the Microsoft DPA. A GitHub-branded product is not automatically governed by the Microsoft DPA.

How this is compiled and delivered

This post is an output of a monthly agreement-stack check. Every tracked instrument in the Microsoft and Google stacks is fetched from its source, compared against the edition we last recorded, and written up as dated, source-linked findings in a running changelog and registry. The check is scheduled; the judgment is not. A detected version bump is evidence of an update, not a finding. A change reaches these pages only after its practical effect is explained and its source has been opened.

The check runs as an agentic workflow. A coordinating agent works through a documented procedure: it reads the run state, fetches each instrument, moving from search to direct fetch to a browser session when a vendor page resists, compares the text against archived editions, classifies what kind of change it is, and drafts summaries that pass a human-in-the-loop review before anything is published. Where a source cannot be opened, the run is recorded as partial rather than guessed at. The research behind this post ran the same way: parallel research agents retrieved the Microsoft transparency reports, OpenRouter's endpoint documentation, and the IPC report itself, and every quotation here was checked against the page it came from.

The full procedure is published as the agreement-stack monitoring workflow: its steps, its sources, and its quality rules, including the rule that nothing is marked verified without opening the source. It is one instance of a practice we build for our own work and for clients: legal AI solutions and workflows for compliance monitoring, contract-stack tracking, regulatory watch, and research, designed to be repeatable, auditable, and tied to their sources. The method is the answer to the point this post keeps making: the baseline moves, and a workflow is how you notice.