How to Redact PHI in an n8n AI Agent Before the LLM Call

Where PHI enters the data path

An AI Agent assembles each model request from several sources: the user's message, the system prompt, responses from tool nodes, content read from memory, and documents retrieved for context. Any of these can contain PHI. Redacting only the chat input leaves the other paths open. A tool that queries a patient record returns identifiers straight into the next model call as the agent loops, and a sub-workflow used as a tool can do the same.

Persistence matters as much as transmission. Workflow execution records and memory stores can retain node inputs and outputs. Design as though any stored node data is a PHI store, and place redaction upstream of it so that the stored copy is already redacted.

Minimum necessary guidance points the same way. Individually identifiable health information should be used or disclosed only to the extent needed for a specified purpose. For an agent, that means deciding which fields each tool may return and which the model call actually needs, before deciding how to mask them.

Place redaction at each entry point

Build the redaction step once, as a reusable sub-workflow or shared function, and call it from every path. Copies of ad hoc Code nodes drift, and a single missed branch sends raw text to the model. The placement below applies to each path.

• User input: Redact immediately after the trigger and before any node that stores, forwards or logs the message.
• Tool outputs: Redact each tool response before it returns to the agent, and restrict tool queries to the fields the task needs.
• Memory: Redact before writing, so stored history holds placeholders. Also check reads, since older entries may predate the control.
• Retrieved context: Redact chunks at retrieval or ingestion, and apply the step again when the prompt is assembled.
• Sub-workflows: Call the same redaction step inside every sub-workflow. Never assume the parent workflow already redacted.
• Failure handling: If detection errors or times out, block the call. Do not pass the original text through.

Detection techniques and where they fail

Pattern matching works for identifiers with fixed formats, such as phone numbers, email addresses and record numbers that follow a known layout. It misses names, locations and descriptive phrases in free text, which is where clinical notes and chat messages carry most of their identifying detail. NER-based detection covers more of this, but automated rule-based and machine learning methods are documented as struggling to generalize across diverse data types and needing large volumes of labeled examples. Clinical text from a new specialty or a new note template can behave differently from the data a detector was tuned on.

Placeholder substitution, such as replacing a name with a typed token like [PATIENT_1], reduces leakage risk and keeps the prompt coherent for the model. If outputs must be re-identified, store the mapping separately, restrict access to it, and restore values only in the response shown to an authorized user. Never restore them in text that returns to the model.

Removing direct identifiers can also be insufficient. Records have been re-identified by correlating them with other data sources, so test redacted output for linkage risk. HIPAA recognizes two ways to de-identify data so that it is no longer PHI. Decide which standard your workflow targets and record that decision.

The common failure modes are predictable: identifiers the detector does not recognize, free text with unusual phrasing, PHI re-entering through a tool response after input was already redacted, and a new branch or sub-workflow added without the redaction step.

Enforcing redaction policy in the execution path

Treating redaction as a runtime control means the policy decision happens in the path between the agent and the model, not in a prompt instruction and not in a review after the fact. A prompt that tells the model to ignore identifiers does nothing about what has already been transmitted.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Actions are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to HIPAA, and Trussed can be self-managed in the customer cloud with configurable retention and data residency. It runs in production with healthcare and pharma organizations.

This does not remove the detection limits described above. Whatever detector sits behind the policy still needs validation on your own free text. What changes is that the control is applied the same way on every interaction, and the proof comes from the control itself rather than from reconstruction later.