Continuous Compliance & Audit
In Lightspeed the audit trail is not a log written beside the agent. It is the agent's state. And compliance becomes continuous when the checker is an agent that never stops.
Every audit of an automated system asks the same question: show us what it did, and show us why. For most agent deployments the honest answer is a folder of chat transcripts and a logging pipeline someone promised to keep in sync with the code. Lightspeed’s answer is structural. There is no audit trail beside the agent: the audit trail is the agent.
The record is the state
A Lightspeed session is an event log. A user message, a model response, a tool call, a tool result: each is validated at the admission boundary, recorded as an event, and only then applied. The agent’s state is nothing but a replay of that log. The core is deterministic, so replaying the events reproduces exactly what the model was shown at every step and the step the decider chose next. Nothing is reconstructed after the fact, nothing is sampled, nothing depends on a logger being configured.
The log lives in Lightspeed’s own PostgreSQL event store, separate from the workflow engine’s history, so it survives worker restarts, redeploys and the multi-week lifetimes long sessions have. Large payloads, the full context sent to the model, tool output, provider-native data, are stored in content-addressed storage and referenced from the log by hash: the record and its payloads cannot drift apart. A closed session can be deleted; a session whose history a fork still inherits cannot, so a lineage never loses its root.
Who asked
Each command carries the principal that issued it, resolved at the gateway and recorded with the event, scoped to its universe. Credential use is recorded as well: retrievable grants are leased at the execution boundary and every lease is counted. Sub-agents carry typed lineage back to the session and the human that started them. So the three questions a reviewer needs answered, who asked, what was the agent shown, what did it do, are answered from one store, per tenant.
What the auditor sees
Consider a reconciliation agent that ran for a quarter. Its log holds every message it received from the controlling workflow, every model turn including the provider’s reasoning where the provider exposes it, every tool it called with the environment it called it on, every result, every cancellation and every steer an operator sent. Replaying that log reproduces the quarter’s decisions exactly, without calling a model at all. Re-running the same cases in the eval harness with a new prompt or a new model shows precisely which decisions would change. That is the difference between “we believe the agent did the right thing” and a demonstration.
Continuous
Audit looks backwards; compliance under DORA and its national cousins is a standing obligation, and standing obligations are what long-lived agents are for. A resident compliance agent is a managed session with a schedule trigger: every night it borrows a machine, runs the control checks against the live systems using credentials injected into that machine and never shown to the model, writes its findings into a virtual file system that outlives the machine, and posts a summary to the channel where the control owner lives. Triggers are deduplicated and budgeted per day, and schedules are reconciled to the workflow engine’s own scheduler with overlapping runs skipped rather than stacked, so a duplicate event never runs twice. The findings are files in a virtual file system that keeps snapshots, and the run that produced them is itself in the event log.
The agent that checks the controls is subject to the same controls. Its runs are bounded by deadline and budget, its tools are bound immutably by the workflow that owns it, and its own log is the evidence that the check happened.
The stack an auditor can read
The core is Rust, the runtime is Temporal, the stores are PostgreSQL and S3-compatible object storage, and the whole of it is Apache 2.0. An auditor who wants to know how the event log is written can read the code that writes it. A bank that must run inside its own perimeter can, down to the model, by pointing sessions at a vLLM endpoint on its own hardware.
Read next: Govern Long-Running Agents for the controls the evidence sits inside, and Secure Agent Fleets for the boundaries.
Rests on: auditable by design, durable by design, universe-owned auth, encrypted secrets, credential injection, virtual file system, channels, managed sessions.