HIPAA Audit Logging for OpenAI Agents SDK Traces When Zero Data Retention Is Enabled

Separate three concerns that are often conflated

Teams building agents on the OpenAI Agents SDK for healthcare workloads tend to merge three different things. The first is provider-side data retention: what the model provider stores about requests and responses. Zero Data Retention exists to reduce that exposure. The second is SDK trace data: the telemetry an agent runtime produces to help developers debug and inspect runs. The third is the regulated entity's own audit record: the evidence that the covered entity or business associate keeps to show what happened in a system that uses ePHI.

These have different owners and different purposes. Zero Data Retention is a data-handling control. It narrows where PHI may persist outside your boundary, which is useful, but it says nothing about whether you can later demonstrate who invoked an agent, which tools it called, and what was allowed. Treating it as an audit solution creates a gap. The inverse mistake is also common: turning on verbose application logging to close the gap and quietly creating a new store of prompts and tool payloads that now holds PHI and needs its own protection, retention and access controls.

The practical design rule is that your audit record should not depend on whatever trace data a provider or SDK does or does not retain. Generate your own record, in your own environment, and treat any SDK trace output as an optional supplementary input.

What 164.312(b) asks of agent activity

The standard is short. As currently published in the eCFR, 45 CFR 164.312(b) requires covered entities and business associates to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. As of November 2026, that text is unchanged. HHS proposed amendments to the Security Rule in January 2025 that would describe records of activity by persons and technology assets, including audit trails, event logs and system logs. That is a proposal, and the current standard remains the one to build against.

The Security Rule also includes a required implementation specification for information system activity review: procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports. Recording is therefore only half the obligation. Someone must examine the records on a defined schedule.

The rule does not prescribe a format, a field list or an agent-specific method. NIST SP 800-66r2 frames the scope of audit controls, the content of records and the frequency of review as decisions driven by the entity's risk assessment. It asks which activities will be audited, such as creating, accessing, modifying, transmitting or deleting ePHI, what each record should include, such as the responsible user, event type and time, and where audit information will reside, for example on a separate server. For agents, that means your risk assessment decides which model interactions, tool calls and policy decisions are in scope, and you should document the reasoning.

What an agent audit record should contain

The sources behind NIST guidance support a baseline of the responsible user or identity, the event type, and the date and time. The NCCoE concept paper on software and AI agent identity adds the non-human agent identity, visibility of the action and its outcome, and the provenance of prompts and data input sources. No regulation defines a schema for tool calls or policy decisions, so the field set is a design choice that your risk assessment should justify.

A reasonable record for one interaction or tool call includes the accountable human or service identity, the agent identity, the event type (model interaction, tool read, tool write), the timestamp, the target system or tool, the policy that applied, the decision (allow, redact, block, escalate), and the redaction outcome, such as which categories of PHI were detected and removed. Where a human approved an escalation, record the approver and time. Include a reference to the input source so provenance can be followed.

The tradeoff is detail versus exposure. More content makes investigation easier but turns the store into a PHI repository. Storing categories, counts and references instead of values preserves most of the evidentiary value. If a specific use case requires content capture, treat that as an exception with its own justification, access restrictions and retention rule.

Where runtime policy enforcement produces the evidence

Evidence is strongest when it is a byproduct of enforcement rather than a separate recording step. If policy is enforced at runtime in the execution path, every allow, redact, block or escalate decision already exists as an event, and the record of that decision is the audit evidence. There is no gap between what was permitted and what was recorded, and no dependence on after-the-fact review to learn what happened.

Trussed works this way. It enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. The audit-ready evidence that enforcement generates is mapped to HIPAA, including 164.312(b) audit controls. It deploys self-managed in the customer cloud with configurable retention and data residency, so the evidence store sits inside the regulated entity's own boundary. Trussed runs in production with healthcare organizations.

Whatever you choose, evaluate any approach on the same criteria: does it capture each interaction and tool call, does it record the decision and not only the request, can it avoid storing raw PHI, and does it run where you control retention and residency.