How to Audit an MCP Server for HIPAA: The Checklist We Run on Our Own Connectors

The quick answer

Three questions decide most of it. Is your organization a covered entity or a business associate for the records in front of you, because if it's neither, HIPAA isn't the rule that governs them. What does the model see, because the connector is a pipe and the model is the party that reads the chart. And what does the connector keep, because credentials, caches and logs are where a second copy of the data appears. The twelve checks are those three questions broken into things you can ask a vendor for evidence on; the table after them is what our own Clio, MyCase and IntakeQ connectors score.

Are you even a business associate? The matter-type test

In June a defense litigation firm in Oklahoma and Texas found our open-source Clio connector, tested it with Claude, and booked a call. Four offices, Clio Manage only, an outsourced IT vendor who'd review whatever we proposed. The paralegal's use case was the one every defense firm has: take the whole case file and produce a medical chronology, a deposition summary and a paid-versus-incurred table. On that call we said the setup was "HIPAA compliant because the connector stores nothing." That was wrong in a way the IT vendor would have caught in a minute, because the model reads every page of the chart to write the chronology, whatever the connector stores. We corrected it in the proposal, and working out the correction produced the matter-type split.

The definition in 45 CFR 160.103 makes a business associate of anyone who, other than as a member of the covered entity's workforce, "provides ... legal, actuarial, accounting, consulting, data aggregation" or similar services to a covered entity where the service involves protected health information. A nursing home is a health care provider, so it's a covered entity. A firm defending that nursing home in a resident's negligence suit gets the residents' records from its own client, to provide legal services to that client. That's the definition, word for word. The firm is a business associate, a BAA with the nursing home is required, and the Security Rule applies to how the firm handles the records.

The same firm also defends trucking companies and construction contractors. In those matters the medical records belong to the plaintiff and arrive through discovery. 45 CFR 164.512(e) is the provision that lets the plaintiff's providers release them: in response to a court order, or to "a subpoena, discovery request, or other lawful process" backed by satisfactory assurances of notice to the patient or a qualified protective order. The defense firm isn't performing a service for any covered entity there. It's an adverse party receiving records under lawful process. It's not a business associate, and the protective order, rather than HIPAA, is the document that says what it may do with the records, including whether they can go to any outside processor at all.

So one firm, one paralegal, one chronology workflow, and two different sets of obligations depending on the matter. That's the test we now run first with any firm that touches medical records: sort the matters into "we act for a covered entity" and "we received these under process," and design the AI path for the first bin as a business associate would. Whether a specific matter falls in the first bin is a call for the firm and its own counsel. We build software; the legal conclusion stays with them.

Clinics are simpler. A behavioral health practice on IntakeQ is a covered entity outright, so the question isn't whether HIPAA applies but who's in the chain.

The BAA chain

Read the chain from the patient outward. Every party that receives PHI from the covered entity on its behalf needs a BAA, and every party that receives PHI from that party needs one too. HHS's FAQ for lawyers spells out the middle link: a lawyer-business associate who brings in another person or entity to help with the legal work, and has to give them PHI to do it, must ensure they agree to the same restrictions the lawyer is under. In 160.103 that person is a subcontractor, and a subcontractor "that creates, receives, maintains, or transmits protected health information on behalf of the business associate" is itself a business associate.

For the nursing-home defense matter, the chain ran: nursing home, BAA, the law firm; the law firm, BAA, us, because we'd be building and managing a chronology pipeline that receives the records; the firm, BAA, Anthropic, because the model reads the records through the API; and, if inference ran on Amazon Bedrock, the firm's existing AWS BAA on that account. Four links. Signing the middle one was a real decision for us, since it means taking on business associate obligations for the first time, and it's why the proposal defaulted to deploying single-tenant in the firm's own cloud, where we manage the pipeline under retainer and never custody the records.

Two of those links have vendor documentation you can read. Anthropic's help center says it "provides a BAA covering our HIPAA-ready services, such as use of our first-party API or Enterprise plans," that "your organization's Primary Owner will need to sign a BAA and then reach out to your Anthropic contact or our Sales team to get this turned on," and that the BAA "excludes features such as Claude Console, Claude Cowork, or features currently in beta." Free, Pro, Max and Team aren't covered. The line that catches firms is on the same page: "Covered Models require 30-day data retention and aren't available with zero data retention (ZDR) enabled." Covered Models are Anthropic's newest releases; pick the top model off the dropdown and you've left ZDR without a warning. On that June call the firm was on a Max subscription, which opts out of training but keeps prompts for around 30 days and carries no BAA. The API with ZDR under a BAA was the recommendation, and the tier differences are in ZDR on Team versus the API.

On Bedrock the documentation comes from AWS. By default Bedrock stores no model inputs or outputs and no operator can read them, model providers have no access to Bedrock logs or customer prompts, and invocation logging is off unless you turn it on, into your own account. The exception mirrors Anthropic's: one current model retains inputs and outputs for up to 30 days and requires an opt-in to review. We don't print model names in compliance posts because they go stale. Pin a model that sits under the default and re-check on every release.

On the clinic side, IntakeQ and PracticeQ include a self-serve BAA on every plan, signed from the account's settings, which is why a clinic can run a connector against its own data without a partnership gatekeeper. The clinic's chain is IntakeQ, BAA, clinic; clinic, BAA, model provider; and a connector vendor only if one actually receives PHI.

The 12-point checklist

The checks apply to any of the three ways an AI connector gets built: a vendor-hosted product, where the connector and often the model calls run on the vendor's servers; a self-hosted deployment in your own cloud account; or a local agent on a staff member's machine, which is how our open-source connectors run. A hosted product can pass every item; the evidence just comes from the vendor's contract and security documentation instead of a README. The red flag on any item is a vendor who answers "it's secure" and moves on.

1. Business associate agreement

Run the matter-type test first, then get a signed BAA from every party that will receive PHI: the connector vendor if it hosts or processes anything, the model provider, and the cloud if the model runs there. Evidence: the signed agreements, and the model provider's page saying which products the BAA covers.

2. Zero data retention

The model tier stores nothing after the response, in writing. On Anthropic that's the first-party API or Enterprise with ZDR enabled at the organization level; on Bedrock it's the default. Evidence: the ZDR terms for your organization, and an answer to which models are excluded. Retention is still the second question. The model read the chart, and for PHI that access is the exposure; a clean retention posture doesn't undo it.

3. Training disabled

The terms for your tier say inputs and outputs aren't used to train models. Commercial terms say this; consumer plans have their own settings and defaults. Evidence: the paragraph in the commercial terms, with the date you checked it.

4. Token storage

Where do the platform credentials live at rest, how are they encrypted, and where's the key? A token file next to the key that decrypts it is plaintext with extra steps. Evidence: the storage path, the cipher, and the key location. On a hosted product that's a secrets manager; on a local connector it's an OS keychain.

5. Audit log contents

45 CFR 164.312(b) asks for mechanisms that record activity in systems containing PHI. Ask for one sample line. It should carry a timestamp, the tool or endpoint, the arguments, the outcome, and the user and record identifiers, and the file should be append-only. Then ask who can read it and where it lives. The application side is in our audit trail guide.

6. PHI in the logs

Item 5 has a trap in it. Logging the arguments is what makes the log useful, and the arguments to a search tool are a patient's name; the arguments to a write tool can be the text of a note. Evidence: the argument list on one search tool and one write tool, and whether the log file is protected like PHI or those fields are dropped or hashed. Redacting secrets doesn't answer this.

7. Minimum-necessary scoping

Two layers. At the connector, count the write tools and ask whether they can be switched off in configuration rather than by asking the model nicely. At the workflow, list per task which fields go to the model and which are withheld. Sending the whole file is usually the easier thing to code; the chronology task needs the records, the scheduling task doesn't. Evidence: the tool list with a read-only switch, and a per-workflow field list.

8. MFA and OAuth

OAuth through the platform's own login page means the connector never sees a password and inherits whatever MFA policy the firm has set on the platform. A static API key is a password that never expires. Evidence: the auth flow, and for API keys a rotation schedule with an owner's name on it.

9. Retention

Every file the connector keeps and for how long: credentials, caches, downloaded documents, temp files, logs. The goal is fewer copies of PHI in motion. The audit log is the exception you want kept, since HIPAA's documentation requirement runs six years. Evidence: the list of files, with paths.

10. Model version pinning

Retention terms differ by model on both Anthropic and Bedrock, so whoever picks the model version is choosing the retention posture. Ask who that is: the MCP client, the API call, or a vendor setting. Evidence: the pinned version, written in the firm's AI record, and a date it was last re-checked. Package version pinning for the connector itself belongs here too.

11. Subprocessor list

Every company that touches PHI downstream of the connector. A local connector with no relay server adds none; the model provider's own list is the one to ask for. A hosted product should hand you a list with the model provider on it and a way to be told when it changes. Evidence: the list, dated.

12. Incident process

How is a vulnerability reported, who answers, and how does a breach involving PHI reach you inside the Breach Notification Rule's timelines? Evidence: a security contact, a disclosure policy, and the breach clause in the BAA.

What our own connectors pass and fail today

Graded against the READMEs and the source as of the versions shown, August 2026. "Client's control" means the Claude client or API caller decides the item; the connector's job there is to say so in its documentation.

Three of the fails are the same fail on all three connectors, and they're ours to fix. The audit log argument problem is the one that surprised us when we graded honestly: the Clio connector already drops the note body from its create_note entry, which shows someone thought about it, and then logs the free-text note on a time entry and the query on a contact search, which in a law firm is usually a client's name. The MyCase connector writes first name, last name, email and phone into its search entry. On a machine where the log directory is owner-only that's contained, and it's still PHI in a second place. Hashing or dropping free-text arguments is on our list; until it ships, treat the log file as PHI.

The read-only switch exists on our Lawmatics connector as a config flag and hasn't been ported to the other three, which is why item 7 fails across the board. None of the repos has a security contact, a five-minute fix we've owed since the first release.

What no checklist replaces

The Security Rule's first required safeguard is a risk analysis, and a missing or stale one shows up in enforcement more often than any technical gap; the audit failures we see most start there. This checklist is one input to that analysis, for one integration.

Two other things carry more weight than any row in the table. A written policy that says which matters or patients go through the AI path, who approves a new workflow, what fields each workflow sends, and that nothing is relied on before a person reviews it. And training, because the paralegal who pastes the whole file into the chat window on a personal subscription has bypassed every control above without touching the connector. For a clinic that wants an assistant without any of this, the cheapest architecture we know is one that never handles PHI at all; ask whether the task needs the chart before building the chain to protect it.

Frequently asked questions