Metadata only: what an agent should never read

There is a line in every data-plus-AI system between metadata and content, and where you draw it governs everything downstream: what you have to tell your customers, which industries you can sell into, what a breach would mean, and how much of the estate you can touch without a committee.

The two sides of the line

• Metadata: object names, column names and types, row counts, null rates, query text, execution statistics, costs, lineage, schedules, test results.
• Content: the values in the rows. A customer name. A transaction amount attached to an account. A claim.

Almost every question a data engineer asks about an estate is answerable from the first list. Which models are expensive, what is unused, what changed shape, why a test fails, what a column is derived from — all metadata. The temptation to cross the line comes from a small number of genuinely data-dependent questions, and from the fact that crossing it is easy.

What you give up, and what it buys

You give up the ability to answer "why is this specific row wrong", and you have to accept aggregate evidence — a null rate rather than the null rows — when investigating. In exchange, the answer to "has our data left our warehouse" is no, without qualification, and that sentence is worth more in a regulated industry than any feature it costs.

It has to be structural, not a policy

A rule that says the agent should not select rows is not a control; it is a hope. The control is that the queries issued are generated from a fixed vocabulary against metadata views, that the credentials used cannot read user tables, or both. If the only thing standing between your customers' data and a model is an instruction in a prompt, you do not have a line, you have an intention.

If the boundary is enforced by a prompt, it is not a boundary.