pi-permission-system vs pi-secured-setup : choisir comment sécuriser pi

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.

Les voilà face à face.

Deux philosophies#

pi-permission-system, c’est un moteur de politiques. Vous déclarez les règles, le moteur les applique. Trois états : allow, ask, deny. Des wildcards. Des couches de config globales, projet, agent. Le but : verrouiller la surface d’exécution de pi avant que l’agent n’ait bougé.

pi-secured-setup, c’est un paquet de défense en profondeur. Des guards qui bloquent ou confirment. Des scanners qui observent et rédactent. Un audit trail en JSONL. Le but : attraper les fuites, vérifier que les skills sont intègres, tracer chaque action. Vous installez, ça protège. Pas de config à écrire.

• pi-permission-system : framework d’autorisation fin
• pi-secured-setup : suite de durcissement avec détection et audit

Leur terrain commun#

Les deux couvrent les mêmes basiques :

Un utilisateur qui installe l’une ou l’autre récupère une protection de base équivalente. La différence arrive sur le reste.

La vraie différence : le modèle d’exécution#

pi-permission-system fonctionne avec une matrice de politiques. Vous écrivez des règles dans pi-permissions.jsonc :

{
  "defaultPolicy": { "tools": "ask", "bash": "ask", "mcp": "ask", "skills": "ask", "special": "ask" },
  "tools": {
    "read": "allow",
    "write": "deny",
    "mcp": "allow"
  },
  "bash": {
    "git *": "ask",
    "git status": "allow",
    "rm -rf *": "deny"
  }
}

Chaque catégorie (tools, bash, mcp, skills, special) a ses règles. Les wildcards suivent une logique last-match-wins. Vous pouvez surcharger par agent en YAML frontmatter. L’extension retire les outils interdits du prompt système avant le démarrage. L’agent ne les voit pas.

pi-secured-setup enchaîne des guards nommés et des scanners dans un ordre fixe :

boundary → protected-paths → bash-gate

Le premier verdict bloquant gagne. Les scanners (secrets, skills) regardent sans bloquer. Pas de matrice, pas de wildcards. Les règles sont dans des fichiers JSON séparés par guard (command-rules.json, protected-paths.json, allowed-external.json).

En pratique : pour autoriser git status et bloquer git push --force, pi-permission-system vous fait écrire deux règles. pi-secured-setup classe git status en SAFE et git push --force en DANGEROUS tout seul.

Ce que l’un fait et l’autre pas#

En plus chez pi-permission-system#

MCP. Une section dédiée pour l’accès aux serveurs et outils MCP. mcp_status en allow, myServer:search en ask, un serveur complet en deny.

Nettoyage du prompt système. L’extension réécrit la section Available tools: pour retirer ce qui est interdit. L’agent ne connaît que les outils qu’il peut appeler.

Subagents. Un agent délégué sans UI qui tombe sur un ask renvoie la demande à la session principale pour confirmation.

Mode YOLO runtime. Bascule les ask en auto-approbation temporaire via /permission-system ou l’API.

Surcharges par agent. Chaque agent porte sa politique dans son fichier markdown en YAML frontmatter.

En plus chez pi-secured-setup#

Scanner de secrets. Inspecte le payload provider avant l’envoi au LLM. Repère les clés AWS (AKIA...), les tokens GitHub (ghp_...), les clés privées (-----BEGIN RSA PRIVATE KEY-----), les chaînes de connexion base de données, et une dizaine d’autres patterns. L’agent garde le type de secret, pas la valeur.

DATABASE_URL=postgres://user:supersecret@db.example.com:5432/prod

devient :

DATABASE_URL=***REDACTED:db-connection***

Vérification d’intégrité des skills. Hash SHA-256 de chaque SKILL.md. Nouveau skill ou skill modifié : vous devez approuver. Skill modifié à votre insu : alerte.

Audit trail avec rotation. Chaque action dans un fichier JSONL. Rotation à 10 Mo, 3 fichiers conservés. Dashboard /security avec compteurs et événements récents.

Rédaction préventive. Le scanner tourne sur before_provider_request. Les secrets n’arrivent jamais au modèle. Un secret que le modèle ne voit pas, il ne peut pas le répéter.

Face à face#

Quand choisir pi-permission-system#

Vous gérez plusieurs agents avec des profils différents. Vous avez besoin de contrôler l’accès MCP finement. Vous voulez que les subagents suivent les mêmes règles que l’agent principal. Vous venez d’OpenCode et vous voulez porter vos règles existantes. Vous préférez écrire une politique explicite et laisser le moteur l’appliquer.

pi install npm:pi-permission-system

Quand choisir pi-secured-setup#

Vous voulez une protection immédiate sans écrire de config. Vos projets contiennent des secrets qui ne doivent jamais remonter au LLM. Vous voulez savoir si un skill a été modifié derrière votre dos. Vous avez besoin d’un audit trail exploitable. Vous voulez attraper les fuites autant que bloquer les actions.

pi install git:github.com/mwolff44/pi-secured-setup

Les deux ensemble ?#

Les extensions opèrent à des niveaux différents. L’une filtre l’exécution. L’autre scanne les payloads et trace les événements. Pas de conflit.

Sur un projet qui manipule des données sensibles, je recommande d’installer les deux : pi-permission-system pour la politique, pi-secured-setup pour la détection et l’audit.

pi-secured-setup sur GitHub. pi-permission-system sur GitHub. Les deux sous MIT.

Laquelle vous correspond ? Dites-le-moi en commentaire.