Deno vient de rendre open-source son pare-feu pour agents (Claw Patrol)

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00Voici Claw Patrol, un pare-feu de sécurité open source conçu par l'équipe Dino, qui se place entre

00:00:04vos agents IA et Internet, et résout trois problèmes de sécurité majeurs liés aux agents IA.

00:00:09L'accès n'est pas un contrôle réel, votre agent ne doit pas voir les secrets, et vous ne pouvez pas voir ce que votre agent

00:00:14a fait. J'ai testé pas mal d'outils de sécurité pour agents IA récemment, et j'aime vraiment l'approche

00:00:19adoptée par Claw Patrol ici, mais ce n'est pas encore parfait. Alors, comment fonctionne Claw Patrol : vous avez

00:00:28un serveur appelé la passerelle, qui contient vos règles, vos identifiants, vos journaux et le tableau de bord

00:00:32Claw Patrol, et ensuite vous avez un certain nombre de machines qui exécutent des agents, et elles peuvent rejoindre

00:00:36cette passerelle et faire transiter le trafic de leurs agents par celle-ci. En fait, vous pouvez choisir d'exécuter des commandes uniques

00:00:40via la passerelle, ou vous pouvez y ajouter toute votre machine. Dans mon cas, ma passerelle est simplement un serveur Ubuntu

00:00:45auquel je me connecte avec Tailscale, que Claw Patrol prend en charge nativement, ainsi que

00:00:50WireGuard ou les deux, et mes agents sont mon Mac et mon serveur OpenClaw. J'exécute la passerelle OpenClaw

00:00:55via Claw Patrol, et sur mon Mac, j'utilise simplement la commande d'exécution unique avec Clawd quand j'en ai besoin.

00:01:00Avec ce contexte, examinons les trois problèmes clés que Claw Patrol résout, et je vais

00:01:04commencer par le numéro deux, à savoir que vos agents ne devraient pas voir les secrets, car cela mène naturellement aux

00:01:09autres problèmes. Donc, sur la passerelle Claw Patrol, vous pouvez configurer vos identifiants comme les utilisateurs Postgres,

00:01:14les abonnements Clawd, les comptes GitHub, et tous les jetons d'accès ou en-têtes personnalisés, comme je l'ai fait ici pour mon

00:01:19serveur API de production. Grâce à cela, lorsque nous exécutons nos agents via la passerelle en utilisant cette commande

00:01:25Claw Patrol, ils n'ont besoin d'aucun de ces identifiants pour que les requêtes fonctionnent. Ils seront simplement

00:01:30injectés lorsque la requête passera par la passerelle. Donc, si je demande à Claw d'utiliser mon API et ma

00:01:35base de données pour me donner un aperçu des deux, il peut le faire sans aucun problème, et je peux voir sur

00:01:41les commandes qu'il exécute réellement qu'il n'inclut aucune clé API pour ces requêtes curl,

00:01:46alors qu'il en a besoin, et pour Postgres, il utilise juste un faux mot de passe X qui n'est certainement pas le vrai

00:01:51mot de passe, mais il se connecte quand même et récupère les informations pertinentes, car la passerelle a

00:01:56effectivement intercepté ces requêtes et attaché les vrais identifiants. Cela signifie que l'agent n'a jamais

00:02:00accès aux vraies valeurs, donc si quelqu'un voyait les journaux de mon agent ou tentait une injection de prompt,

00:02:06il n'obtiendrait jamais ces identifiants car ils résident sur un serveur complètement séparé, et l'agent n'a

00:02:10aucun moyen d'y accéder. Juste pour montrer ce processus d'injection encore plus clairement, si j'exécute cette requête curl sur mon

00:02:15terminal ici, vous pouvez voir qu'elle est rejetée parce que je n'ai pas fourni de clé API, mais si j'exécute exactement

00:02:20la même commande via claw patrol run, les données sont renvoyées normalement car cette clé API est injectée.

00:02:26Le problème suivant que Claw Patrol vise à résoudre est que l'accès n'est pas un contrôle d'action. Claw Patrol vous donne

00:02:31un contrôle très précis sur ce qu'un agent peut faire avec une requête. Par exemple, si j'utilise à nouveau ce

00:02:36skill Postgres, mais que cette fois je lui demande de supprimer une table et d'en créer une nouvelle, quand il l'exécute, il renvoie immédiatement

00:02:41un message d'erreur personnalisé que j'ai configuré, indiquant que les changements de schéma ne se font que via des PR

00:02:46de migration, pas via l'agent. La passerelle a effectivement analysé la requête Postgres que mon agent a faite,

00:02:51et elle l'a vérifiée par rapport à un ensemble de règles que j'ai défini, et grâce à l'une de mes règles, elle a refusé

00:02:56la requête de suppression de table. Une autre façon de gérer cela est d'utiliser un humain dans la boucle, donc je peux

00:03:00faire en sorte que cette règle fasse appel à moi pour approuver l'action. Pour le moment, celle-ci ne prend en charge que

00:03:04Slack, mais d'autres options arrivent bientôt. Il existe même une option pour utiliser un LLM comme juge,

00:03:09et les règles sont incroyablement personnalisables et flexibles, vous pouvez donc même avoir des règles comme vérifier

00:03:13votre point de terminaison d'API de support client qui envoie des réponses, et vous pouvez voir s'il y a du contenu

00:03:18offensant, des salutations manquantes, ou simplement tout ce que vous ne voulez pas voir fuiter dans cette requête. Et encore une fois,

00:03:22tout cela étant effectué sur la requête au niveau de la passerelle signifie que théoriquement tout cela est protégé contre

00:03:27les injections de prompt et pratiquement tous les autres types d'attaques IA. Le troisième problème que Claw Patrol

00:03:31résout, c'est que vous ne pouvez pas voir ce que l'agent a fait, mais avec Claw Patrol, chaque requête est visible dans

00:03:37le tableau de bord ici, et vous pouvez même voir les sessions actives ainsi que les jetons utilisés, et si vous cliquez

00:03:42sur une requête, vous pouvez voir les détails pertinents comme la commande postgres qui a été réellement exécutée,

00:03:46ou dans le cas d'un appel API, vous pouvez voir la requête API ainsi que la réponse qu'elle a reçue.

00:03:51De cette façon, vous n'avez pas besoin de passer du temps à parcourir tous les journaux des services individuels

00:03:55que l'agent a touchés pour essayer de comprendre ce qu'il a fait, et au lieu de cela, vous pouvez simplement voir ce qu'il a fait

00:03:59au moment de la requête, vous devriez donc voir pratiquement tout ce que l'agent fait.

00:04:03Voilà les trois problèmes que Claw Patrol vise à résoudre, mais comment tout cela est-il configuré ? Eh bien,

00:04:07une fois que Claw Patrol est installé, la passerelle est entièrement configurée avec un seul fichier HCL.

00:04:12Ici, vous définissez les différents points de terminaison pour lesquels vous aurez des règles et des identifiants,

00:04:16donc j'en ai divers comme OpenAI, Slack, SSH, Postgres, et ainsi de suite, donc si une requête passe

00:04:22par la passerelle et correspond à l'un d'eux, elle sait qu'elle doit vérifier les règles et les identifiants.

00:04:26Quant aux identifiants eux-mêmes, leur configuration est également assez simple.

00:04:30Vous indiquez le type d'identifiant et le point de terminaison auquel cet identifiant doit correspondre.

00:04:34Il existe une prise en charge de nombreux types d'identifiants comme les abonnements Anthropic, Codex,

00:04:39ClickHouse, Postgres, ainsi que les bases comme les jetons d'accès et les en-têtes personnalisés,

00:04:43vous devriez donc trouver qu'il prend en charge presque tous les types dont vous avez besoin,

00:04:46et même s'il ne le fait pas, vous pouvez coder des plugins pour ajouter votre propre type.

00:04:50Une fois que vous avez défini un identifiant ici, il vous suffit de vous rendre sur le tableau de bord pour remplir

00:04:54la valeur réelle. La configuration des règles est également assez facile.

00:04:56Vous indiquez simplement le point de terminaison auquel la règle va s'appliquer, puis vous écrivez la règle

00:05:00en utilisant le langage d'expression commun (CEL), donc cela peut couvrir un large éventail de choses comme HTTP,

00:05:05Postgres, Kubernetes, etc. Ensuite, vous indiquez le verdict pour la règle que vous venez

00:05:09de définir, si vous approuvez ou refusez en fonction de celle-ci, et vous utiliseriez “approuver” ici si vous créiez

00:05:14une approche basée sur une liste d'autorisation plutôt qu'une liste de blocage, donc vous bloqueriez tout par défaut puis

00:05:18n'autoriseriez que certaines choses. Dans mon cas cependant, j'ai simplement utilisé la méthode de la liste de blocage.

00:05:22Enfin, une autre fonctionnalité très utile ici est les profils. Vous pouvez en effet regrouper vos identifiants

00:05:26en plusieurs profils, ce qui signifie que toutes les règles et tous les points de terminaison attachés à ces identifiants

00:05:31sont également regroupés avec eux, et cela vous permet de mettre en place une sorte de contrôle basé sur les rôles pour vos

00:05:35agents et vos équipes, ainsi les développeurs peuvent avoir certains accès aux identifiants et des règles différentes pour

00:05:40eux, et peut-être qu'une autre équipe, comme une équipe de support, a des identifiants et des règles différents également.

00:05:45Pour vous aider lorsque vous apportez des modifications aux règles, il existe en fait une commande de test où vous pouvez

00:05:49télécharger les actions de règle depuis le tableau de bord, puis les réexécuter par rapport à vos modifications locales pour voir si

00:05:54l'une d'entre elles a changé le résultat, afin que vous puissiez repérer s'il va y avoir des fuites accidentelles.

00:05:59Je dois admettre que j'ai trouvé ce processus de configuration un peu fastidieux, et je suis sûr qu'il sera

00:06:02amélioré bientôt, car nous sommes au tout début de la vie du projet, mais s'il y avait juste un moyen simple d'ajouter

00:06:07des identifiants et des règles depuis le tableau de bord, ce serait absolument génial. Peut-être quelque chose de similaire à

00:06:11la façon dont fonctionne AdGuard, où vous pouvez simplement voir une requête passer et cliquer pour ajouter une règle ou

00:06:15un identifiant pour cette requête. J'ai aussi rencontré beaucoup de problèmes lorsque j'essayais d'ajouter des points de terminaison

00:06:19qui étaient simplement des adresses IP vers mon serveur Proxmox local. Pour une raison quelconque, il ne voulait tout simplement pas

00:06:24intercepter ces requêtes, et je ne pouvais en voir aucune apparaître sur le tableau de bord, et cela m'a juste

00:06:28donné un peu mal à la tête. Donc, il y a certainement des correctifs nécessaires, ou peut-être que je l'utilisais mal,

00:06:33mais dans les deux cas, oui, il faudra du travail pour arriver à un point d'utilisabilité qui n'interrompt pas

00:06:38votre flux, mais cela a du sens puisque tout cela concerne la sécurité et pas seulement l'envoi d'un agent

00:06:43en mode YOLO. Dites-moi donc dans les commentaires ci-dessous ce que vous pensez de Claw Patrol, et si vous

00:06:47avez des outils de sécurité que vous utilisez pour vos agents. Pendant que vous y êtes, abonnez-vous, et comme

00:06:51toujours, on se voit dans la prochaine.

Key Takeaway

Claw Patrol sécurise les agents IA en agissant comme une passerelle qui injecte les identifiants à la volée, filtre les actions via des règles CEL et centralise l'observabilité des requêtes.

Highlights

Claw Patrol fonctionne comme une passerelle sécurisée entre les agents IA et Internet pour résoudre trois problèmes majeurs de sécurité.
L'injection automatique des identifiants (secrets) par la passerelle empêche l'agent d'y accéder directement, limitant les risques en cas d'injection de prompt ou de fuite de journaux.
Le contrôle granulaire des actions permet de bloquer des requêtes spécifiques, comme la suppression de tables de base de données, via une analyse en temps réel des requêtes.
Chaque requête effectuée par l'agent est enregistrée dans le tableau de bord, centralisant la visibilité des activités de l'agent sans nécessiter d'examen manuel des journaux de chaque service.
La configuration s'effectue via un fichier HCL unique, permettant de définir des règles, des identifiants et des profils de contrôle basés sur les rôles.
La prise en charge native de Tailscale et WireGuard facilite la mise en place de l'infrastructure de passerelle pour les agents distants.

Timeline

Problèmes de sécurité et architecture

Claw Patrol résout trois failles : l'exposition des secrets, l'absence de contrôle des actions et le manque de visibilité sur les activités de l'agent.
L'architecture repose sur une passerelle centrale traitant le trafic, compatible nativement avec Tailscale et WireGuard.

Cette passerelle sert d'intermédiaire entre les machines exécutant les agents et Internet. Elle centralise la gestion des règles, des identifiants et des journaux, offrant une couche de contrôle sur les requêtes sortantes.

Gestion des secrets par injection

Les identifiants sensibles (clés API, mots de passe Postgres) sont stockés sur la passerelle et non sur la machine de l'agent.
La passerelle injecte les vraies valeurs dans les requêtes curl avant leur exécution réelle.

L'agent n'a jamais accès aux identifiants réels, ce qui protège ces données contre les fuites accidentelles, les injections de prompt ou l'exposition dans les journaux. Cette technique permet aux agents d'effectuer des tâches authentifiées tout en manipulant des données factices ou vides en local.

Contrôle des actions et observabilité

Le filtrage des requêtes permet d'interdire des actions spécifiques, comme la modification de schéma sur une base de données.
Le tableau de bord offre une visibilité totale sur les sessions actives, les requêtes API et les commandes exécutées.

Les règles de contrôle analysent les requêtes en temps réel, permettant de bloquer des opérations non autorisées ou de demander une validation humaine. L'interface centralisée élimine le besoin de parcourir les journaux de chaque service pour auditer les actions de l'agent.

Configuration et limites actuelles

La configuration utilise un fichier HCL pour définir les points de terminaison, les identifiants et les règles (langage CEL).
Les profils permettent un contrôle basé sur les rôles pour différents agents ou équipes.
Le projet est à un stade précoce, rendant la configuration parfois fastidieuse et présentant des difficultés d'interception sur certaines infrastructures locales.

La mise en place nécessite de définir des règles de blocage ou d'autorisation. Bien que la fonctionnalité de test des règles permette de limiter les erreurs, l'ajout dynamique d'identifiants via le tableau de bord reste un axe d'amélioration important pour la fluidité d'utilisation.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video