CONTEXTUAL TRUST RESEARCH
Enterprise AI Data Protection Across Lakehouses and Agents
Published 3 November 2026. Written as at 3 November 2026.
Enterprise AI data protection starts with a practical question: can this person, through this application, use this data for this purpose now? Encryption matters, but a correctly encrypted lakehouse can still supply sensitive information to an overprivileged agent. A restricted table can become an unrestricted extract, embedding or prompt log if the surrounding workflow loses its permissions.
Contextual Trust's proposed approach connects business purpose, data ownership and technical enforcement across the existing enterprise estate. It does not require every organisation to move its data to one provider. The architecture must make each connection accountable and testable. The patterns below are design recommendations, not claims that Contextual Trust has deployed these integrations.
From a useful control list to an enforced path
Matthew Coombs's Enterprise AI Data Protection Simplified discussion highlights classification, lineage, permission-aware retrieval, scoped agent access and other controls. It is a discussion source, not a security standard or evidence of a deployed implementation. The additional question for an architect is where each control executes, who owns it and how a negative test demonstrates it works.
Treat retrieved documents and tool outputs as untrusted data. Their contents cannot grant permissions or change the governing policy. Masking and output filtering can reduce exposure, but neither replaces access control. Private deployment changes hosting and custody; it does not automatically resolve excessive privilege, unsafe tools or inappropriate retention.
Connect without flattening the security model
Start with metadata discovery: approved catalogues, schema definitions, classification, owners, lineage and access policies. Reading metadata also requires authorisation; names and descriptions can themselves be sensitive. Record unknowns rather than inferring that an unlabelled dataset is public.
Then choose an access pattern for each workload:
| Pattern | Appropriate use | Boundary to verify |
|---|---|---|
| Governed SQL or service API | Structured questions and bounded calculations | Identity, row/column restrictions, query limits and result filtering |
| Permission-aware document retrieval | Approved unstructured content | ACL translation, current authorisation, tenant filters and source version |
| Federation or external table access | Supported queries across systems | Actual engine and storage path; source policies may not carry over automatically |
| Controlled materialisation | An index or local copy is necessary | Approved fields, destination permissions, expiry, lineage and deletion propagation |
| Business action API | A change to an operational record | Separate write authority and current-state enforcement in the owning service |
An adapter should translate technical interfaces, not invent business permissions. Prefer delegated user identity where supported. If a service identity must read on behalf of users, the gateway needs a reviewed, enforceable mapping of user, tenant, purpose and permitted scope. A shared account with broad access is not permission-aware retrieval simply because the UI requires login.
How the provider connections differ
These are candidate connection paths. Features, editions, regions and supported engines must be checked in the customer's deployment.
| Existing platform | Candidate path | Required evidence |
|---|---|---|
| Databricks | Approved query endpoint or supported Unity Catalog external access | Principal privileges, table format and client support; prove that the chosen route preserves intended controls |
| Snowflake | Approved SQL/API path using narrowly scoped roles and governed views | Row access policies, role behaviour, export privileges and edition requirements |
| Google BigQuery | Approved query service with scoped identity | Dataset/table IAM, applicable row policies, column controls and destination/export restrictions |
| Microsoft Fabric and OneLake | Supported engine or OneLake access route | Workspace/item permissions and applicable OneLake roles; test each engine and shortcut path |
| Object storage and operational systems | Scoped object access or an owning-service API | Bucket/container policy, object version, classification, API authorisation and network route |
Databricks documents external access as an explicit metastore configuration with required privileges; it is not a universal plug-in switch. Snowflake row policies and BigQuery row-level security operate within their respective access models. Microsoft documents OneLake roles and scopes. These mechanisms are not interchangeable policy languages. See the linked provider references below before selecting a path.
The existing CAE article Choosing a Lakehouse for a Contextual Agentic Enterprise covers platform selection. This article concerns the connection and protection boundary after a platform has been selected.
Carry meaning and permission into the contextual model
A contextual model can connect business capability, process, person or role, data asset, owner, policy, system and outcome. For each evidence item, retain its source identifier, version or observation time, classification, tenant, allowed purpose and relevant policy reference. Link to the source instead of copying sensitive contents unnecessarily. Preserve the distinction between a source fact, a model inference and a human decision.
The semantic layer helps interpret terms such as customer, entitlement or active contract. It does not become an authority to override the underlying system. If two platforms disagree, record the conflict and route it to the named data owner rather than allowing the model to select whichever answer enables the requested action.
Protect derivatives and memory
Embeddings, caches, conversation history, evaluation datasets and traces can contain sensitive information or reveal it indirectly. Register these as data assets with their own access, retention and deletion requirements. Check permissions before retrieval and again before releasing results where state may have changed. A stale index ACL must not silently preserve access revoked at the source.
Revocation needs a defined propagation time and a fail-closed path when the authorisation service is unavailable. Deleting a source document is not proof that its chunks, embeddings, logs or backups disappeared. Define which copies can be deleted promptly, which are retained for an approved obligation, and who verifies completion. Do not log full prompts or results merely to make an audit trail look comprehensive.
A fictional account-review example
Illustrative scenario: fictional, not a customer deployment or measured outcome.
A support employee asks an agent to explain an account adjustment. Billing records are queried through a governed service; the contract is retrieved from an approved document repository. The employee can see their own service region, but not another region's records. The gateway binds the request to the employee and tenant, restricts retrieval and records the source versions used.
An indexed contract still carries yesterday's permission after the employee changes teams. The current authorisation check denies its release. The application explains that access could not be confirmed, returns no restricted excerpt and creates a minimal operational exception for the access owner. It does not fall back to the broad ingestion account. The index synchronisation problem is repaired and the revoked-access test is rerun before recovery is accepted.
If the employee subsequently requests a credit, read permission and an explanatory answer are insufficient. The billing service must check write authority, current eligibility and duplicate state at the point of effect. An uncertain result requires reconciliation before retry. This is where data protection connects to governed execution.
Ownership and acceptance
The data owner approves purpose, classification and retention. Identity and security owners approve delegation and control boundaries. Platform owners configure and test source enforcement. Product owners define useful behaviour and understandable denial paths. Operators own revocation delays, failed connectors and incident recovery. The model cannot hold any of these accountabilities.
Before enabling a connection, test an allowed request and a denied request; cross-tenant access; a changed group membership; revoked document access; a direct storage/export route; a malicious retrieved instruction; sensitive output; an unavailable policy service; and deletion of a materialised copy. Retain reproducible evidence using synthetic records before introducing customer data.
Measure reviewed access-decision correctness across both allowed and denied samples; revocation propagation time; the proportion of registered derivatives with an owner and retention rule; and incident containment/recovery time. Define the observation window, source coverage and review owner. Baselines are unknown until measured. Zero alerts alone does not demonstrate protection.
For an initial review, bring a metadata inventory, approved identity/access diagrams, policy examples and synthetic test cases. Do not send credentials, private keys or production extracts through an enquiry form. The Contextual Trust service catalogue and scope workflow can frame an enquiry; they do not activate a live connector or scanner.
Provider references
Checked 3 November 2026. These sources describe provider mechanisms, not endorsement of Contextual Trust.
- Databricks external access and privileges.
- Snowflake row access policies.
- BigQuery row-level security.
- OneLake roles, permissions and scopes.
Educational architecture guidance. Application requires organisation-specific security, privacy, legal, operational and governance review and appropriate approval.