Governed Growth, Part 1: Better Together, Governed Apart

“We approved the model” and “we approved the model’s web search” are two different decisions—and most platforms treat them as one.

I know that gap because I’ve spent three years living in it. I founded and run a hands-on, multi-day engagement where Google engineers co-engineer with a company’s own engineers to build production-grade software—much of it AI—on Google Cloud, accelerating their roadmap and cutting time to value. That’s put me in the room with enterprises across multiple countries and continents, disproportionately in the industries where governance is the job, not an afterthought: healthcare handling PHI, telecom, financial services. The same failure keeps showing up. A team picks a model, ships, and only later discovers it quietly inherited a capability’s data-handling, region, and logging behavior it never actually chose. This series is that pattern written down by someone who has watched it happen at scale—and who ships the plumbing too. The open-source grounding server in the companion post encodes the capability-versus-model split in running code, not just in an argument.

That gap is the whole series. Governed Growth rests on one idea with outsized consequences: on a modern AI platform, a capability’s trust boundary is a separate decision from the model’s, and the cloud estates that grow safely are the ones that treat it that way. This post sets the frame. The parts that follow turn it into policy you can enforce.

Here is the shape of it. Your platform is doing well. More teams want in, and they don’t all want the same model—one group is building on Gemini, another swears by Anthropic’s Claude, a third wants both in the same application, and next quarter someone will ask for a model that isn’t on anyone’s radar yet, each doing what it’s best at. So you open the door. You grant access, usage climbs, and everyone is happy. Somewhere in that expansion, a server-side capability gets switched on—web search, say—and the data path it opened never got a decision of its own. It rode in on the model’s coattails. Nobody chose it. It just arrived.

That is expansion with exposure, and it’s the default outcome unless you architect against it. The good news, and the through-line of this series, is that Google Cloud is built to let you architect against it—to grant capability broadly while keeping each model’s data path a deliberate, fine-grained decision rather than an accident. The goal is governed growth: you scale capability access up, and the guardrails scale with you.

And the upside is real before we ever reach the caveats. You can enable Anthropic’s Claude models directly in Model Garden and run them inside Google Cloud—under the same IAM, the same VPC Service Controls, the same regional data-residency and audit controls that already govern your first-party workloads. That is the good version of multi-model: the model a team swears by, running inside the governance perimeter you already trust. You don’t have to choose between the best tool for the job and the cleanest audit story—which is exactly why getting the capability seams right is worth the effort.

The Trap: One Grant, Two Trust Boundaries

The instinct is to reason about a model as a single thing you either trust or don’t. You vet Claude, you approve Claude, you move on. But a modern model is not one thing. It is a base model plus a set of server-side capabilities the vendor runs on your behalf—web search, structured outputs, code execution—and those capabilities can cross a completely different trust boundary than the base model does.

The clearest example is web search. When a model answers from its own weights, your prompt goes to the vendor under the vendor’s model terms. When that same model runs a server-side web search, your prompt is now fanning out to a search provider, under whatever terms govern that capability—terms that are frequently not the same as the base-model terms, and are sometimes carved out explicitly.

This is the finding that reframes the whole problem, and it holds for both vendors, from their own documents. The right questions to ask about any server-side capability are three: who retains the data, is it shared beyond the vendor you already trust, and under whose terms?

• Google’s Training Restriction (Service Specific Terms §17) says Google won’t use your data to train its models, and it covers all managed models on the platform—Gemini and the partner models alike. That baseline is strong, and it’s worth saying clearly before the caveat: turning on search doesn’t put your data into anyone’s training set. What it does do is open a retention window. Turn on Grounding with Google Search and, per the Service Specific Terms (§19), Google retains your prompts and output for a fixed window you can’t disable—Part 2 reads that clause line by line and is the home of the full finding. The data stays inside Google’s own boundary and isn’t used for training; it’s retained for grounding, debugging, and testing, then it ages out. For many teams that’s perfectly usable. For a team with a zero-retention obligation it’s disqualifying, and Google’s own answer to that team is to use Web Grounding for Enterprise instead. Either way, the base-model guarantee doesn’t carry to the search capability unchanged. It can’t; the capability is a different thing with different terms.
• Anthropic draws its line in a different place, and it has moved—which is exactly why you read the terms per capability rather than trusting a fact you learned last quarter. Take one concrete example: the Business Associate Agreement (BAA), the contract a vendor signs before it may handle protected health information on your behalf under HIPAA. The BAA is a US-only instrument, and a deliberately narrow one—only organizations that qualify under HIPAA (healthcare providers, health plans, and the like) can even enter one. Hold onto that pattern, though, because it recurs everywhere: it’s never on by default, you opt in, each vendor implements it differently, and it covers only the specific services and capabilities the vendor names. Per Anthropic’s own dated BAA coverage documentation—the feature-by-feature table that is the current authoritative source—Anthropic’s BAA covers web search as an eligible service. That makes sense once you see where the work happens: web search is a server-side capability—Anthropic runs the search on its own infrastructure, inside the boundary its BAA governs, so it can name it as an eligible service. Because this is a partner’s contract and its lines move, verify the current terms against that dated table before you rely on any of it—the discipline the upcoming Part 2 cashes out in full.
• One boundary is worth pulling out on its own, because it isn’t one vendor’s quirk—it’s structural, and it applies to every vendor. Some capabilities send your data to a destination the model vendor never sees and cannot govern, and the terms follow the data across that line. A third-party MCP connector is the clearest case: you’re handing data to a server you chose, over a boundary the vendor doesn’t control. Web Fetch is the same shape—the model retrieves a URL supplied on the client side, so the fetched destination sits outside the vendor’s controlled surface, which is exactly why Anthropic’s dated BAA coverage documentation covers server-side web search but not Web Fetch (and likewise not third-party MCP connectors, nor code execution’s network egress). The reason is universal: no vendor can make promises about a destination it doesn’t control. The administrator who enables one of these owns that exposure, whichever model is on the other end. That’s the whole point of reading capability-by-capability—where a capability runs decides whose contract governs the data. (Partner terms move; confirm the current table before you lean on any coverage claim here.)¹

Find Your Own Version of the Line

You may never touch a BAA—most organizations won’t, and outside the United States you can’t. But the BAA is just the sharpest instance of a rule that holds everywhere: a governance guarantee is opt-in, per-vendor, capability-scoped, and, for some instruments, gated to a defined class of party. Wherever you operate, there is a contract that plays the BAA’s role, and your job is to find it and read where it draws the line.

For most of the world, that contract is the Data Processing Agreement (DPA). It is the workhorse of privacy law—the controller-to-processor contract that GDPR established in the EU and UK, and that recurs under Brazil’s LGPD, Japan’s APPI, Singapore’s PDPA (which calls your vendor a data intermediary), Canada’s PIPEDA, and Australia’s Privacy Act. Unlike the BAA, the DPA is not gated: any customer processing personal data can execute one. And you usually execute one—major vendors ship a single global DPA that folds the per-region terms in by reference. Google Cloud’s Cloud Data Processing Addendum carries EU, UK, Swiss, Brazilian, and other privacy laws in one document (see its Appendix 3, “Specific Privacy Laws”); Anthropic’s DPA does the same, attaching the EU Standard Contractual Clauses plus UK and Swiss addenda. Both are public—you can read exactly where each draws the line before you sign. The procurement question is usually “execute the vendor’s DPA,” not “negotiate a contract per country.”

Some instruments are gated the way the BAA is—only a defined class of entity may enter them. AWS GovCloud is gated to verified US government agencies and screened US persons. The CJIS Security Addendum, for criminal-justice data, may be signed only by a contractor under a specific agreement with a criminal-justice agency, with contents fixed by the US Attorney General. In EU finance, the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554—not to be confused with DevOps Research and Assessment, the software-delivery research program) sets Article 30 contractual provisions that bind only regulated financial entities. The BAA, GovCloud, CJIS, and DORA are the gated family; the DPA is the open one. The question that tells them apart is simple: who is allowed to sign it?

Two things the contract does not do, and both bite architects who assume it does. First, a DPA gives you the contractual commitment, but it does not pin where your data physically lives. Data residency is a separate configuration surface—on Google Cloud it’s governed by the Service Specific Terms and a per-service residency list, not the DPA itself. “We signed the DPA” and “our data stays in the EU” are two different decisions. Second, these instruments cover GA services, not experiments. Google’s Pre-GA Offerings Terms (Service Specific Terms, §5(b)) state plainly that anything labeled Preview, Alpha, Beta, or Experimental is “not a Service,” and the data-location commitment “will not apply” to it; Anthropic’s BAA excludes beta features. The same capability-scoped lesson, one level up: the contract you signed may not cover the preview feature you’re about to switch on.

Same capability category. Different lines, drawn on purpose, documented, and subject to revision. The lesson is not “this vendor is risky.” It is that a data guarantee has more moving parts than “which model.” Which capability is on, who retains the data and for how long, where it physically lives, whether the contract even covers a preview feature, and who is allowed to sign that contract in the first place—each is a separate variable, and each can be set independently of the model you picked. Put plainly: your real data guarantee is not a single toggle but the product of capability × vendor × region × retention × training-use × service-maturity × the instrument you govern it with, and governed growth is the practice of setting each of those factors on purpose so you can grow usage without growing exposure. This series pulls hard on one of those variables, because it’s the one most often assumed away: the trust boundary a capability crosses is a separate decision from the model’s. Get that one right and you have the habit that makes the rest tractable—read the terms per capability, not per model, and re-read them, because the lines move.

How Easily This Gets Switched On

The reason this matters in practice is that tripping a server-side capability is almost effortless—far easier than the deliberate decision it deserves. It happens two ways, and most estates hit both: an agent that reaches for the tool on its own, and a single line someone adds in code.

The Agent That Searches Without Asking

Coding agents and chat clients—Claude Code, Gemini’s Antigravity CLI, Cursor, an internal agent your platform team wrote—are built to reach for the web when a task needs current information. A developer asks whether there’s a known CVE affecting an internal dependency, and the harness decides, on its own, that it needs to search. What actually serves that request? The model’s server-side web search. Nobody opened a settings panel. Nobody approved a data path.

So what actually leaves your estate? Less than the worst-case fear, more than nothing. The model doesn’t ship your whole context window to the search engine; it generates a search query and sends that. But the query is written from your context—so the internal package name, the private service, the not-yet-public detail the developer was asking about can end up in the query string itself. And separately, the capability runs under its own terms: with Grounding with Google Search, the prompt and contextual information you send are retained—Part 2 reads the exact clause and its retention window. Two different data flows, one casual trigger—and a trust boundary crossed as a side effect of the harness making a reasonable engineering choice.

The One Line in a Pull Request

If your teams build on the models directly, the toggle is one line. All of the code below runs through Google Cloud, against the platform’s own endpoints—so the model a team swears by lives inside the governance perimeter you already trust. Here is Google’s Gemini, grounding a response with Google Search using the google-genai SDK:

1
from google import genai
2
from google.genai import types
3

4
client = genai.Client()
5

6
prompt = (
7
    "Is there a published CVE for acme-internal-auth 2.3.1? "
8
    "Our payments service pins it."
9
)
10

11
response = client.models.generate_content(
12
    model="gemini-3-flash",
13
    contents=prompt,
14
    # This one line opens the data path—and its terms.
15
    config=types.GenerateContentConfig(
16
        tools=[types.Tool(google_search=types.GoogleSearch())],
17
    ),
18
)

Claude is the same shape, accessed through Google Cloud with the AnthropicVertex client. One entry in tools turns on its server-side web search:

1
from anthropic import AnthropicVertex
2

3
client = AnthropicVertex(region="us-east5", project_id=PROJECT_ID)
4

5
prompt = (
6
    "Is there a published CVE for acme-internal-auth 2.3.1? "
7
    "Our payments service pins it."
8
)
9

10
response = client.messages.create(
11
    model="claude-haiku-4-5",
12
    max_tokens=1024,
13
    messages=[{"role": "user", "content": prompt}],
14
    # One entry does the same for Claude—if the org allows it.
15
    tools=[
16
        {"type": "web_search_20250305", "name": "web_search", "max_uses": 5}
17
    ],
18
)

Run that against a model your organization has cleared for search, and it works: Claude issues real web searches from inside Google Cloud and comes back with grounded results. That is the “better together” half, in running code—a partner model doing its job inside the perimeter you already govern. Useful, and completely unremarkable. The interesting part is what happens when the same code meets a capability the organization has not cleared.

Now change one string. Point the same request at claude-opus-4-8, a model whose web-search feature the organization has not cleared, and the platform answers for the governance team before a single token is billed:

1
{
2
  "error": {
3
    "code": 400,
4
    "message": "Organization Policy constraint constraints/vertexai.allowedPartnerModelFeatures violated for `projects/287318173485` attempting to use a disallowed feature web_search for Partner model claude-opus-4-8. Please contact your organization administrator to fix this violation by adding `publishers/anthropic/models/claude-opus-4-8:web_search` to the allowed values.",
5
    "status": "FAILED_PRECONDITION"
6
  }
7
}

That is the “governed apart” half, and it is not a diagram or a promise—it is a real response from a real call. The organization decided, at the policy layer, that this model may not run server-side web search, and the platform enforced it the moment the code asked. The error even names the exact grant an administrator would add to change the answer. Same one-line toggle, two outcomes, and the difference between them is a deliberate decision recorded as policy—not a setting buried in a request nobody reviewed.

The point is not the specific model on either side of that line; the allowlist is yours to set. The point is that the toggle is a single addition to a request you were already making—there is no scary dialog, no “are you sure,” no separate contract to sign. The capability is designed to be easy to turn on, and the ease of that toggle is inversely proportional to the deliberateness of the decision behind it. A data path that opened this casually is one nobody actually chose. That is the gap between “we approved the model” and “we approved the model’s web search,” rendered in the two places it actually happens: an agent reaching for a tool, and a pull request adding one line.

There is a companion constraint, vertexai.allowedModels, that governs which model actions are allowed at all, and it does something quiet but useful: when you write an allow-list, you’re recording which deployment path each model runs on, because the action suffix says it. :predict is the managed API you gate but don’t run; :deploy is an endpoint you stand up and own. The model IDs below are illustrative and current as of this writing—the catalog moves; the shape doesn’t:

1
name: organizations/ORGANIZATION_ID/policies/vertexai.allowedModels
2
spec:
3
  rules:
4
    - values:
5
        allowedValues:
6
          - publishers/google/models/gemini-3-pro:predict # first-party, managed API
7
          - publishers/anthropic/models/claude-opus-4-5:predict # partner, managed API only
8
          - publishers/google/models/gemma-3-27b:deploy # open model, self-deployed into your VPC

Read the suffix on each line as the record of how that model’s data path runs. A model not on the list can’t be called; a model on it carries, in the suffix, the tier you chose for it. Part 3 is the full runbook for these constraints; the point here is only that the allow-list is where “which tier” stops being tribal knowledge and becomes enforced policy.

The People Using the Approved Tools

And here is the part that should change how you think about the fix: in almost every one of these cases, the developer did nothing wrong on purpose. They used a model the organization approved, through a tool the organization gave them, to answer a normal question. They may have no idea that a server-side capability just carried context across a boundary their compliance team cares about—or that in a regulated context it could put a policy or a regulation at risk. You cannot govern this with a memo telling people to be careful, because being careful was never the failure. The people using the approved tools are acting in good faith, and keeping them safe—not just the data—is the job. That takes a control that sits above the individual developer and the individual request, defaulted to safe. Which is exactly what the platform gives you.

On the builds I’ve worked, this is the difference that holds up in practice: capabilities locked off by default and enabled deliberately, PII handled through DLP redaction and encrypted tables rather than a developer’s good intentions. The control sits above the person, so a good-faith mistake can’t become an incident.

Better Together, Governed Apart

None of this is an argument for one model over another. Say that plainly, because the multi-model conversation gets tribal fast, and tribalism is a bad substitute for architecture. A mature estate usually runs more than one—for example, both Gemini and Claude: Gemini where keeping the search path inside the already-accepted Google trust boundary and getting knowable provenance matter, a partner model like Claude where its particular strengths matter, and often both in the same system. Gemini and Claude are the pair I’ll use throughout the series, but nothing here is specific to them; the same seams apply to any first-party or partner model you can enable on the platform, the ones available today and the ones that land next quarter. That is the “better together” half—each model doing what it’s best at.

The “governed apart” half is the discipline that makes “better together” safe: you control the seams. Every server-side capability is a decision on record, made per capability and per model, rather than a side effect of granting access. The two halves are one posture.

You don’t earn the freedom to say yes to more models until you can govern their capabilities separately.

Here is the boundary picture the rest of the series builds on.

graph LR
  subgraph estate["Your Google Cloud Estate"]
    app["Application / Agent"]
  end

  subgraph accepted["Trust Boundary You Already Accepted"]
    gem["Gemini base model"]
    claude["Claude base model"]
  end

  subgraph capability["Capability Trust Boundaries — Each a Separate Decision"]
    gsearch["Grounding with Google Search<br/>30-day store, no opt-out, Google end-to-end"]
    csearch["Claude web search<br/>third-party provider; covered by BAA, but Web Fetch and MCP connectors are not"]
  end

  app --> gem
  app --> claude
  gem -. "deliberate grant" .-> gsearch
  claude -. "deliberate grant" .-> csearch

The base models sit inside a trust boundary you signed up for when you chose the platform. The server-side capabilities—the two nodes in the bottom group—reach past that boundary, each on its own terms. The dotted edges are the decisions. Governed growth means every one of those dotted edges is a choice you made on purpose, not a default you inherited.

The Part That Makes This Possible: Default-Deny

If the story stopped at “read the terms per capability,” it would be a warning, not a strategy. What turns it into a strategy is that Google Cloud gives you a real, enforceable place to make each of these decisions—and, crucially, it defaults to the safe answer.

Model access on the platform is governed by Organization Policy, not by a per-request flag and not by hope. Two constraints do the work: allowedModels gates which model actions are permitted, and allowedPartnerModelFeatures gates the partner features—web_search and structured_outputs. Both apply at the organization, folder, or project level, to every principal, and explicit deny wins.

The load-bearing default is this: for any project that belongs to an organization, the partner features are denied by default. Web search for a partner model is off until a policy explicitly turns it on. That is least privilege, applied to a model’s server-side capabilities—the capability arrives switched off, and a human has to make a deliberate decision to switch it on. The platform’s default is exactly the posture this series argues for. You have to opt into exposure, not remember to opt out of it.

That single default is why “governed apart” is achievable and not just aspirational. The seam has a switch, the switch has an owner, and the switch starts in the safe position.

Two honest caveats keep this from being a bumper sticker. First, that default-deny governs partner features—Claude, and the other partner models you can enable in Model Garden, under one consistent org-policy surface. Google’s own Grounding with Google Search is a first-party Gemini capability, and allowedPartnerModelFeatures does not reach it—so the honest answer to “can I just deny it by org policy the way I deny partner web search?” is no, not with that constraint. You govern it a different way: you decide whether to enable the grounding tool at all, you can choose Web Grounding for Enterprise when you need zero retention, and VPC Service Controls can block the search path at the network boundary. “Read the terms per capability” applies to first-party capabilities too, not only partner ones. Second, allowedPartnerModelFeatures is not the only seam: VPC Service Controls blocks the partner web-search tool at the network boundary, and request logging is its own toggle. The point is not that one switch solves it—it’s that the switches exist, at the organization boundary, defaulted safe.

That matters most where the cost of getting it wrong is highest. In a regulated environment—PHI under a BAA, data-residency obligations, an audit you have to pass—the difference between “we approved the model” and “we approved the model’s web search” is the difference between a clean audit story and an incident. This is the part to think through before you grant, not after: one place to decide, per capability, across every partner model, with the answer defaulted to no.

What’s Coming in This Series

This post set the frame. It did not deliver the whole argument—it set up the three pieces that do. Governed Growth runs in four parts, plus a standalone companion for the developer who wants to build the thing rather than govern it.

1. Part 1: Better Together, Governed Apart (you are here) — the frame: a capability’s trust boundary is a separate decision from the model’s, and Google Cloud is built to let you make it deliberately.
2. Part 2: The 30-Day Retention You Didn’t Opt Into — the central finding made concrete: what actually happens to your data when each model’s server-side search fires, and where the documented line sits.
3. Part 3: Default-Deny for Model Capabilities — the operator’s how-to: which org-policy toggles, at which scope, via gcloud and Terraform, to turn these decisions into enforced, auditable policy.
4. Part 4: Multi-Model, Governed, and Boring — the mature end-state, where every capability’s trust boundary is a decision on record and saying yes to more teams is safe by construction.

And the companion, for builders:

• Building gemini-search-mcp: Grounding, Citations, and Choosing a Gemini Model — the same subject from the implementer’s chair: a real grounding server, how citation extraction works against the Gemini API, and a head-to-head model evaluation.

Make the List Before You Make the Grant

You can run this Monday morning, at your desk, before you read Part 2—an hour with a spreadsheet, not a project. Three moves, in order.

1. Audit every capability you’ve granted. Open a sheet. List every server-side capability your teams can currently reach—web search first, then code execution, structured outputs, grounding, MCP connectors, whatever your models expose—one row each. Then give the sheet a column for each axis of the guarantee, and fill in every row:

• Capability — the server-side feature, named specifically (e.g. Grounding with Google Search, not just “search”).
• Vendor and model — whose capability it is: first-party Gemini, partner Claude, or another partner model you enabled.
• Region — where the capability’s data path actually runs, which is not always where the base model runs.
• Retention — how long the provider keeps prompts and output, and whether you can disable it.
• Training use — whether your data can train a model. On Google Cloud, the §17 answer is no; write down the answer for every other path too.
• Service maturity — GA, or Preview/Beta, because your contract may not cover a preview feature.
• Governing instrument — the DPA, BAA, or org policy that actually binds it.

Most estates have never written this down, and filling one row is usually the moment the one-grant-two-boundaries trap becomes obvious: the model’s terms sit in the vendor column, but the retention, region, and instrument columns are about the capability, and they don’t match.

2. Check the one default you probably assume. For your partner models on Google Cloud, confirm whether allowedPartnerModelFeatures is set the way you think it is. If your projects belong to an organization, partner web search is denied until a policy turns it on—so verify a policy hasn’t quietly turned it on everywhere, and that the one that did has a name attached.

3. Take the sheet to whoever owns compliance. For each row, ask one question: did we decide to turn this on, or did it arrive? The answer tells you how much of your exposure is chosen and how much is inherited—and the rows with a blank cell are the ones to close first.

That is the first act of governed growth: refusing to let a single “yes” answer a whole list of questions at once. Do it now, while the list is short, and the rest of this series is a matter of tightening what you already understand rather than discovering it after an audit does.

This is Part 1 of the Governed Growth series. Facts on org-policy behavior, retention terms, and contractual scope are drawn from Google Cloud’s and Anthropic’s own terms and from the primary text of the privacy and sector regulations named above.