WHITEPAPER

What We Actually Read From Your Database

3 min read · Sep 19, 2026

Every vendor says they read only metadata. Databases expose their internals in ways that make that claim harder than it sounds, and the honest answer is architectural rather than verbal.

The Question That Decides Adoption

Adopting any automated database tool means letting an agent into a production system. Whatever else a team weighs, this is the decision that actually gates it, and it is rarely settled by a promise to be careful. Every vendor promises that.

The useful question is narrower: what does the design make possible in the first place? Not what the vendor intends, but what the architecture permits on a bad day.

The Default Path

Detection and diagnosis can be built entirely on logs, performance counters and system catalog metadata. Table contents are not an input to that work. Bloat is visible in page counts and tuple estimates, stale statistics in modification counters and timestamps, plan regressions in cumulative statement statistics. None of it requires reading a row a customer stored.

That is a property of what the algorithms are built from, not a policy applied on top of a system that could read rows if it chose to.

Where Metadata Is Not Innocent

One qualification, because anyone who looks will find it: a database's diagnostic surfaces are not uniformly free of its data. Planner statistics hold samples of real column values by design — that is how the optimizer estimates selectivity. The text of a currently executing statement carries its literal parameters.

In PostgreSQL that means most_common_vals on an email column contains real addresses, and pg_stat_activity shows the values a running query was given. This is how databases expose their own internals rather than a defect in any one of them; other engines have equivalents in their statistics histograms and their session views.

Anyone who tells you they read only metadata either has not looked or is hoping you will not.

An Architectural Answer, Not a Verbal One

Since the fragments exist, the question becomes where they go. Ours stay on the agent, which runs inside the customer's own infrastructure, and object names are tokenized before anything leaves it.

Tokenization is only worth something if the key stays behind. The mapping between real object names and their tokens is held by the agent, on the customer's side. Tokens travel; what would turn them back into names does not. It is reversible only where the original data already lives.

Refusal Has To Be a Supported Answer

Some diagnostics need more than the default — a query text, a specific object. Where that is the case the right behavior is to ask, explicitly, for read-only access, with a scope, a duration and limits the customer sets, revocable at any moment without negotiation.

And refusal has to be survivable. If a grant is declined or withdrawn, the capability that depended on it should stop and say plainly that it has stopped, while everything else continues at full confidence. A system that degrades quietly when you withhold access has made that access mandatory in practice, whatever its documentation says.

More Posts