Comment ça marche

Le fonctionnement de akko-mcp-trino de bout en bout, pour un responsable sécurité, un administrateur et un développeur d'agent.

Un agent IA qui interroge vos données agit pour quelqu’un. akko-mcp-trino fait en sorte que le moteur le sache, dans son cœur open source comme dans AKKO et ARCHE. Cette page suit une question de bout en bout ; la présentation donne ensuite les garanties, les preuves et le cœur open source.

Le principe en une phrase

Le serveur porte l’identité, le moteur décide. Le serveur ne connaît aucune règle d’accès aux données. Il fait exécuter chaque requête sous l’identité de la personne, et Trino applique la politique que vous avez déjà, exactement comme pour un outil de BI ou un notebook.

Le trajet d’une question

La personne se connecte au fournisseur d’identité de l’entreprise (Keycloak, Entra ID, Okta…).
L’hôte MCP appelle un outil (Cursor, Claude Desktop, VS Code ou votre agent) et présente l’identité de la personne. Le modèle, lui, ne voit jamais ses secrets.
Le serveur vérifie cette identité. Sans identité valide, la requête est refusée.
L’outil prépare son SQL. Les identifiants sont validés, et une requête qui écrit, où que ce soit dans son arbre, est refusée avant d’atteindre Trino.
Trino exécute la requête sous l’identité de la personne. Son moteur de politique applique le périmètre de catalogues, les filtres de lignes et les masques de colonnes.
Le résultat revient, borné. Un plafond de lignes et des budgets de temps s’appliquent ; ce qui dépasse est annulé dans Trino.
Une ligne d’audit est écrite. Elle dit qui a appelé quel outil, avec quel résultat et en combien de temps, sans jamais contenir de jeton ni le texte SQL.

Deux personnes, la même question

alice est administratrice ; carol est analyste, limitée aux clients français, et les emails lui sont masqués. Elles posent la même question à travers le même serveur et le même modèle. Le modèle écrit la même requête SQL dans les deux cas. Trino rend les emails en clair à alice, et à carol des emails masqués, uniquement pour la France. Le modèle n’a rien décidé ; il ne savait même pas que carol était restreinte.

Ce qu’un agent voit

Un agent voit ce que la personne verrait depuis n’importe quel autre client, et rien de plus. Cela vaut pour les données comme pour la découverte : lister les catalogues, les schémas et les tables passe aussi par Trino sous l’identité de la personne. Une table interdite n’apparaît donc pas dans les listes, et une tentative de la lire reçoit le refus de Trino, comme une erreur ordinaire que l’agent peut lire.

Une valeur masquée ou une ligne absente n’est pas une erreur. Les descriptions des outils le disent au modèle, pour qu’il ne relance pas la même requête en boucle.

Ce que le serveur refuse

Une requête sans identité vérifiée.
Toute écriture, y compris cachée dans un WITH, une sous-requête ou un EXPLAIN ANALYZE.
Les fonctions de table et le catalogue system, qui contourneraient la politique du moteur.
De démarrer avec une configuration incohérente.

Et le cœur open source

Le cœur, publié sous licence Apache 2.0, suit ce trajet en 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. En mode service, le mode par défaut, il s’exécute sous une identité unique que l’administrateur configure. AKKO et ARCHE ajoutent d’autres façons de porter l’identité de l’utilisateur, la gestion des agents et des accès, un audit relié au journal du moteur et le contexte métier du catalogue. La documentation du cœur donne le détail.

Pour aller plus loin

Les exemples montrent comment brancher un hôte et écrire un agent. Le blog raconte les choix d’architecture et ce que les preuves nous ont appris.