A data agent can recheck every query and still expose the wrong conversation

Enterprise data agents are converging on live permission checks, but the control is narrower than the phrase suggests. Recent documentation from AWS, Databricks, ThoughtSpot and MotherDuck exposes four different places where an answer can cross a boundary: retrieval, SQL execution, retained conversation state and model processing. A clean test at one layer does not certify the others.

Live authorization is becoming the query-time default

Amazon Quick uses a two-stage path for connected enterprise content. Indexed access-control lists first reduce the semantic-search candidate set; Quick then checks those candidates against the source before passages reach the model. AWS describes the index as a performance filter and the connected source as the final authorization authority (AWS architecture post). This closes the stale-grant window between connector crawls, although teams still need to test how quickly new grants become searchable.

Databricks applies the same principle to structured data through a different mechanism. An application can put a signed end-user claim in a service-principal OAuth token, and a Unity Catalog dynamic view or ABAC policy can filter rows using that claim. The supported surfaces include the Genie Agents API (Databricks identity-claims documentation). Here the database policy, rather than the vector index, makes the query-time decision.

Query authorization does not authorize the conversation

Databricks explicitly says Genie conversations belong to the service principal, not the human user behind the application. The application must record conversation ownership and reject attempts to read or continue another user’s conversation. Row filtering can therefore work perfectly while a leaked conversation ID opens a cross-user path (Databricks Genie guidance).

ThoughtSpot documents a related persistence boundary. When a saved Spotter chat reopens, the product refetches live data and rechecks model, row and column permissions. But its documentation warns that historical text analysis can still refer to data later redacted from the user (ThoughtSpot chat-history documentation). Revocation closes the next query without necessarily rewriting what the earlier conversation said.

Processing location is a fourth control plane

MotherDuck shows why permission tests are still incomplete without a data-flow map. Agent Chat inference stays within the organization’s geography, but MotherDuck says prompt_jev inputs from every region are processed by TypeSafe servers in the United States. The function sends each non-null row’s text plus instructions, questions and optional labels to that service (MotherDuck cloud-regions documentation; Jev integration documentation). A user may be fully authorized to query a column while policy still forbids sending its values to that processing location.

Test four boundaries, not one demo

A production acceptance test should revoke a source permission and verify four outcomes independently:

1. the retriever or SQL engine stops returning the protected data;
2. another user cannot open or continue the original conversation;
3. retained prose and charts no longer disclose facts that policy requires removed;
4. every function and model endpoint keeps permitted inputs inside the approved geography.

The pattern across these products is not that live permission checks are weak. It is that they are precise: each check governs one operation at one moment. Treating that precision as blanket authorization is the rollout mistake.