Niveaux de sécurité : safe, neutral, destructive, yolo

Pourquoi les niveaux de sécurité sont essentiels

Quand vous créez un agent custom dans Mistral Vibe, le champ safety détermine les actions que l’agent est autorisé à entreprendre. C’est votre garde-fou principal, et il se règle mal dans les deux sens : trop bas, il bloque un agent parfaitement légitime qui n’arrive plus à écrire le fichier qu’on lui demande ; trop haut, il ouvre l’accès à des opérations dangereuses dont vous n’aviez pas envisagé l’usage. Les quatre niveaux forment une échelle progressive, du plus restrictif au plus permissif.

safe — lecture seule

Le niveau safe limite l’agent aux opérations de lecture. Il peut explorer votre codebase, analyser des fichiers et produire des rapports, mais ne peut rien modifier. Concrètement, il lit des fichiers, recherche dans le code avec grep, liste des répertoires, analyse et produit des recommandations — et rien d’autre : écrire ou modifier un fichier, exécuter une commande shell, installer un paquet lui sont interdits.

# Agent d'audit de code
display_name = "Security Auditor"
safety = "safe"
enabled_tools = ["read_file", "grep", "list_dir"]

C’est le niveau des audits de sécurité, des revues de code, des analyses d’architecture et de la planification de refactoring. Son intérêt est autant psychologique que technique : vous laissez tourner l’agent sans surveiller chaque étape, parce que le pire résultat possible est un rapport inexact.

neutral — modifications contrôlées

Le niveau neutral autorise les opérations d’écriture standard, sans les opérations potentiellement destructrices. Il ajoute à ce que permet safe la création de nouveaux fichiers, la modification de fichiers existants et les éditions partielles. En revanche, supprimer des fichiers, exécuter des commandes shell arbitraires ou modifier les permissions système restent hors de portée.

# Agent de refactoring
display_name = "Refactoring Assistant"
safety = "neutral"
enabled_tools = ["read_file", "write_file", "edit_file", "grep"]

C’est le niveau de travail quotidien : refactoring, génération de code, documentation, corrections de bugs. Un agent neutral qui se trompe produit un mauvais diff, que votre gestionnaire de versions annule en une commande.

destructive — opérations à risque

Le niveau destructive donne accès aux opérations qui peuvent causer des pertes de données. À tout ce que permet neutral s’ajoutent la suppression de fichiers et de dossiers, l’exécution de commandes shell, l’installation ou la désinstallation de paquets et la modification de la configuration système.

# Agent de nettoyage
display_name = "Project Cleaner"
safety = "destructive"
auto_approve = false  # TOUJOURS false pour destructive
enabled_tools = ["read_file", "write_file", "bash", "grep", "list_dir"]

La recommandation est forte : gardez auto_approve = false à ce niveau. Un agent de nettoyage de projet qui interprète un peu largement « supprimer les fichiers inutilisés » vous fera comprendre pourquoi vous vouliez valider chaque action destructrice. Ce niveau convient au nettoyage de projet, à la migration de dépendances et aux scripts de déploiement.

yolo — aucune restriction

Le niveau yolo supprime toutes les barrières de sécurité : l’agent peut absolument tout faire, sans aucune vérification ni confirmation.

# Agent CI/CD (environnement jetable uniquement)
display_name = "CI Pipeline"
safety = "yolo"
auto_approve = true
enabled_tools = ["read_file", "write_file", "bash", "grep", "edit_file"]

Ne l’utilisez que dans un environnement jetable — container Docker, branche éphémère, pipeline CI/CD — c’est-à-dire un endroit dont la destruction complète ne coûte qu’un redémarrage. Jamais sur votre machine de développement avec du code de production.

Choisir le bon niveau

La règle d’or est le principe du moindre privilège : donnez à chaque agent le minimum de permissions nécessaire pour accomplir sa tâche. Appliquée à une journée de travail ordinaire, elle donne le découpage suivant.

# Analyse de code ? → safe
vibe --agent security-auditor

# Refactoring ? → neutral
vibe --agent refactoring-assistant

# Déploiement ? → destructive avec auto_approve = false
vibe --agent deployer

# Pipeline CI dans un container ? → yolo
vibe --agent ci-pipeline

Combiner safety et enabled_tools

Le niveau safety et la liste enabled_tools ne se recouvrent pas, ils se complètent. Même avec safety = "destructive", si vous ne listez pas bash dans enabled_tools, l’agent ne pourra pas exécuter de commandes shell : le niveau autorise la catégorie d’action, la liste blanche fournit — ou non — l’outil qui la rend possible.

# Destructive MAIS limité à l'édition de fichiers
safety = "destructive"
enabled_tools = ["read_file", "write_file", "edit_file"]
# Pas de bash, pas de suppression via shell

C’est une approche défensive recommandée : réglez safety pour le niveau global, puis affinez avec enabled_tools. Les deux exemples qui suivent montrent ce que donne cette combinaison sur des cas réels.

Un agent de revue de pull request n’a besoin que de lire, et peut donc travailler sans interruption. safe combiné à auto_approve = true est ici parfaitement sûr, puisque le pire scénario reste un rapport à corriger.

display_name = "PR Reviewer"
safety = "safe"
auto_approve = true
system_prompt = """Analysez les changements et produisez un rapport structuré."""
enabled_tools = ["read_file", "grep", "list_dir"]

Un agent de migration de base de données se situe à l’opposé : il doit exécuter des commandes, mais chacune peut toucher des données réelles. destructive avec auto_approve = false lui donne le pouvoir d’agir tout en vous laissant valider chaque étape.

display_name = "DB Migrator"
safety = "destructive"
auto_approve = false
system_prompt = """Générez des migrations SQL avec rollback. Demandez confirmation."""
enabled_tools = ["read_file", "write_file", "bash", "ask_user_question"]

Points clés à retenir

• safe : lecture seule — zéro risque, parfait pour l’analyse
• neutral : créer et modifier des fichiers sans supprimer
• destructive : opérations à risque — toujours avec auto_approve = false
• yolo : réservé aux environnements jetables (CI/CD, containers)
• Combinez safety et enabled_tools pour un contrôle granulaire
• En cas de doute, commencez par safe et montez progressivement