AKKOAnalytics Kernel · Keep OwnershipDocumentationNous écrireEN

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 policy que vous avez déjà, exactement comme pour un outil de BI ou un notebook.

Le trajet d’une question

  1. La personne se connecte à l’identity provider de l’entreprise, ou IdP (Keycloak, Entra ID, Okta…).
  2. Le MCP host appelle un tool (Cursor, Claude Desktop, VS Code ou votre agent) et présente l’identité de la personne, par un token émis pour le serveur. Le modèle, lui, ne voit jamais ses secrets.
  3. Le serveur vérifie cette identité. Sans identité valide, la requête est refusée.
  4. Le tool 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.
  5. Trino exécute la requête sous l’identité de la personne. Sa policy applique le périmètre de catalogs, les row filters et les column masks.
  6. Le résultat revient, borné. Un plafond de lignes et des budgets de temps s’appliquent ; ce qui dépasse est annulé dans Trino.
  7. Une ligne d’audit est écrite. Elle dit qui a appelé quel tool, avec quel résultat et en combien de temps, sans jamais contenir de token 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 tools 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.
  • Un token émis pour Trino plutôt que pour lui.
  • Toute écriture, y compris cachée dans un WITH, une sous-requête ou un EXPLAIN ANALYZE.
  • Les table functions et le catalog system, qui contourneraient la policy 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 par défaut, en mode jwt. Le serveur échange le token de la personne, émis pour lui, contre un token émis pour Trino (RFC 8693). Trino vérifie ce second token et exécute la requête sous le nom de la personne. Le token de la personne ne quitte jamais le serveur. Le mode impersonation couvre les IdP qui ne savent pas échanger de tokens. Le mode service, une identité unique, n’est pris que s’il est nommé. 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 MCP host et écrire un agent. Le blog raconte les choix d’architecture et ce que les preuves nous ont appris.