MCP for Healthcare Agencies: Client Data Boundaries

An agency running clinic accounts through MCP keeps client data apart with one credential and one conversation per clinic, only the AI tools each clinic approved in writing, and access that either side can revoke. Curve builds that boundary into its own AI access by binding every MCP token it issues to a single clinic organization that the clinic itself switches on. The catch most agencies miss is the BAA chain. Your BAA with the clinic does not reach your AI subscription, and the signed BAA included on every Curve plan covers Curve's processing, not the assistant you connect to it.

One AI client, many covered entities

Before MCP, agency tooling kept clients apart almost by accident: separate ad accounts, dashboard logins and exports. An MCP-connected assistant removes that friction on purpose. One chat window, several connectors, and every account the underlying login can reach.

What the common servers reach:

• Google Ads. Google's official server is strictly read-only, and its search tool runs GAQL against any account the authenticated user can access. Its setup takes a GOOGLE_ADS_LOGIN_CUSTOMER_ID for access through a manager account, and Google describes a manager account as "a single sign in to access all client Google Ads accounts." Point the server at the agency MCC and every client under it is one prompt away.
• GoHighLevel. HighLevel lets an agency connect "one sub-account, several specific locations, or all available sub-accounts under your agency." Each request runs against one sub-account, but HighLevel's docs tell agencies to "Switch freely in the same chat," and their own example asks the assistant to list contacts tagged "vip-2026" in one clinic "then compare the count with Uptown Med Spa." Cross-client comparison is a documented feature, not a misuse. The operation catalog covers contacts, conversations, appointments and notes, which in a clinic sub-account is patient data.
• Meta. The Meta Ads MCP server signs in through Facebook Login for Business, so it reaches the ad accounts that business user can see, which for an agency user can mean every client. Its write tools can create campaigns and, once a user confirms, activate spend.

The ad account is no longer the boundary that matters. The conversation is. Every tool result becomes model context, and model context does not remember which clinic it came from.

How client data crosses over in one conversation

Cross-client leakage rarely looks like a breach. It looks like a slightly wrong report. Four failure modes:

1. Context carryover. You pull Clinic A's weekly numbers, then ask for Clinic B's client note in the same thread. A's campaign names and figures are still in context and can surface in B's draft. The numbers look plausible, so nobody catches it.
2. Wrong-account resolution. Two clinics both run a campaign called "Botox Search." The assistant picks an account by inference, not by instruction, and HighLevel resolves sub-accounts by the name you type, asking only when the name is ambiguous. With a read-only server you get a wrong report. With the Meta, TikTok or Amazon Ads servers, which can create or change campaigns, you get a change in the wrong client's account.
3. Persistent stores. Projects, uploaded files, saved chats and memory features outlive the session. An "All clients" project becomes one repository holding several covered entities' data, retained under the agency's workspace settings rather than any clinic's instructions.
4. Chained connectors. HighLevel's current server lists "read and send messages" in its operation catalog, and an agency connection can include several sub-accounts. A model holding Clinic A's contact data, on a connection where messaging is granted and Clinic B is also included, is one bad instruction away from a disclosure. Invariant Labs has also shown that a malicious server can "poison tool descriptions to exfiltrate data accessible through other trusted servers."

The controls are boring:

• One conversation per client per task, opened by naming the client and its account IDs.
• No cross-client projects, and memory switched off on the accounts staff use for client work.
• No write-capable tools in reporting sessions, and a person approving each tool call. The MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations."
• No client-versus-client comparisons inside the AI client. Build benchmarks from figures already aggregated and approved.

For a weekly routine built on these rules, see the PHI-safe weekly agency reporting workflow.

Whose BAA covers what when the agency is the business associate

HIPAA defines a business associate as a person who, on behalf of a covered entity, "creates, receives, maintains, or transmits protected health information" (45 CFR 160.103). An agency that holds a clinic's CRM contacts, lead form answers or customer lists fits that definition. The same section reaches one hop further: a subcontractor handling PHI on the business associate's behalf is itself a business associate.

So the moment PHI goes into your AI vendor, that vendor is your subcontractor. Your BAA with the clinic obliges you to "ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions" (164.504(e)(2)(ii)(D)). Walk the chain one hop at a time:

• Clinic to agency. Your BAA with each clinic. If it was signed before November 2024, it predates MCP itself.
• Agency to AI vendor. Anthropic enables HIPAA readiness only on Claude Enterprise, not Team, Pro or Max. Even on Enterprise, data sent to third parties through MCP connectors is outside Anthropic's BAA. OpenAI offers a ChatGPT BAA only to sales-managed Enterprise or Edu accounts, not ChatGPT Business, and says custom MCP connectors are not verified by OpenAI. An eligible agency building its own reporting tools on the Claude API can accept a BAA in the Console, but the API's MCP connector is not HIPAA-eligible.
• Ad platforms behind the servers. Google does not offer a BAA for Google Analytics, Google Ads is not on Google Cloud's list of BAA-covered products, and Meta's Business Tools Terms forbid sending health information. Whatever these servers return must already be PHI-free, because those platforms never agreed to hold PHI.
• Tracking vendor. Curve's BAA covers the data Curve processes, not the AI client a clinic chooses to connect to its MCP server, which is not a Curve subprocessor and needs its own coverage decision.

If your staff use Claude on a Team or Pro plan, no BAA is available for that workspace, so the only safe input is data that is not PHI. "We will be careful what we paste" is a policy, not a control. More on what you sign: agency BAA obligations.

Per-client tokens and revocation

A shared agency credential undoes every other boundary. When five people paste the same token into their MCP config, every logged call reads as "the agency," and revoking one person revokes everyone. Four rules fix it:

1. One credential per client, per person. The audit trail should answer "who pulled Clinic B's data on Tuesday" without a meeting.
2. Scope it to the one client. For Google Ads, a Google identity with access to that client's account instead of the agency MCC. Confirm it: list_accessible_customers should return exactly one customer ID. For HighLevel, select a single sub-account when you authorize, or pair the older server's Private Integration Token with that one location's locationId. For Meta, sign in with a business user assigned only that client's ad account, then set the agent to read-only on it. The login decides which accounts the agent can see; the agent setting decides what it may do there.
3. Expiry you do not control. Google, Meta and HighLevel set their own token lifetimes, so offboarding (rule 4) is the control the agency owns.
4. A revocation runbook per client. When a clinic or staff member leaves, remove access at each platform (Google account user, Meta business user or agent, HighLevel integration), delete local MCP configs, and delete that client's projects and conversations.

Revocation stops future reads. It does not recall tool results already sent to the model vendor, which is why what goes in matters more than the kill switch. Token lifetimes and scopes are covered in MCP access tokens for health data, and HighLevel specifics in locking down GoHighLevel contact data.

What each clinic should approve in writing

Treat AI access as a signed schedule to your BAA or services agreement, one per clinic. It should fit on a page and name:

• AI clients and plans. For example "Claude Enterprise, HIPAA readiness enabled," not "AI tools."
• People. Who at the agency may use them for this client, by name or role.
• Servers and accounts. Each MCP server and the exact accounts it may reach, by customer ID, ad account ID or sub-account ID.
• Read or write. Whether the assistant may create, edit or activate campaigns, and which named person approves any change that spends money.
• Data classes. Allowed: aggregate campaign and site KPIs by week. Never: contact records, conversations, appointment notes, form answers, customer lists. This is HIPAA's minimum necessary standard (164.502(b)) applied to what the assistant may read.
• Retention and return. Where chat histories live, for how long, and their deletion at contract end, matching the BAA duty to "return or destroy" PHI at termination.
• Incident reporting. If PHI from one clinic lands in another clinic's conversation or deliverable, that is a use or disclosure the contract did not provide for, and the BAA requires you to report it to the clinic whose data moved (164.504(e)(2)(ii)(C)).
• Revocation and review. Who can pull access, how quickly you will confirm it, and a re-approval date each quarter.

Keep the signed schedules and access lists for six years, the retention period HIPAA sets for required documentation (164.316(b)(2)(i)). For the connector sign-off itself, use the compliance officer checklist for MCP connectors.

How Curve scopes AI access per organization

Every clinic is its own organization in the dashboard, and agencies work across them through Managed Accounts, which gives partner users Full Access or Read Only per client. Curve MCP applies a stricter rule.

• One token, one organization. Every token is bound to a single organization, and the organization comes from the credential, never from anything the model types. There is no account parameter for the assistant to guess wrong or be talked into changing.
• The clinic holds the key. MCP access is off by default for each user. Only the clinic's primary user can switch it on for the organization, issuing a token needs a confirmation code, admins are notified, and tokens expire.
• The agency holds the brake. In a managed organization, a partner admin with Full Access can revoke a member's AI access or switch MCP off, but cannot grant access or turn it on. Agency staff are not issued MCP tokens into client organizations, because the agency's AI tool is the agency's vendor and the clinic's approval covers the clinic's own staff.
• Only small answers travel. The tools are read-only and work from Claude, ChatGPT, Cursor or any other MCP-capable client. They return organization-level KPIs for completed weeks and reconcile your server-side campaigns: each campaign's platform-reported spend, clicks and impressions next to the conversions Curve's server-side tracking recorded, with cost per conversion by week. One link opens the full sent, accepted and matched view inside Curve. Small groups are withheld, counts are rounded, inputs are fixed choices, and a campaign or goal name appears only if the organization approved it.
• Fail closed, log everything. A final guard blocks any answer that looks like it contains an email, phone number, ID, date or name. Every call is logged, and no data is returned if the log cannot be written.

Where a client has Curve Analyst turned on, agency staff use that in-app assistant inside the client's account. It runs under the BAA that comes with every Curve plan, so the client's data never passes through the agency's own AI subscription. See what Curve AI Analyst does and the marketing agencies page.

For other MCP servers, copy the shape rather than the product. Bind each credential to one client, let the covered entity grant access, let the agency revoke it, and return aggregates instead of records.

Frequently asked questions

Is a healthcare marketing agency a business associate?

If it creates, receives, maintains or transmits PHI on a clinic's behalf, yes. Managing a clinic's CRM, lead routing or customer list uploads usually puts an agency there. Settle it in the BAA rather than by assumption.

Can one agency Claude or ChatGPT account serve every client?

Technically, yes. Whether it should depends on each clinic's written approval and on whether the plan can carry a BAA at all, which rules out Claude Team and ChatGPT Business for anything that could be PHI. Those plans can still carry work that holds no patient data, such as aggregate campaign spend and clicks. Even on an eligible plan, keep separate projects and conversations per client.

Does the clinic's BAA with the agency cover the agency's AI vendor?

No. The agency needs its own subcontractor agreement with any vendor that handles the PHI, and on Claude Enterprise even that stops at connectors that send data to third parties.

Is connecting our Google Ads manager account to the MCP server a problem?

The official server is read-only, so it cannot change bids or spend. The problem is reach: one login puts every client account into one conversation. Use a per-client identity instead, and keep PHI out of the accounts, since Google Ads is not a BAA-covered product.

What happens to client data in chat history after we revoke a token?

It stays where it is, under the AI vendor's retention terms and your workspace settings. Delete the client's projects and conversations in the same runbook, and record it.

What do we do when one clinic's data shows up in another clinic's report?

Hold the deliverable if it has not gone out. If what moved could be PHI, report it to the clinic whose data moved, because the BAA treats that as a use or disclosure the contract did not provide for. Delete the conversation and any drafts that hold it, and record what moved, where and when, so the clinic can decide whether it is a reportable breach.

Where to start

This week:

1. Inventory every MCP connection your staff run: person, client, server, credential, AI plan. Anything connected through the MCC or "all sub-accounts" goes to the top of the list.
2. Split shared credentials and shared projects into per-client ones, and delete the cross-client history you can.
3. Send each clinic its one-page AI schedule, and do not reconnect until it is signed.
4. Check what feeds the ad accounts: run each client site through the free compliance scanner.

To see per-organization MCP access and Managed Accounts working together, book a Curve demo. We will walk through how a clinic turns AI access on, what the assistant returns, and how your team revokes it.

Reviewed September 2026. Sources include 45 CFR 160.103, 164.502, 164.504 and 164.316, the MCP specification, and published documentation from Anthropic, OpenAI, Google, Meta and HighLevel.