Is the Google Ads MCP HIPAA Compliant? A Clinic Verdict

No, the Google Ads MCP server is not HIPAA compliant on its own: it is a read-only connector that pipes your Google Ads account into an AI assistant, and Google does not sign a BAA for Google Ads. Whether a clinic can use it safely comes down to two things, what data sits in the account and which AI client receives the answers. Curve, which signs a BAA on every plan, handles the first with server-side tracking built to keep PHI out of Google Ads and narrows the second: Curve MCP gives an AI assistant rounded weekly aggregates instead of raw account rows.

The verdict, in three questions

HIPAA does not certify software, so the real test is whether PHI can travel through the connector to someone who has not signed a BAA.

• Does Google sign a BAA for Google Ads? No. Google's HIPAA BAA covers a published list of Google Cloud products, and no advertising product is on it.
• Is there PHI in your account? Possibly, in places most teams never check: lead form submissions, click-level records, list names and conversion action names.
• Does the AI client have a BAA that covers this path? Not by default. MCP servers get connected from whatever plan the marketer already has, and Claude's Free, Pro, Max and Team plans and ChatGPT Business carry no BAA at all.

If the account holds no PHI and the lead and click-level resources are fenced off as described below, the connector is a reasonable productivity tool. If nobody has looked, connecting it copies whatever is there to a second vendor.

What Google's official Google Ads MCP server exposes

Google released the server in October 2025 and publishes it as open source (Apache 2.0). Google does not host it: you run it yourself, locally over stdio or as your own web service such as Cloud Run, with a developer token that has at least Explorer access.

This verdict covers Google's official server. A third-party server, especially a hosted one, puts another company between your ad account and the AI and holds your Google Ads credential, so check who runs it, whether it can write and what it stores.

Google's server has three tools:

• list_accessible_customers returns the customer IDs the signed-in Google user can access directly. Set GOOGLE_ADS_LOGIN_CUSTOMER_ID to an agency manager account and search can query every client account under it.
• search runs a Google Ads Query Language (GAQL) query. The model picks the resource, fields, filters and row limit; the server assembles the query and returns the rows.
• get_resource_metadata describes the fields on a resource such as campaign.

Google's documentation is explicit: "This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets." That makes it the only read-only server among the official ad-platform MCPs: Meta's, TikTok's and Amazon's can create or change campaigns.

Read-only protects campaigns, not data, because reading is how information leaves the account. The repository says so: "The MCP Server will expose your data to the Agent or LLM that you connect to it."

Three details matter in a compliance review:

• The reach is the whole account. In the September 2026 code, the search tool's description lists 181 queryable resources, including lead_form_submission_data, click_view, search_term_view and user_list. The list is a hint, not a fence: tools_config.yaml can switch off groups of tools, but nothing blocks a single resource.
• Read-only lives in the code, not the credential. The Google Ads API has one OAuth scope, https://www.googleapis.com/auth/adwords, and "uses the same scopes for readonly versus readwrite operations." A refresh token copied from a laptop's google-ads.yaml can change the account; only the Google Ads user role behind it limits that.
• The audit trail is a log line. The server logs each GAQL query and keeps no record of who asked or what came back.

Where PHI can sit in a Google Ads account

Most of what the server returns is spend, clicks, impressions and conversions, which describe campaigns, not people. The risk concentrates in five places, all readable through search.

Lead form submissions

The lead_form_submission_data resource returns the submitted fields (such as full name, email, phone number and zip code), any custom questions with their answers, the GCLID, the submission time, and the campaign and ad group. Google keeps leads for 60 days, and the CSV download covers only the last 30, so the API reaches older leads than the interface shows.

A named person asking about a specific treatment at your clinic is a record to treat as PHI, and "show me last week's leads" is a one-line prompt. Webhook delivery to your CRM does not remove the copy Google Ads keeps, so if you run lead forms, assume this resource holds names and fence it off. Our guide to PHI-safe lead form routing covers the form side.

Search terms

search_term_view.search_term returns the queries that triggered your ads. Google already omits terms without enough query activity "in order to keep with our standards on data privacy", so one patient's unusual query should not surface.

Customer Match lists

GAQL cannot return the members of a Customer Match list, but it does return user_list.name, the description and estimated sizes. A list named "Sleep apnea patients 2025" says a patient roster went to Google, which is the real problem: Google treats health as a sensitive interest category and does not allow Customer Match when promoting health content. Our customer list upload audit covers the cleanup.

Offline conversion uploads

GAQL has no resource that reads uploaded conversions back row by row. It does return conversion action names, conversion counts and values by campaign, keyword and date, and upload summaries. A conversion action called "Suboxone induction completed" with one conversion on one keyword on one day points at someone your front desk can name.

Renaming conversion actions fixes most of this, as the offline conversion import guide explains. Curve's neutral event aliases fix it at the source: Google receives a neutral conversion name instead of the service line, only fields you map for that destination are sent, and identifiers are SHA-256 hashed.

Click-level GCLIDs

click_view returns one row per click: the GCLID, the keyword, city-level location fields and the date, for any single day in the last 90. A GCLID is just a code until your CRM stores it against a patient. Then a row pairing it with a city and a date carries three identifiers that HIPAA's Safe Harbor method tells you to strip: a unique code, geography below state level and a date.

No tracking setup removes these rows, because Google records every click. If your CRM keeps GCLIDs for offline conversion import, fence click_view in every configuration.

Which AI client sees the answers

Every row the server returns lands in the model's context and goes to the AI vendor as soon as the model reads it, even when the server runs on your laptop. So the verdict also depends on the client:

• Claude. HIPAA readiness is Enterprise-only, and even there Anthropic says data sent to third parties through MCP connectors is not covered by its BAA. Run locally over stdio, Google's server plugs into Claude Code or the Claude desktop app. Anthropic's pages conflict on Claude Code (its BAA article covers it only with zero data retention, while its API data-retention page says Claude Code "is not covered under HIPAA readiness"), and we found no statement covering the desktop app (more in our Claude BAA breakdown).
• ChatGPT. OpenAI limits ChatGPT BAAs to sales-managed enterprise offerings and describes custom MCP connectors as not verified by OpenAI. ChatGPT connects only to remote HTTPS MCP servers, so using it means deploying Google's server as an internet-reachable endpoint that holds your Google Ads credential. See is ChatGPT HIPAA compliant.
• Anything else. If you cannot point to a signed BAA that names the product and covers the MCP path, treat the client as outside your HIPAA boundary.

Search terms and form answers are also text written by outsiders, the raw material of prompt injection (OWASP LLM01). Our piece on prompt injection in ad data traces how that reaches the assistant's other tools.

How to configure the Google Ads MCP safely

For keyword and search term work, this is the configuration we would sign off on (install steps are in our Claude and Google Ads setup playbook).

1. Clean the account first. Retire lead forms that ask health questions (submissions already collected stay readable through the API for up to 60 days, so the step 3 fence is the only control until they age out), give conversion actions neutral names, and delete any list built from a diagnosis or treatment.
2. Authenticate as a dedicated Google user with Read-only access to only the accounts the work needs. Never connect through an agency manager account: with GOOGLE_ADS_LOGIN_CUSTOMER_ID set to the manager, search can reach every client under it.
3. Fence the resources in code. You run the server, so allowlist the search tool's resource argument (the server builds the query from it) to campaign, ad group, keyword and search term views, rejecting lead_form_submission_data, click_view and user_list before any query is sent. The fence cannot hide conversion action names, which any campaign or keyword query can segment by date, so step 1's renaming is the only fix there.
4. Choose the client on purpose. Use one covered by a BAA that names this path, or declare the connection PHI-free and enforce steps 1 to 3 so that it is. The HIPAA-safe MCP server checklist is the full test.
5. Keep a human on every call. Leave approval prompts on for search, as the MCP specification says there "SHOULD always be a human in the loop."
6. Keep the logs. Route the server's log output to storage you keep; it records each query but not the rows returned, so sizing a slip means re-running the logged query while the data is still inside Google's 60-day lead or 90-day click window.

How Curve answers campaign questions without patient rows

Curve's script replaces the Google tag, and conversions reach Google through Enhanced Conversions and the Data Manager API with nothing forwarded unless you map it. Offline conversions from your CRM or EHR match on click ID, so the upload never needs chart data.

Curve MCP then gives an AI assistant campaign answers without the ad account, in any MCP-capable client or agent: Claude (desktop, web or Claude Code), ChatGPT, Cursor and others. It returns:

• Organization-level figures only: visitors, sessions, goal completions, funnel steps, and a reconciliation of your server-side campaigns that puts each campaign's spend, clicks and impressions as Google reports them next to the last-touch conversions Curve's server-side tracking recorded, with cost per conversion.
• One link that opens the full sent, accepted and matched view inside Curve.
• Completed weeks only, over fixed look-backs of 1, 4, 13 or 52 weeks, as window totals plus a week-by-week series.
• Rounded counts of people, with small groups withheld and any figure that could be subtracted to expose a small group suppressed (the method is in de-identified MCP answers).
• A campaign or goal name only when the clinic has approved it; otherwise it reads "(label hidden)".

It returns no search terms, lead form answers, click IDs or visitor-set strings such as UTMs, page paths and referrers. Inputs are fixed choices, not free text, so there is no query language to aim at a sensitive table. A final guard blocks any answer containing something shaped like an email, phone number, ID, date or name, and blocks everything if it cannot run. The service runs under a database role that cannot read contact details, form answers or journeys.

Access is locked down as well:

• Read-only tools and scoped tokens that expire, with a confirmation code and an admin notice for each new token.
• A per-user switch that is off by default, and organization enablement that only the clinic's primary user can grant.
• A log of every call, with no data returned if the log cannot be written.
• A single-use link into Curve Analyst for person-level questions, which requires a login and carries no data.

One boundary: the BAA covers Curve, not the AI vendor you connect, which is why the answers are built as rounded weekly aggregates.

When to use Curve MCP instead

• Use Curve MCP for "which campaigns drove booked consultations over the last four weeks" and "what did each conversion cost, week by week".
• Use Google's server on a cleaned, fenced account for search term mining, negative keywords, match type reviews and ad copy audits. Curve MCP stops at campaign level.
• Use neither for questions about a person, such as which lead came from which ad; those belong inside a system under a BAA.

The trade-offs: figures run up to a week behind the dashboard, since the current week is never included, and there is no revenue, ROAS, device, channel or region breakdown.

Frequently asked questions

Can the Google Ads MCP change campaigns or spend money?

No. Google documents it as strictly read-only, but the credential behind it can write, so sign in as a Google Ads user with Read-only access.

Does hosting the server on Google Cloud bring it under a BAA?

Not for the ad data. Google Ads is not on the BAA's covered-product list wherever the connector runs, and the AI client still needs its own coverage.

Are Google Ads search terms PHI?

Usually not on their own, because Google withholds low-volume terms for privacy. They become risky in combination: sliced by day for a small location, read next to click-level data, or matched to your CRM.

Is it safe if we only ask about keywords?

Safer, not safe. You write the question, but the model writes the query, and "which keywords produce real patients" can send it to lead form or click data if those resources are reachable. The allowlist turns intent into a guarantee.

Can we run Curve MCP and the Google Ads MCP in the same session?

You can, but keep them apart. Do search term work in a session with only Google's server, and campaign questions in another with only Curve MCP. Search terms are text typed by strangers, and a shared context lets that text steer the model's next calls against either server.

Where to start

Start with the account, not the connector. Check it for lead form submissions, health-named lists and revealing conversion action names, then run the free compliance scanner to see what your site's tags send to Google today. If PHI turns up, fix the tracking before any AI touches it.

If you want AI answers about campaigns without handing an assistant your ad account, book a Curve demo to see server-side tracking that keeps Google Ads clean, under a BAA on every plan, and Curve MCP answering weekly performance questions from rounded aggregates.

Reviewed September 2026. Sources: Google's Google Ads MCP documentation and repository, the Google Ads API reference, Google Ads Help and policy pages, Google Cloud's HIPAA page, and Anthropic and OpenAI BAA documentation.