HIPAA Audit Controls for Self-Hosted n8n Agent Executions: What to Log

What 164.312(b) requires, and what it leaves to you

The audit controls standard is one sentence. It tells covered entities and business associates to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. It names no fields, no retention period, and no integrity mechanism.

The scope is set by your risk analysis. NIST SP 800-66, hosted by HHS, says the scope of audit controls should follow the covered entity's risk assessment and other organizational factors, and that the entity must determine what data needs to be captured. Its example of audit record content is user ID, event type, date, and time. The NIST HIPAA implementation guide adds activities worth considering: creating, accessing, modifying, transmitting, and deleting ePHI.

Recording is only half the standard. The information system activity review specification is marked Required and calls for procedures to regularly review records such as audit logs, access reports, and security incident tracking reports. A log nobody reviews does not satisfy the intent. A January 2025 proposed rule would add written policies for retaining and reviewing activity records. As of November 2026, the current 164.312(b) text is the operative standard, so treat the proposal as a reason to document these procedures now rather than as a requirement.

Debugging output is not audit evidence

Workflow execution data exists so engineers can see what happened inside a run. It typically stores node inputs and outputs, which is useful for troubleshooting and a problem for compliance. In a workflow with an agent step that handles clinical text, those inputs and outputs can contain PHI. The debugging store then becomes a second repository of ePHI with its own access and retention exposure.

Audit evidence has a different job. HHS describes audit trails as support for reviewing inappropriate access, tracking unauthorized disclosures, detecting intrusions, and providing forensic evidence in incident and breach investigations. That calls for event records with who, what, when, and outcome, held where they cannot be quietly altered by the people being audited.

There is also a gap in what a debugging record can show. It records what an agent did. An auditor will also ask what the agent was permitted to do and which rule applied when it acted. NIST SP 800-53 Rev. 5 lists access control or flow control rules invoked as possible audit record content, which supports recording the policy decision next to the action. Keep the two stores separate, with different contents, access lists, and retention settings.

A minimum audit record schema for agent executions

No source defines an AI-agent audit schema, so this one extends the NIST baseline of identity, event type, date and time, component, and outcome. Treating agent tool calls as privileged functions is a reasonable analytical step, since NIST SP 800-53 Rev. 5 includes logging the execution of privileged functions. Emit one record per execution start, model call, tool call, and decision point, each carrying a shared execution identifier so reviewers can group them.

• Identity: The human user, service account, or workflow identity that triggered the action, plus the agent identity that acted. Record the credential or role used, never the secret.
• Time and component: A timestamp from a consistent, synchronized clock, and the component where the event occurred, such as the workflow, node, model endpoint, or tool.
• Event type: Execution start or end, model invocation, tool invocation, data read, data write, or transmission. Include the model or tool name and version.
• Data access by reference: The data source and record identifier touched, not the PHI content. Add a data classification label and the number of records.
• Policy decision: Allow, redact, or block, the rule that applied, and the rule version. Record what the agent was permitted to do separately from what it did.
• Approval and outcome: The approver identity and decision where a human approved the action, plus success or failure. Denied and blocked actions need records too.

Keeping PHI out of the audit record

NIST SP 800-53 Rev. 5 notes that audit trails can reveal personally identifiable information and suggests limiting additional record content to what the audit requirement explicitly needs. Apply that to the three places PHI concentrates in agent runs: prompts, tool arguments, and outputs.

The default should be references over content. An ONC test method for audit logging gives a useful precedent: a log can record that a user accessed a medication list without recording the specific medication, and it can link to an original document rather than copy it. That criterion applies to certified health IT and is not a HIPAA mandate, but the design principle carries over. Log a patient record identifier, a document reference, a field name, and a size. Do not log the prompt text or the tool response.

Where a documented audit need requires content, capture the minimum, redact identifiers before writing, and record that redaction occurred. Hashes of content can show that two events involved the same input without storing it. Decide these rules once, in writing, so they follow from your risk analysis and are not left to each workflow author.

Integrity, access, retention, and review

The standard and HHS guidance do not prescribe tamper-evidence or a specific retention period, so these are design decisions you should justify and document. HHS does say covered entities and business associates should appropriately review and secure audit trails, which makes the audit store a protected system in its own right.

For integrity, write audit records to a store that workflow operators and agent runtime accounts can append to but not edit or delete. Hash chaining or signed batches make alteration detectable. Use one synchronized time source across components so events from different systems sort correctly. For access, limit read access to security and compliance roles, log reads of the audit store itself, and keep it apart from the debugging store.

For retention, set the period in your written policy and apply it by configuration, not by default pruning behavior. Confirm that the period you choose covers your documentation and investigation needs, and that deletion is deliberate. For review, define exception reports, such as blocked actions, off-hours executions, and unusually large record counts. Set the review frequency from your risk assessment, assign an owner, and test periodically whether the process actually catches problems. Self-hosting helps here because storage location, residency, and access are under your control.

Where runtime enforcement adds evidence

Workflow-level records can show that a tool ran. They are weaker at showing whether the action was allowed and under which rule. Enforcing policy in the execution path closes that gap, because the component that decides is the component that records.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, at the level of individual interactions and tool calls. Each action is allowed, redacted, blocked, rate limited, or escalated for human approval, and that decision produces audit-ready evidence mapped to HIPAA, including 164.312(b). It is enforced at runtime, not reviewed after the fact. Trussed deploys self-managed in the customer cloud with configurable retention and data residency, so the evidence stays inside your environment. It runs in production with healthcare and pharma organizations.

This covers the policy decision and action fields in the schema above. It does not replace your risk analysis, your review procedures, or your decisions about what to retain. A useful test for any approach is whether an auditor can see the allow, redact, or block decision, the rule applied, and the outcome for a given tool call, without reading PHI.