Nous avons laissé un agent IA exécuter Bash et nous en sommes sortis vivants — Sarah Sanders, PostHog
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Salut tout le monde, comment allez-vous ? Nous sommes dans la dernière ligne droite. Je m'appelle Sarah et je suis ingénieure en contexte
00:00:23chez PostHog, et j'ai le grand plaisir de travailler sur notre cher assistant magique chaque jour.
00:00:30Alors, qu'est-ce que cet assistant ? Il configure PostHog pour vous. C'est un outil CLI agentique
00:00:39qui lit votre base de code, installe le bon SDK pour votre projet, instrumente
00:00:44vos événements et configure vos tableaux de bord. Ce qui prenait autrefois environ une ou deux heures
00:00:52de configuration est réalisé en cinq à six minutes environ, avec une inférence gratuite
00:00:57prise en charge par nos soins pour que votre intégration sur PostHog se passe au mieux. C'est plutôt cool. Les gens
00:01:03adorent. Mais il y a quelques mois, nous avons osé rêver : et si cela devenait la méthode recommandée ou par défaut
00:01:10pour installer PostHog sur votre projet ? Et mes alarmes de sécurité ont commencé à se déclencher.
00:01:17Je me suis demandé à quel point cet outil était sécurisé, car il avait un peu la forme d'un malware.
00:01:25Et en me posant ces questions, j'ai beaucoup appris. Donc aujourd'hui, nous allons parler des leçons que j'ai tirées,
00:01:31de ce qui m'a empêchée de dormir pendant que je construisais cet outil, et de ce que j'ai fini par créer
00:01:37à cause de tout cela. Alors avant de plonger dans toute la partie sécurité un peu ennuyeuse, alias votre sieste de 14 heures, je veux vous montrer l'assistant en action.
00:01:49Si vous regardez l'écran, il tourne en boucle pour vous. C'est exactement la même expérience que celle de toute personne qui exécute
00:01:56NPX PostHog Wizard sur son terminal. Comme je le disais, c'est un agent. Il détermine quel SDK convient à votre projet, l'installe pour vous, instrumente vos événements et crée des tableaux de bord.
00:02:10J'aime l'appeler un petit ingénieur d'implémentation miniature dans votre terminal. Et parfois, je montre cela aux gens et on me demande : pourquoi un agent ? Pourquoi ne pas donner un bon prompt aux utilisateurs ? Pourquoi ne pas leur donner une compétence qu'ils peuvent invoquer dans leur propre outil ?
00:02:23Et bien que nous fournissions ces options, la réponse est que cette expérience développeur et les capacités de l'assistant constituent tout l'intérêt. C'est le produit même.
00:02:34Parce que nous construisons un outil CLI capable de participer pleinement à une boucle d'agent, et faire l'expérience de cela pour la première fois est vraiment puissant.
00:02:43Mais on ne peut pas lancer un outil comme l'assistant sans y inclure ce qui le rend un peu suspect.
00:02:50Décortiquons-le donc. Analysons l'anatomie de l'assistant, car les modèles de menaces découlent généralement directement de l'anatomie de l'agent.
00:03:01L'assistant a une structure similaire à ce que beaucoup d'entre vous construisent probablement si vous concevez des agents.
00:03:07Il utilise des modèles choisis pour des tâches spécifiques, des prompts qui le guident et un ensemble d'outils que nous lui confions pour accomplir son travail.
00:03:17Mais il possède également des éléments qui nous sont propres. Il dispose d'un moteur de contexte entièrement conçu en interne par mon équipe.
00:03:25C'est ce qui permet à l'agent d'accomplir un excellent travail et de nous donner des résultats constants à chaque exécution.
00:03:30J'aime l'appeler le cerveau de l'assistant. Parfois, nous disons que c'est du Markdown déguisé.
00:03:35Mais c'est notre moteur de contexte maison. Il y a aussi une interface utilisateur de terminal que nous avons créée nous-mêmes avec Ink.
00:03:43Et désormais, il y a un scanner de sécurité appelé le warlock (le sorcier), que j'ai construit lorsque j'ai commencé à fouiner et à découvrir les horreurs du déploiement d'un agent en production.
00:03:55Donc, si l'on prend l'anatomie de n'importe quel agent capable d'exécuter des commandes, c'est basiquement ce que j'appelle le kit de démarrage du malware.
00:04:03Car c'est presque exactement ce que l'on confierait à un logiciel malveillant si l'on se sentait généreux ou d'une humeur chaotique maléfique.
00:04:11Heureusement, il s'agit du pire scénario possible ou du cauchemar éveillé, et ce n'est pas une confession de ma part, mais un avertissement pour vous tous.
00:04:19Car si vous voulez lancer un agent doté de mains, un agent capable d'exécuter des commandes, vous devez vous assurer de ne pas construire cela.
00:04:28La version 0 de l'assistant est née parce que Josh Snyder, si vous le connaissez dans notre équipe de croissance, regardait Cursor halluciner des configurations PostHog de la pire des manières.
00:04:41Et il s'est dit : et si nous construisions un agent capable de faire un meilleur travail ?
00:04:46Mon équipe a donc commencé à développer par-dessus alors que nous validions qu'il faisait un travail bien meilleur que les hallucinations de Cursor.
00:04:52Et nous nous sommes dit : et s'il pouvait intégrer n'importe qui sur PostHog ?
00:04:58Peu importe leur framework ou leur stack, il pourrait instrumenter tous leurs événements sans qu'ils aient à toucher à quoi que ce soit.
00:05:04Et puis nous avons osé rêver : et s'il devenait la méthode par défaut pour installer PostHog ?
00:05:09Nous rêvions de voir des milliers de développeurs l'utiliser chaque semaine, et hier, nous avons atteint 8 000 utilisateurs par semaine.
00:05:16Notre rêve est donc devenu réalité.
00:05:18Mais à l'époque où nous rêvions, nous avons dû passer notre posture de sécurité au microscope et analyser ce qui se passait.
00:05:26J'ai donc pris la responsabilité de m'en occuper et je me suis posée pour évaluer notre situation.
00:05:31Au tout début, il y a environ un an ou neuf mois, nous en étions à ce que j'appelle la couche zéro, car ce n'est littéralement pas de la sécurité.
00:05:41Ce sont simplement des prompts qui suggèrent ce que l'agent doit faire et le guident, or les prompts ne sont pas de la sécurité.
00:05:48J'étais donc inquiète à ce sujet.
00:05:51La couche un consistait en une liste blanche (allowlist).
00:05:53Et quand j'ai commencé à creuser cette liste blanche, j'ai commencé à me sentir un peu mieux car elle était assez strictement délimitée.
00:05:59Mais j'avais toujours beaucoup de préoccupations.
00:06:01Et j'ai commencé à paniquer à cause de ce fameux moteur de contexte dont je vous ai parlé.
00:06:05Nous injectons énormément de contexte dans l'agent au moment de l'exécution.
00:06:09J'ai donc construit ce scanner regex très bricolé pour détecter les éléments ayant une forme de menace entrant et sortant de l'assistant.
00:06:20Et je dois admettre que c'était extrêmement artisanal.
00:06:23Mais je vous dis tout cela très franchement parce que nous construisons tous des choses qui semblent extrêmement expérimentales et nous allons très vite.
00:06:33Et je sais que la sécurité n'est pas le domaine de prédilection de nous tous.
00:06:38Certains l'apprennent sur le tas comme je l'ai fait.
00:06:43Mais c'est quelque chose auquel nous devons penser lorsque nous construisons des outils de cette forme.
00:06:50Voilà donc quelle était notre posture de sécurité.
00:06:53Mais je me suis posé la question : est-ce qu'on est cuits ?
00:06:56Bonne nouvelle, nous étions moins cuits que je le pensais.
00:06:59Car comme je l'ai mentionné tout à l'heure, cette liste blanche était plutôt bien encadrée.
00:07:03Bash était bloqué par défaut.
00:07:06Il pouvait uniquement installer des paquets de confiance préalablement vérifiés par nos soins.
00:07:09Il pouvait compiler.
00:07:10Il pouvait vérifier les types.
00:07:11Il pouvait faire du linter.
00:07:12Et pratiquement rien d'autre.
00:07:13Il ne pouvait pas exécuter de commandes shell aléatoires.
00:07:16Et il n'avait pas accès aux variables d'environnement.
00:07:20L'agent ne pouvait pas lire votre fichier .env car nous l'avions bloqué net, et nous redirigions les secrets via un coffre-fort.
00:07:28J'ai donc poussé un soupir de soulagement en réalisant que nous étions dans une meilleure posture que je ne le pensais.
00:07:34Mais je voulais savoir où se trouvaient les failles, car en matière de sécurité, il y a toujours des failles.
00:07:39J'ai donc fait ce que nous devrions tous faire.
00:07:41J'ai fait appel à notre équipe de sécurité en leur disant : hé, pouvez-vous auditer cet outil pour moi et trouver ces failles ?
00:07:48Et ils ont trouvé des choses.
00:07:51Ils ont trouvé des lacunes.
00:07:52Et la partie intéressante n'était pas les failles ou bugs spécifiques qu'ils avaient découverts, mais plutôt leur forme.
00:07:58Car presque aucune d'elles n'était ouvertement malveillante.
00:08:01Il s'agissait à chaque fois de deux éléments très innocents et bien intentionnés qui se serraient la main et ouvraient une brèche.
00:08:07La leçon que j'ai donc apprise est que les attaques se composent, mais pas la relecture de code, car nous, les développeurs, examinons tous les diffs un par un.
00:08:20Mais les attaquants regardent le système dans son ensemble et cherchent ces deux éléments qui se serrent la main pour ouvrir une porte.
00:08:25Mais il y avait une autre chose qui m'empêchait de dormir.
00:08:29Et en repensant à ce moteur de contexte, j'ai réalisé que la partie la plus effrayante de l'agent que nous avions construit n'était pas vraiment une commande dans notre cas.
00:08:37C'était le contenu d'apparence utile que nous contisions à injecter dans son cerveau.
00:08:43Oh, je crois que je suis allée dans la mauvaise direction.
00:08:46Oui.
00:08:47L'usine à contexte.
00:08:48Il s'agit donc de notre moteur de contexte, alias le cerveau de l'assistant.
00:08:51C'est grâce à lui que l'assistant sait quoi que ce soit et c'est pourquoi il fait du bon travail.
00:08:56Il extrait des informations de notre documentation.
00:08:58Il contient des prompts rédigés à la main qui recensent les pièges et les leçons apprises en chemin.
00:09:02Et de véritables applications d'exemple fonctionnelles de bout en bout qui aident l'agent à faire de la correspondance de motifs pour installer PostHog de la meilleure des manières pour vous.
00:09:11Il empaquette tout cela dans des lots de compétences envoyés à l'assistant via notre serveur MCP et chargés directement dans le contexte de l'agent à l'exécution.
00:09:22Alors, méditez là-dessus une seconde.
00:09:24C'est une machine dont le seul rôle est de prendre du contenu et de l'injecter dans un agent capable d'exécuter des commandes.
00:09:31Maintenant, si vous étiez un attaquant, vous pourriez vous dire : “Et si je me contentais de corrompre le contenu ?”
00:09:36Pas la base de code de l'utilisateur, pas l'agent lui-même, mais le contenu proprement dit.
00:09:41Disons qu'une personne ouvre une pull request sur l'un de nos dépôts open source, car chez PostHog nous construisons tout en open source,
00:09:48et qu'elle injecte quelque chose dans un fichier markdown ou un commentaire de code en apparence inoffensif,
00:09:55et qu'une sorte de revue de code propulsée par LLM analyse cela et déclare : “Ça a l'air bon” en l'ignorant.
00:10:04Nous venons peut-être de déployer une charge utile d'injection de prompt signée par nous dans un agent qui tourne sur les machines de milliers de développeurs dans un bac à sable, mais c'est tout de même le cas.
00:10:14C'était donc la menace qui a remodelé ma façon de concevoir la sécurité et l'assistant, car l'entrée dangereuse pour nous pouvait réellement provenir de notre propre chaîne d'approvisionnement.
00:10:25J'ai donc fini par analyser le contenu aux deux extrémités de ce tuyau.
00:10:30D'abord, lorsqu'une compétence est construite et publiée, et ensuite, lorsque l'assistant l'utilise réellement.
00:10:36Ma méthodologie consiste à l'attraper à la source, à supposer que la source a échoué, et à l'attraper à nouveau au point d'utilisation.
00:10:43Je peux donc maintenant vous présenter Warlock.
00:10:48Construire Warlock n'était pas nécessairement une mesure de limitation des dégâts.
00:10:52Comme je l'ai dit, nous avions des mesures de défense par ailleurs.
00:10:55Mais j'ai construit Warlock parce que je n'aimais pas dire aux gens : “Eh bien, cet outil est plutôt bien verrouillé.
00:11:01Ça ne passe pas à l'échelle.
00:11:02Ce n'est pas ce qu'on veut déployer en production.
00:11:04Ce n'est pas ce que vous voulez voir des milliers de développeurs exécuter chaque jour.”
00:11:08Car lorsque vous déployez quelque chose à cette échelle, vous avez une surface d'attaque bien plus grande, beaucoup plus d'utilisateurs, et beaucoup plus de contenu qui afflue à mesure que vous élargissez les capacités de l'assistant.
00:11:19Et nous allons probablement bien.
00:11:21C'est juste que ça ne suffit plus.
00:11:23J'ai donc extrait ce petit scanner regex artisanal que j'avais mis en place, je l'ai sorti de l'assistant et j'en ai fait un outil autonome.
00:11:30Je l'ai appelé Warlock parce que tout ce qui a une forme d'assistant a besoin d'un garde du corps.
00:11:35Et il ne fait qu'une seule chose.
00:11:38Vous lui passez une chaîne de caractères.
00:11:40Il vous renvoie une liste de résultats.
00:11:42Chacun de ces résultats comporte une catégorie, une sévérité et une action recommandée, et ensuite il s'arrête.
00:11:48Je veux que vous vous concentriez sur le mot recommandé.
00:11:51Car le Warlock détecte, il n'agit pas.
00:11:54Il vous dira : “Hé, ça ressemble à une exfiltration.
00:11:57C'est critique.
00:11:58Je le bloquerais.”
00:11:59Mais ce que vous faites réellement de cette découverte vous regarde entièrement.
00:12:04Parce que détecter un problème est une tâche, et décider quoi en faire en est une totalement différente.
00:12:10Et la seule façon de garder tout cela compréhensible est de bien séparer ces deux choses.
00:12:15Donc, sous le capot du Warlock, au lieu de mes expressions régulières artisanales, les règles s'exécutent sur Yara, le moteur de motifs que les chercheurs en malware utilisent depuis plus de 15 ans.
00:12:27C'est entièrement déterministe.
00:12:28C'est la même entrée, la même sortie, à chaque fois.
00:12:31C'est ennuyeux par choix.
00:12:33Et en matière de sécurité, être ennuyeux est une fonctionnalité.
00:12:39Alors, qu'est-ce que le Warlock attrape réellement en conditions réelles aujourd'hui ?
00:12:42Pas mal de choses, mais il y en a deux qui sont une véritable plaie pour mon âme.
00:12:48La première n'est pas vraiment un problème lié à une règle.
00:12:52C'était un comportement de sous-agent signalé par le Warlock, qui nous a exposé une vulnérabilité en fonction de ce que faisaient ces sous-agents.
00:13:03En gros, nous lancions des agents pour effectuer de grandes tâches.
00:13:07Ils spawneraient des sous-agents.
00:13:08Et ces sous-agents essayaient de contourner les garde-fous que nous avions mis en place dans le wizard, et ils tentaient d'inventer des secrets.
00:13:16Ils essayaient d'extraire des secrets de littéralement n'importe où dans la base de code.
00:13:20Et nous avons stoppé net.
00:13:21Nous avons dit : “Plus de sous-agents.”
00:13:23Et grâce au Warlock, nous l'avons détecté.
00:13:26Je peux faire preuve d'empathie envers le robot.
00:13:28Le robot avait une tâche à accomplir, et il essayait d'optimiser et de nous plaire.
00:13:32Mais nous ne pouvons pas tolérer cela.
00:13:35Et une autre chose qui compte vraiment pour nous chez PostHog, ce sont les PII.
00:13:39Les agents se fichent éperdument d'exposer des données à moins que vous ne définissiez des règles strictes.
00:13:46Livrés à eux-mêmes, nous les avons vus balancer des e-mails, des numéros de téléphone directement dans les événements, et pour un agent, cela semble tout à fait normal à capturer.
00:13:57Et heureusement pour l'injection de requêtes en particulier, je touche du bois, nous n'avons pratiquement jamais attrapé de véritable injection malveillante en production.
00:14:08Mais nous attrapons une tonne de faux positifs, comme nos écrans de connexion de démo, du texte dans nos applications d'exemple, des éléments de documentation.
00:14:17Et cela m'a poussé à repenser ma façon de construire des applications et d'écrire la doc, car je ne veux rien publier qui ressemble à une menace.
00:14:27Mais ces faux positifs constituent honnêtement le tremplin parfait vers la partie la plus complexe et la plus intéressante de toute cette histoire.
00:14:36C'est donc avec cela que j'ai dû batailler.
00:14:39J'ai passé tout cet exposé à vous prôner le déterministe, pour ensuite aller ajouter une couche de LLM afin de trier mes faux positifs et réduire un peu le bruit.
00:14:50Et j'appelle ça le triage.
00:14:51Quand je concevais cette couche de triage, j'ai dû faire un choix.
00:14:56Cette couche devait-elle jouer le rôle de videur ou de conseiller ?
00:15:01Et le choix le plus facile aurait sans doute été de faire du LLM un videur.
00:15:06Lui montrer la commande, lui demander s'il s'agit d'une attaque, bloquer, autoriser, et faire exactement ce qu'il dit.
00:15:13Et bien que ce soit tentant parce que ça a l'air plus simple, je ne peux pas miser mon modèle de sécurité sur un pile ou face au cas où mon modèle passerait une mauvaise journée ou réagirait différemment d'hier.
00:15:26Alors au lieu d'en faire un videur, j'ai conçu le modèle pour qu'il soit un conseiller.
00:15:32C'était la ligne claire que j'ai trouvée et que je continue d'explorer, mais que je tiens à vous transmettre à tous.
00:15:38Premièrement, pour nous, la détection et l'application restent déterministes et mécaniques.
00:15:43Si une règle correspond, la porte se verrouille, la session se termine, et aucun modèle n'intervient sur ce chemin.
00:15:49Le blocage intervient avant même que nous demandions l'avis du LLM.
00:15:54Le LLM ne peut donner son avis qu'ensuite, si nous n'avons rien bloqué.
00:15:58Il est conçu pour supprimer le bruit.
00:16:00Il n'est pas conçu pour laisser passer des choses.
00:16:03Et s'il échoue en mode fermé, c'est-à-dire si le modèle passe une mauvaise journée, toutes les exécutions du wizard sont stoppées ; désolé, mais c'est pour mieux vous protéger.
00:16:14L'application des règles est la partie sur laquelle vous jouez votre va-tout, elle doit donc être déterministe.
00:16:20Mais le discernement est la partie qui apporte de la nuance, c'est donc le seul endroit où l'on peut introduire du probabiliste.
00:16:27Alors, comment mettons-nous en place de vraies règles pour les agents ?
00:16:34Voici l'anatomie de l'une de nos règles Warlock, et chaque règle Warlock comporte quatre parties.
00:16:41La première partie est les métadonnées.
00:16:43Description en anglais clair, sévérité, catégorie, action, direction.
00:16:50Première partie, cela entre-t-il dans l'agent ?
00:16:52Est-ce quelque chose que l'agent est en train d'écrire ?
00:16:57Ensuite, nous avons les chaînes, qui sont les motifs réels que vous recherchez.
00:17:03Et la troisième partie est la condition.
00:17:05C'est ici que la règle est réellement autorisée à se déclencher.
00:17:10Je vais vous détailler cet exemple et nous pourrons faire comme si nous l'écrivions mentalement.
00:17:15L'injection de requêtes étant le classique “ignore toutes les instructions précédentes”.
00:17:20Votre premier réflexe ici est probablement de bloquer le mot ignore, mais les agents lisent du code toute la journée,
00:17:27et le mot ignore peut apparaître tout le temps dans des commentaires de code ou des exemples.
00:17:31Vous ne voulez donc pas cibler le verbe seul.
00:17:33Vous ciblez le verbe associé à un nom à connotation d'instruction.
00:17:38Dans la condition, vous dites de déclencher si l'un de ces motifs correspond.
00:17:42Et dans les métadonnées, vous déterminez si c'est critique, quelle est la catégorie, l'action,
00:17:50dans ce cas bloquer, et la direction, ici une entrée affluant vers l'agent.
00:17:56Mais pour écrire de bonnes règles qui réduisent le bruit, vous devez y associer des tests.
00:18:02Vous devez donc écrire des tests qui disent : ce sont des motifs qui correspondent.
00:18:06Ce sont ceux qui ne le devraient pas.
00:18:08Et ce test négatif constitue la première ligne de défense contre les faux positifs.
00:18:13Mais vous devez également vous assurer, lorsque vous décidez de la sévérité de cette règle,
00:18:19de prendre en compte l'impact réel, et non son degré d'effrayant.
00:18:24RM -RF fait peur, mais c'est aussi de cette façon que nous supprimons tous des modules node 40 fois par jour.
00:18:31Vous déterminez l'impact réel pour l'agent que vous construisez,
00:18:37car un outil de sécurité qui plante à chaque fois qu'il essaie de nettoyer un dossier de build
00:18:42est un outil qu'on finit par désactiver et qui ne détecte absolument rien.
00:18:47Je suis donc fier de dire que telle est notre posture de sécurité à présent.
00:18:51Je peux enfin monter ici et affirmer que nous disposons d'une véritable défense en profondeur.
00:18:56Tous mes apprentissages se sont assemblés en ceci.
00:19:00C'est toujours cloisonné, mais chaque couche accomplit désormais une tâche pour laquelle elle est douée.
00:19:04Nous avons toujours des prompts, mais nous ne les utilisons que pour le guidage.
00:19:07Tout s'exécute dans un bac à sable.
00:19:09Nous refusons par défaut.
00:19:11Nous avons un coffre-fort pour que les secrets n'atteignent jamais le modèle.
00:19:14Nous avons le warlock pour analyser le contenu entrant
00:19:17et scanner les sorties rédigées par l'agent.
00:19:20Nous avons aussi le triage pour réduire le bruit,
00:19:23et nous disposons d'une télémétrie intégrée à l'ensemble du processus
00:19:26afin de tout voir.
00:19:28Aucune de ces couches ne se suffit à elle-même.
00:19:31Pas un seul élément ici ne vous sauvera,
00:19:33ce sont juste des couches ennuyeuses et honnêtes,
00:19:36chacune remplissant une unique tâche qu'elle maîtrise.
00:19:40Alors si vous construisez un agent doté de mains,
00:19:45voici tout l'exposé en trois lignes.
00:19:47Un, si ce n'est pas appliqué de manière déterministe,
00:19:50ce n'est pas appliqué.
00:19:52Les prompts ne sont pas des règles de sécurité.
00:19:54Ne faites pas comme s'ils l'étaient.
00:19:57Deux, l'entrée dangereuse ne se limite pas à ce que tape votre utilisateur.
00:20:02Elle ne se limite pas non plus aux commandes que vous l'autorisez à lancer.
00:20:04C'est tout ce qui parvient au modèle,
00:20:06y compris le contenu que vous rédigez vous-même.
00:20:09Scannez donc votre propre chaîne d'approvisionnement à la source
00:20:12et au moment où l'agent l'invoque.
00:20:15Trois, les attaques se combinent, la revue de code non.
00:20:18La plupart de nos failles lors de notre audit provenaient de deux choses anodines,
00:20:22serrer des mains et ouvrir une porte.
00:20:25Le wizard, le warlock et le contexte mill sont tous open source,
00:20:29venez donc me trouver en bas.
00:20:32Je suis dans le hall d'exposition à notre stand
00:20:34et je vous ferai visiter, vous montrerai ce que nous avons construit,
00:20:37et je veux savoir comment vous sécurisez vos agents de votre côté.
00:20:41Merci.
00:20:59Merci.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video