Imposer des permissions à ses agents IA avec un proxy
Salut salut,
Pas un post habituel pour ce sub avec un long partage d'expérience sur commun on tente de limiter les périmètres d'actions nos agents dans ma boîte. C'est en réaction au post de totolitotix sur les libertés que s'accordent un LLM et la diffculté de les confiner : reddit.com
Vu le nombre de réactions sur le post original, ca pourra peut être être utile à d'autres (désolé pour le pavé pour les autres : )
Notre équipe a cherché un système pour éviter de fuiter des credentials vers les agents pour les circonscrire à leur tâche uniquement.
On a d'abord envisagé un secret manager en local qui stockerait tous les identifiants que les agents peuvent utiliser, mais la surface à nettoyer pour garantir l'absence de fuites de la part des users est trop importantes à couvrir en temps réel. On a retrouvé nos secrets éparpillés partout : navigateur, mémoire, slack. Même si on cleanait tout, les agents finiraient toujours par les retrouver à un moment ou à un autre. En plus, le secret manager ne permettait pas de visualiser simplement les droits des agents et leur activité réelle sur les bdd. Pour ceux qui veulent creuser : infisical a une solution OpenSource sympa : Infisical/agent-vault
On s'est ensuite tournés vers une couche au plus proche de la base de données et on a découvert des proxys MCP comme Query Shields : queryshield.dev, mais on n'a pas vu l'intérêt d'avoir un endpoint unique qu'on interroge en langage naturel, avec le LLM du proxy qui reconstruit une requête selon ses droits. Ca paraît à la fois overkill, gourmand en tokens (puisque chaque requête est tokenisée) et une boîte noire non sécurisée (puisque c'est le LLM qui décide quelle requête est réalisée). Finalement on s'est dit qu'il suffisait juste que le proxy renvoie une table de droits et la doc de l'API avec une description et les limites imposées pour chaque route.
Donc on est partis sur un montage open source simple avec :
• d9 en proxy : LaWebcapsule/d9 (un fork communautaire d'un produit qui s'est privatisé et que les IA manipulent très bien // dont je suis maintener //), qui génère instantanément un ensemble d'API sécurisées avec une gestion fine des permissions sur une BDD existante. Ce proxy agit comme fournisseur d'authentification des agents avec des tokens tournants. L'approche doit marcher avec toutes autres solutions du genre.
• Keycloak : keycloak/keycloak comme fournisseur d'authentification des utilisateurs réels, qui gère le SSO et rattache chaque agent à l'humain qui en est responsable et (2FA quand jugé nécessaire)
C'était plutôt simple à mettre en place avec une supervision visuelle en temps réel de chaque agent, de ses permissions et de son activité.
Quelques captures d'écran d'un projet demo pour illustrer comment ça marche.
Si vous avez des meilleures pratiques, je suis aussi preneur et ca pourra peut être en aider d'autres :)
1 point · 3 comments
Mentions
@dfolloni Mas isso ja existia, inclusive open source, uso no meu hermes Infisical/agent-vault
Imposer des permissions à ses agents IA avec un proxy Salut salut, Pas un post habituel pour ce sub avec un long partage d'expérience sur commun on tente de limiter les périmètres d'actions nos agents dans ma boîte. C'est en réaction au post de totolitotix sur les libertés que s'accordent un LLM et la diffculté de les confiner : reddit.com Vu le nombre de réactions sur le post original, ca pourra peut être être utile à d'autres (désolé pour le pavé pour les autres : ) Notre équipe a cherché un système pour éviter de fuiter des credentials vers les agents pour les circonscrire à leur tâche uniquement. On a d'abord envisagé un secret manager en local qui stockerait tous les identifiants que les agents peuvent utiliser, mais la surface à nettoyer pour garantir l'absence de fuites de la part des users est trop importantes à couvrir en temps réel. On a retrouvé nos secrets éparpillés partout : navigateur, mémoire, slack. Même si on cleanait tout, les agents finiraient toujours par les retrouver à un moment ou à un autre. En plus, le secret manager ne permettait pas de visualiser simplement les droits des agents et leur activité réelle sur les bdd. Pour ceux qui veulent creuser : infisical a une solution OpenSource sympa : Infisical/agent-vault On s'est ensuite tournés vers une couche au plus proche de la base de données et on a découvert des proxys MCP comme Query Shields : queryshield.dev, mais on n'a pas vu l'intérêt d'avoir un endpoint unique qu'on interroge en langage naturel, avec le LLM du proxy qui reconstruit une requête selon ses droits. Ca paraît à la fois overkill, gourmand en tokens (puisque chaque requête est tokenisée) et une boîte noire non sécurisée (puisque c'est le LLM qui décide quelle requête est réalisée). Finalement on s'est dit qu'il suffisait juste que le proxy renvoie une table de droits et la doc de l'API avec une description et les limites imposées pour chaque route. Donc on est partis sur un montage open source simple avec : • d9 en proxy : LaWebcapsule/d9 (un fork communautaire d'un produit qui s'est privatisé et que les IA manipulent très bien // dont je suis maintener //), qui génère instantanément un ensemble d'API sécurisées avec une gestion fine des permissions sur une BDD existante. Ce proxy agit comme fournisseur d'authentification des agents avec des tokens tournants. L'approche doit marcher avec toutes autres solutions du genre. • Keycloak : keycloak/keycloak comme fournisseur d'authentification des utilisateurs réels, qui gère le SSO et rattache chaque agent à l'humain qui en est responsable et (2FA quand jugé nécessaire) C'était plutôt simple à mettre en place avec une supervision visuelle en temps réel de chaque agent, de ses permissions et de son activité. Quelques captures d'écran d'un projet demo pour illustrer comment ça marche. Si vous avez des meilleures pratiques, je suis aussi preneur et ca pourra peut être en aider d'autres :)