Sécuriser un agent : safety, permissions et dossiers de confiance
Sur cette page
- Ce que fait safety, et ce qu’il ne fait pas
- Premier levier : les outils disponibles
- Deuxième levier : la permission de chaque outil
- Troisième levier : le périmètre du répertoire de travail
- Quatrième levier : les dossiers de confiance
- Répondre à une demande d’approbation
- Choisir le bon dosage
- Points clés à retenir
Leçon réécrite le 2 novembre 2026. La version précédente présentait le champ
safetycomme un niveau de permission. La documentation de Vibe est explicite : c’est un indice visuel qui colore la bordure de saisie, il n’impose rien. Ce qui protège réellement, ce sont les listes d’outils, les permissions par outil et les dossiers de confiance. Sources : Safety, approvals, and permissions · Configuration reference.
Ce que fait safety, et ce qu’il ne fait pas
Le champ safety d’un fichier d’agent accepte cinq valeurs : safe, neutral (la valeur par défaut), destructive, smart et yolo. Il change la couleur de la bordure de la zone de saisie, pour vous rappeler d’un coup d’œil dans quel agent vous êtes. Il ne retire aucun outil et ne déclenche aucune demande d’approbation. Un agent marqué safe mais doté de bash sans restriction peut tout à fait lancer une commande destructrice.
Une seule exception : quand un administrateur désactive l’approbation automatique (enable_auto_approve = false), Vibe masque tous les agents marqués yolo. Pour le reste, safety est une étiquette, pas un verrou. Associez-le toujours aux vrais leviers ci-dessous.
Premier levier : les outils disponibles
enabled_tools (liste d’autorisation) et disabled_tools (liste d’exclusion, appliquée après) décident de ce que l’agent peut appeler. Ils acceptent des noms exacts, des motifs glob et des expressions régulières préfixées par re:.
# Agent d'audit en lecture seule
display_name = "Audit de sécurité"
safety = "safe"
enabled_tools = ["read_file", "grep"]
Un outil absent de la liste n’existe pas pour l’agent : c’est la garantie la plus forte.
Deuxième levier : la permission de chaque outil
Pour les outils disponibles, un bloc [tools.<outil>] fixe la règle : "always" (sans demander), "ask" (demander à chaque fois) ou "never" (bloquer).
display_name = "Refactoring"
safety = "neutral"
enabled_tools = ["read_file", "grep", "edit", "write_file", "bash"]
[tools.edit]
permission = "always"
[tools.write_file]
permission = "ask"
[tools.bash]
permission = "ask"
allowlist = ["git status", "git diff", "pnpm test"]
denylist = ["rm -rf", "git push"]
Pour bash, allowlist et denylist listent des préfixes de commandes toujours permis ou toujours refusés. Vibe autorise par défaut quelques commandes en lecture seule (ls, pwd, cat, git status…), mais chaque liste que vous écrivez remplace la liste par défaut : reprenez-y les commandes par défaut que vous voulez garder. Pour read_file, write_file et edit, ces listes acceptent des motifs de chemins absolus. Enfin, une règle prudente : un script lancé par bash peut construire des chemins que Vibe ne voit pas dans la commande ; gardez bash en "ask" dès que l’enjeu le justifie.
Troisième levier : le périmètre du répertoire de travail
Par défaut, Vibe demande avant qu’un outil de fichier ou de shell n’atteigne un chemin hors du répertoire de travail, même par un lien symbolique, et avant toute lecture ou modification de fichiers .env et .envrc. Vous pouvez durcir ce comportement :
outside_workdir = "deny" # refuser au lieu de demander ; l'agent reçoit une erreur et continue
Quatrième levier : les dossiers de confiance
Un dépôt peut embarquer sa propre configuration Vibe (agents, skills, serveurs MCP, permissions) dans un dossier .vibe/, ou des instructions dans un AGENTS.md. Comme cette configuration change le comportement de Vibe, elle n’est chargée que depuis un dossier que vous avez explicitement approuvé. Au premier lancement, Vibe liste les fichiers détectés et vous propose Trust folder, Trust full repo ou Don’t trust ; vos choix sont mémorisés dans ~/.vibe/trusted_folders.toml. La boîte de dialogue n’analyse pas ces fichiers : relisez-les comme n’importe quel code du dépôt, surtout les définitions de serveurs MCP et les permissions. En mode programmatique, Vibe ne demande jamais : vibe --trust accorde une confiance temporaire, pour une exécution.
Répondre à une demande d’approbation
Quand Vibe demande, quatre réponses sont possibles au clavier : 1 ou y autorise une fois, 2 pour le reste de la session, 3 toujours, et 4, n ou Échap refuse. La couleur de la bordure vous rappelle l’agent actif.
Choisir le bon dosage
| Besoin | Réglage |
|---|---|
| Analyser sans rien toucher | enabled_tools = ["read_file", "grep"] |
| Refactorer en confiance | edit en "always", bash en "ask" avec une allowlist de commandes de test |
| Nettoyer un projet | bash en "ask" et une denylist des commandes irréversibles |
| Tâche sans surveillance en intégration continue | conteneur jetable, vibe --prompt … --auto-approve, limites --max-turns et --time-limit |
La règle d’or reste le moindre privilège : donnez à chaque agent le minimum nécessaire, commencez restrictif et ouvrez au besoin.
Points clés à retenir
safety(safe,neutral,destructive,smart,yolo) colore la bordure, il n’impose aucune permission- Les vrais verrous :
enabled_tools/disabled_tools, puis[tools.<outil>](always,ask,never) - Pour
bash,allowlistetdenylistremplacent les listes par défaut - Vibe demande avant de sortir du répertoire de travail et avant de toucher aux fichiers
.env - La configuration d’un projet ne se charge que dans un dossier de confiance ; relisez-la avant d’approuver