How to Give an Auditor Access to Your Agent Logs Without Handing Over the Keys

Sooner or later someone outside your team asks to see what your AI agent did. It might be an external auditor, a customer's security team, a regulator, or an insurer. They do not want a slide deck. They want evidence they can check themselves.

Most teams handle this badly. They export a spreadsheet by hand, paste screenshots into a document, or, worst of all, share an admin login so the visitor can look around. The first approach is slow and easy to dispute. The second gives away your whole system. Neither lets the visitor confirm that the records were not edited after the fact.

This guide shows a better routine using ZizkaDB, an open source causal database for AI agents: give outsiders read-only, expiring access, hand over an export they can verify, and keep control of what they see. I describe features as documented in the project changelog and SDK documentation at the time of writing. Exact command names and settings can change, so confirm them against the current documentation before you rely on them.

Why this is worth setting up before anyone asks

An evidence request arrives at a bad moment. It comes with a deadline, from someone whose opinion affects a deal or a license, and it lands on whoever knows the system best. That person is usually also the one fixing something else.

Preparing the routine in advance has three business effects:

Faster reviews. A customer security questionnaire that needs two weeks of internal digging becomes a day of sharing a prepared pack.
Fewer risky shortcuts. Nobody shares a master credential under pressure, because a safe alternative already exists.
Stronger evidence. A record the visitor can verify independently is worth much more than a summary you wrote about it.

None of this is specific to one regulation. Rules such as the EU AI Act expect high-risk systems to keep automatic records and to make them available to authorities when required, and customers in finance, health, and insurance ask similar questions. Check with legal counsel which obligations apply to you.

What the visitor actually needs

Before building anything, decide what a reasonable outsider needs to see. In most cases it is three things:

The history of specific agent actions, with the reasons behind them.
Proof the history was not changed after it was written.
Context about the period, such as which prompt and model versions were live.

They do not need your whole database, your keys, other customers' data, or the ability to write anything. Define the scope first, then give exactly that.

Step 1: Start with a record worth sharing

This routine works only if the underlying record is complete and linked. ZizkaDB stores each event with a link to its cause, so any step can be traced back to its inputs. It also stores a SHA-256 checksum for each event and a chain hash that ties each event to the previous one for that agent. If any row is deleted, inserted, reordered, or edited, the chain breaks and verification fails.

If you are not recording agent events yet, start a local instance with the quickstart in the repository and wrap your agent calls first. Without a record there is nothing safe to share.

Two preparation points pay off later:

Redact before storage. ZizkaDB can redact sensitive fields before they are written. Set this up early, because removing secrets from an export afterward is much harder than never storing them.
Log your configuration as state. Record prompt versions, model names, and enabled tools when they change, so the question of what was live that day has an answer.
Step 2: Create read-only, expiring access

The simplest safe move is to avoid sharing your own credentials at all. According to the changelog, ZizkaDB supports read-only keys and keys that expire. Create a dedicated key for each external reviewer, make it read-only, and give it an end date that matches the review window.

Good habits for this key:

One key per reviewer. If something looks wrong later, you can tell whose access it was and revoke only that one.
Shortest sensible expiry. A two-week review does not need a six-month key.
Record the grant. Write down who received access, when, and for what purpose. That note is part of your own evidence.
Share it through a proper channel, not a chat message that stays searchable forever.

I could not confirm exactly where keys are created in every version, whether in the dashboard, the API, or both, so check your version for the current steps. The point is the principle: read-only, time-limited, and per person.

Step 3: Decide between live access and an export

There are two ways to let a reviewer see the record, and the right choice depends on trust and technical comfort.

Live access means the reviewer connects with their read-only key and explores. This suits a customer security team that wants to look around and ask follow-up questions. It works best when you host the instance somewhere reachable, and when the data is already redacted.

An export means you hand over a file. This suits an auditor who works offline, a regulator, or any case where you do not want an outsider connecting to your systems. It also leaves a clear artifact: this is what we gave you, on this date.

Many teams do both: an export as the formal record, and live access for questions.

Step 4: Produce an export the visitor can verify

The SDK includes functions to export and import events and to iterate over them in pages, so large histories do not need to fit in memory. Export a defined scope, such as one agent over a stated period, in a standard line-based format.

A simple pattern in code looks like this:

python
report = await db.verify_chain("my-agent")
print(report)

async for event in db.iter_events(agent="my-agent"):
... # write each event to your export file

Check the current SDK documentation for the exact parameters on date filters and output formats. The structure is what counts: verify first, then export, then record both results together.

Next, give the visitor a way to check your work. The verification call returns whether the chain is intact, a short summary, any problems found, and a chain head. Save that chain head somewhere independent of the database, such as a signed note or a repository, and include it with the export. Later, the visitor can confirm that the history they hold matches the anchor, which shows nothing was rewritten between your export and their review.

If you use GitHub for your pipeline, the ZizkaDB Audit action can do part of this on a schedule. It verifies each agent's hash chain, exports the history, and writes a report attested by GitHub, so anyone can check that the report came from your workflow run. Pointed at your live instance, it gives you a recurring, dated record to share.

Step 5: Write a one page cover note

Evidence without context creates confusion. Write a single page that the reviewer reads first. It should include:

Scope. Which agent, which period, which events.
Method. How the export was produced and how the chain was verified.
Anchors. The chain head and the date it was recorded.
Known limits. For example, that the record proves events were not altered after writing, not that the agent's decisions were correct.
Redactions. What was removed or masked, and why.
Contact. Who can answer questions.

The limits matter. Checksums and chains show that a record is unchanged. They do not prove that the logged content was true, and they do not stop someone with full database access from rewriting everything, which is why the independent anchor matters. Saying this plainly makes the evidence more credible, not less.

Step 6: Handle personal data and deletion requests

Agent logs often contain personal data, so an export has a privacy dimension. Three controls help:

Redaction before storage, as above, so sensitive fields are never kept.
Retention settings, so old data leaves the system on a schedule you can state.
Erasure with tombstones. When data is erased for privacy reasons, ZizkaDB leaves a tombstone that keeps the link and the reason but no content, so the chain still verifies and shows where data was removed.

Tell the reviewer about erased data in the cover note. A gap that is explained is routine. A gap that is a surprise looks like tampering.

Step 7: Close the loop after the review

When the review ends, finish the job:

Revoke or let the key expire, and confirm it no longer works.
Store the exact export you gave, with its checksum, so you can prove later what was shared.
Log the questions asked. Repeated questions show what your standing evidence pack is missing.
Update the pack. If the reviewer needed something you did not have, add it to the routine.

Over time, this turns each request into an improvement of the next one.

Common mistakes to avoid

Sharing an admin login. It is quick and it gives away everything. Use read-only keys.

Giving a key with no end date. Access that nobody remembers is a risk. Set an expiry.

Exporting before verifying. If the chain is broken, you want to know before the reviewer does.

Skipping the independent anchor. Without it, the verification claim rests on trusting your database.

Leaving personal data in the export. Redact first and explain what you removed.

Claiming more than the evidence shows. The record shows what happened and that it was unchanged. People still judge whether it was acceptable.

What it saves

The following are modeled assumptions, not measured results, so replace them with your own. Suppose a team receives six evidence requests a year. Without a routine, each takes two people about three days to assemble and defend, around 4,800 euro at 100 euro per hour. With read-only access, a verified export, and a cover note, each takes roughly one day, saving about 3,200 euro per request, or around 19,000 euro a year. The larger benefit is harder to price: a deal that does not stall in security review, and an auditor who leaves with confidence.

Start this week

Pick one agent and one imaginary request: show me what this agent did last month and prove nobody changed it. Run the verification, export a month of events, save the chain head somewhere independent, and write the cover note. If you can do all of it in an afternoon, you are ready for the real request. If you cannot, you have found the gap before an outsider did.

Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB

Interested in a design partnership? Fill in the form on our site or reach me directly at [email protected]

Sources: ZizkaDB changelog · ZizkaDB Python SDK wiki · ZizkaDB Audit on GitHub Marketplace · AI Act Article 12 · ZizkaDB repository