Skip to content

Security.fr

Thomas Leberre edited this page Aug 20, 2026 · 3 revisions

Sécurité

Laisser des agents IA exécuter des commandes et modifier votre code nécessite un modèle de sécurité robuste. Voici comment WorkPilot AI protège votre machine, votre code et vos credentials.


🛡 Le modèle de sécurité en 3 couches

┌─────────────────────────────────────────────────┐
│   Couche 3 — Allowlist dynamique de commandes    │
│   (seules les commandes adaptées à la stack)     │
├─────────────────────────────────────────────────┤
│   Couche 2 — Restrictions filesystem             │
│   (opérations limitées au répertoire projet)     │
├─────────────────────────────────────────────────┤
│   Couche 1 — Sandbox OS                          │
│   (commandes bash en isolation)                  │
└─────────────────────────────────────────────────┘

🔒 Couche 1 — Sandbox OS

Chaque commande exécutée par un agent passe par un subprocess contrôlé :

  • Variables d'environnement sanitizées (pas d'exposition de secrets hors scope)
  • Timeout par défaut (empêche les commandes qui traînent)
  • Capture stdout/stderr sans interprétation directe du shell
  • Pas de héritage de file descriptors sensibles

📁 Couche 2 — Restrictions filesystem

Toutes les opérations d'écriture / suppression / renommage sont confinées au répertoire projet.

Ce qui est contrôlé

  • Création / modification de fichiers
  • Suppression
  • Déplacement
  • Création de dossiers

Validation des chemins

  • Les chemins relatifs sont résolus vers un chemin absolu
  • Si le chemin résolu sort du répertoire projet → refus immédiat
  • La traversée (../../) est bloquée par le validateur
  • Utilisation obligatoire de core.platform.joinPaths() plutôt que de concat manuel

📋 Couche 3 — Allowlist dynamique

apps/backend/security/ maintient une liste blanche de commandes autorisées.

Détection de stack

Au démarrage, WorkPilot AI analyse votre projet et détecte :

  • Le(s) langage(s) utilisé(s)
  • Les outils de build (Vite, Webpack, Cargo…)
  • Les frameworks de test (pytest, vitest, jest…)
  • Les gestionnaires de packages (npm, pnpm, uv, poetry, cargo…)

Allowlist adaptative

Stack détectée Commandes autorisées
Node.js node, npm, pnpm, npx, yarn, biome, eslint, tsc, vite, vitest, jest, playwright
Python python, python3, pip, uv, poetry, pytest, ruff, black, mypy
Rust cargo, rustc, rustup, cargo-test
Go go, gofmt, golangci-lint
Universel git, ls, cat, grep (en lecture), find, echo

Commandes toujours bloquées

Peu importe la stack :

rm -rf /          dd              mkfs           fdisk
shutdown          reboot          halt           poweroff
mkuser            userdel         chown -R /     chmod 777 /
curl | bash       wget | sh       eval           iptables

Ajouter des exceptions

Via Paramètres → Sécurité → Allowlist personnalisée, vous pouvez :

  • Ajouter des commandes supplémentaires (avec justification)
  • Retirer des commandes jugées trop permissives
  • Définir des regex de blocage

🪝 Hooks de sécurité

Le Claude Agent SDK utilise des hooks qui s'exécutent avant et après chaque appel d'outil :

Hook Rôle
PreToolUse Valide la commande contre l'allowlist
PostToolUse Enregistre le résultat, détecte les anomalies
FileWrite Valide le chemin cible, empêche les écrasements
BashExecute Sanitize les arguments, applique les timeouts

En cas de refus, l'agent reçoit un message d'erreur explicite et peut adapter son plan.


🔑 Gestion des credentials

Stockage OS natif

Les credentials sensibles ne sont jamais stockés en clair :

OS Service
macOS Keychain
Windows Credential Manager
Linux libsecret / kwallet

Multi-profils

Plusieurs comptes (Claude, OpenAI, etc.) peuvent coexister sans conflit. Chaque profil a son propre espace sécurisé.

Rotation automatique

token-refresh.ts surveille l'expiration des tokens OAuth et les rafraîchit automatiquement avant échéance. Vous n'avez pas à vous authentifier à chaque session.

Validation d'input

Tous les inputs utilisateur (noms de profil, URLs d'endpoints custom, commandes…) sont validés et sanitizés avant usage.


🧱 Isolation par worktree

Le cœur de la sécurité opérationnelle : tout se passe dans un worktree git isolé.

mon-projet/
├── .git/
├── src/                    # ← main (intouchée)
└── .worktrees/
    └── workpilot-ai/       # ← agents travaillent ici
        ├── src/            # copie modifiable
        └── .git/...        # lien vers .git/worktrees/

Conséquences positives :

  • Votre branche principale ne peut pas être cassée par une tâche en cours
  • Si quelque chose tourne mal → --discard supprime le worktree, main est intacte
  • Vous pouvez faire tourner plusieurs tâches en parallèle sans interférence
  • Git préserve l'historique normal (pas de modifications ad-hoc de .git/)

📦 Intégrité des releases

Toutes les releases publiées sur GitHub incluent :

  • Checksums SHA256 pour vérifier l'intégrité des binaires téléchargés
  • Scans VirusTotal publiés en commentaire de release
  • Builds reproductibles (dans la mesure où les toolchains le permettent)

Vérifier un téléchargement

# Linux/macOS
sha256sum WorkPilot-AI-1.1.0-linux-x86_64.AppImage
# Comparer avec la valeur publiée sur la page de release

# Windows PowerShell
Get-FileHash WorkPilot-AI-1.1.0-win32-x64.exe -Algorithm SHA256

🌐 Confidentialité des données

Ce qui est envoyé au fournisseur IA

  • Les prompts (qui incluent potentiellement du code de votre projet)
  • Les résultats d'outils (stdout de commandes, contenu de fichiers lus)

Ce qui n'est jamais envoyé

  • Vos credentials OS (ils restent dans le Keychain)
  • Les fichiers en dehors du scope de la tâche
  • Les secrets détectés dans .env, .git, node_modules/ (filtrés par défaut)

Filtrage de secrets

apps/backend/security/secret_scanner.py scanne les fichiers avant envoi et redacte :

  • Clés API détectées par pattern
  • Connection strings (DB, Redis…)
  • Tokens JWT
  • Contenu de .env*

Mode local-first

Pour un contrôle total, combinez :

  • Ollama comme fournisseur IA (modèles locaux)
  • Graphiti avec embeddings locaux
  • Désactivation des intégrations cloud (GitHub, Linear, etc.)

→ Aucune donnée ne sort jamais de votre machine.


🎛 Paramètres de sécurité

Dans l'application : Paramètres → Sécurité

Option Effet
Strict allowlist Bloque toute commande non explicitement autorisée
Confirmation avant écriture Demande validation humaine avant chaque write_file
Timeout par commande Durée max avant kill (défaut : 5 min)
Désactiver le réseau Bloque curl, wget, etc.
Redaction des secrets Scan et redacte avant envoi au LLM
Audit log Fichier de log de toutes les actions sensibles

🧾 Audit et traçabilité

Le Workflow Logger enregistre toutes les actions sensibles avec :

  • Trace ID par tâche
  • Timestamp précis
  • Agent source
  • Commande exécutée
  • Résultat (succès/échec)
  • Fichiers touchés

Fichiers de logs :

logs/
├── workflow.log          # log principal
├── security.log          # events de sécurité (refus, alertes)
└── audit.jsonl           # format JSON pour ingestion SIEM

🐛 Signaler une vulnérabilité

Si vous découvrez une faille :

  1. Ne pas la divulguer publiquement
  2. Envoyer un mail à l'adresse de sécurité du projet (voir docs/SECURITY.md)
  3. Inclure :
    • Description détaillée
    • PoC (proof of concept)
    • Version affectée
    • Impact estimé

Une réponse initiale est envoyée sous 72 h en général.

Voir SECURITY.md pour le processus complet.


✅ Bonnes pratiques utilisateur

  • Utilisez la branche develop comme base (pas main) — déjà configuré par défaut
  • Examinez toujours le diff avant de fusionner
  • Activez la confirmation avant écriture pour les projets sensibles
  • Utilisez plusieurs profils IA pour éviter les rate limits — pas pour contourner les quotas
  • Gardez le Claude Code CLI à jour : pnpm update -g @anthropic-ai/claude-code
  • Surveillez logs/security.log si des alertes apparaissent

Prochaine étape

➡️ Personnalisation — thèmes, langues, raccourcis

Clone this wiki locally