akko-mcp-trino

A governed MCP server for Trino, with an open source core. Every tool call can carry the user's identity; Trino and its policy engine decide.

akko-mcp-trino gives your AI agents access to Trino without giving them your data. Every tool call can carry the identity of the person the agent works for, and the query then runs in Trino under that identity. What that person may read is decided inside the engine, by the policy you already run (OPA, Ranger or Trino’s own access control). The server never decides access on its own.

The core of the server is open source, under the Apache 2.0 licence, and already carries each user’s identity down to Trino; the last section presents it. AKKO and ARCHE deliver the complete server, ready for the enterprise. To follow one question end to end, read How it works.

Same question, three answers

These answers are real. They come from the sandbox: Trino behind Keycloak and OPA, with fictitious data. Same SQL, same server. Trino runs as each person, and the policy decides. The model does not need to know who is restricted.

The idea

The MCP host calls a tool with the person's token; akko-mcp-trino verifies it; Trino verifies it again and runs as that person; the policy (OPA or Ranger) decides.

The person logs in to the identity provider you already have. The MCP host presents their identity on every call, the server verifies it, and the query runs in Trino under that identity. Trino asks its policy engine, applies the person’s catalog scope, row filters and column masks, and returns only what the person could have read from any other client.

A request without a verified identity is refused; it never runs under another name. In the open source core, Trino verifies the person’s token again before running anything. Two people asking the same question through the same server get two different answers.

What an agent can do

An agent explores the catalogs, schemas and tables it may see, describes a table, checks a statement and runs it read-only. Discovery also runs under the person’s identity: a forbidden table does not appear in the listings. Tool descriptions are written for a model and say that a masked value or a missing row is the access policy, not an error to retry.

Read-only and bounds

Read-only is decided on the syntax tree of the statement, never on its first word. A statement is refused if it holds more than one instruction, or if a write (INSERT, UPDATE, DELETE, MERGE, CREATE, DROP, ALTER, GRANT, CALL, SET) appears anywhere in the tree, CTEs, subqueries and EXPLAIN included. EXPLAIN ANALYZE is refused, since it executes what it explains. Table functions (TABLE(...)) and the system catalog are refused too. The blog tells why.

Every identifier is validated before it enters the SQL. Results are capped, the rest of a cut query is cancelled in Trino, and time budgets per query and per call cancel whatever runs past them.

The audit

Every tool call leaves one audit line, keyed by the request id: who called which tool, with which outcome, for how long. The line has no field that could hold a token or the SQL text, and an error appears as a code, never as a message, because a message from Trino may quote a value read from a row.

What has been proven

Replayable scripts run against a real cluster, Trino behind Keycloak and OPA.

Proof	What it checks	Result
Two people	Trino sees carol then alice as the current user, emails are masked for carol and in clear for alice, a request without an identity is refused, no token in the server log	passed
Adversarial	two people in parallel with no crossed answer, direct and hidden writes (`WITH`, `EXPLAIN ANALYZE`), stacked statements, table function, `system` catalog, injections in identifiers, tokens signed by another key or expired, row cap held	nothing got through
Mistral agent	a model drives the tools and gives two different answers for two people	10/10
Open source core, identity per user	two accounts on a Trino that verifies the token itself: emails masked for one, in clear for the other; a request without a token refused; a forged token refused	passed

In AKKO and ARCHE

AKKO and ARCHE deliver the complete server, ready for enterprise production. They add to the core what an organisation asks for on top.

Other ways to carry each user’s identity, suited to the Trino your team runs as it is.
Nothing escapes the engine’s rules, neither the data, nor the descriptions, nor the metadata.
A complete audit of every call, which your security teams join to the engine’s log.
The business context of the catalogue for the model, never describing what the person cannot see.
Agent and access management, which says which products call, for whom and within which limits.
Enterprise operations, installed and monitored with the rest of the platform.

For any question, write to contact@akko-ai.com.

The open source core

The core of akko-mcp-trino is published under the Apache 2.0 licence, as version 0.5.3. It gives an agent read-only MCP access to Trino, with six tools to list catalogs, schemas and tables, describe a table, explain and run a query. It applies the same read-only guard and the same bounds, and it writes one audit line per call.

It reads under one of two identities. By default, it is the identity the administrator configures, the same for every call (service mode). When Trino trusts the same identity provider, it is each user’s own (jwt mode): the server sends Trino the token it has verified, Trino verifies it again and runs the query under the person’s name. Ranger or OPA then decide for each person. Its full documentation gives the tools, the configuration and the examples.

pip install akko-mcp-trino

The code, the tests and the examples are on GitHub. Changes are tracked in the changelog, and a vulnerability is reported through the security policy.