Compliance and audit trails for AI

In regulated settings, it isn't enough for an AI agent to do the right thing. You have to be able to show what it did and what it knew when it did it, after the fact, to someone who wasn't there. An agent that produces good outcomes but leaves no reconstructable record is a problem waiting to happen, because the question "what did the system do, and why?" will eventually be asked by an auditor, a regulator, or a court.

This page is for developers building agents in regulated industries who need that record as infrastructure. Exabase Memory gives every memory a timestamped creation and modification history, and Bases enforce data isolation between clients or cases, so the agent's knowledge is both traceable and properly separated. The result is an infrastructure layer that makes agents auditable.

A scope note up front, because it matters here more than anywhere. This page is about infrastructure that supports auditability and isolation. It is not a claim that using Exabase makes a system compliant with any particular regulation. What compliance requires depends on your jurisdiction, your industry, and your specific obligations, and determining whether a deployment meets them is a matter for your own compliance and legal review. What's described below is what the infrastructure provides; mapping that to your regulatory requirements is your responsibility.

The problem

Auditability and isolation are both hard to bolt on after the fact, which is exactly when teams usually try to. An agent built without an audit trail produces results with no record of the reasoning or the data behind them, and reconstructing that later, when it's demanded, is somewhere between painful and impossible. The trail has to be there as the agent works, capturing what it knew and when, or it doesn't exist when you need it.

The "what did it know, and when" part is genuinely subtle. An agent's knowledge changes over time as facts update, so an honest audit trail can't just show the current state, it has to be able to establish what was true at the moment of a past action. A store that overwrites old facts with new ones loses exactly the history an audit needs. Keeping both the current picture and the record of what changed when is a real requirement, and a naive log either grows into something unnavigable or fails to preserve the temporal truth.

Isolation is the other half. In regulated work, one client's or one case's data bleeding into another's isn't a quality issue, it's a breach. Isolation that depends on every query remembering to filter correctly is isolation waiting to fail, and "we filter by client ID" is not an answer that survives scrutiny when the stakes are regulatory. The separation has to be structural, so that cross-contamination isn't a risk you mitigate but something the architecture prevents.

What Exabase unlocks

With timestamped memory and structural isolation underneath, an agent's behaviour becomes reconstructable and its data properly separated.

Every memory has a history. Creation and modification timestamps mean you can establish what the agent knew at the point it acted, not just what it knows now, so a past action can be examined against the state of knowledge that informed it. The audit trail builds itself as the agent works rather than being assembled afterward from whatever fragments survived.

The current picture and the historical record coexist. Because memory resolves contradictions while preserving timestamps, the agent reasons from the current state in operation, while the trail still shows what was true earlier and when it changed. You get an agent that behaves correctly and a record that explains how, rather than having to choose.

And data stays isolated by construction. Bases keep each client's or case's data in a sealed environment, so separation is a property of the architecture rather than a filter that has to be applied correctly every time. One case's data cannot surface in another's, because operations scoped to a Base can only see that Base. Data is also encrypted at rest using AES-256.

How it works

Two primitives carry this: Memory for the timestamped trail, and Bases for the structural isolation.

Memory

Exabase Memory provides the audit trail as a property of how it stores things. Every memory carries creation and modification timestamps, so the history of what the agent knew is recorded inherently, not as an extra logging step you build. Because memory resolves contradictions through entity resolution while keeping that timestamped history, you can both see the current state and reconstruct what was true at an earlier point, which is the combination an audit needs. This is a different thing from storing raw logs: a log records events without keeping a coherent, queryable picture, whereas the memory layer maintains both the current state and its history. The distinction is the one drawn in why a vector database is not a memory system.

Bases

A Base is the isolation boundary. Each client, case, or matter gets its own Base, a fully isolated environment whose memory, storage, and search contain only that one context. The isolation is structural: an operation scoped to a Base can only ever access that Base, so cross-contamination between clients or cases isn't something you guard against with careful filtering, it's something the architecture doesn't permit. Creating a Base is a single API call, so per-client or per-case isolation scales without a partitioning scheme of your own. This is the same isolation primitive described in multi-tenant memory for SaaS, applied where the stakes are regulatory.

Example architecture

The structure is per-context isolation with an inherent timestamped trail.

One Base per client or case. Each regulated context, a client, a matter, a case, gets its own isolated Base, so its data is structurally separated from every other.

Capture as the agent works. As the agent acts, its knowledge and the context behind its actions go into Memory within that Base. The timestamps are recorded inherently, so the trail forms as a byproduct of operation rather than a separate effort.

Reconstruct when required. To answer what the agent did and knew, retrieve memory and use the creation and modification timestamps to establish the state of knowledge at the relevant time.

Keep contexts sealed. Because each Base is isolated, an audit or operation in one client's context touches only that context, with no risk of exposing another's data.

Each regulated context lives in its own sealed Base, the agent's knowledge accrues there with inherent timestamps, and the trail is reconstructable on demand. Auditability and isolation are properties of the infrastructure rather than features layered on top.

What compounds over time

The value of building auditability in from the start, rather than retrofitting it, grows with every action the agent takes.

An audit trail that's captured inherently becomes more complete and more valuable over time, a full, timestamped history of what the agent knew and did, available whenever it's needed. Because the trail forms automatically, there's no growing backlog of un-logged actions and no point at which someone has to reconstruct missing history. Contrast that with retrofitted auditing, where the record is only as good as the gaps people remembered to fill, and where the absence of early history can't be repaired.

The isolation compounds in reliability rather than volume. A structural boundary doesn't get more fragile as you add clients, cases, or features, because individual operations can't weaken a separation they don't control, whereas hand-built filtering gets riskier with every new query and every new engineer. As a regulated system grows, building on infrastructure where the trail is inherent and the isolation is structural means the properties that matter most hold steady rather than degrading, which is the opposite of what happens when auditability and isolation are things you maintain by hand.

Who's building this

Developers building AI agents in regulated industries, financial services, healthcare, legal, and anywhere actions must be explainable and data must be separated by client or case. It's for teams who know that "the agent did the right thing" won't be a sufficient answer, and that they'll need to show what it did, what it knew, and that one client's data never touched another's.

The closest neighbour is decision trace infrastructure, which captures the reasoning behind decisions for the same auditability, from the operational rather than the regulatory angle. Healthcare agents and legal AI agents apply this in specific regulated domains, and multi-tenant memory for SaaS covers the isolation primitive in general.

Get started

Start with the getting started guide, then about Bases and creating Bases for isolation, and about memories and retrieving memories for the timestamped trail. There's a free tier to build against. As with any regulated deployment, whether the infrastructure meets your specific obligations is a question for your own compliance and legal review.

FAQs

Does using Exabase make my system compliant?

No. Exabase provides infrastructure that supports auditability and data isolation, timestamped memory history and structural per-context separation. Whether a given system is compliant with a particular regulation depends on your jurisdiction and obligations and is a determination for your own compliance and legal review. The infrastructure supports compliance work; it doesn't constitute it.

How do I establish what an agent knew at the time of a past action?

Every memory carries creation and modification timestamps, so you can reconstruct the state of the agent's knowledge at an earlier point rather than only seeing the current state. The memory layer keeps the historical record even as facts are later updated.

How is the audit trail different from just keeping logs?

Logs record events but don't maintain a coherent, queryable picture of what the agent knew. Memory keeps both the current state and its timestamped history, resolving contradictions while preserving what was true when, so the trail is reconstructable and navigable rather than a flat event stream. See why a vector database is not a memory system for the underlying distinction.

How is one client's or case's data kept separate?

Each gets its own Base, a structurally isolated environment. An operation scoped to a Base can only access that Base, so cross-contamination isn't prevented by careful filtering, it's prevented by the architecture. Data is also encrypted at rest using AES-256.

Is the audit trail something I have to build on top?

No. The timestamps are an inherent property of how Memory stores data, so the trail forms as the agent works rather than requiring a separate logging system. You capture the agent's knowledge into memory as normal and the history is recorded with it.

What's the difference between this and decision trace infrastructure?

They're two angles on the same auditability. Decision traces focus on capturing the reasoning behind decisions, why something was decided, from an operational standpoint. This page focuses on the regulatory need to reconstruct what an agent did and knew and to keep data isolated. Many regulated systems want both.