Nous travaillons sur une instance Dinum, et une collègue m’a alertée dernièrement sur la possibilité de connecter un assistant IA directement à nos fichiers. Est-il possible de désactiver cette fonctionnalité ? Lorsqu’un collaborateur avec le statut owner connecte un assistant IA, les autres owners le voient-ils quelque part ?
Si la réponse est non à ces deux questions : comment gérez-vous ce très gros risque potentiel sur la sécurité des données ?
De ce que j’ai pu lire sur les différents connecteurs pour les modèles d’IA (les fameux MCP) ils utilisent “tout simplement” la clé API de l’utilisateur.
C’est une fonctionnalité qui n’est pas liée aux AI, chaque utilisateur peut récupérer dans Grist sa clé API, et avec elle n’importe qui peut avoir les mêmes accès en lecture/écriture que lui.
Je ne pense pas qu’il soit possible de désactiver la génération de la clé qui est liée au profil utilisateur, après est-ce que l’on peut restreindre les requêtes de l’api uniquement au url interne de l’instance je ne sais pas mais ca ne me dit rien.
Une bonne pratique toutefois, serait de dire à vos collègues d’utiliser à minima un compte de service, un utilisateur “fictif” auquel vous pourrez donner des permissions très restreintes et lié très précisément aux tables/colonnes souhaitées.
Merci beaucoup pour cette réponse, qui clarifie de mon côté que ce mécanisme utilise la clé api, ce qui est bien en soi un souci. Il s’agit donc d’informer en amont les utilisateurs sur les dangers de la pratique, d’autant plus s’il n’y a pas moyen de voir a posteriori si quelqu’un a transmis sa clé à un agent IA.
Nous explorerons la piste des comptes de services si nous avons réellement besoin d’utiliser l’ia directement sur les données. La possibilité de limiter dans le temps la durée de vie de la clé api associée à cet utilisateur “fictif” est très intéressante !
J’irai même beaucoup plus loin en disant que seule une clé API d’un compte de service avec une date de fin est tolérable/possible.
Le partage d’une clé API personnelle ne doit jamais arriver. C’est limité aux développeurs qui savent (normalement) ce qu’ils font, et même là le passage par un compte de service est à favoriser.