akko-mcp-trino

Un serveur MCP gouverné pour Trino, dont le cœur est open source. Chaque appel d'outil peut porter l'identité de l'utilisateur ; Trino et son moteur de politique décident.

akko-mcp-trino donne à vos agents IA un accès à Trino sans leur donner vos données. Chaque appel d’outil 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 politique 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.

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

Le MCP host appelle un tool avec le token de la personne ; akko-mcp-trino le vérifie ; Trino le revérifie et exécute sous son nom ; la policy (OPA ou Ranger) décide.

La personne se connecte au fournisseur d’identité que vous avez déjà. L’hôte MCP 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 son moteur de politique, applique le périmètre, les filtres de lignes et les masques de colonnes 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, Trino vérifie à son tour le jeton de la personne avant d’exécuter quoi que ce soit. 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 explore les catalogues, les schémas et les tables qu’il a le droit de voir, décrit une table, 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 pas dans les listes. Les descriptions des outils sont écrites pour un modèle et précisent qu’une valeur masquée ou une ligne absente est la politique 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 fonctions de table (TABLE(...)) et le catalogue 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 d’outil laisse une ligne d’audit, indexée par l’identifiant de la requête : qui a appelé quel outil, avec quel résultat, en combien de temps. La ligne n’a aucun champ qui pourrait contenir un jeton 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 jeton 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, fonction de table, catalogue `system`, injections dans les identifiants, jetons signés par une autre clé ou expirés, plafond de lignes tenu	aucun passage
Agent Mistral	un modèle pilote les outils et rend deux réponses différentes pour deux personnes	10/10
Cœur open source, identité par utilisateur	deux comptes sur un Trino qui vérifie lui-même le jeton : emails masqués pour l’un, en clair pour l’autre ; requête sans jeton refusée ; jeton falsifié refusé	réussie

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.5.3. Il donne à un agent un accès MCP en lecture seule à Trino, avec six outils pour lister les catalogues, les schémas et les tables, décrire une table, 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 sous l’une de deux identités. Par défaut, c’est l’identité que l’administrateur configure, la même pour tous les appels (mode service). Quand Trino fait confiance au même fournisseur d’identité, c’est celle de chaque utilisateur (mode jwt) : le serveur transmet à Trino le jeton qu’il a vérifié, Trino le vérifie à son tour et exécute la requête sous le nom de la personne. Ranger ou OPA décident alors pour chaque personne. Sa documentation complète donne les outils, la configuration et les exemples.

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é.