akko-mcp-trino

Un serveur MCP gouverné pour Trino, dont le cœur est open source. Chaque tool call peut porter l'identité de l'utilisateur ; Trino et sa policy décident.

akko-mcp-trino donne à vos agents IA un accès à Trino sans leur donner vos données. Chaque tool call peut porter l’identité de la personne pour qui l’agent travaille, et la requête s’exécute alors dans Trino sous cette identité. Ce que cette personne a le droit de lire est décidé dans le moteur, par la policy que vous appliquez déjà (OPA, Ranger ou le contrôle d’accès de Trino). Le serveur ne décide jamais l’accès lui-même.

Le cœur du serveur est open source, sous licence Apache 2.0, et porte déjà l’identité de chaque utilisateur jusqu’à Trino ; la dernière section le présente. AKKO et ARCHE livrent le serveur complet, prêt pour l’entreprise. Pour suivre une question de bout en bout, lisez Comment ça marche. Pour comprendre le serveur en cinq minutes, sur les vraies données du sandbox, suivez le parcours en cinq niveaux.

La même question, trois réponses

Même question, trois réponses : carol_analyst voit 5 lignes aux e-mails masqués, alice_admin 10 lignes en clair, dave_viewer est refusé par la policy.

Ces réponses sont réelles. Elles viennent du sandbox : Trino derrière Keycloak et OPA, avec des données fictives. Même SQL, même serveur. Trino exécute sous le nom de chaque personne, et la policy décide. Le modèle n’a pas besoin de savoir qui est restreint.

Le principe

La personne se connecte à l’identity provider (IdP) que vous avez déjà. Le MCP host présente son identité à chaque appel, le serveur la vérifie, et la requête s’exécute dans Trino sous cette identité. Trino interroge sa policy, applique le périmètre, les row filters et les column masks de la personne, et ne rend que ce qu’elle aurait pu lire depuis n’importe quel autre client.

Une requête sans identité vérifiée est refusée ; elle n’est jamais exécutée sous un autre nom. Dans le cœur open source, le serveur échange le token de la personne contre un token émis pour Trino, et Trino vérifie ce second token avant d’exécuter quoi que ce soit. Le token de la personne ne quitte jamais le serveur. Deux personnes qui posent la même question au même serveur obtiennent deux réponses différentes.

Ce qu’un agent peut faire

Un agent trouve les tables et les colonnes qui contiennent ce qu’il cherche, à partir de quelques mots de leurs noms ou de leurs commentaires. Il décrit un schéma entier ou une table, parcourt les catalogs, les schémas et les tables qu’il a le droit de voir, vérifie une requête et l’exécute en lecture. La découverte passe elle aussi sous l’identité de la personne : une table interdite n’apparaît ni dans une recherche ni dans une liste. Les descriptions des tools sont écrites pour un modèle et précisent qu’une valeur masquée ou une ligne absente est la policy d’accès, pas une erreur à relancer.

Lecture seule et bornes

La lecture seule est décidée sur l’arbre syntaxique de la requête, jamais sur son premier mot. Une requête est refusée si elle contient plus d’une instruction, ou si une écriture (INSERT, UPDATE, DELETE, MERGE, CREATE, DROP, ALTER, GRANT, CALL, SET) apparaît n’importe où dans l’arbre, CTE, sous-requêtes et EXPLAIN compris. EXPLAIN ANALYZE est refusé, puisqu’il exécute ce qu’il explique. Les table functions (TABLE(...)) et le catalog system sont refusés aussi. Le blog raconte pourquoi.

Chaque identifiant est validé avant d’entrer dans le SQL. Les résultats sont plafonnés, le reste d’une requête coupée est annulé dans Trino, et des budgets de temps par requête et par appel annulent ce qui dépasse.

L’audit

Chaque appel de tool laisse une ligne d’audit, indexée par l’identifiant de la requête : qui a appelé quel tool, avec quel résultat, en combien de temps. La ligne n’a aucun champ qui pourrait contenir un token ou le texte SQL, et une erreur y figure sous forme de code, jamais de message, parce qu’un message de Trino peut citer une valeur lue dans une ligne.

Ce qui a été prouvé

Des scripts rejouables tournent contre un cluster réel, Trino derrière Keycloak et OPA.

Preuve	Ce qu’elle vérifie	Résultat
Deux personnes	Trino voit carol puis alice comme utilisateur courant, les emails sont masqués pour carol et en clair pour alice, une requête sans identité est refusée, aucun token dans le journal du serveur	réussie
Adverse	deux personnes en parallèle sans aucune réponse croisée, écritures directes et cachées (`WITH`, `EXPLAIN ANALYZE`), instructions multiples, table function, catalog `system`, injections dans les identifiants, tokens signés par une autre clé ou expirés, plafond de lignes tenu	aucun passage
Agent Mistral	un modèle pilote les tools et rend deux réponses différentes pour deux personnes	10/10
Cœur open source, identité par utilisateur	intégration réelle à chaque pull request, 0.7.0 comprise, Keycloak et Trino : échange de tokens, impersonation par certificat client, mode `service`, chaque refus à la porte ; dans le sandbox, sur la 0.7.0, deux comptes et deux réponses, un `401` pour une requête sans token, un token falsifié et un token émis pour Trino, et la suite de la 0.7.0 (recherche, pagination, colonnes cachées, le `kind` des erreurs) en direct et derrière Trino Gateway	réussie, 153/153 dans chaque cas
Liste blanche de lecture (0.7.2)	dans le sandbox, en direct et derrière Trino Gateway : `SHOW STATS`, `EXPLAIN`, `SHOW CREATE`, `SHOW GRANTS` et `SHOW SESSION` refusés, `explain_query` sans plan, les lectures utiles à un agent toujours servies sous les mêmes règles, et chaque commande rouverte seulement par son nom ; intégration réelle Keycloak et Trino à chaque pull request	réussie dans chaque cas

Dans AKKO et ARCHE

AKKO et ARCHE livrent ce serveur complet, prêt pour la production en entreprise. Ils ajoutent au cœur ce qu’une organisation demande en plus.

D’autres façons de porter l’identité de chaque utilisateur, adaptées au Trino tel que votre équipe l’exploite.
Rien n’échappe aux règles du moteur, ni les données, ni les descriptions, ni les métadonnées.
Un audit complet de chaque appel, que vos équipes de sécurité relient au journal du moteur.
Le contexte métier du catalogue pour le modèle, sans jamais décrire ce que la personne ne voit pas.
La gestion des agents et des accès, qui dit quels produits appellent, pour qui et dans quelles limites.
L’exploitation en entreprise, installée et suivie avec le reste de la plateforme.

Pour toute question, écrivez à contact@akko-ai.com.

Le cœur open source

Le cœur de akko-mcp-trino est publié sous licence Apache 2.0, en version 0.7.2. Il donne à un agent un accès MCP en lecture seule à Trino, avec huit tools pour trouver où vit la donnée, décrire un schéma ou une table, lister les catalogues, les schémas et les tables, expliquer et exécuter une requête. Il applique la même garde de lecture seule et les mêmes bornes, et il écrit une ligne d’audit par appel.

Il lit par défaut sous l’identité de chaque utilisateur (mode jwt). Le serveur vérifie le token émis pour lui et l’échange contre un token émis pour Trino (RFC 8693). Trino exécute alors la requête sous le nom de la personne, et Ranger ou OPA décident pour elle. Sans échange de tokens, le mode impersonation fait exécuter la requête au nom de l’appelant par le compte du serveur, sous une règle d’impersonation réservée à ce seul compte. Une identité unique (mode service) n’est prise que si l’administrateur la nomme, et le serveur l’annonce. Sa documentation complète donne les tools, la configuration et les exemples, et le guide Brancher Claude Desktop ou Cursor le relie à votre MCP host, du sandbox à un serveur d’équipe.

pip install akko-mcp-trino

Le code, les tests et les exemples sont sur GitHub. Les changements sont tenus dans le journal des versions, et une vulnérabilité se signale selon la politique de sécurité.