MCP Audit Logs for Healthcare: What to Keep and Why

An MCP audit log for healthcare should keep six things for every tool call: who asked, which AI client and credential they used, which tool ran, with which arguments, exactly what the server returned or refused, and when. Keep the records of calls that returned data for six years, the period HIPAA sets for required Security Rule documentation, because they are the evidence of what an AI assistant received from you. Curve writes that record for every Curve MCP call and returns no data when it cannot. A server log proves what left your system, not what the model did with it next.

Why the MCP server needs its own log

The MCP specification puts logging on the client: clients SHOULD "Log tool usage for audit purposes." That log sits on someone's laptop or in an AI vendor's account, under someone else's retention. Useful, but not your record.

HIPAA's audit controls standard, 164.312(b), asks for mechanisms that "record and examine activity in information systems that contain or use electronic protected health information." An MCP server that can read ePHI, such as patient contacts in a CRM or form submissions, is one of those systems. One that reads only ad-platform metrics may not be, and the log is how you prove that. 164.308(a)(1)(ii)(D) supplies the second half: procedures to "regularly review records of information system activity," audit logs included.

Official ad-platform servers do not solve this. Google's Ads MCP server is self-hosted, so its audit trail is whatever you build around it. Vendor-hosted servers such as Meta's run on the vendor's infrastructure, so whatever they log sits under the vendor's policies, and Meta does not sign a BAA for its advertising products.

General application logs are the wrong home: often sampled, rotated within weeks, and shipped to monitoring tools outside any BAA. If arguments or output land there, the log itself becomes the leak, one of the paths in our breakdown of where health data leaks in MCP tool calls.

What every call record must contain

Miss any of these six and a whole class of investigator's question goes unanswered.

Who asked, and for which account

Record the person, not the integration. The common failure is a shared credential: if every marketer runs Google's Ads MCP server from one google-ads.yaml file, every call looks like the same user. Store the organization and a stable user identifier; a keyed hash of the user's email keeps addresses out of the log.

On multi-account servers the target is an argument: a Google Ads customer ID, a GoHighLevel sub-account. Copy it into its own field when the record is written, because arguments expire and the response may not name the account.

Which client and credential

Record the token or OAuth grant that authorized the call, plus the client's reported name. The name is a claim, since a client can call itself anything; the credential ID you issued is what holds up in an investigation. One credential per person per client makes revocation and attribution the same act. Our guide to MCP access tokens, scopes and expiry covers the credential side.

Which tool, under which definitions

Log the tool name exactly as called, including unknown tools and refused calls, plus a version or hash of the tool definitions in force. Invariant Labs showed that "A malicious server can change the tool description after the client has already approved it," and OWASP recommends pinning tool definitions with cryptographic hashes. Without a version on each record, you cannot say which instructions the model was reading.

Which arguments

Arguments are written by the model, so they can carry anything in the conversation: what the user typed, a name another connector returned, or text planted in data the model read. "Did Maria book after the Botox campaign?" becomes a search argument with a patient's name in it. That argument leaves the AI vendor as soon as it is sent. Anthropic's BAA page says data sent to third parties through MCP connectors is not covered by its BAA, so the receiving server's log is where that disclosure gets recorded.

Log them anyway, because they show intent and reveal probing, but treat them as the record's most sensitive field.

What was returned, or refused

Store the exact response that left the server, not a row count or a summary, plus its SHA-256 fingerprint. Record the decision (allowed or denied), any denial reason, and whether a final check blocked the answer. A burst of denials from one credential is often the first sign that someone, or an instruction planted in ad data, is probing for what the server will not give.

When

Use the server's clock in UTC, never the client's, plus how long the call took and the network the request came from. Time and network together are what separate a stolen laptop's calls from its owner's.

Redacting arguments without destroying the evidence

Arguments and outputs need opposite treatment. The output is the evidence of what you disclosed, so keep it whole and restrict who can read it. Arguments are incidental, so reduce them.

• Accept less. The best redaction is an input that cannot hold PHI: enums, fixed date windows, bounded numbers. A tool that takes free text will log free text, whatever your policy says.
• Hash identifiers with a key. If a tool must accept an email or phone number, store an HMAC keyed with a secret held outside the log database, never the value. An unkeyed hash of a phone number can be reversed by hashing every possible number; the keyed one still answers "did anyone look up this person?"
• Mask contact details in free text. Replace emails and phone numbers in any stored question before the record is written. Names are harder to catch, which is why the next rule exists.
• Expire arguments sooner than outputs. After your review window, arguments add more risk than evidence; the response, the metadata and the target account carry any investigation.
• Keep both out of every other log. Request logs, tracing and error reports should carry metadata only: tool, status, timing, credential ID.

Do not redact the output: a cleaned copy cannot prove what the assistant received, the one question the log exists to answer.

Retention: applying HIPAA's six-year rule

HIPAA does not name a retention period for audit logs as such. 164.316(b) requires a written record of any "action, activity or assessment" the Security Rule requires to be documented, retained "for 6 years from the date of its creation or the date when it last was in effect, whichever is later." Audit controls and activity review are required, so the conservative reading applies six years to their records.

The stronger reason is breach math. Under 164.402, an impermissible disclosure is presumed a breach unless you show a low probability of compromise, and one of the four factors is "Whether the protected health information was actually acquired or viewed." Under 164.414(b), the burden of demonstrating that is yours. A leak found in year three can only be scoped if the year-one responses still exist.

• Calls that returned data: six years, with the full response and metadata, in storage the application cannot edit or delete.
• Denied calls with no output: through your review cycle and a realistic investigation window.
• Arguments: the shortest period you can defend.
• Reads of the log itself: logged, and kept as long as the records they touched.

One uncomfortable collision: at termination, a BAA must require the business associate to "return or destroy all protected health information" if feasible, or extend the contract's protections where it is not (164.504(e)(2)(ii)(J)). Six years of disclosure evidence pulls against that clause. Decide in advance which path applies to audit records and write it into the agreement; our guide to reading a BAA's fine print shows where that clause sits. Curve's choice is described below.

Proving what an AI assistant saw

When someone asks "what did Claude see?", three sources answer different parts.

• The server log shows exactly what left each MCP server, call by call. It sets the ceiling: from this server, whoever held that credential received this and nothing more. The client name on the record is a claim; a script using the same token looks the same.
• The client and vendor history shows the conversation: what the user typed, attached files, and other connectors' results. It sits in the AI vendor's account, under its retention.
• Nothing proves what the model inferred, or what a user did with an answer after copying it.

A worked example: an account manager's laptop is stolen with an AI client still signed in.

1. Revoke every MCP credential on that device and record the time.
2. Pull every record for those credentials across the exposure window, from each connected server.
3. Read the responses, not just the metadata. Sort them into aggregate counts, labels, and anything person-level. Curve MCP returns only organization-level weekly figures with small groups withheld, so its part of step three is reading counts, not contact records.
4. If a response surfaces later as exported text, fingerprint it and compare. A hash matches only byte-identical text, so if the client reformatted the JSON, compare field by field against the stored response, one more reason to keep the response itself. Neither method matches a paraphrase or a screenshot.
5. Run the four-factor assessment with those responses in hand, and file it with your review records.

A CRM server that can read contacts and messages, such as GoHighLevel's, makes step three far harder, and only its log holds the answer.

How Curve MCP logs every call

Curve MCP answers organization-level questions about visitors, goals, funnels, campaign spend and conversions, in completed weeks, with small groups withheld.

• No log, no answer. The record is written before any response is returned. If the write fails, the assistant receives "Curve could not record this request, so it was not answered" and no data.
• What each record holds. The organization, the user as a keyed hash of their email, the credential, the client, the tool, the decision and any denial reason, the outcome, the exact response with its SHA-256 fingerprint, the timing, and the version of the release rules that shaped the answer.
• Blocked answers kept. A final guard checks every response for anything that looks like an email, phone number, ID, date or name. When it blocks one, the record keeps what was withheld and an alert fires.
• Arguments reduced. The data tools accept fixed choices only, so there is no free text to log; the one tool that carries a question returns a single-use link into Curve Analyst that holds no data. In its stored arguments, email addresses and phone numbers are masked and any person handed over is kept only as a keyed hash. A patient's name typed into the question is not caught, which is why the arguments are cleared well before the responses.
• Append-only, with logged reads. The application cannot edit or delete records; only the scheduled retention job and a documented offboarding purge can, each writing its own security record. Every read of a full record is logged before it appears.
• Held under the BAA. Curve MCP is vendor-hosted, so this log lives with us, not in your systems. Unlike an ad platform, we keep it as your business associate under the signed BAA, and only a named Curve administrator opens a full record, for example when you need the responses for a breach assessment.
• Kept until you leave. Routine retention never removes a record of a call that returned data; arguments and denials age out long before. When a customer leaves and the BAA's return-or-destroy clause applies, a documented purge clears the stored arguments and responses and keeps the metadata and each response's SHA-256 fingerprint, so a copy that surfaces later can still be confirmed or refuted.
• Out of every other log. Arguments and responses never reach application logs, tracing or error reporting.

That BAA, included on every plan, stops at our edge. It does not cover the AI vendor your client forwards answers to, which is exactly why the log records what went there.

A review cadence someone will actually keep

The standard says record and examine. Many teams stop at the first half.

• As it happens: alerts on blocked responses, denial bursts from one credential, repeated authentication failures, and a credential appearing from a new client or network. Curve's server alerts on any withheld answer, on repeated unauthenticated requests from one address, and on any credential or organization reaching its daily call budget.
• Weekly, 15 minutes: who called, from which clients, how often; every denial; any credential held by someone who has left.
• Monthly: read a sample of full responses per server, confirm they match what it should return, and check whether any tool definitions changed.
• Quarterly: review who can read the audit log, force a log-write failure in testing to confirm no data comes back, and confirm the retention job ran.
• Every time: write down what you checked and what you found. That note is documentation under 164.316(b), with its own six-year clock.

Frequently asked questions

Does HIPAA require audit logs for MCP servers?

Yes, for any MCP server that can read ePHI: 164.312(b) is a required standard for systems that "contain or use" it. A server that only returns de-identified aggregates is a harder call, but its log is how you prove that, so log it either way.

How long should we keep MCP tool-call logs?

Six years for calls that returned data, matching 164.316(b)(2)(i). Denials and arguments can age out sooner, on a schedule your policy states.

Is metadata enough, or do we need the full response?

You need the full response. Metadata proves a call happened; only the response shows whether PHI was "actually acquired or viewed." Restrict who can read responses rather than declining to store them.

Can the AI vendor's chat history serve as our audit trail?

No. It sits under the vendor's retention, a user can often delete it, and it mixes your server's answers with everything else. Use it alongside your server log, never instead.

What should an agency log when it runs MCP across several clinics?

Record the clinic's account on every call as its own field, since the organization on the record is usually the agency itself. Issue one credential per person per clinic, and give each clinic its own records, never another's. Our guide to client data boundaries for healthcare agencies covers the rest.

Where to start

Inventory every MCP server your team's AI clients connect to, and check each against the six fields above. Start with the response: a server that cannot show exactly what it returned should not touch data that could contain PHI.

To see what your website already sends to ad platforms, run the free compliance scanner. To see Curve MCP's call records and the answers they hold, book a demo.

Reviewed September 2026. Regulatory quotations are from 45 CFR Part 164 on the eCFR; MCP details reflect the 2026-07-28 specification.