What does a BAA review ask about AI agents and PHI?
AI agents and PHI meet in an access review, not in a new kind of review. A business associate agreement (BAA) reviewer asks the same four things about an AI client as about any other path to protected health information (PHI). Access has to be held to the minimum necessary, activity has to be recorded, the person has to be cleared, and access has to end when they leave.
The file usually opens with a request. A support lead wants Claude pointed at the help desk, and that help desk holds patient names, appointment dates and claim numbers. The questions come from the contract. A covered entity may let a business associate handle electronic PHI only after obtaining satisfactory assurances that it will be safeguarded (eCFR, 45 CFR 164.308). The contract then has to commit the business associate to the Security Rule's safeguards, to reporting security incidents, and to binding its own subcontractors (eCFR, 45 CFR 164.314).
Some vocabulary first, because the rest depends on it. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps (MCP specification). Elaichi is a governed MCP control plane: each SaaS account is connected once, and its tools are served through one organization-wide MCP endpoint, POST /mcp, behind OAuth. OAuth here means each member signs in from the client and holds a grant, so no per-user server address or pasted token sits in a client config.
Settle one thing before the four questions. Elaichi states it is HIPAA compliant, as its Trust Center, linked from /security/, does. Anything you carry into your own compliance file should be attributed to that page. A Business Associate Agreement is not offered by default. Signing a BAA with every vendor in the path is still your work. For the reviewer's side of the file, NIST's HIPAA Security Rule guide offers practical guidance for regulated entities of every size (NIST SP 800-66 Rev. 2).
Question one: is the agent held to the minimum necessary?
It can be, once the rules are written, and in Elaichi they live in two places: restrictions and frozen parameters. Both are enforced on the server, so neither depends on the model choosing to behave.
Two standards meet here. The Privacy Rule asks for reasonable efforts to limit PHI to the minimum necessary for the purpose (eCFR, 45 CFR 164.502). The Security Rule's access-control standard allows access only to persons or software programs that have been granted access rights (eCFR, 45 CFR 164.312). A reviewer will read an AI client as one of those software programs.
Restrictions govern which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So "we have not written a rule yet" is a real state with a real meaning for a reviewer: everything is open.
A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, allow rules combine, block rules combine, and a block always beats an allow. Note that the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. It is the strictest thing you can express, and it does not look strict on the screen.
Blocks match the tool's name or the operation recorded when the rule was written. Allows match that 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 removed from the schema the model is shown. Its value is laid over whatever the caller sends at execution, so naming the key in a call cannot undo the pin. In a PHI setting, that is how you hold a call to one clinic, one queue or one record type, out of the prompt's reach.
Enforcement runs against the same resolver at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file.
Question two: does the record satisfy 45 CFR 164.312(b)?
Elaichi records each call that reaches execution, but not what an agent wrote, and the difference matters here. The audit-controls standard asks for mechanisms that record and examine activity in systems that contain or use electronic PHI (eCFR, 45 CFR 164.312). Elaichi answers the recording half directly, with one limit a reviewer should hear from you rather than find alone.
Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The account on that entry is the one the call landed in, read from the execution rather than from the request. So "which of our two workspaces did the agent write to" has an answer in the record. Who acted is a stored field, actor_kind, rather than a guess made later. Its values include user, scim, api_token and ai_assistant, which marks only the Elaichi Agent. A call from Claude or ChatGPT is recorded under the person who signed in, with surface mcp and the OAuth client named.
Beside the account, each entry carries the operation and tool, the classification, the approval decision, the result, and for a failure an error code only. Of the arguments, it keeps the one path argument that names the object, as the target id, and nothing else about the arguments.
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.
Failed calls get the same care. Two error strings exist for each one. The string returned to the caller comes from the third party's response and is never written anywhere else. The string in the audit trail is never derived from the request or the response, because audit records are visible across the organization, readable by the in-product assistant, and can be forwarded outside Elaichi.
The trail is append-only, newest-first and filterable by free text, category, actor, action kind and time. One organization's audit history is kept apart from every other organization's, 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. It is on Gold. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon; Splunk HEC and Microsoft Sentinel are accepted as destinations, but Elaichi delivers events only to Datadog.
The Security Rule also asks for regular review of activity records such as audit logs (eCFR, 45 CFR 164.308). That review needs no paid seat, because Auditor is a free read-only role.
Question three: who cleared this person for the system?
Three layers carry the answer in Elaichi: a role, sharing and restrictions. Workforce clearance under 45 CFR 164.308(a)(3)(ii)(B) asks for procedures that determine a workforce member's access to electronic PHI is appropriate (eCFR, 45 CFR 164.308). Keeping the three layers 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, the permission that gates the whole endpoint ahead of every scope. Without it, the tool list is empty and a call returns an 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 that person is.
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. A member's role can therefore 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. Removal and suspension hold from the next call.
Question four: what happens on the day someone leaves?
For removal and suspension, access ends on the next call, and a preflight settles what happens to the person's connections. Termination procedures under 45 CFR 164.308(a)(3)(ii)(C) ask how access to electronic PHI ends when employment or another arrangement ends. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is re-read from the organization store on every single call.
The offboarding preflight is the part to describe to a reviewer. It lists every connection the departing member owns. A private connection that a shared toolbox relies on blocks the removal until an admin transfers it to one other active member or deletes it. A transfer never goes to the organization, to a team, or to the admin running the removal. A private connection that nothing beyond the member depends on cannot be transferred and is deleted with them.
A shared connection a team still depends on is deleted only if the admin explicitly asks. Otherwise the admin transfers it to a member who is staying, which leaves every grant on it exactly as it was. Delegated toolbox entries surface as a non-blocking warning, 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 workspace and deletes every connector credential. Three stores keep residue, and the deletion names them: the audit history, the analytics events, and the credential service's organization, environment and installed-connector configuration rows. Deletion does not purge the audit history. Each record ages out under the log server's 90-day retention, counted from when it was written. Describe it that way, as deletion with three documented residues, and never as total erasure.
Where do the credentials sit, and who holds the key?
Not in Elaichi. Connector credentials live in a separate credential service that holds per-account secrets, AES-256-GCM at rest, and owns refresh. Connections created since 2026-10-05 have their credentials placed in the organization's region, by best-effort placement for APAC. Older connections stay where they were until reconnected, which copies them into the region. 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, with 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 means per-organization envelope encryption under a key you hold. In Elaichi, customer-managed keys in AWS KMS come with the Black plan, which is launching soon. BYOA lets an organization supply its own OAuth app per connector. It is gated on connector:manage rather than connection:manage, so the right to delete a connection never quietly includes the right to repoint the organization's OAuth app.
Which questions will Elaichi not answer for you?
Three, and a reviewer will find all of them 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. An MCP server never sees the user's prompt. What does hold at the endpoint: a permission check per operation, the forbidden classification that no OAuth scope reaches, output redaction, limits across the mcp:read, mcp:write, mcp:destructive and mcp:tools scopes, and an audit row for each call that reaches execution. A connected tool whose method is a delete needs mcp:destructive as well as mcp:tools.
The content of a write is the second. Elaichi stores no argument values beyond the target id, so it cannot show a reviewer the text an agent sent.
Certification evidence is the third. Any statement you make about a certification comes from the Trust Center linked from /security/, attributed to that page.
When should you leave the PHI system unconnected?
When the use is occasional, when nobody is pointing AI clients at company data yet, or when reaching the system would take a custom connector nobody has reviewed. 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 one person's convenience 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.
If nobody is pointing AI clients at company data yet, the problem is policy and monitoring first. That 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 a custom connector to reach it, treat that as its own review item. The permission behind it, 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 600+ connectors you could govern.
