Two releases on the same day, twenty minutes apart: v1.0.1 then v1.0.2. Both do the same job — harden pi-secured-setup itself. This is a short post to explain what changed and why it matters, because a security tool that ships its own vulnerabilities loses all credibility.
If you’re new to the project, the introductory article covers the basics: Guards, Scanners, the audit trail.
Three threads:
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.
pi in YOLO mode gives you full filesystem access, unrestricted command execution, zero guardrails. The creator made that choice deliberately. But when your project contains .env files, SSH keys, or a production.yaml, that choice puts you at risk.
I covered pi-secured-setup a few days ago. Guards, Scanners, audit trail, wired into the agent. Since then I looked at another extension: pi-permission-system by MasuRii. Both secure pi. Not the same way.
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.
In the previous article, I introduced pi-secured-setup — a pi extension that adds Guards, Scanners, and an audit trail to your AI coding agent. It ships with sensible defaults: boundary enforcement, protected path globbing, bash command classification, secret redaction, skill verification.
But every project has unique risks. A Terraform shop needs different rules than a Node.js monorepo. A team with strict compliance requirements needs different audit granularity than a solo developer.
A few days ago, I covered Greywall — a kernel-level sandbox that contains pi with a deny-by-default approach. That’s your outer wall. But what about threats inside the boundary? The agent that accidentally writes to the wrong project, the .env file that ends up in the LLM context, the skill whose SKILL.md was silently modified. That’s a different problem, and it needs a different tool.
Today I’m releasing pi-secured-setup — a pi extension that adds Guards, Scanners, and an audit trail directly inside the agent. No kernel modules, no containers, no external dependencies. Just a pi install and you’re protected.
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.