Agent Query Audit Logging in Analytical Databases

In July 2025, a Replit agent ran a DROP DATABASE command against a production system. All three events left a trail. None of the three trails answered the question an auditor actually asks after the fact: which governance regime authorized this action, and who signed off on it? The record showed what happened. It could not show why, under what authority, or under whose approval.

That gap is the starting point for understanding agent query logging. An AI agent doesn't work that way. There's no call stack to walk because there's no fixed stack to begin with. The query that hit the database is downstream of a reasoning process, and that process left no structural trace a traditional audit log was ever built to capture.

Volume compounds the problem. There's no one to ask, the query volume is anything but sparse, and intent isn't a fact sitting in someone's memory: it's a property of a reasoning process that happened once and left behind, at best, a partial trace.

The Decision Evidence Maturity Model (DEMM) paper names the failure mode that results: the container fallacy. The container fallacy is the automatic assumption that having a log container, some record, some trace, some file full of entries, means the audit question is answered. A log can exist in full and still fail to answer the one question a regulator or incident reviewer will actually ask about a specific decision. The three incidents above are the container fallacy in production: each left documentation of an action, and in each case that documentation stopped short of the one fact that mattered most, which governance regime, if any, had authorized the action that was taken.

What the database layer must now meet under regulation

Governance of AI agents has stopped being a matter of internal policy and started being a matter of enforceable deadlines. For any organization running agents in a high-risk category, the ability to demonstrate audit capability on demand is now a compliance requirement bolted into the regulation itself.

What that shift means in practice is a move in regulatory attention from the model to the data the model can touch. An autonomous agent with database access can query production data at a scale and speed no human reviewer ever could, which means the live question is about data access: which agent reached which table, under what authority, and can that access be reconstructed after the fact. That's the question regulators and internal security teams are converging on, and it lands squarely at the database layer.

A few obligations follow directly from that convergence, and each one has a concrete engineering shape. Every query an agent runs has to produce a log entry that is attributable to that specific agent, and that entry has to be tamper-proof: it records which agent, which connection, what query, and when, in a form nobody can quietly edit later. An agent must never be able to modify its own audit trail. And organizations need to know, in concrete terms, what data a given agent could reach and how sensitive that data was, because an audit log that doesn't carry classification context can't tell a reviewer whether a breach was trivial or severe.

What an agent audit log must capture

A complete agent audit log has to answer four questions at once: who did this, what were they trying to do, what action did they take, and what happened as a result. Miss any one of the four and a governance question that seems answerable in the moment turns out, months later, to have no answer.

Identity comes first, and it has to resolve to the agent, not to a human. A service account, an API key, or a connection credential has to point uniquely to the agent that issued the query, not to whichever person happens to own the account the agent runs under. That distinction matters because shared credentials are how audit trails collapse: if ten agents share one service account, the log can tell you a query ran, but not which of the ten ran it.

A production-grade schema needs an event_timestamp precise enough to untangle queries that ran in parallel, a user_id or service_account field that resolves to agent identity rather than a shared login, an action_type and a resource_type and resource_id describing what was done to what, and the full query_text itself rather than a summarized version of it. It needs ip_address and user_agent for network attribution, and it needs data_classification and an is_sensitive_access flag evaluated at the moment the query ran, not at the moment the schema was first designed, since sensitivity can shift as data and policy both evolve.

Agent workloads need fields a human-user schema never had to carry. The log needs the prompt or tool-call context that triggered the query in the first place, the closest thing available to the agent's stated intent at that moment. It's one step inside a longer chain of tool calls, and the chain is what gives the query its meaning. It needs to capture decision points: which guardrails fired, which access-control filters blocked or altered a request, and what exactly got filtered out. And where the agent is LLM-driven, it needs latency and token metadata, since those numbers are often the first signal that something in the reasoning process went sideways.

Access-control filtering deserves its own line in the log, not an assumption that it's implied. On the storage side, partitioning by event_timestamp and clustering by user_id and resource_id keeps a table built around these fields queryable at scale, letting a reviewer pull every action tied to one agent, or every touch on one sensitive table, without scanning the entire history to find it.

Why append-only storage is insufficient and what tamper-evidence requires

A log that can be quietly rewritten after the fact isn't evidence of anything, no matter how complete its fields are. Most agent-observability tools on the market today produce traces, and a trace is a useful diagnostic artifact but a weak legal one: it can be altered without leaving a mark, and it offers no built-in way to prove to a skeptical third party that it hasn't been.

It helps to separate three things that get treated as interchangeable but aren't. Regulatory frameworks like the EU AI Act's logging duty are written with that third tier in mind. Observability tooling and even solid append-only tables don't fully clear the bar on their own.

Getting there starts with write semantics: audit tables should be append-only, with no update or delete paths available against audit rows at all, not even for administrators cleaning up test data. From there, the NovaFabric project illustrates the shape a stronger guarantee takes: it seals agent runs with a holistic DSSE signature, an RFC 3161 timestamp for independently verifiable time attribution, an append-only Merkle log structure, and a redaction attestation. That last piece matters more than it might first appear. Without that attestation, a reviewer has no way to tell deliberate redaction apart from missing data, and the two mean very different things.

The requirement that an agent must never modify its own audit trail carries a real architectural consequence. HMAC-signed audit logs, the kind built into some gateway-layer tools, show the underlying principle clearly: the signature is a property of the surrounding infrastructure, generated and checked outside the agent's control, so the agent has no way to forge or quietly suppress it even if it tried.

Gateway layer versus database layer for capturing the audit record

Capturing audit data only where the query lands in the database misses most of the story. The query text alone says what ran. It says nothing about the reasoning that produced it.

The gateway layer sits earlier in the chain, at the point where every agent-to-database interaction passes through a defined tool call with a known, structured schema. Intercepting and logging at this layer, rather than relying on the database layer alone, is what lets the audit trail capture intent alongside execution.

What the gateway captures that the database layer structurally cannot includes the prompt or tool-call parameters behind the query, the agent's stated purpose at the moment it acted, attribution tied to a specific virtual key or connection identity rather than a generic database session, and the full request-response cycle, including tool call parameters, model outputs, and latency. A centralized AI gateway can capture request, tool-call, and attribution data together, in one consistent pass. The alternative, assembling the same picture from an OpenTelemetry stack, cloud-native audit logging, a SIEM platform, and an APM tool working in parallel, means stitching together partial coverage from four different systems, each one built to answer a different question and none built to answer this one by itself.

Centralizing the audit function at the gateway raises an honest objection: a gateway that sees everything also becomes a single point of failure and a high-value target for anyone trying to cover their tracks. Read-only enforcement at the gateway turns out to serve compliance almost as a side effect of good design: a SQL guard that blocks agents from mutating regulated data removes a whole category of risk simply because the agent is never capable of the mutation in the first place, and instant key revocation shuts off access the moment something looks wrong, with no schema change and no deploy required.

The ingestion architecture that keeps audit logging reliable under agent query bursts

Agent workloads don't arrive at a steady pace. They spike, often without warning, as a single workflow kicks off dozens or hundreds of queries in a tight window, and an audit ingestion path sized for human query volumes will fall over under that kind of load unless it's built with the burst pattern in mind from the start. The fix is architectural: separate the reliability of the write path from the performance of the analytical query path, so a burst that strains one doesn't take out the other.

The stakes are different here than in ordinary monitoring. A dropped metric in a performance dashboard is an inconvenience. A dropped audit record is a compliance gap, a hole in the one record that was supposed to be complete by definition. That distinction is why "best-effort" ingestion, the design standard for a lot of observability tooling, isn't good enough for this job. The audit log needs ingestion built around the assumption that nothing gets lost, even during the exact traffic spikes that make loss most tempting to architects trying to keep latency down.

Columnar OLAP engines are the right tool for querying audit data at scale: fast aggregations, fast time-range scans, fast anomaly-detection queries across millions of rows. But that's a statement about the query side, not the ingestion side. A steadier pattern separates the two concerns: batch incoming records, write the batches to object storage first, pass them through a durable queue, and only then land them in the OLAP engine for analysis. Each stage absorbs a different kind of load, and the queue in particular gives the system somewhere to put a burst without dropping it, rather than forcing every write to hit the analytical engine in real time.

The audit system generates audit data of its own, an operational detail that gets missed often enough to be worth stating. TTL management on system tables isn't a tuning nicety here; it's a required part of keeping the audit log usable under its own weight.

How per-property sufficiency checking closes the gap

Return to the container fallacy from the opening section: the mistake of treating the presence of a log as proof that the log is sufficient. Everything described so far, the fields, the tamper-evidence, the gateway capture, the ingestion architecture, builds a log that's complete and trustworthy as a container. None of it, by itself, proves that the log answers the specific question a given auditor will actually ask about a given decision.

That's the gap the Decision Evidence Maturity Model closes, and it closes it by refusing to evaluate a log as a single pass-or-fail object. Instead, DEMM evaluates sufficiency property by property: for a specific decision, does the record answer this particular governance question, yes or no, and if not, exactly which piece is missing? One decision's record might fully answer "which agent issued this" while leaving "under what authorization" completely blank. Grading the log as a whole, complete versus incomplete, would hide that distinction, while grading it property by property surfaces it.

DEMM's method sorts evidence sufficiency into four executable categories, plus a fifth category for cases where the protocol itself conflicts, and rolls the per-property verdicts up into a five-level capability rubric. The open-source Decision Trace Reconstructor that accompanies the method ships ten executable adapter-fallback classes, covering vendor SDKs, protocol-level traces, prose pulled from public postmortems, and generic JSONL records, so the sufficiency check can run against evidence in the form it actually appears in. A feasibility run across 140 synthetic scenarios plus the three public incidents named earlier produced a completeness range of 53.6% to 100%. That range describes how the implementation behaved in that exercise, not an external validation of the method against real-world governance outcomes.

What the range does make visible is the finding underneath this whole subject: having a log and being able to answer a governance question are two different achievements, and an organization can score well on the first while failing the second on exactly the property that mattered most. Agent query audit logging in analytical databases has to be built toward the second achievement from the start, with identity, intent, tamper-evidence, gateway capture, and ingestion reliability all serving one end: a record that can answer, property by property, the question an external party actually asks.