Vos agents IA voient exactement ce que l'utilisateur a le droit de voir

Un agent IA qui interroge vos données a besoin d’un compte pour se connecter. Dans la plupart des montages que nous voyons, ce compte est unique, technique, et large. Tous les agents, tous les utilisateurs, tous les prompts lisent alors avec les mêmes droits. La question « cet utilisateur a-t-il le droit de voir cette colonne ? » n’est plus posée au moteur de données ; elle est déléguée, sans le dire, au modèle de langage et à son prompt système.

Nous pensons que c’est le mauvais endroit pour la poser. akko-mcp-trino, notre serveur MCP pour Trino, remet la question là où elle a toujours été tranchée : dans le moteur, sous l’identité de la personne pour qui l’agent travaille.

Le problème, concrètement

Prenez une table de clients avec une colonne d’emails, un filtre par pays pour les analystes et un masque sur les emails pour tout le monde sauf les administrateurs. Votre BI le respecte. Vos notebooks le respectent. Vos requêtes SQL le respectent, parce que Trino demande à OPA ou à Ranger avant chaque lecture, et que ces moteurs connaissent l’utilisateur.

Branchez maintenant un agent avec un compte technique. Le filtre par pays disparaît. Le masque disparaît. Et ce qui les remplace, c’est une phrase dans un prompt système qui dit au modèle de ne pas montrer les emails. Une injection de prompt, un utilisateur insistant, ou simplement un modèle qui interprète mal une consigne, et la table sort entière.

Ce n’est pas un problème de modèle. C’est un problème d’identité : le moteur ne sait plus pour qui il travaille.

Ce que fait akko-mcp-trino

Le serveur reçoit, à chaque appel d’outil, le jeton de l’utilisateur, celui que votre fournisseur d’identité lui a délivré en se connectant. Il vérifie la signature contre les clés publiques du fournisseur, l’émetteur, l’audience, l’expiration. Puis la requête s’exécute dans Trino sous l’identité de cette personne.

À partir de là, rien de nouveau ne se passe, et c’est tout l’intérêt. Trino interroge son moteur de politique comme il le fait pour n’importe quel client. Le filtre par pays s’applique. Le masque s’applique. Le périmètre de catalogues s’applique. L’agent reçoit ce que l’utilisateur aurait obtenu en tapant la requête lui-même.

Le serveur ne décide jamais l’accès. Il ne connaît pas vos règles, et ne veut pas les connaître. Mettre de la politique dans un serveur intermédiaire, c’est la dupliquer, puis, un jour, la contredire.

La même question, deux réponses

Nous avons fait tourner un modèle Mistral sur ce serveur, avec un agent de quatre-vingts lignes qui lui expose les outils. Même question, même serveur, même modèle, deux jetons.

Le modèle ne savait pas que carol était restreinte. Il n’y avait rien à ce sujet dans son prompt. Il a exploré le catalogue, décrit la table, écrit la même requête SQL dans les deux cas, et rendu ce que Trino lui a donné.

Ce qu’il y a autour

Porter l’identité ne suffit pas à faire un serveur qu’on peut exposer à des agents. Quelques choses que nous avons ajoutées, parce que nous en avions besoin nous-mêmes.

Lecture seule décidée sur l’arbre syntaxique. Un contrôle par mot-clé de tête laisse passer WITH w AS (DELETE FROM t) SELECT 1. Le serveur analyse la requête et refuse une écriture où qu’elle se trouve, CTE et sous-requêtes compris.

Des bornes. Un plafond de lignes, un budget de temps par requête et par appel d’outil ; ce qui dépasse est annulé dans Trino.

Un identifiant de requête et une ligne d’audit par appel. La ligne dit qui a appelé quel outil, avec quel résultat et en combien de temps. Jamais le jeton lui-même : la structure de la ligne n’a pas de champ pour le contenir.

Tout cela est dans le cœur open source. Dans AKKO et ARCHE, le serveur va plus loin, avec 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.

Ce que les preuves nous ont appris

Nous ne faisons pas confiance à une suite de tests unitaires verte. Des centaines de tests à cent pour cent de couverture, c’est nécessaire, pas suffisant. Trois scripts rejouables tournent contre un cluster réel, Trino derrière Keycloak et OPA, sans rien redéployer.

Le premier vérifie les gardes une à une et la démonstration à deux comptes. Le deuxième est adverse : deux utilisateurs sur quatre sessions chacun, trois appels par session, tous en même temps, sur les deux transports MCP ; écritures, instructions empilées, injections dans les identifiants, jetons signés par une autre clé, jetons expirés, en-tête d’utilisateur forcé par l’utilisateur restreint. Le troisième fait piloter le serveur par un modèle.

Le deuxième a trouvé un vrai défaut avant la publication. La garde de lecture seule était testée, verte, et fausse : elle regardait le nœud racine de l’arbre, et un DELETE dans un CTE passait. Trino le refusait ensuite comme erreur de syntaxe, ce qui n’est pas une protection. Le troisième en a trouvé un autre, plus humble : les modèles terminent leur SQL par un point-virgule, Trino le refuse, et l’agent a relancé douze fois la même requête. Le serveur retire maintenant ce point-virgule.

Si nous avions publié après les tests unitaires, ces deux défauts seraient sortis avec le code.

Où ça s’installe

N’importe où il y a un Trino et un fournisseur OIDC. Trino 351 et suivants. OPA, Ranger ou le contrôle d’accès fichier de Trino pour décider. Keycloak, Entra ID, Okta ou tout autre fournisseur qui publie un JWKS. Une ligne dans le mcp.json de l’hôte suffit à y brancher un agent.

Le cœur open source est sous licence Apache 2.0, sur github.com/AKKO-p/akko-mcp-trino. Il lit soit sous une identité que l’administrateur configure, soit sous celle de chaque utilisateur quand Trino fait confiance au même fournisseur d’identité : Trino vérifie alors lui-même le jeton de la personne. Sa documentation le décrit.

Il s’installe avec pip install akko-mcp-trino.

La documentation donne les garanties et le détail des preuves.

Pourquoi cette brique

AKKO construit des briques d’accès gouverné pour les agents, sur les moteurs et les annuaires que les entreprises ont déjà. Celle-ci est la première, et la plus simple à expliquer : l’agent apporte l’identité, le moteur décide. Les suivantes s’occuperont du passage de l’identité d’un annuaire à l’autre, de la synchronisation des politiques depuis le catalogue, et de la mesure, chacune avec ses preuves.

Si vous faites tourner Trino derrière Ranger ou OPA et que vous voulez mettre une identité devant vos agents, le serveur est prêt.