Nobody gets around the permissions — the agent included

Row level security and data masking

Row level security limits which rows a person may read. Data masking protects individual column values, such as names in an HR analysis. In lavalake, Trino policies evaluate both rules under the user’s identity, allowing different views of the same table.

User access management through roles

Keycloak roles are passed through to Trino for access management. Role-based access control (RBAC) groups permissions; row and column policies determine the visible slice. Check the combination using a business role and a restricted role before sharing a report.

Data provenance: trace sources and processing

Data provenance describes where data originates and which processing steps it has passed through. lavalake derives table lineage from recorded operations. Combined with access history, it helps trace the source behind a table and who accessed it. Coverage extends to the operations recorded in the platform.

Privacy in everyday work

Data subject requests, confirmed erasure and retention periods are part of the platform. A report of the installation’s processing activities can be exported as Word or PDF. Time-limited support access and a configurable two-factor requirement extend access controls.

The chain everything hangs on

You sign in to Keycloak over OIDC. The agent service exchanges your token per RFC 8693 for a Trino token. Trino runs the statement under that identity. What you may not see does not come back — not because the interface hides it, but because the engine does not return it.

Browser  ── OIDC login ──▶  Keycloak
Agent    ── token exchange (RFC 8693, audience=trino)
Trino    ── executes under your identity
         ── grants + row access + column masking
Result   ── your slice only

Permissions enforced in the interface are not permissions. They are a request.

The difference shows the moment somebody bypasses the interface. Under a shared-service-account model the whole database is then open. Here, what is open is exactly what the signed-in user's role could already see.

Rows and columns

Row-access and column-masking policies are evaluated in Trino. One department sees its slice, an HR role sees names, the analysis beside it sees the same table with that column masked. These are not two tables and not two reports — it is one table, filtered differently.

Where this applies matters: not only in the query you type yourself, but in a dashboard tile somebody else created, and in a search result. Every tile computes per viewer under that viewer's identity.

Since v0.34.0, Keycloak roles are passed through as Trino groups. A policy therefore applies to every member of the specified role. Changes made in user administration are synchronized immediately; the mapping is also refreshed periodically.

Classify tables and columns

In the table view, administrators tag tables and columns as personal data, confidential, financial data and other categories. “Klassifizieren” suggests tags from column names and data types. Suggestions are confirmed individually and every change is audited.

Name-based heuristics work without an AI backend. An optional configured API or self-hosted model refines suggestions, receiving only names and types, never data values. Tags do not yet trigger automatic masking. Personal-data access, deletion and retention workflows support handling personal data.

An audit log you cannot quietly edit

The audit log is a hash chain: each entry carries the hash of its predecessor. Change or remove an entry after the fact and the chain breaks at that point — and the break is verifiable. That is not the same as “we write logs”, and it is the distinction an audit ultimately comes down to.

• Users and agents are recorded alike
• Derived from the log: lineage per table — where the data came from
• Derived from the log: access history — who touched a table
• Personal-data access, deletion and retention workflows

The agent gets your rights, nothing more

The built-in assistant works with the same delegated token. It has no identity of its own with wider rights. On top of that, every tool call runs through a chain: classify, audit, execute. Mutating and destructive steps ask first.

The outer edge

Everything runs behind a single reverse proxy. Trino, the object store and the platform database are not reachable from outside — there are three routes, and none of them bypasses the identity check. Connections to registered sources pass an egress guard against SSRF and metadata-endpoint access. Documents are parsed in a worker with time and memory limits; secrets are stored AES-256-GCM encrypted.

• Three routes outward: console, agent API, Keycloak
• Egress guard against SSRF and metadata endpoints
• Document parsing in a worker with time and memory limits
• Optional internal TLS layer for documented service connections
• Secret files for Compose; Vault/External Secrets for Kubernetes

Check data integrity along the data path

Data integrity concerns whether data stays consistent and changes are controlled. Check, for example, whether customer keys still match the right orders after import and whether a transformation unexpectedly multiplies rows. Access rules and audit logs complement business quality checks. A traceable access event alone does not establish that a value is correct.