Nobody gets around the permissions — the agent included

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.

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
• Access, deletion, retention and classification as featuresIn development

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 separate process; secrets are stored AES-256-GCM encrypted.

• Three routes outward: console, agent API, Keycloak
• Egress guard against SSRF and metadata endpoints
• Document parsing process-isolated
• TLS between all servicesIn development
• Secrets through Vault or External SecretsIn development