Approving an MCP Connector: A Compliance Officer Checklist

A compliance officer should approve an MCP connector only on a written record that names a BAA, or a documented no-PHI finding, for every system the answers pass through, inventories what each tool can return, states the de-identification method, and sets access control, logging and retention, incident response and a review date. Curve built Curve MCP so the connector's side of this record has a concrete answer, and the filled-in example below marks the lines that stay yours, starting with the one that matters most: Curve's signed BAA, included on every plan, covers its own hop, not the AI vendor your team picks.

What the sign-off record is, and what goes at the top

The Security Rule's risk analysis standard (45 CFR 164.308(a)(1)(ii)(A)) asks for "an accurate and thorough assessment" of risks to ePHI, and a new AI connector changes who can see what. The approval updates that assessment for one connector, in writing.

Our HIPAA-safe MCP server checklist covers what a server must do; this is the document you sign afterward. Scope each record to one connector, one AI client and one group of users. "Claude Code on the Enterprise plan" and "a coordinator's personal ChatGPT" are separate approvals, even for the same server.

The header needs five fields:

• Requester and purpose. The questions marketing wants answered, such as "weekly cost per booked consult by campaign." Minimum necessary (164.502(b)) is measured against this line.
• Connector. Name, operator, version, and where it runs: a vendor-hosted endpoint or a local process on a staff laptop.
• AI client and plan. "Claude" is not an answer; "Claude Enterprise with HIPAA readiness enabled" is.
• Users. Named people or a workforce class, as 164.514(d) already requires for PHI access.
• Decision. Approved, approved with conditions, or rejected, with every condition written out.

A purpose of "explore our data with AI" cannot be measured against anything, so it approves everything the connector can reach.

Part 1: Every hop the answers pass through, and its BAA

An MCP answer crosses at least three systems: the server that fetches it, the host app (the AI client) that calls the tool, and the model vendor whose model reads the result. Other connectors in the same session can receive it too: the model can pass one tool's result into another tool's arguments, and Invariant Labs showed a poisoned tool description can make it do so. Draw that path, then record for each hop who operates it, which BAA and covered-features list apply, and, where there is no BAA, why no PHI reaches it.

The documents you will cite most:

• Anthropic. In the Claude apps, HIPAA readiness is available only on Enterprise plans; the Claude API has a separate BAA that eligible organizations accept in Console. The BAA page says data sent to third parties through MCP connectors is not covered, and the API's MCP connector is not HIPAA-eligible. On Claude Code, Anthropic's BAA page and its API data-retention doc disagree, so get Anthropic's answer in writing and file it.
• OpenAI. Its help center limits ChatGPT BAAs to sales-managed Enterprise or Edu accounts, and describes custom apps and MCP connectors as "not verified by OpenAI."
• Meta. The Business Tools Terms bar sharing data that "includes or is based on... health information."

The candid finding: almost every marketing MCP connection has at least one hop with no BAA. That is not an automatic rejection, but the approval then rests on Part 2, because nothing contractual protects an answer at that hop. Read each BAA's covered-features list, not its title (see what a real BAA covers).

Two answers should stop the review: one vendor's BAA offered for the whole chain, and "it runs locally, so nothing leaves." Google's own Ads MCP repository says the server "will expose your data to the Agent or LLM that you connect to it."

Part 2: What the tools return, and the de-identification method

Inventory tool outputs, not the vendor's database

Get the server's tool list and write one line per tool: inputs, output fields, whether it can write or spend, and who can set each string it returns. For example:

• Google Ads MCP. Read-only per Google's docs, but search runs any GAQL query the accounts can answer, including search terms typed by strangers looking for care.
• GoHighLevel MCP. v1's conversations_get-messages and calendars_get-appointment-notes return patient records in a clinic account; in v2, the inventory is the OAuth scope list behind execute_operation.
• HubSpot MCP. With Sensitive Data on, activity and conversation data are blocked from the MCP server; record whether the setting is on, not whether it exists. It does not block contacts, deals or appointments, and in a clinic's CRM a contact record alone can be PHI. HubSpot also says the restriction applies to the MCP server only, not its standard CRM APIs.
• Meta Ads MCP. Meta hosts the server. Write tools create entities paused, and ads_activate_entity starts spend once the user confirms. Its custom-audience tools can create, update and delete audiences, so with a CRM connector in the same session a patient list can reach Meta, which offers no BAA. Restrict the agent to read-only, which Meta supports per asset, or reject.

Classify every output field as identifiers or PHI, free text an outsider can set, aggregate counts, or configuration. Do not accept a tool's readOnlyHint as proof; the MCP specification says annotations are untrusted unless the server is trusted. File a hash of the approved tool list too; OWASP recommends hashing tool definitions to catch changes after approval.

Name the method, then file its evidence

Record which HIPAA method the vendor relies on; the methods and the small-count traps are explained in small-group rules for MCP answers.

The record names the method and holds its evidence. For Safe Harbor: the field inventory showing no identifier survives, plus confirmation of no actual knowledge that the rest could identify someone. For Expert Determination: the report, naming the expert, the assumed recipient, the date and the exact output rules covered.

Reject "we mask names," "it's anonymized" and "it's only aggregated" as method statements. Then close the gap no server can: a patient name typed into a prompt reaches the AI vendor before any tool runs, so make a no-patient-details rule a written condition (see why you cannot paste a patient funnel into ChatGPT).

Part 3: Who can use it, and what gets recorded

Access control

• Who switches it on. The covered entity, not the agency and not whoever installed the connector.
• Who uses it. Per-user grants matching the header's workforce classes, off for everyone else.
• What credential. Remote servers use OAuth 2.1 with PKCE under MCP's authorization spec; local stdio servers read credentials from the environment, such as a google-ads.yaml file on a laptop. Record the token type, lifetime, and whether anyone shares it.
• How it ends. Who revokes access when someone leaves, and how fast (see MCP token scopes and expiry).

Logging and retention

The audit controls standard (164.312(b)) requires mechanisms that "record and examine activity" in systems that contain or use ePHI. For MCP, that means a server-side record of who called, from which client, which tool, with which arguments, exactly what left, and every denial. Client-side logs are not enough; they live on a laptop or in the AI vendor's account. See what to keep in MCP audit logs.

Record three retention clocks: the server's log, the AI app's chat history, and the model vendor's retention. OpenAI's API docs say data sent to a remote MCP server follows that server's retention policies, and Anthropic's API MCP connector is not eligible for zero data retention. Then name who reviews the logs, and how often; 164.308(a)(1)(ii)(D) requires regular review.

Part 4: Incidents, and the date you look again

Incident response, written before the first call

164.308(a)(6)(ii) requires you to identify and respond to security incidents, mitigate harm, and document outcomes. Define the MCP incidents in advance:

• A tool returns identifiable data.
• A user pastes PHI into the assistant.
• A token leaks, or is used from somewhere unexpected.
• The tool list or a tool description changes without notice.
• Text planted in ad or CRM data steers the assistant.

For each, name who pulls the kill switch (it should need no approval code), how logs scope the event, and who assesses it. Under 164.402, an impermissible disclosure is presumed a breach unless a four-factor risk assessment shows a low probability that the PHI was compromised. A business associate must notify you "without unreasonable delay and in no case later than 60 calendar days after discovery" (164.410); check whether each BAA sets a shorter clock.

The uncomfortable truth: data that reached a model vendor cannot be recalled. You can ask for deletion; you cannot independently verify it. That is why output design carries more of the approval than the incident plan does.

Periodic review and re-approval triggers

164.308(a)(8) requires periodic evaluation, including "in response to environmental or operational changes." List the triggers that reopen the record:

• A tool is added, removed or redescribed.
• The AI client or plan changes, or a vendor edits its covered-features list.
• The de-identification rules or their evidence change.
• New users, a new workforce class, or an agency wants in.
• Any incident.

A workable cadence is a quarterly access and log review plus a full re-approval each year. HIPAA attaches no expiration date to a de-identification determination, so the date on your record is the only one there is.

How Curve MCP fills in the record

Curve MCP gives an AI assistant organization-level weekly numbers: visitors, sessions, goal completions and funnel steps from Curve's tracking, plus a reconciliation of 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 completed week. One link opens the full sent, accepted and matched view inside Curve. The completed record:

1. Header. Requester: marketing lead. Purpose: "weekly conversions and cost per conversion by campaign, completed weeks." Connector: Curve MCP, run by Curve, reached from any MCP-capable client, such as Claude (desktop, web or Claude Code), ChatGPT or Cursor. AI client and plan: your entry. Users: named staff, switched on one by one. Decision: approved with conditions, listed below.
2. Part 1, chain. The connector's hop runs under the signed BAA included on every plan. The AI client and model vendor are ones you select, not Curve subprocessors, so enter their BAA status yourself.
3. Part 2, inventory. Three read-only tools with fixed-choice inputs: one describes what the connector can and cannot return, one returns weekly figures for last week or the last 4, 13 or 52 completed weeks, and one hands person-level questions to Curve Analyst through a sign-in link that works once, expires quickly and carries no data. No revenue, ROAS, or channel, device, region or page breakdowns. Labels are organization-approved or "(label hidden)"; no UTM, path or referrer comes back. Classification: aggregate counts and configuration only.
4. Part 2, de-identification. Rules: people counted across the whole window, small groups withheld, counts and spend rounded, and any figure withheld that would expose a small group by subtraction. A closing check refuses any answer holding something shaped like an email, phone number, ID, date or name, and refuses when it cannot run. Method and evidence: ask Curve which HIPAA method these rules rely on, and for the evidence behind it, and file both. The rule list above describes the design; it is not the evidence. Until the evidence is in the file, record the decision as approved with conditions.
5. Part 3, access. Only the clinic's primary user can enable MCP for the organization. Tokens carry a scope and an expiry; minting one takes a confirmation code and alerts admins. The service's database role cannot read contact details, form answers or journeys, and the service verifies that on every start.
6. Part 3, logging. Server-side, every call. A failed log write means the call returns nothing. Calls that returned data stay on record for years. Your entries: AI-side chat history and model vendor retention.
7. Part 4, incidents. Turning MCP off for the organization removes everyone's access at once. Records of calls that returned data scope any event to the exact figures that left.
8. Part 4, review. Re-approve when the self-describing tool reports a new capability, the tool-list hash changes, or your AI client or plan changes.

Conditions of approval:

• De-identification method and evidence on file.
• No patient names, phone numbers or visit dates in prompts.
• Connector tokens entered only in the AI client and plan named in the header, on accounts the clinic controls.
• AI-side BAA status and retention recorded.

Frequently asked questions

Who should sign off on an MCP connector at a clinic?

The privacy official and the security official, whom HIPAA requires every covered entity to designate (164.530(a)(1) and 164.308(a)(2)). In a small practice that may be one person. Marketing requests the connector; it should not approve it. A clinic with no compliance officer can start from the owner's version, questions to ask before you connect.

Can the decision read "approved" when the AI vendor will not sign a BAA?

Only as "approved with conditions": outputs de-identified under a named HIPAA method with evidence on file, and a written rule against typing patient details. If any tool can return PHI, the decision is rejected.

Does an MCP approval count as our HIPAA risk analysis?

No. It updates the organization-wide risk analysis (164.308(a)(1)(ii)(A)) for one connector. File it with that analysis so the two stay consistent.

How long do we keep the approval record?

Six years from creation or from when it was last in effect, whichever is later (164.316(b)(2)(i)). A superseded approval's clock starts when it is replaced, not when it was signed.

Do we need a new approval when the vendor adds a tool?

Yes. A server can change tool descriptions after approval, which is why you file a hash of the tool list, and 164.308(a)(8) requires re-evaluation after operational changes.

What belongs in the approval file?

The header, a chain diagram, each BAA with its covered-features list, the tool list and its hash, the de-identification evidence, token settings, a sample log entry, incident contacts, and the next review date.

Where to start

Fill in the header for the next connector request before anyone connects anything. If the requester cannot name the AI client and plan, the request is not ready. If your website still sends pixel data to ad platforms, run the free compliance scanner first, because no MCP approval fixes a leak upstream of it.

To walk through this record against the live connector, book a demo of Curve MCP. It shows what the connector returns and what it withholds.

Reviewed September 2026. Sources: 45 CFR Parts 160 and 164, the MCP specification revision 2026-07-28, HHS de-identification guidance, and vendor documentation.