How do I audit what data an AI agent accessed?
Updated · DBShifts
Short answer
Log every agent request where the data is served, not inside the agent: which token, which tool, which table and columns, what was masked or refused, how many rows came back, and when. Make the record complete — including failed requests — tamper-evident and exportable, so you can answer what an agent saw.
Key facts
- Logs written by the agent itself can be skipped, lost or never written at all.
- Refused requests matter as much as allowed ones; a burst of denials is often the first sign of a steered agent.
- An audit trail should record that data was masked, not the data itself.
- A hash chain makes edits detectable; a signed anchor kept outside the system makes them provable.
- A live view is only trustworthy if it is computed from the same records the audit uses.
What to record
For each request: the agent's token, the tool or endpoint, the table, the columns asked for and returned, which were masked, the filters, the row count, whether it was allowed, and why not if it was refused. Add timing so slow or failing requests are visible.
Make it complete
The easy log covers successful queries. The useful one also covers requests that failed validation, crashed or were rejected before they reached the handler, because those are often the interesting ones.
Make it trustworthy
A table of rows can be edited by anyone who can edit rows. Chaining each entry to the one before makes edits detectable, and handing the owner small signed receipts of the chain's state lets them prove later that nothing was changed or removed.
Checklist
- 1
Log at the gateway, for every request
- 2
Include refused and failed requests
- 3
Record masking and row counts, not raw values
- 4
Make the log exportable for auditors
- 5
Chain entries and keep signed anchors outside the system
- 6
Review agent activity regularly, not only after an incident
Common mistakes
Logging only successes
Probing for tables an agent was never given shows up only as refusals. A log without them hides the attack.
Copying sensitive data into the log
The audit log is exported widely. Recording raw values there creates a second copy of the data you were protecting.
Claiming 'nobody can edit it'
Whoever runs the system can usually rewrite it. What you can prove is that history covered by an anchor someone else holds was not changed.
How DBShifts does it
- DBShifts writes an audit row for every agent request that can be tied to a gateway, including requests that failed validation or crashed.
- Replay shows exactly which rows an agent saw, and an access report lists what each agent touched, with a CSV export.
- A tamper-evident ledger chains every access and periodically signs the chain head with an Ed25519 key; owners export and keep those anchors.
- The gateway's Live view is computed from the audit log itself, with exact percentiles, so the dashboard and the record cannot disagree.
Questions people also ask
Can the platform operator rewrite the audit history?
Anyone holding the signing key could in principle rebuild a chain. What they cannot do is produce a different history that still matches an anchor you exported earlier — which is why you keep the anchors.
How long are agent logs kept?
Agent query logs are kept for 90 days; audit retention for the account depends on the plan.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free18 answers in this series. See all.