Is the GoHighLevel MCP HIPAA Compliant? A PHI Verdict

No, the official GoHighLevel MCP is not HIPAA compliant: connected to a clinic sub-account, it gives an AI assistant contacts, conversations, appointments, pipelines and tags, which are protected health information. Nothing HighLevel publishes says its BAA covers MCP traffic, and no HighLevel agreement can cover the AI vendor that receives the data. It becomes defensible only when every link carries a signed BAA and the grant is narrow. If what you want from it is campaign reporting, Curve MCP answers those questions from rounded weekly campaign figures, never patient records, with a signed BAA on every plan.

What the GoHighLevel MCP can reach in a clinic account

HighLevel hosts two versions of its MCP server under its LeadConnector name. The older v1 endpoint at services.leadconnectorhq.com/mcp/ authenticates with a Private Integration Token plus a locationId header and exposes named tools. The current v2 endpoints, /mcp/anthropic/v2 for Claude and /mcp/openai/v2/ for OpenAI clients, use OAuth instead.

v2 hides its breadth behind four unified tools: list_locations, search_operations, describe_operation and execute_operation.

For the Claude endpoint, HighLevel's help article of August 2026 lists 625 operations across 40 domains, of which 571 are active: 243 read, 244 write and 84 delete. Your approved OAuth scopes decide which ones a connection can run.

What that catalog touches, and why each item is PHI in a clinic sub-account:

• Contacts. Name, phone and email, plus tags, notes, tasks and appointments. A contact tagged semaglutide-consult is a named person linked to a treatment.
• Conversations and messages. SMS, email and chat threads, and in v2 recordings and transcriptions. These threads are where patients describe symptoms.
• Calendars and appointments. Who is booked, with which provider, for which service. v1 even ships a dedicated calendars_get-appointment-notes tool.
• Opportunities and pipelines. Stage names such as "Consult booked" or "Started treatment" turn a sales pipeline into a care timeline.
• Forms, surveys and payments. Intake answers, survey submissions, orders and transactions.

HighLevel's own HIPAA help article agrees. It lists "Contacts, Notes, Custom Fields, SMS/MMS, voice recordings, email bodies & attachments, form/survey submissions, calendars, invoices" as the objects that can store PHI.

Does HighLevel's HIPAA offering and BAA cover MCP access?

HighLevel states the baseline in capitals: "HighLevel accounts are NOT HIPAA compliant by default." HIPAA is a paid add-on at US$297 per month, bought at the agency level, and it cannot be canceled once enabled. It includes a BAA, encryption of ePHI, audit logging and MFA enforcement. Our GoHighLevel platform verdict covers the CRM beyond MCP.

After the BAA is signed, the agency owner still has to switch on the HIPAA toggle in each clinic sub-account. HighLevel's terms also make the BAA contingent on the package staying paid: on payment failure it is "immediately and automatically terminated."

Now the gap. HighLevel's MCP documentation, from the developer docs to help articles updated as recently as August 2026, never mentions HIPAA, PHI or the BAA. Silence is not an exclusion, but it is not coverage you can show an auditor either. If you rely on the BAA for MCP traffic, get HighLevel to confirm it in writing.

Even written confirmation only covers HighLevel's side. Once execute_operation returns a contact to Claude or ChatGPT, that record sits in a second company's systems. HighLevel's terms say that when you use its APIs, "you represent and warrant that you have obtained all necessary rights and consents to transmit your data to any third party via the API and that such transmission is in compliance with all applicable laws." The MCP server is documented inside HighLevel's API docs and runs the same operations, and the terms never carve MCP out, so assume that warranty applies and the AI leg is yours.

The AI vendor is the link most setups break

HIPAA defines a business associate as anyone who "creates, receives, maintains, or transmits protected health information" on a covered entity's behalf (45 CFR 160.103), and it requires a written agreement with each one. An AI vendor whose model reads your patients' messages fits that definition. So the question is whether the AI client can be covered.

HighLevel documents five AI clients. Where each stands:

• Claude.ai. Anthropic offers HIPAA readiness only on Enterprise plans. Even there, its BAA does not cover data sent to third parties through connectors, so that leg rests on HighLevel's BAA reaching MCP traffic.
• Claude Cowork. Excluded from Anthropic's BAA, even though HighLevel lists it as a supported client.
• Claude Code. Anthropic's own documents conflict on whether it is covered. Treat it as uncovered.
• ChatGPT. OpenAI offers a BAA only on sales-managed Enterprise or Edu accounts and its healthcare offerings, not on ChatGPT Business. HighLevel's setup starts with turning on Developer mode, and OpenAI calls custom MCP connectors "not verified by OpenAI."
• Codex. OpenAI's Regulated Workspace document allows Codex only for uses that involve no PHI.

The uncomfortable part is the default path. HighLevel's setup steps never ask which plan the seat is on, and on Pro, Max, Team or ChatGPT Business there is no AI-vendor BAA at all. Vendor detail is in our pieces on Claude and BAAs and ChatGPT and marketing data.

Some of those connections exist only to answer marketing questions: which campaign booked consults, and what each cost. None of that needs a patient record, which is why Curve MCP answers it from aggregate campaign data instead of the CRM.

Agency access across sub-accounts multiplies the exposure

The Claude v2 endpoint lets an agency connect once and "choose one sub-account, several specific locations, or all available sub-accounts." HighLevel describes agency-wide connections as rolling out. Every operation runs against one sub-account at a time with a short-lived token scoped to that location, and requests for unselected sub-accounts are refused.

The risk is that one assistant, one chat history and one person's AI account now hold PHI from several covered entities. HighLevel's HIPAA article frames the chain itself: the practice is the covered entity, HighLevel and the agency are both business associates, and the agency owes each practice its own BAA. Each of those agreements, and each clinic's minimum-necessary duty under 45 CFR 164.502(b), has to allow that access.

Two agency traps:

• Mixed sub-accounts. The HIPAA toggle is per sub-account. Nothing in HighLevel's MCP documentation says the connection checks it, so "all available sub-accounts" can include clinics where the toggle was never switched on.
• Staff turnover. The OAuth grant and the chat history belong to whoever connected. Revoking the grant stops new calls; it does not delete what the AI vendor already holds.

Agencies should set these rules before a client asks; see MCP client data boundaries for healthcare agencies.

Write tools turn a privacy risk into an action risk

The GoHighLevel MCP is not a reporting connector. The v1 server alone can add and remove tags, create, update and upsert contacts, update opportunities and send a new conversation message. The v2 Claude endpoint lists 84 delete operations, plus workflow enrollment, invoice sends, and advertising operations for Facebook, Google and LinkedIn that include audiences and lead forms.

HighLevel says sensitive and irreversible operations are "gated with additional confirmation and safety checks." That helps against an accidental bulk delete. It does not judge whether a text to a patient is appropriate, or whether a new tag writes a treatment onto a record.

The failure modes to plan for:

• A message to the wrong person. "Text yesterday's no-shows" can send to a list the model assembled. A wrong match is a disclosure to a stranger, in the clinic's name.
• Health data written into tags. "Tag everyone who asked about TRT" creates a treatment label that every downstream workflow, integration and export will carry.
• Instructions hidden in inbound messages. Patient and spam messages are text an outsider controls. OWASP classes instructions smuggled in through external content as indirect prompt injection, and an assistant that both reads conversations and sends messages is exactly what it targets.
• Patient lists next to ad audiences. If its scopes allow, the grant that searches treatment-tagged contacts can also reach ad-audience operations. Google's Customer Match policy restricts uploading health information, and Meta's Business Tools Terms bar sharing data through its business tools that includes or is based on health information. See our customer list upload audit.

The MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations." With write scopes on a clinic sub-account, treat that as the floor. The full review list is in what makes an MCP server HIPAA-safe.

How Curve limits what ad platforms and AI models see

The fix is to stop asking marketing questions of the CRM. GoHighLevel's Ads operations cover Facebook, Google and LinkedIn audiences, the shortest path from a treatment-tagged contact list to an ad platform. Curve's route sends a booking or stage change as a neutral conversion with hashed, mapped identifiers instead of a list.

A GoHighLevel workflow webhook posts the booking to Curve's incoming webhook, which matches attribution by email, click ID or bridge token. Website events reach the same US-hosted infrastructure from a tracking script that replaces the Meta Pixel and Google tag. From there:

• Per-destination field mapping. Nothing forwards to Meta or Google unless you mapped it. The default is that nothing goes.
• Hashed identifiers. Mapped identifiers are SHA-256 hashed to each platform's conversion API requirements.
• Neutral event aliases. The platform sees a neutral event name, not "TRT consult booked."
• PHI-pattern detection. PHI-shaped values are flagged. This is monitoring, not redaction; the protection comes from mapping and hashing.

For AI questions, Curve MCP returns organization-level weekly figures: visitors, sessions, goal completions, funnel steps, and a reconciliation of your server-side campaigns. That reconciliation puts 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, and one link opens the full sent, accepted and matched view inside Curve. It counts people across the whole window, withholds small groups, rounds released counts, and holds back any number that subtraction could turn into a small group. Campaign and goal names appear only if the clinic approved them.

It works with any MCP client or agent, including Claude (desktop, web and Claude Code), ChatGPT and Cursor. It is read-only and not a CRM tool: it cannot text a patient, move a pipeline stage or enroll anyone in a workflow. It offers fixed look-backs (last week, 4, 13 or 52 weeks), with no revenue, ROAS, or channel, device or page breakdown. Access is off by default per user, only the clinic's primary user can turn it on for the organization, and access tokens are scoped and expire, need a confirmation code to issue, and notify admins.

A final check blocks any answer that looks like it holds an email, phone number, ID, date or name, and fails closed if it cannot run. The service's database role cannot read contact details, form answers or journeys, and no data returns if the call log cannot be written.

Person-level questions get a one-time link into Curve Analyst; the link needs a login and carries no data. None of this makes your AI vendor HIPAA compliant, and Curve's BAA does not extend to the AI vendor you choose. The design goal is narrower: what reaches the model is aggregate, rounded and free of small groups.

What a clinic should do before anyone connects it

1. Find existing connections. Ask who has added a LeadConnector endpoint to an AI client, and whether through a v1 Private Integration Token or a v2 OAuth grant. OAuth grants can be reviewed and revoked from the HighLevel account; tokens live under Settings, Private Integrations.
2. Check four things. HighLevel's HIPAA package and BAA; the HIPAA toggle on in this sub-account, under Sub-Accounts > [Location] > Advanced Settings; an agency BAA with the clinic; and a BAA with the AI vendor on a plan and feature it actually covers. If any one is missing, disconnect.
3. Ask HighLevel two questions in writing. Does the BAA cover MCP operations? Do MCP calls appear in the audit log the HIPAA package includes? The audit-controls standard at 45 CFR 164.312(b) expects you to record and examine activity in systems that hold ePHI.
4. If it stays, shrink it. One sub-account, read scopes only, no conversations. The step-by-step version is in GoHighLevel MCP for clinics: locking down contact data.
5. Move marketing questions elsewhere. Campaign performance, cost per conversion and week-over-week trends belong in a source that holds no patients.

Frequently asked questions

Does HighLevel's HIPAA package make the MCP HIPAA compliant?

No. It gives you a BAA with HighLevel and HIPAA hardening in sub-accounts where the toggle is on. No HighLevel agreement can cover the separate AI vendor that receives the data.

Is every GoHighLevel contact PHI?

Not in every account. In a clinic or telehealth sub-account, a name or phone number tied to an appointment, a treatment tag, a pipeline stage or a message thread is identifiable health information held for a covered entity. Treat the whole sub-account that way; sorting records one by one is not a control.

Can I use the GoHighLevel MCP with Claude Pro or ChatGPT Plus?

Not with PHI. Anthropic enables HIPAA readiness only on Enterprise, and OpenAI offers ChatGPT BAAs only on sales-managed Enterprise or Edu accounts and its healthcare offerings. Individual and small-team plans carry no BAA.

Is the v1 Private Integration Token safer than the v2 OAuth connection?

Narrower, not safer in HIPAA terms. v1 names one location per request in a header and has a fixed tool list, but the token sits in your client configuration, and HighLevel warns never to expose it "in public repositories, screenshots, shared prompts, or client-side code." v2 reaches a far larger catalog with short-lived per-location tokens. Neither answers the BAA question.

Can an agency connect every client sub-account to one Claude account?

Technically yes, where HighLevel's agency-wide option has rolled out, since the Claude endpoint lets an agency select all available sub-accounts. It also concentrates PHI from several covered entities in one AI account, so every clinic's BAA with the agency must permit it and the AI plan must carry a BAA. Most agencies should not.

Does Curve MCP read GoHighLevel data?

Not directly. If a GoHighLevel workflow posts bookings to Curve's incoming webhook, those bookings count toward the aggregate goal and conversion figures it returns. The assistant never receives a contact record, a message or a path into the CRM.

Where to start

If a GoHighLevel MCP connection already exists on a clinic sub-account, list it, check those four things, and disconnect anything that fails. Then run the free compliance scanner on the clinic's website.

If the real goal was answering campaign questions in an AI client, book a demo to see Curve MCP answer cost per conversion by campaign from rounded weekly figures. Curve signs a BAA on every plan; your AI vendor's coverage is still yours to confirm.

Reviewed September 2026. Based on HighLevel's MCP docs, help articles and terms, and on Anthropic's and OpenAI's published BAA scope.