Salut ! C’est ici que je partage mes pensées et mes notes sur tout ce qui me passionne et sur lequel je bosse en ce moment. J’espère vraiment y rencontrer des gens qui pensent comme moi. Salut ! Je voulais juste te dire que… J’aimerais vraiment avoir de tes nouvelles !
Je t’invite à jeter un œil à mes derniers articles de blog, juste en dessous.
Deux releases le même jour, à vingt minutes d’intervalle : v1.0.1 puis v1.0.2. Les deux font le même travail — durcir pi-secured-setup lui-même. C’est un billet court pour expliquer ce qui a changé et pourquoi ça compte, parce qu’un outil de sécurité qui traîne ses propres vulnérabilités perd toute crédibilité.
Si vous découvrez le projet, l’article de présentation pose les bases : Guards, Scanners, audit trail.
Trois axes :
pi en mode YOLO, c’est le filesystem sans frein, n’importe quelle commande exécutée, zéro garde-fou. Le créateur a fait ce choix sciemment. Mais quand votre projet contient des .env, des clés SSH ou un production.yaml, ce choix vous met en danger.
J’ai présenté pi-secured-setup il y a quelques jours. Guards, Scanners, audit trail, branchés dans l’agent. Depuis, j’ai regardé une autre extension : pi-permission-system, par MasuRii. Les deux sécurisent pi. Pas de la même façon.
Dans l’article précédent, j’ai présenté pi-secured-setup — une extension pi qui ajoute des Guards, des Scanners et un audit trail à votre agent de code IA. Elle est livrée avec des defaults pertinents : application de frontière, globbing de chemins protégés, classification de commandes bash, rédaction de secrets, vérification de skills.
Mais chaque projet a des risques uniques. Un shop Terraform n’a pas les mêmes règles qu’un monorepo Node.js. Une équipe avec des exigences de conformité strictes n’a pas la même granularité d’audit qu’un développeur solo.
Il y a quelques jours, je présentais Greywall — un sandbox kernel-level qui contient pi grâce à une approche deny-by-default. C’est votre mur extérieur. Mais qu’en est-il des menaces à l’intérieur de la frontière ? L’agent qui écrit accidentellement dans le mauvais projet, le fichier .env qui se retrouve dans le contexte LLM, le skill dont le SKILL.md a été silencieusement modifié. C’est un problème différent, qui nécessite un outil différent.
Les agents de code IA comme pi sont devenus des compagnons indispensables au quotidien. Mais par défaut, pi fonctionne en mode YOLO : accès complet au filesystem, exécution de n’importe quelle commande, aucune restriction. C’est un choix délibéré de son créateur, mais cette liberté a un coût réel. Aujourd’hui, je vous propose de découvrir Greywall, un outil qui permet de sandboxer pi grâce à une approche deny-by-default au niveau kernel.
Dans le contexte actuel où les architectures télécom évoluent vers des solutions cloud-native et microservices, la flexibilité du routage SIP devient un enjeu majeur. Kamailio, en tant que serveur SIP puissant et modulaire, propose des modules comme http_async_client et rtjson qui permettent d’intégrer facilement des décisions de routage dynamiques basées sur des réponses de microservices externes.
Le module http_async_client permet d’effectuer des requêtes HTTP(S) de manière asynchrone, sans bloquer le traitement des messages SIP. Cela signifie que Kamailio peut interroger un service externe (API REST, microservice) pour obtenir des instructions de routage, tout en continuant à gérer d’autres appels.