How AI-agent tool calls reach ePHI and fall under the Security Rule — what OCR asks, where default setups fall short, and the controls that let you use agents with patient data safely.
QUICK ANSWERHIPAA regulates organisations handling ePHI, not protocols. The moment an agent calls a tool that reads or writes patient data, the Security Rule (45 CFR Part 164 Subpart C) attaches to whoever runs that access path — and a shared service key fails unique user identification, audit controls and access management by default.
No protocol or product can “be HIPAA compliant” — the Security Rule binds covered entities and business associates handling ePHI. Scope attaches the instant an agent touches that data through a tool. Three things put MCP traffic there.
A tools/call against an EHR, patient database, scheduling or claims system reads or writes ePHI. That is Security Rule territory — access must be controlled, attributable and recorded.
§164.312(a) grants ePHI access to persons or software programs with access rights. An agent calling tools is in scope — and a shared key collapses every agent action onto one identity.
A hosted gateway that transmits and maintains ePHI is, in our reading, a business associate — it inspects calls rather than acting as a “mere conduit”. We sign a BAA; the upstream vendors you reach should sit in that chain too.
The Security Rule safeguards MCP traffic on ePHI is tested against. For each: what it requires, the question asked at audit, the default-setup gap, and the control that closes it.
Technical policies allowing ePHI access only to persons or software programs granted rights under §164.308(a)(4), and a unique name or number for identifying and tracking each user — §164.312(a)(2)(i) is a Required implementation specification.
Which identity made this tool call against ePHI — and was it granted that right? The text covers software programs, so each agent needs its own trackable identity.
A shared API key in client config collapses every agent and person onto one identity. Nothing tracks who actually acted, and access is granted to whoever holds the key.
Per-person scoped grants give each consumer — human or agent — a distinct, trackable identity; upstream credentials stay in central custody, out of client configs.
Across 4,628 servers, the shared key is the default auth model — the pattern unique user identification exists to replace.
Mechanisms that record and examine activity in systems containing or using ePHI — hardware, software or procedural.
Can you produce a record of every tool call against ePHI, with enough detail to examine what happened and who did it?
Default MCP traffic is an ephemeral client-to-server exchange. Logs are scattered and local, upstream identity is opaque — there is nothing centrally examinable.
Every call lands in a per-call audit log: the grant, the tool, the argument keys, the deciding rule and the verdict — recorded centrally so it can be examined.
1,649 execute plus 1,773 destructive tools in the corpus make “record and examine” meaningless without a single choke point recording the calls.
Protect ePHI from improper alteration or destruction; §164.312(c)(2) is an Addressable specification to corroborate that ePHI has not been altered.
What stops a prompted or accidental mass mutation of patient records — and where is the record of what an agent changed?
Nothing distinguishes a legitimate single-record update from an accidental or prompted bulk overwrite; once it runs, there is no trail of what changed.
Deny rules and argument conditions gate write and destructive tools, and the log records each attempted operation and its verdict — prevention plus an audit trail, not a cryptographic checksum. Record-level change evidence pairs it with the EHR or database audit trail.
7,607 write plus 1,773 destructive tools are the integrity-risk surface this safeguard speaks to.
Verify that a person or entity seeking access to ePHI is the one claimed. HIPAA’s access-control standard expressly covers software programs, so the person, agent or service identity behind a request should be authenticated per the access-management design.
Is the caller authenticated as a specific person or agent before any ePHI tool executes — or only as the shared application?
A shared service account authenticates the app, not the person behind the request. Every agent looks identical at the point of access.
Each session is bound to a verified, issued grant before any tool runs — authentication happens per identity, ahead of execution.
Guard against unauthorised access to ePHI transmitted over a network; §164.312(e)(2) integrity and encryption specifications are Addressable.
How is ePHI protected in transit between clients and the servers holding it, and is that posture consistent across every connection?
Direct client-to-server connections vary in TLS posture — every laptop and runner sets its own, and none of it is enforced centrally.
The gateway standardises TLS and certificate policy across both legs — client to gateway and gateway to upstream — so transmission protection is set in one place rather than negotiated per client.
4,628 servers behind one enforced transmission policy instead of as many inconsistent ones.
Regularly review records of information system activity — audit logs, access reports and security-incident tracking. A Required implementation specification.
Beyond recording calls, can someone actually review who accessed ePHI and what they did, period over period?
With no central call records there is nothing to review; activity review pairs with audit controls, and the default setup produces neither.
The centralised, queryable audit log is the literal artefact a review draws on — filterable by identity, tool and verdict.
Authorise and supervise workforce access, terminate it on departure (a)(3), and establish, document, review and modify each user’s right of access consistent with Subpart E (a)(4).
Show how a person’s access was authorised and documented — and the record of it being revoked when they left.
A shared key is all-or-nothing: revoking it breaks every agent for everyone, so in practice it never gets revoked, and there is no per-user authorisation record.
One person’s grant is revoked instantly without touching anyone else’s; per-tool authorisation is documented in the grant and call log.
Make reasonable efforts to limit ePHI to the minimum necessary for the intended purpose — with a standing exemption for treatment disclosures, so it does not apply universally.
Where minimum necessary applies, is an agent’s access scoped to the records its task needs — or does it hold the whole server?
Agents typically get full server access by default — “look up this patient” and “dump the table” are the same grant.
Allow/deny rules and argument conditions scope each grant to the minimum tool surface — a single-record lookup rather than bulk read or export.
Of 19,718 read tools, minimum-necessary scoping is the difference between “look up this patient” and “dump the table”.
Illustrative policies — not complete compliance controls on their own.
Allow a single-patient lookup and nothing else. Search, bulk export and every write tool stay denied by default — the agent can read one record at a time, not the table.
{
"version": "1",
"default": "deny",
"tools": {
"get_patient_record": {}
}
} Reads run; statements that alter or destroy records do not. Each denied attempt is itself an audit-control record of what was prevented. Illustrative — in production, pair the gateway rule with read-only database credentials upstream.
{
"version": "1",
"default": "deny",
"tools": {
"query_records": {
"deny_if": [
{
"conditions": [
{ "path": "args.sql", "op": "regex", "value": "(?i)(DELETE|DROP|TRUNCATE|UPDATE|ALTER)\\s" }
]
}
]
}
}
} See Writing policies for the policy format, operators, and quota shapes.
OCR investigations and risk analyses ask for traceability — who accessed ePHI, under what authority, and the record of it. The artefacts a gateway deployment hands over:
| What the auditor asks for | What the gateway exports |
|---|---|
| Access, audit and activity logs for systems holding ePHI (§164.312(b), §164.308(a)(1)(ii)(D)) | Per-call audit log: grant, tool, argument keys, deciding rule, allow/deny verdict. |
| User provisioning and termination records (§164.308(a)(3)/(a)(4)) | Grant issue and revocation history per identity, timestamped. |
| “Who accessed this patient’s record, and under what authority?” | A query over the audit log returning each access by identity, grant and deciding rule — the answer a shared-key setup cannot give. |
| Risk analysis and risk-management plan (the recurring OCR finding) | The gateway is the control your analysis prescribes for the MCP slice, not the analysis itself — its scoped grants and logs are the documented enforcement. |
| Business associate agreements down the chain | A signed BAA for the gateway, plus the upstream server registry showing which vendors touching ePHI need one too. |
| Periodic access-review evidence (§164.308(a)(4)) | Exportable grant registry: every identity, its scoped tool set, issue date and last review. |
That is the wrong question. HIPAA regulates organisations handling ePHI, not protocols — so MCP itself is neither compliant nor not. What matters is your deployment: a raw shared-key setup fails unique user identification, audit controls and access management by default, whereas a deployment with per-person identity and examinable logs can satisfy the safeguards.
Yes. HIPAA is technology-neutral — there is no rule against AI agents touching patient data. What you need is per-person identity rather than a shared key, examinable audit logs of every call, least-privilege scoping under minimum necessary, and business associate agreements down the chain. A gateway gives those a single enforcement point.
If it transmits or maintains ePHI, our position is yes. A gateway that evaluates policy on each call inspects the content of the request, so it is not a “mere conduit” — that exception is narrow, covering transient transport without access to the data. We sign a BAA. Treat this as our reading rather than settled law, and confirm it with your own counsel.
§164.312(a)(2)(i) is a Required specification: assign a unique name or number to identify and track each user. Crucially the rule covers software programs, not just people, so an agent counts as a user. A shared service account fails this — it makes attribution, activity review and per-identity revocation impossible, because every agent looks like the same actor.
The 2025 NPRM proposes making all implementation specifications mandatory and adding requirements such as MFA, encryption and audit logging. As of June 2026 it is not finalised — the current rule text is unchanged — so treat it as proposed direction, not requirement. A deployment already enforcing unique identity and audit logging is positioned for the proposed changes if they land.
| Default setup | Through the gateway |
|---|---|
| One shared upstream API key on every laptop | Per-person scoped grant tokens, revocable individually |
| No record of what agents called | Per-call audit log: grant, tool, argument keys, rule, verdict |
| Every tool on a server is callable | Deny-by-default — each tool and argument explicitly granted |
| Access rules scattered across client configs | One central, version-controlled policy |
PolicyLayer doesn’t certify your organisation — it gives your compliance team enforceable controls and exportable evidence for the MCP slice of the audit.
Last reviewed 04-06-2026 by the PolicyLayer research team. This guide maps how the framework intersects with MCP deployments — it is not legal advice.
Per-person grants, deny-by-default policy and a per-call audit log — the HIPAA evidence for the MCP slice of your programme. Live in minutes.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.