Query-Time Access Control Stops at the Warehouse Door

Begin with what the query-time access-control vendors got right, because they got a great deal right. The data catalogs and governance suites that preceded them govern a description of data: an inventory of where it lives, a glossary of what it means, a tag declaring what policy should apply. The tag is advice. Whether the warehouse, the BI tool, or the pipeline honors that tag is someone else's integration problem. The query-time vendors saw this clearly and said so — in their telling, discovery is not delivery, and governance that stalls before enforcement is theater. That critique was correct.

Their answer was serious engineering. Policy expressed once against attributes — of the user, the data, the purpose — instead of hand-maintained per-table grants; the category claims order-of-magnitude reductions in the number of policies an enterprise must maintain, and directionally that is plausible. Row-level filters and column masking compiled into the query path of the platforms they front, so the SQL that runs is the SQL that policy allows. A unified audit of who read what, when, under which rule. This is the one architecture in the category where policy is enforcement rather than advice. A CISO can stand in front of a regulator and say: inside these platforms, no query runs unauthorized. That sentence is earned, and nothing below takes it away.

What follows is not a critique of the execution. It is a map of the perimeter.

Query-time enforcement lives, by definition, in the query path of the platforms it integrates with. That gives it a precise perimeter: the enforcement zone is the set of fronted platforms, and the enforcement event is the read. Both boundaries are structural — no roadmap changes what "at query time" means.

Start with the zone. Data does not stay in the warehouse; the entire point of reading it is to move it into the systems where work happens. Trace the exits:

• The BI extract. A dashboard tool runs one authorized query — masked, filtered, logged — and pulls the result set into its own in-memory model. From that moment the data is redistributed under the BI tool's sharing rules, which the policy engine has never heard of.
• The application cache. An application queries once and serves the answer to thousands of downstream requests. One governed read; an unbounded number of ungoverned re-reads.
• The file export. A result set becomes a CSV in object storage or an attachment in an inbox. The mask was applied at the moment of the query. The file lives on for years under file-system permissions.
• The agent's context window. An AI agent retrieves data — authorized, masked, logged — into its working context, then reasons over it, summarizes it, and acts on it. The retrieval was governed. Everything the agent does next is not.

None of these is a defect. Each is the architecture working exactly as designed: it governs the read, at the door. Data that walks out through an authorized query is, by construction, beyond it.

Now the second boundary — the one that matters more. Even deep inside the zone, ask what the enforcement event actually is: a read. But an enterprise does not read data as an end in itself. It reads data in order to do something — post the journal entry, approve the loan, change the customer record, release the shipment, file the disclosure. Those actions execute in ERP transactions, workflow tools, scripts, SaaS applications, and increasingly in agents — layers the query-time engine does not front and was never designed to front.

So the strongest read-governance in the category says nothing about whether the action taken on the data was entitled. Nothing about whether the write that followed met quality policy. Nothing about whether residency held when the process carried the data toward the act. The audit log can prove an analyst was allowed to see the number; it cannot say what the enterprise did with it.

Here the vendors' own argument boomerangs. They told the catalogs that discovery is not delivery, and governance stalls at the last mile. Correct. But their delivery ends at governed read-access — and governed read-access is delivery of data, not governance of the act. The last mile they diagnosed has moved one layer up, and it is still unowned.

Entroid approaches this from the opposite end. Instead of standing at the door of the data platforms, it makes the data model the runtime the process executes on. The fabric is five primitives — Deterministic Workflows, Intelligence Orchestration, Atomic Agents, Functions, and Connectors — composed on a Semantic Ontology, on one runtime, with an immutable per-action audit. The ontology is not a catalog beside the estate, and not a policy engine at the estate's door; it is the governed model on which the work itself runs. That placement, not any feature, is what changes the scope of governance. Architecturally:

• The read, the write, and the act share one gate. A Deterministic Workflow that touches data passes classification, entitlement, quality, and residency checks inline, at the moment of the action — whether that action is reading a balance, writing a record, or approving the transaction the data drives.
• Quality is enforced at the write. The nonconforming record is refused when it is written, not flagged by a profiling job after it has been consumed downstream.
• Lineage is a byproduct, not a crawl. Every action emits an immutable record as it executes. The lineage graph is not stitched together after the fact; it is the execution trace itself.
• Egress is a gate, not an edge. Connectors are the only primitive that touches external systems. Data reaching a BI tool, a file store, or a downstream application crosses a governed, audited boundary — it does not simply exit an enforcement zone into the dark.
• Agents are inside the gate. Atomic Agents run on the same runtime with human-in-the-loop as a first-class construct. An agent's retrieval and the action it takes pass the same inline checks, and both land in the same audit.

Two honest qualifications. First, this is not zero-integration magic: ES runs over the existing estate, and it reaches that estate through governed Connectors — the integration work is real, simply concentrated at an audited boundary instead of scattered across tools. Second, query-time control in your warehouses remains worth having. Analysts and tools will keep querying those platforms directly, and enforcing policy on those reads is necessary defense in depth. The argument is about locus, not replacement: for the processes that run on the fabric, governance stops being a property of one door and becomes a property of the runtime.

None of this requires taking a vendor's word — ours included. It requires a map. At the next governance architecture review, put four questions on the table:

• Draw the zone. Which platforms does your enforcement actually front, and what fraction of business-critical data flows begin and end inside them?
• List the exits. Extracts, caches, exports, agent retrievals: which are even logged, and which are governed after the data crosses?
• Name the actions. For your three most regulated processes, where does the decision execute — and what enforces policy at that point, if anything?
• Test the write. What in the current architecture prevents a nonconforming or unentitled write, as opposed to detecting it later?

If the honest answers keep coming back to "we govern the authorized read," you have something necessary — and something incomplete. "Who may see this data?" and "what may the enterprise do with it?" are different questions, and only the first is answered at the warehouse door. The second can only be answered by the thing that executes the doing — which is why it must be a property of the runtime, not a product standing beside it.