An MCP server that passes your rights through instead of around

Why agents on company data fail

When an assistant reaches the warehouse through a technical catch-all account, it sees everything — and so does anyone who asks it cleverly. The usual answer is a second permission model just for the agent, sitting beside the real one and drifting apart from it over time.

lavalake takes another route: the agent gets no account of its own. It works with the same exchanged token you do. What you may not see, it does not see in your session either — without a single extra rule to maintain.

An agent with its own rights is a second permission model. Two permission models always drift apart.

Curated tools instead of open SQL

The agent does not get an open database connection but a list of tools: explore catalogs and schemas, describe tables, run read-only queries, search semantically, fetch metrics from the semantic layer, create dashboards, manage roles in Keycloak, start imports.

trino_list_catalogs        read
trino_list_schemas         read
trino_describe_table       read
trino_run_readonly_query   read
semantic_search            read
query_semantic_metric      read
list_semantic_metrics      read

inspect_csv / import_csv       mutating
define_semantic_metric         mutating
create_dashboard               mutating
add_dashboard_tile             mutating
keycloak_assign_role           mutating

trino_drop_table               destructive
delete_dashboard               destructive
delete_semantic_metric         destructive

trino_execute_statement    classified per statement
platform_pod_status        read

Because the tools are named, what an agent did stays legible afterwards. A log of free-form SQL answers the question “what happened here” poorly; a log of tool calls answers it well.

Gate, audit, run

Every tool call passes three stages. First classification: is this read, mutating or destructive? For free-form SQL a classifier decides per statement, not by tool name. Then the audit entry. Only then execution — and for mutating and destructive steps, only after your confirmation.

The model stays your decision

No model key ships with the platform. You choose the backend: your own API key, a self-hosted model with an OpenAI-compatible endpoint, or a per-user Claude sign-in. Semantic search needs no backend at all — the embedding model runs locally.

• Your own API key for an external provider
• A self-hosted model behind an OpenAI-compatible endpoint
• Per-user Claude sign-in, with the gates intact
• Embeddings always local, no key
• AWS Bedrock as a providerIn development
• Natural language to SQL against curated metricsIn development

The agent can build the model itself

Because the assistant may read catalogs and schemas and define metrics, it can propose and create the semantic layer out of your own data — every step with a confirmation, every step in the log. That is the part that otherwise sits untouched for months because nobody has time to define metrics.