Skip to main content
Guide

MCP vs Ad Platform APIs: What Changes for PHI Risk

With MCP a model, not a developer, picks the ad data query at runtime, so PHI risk shifts to open-ended reads, the model vendor hop, injection and audit gaps.

11 min read

MCP changes PHI risk because a language model, not a developer, now writes the ad data query at runtime, and every result it reads goes into a prompt sent to the model vendor. The HIPAA rules do not change, and neither does the fact that Google and Meta sign no BAA for their advertising products. What changes is where control lives. Curve builds its MCP server to put that control back: fixed inputs, aggregate-only answers and a logged record of every call, with a signed BAA on every plan covering its own side of the flow.

Fixed queries vs runtime choices: the real difference

In a classic integration, a developer writes the query once. A nightly job that pulls Google Ads spend into a dashboard might run SELECT campaign.name, metrics.cost_micros, metrics.clicks, metrics.conversions FROM campaign WHERE segments.date DURING LAST_30_DAYS and nothing else, for years.

MCP inverts that. Google's official Ads MCP server exposes three tools: list_accessible_customers, search and get_resource_metadata. The search tool runs whatever GAQL query the model composes, and get_resource_metadata lets the model discover which fields exist before it asks.

Side by side:

  • Who writes the query. API: a developer, once, in reviewed code. MCP: the model, per question, unreviewed.
  • What can be read. API: the fields in the code. MCP: anything the tool accepts, in every account the credential sees.
  • Where results land. API: a table you chose. MCP: the model's context, sent to the model vendor.
  • What text in the data can do. API: nothing, it sits in a column. MCP: steer the model's next tool call.
  • The record. API: the code plus a job log. MCP: per-call logs, only if someone keeps them.
  • Writes. API: each mutation written on purpose. MCP: on Meta, TikTok and Amazon, write tools on the model's menu.

Other servers carry bigger menus. TikTok describes a mode with about 400 tools, and HighLevel's current server routes everything through one generic execute_operation tool, limited by the OAuth scopes you granted. Server-by-server verdicts start with whether the Google Ads MCP is HIPAA compliant.

The friction you lost was a control

API work used to require a developer token, credentials held by engineering, and a deploy. That friction was never a compliance control, but it worked as one: nothing new left an ad account until someone technical looked.

Meta says its connectors need "no developer credentials, API setup, or coding," and TikTok says much the same, so a media buyer can wire an ad account into an AI assistant in minutes. Google's server keeps some friction: it still needs a developer token with Explorer access or higher, and someone to host it. The first person to review that data flow may be the one reading the incident report.

What changes for PHI risk

1. The query surface becomes open-ended

HIPAA's minimum necessary standard (45 CFR 164.502(b)) asks for "reasonable efforts to limit protected health information to the minimum necessary." A fixed query meets that at design time by choosing fields. With MCP, the surface is everything GAQL can reach in every account the credential sees.

In a health account, that includes search_term_view, the raw terms people typed when your ad showed. Google aggregates them by term at the ad group level with no user attached, so a condition name alone identifies no one. The PHI case is the term that contains a name, phone number or email, which the model then reads verbatim.

It also includes the names and descriptions of your audience lists (user_list). A list named for its source ("Existing patients, weight loss") tells the reader what everyone on it has in common, and Google's Customer Match policy restricts uploading health information at all. And list_accessible_customers returns every customer ID the login can access, so an agency login puts every client one question away.

2. Every result reaches a model vendor

An MCP call moves ad data into a model's context window, and the AI client sends that context to the model vendor on the next turn.

Among Claude's apps, HIPAA readiness is Enterprise-only, not Team, Pro or Max. Anthropic's BAA page lets HIPAA-ready organizations use connectors but says data sent to third parties through them is not covered, and on the Claude API the MCP connector feature is not HIPAA-eligible. OpenAI offers no BAA for ChatGPT Business, and its admin documentation describes custom MCP connectors as "not verified by OpenAI."

If a tool result can contain PHI, this hop needs a covered path, and a Team or Pro seat is not one. The hop also runs outward. The model writes the tool arguments, so a patient name pasted into the chat, or a record pulled from a CRM server, can ride along in a query sent to Google or Meta, and neither signs a BAA for its ad products.

3. Text in the result can steer the model

In an MCP session the model reads every string in a result, then decides what to do next. OWASP calls this indirect prompt injection (LLM01): instructions arriving when a model "accepts input from external sources."

Ad data is full of text other people wrote: search terms from anyone who triggers your ad, other advertisers' ads from Meta's ads_library_search tool, and form answers and message threads from a CRM server. In 2025 Invariant Labs showed a public GitHub issue getting an agent to leak private repository data through GitHub's MCP server "even with fully trusted tools."

Tool descriptions are a second channel that APIs never had. Invariant also showed a malicious server can poison its descriptions to pull data from other trusted servers in the same session.

The exit route is whatever else is connected. If the same session holds a HighLevel server that can send messages (v1 exposes conversations_send-a-new-message), or Meta's custom audience tools, a steered model has an outbound path no fixed integration ever had. More in prompt injection in ad data.

4. The audit trail moves from code to call logs

With MCP, the only record of what the model asked for and what came back is the per-call log, if one exists. The MCP specification says clients SHOULD "log tool usage for audit purposes," a recommendation, not a requirement. A chat history is not an audit trail.

HIPAA's audit controls standard (45 CFR 164.312(b)) calls for mechanisms that "record and examine activity" in systems that contain or use ePHI. After an incident, only the arguments and output of each call, tied to a named user, show what the model saw. The fields worth keeping are in MCP audit logs for healthcare.

5. Writes become a model decision

MCP puts write tools on the model's menu. Meta's server can create campaigns, ads and creatives and create, update or delete custom audiences; it creates entities paused, and the client asks for confirmation before ads_activate_entity starts spend. Amazon's creates, updates and deletes campaigns and reaches billing data. Google's is the exception and calls itself "strictly read-only."

For PHI, the write that matters most is a custom audience built from a patient list, not a runaway budget. A list of who your patients are is PHI, and the platform receiving it signs no BAA.

What stays the same

On a read-only server, MCP is a new way to read ad data out. The exposure behind the pixel lawsuits came from what went in, and that part does not change: whatever your pixel, uploads and audience lists already sent is still there.

  • No BAA from the ad platforms. Meta and Google do not sign BAAs for their advertising products, with or without MCP.
  • The API and credential underneath. An MCP server still calls the platform's API under an OAuth grant, as an integration does. Google's Ads server uses the https://www.googleapis.com/auth/adwords scope, the scope Google's OAuth docs give for the Google Ads API, so its read-only promise lives in the server's code, not the token. Google's GA4 server asks for analytics.readonly instead.
  • Platform policy. Google still treats health as a sensitive interest category and bars advertiser-curated audiences, Customer Match included, for it. Meta's Business Tools Terms still forbid sending health information.
  • The law. Anyone outside your workforce who "creates, receives, maintains, or transmits" PHI on your behalf is still a business associate (45 CFR 160.103), and minimum necessary still applies.

The upstream fix is unchanged. Curve's server-side tracking layer forwards only the fields you explicitly map to each destination, hashes identifiers with SHA-256 to each platform's spec, and shows the platform a neutral event alias instead of the service line. Less sensitive data in Meta and Google means less for any MCP server to read back.

How to keep API-grade control with MCP

Each item names what the API gave you, then how to get it back. The full buyer's version is the HIPAA-safe MCP server checklist.

  1. The API wrote only on purpose. Enforce read-only outside the model. Use Google's read-only server where it fits, and treat the Google Ads token itself as read-write if it leaks. For Meta, set the agent to read-only per asset in Meta's own access controls.
  2. A service login saw one account. Scope the credential to one account. Use a login that sees only that account, never an agency manager login. HighLevel lets an agency pick one sub-account, several or all; pick one.
  3. A fixed field list. Narrow the query surface. Google's server is open source (Apache 2.0) and self-hosted, so an engineer can wrap search to allow named resources only and refuse search_term_view and user_list.
  4. A pipeline had one destination. Keep PHI sources and outbound tools in separate sessions. A CRM server that returns contact records should never share a context with a tool that can send, post or build an audience.
  5. Results landed in your own table. Cover the model hop or keep PHI out of it. Either the AI client runs under a BAA that covers the exact surface you use, or every tool result must be non-PHI by construction.
  6. A job log. Log arguments and outputs per call, per user. If the client cannot, put a logging proxy in front of the server, and keep a human approving any write, as the spec recommends.
  7. Code changed only through review. Pin what you approved. A server can change tool descriptions after approval (a rug pull), so OWASP recommends pinning tool definitions with cryptographic hashes.

How Curve MCP keeps the query space closed

The API-era control worth copying is the fixed query: a reviewed list of what can be asked. Curve MCP rebuilds that on the server side, so the model's options are enumerable again instead of open-ended GAQL.

  • Choices, not queries. Inputs are fixed options, not free text: last week or the last 4, 13 or 52 weeks, with no custom date ranges, filters or query language. The model picks from a menu the server defines, which is the MCP equivalent of a field list in reviewed code.
  • No visitor-set text. UTM values, page paths and referrers are never returned. That closes the obvious channel for an outsider to plant instructions in a result, the injection path described above.
  • No log, no answer. Every call is logged, and no data is returned if the log cannot be written. The record the API era kept in code and job logs exists for every call by construction, not by someone remembering to turn it on.
  • Reconciled campaigns. Each campaign's platform-reported spend, clicks and impressions sit next to the conversions Curve's server-side tracking recorded, with cost per conversion by completed week, and one link opens the full sent, accepted and matched view inside Curve.

It works with any client that can connect to an MCP server: Claude (desktop, web and Claude Code), ChatGPT, Cursor and other MCP-capable agents.

The rest of the design, from approved labels and small-group rules to token issuance and who can switch it on, is laid out in what Curve MCP returns and how it is locked down.

Curve MCP will not answer keyword, search-term or audience questions. For those you still need the platform's own server, with the controls above.

Frequently asked questions

Is an MCP server just a wrapper around the ad platform's API?

Mostly. Google's server runs GAQL through the Google Ads API under the same adwords scope a direct integration uses. MCP changes who writes the query and where the answer goes, not what the platform permits. Meta adds its own agent access levels on top.

If our BI dashboard already pulls this data by API, is MCP any riskier?

Only where it widens what is read or who receives it. The same fields going into the same warehouse add no new exposure. Fields the model picks, sent into a model vendor's context, do, and the dashboard's code review never covered them.

Should we keep the API integration and skip MCP for health accounts?

For scheduled reporting, often yes, because a fixed query is the tightest control there is. Use MCP for ad hoc questions, and only through a server whose inputs are as narrow as that query.

Can our team use Claude or ChatGPT with an ad platform MCP server?

Yes. Curve MCP connects to Claude, ChatGPT, Cursor and any other MCP-capable client. For results that are not PHI, HIPAA does not stand in the way. For anything that could be PHI, you need a BAA covering the exact surface, and for their chat apps Anthropic and OpenAI reserve it for enterprise or healthcare plans. Anthropic's BAA excludes data sent to third parties through connectors, and OpenAI calls custom MCP connectors "not verified by OpenAI." More in whether Claude is HIPAA compliant and whether ChatGPT is safe for marketing data.

Does Curve's BAA cover the AI assistant we connect to Curve MCP?

No. Curve's BAA covers Curve's handling of your data; the AI client and model vendor are yours to choose and contract. That is why the server returns rounded weekly aggregates with small groups withheld, built to describe campaigns, not people.

Where to start

Start with an inventory: every MCP connector your team has added to an AI client, the accounts each credential sees, and the tools that can write. Then check what your site sends to the ad platforms, since that is what any server can read back; the free compliance scanner shows it.

If you want campaign answers in an AI client without handing the model a query language, book a demo of Curve MCP and bring your compliance officer. The tracking layer underneath it, with a BAA on every plan, starts at curvecompliance.com.

Reviewed September 2026. Vendor tool lists and BAA terms reflect published documentation as of that month.

Stay Compliant. Scale Confidently.

Join healthcare innovators who trust Curve for HIPAA-compliant ad tracking.Launch in hours, not months. Your growth stack, now HIPAA-safe.

Book a free tracking audit