Daylite is the runtime enforcement and verifiable audit layer for AI agents in regulated enterprises. It is a self-hosted Rust binary that sits at the MCP tool-call boundary. It checks each agent action against policy before the action runs and decides whether it executes, then writes a tamper-evident, cryptographically signed record of what was requested, what policy decided, and what actually ran. It deploys in your VPC, on-prem, or in an air-gapped network.

How is Daylite different from Vanta, Drata, Credo AI, or OneTrust?

Those tools document and score policy. They map it to frameworks and produce reports, and they sit out-of-band from the running agent, so they cannot block a non-compliant tool-call. Daylite enforces policy at the tool-call boundary at runtime and produces cryptographic proof of what the agent actually did. Keep your governance tool for documentation. Daylite sits beneath it.

What does 'built on FIPS-validated cryptography' mean?

Daylite runs its cryptography through AWS-LC, a FIPS 140-3 validated cryptographic library. Daylite itself is not product-certified under CMVP, and we do not claim a CMVP certificate. Commercial enterprise procurement under SOC 2, HIPAA, and DORA accepts library-level validation. FedRAMP High and certain DoD contracts require product-level CMVP, which is on the roadmap.

How does an auditor use the evidence?

Your team runs one command to export the record. The auditor verifies the hash-chain offline with the verify tool, confirms no entry was changed after it was written, and reviews the decisions. The format is open, so there is no lock-in on the evidence itself, and no trust in Daylite is required to check it.

Where does Daylite run, and where does the data go?

Daylite is self-hosted and air-gap capable. It runs in your VPC, on-prem, or in a disconnected network. Data never leaves your environment. That disqualifies cloud-only governance tools in banking and defense, and it is why Daylite fits where they cannot.

How long does Daylite take to deploy?

Minutes. Docker ships today. Run the container, point your agents at the MCP proxy, and the policy gate and the hash-chain audit are live. A Helm chart for Kubernetes is on the roadmap.

July 29, 2026 · 10 min read

AI agent audit trail requirements: what SOC 2, HIPAA and DORA actually ask for

Ask three compliance leads what an AI agent audit trail must contain and you get three answers, because the frameworks behind them ask for different things. SOC 2 wants your controls to operate as described. HIPAA wants activity in systems with ePHI recorded and examined. DORA wants an ICT risk framework that can detect, respond, and report. An agent that reads data, calls tools, and takes actions touches all three at once.

This article separates what each framework actually says from what reviewers and examiners ask for in practice. The gap between those two is where deals stall.

What makes agent audit trails different from application logs

A traditional application log records what your code did. An agent log has to record what a model decided to do, which is a harder question. The useful record answers five things for every consequential action: what was requested, what context the agent had, what policy allowed or blocked, what actually executed, and who or what authorized it.

Most logging stacks capture the fourth item and skip the rest. That is the root of most failed audit questions about agents. The reviewer does not want to know that an API call happened. They want to reconstruct why.

SOC 2: criteria, not prescriptions

SOC 2 does not contain the words "AI agent." It is built on the Trust Services Criteria, and the relevant ones are the monitoring criteria in the CC7 series: detect anomalies, evaluate security events, respond to incidents. Your auditor tests whether the controls you described operate consistently.

Two practical consequences. First, if your system description says agent actions are logged and reviewed, the auditor will sample for exactly that, so an agent that acts outside the logged path becomes an exception in your report. Second, SOC 2 says nothing about model versions, prompts, tool calls, or decision attribution, which is why buyers who receive your SOC 2 report still send an AI questionnaire. We covered that dynamic in the AI-CAIQ field guide: the report answers the organizational question, not the agent question.

HIPAA: audit controls reach whatever touches ePHI

The HIPAA Security Rule is short on this point. 45 CFR 164.312(b), Audit controls: implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Its companion, 164.308(a)(1)(ii)(D), requires regular review of information system activity records.

Neither provision prescribes a format or a retention period for the logs themselves, and that surprises people. The six-year retention rule in 164.316 applies to policies and documentation. What matters for agents is scope: an agent that queries a patient record or drafts a claim is activity in a system that contains ePHI, so the recording and review obligations follow it. A hospital security team will also ask who the actor was, which is where a shared service account fails you. The healthcare-specific version of this review is covered in the healthcare AI security review guide.

DORA: reconstruction under regulatory deadlines

DORA, Regulation (EU) 2022/2554, has applied to EU financial entities since January 2025. Article 6 requires a documented ICT risk management framework, and the detection and response provisions that hang off it assume you can identify anomalous activity and reconstruct incidents well enough to classify and report them on the regulation's timelines. Article 28 extends the discipline to ICT third-party providers, which is how the obligations land on AI vendors selling into banks and insurers: your customer must be able to answer for what your product did inside their estate.

For agents, the hard part is that reconstruction happens after the fact, under time pressure, and the examiner has no reason to trust a log the vendor or the bank could have edited. Evidence that carries its own integrity, where tampering is detectable by verification rather than by trust, is the difference between an incident report and an argument.

The common core: what to build once

The three frameworks converge on a single engineering target. Build it once and answer all three:

Record every consequential agent action: request, context reference, policy decision, execution result, authorizer.
Attribute each action to a distinct agent identity, not a shared account.
Make the record append-only and tamper-evident, so alteration is detectable.
Write a retention period into policy and enforce it mechanically.
Review the records on a schedule, and keep evidence that the review happened.
Be able to export the trail in a form an outside party can verify without trusting you.

Daylite exists because this list is easy to state and slow to build. It gates each agent tool-call against policy at runtime, then writes the decision into an append-only, hash-chained, HMAC-signed log that an auditor can verify offline. Self-hosted, so the record never leaves your environment. If you build your own layer instead, the list above is still the target the frameworks converge on.

FAQ

Does SOC 2 require a specific audit log format for AI agents?

No. SOC 2 is criteria-based, not prescriptive. Your auditor tests whether your monitoring and logging controls operate as you described them. The practical bar is set by what you commit to in your system description and by what enterprise buyers ask on top of the report, and buyers increasingly ask for per-action agent records that SOC 2 alone does not produce.

Do HIPAA audit controls apply to an AI agent?

If the agent creates, receives, maintains, or transmits ePHI inside a covered entity or business associate, the systems it touches sit squarely under 45 CFR 164.312(b), which requires mechanisms that record and examine activity in systems containing ePHI. An agent reading patient records is activity in such a system. The regulation does not care that the actor was a model.

How long do agent logs need to be kept?

It depends on the framework. HIPAA requires policies and documentation to be retained six years but does not name a log retention period, so covered entities set one in policy, and six years is a common conservative choice. DORA expects retention that supports incident analysis and reporting. SOC 2 expects whatever your own policy says, tested for consistency. Write the number down and follow it.

Is a normal application log enough for these frameworks?

Often for the letter of the control, yes. For the review that follows, increasingly no. A log you can edit proves little to a skeptical examiner, and agent incidents get investigated after the fact, sometimes months later. Tamper-evident records, where any change to a past entry is detectable, answer the question a mutable log cannot: has this history been altered?

Who is responsible for the audit trail, the AI vendor or the customer?

Both, split by boundary. The vendor must produce records of what its agents did inside the product. The customer must retain them, review them, and fold them into their own monitoring. In regulated deals the contract makes this explicit, so a vendor that can export complete, verifiable agent records makes its customer's side of the obligation cheap.

If an audit-trail question is sitting unanswered in a security review right now, the AI Security Review Kit turns a 30-minute intake into the full answer pack, mapped to the AI-CAIQ, NIST AI RMF, and ISO 42001.

Written by Dmitrii Karataev. Twenty years in infrastructure and security. Corrections welcome: hello@daylite.ai.