How to Prove PHI Did Not Leave Your Firewall Through an AI Request

The firewall claim is an evidentiary burden

Most healthcare organizations assume that a perimeter keeps PHI inside. In an OCR inquiry or breach investigation that touches AI, that assumption has to become evidence. The question is not whether a boundary exists. It is whether you can show, for a specific prompt, tool call or model response, that PHI did not reach an external model, tool or MCP server.

The usual artifacts fall short of that. A network diagram shows intended topology. Application logs show what an application recorded, often after the fact and often without the policy that applied. A vendor attestation describes the vendor's practices, not your individual requests. None of these shows what was allowed, redacted or blocked for one interaction.

The paths matter. PHI can leave through external model APIs, agent tool calls, MCP servers, browser-based AI sites and coding assistants. A single control point at the network edge may not see the content or intent of each of those requests, so the evidence it produces is partial.

What the Security Rule asks you to evidence

The HIPAA Security Rule standards in 45 CFR Part 164 Subpart C apply to all electronic protected health information, including 164.312 on technical safeguards. As of November 2026, that scope is the starting point for any AI-related inquiry. How each provision applies to prompts, tool calls and model responses is an interpretation, and counsel should review your mapping.

Audit controls, the subject of 164.312(b), are the most direct fit. A January 2025 Federal Register document on strengthening the Security Rule describes audit controls as crucial for recording and examining activity in electronic information systems, especially when determining whether a security violation occurred. It says an entity should weigh its risk analysis and technical infrastructure when choosing reasonable and appropriate controls. It also states that OCR's enforcement experience points to a need for more specificity in how the standard is understood and met.

The same document sets out transmission security language: technical controls that guard against unauthorized access to ePHI sent over an electronic communications network, reviewed and tested at least every 12 months or after operational change. Read together, these point to event-level evidence tied to a documented risk analysis, with control testing retained alongside the records.

What a boundary shows versus what a regulator needs

The gap is clearest when each artifact is compared with the question it can answer.

• Network diagram: Shows intended paths. Does not show which policy applied to a given request or whether PHI was in it.
• Application logs: Show what the application chose to record. Often lack the policy version, detection result and final destination.
• Vendor attestation: Describes the vendor's practices in general. Does not cover your individual interactions.
• Per-interaction evidence record: Shows the policy, detection, action and destination for one request or tool call.

Why enforcement in the execution path produces stronger evidence

Reviewing activity after the fact can tell you what happened, but only if the right data was captured. Enforcement in the execution path changes the sequence. The policy decision is made before the request leaves, and the record is a by-product of that decision. The evidence therefore describes what the control actually did, not a reconstruction of it.

For PHI, the decisions are straightforward. Allow a request that contains no PHI or that targets an approved internal destination. Redact identifiers when the task can proceed without them. Block a request that would send PHI to a destination that is not approved. Escalate to a named approver when a human decision is required. Each outcome is recorded with the same structure.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, and generates audit-ready evidence from that enforcement. It runs in production with healthcare organizations. The scope is individual interactions and tool calls. It does not provide business-transaction-level governance across tasks and agents, so questions about a full clinical or administrative workflow need other records.

Implementation path

The steps below move from definition to retrieval. Document the reasoning at each step in the risk analysis, since audit control choices are meant to follow from it.

• 1. Inventory AI data paths: List every point where AI requests are created, transmitted and recorded: model APIs, agent tools, MCP servers, browser AI sites and coding assistants. Note what each point can evidence today.
• 2. Define PHI policy: Specify what counts as PHI in prompts, tool arguments and responses, and which destinations are approved. Version the policy so each decision can cite it.
• 3. Place enforcement points: Put enforcement where requests pass, not beside them. Cover tool calls and MCP servers as well as direct model calls.
• 4. Set escalation authority: Name who can approve escalated requests, drawing on your existing list of personnel authorized to approve access to ePHI systems. Record the approver in the evidence.
• 5. Choose deployment, retention and residency: Deploy inside your own cloud so evidence stays in your environment. Set retention against the period counsel identifies, and set data residency to match your obligations.
• 6. Test retrieval: Run a mock inquiry: pick a request and produce its full record. Retain the results with the control records and repeat at least annually or after change.

What a defensible evidence record contains

A record is defensible when it answers a regulator's likely questions without further reconstruction. A practical design includes a request identifier, timestamp, user or application identity, the policy version applied, the detection result, the action taken (allow, redact, block or escalate), the destination, and the approver where a request was escalated. This field set is a design recommendation, not a regulatory list.

Integrity and retention need equal attention. Store records so that alteration is detectable, and keep them in a system separate from the application they describe. A January 2025 Federal Register document describes retaining certain required documentation for the later of six years from creation or the date last effective. Which AI records fall under that period is a question for counsel, but designing for long retention is cheaper than extending it later.

Self-managed deployment in the customer cloud lets you hold the evidence in your own environment, with configurable retention and data residency. That matters in an inquiry because the organization, not a third party, controls access to the record. Evaluation documentation should also capture findings, remediation decisions and any accepted risk with its justification, so AI-related decisions sit in the same trail.