Governed Growth, Part 2: The Retention Window That Quietly Shrank

If you turned on Grounding with Google Search in a governed estate, the terms got better for you on a specific Monday and you probably never heard. On February 23, 2026, Google revised the retention clause in its Service Specific Terms: the window dropped from thirty days to up to three, and what’s kept narrowed from your prompts and the model’s output to short-lived debug logs. For anyone running search inside a boundary they have to defend to a security reviewer, that is a real win, and it landed with no announcement I ever saw.

I know the date because I can check it. Google keeps every dated version of the Service Specific Terms at a stable archive URL, and the two that bracket the change sit side by side: the February 18 version still says thirty (30) days, the February 23 version says up to three (3) days, and nothing was published between them. You don’t have to trust the number you remember from last quarter; you can diff two dated documents and prove when the clause moved. It moves often enough that it changed again on July 29, the day before this post went up—that revision left this clause alone, but it renamed a product and added a controlled-goods provision elsewhere, so the document you’re citing has a version history and isn’t done changing.

What Grounding With Google Search Retains Now

The zero data retention page quotes the current clause, and it’s worth reading the actual sentence rather than my paraphrase:

Grounding with Google Search: As outlined in Section 20 “Generative AI Services: Grounding with Google Search” of the Service Specific Terms, Google collects and stores logs, which contains the following Customer Data: queries derived from End User prompts and contextual information that Customer may provide along with the prompts that are not associated with any Customer or its End Users for up to three (3) days, this stored information may be used for debugging of systems that support Grounding with Google Search. There is no way to disable the storage of this information if you use Grounding with Google Search. If you require zero data retention, we recommend using Web Grounding for Enterprise.

Two things about that clause decide whether a team relaxes or panics. It is not training: the Training Restriction in the same terms (§17) says Google won’t use your data to train its models, and it covers every managed model on the platform, Gemini and the partner models alike. The logs stay inside Google’s boundary, kept to debug the search systems for up to three days, then aged out. And it is fixed: no per-request flag, no config toggle, no scope you can narrow to switch the debug logging off. If you need zero retention you don’t tune this tool, you leave it—for Web Grounding for Enterprise, the grounding capability built for teams that need it, on the same base model with a deliberately different posture. The clause names it: if you require zero data retention, we recommend using Web Grounding for Enterprise.

That corrected posture makes the enterprise case easier, not harder. Three days of derived debug queries is less kept, kept shorter, and less sensitive than thirty days of verbatim prompts and answers—better on every axis a security reviewer weighs.

Where the Old Number Went

The old thirty-day, prompts-and-output language didn’t disappear when the clause changed. It moved. It now describes a different capability—Grounding with Google Maps, a sibling subsection under the same Section 20, which stores prompts, contextual information, and generated output for thirty days. So if you’re certain you read “thirty days, prompts and output” somewhere in Google’s terms—you did. It’s just attached to Maps grounding now, not Search grounding. Two capabilities from one provider, one parent section, two different postures. You only catch that by reading the current clause instead of the one you remember.

I’ve watched how sharp the consequences get when a team assumes a capability’s data handling instead of reading it. On a regulated-industry assistant build, my team caught a safety-tooling and logging path that was silently writing raw PII—Social Security numbers among it—into audit logs. Nobody chose that. It rode in on a capability’s behavior, not on the model anyone had vetted. We drove a redact-then-log fix, a compliance-grade save that had nothing to do with which model was answering and everything to do with what a capability did with the data on its way out. The exposure lived in the capability, and it stayed invisible until someone read what the capability actually did—and kept reading, because what it does can change.

The Same Capability, With Retention Flipped

Now the same capability, the other vendor—and here the mechanism inverts. On the Gemini path, retention is a short-lived debug log and you step to a different tool to escape it entirely. On Claude’s server-side web search, retention runs the other direction: when the coverage that lets a regulated team use the tool at all kicks in, retention becomes a condition of that coverage, and zero data retention is off the table. One capability category, two vendors, and the retention term pointing opposite ways. The documented detail is below.

I’m using Gemini and Claude here because they’re the pair whose terms are easiest to read side by side—the same gap opens under any two models you happen to enable. Both are good, common, illustrative examples of the same point: server-side web search is a capability with its own terms, and those terms are the thing you read, per capability, and re-read, because they move.

The worked example: the HIPAA Business Associate Agreement. The concrete instance where this is written down is the HIPAA Business Associate Agreement—the contract a vendor signs before it may handle protected health information on your behalf. I lead with it because it’s the worked example with the sharpest, most legible terms, not because it’s the common one; most readers will never sign a BAA, and Part 1 already covered the wider family of instruments it belongs to. Read it as the illustration, then generalize the mechanism.

Under the BAA, Covered Models require retention and are not available with Zero Data Retention enabled, while some services (Claude Code among them) are only BAA-covered with ZDR on—so those services can’t use Covered Models under the BAA at all.¹ Because this is a partner’s contract, read that as true as of the dated coverage table, not as a permanent fact. Verify the current terms before you rely on them—Google’s terms did exactly this kind of moving in February, and a partner’s will too.

Read the current, dated terms and the coverage is more generous than the folklore suggests. Anthropic’s dedicated Business Associate Agreement coverage documentation—the feature-by-feature table that is the authoritative current source—lists web search as covered under the BAA.¹ Older carve-out language still lingers on other pages that read as if the BAA “would not apply” to web search, but the dated coverage table is the feature-specific source that governs.

What rides in, and what gets carved out. The coverage table that pulls web search in draws the boundary somewhere else, and each carve-out is a different capability that rode in on the same model:

• Web Fetch is not covered. The table marks it “not covered under Anthropic BAA and not accessible for HIPAA-Ready API users.” Web search is in; web fetch—retrieving the full contents of a specific URL—is out. Two features that sound like siblings, on opposite sides of the line.
• Code execution’s network egress is not covered. File creation and code execution are covered, “excluding network access and use of external websites.” The sandbox is in; the moment it reaches out to the open internet, you’re outside the BAA.
• Third-party MCP and connector data flows are not covered. Anthropic says it plainly: you can use them, but “sending data to 3rd parties via this feature isn’t covered under Anthropic’s BAA,” and the administrator who enabled the connector owns that exposure. This is the one carve-out that isn’t a quirk of one vendor—no vendor can make promises about a destination you chose and it cannot see.

Every line in that list is a claim about a partner’s instrument, and partner terms move—so read each one as current only against the dated coverage table above, and re-check it before you depend on it.¹

And the provider is undisclosed. The provenance point Part 1 flagged, now concrete: when Claude’s server-side web search runs, the search goes through a provider Anthropic wires up, and which provider is not disclosed to you. Google’s own Model Garden documentation describes it as “a third-party search provider,” and the results come back as an encrypted list of snippets; Anthropic’s own docs never name the provider either.

Same Capability, Opposite Posture

Set the two side by side, axis for axis, and the contrast is literal.

graph LR
  app["Application / Agent<br/>one line in a tools list"]

  subgraph gemini["Grounding with Google Search"]
    g1["Retention: short-lived debug logs, up to 3 days"]
    g2["Scope: queries derived from prompts, for debugging; not prompts and output"]
    g3["Opt-out / ZDR: none for this tool; switch to Web Grounding for Enterprise"]
    g4["Provider: Google end-to-end, and selectable"]
  end

  subgraph claude["Claude server-side web search"]
    c1["Retention: required under coverage"]
    c2["Scope: governed by the BAA coverage table"]
    c3["Opt-out / ZDR: off the table under the BAA"]
    c4["Provider: undisclosed third party"]
  end

  app --> gemini
  app --> claude

Read the rows straight across—retention, scope, opt-out, provider—and the posture diverges on every one. Gemini keeps a short-lived debug log, leaves you a zero-retention door in a sibling tool, and lets you name and swap the search provider. Claude makes retention a condition of coverage, closes the zero-retention door under the BAA, and routes through a provider you cannot see. Same capability category. Different documented posture, drawn on purpose by each vendor in its own terms.

The instinct, reading that, is to score it. Which one is better? That’s the wrong question. Ranking the two vendors turns an architecture problem into a loyalty test, and a loyalty test tells you nothing about where your data went. Neither posture is a defect, and this is where it’s worth being concrete about what the platform actually gives you—as affordances, choices you get to make, not as a scoreboard:

• A zero-retention sibling exists on the same platform. The team that needs zero retention isn’t told to live with the debug log; Web Grounding for Enterprise is a first-class tool on the same base model with a different posture. The choice sits with you, not with the default.
• You can name the provider, or be the provider. Grounding with Google Search runs on Google’s own engine end to end—the trust boundary you already accepted—and Google exposes a menu of named alternatives (Grounding with Parallel, Grounding with Exa, or your own search API). The contrast with an undisclosed downstream provider is real. Neither is wrong. But they aren’t the same decision.
• One enforcement plane governs partner models too. The org-policy default-deny on constraints/vertexai.allowedPartnerModelFeatures keeps partner web search—Claude’s included—off until a human turns it on, from one control point, for a model Google didn’t build. A platform that will enforce your capability decision across a competitor’s model is a platform making an honest offer.
• The no-training baseline covers partner models too. The §17 Training Restriction reaches every managed model on the platform, Gemini and partner alike—Google committing that it won’t train on your data even about a model it doesn’t own.

None of those is “Google is more private than Anthropic.” Each is “the platform lets you decide something you’d otherwise inherit.” That’s the honest version of a benefit: an affordance you can reach for, not a verdict you’re handed.

The Real Lesson: Govern Facts That Move

Here is the part I’d actually staple to a wall. It survives the next revision of every term in this post.

The mistake wasn’t quoting thirty days. Thirty days was correct when it was written, verified against the terms as they stood. The mistake would have been hard-coding it—baking a specific number into an architecture decision, a runbook, a slide, a compliance memo, as if it were a constant. It wasn’t a constant. It was a snapshot of a moving thing, and moving things need to be governed as moving things.

That changes how you write the fact down. Instead of “Grounding with Google Search retains your data for thirty days,” write “Grounding with Google Search keeps short-lived debug logs—see the current Service Specific Terms for the exact window,” and link the primary doc. The hedge isn’t vagueness; it’s accuracy about a fact whose defining property is that it drifts. A number pins you to a moment. A link to the primary source pins you to the truth, whenever someone reads it.

And retention isn’t the only term that moves. Region-bound capability behavior is filed-bugs-not-theory for me—I’ve hit a model feature gap that showed up only in an EU (London) region and not elsewhere. Same model, same call, a different answer because of where it ran. Section numbers move. Coverage tables move. Default states move. Product names move. Every one of those is a fact you can either snapshot and forget, or govern as a live value with its source attached.

The habit that survives all of it is small and boring: for any load-bearing claim about a vendor’s terms, cite the dated primary source, hedge the specific number, and re-read it before you rely on it. That’s not extra caution. It’s the only version of “I read the terms” that stays true past the day you read them.

What I Do About It as One Builder

There’s a move that sidesteps the whole question of whose retention posture you inherited, and it’s the one I actually reach for. Instead of turning on a model’s built-in server-side search and accepting whatever terms come wired to it, I expose search as a tool I run—in a subprocess whose data path I chose on purpose.

That’s what gemini-search-mcp is: a small MCP server I built for my own daily work. One tool, web_search, answered by Gemini’s grounded search, running in a process I control. My assistants call the tool; the search happens on my side of the line, against the backend and the terms I picked, with citations coming back so I can check the sources. The retention posture stops being something I inherit from whichever model a developer enabled and becomes a decision I made when I stood the server up—and, usefully, it also means the terms I care about are the ones for the grounding mode I selected, which I can read in one place.

It comes down to one install and one config decision. Install it, then choose where the grounded search actually runs:

1
go install github.com/cwest/gemini-search-mcp@latest
2

3
# The config that makes the boundary YOUR decision:
4
# point it at your own Google Cloud project, so the grounded search
5
# runs inside the trust boundary you already govern.
6
export GOOGLE_CLOUD_PROJECT=my-governed-project
7
export GOOGLE_CLOUD_LOCATION=global

The server checks for a Gemini Enterprise Agent Platform project first, so setting your project and location routes the search through the Google Cloud project you govern—the same boundary, the same residency and audit controls Part 1 covered—instead of a model’s built-in search whose posture a developer inherited by accident. Skip them and the server falls back to the quick AI Studio key path. The developer companion walks the whole build: the grounding call, how citation extraction works against the Gemini API, and a head-to-head model evaluation.

The Governance Move, and the One That’s Still Open

Owning the search yourself is what I do. It doesn’t scale to an organization where hundreds of developers each add their own line to their own tools list. For that you need the pair of instruments Part 1 named: the legal instrument—the DPA, the BAA, or whichever member of that family is yours—where you read what each capability’s terms actually commit the vendor to, and the technical instrument—Organization Policy, and specifically the default-deny on constraints/vertexai.allowedPartnerModelFeatures—where you enforce the decision so it can’t be tripped by accident. The legal instrument tells you what the terms are. The technical instrument makes your decision stick. The cloud estates that grow without growing their exposure run both—and re-read the legal instrument on a cadence, because this post is proof that its contents don’t hold still.

But knowing the retention posture doesn’t stop the keystroke. That’s the tension this post leaves open on purpose. You can read every retention clause, sign the right instrument, and draw the boundary exactly where you want it—and tomorrow morning a developer on a team you’ve never met will still add one line to a tools list and trip the capability anyway. Reading the terms tells you which posture you’re in. It does nothing, by itself, to keep a good-faith developer from walking into the wrong one before coffee.

Closing that gap—turning “we decided” into “the platform enforces what we decided, at the org boundary, defaulted to no”—is exactly what Part 3, Default-Deny for Model Capabilities is the runbook for: which org-policy toggles, at which scope, via gcloud and Terraform. Part 4, Multi-Model, Governed, and Boring is the end state, where the clause you just read stops being something you have to remember and becomes one of three registers the platform already has on file.

Read One Clause Before Part 3

Part 1’s audit was the whole spreadsheet: every capability, every axis, one row each. Don’t redo it. Do the deep cut instead—the one row this post is about.

For the one capability this post covered—server-side web search—go read the actual retention clause, today, from the primary dated source, for whichever model your teams actually use. Not the summary you remember. Not last quarter’s fact. Not this post’s paraphrase, which is a snapshot too. The current, dated, feature-specific text: the Service Specific Terms for Grounding with Google Search, or Anthropic’s BAA coverage table for Claude’s web search. One capability, one clause, one afternoon.

The thirty-day number I could have quoted went stale in February, and plenty of careful writing kept repeating it for months. That isn’t a story about a number; it’s a story about every load-bearing fact in every governance decision you’ve made. The developers on your teams will keep turning capabilities on whether or not you’ve done this reading. The only question is whether you read the clause recently enough that the posture they land in is still the one you chose.

This is Part 2 of the Governed Growth series. Retention terms, BAA coverage, and contractual scope are drawn from Google Cloud’s and Anthropic’s own published terms and documentation, and from the primary text of the privacy regulations named in Part 1. Verified against the live terms on 2026-07-22; because those terms move, check the linked primary sources for the current text.