What a reviewer means by HIPAA AI agents PHI access
A support lead asks to point Claude at the help desk. That help desk holds patient names, appointment dates and claim numbers. Compliance opens a file, and the questions in it come from the business associate agreement (BAA), the contract that binds a vendor handling protected health information on your behalf.
A HIPAA AI agents PHI access review is an access review, not an AI review. The reviewer wants to know who can reach electronic protected health information (PHI), through what path, and what record survives afterwards. An AI client is a new actor in that path. It is not a new category of question.
Two definitions, because the rest depends on them. MCP (Model Context Protocol) is the standard way an AI client calls external tools. Elaichi is a governed MCP control plane: each SaaS account is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint, POST /mcp, behind OAuth. OAuth here means the client signs in and holds a grant, so there is no per-user server URL and no token pasted into a client config.
Settle one thing before the four questions. This post makes no certification claim. Elaichi publishes what it attests to on the Trust Center at /security/, and anything you carry into your own compliance file should be attributed to that page. Signing a BAA with every vendor in the path is still your work.
Question one: is the agent held to the minimum necessary?
Restrictions and frozen parameters are where minimum necessary is decided in Elaichi. Both are enforced server-side, so neither depends on the model choosing to behave.
Restrictions govern which connectors and which individual tools a target may reach. Targets are a role or a user. There is no organization target. The organization default is the absence of any rule, which means allow-all. "We have not written a rule yet" is a real state with a real meaning for a reviewer.
Precedence runs user override, then role rule, then organization default. A user-targeted rule replaces role rules entirely rather than layering on top of them. Within the winning layer, allow rules union, block rules union, and blocks always beat allows.
the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. An allow rule that names nothing therefore denies everything. It is the strictest thing you can express, and it does not look strict on the screen.
Blocks match the tool name or the pinned operation. Allows match the pinned operation only, because a tool's advertised name is a label whoever edits the connector controls. Governance binds the operation, never the label, and why a block matches the name and an allow matches the operation works through the reasoning.
Frozen parameters are the narrower instrument. A frozen key is stripped from the advertised schema, so the model never sees it. The frozen value is merged over caller arguments at execution, so passing the key cannot un-freeze it. Precedence is entry defaults, then caller arguments, then frozen parameters. In a PHI setting that is how you pin a call to one clinic, one queue or one record type, and put the pin out of the prompt's reach.
Enforcement runs at four points against the same resolver: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.
Question two: does the record satisfy 45 CFR 164.312(b)?
45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems containing or using electronic PHI (eCFR, 45 CFR 164.312). The Elaichi audit trail answers the recording half directly, with one limit a reviewer should hear from you rather than find alone.
Every tool-call attempt writes one entry, succeeded or failed. Each entry names the account actually reached, taken from the execution rather than from the intent. "Which of our two workspaces did the agent write to" is the first question after an unexpected change, and the record answers it.
actor_kind is a field, not an inference. Its values include user, system, staff, scim, api_token and ai_assistant. Whether an action was taken by an AI is written down at the point of action.
Recorded per call: the operation and tool, the connection, the classification, whether the call was approved, the outcome, and an error code. Argument names and counts are logged. Argument values never are.
That cuts both ways, and it is the sentence to put in the file. A reviewer asking whether PHI can leak out through the log pipe gets a clean answer. A reviewer asking what the agent typed into a patient note gets nothing from Elaichi, and has to read the downstream system's own record.
The error-text firewall is the other half of that answer. Two error strings exist per failed call. The one returned to the caller derives from the third party's response body and is never written anywhere else. The one written to the audit trail is never derived from the request or the response, because audit records are organization-visible, readable by the in-product assistant, and fanned out to whatever SIEM the customer configured.
The practical shape: one record form for audit events and application logs, append-only, newest-first, cursor-paginated, filterable by free text, category, actor, action kind and time. There is one log tenant per organization, enforced in the type system rather than by a WHERE clause. The trail is eventually consistent, so a row may take a moment to appear. Export forwards to a destination you own, where Datadog is implemented and Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. A reviewer does not need a paid seat, because Auditor is a free read-only role.
Question three: who cleared this person for the system?
Workforce clearance under 45 CFR 164.308(a)(3)(ii)(B) asks that access be appropriate to the person's job (eCFR, 45 CFR 164.308). Three layers carry that in Elaichi, and keeping them distinct is what makes the answer defensible.
Permissions come from exactly one role per member, enforced by a unique index. Every role is a complete persona, so there is no stack of additive grants for a reviewer to reconstruct. Guest, Auditor and Billing Admin lack tool:execute, which gates the whole endpoint ahead of every scope. Without it tools/list is empty and a call returns an in-band error naming the missing permission.
Sharing is the second layer, and it is deliberately separate. A member sees only what they own or what was explicitly shared with them, as a grant of view, use or edit to a user, a team or the organization. No organization-level permission silently widens a listing, owners and admins included.
Restrictions are the third layer. They answer what a cleared person may reach, rather than who they are.
Clearance has an upstream too. SAML and OIDC SSO are built in-house, with SCIM v2 for users and groups and group-to-role mapping, so the persona a member gets can follow the identity-provider group that already governs the PHI system. Sign-in also supports TOTP MFA with single-use recovery codes, and passkeys. One permission deserves its own line in the file: connector:create is flagged high trust, because a custom connector can be pointed at any destination.
One correction for the write-up. A role change or a restriction change takes effect within about two minutes, not on the next call. Write two minutes.
Question four: what happens on the day someone leaves?
Termination procedures under 45 CFR 164.308(a)(3)(ii)(C) ask how access ends. removing or suspending a member revokes every live grant in the same transaction as the membership change, and revoked_at is re-read from the organization store on every single call. For removal and suspension, "the next call" is accurate.
Offboarding in Elaichi runs a preflight, and that is the part worth describing to a reviewer. A personal connection referenced by a toolbox entry has to be resolved first: transferred to the organization, a team or another member, or deleted. Otherwise the removal is refused. Unreferenced personal connections are cleaned up on the way out.
A private connection is not transferable at all. A credential only its owner could ever use does not become somebody else's because its owner left. Delegated toolbox entries surface as a non-blocking warning instead, and re-pinning the entry is the fix rather than a decision about credentials.
Contractors deserve their own pass, since their accounts tend to outlive the engagement. There is a working sequence in what to do about contractor AI access today.
One honest line for the BAA response. Deleting an organization tears down the rest of the workspace but has no path to purge that organization's log tenant, and the deletion returns the residue by name. Do not write "deleted, with a documented log-tenant residue".
Where the credentials sit, and who holds the key
Not in the control plane. Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing silently.
A connect URL is not a credential. It is a one-time session that carries no token, which is why it is safe to return over MCP. Reading back an account's configuration returns public values plus secret_paths, the list of dot-paths that were encrypted, carrying none of their values. Editing one is refused, and the refusal text is identical whichever side produced it, so a caller cannot tell which side refused.
Two options a reviewer usually asks for by name. BYOK is per-organization envelope encryption with a customer-managed key in AWS KMS. BYOA lets an organization supply its own OAuth app per connector, gated on connector:manage rather than connection:manage, so everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app.
What a governed MCP endpoint cannot answer for you
Four gaps, and a reviewer will find all four eventually.
Prompt injection is the first. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold at the endpoint: RBAC per operation, the forbidden classification that is reachable under no OAuth scope, output redaction, scope limits across mcp:read, mcp:write, mcp:destructive and mcp:tools, and full audit logging. A connected tool whose method is a delete needs mcp:destructive as well as mcp:tools.
The content of a write is the second. Argument values are not stored, so Elaichi cannot show a reviewer the text an agent sent.
Residency in Asia is the third. The eu and us regions are hard residency, a jurisdiction that holds compute and storage together. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Region also selects which regional log instance the audit trail lands in.
Certification is the fourth. Nothing in the product asserts a certification on its own authority. Any statement you make about one comes from the Trust Center at /security/, attributed to that page.
When the honest answer is not to connect the system at all
Some reviews should end with no connector, and saying so early saves a quarter. If the only reason an agent would touch the PHI system is convenience for one person once a month, a control plane is one more vendor in a regulated path for very little return. Keep the export or the read-only report you already have.
The same holds if nobody is pointing AI clients at company data yet. That is a policy and monitoring problem first, and the case is laid out in the post on not needing an MCP gateway yet.
If the PHI system is not in the catalog and somebody proposes authoring a custom connector to reach it, treat that as its own review item. connector:create is high trust for a reason, and a custom connector pointed at a clinical system changes your PHI map.
Where the review ends in a yes, the next two decisions are who runs the server and which team goes first. On the first, see the comparison of self-hosted MCP servers and a managed control plane. On the second, Compliance is one of the twelve teams on /use-cases/, and /connectors/ lists the 450+ you could govern.
