How it works

How akko-mcp-trino works end to end, for a security officer, an administrator and an agent developer.

An AI agent that queries your data acts for someone. akko-mcp-trino makes sure the engine knows who, in its open source core as in AKKO and ARCHE. This page follows one question end to end; the overview then gives the guarantees, the proofs and the open source core.

The idea in one sentence

The server carries the identity, the engine decides. The server knows no data access rule. It has every query run under the person’s identity, and Trino applies the policy you already have, exactly as it does for a BI tool or a notebook.

The path of one question

The person logs in to the company’s identity provider (Keycloak, Entra ID, Okta…).
The MCP host calls a tool (Cursor, Claude Desktop, VS Code or your agent) and presents the person’s identity. The model never sees their secrets.
The server verifies that identity. Without a valid identity, the request is refused.
The tool prepares its SQL. Identifiers are validated, and a statement that writes, anywhere in its tree, is refused before it reaches Trino.
Trino runs the query under the person’s identity. Its policy engine applies the catalog scope, row filters and column masks.
The result comes back, bounded. A row cap and time budgets apply; whatever runs past them is cancelled in Trino.
One audit line is written. It says who called which tool, with which outcome and for how long, without ever holding a token or the SQL text.

Two people, the same question

alice is an administrator; carol is an analyst, limited to French customers, with emails masked. They ask the same question through the same server and the same model. The model writes the same SQL in both cases. Trino returns the emails in clear to alice, and masked emails to carol, for France only. The model decided nothing; it did not even know carol was restricted.

What an agent sees

An agent sees what the person would see from any other client, and nothing more. That holds for data as well as for discovery: listing catalogs, schemas and tables also goes through Trino under the person’s identity. A forbidden table therefore does not appear in the listings, and an attempt to read it gets Trino’s refusal, as an ordinary error the agent can read.

A masked value or a missing row is not an error. The tool descriptions tell the model so, so that it does not retry the same query in a loop.

What the server refuses

A request without a verified identity.
Any write, including one hidden in a WITH, a subquery or an EXPLAIN ANALYZE.
Table functions and the system catalog, which would bypass the engine’s policy.
Starting with an inconsistent configuration.

And the open source core

The core, published under the Apache 2.0 licence, follows this path in jwt mode: the server sends Trino the token it has verified, Trino verifies it again and runs the query under the person’s name. In service mode, the default, it runs under one identity the administrator configures. AKKO and ARCHE add other ways to carry the user’s identity, agent and access management, an audit linked to the engine’s log and the business context of the catalogue. The core documentation gives the details.

Going further

The examples show how to connect a host and write an agent. The blog tells the architecture choices and what the proofs taught us.