Kimi Code Never Ask : modes et commandes dangereuses

Dans Kimi Code, le mode Never Ask (/auto) approuve tout automatiquement : il exécute rm -rf, shutdown et reboot sans poser la moindre question. L’agent ne demande confirmation avant ces commandes que dans les 2 autres modes, Always Ask et Ask When Needed.

Je travaille moi-même dans Claude Code avec l’option « tout autoriser » activée ; sinon, nous resterions là à cliquer : oui, oui, oui. Mais une fois sur 10, l’agent fait les choses à sa manière.

Même un prototype personnel peut exposer fichiers et identifiants précieux. Utilisez une copie ou un conteneur isolé, des droits limités et une sauvegarde vérifiée. Pour les systèmes clients, ajoutez une identité de base distincte avec les seuls droits nécessaires. Ainsi, même s’il veut vraiment supprimer la base, il ne le peut pas.

Voyons ce que fait chaque mode de Kimi Code, où la protection fonctionne et comment définir une interdiction. C’est parti.

Pour savoir comment utiliser le service, consultez la documentation d’Ailoot.

Que permet le mode Never Ask de Kimi Code ?#

Si vous avez déjà installé Kimi Code, vous avez vu le panneau de confirmation : l’agent veut modifier un fichier ou exécuter une commande et attend votre « oui ». Les modes s’appelaient autrefois Manual, YOLO et Auto ; c’est pourquoi ils utilisent encore les anciennes commandes /yolo et /auto.

Always Ask. Le mode par défaut. L’agent lit les fichiers sans demander, mais vous confirmez séparément chaque modification et chaque commande. C’est le mode le plus lent.

Ask When Needed. S’active avec /yolo. Ce mode approuve de lui-même les modifications et les commandes ordinaires, mais demande confirmation avant d’accéder à .env (le fichier qui contient les mots de passe et les clés du projet) et aux clés SSH du serveur, avant d’exécuter des commandes dangereuses telles que shutdown (éteindre l’ordinateur) et rm -rf (supprimer un dossier entier en contournant la corbeille), ainsi qu’avant de quitter le mode Plan. L’agent peut aussi vous poser une question de son propre chef.

Never Ask. S’active avec /auto. Toutes les actions sont approuvées automatiquement, y compris l’accès aux fichiers sensibles et la sortie du mode Plan. L’agent ne vous pose pas de questions et décide de tout lui-même.

Le mode Plan s’active séparément, avec Shift-Tab ou /plan : l’agent rédige d’abord un plan et attend votre approbation avant de toucher aux fichiers.

Quand je travaille moi-même sans confirmations#

Dans Claude Code, « tout autoriser » est mon réglage par défaut, activé dans chaque nouvelle conversation. Sans cela, le vibe coding est trop lent. Un vibe coder comprend déjà peu de choses, et il doit en plus appuyer sans cesse sur des boutons : oui, oui, oui, non, non, non.

Mais dans ce mode, l’agent peut faire absolument n’importe quoi d’imprudent, y compris effacer une base de données. Il dira ensuite « désolé, toutes mes excuses », mais parfois, ce qu’il a fait est irréparable. Ce mode est donc réservé aux plus téméraires, et vous en êtes responsable.

Voici mes règles. Pour un projet personnel, une expérience ou un prototype, ne considérez le mode sans confirmation que dans une copie ou un conteneur isolé, sans fichiers précieux ni identifiants de production, avec droits limités et sauvegarde. L’absence de clients ne protège ni vos fichiers ni vos clés ; vérifiez aussi l’isolation. Mais si vous activez ce mode dans le même projet qui a accès à un serveur de production, 1 prompt suffit pour que l’agent y supprime la base de données pendant la nuit et déploie des modifications sur le site en production.

Pourquoi une interdiction formulée en toutes lettres ne vous protège pas#

Beaucoup de gens écrivent « ne touche pas à la base de données » dans les instructions de l’agent. Ne comptez pas là-dessus pour vous protéger. Vous lui dites : mon ami, n’entre pas là-dedans. Mais il y ira quand même et prendra ce dont il a besoin au moment où il en aura besoin. C’est particulièrement vrai pour le Kimi chinois : il enfreindra toutes les interdictions que vous lui fixerez. Les modèles américains sont beaucoup mieux entraînés à ne pas le faire.

J’utilise toujours Kimi dans mon travail. Kimi K3 est très attentif ; je m’en sers pour vérifier si des clés ont été divulguées dans des projets et pour recueillir des informations. Une fois, j’ai épuisé toutes ses limites en quelques jours. Kimi ne fait pas de caprices et fait tout ce qu’on lui demande. C’est pourquoi il faut l’isoler quand on travaille avec lui. J’ai décrit ici comment je l’ai testé sur mes propres tâches.

Vous avez besoin de 2 formes d’isolation :

1. Liste de blocage des commandes. Elle bloque les appels d’outils correspondants ; un motif visant une écriture de commande ne couvre pas tous les outils ou actions équivalentes. Complétez-la par les permissions du système, du conteneur et de la base.
2. Un accès à la base de données en lecture seule. Sur la base en production, l’agent dispose d’un utilisateur distinct avec des droits en lecture seule. Ainsi, même en mode Never Ask, il ne peut pas effacer la base de données.

Où la protection contre les commandes dangereuses fonctionne#

La protection intégrée de Kimi Code contre les commandes dangereuses est activée par défaut. Dans les modes Always Ask et Ask When Needed, il demande confirmation avant shutdown, reboot (redémarrer) ou rm -rf. En mode Never Ask, ces commandes s’exécutent sans interruption.

Il existe 2 exceptions :

• rm -rf s’exécute sans demander si la commande ne supprime que le contenu des dossiers temporaires /tmp ou /temp (depuis la version 0.43.0) ;
• en mode Ask When Needed, Kimi Code ne demande pas confirmation pour les commandes du terminal qu’il ne peut pas analyser à l’avance (depuis la version 2.0.1).

Dans la version 0.40.0, le mode Auto bloquait les commandes dangereuses ; ce blocage a été supprimé dans la version 0.41.0.

Vous pouvez désactiver la protection avec dangerous_command_guard = false dans la section [permission] du fichier de paramètres ~/.kimi-code/config.toml, ou avec la variable KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Les développeurs recommandent de ne le faire que dans les environnements où les commandes dangereuses sont déjà interceptées par un mécanisme externe.

Comment définir une interdiction permanente dans Kimi Code#

Lorsque l’agent veut modifier quelque chose, Kimi Code affiche un panneau de confirmation :

• Approuver : utilisez les touches fléchées et Enter, ou appuyez directement sur 1, 2 ou 3 ;
• Refuser : Esc, Ctrl-C ou Ctrl-D ;
• Approuver pour cette session : les appels du même type sont approuvés jusqu’à la fin de la session ;
• Règles permanentes : une règle permanente d’autorisation ou de refus dans le fichier de paramètres.

Les règles permanentes sont écrites dans le fichier de paramètres ~/.kimi-code/config.toml, dans des blocs [[permission.rules]]. Kimi Code les vérifie dans l’ordre ; la première règle correspondante s’applique. Placez donc les interdictions avant les autorisations. Chaque règle comporte un decision : allow (autoriser immédiatement), deny (refuser immédiatement) ou ask (demander à chaque fois).

Une interdiction de rm -rf et une demande de confirmation avant toute autre commande du terminal :

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

Pour les commandes du terminal, le motif se place entre parenthèses : Bash(command-pattern) ; pour la lecture de fichiers, utilisez Read(path-pattern). Les outils MCP, AgentSwarm et vos propres outils ne peuvent être interdits qu’en indiquant leur nom complet.

Si vous n’êtes pas à l’aise avec la technique et ne souhaitez pas ouvrir le fichier de paramètres, collez simplement le prompt ci-dessous dans l’agent : il déterminera lui-même ce qu’il faut restreindre. Demandez-lui simplement de vous dire d’abord dans quelle mesure cela vous ralentira. Si vous avez l’habitude de travailler sans confirmations, certaines choses ne fonctionneront plus après l’ajout des interdictions. Voici mon prompt :

Analyse mon projet et dis-moi si tu as accès au serveur de production, à la base de données de préproduction et aux clés de production. Si c’est le cas, configure une protection contre les commandes dangereuses : interdis la suppression de dossiers entiers, les commandes qui réécrivent irréversiblement l’historique des modifications et les commandes directes adressées à la base de données de production. Présente d’abord un plan au format « avant - après » et dis-moi franchement dans quelle mesure cela me ralentira.

J’ai expliqué comment configurer la même chose dans Claude Code dans un article distinct. Consultez aussi cet article sur la manière dont le mode Auto de Claude Code vérifie les actions de l’agent.

Quel mode choisir ?#

• Vous voulez voir chaque étape effectuée par l’agent : Always Ask, le mode par défaut. Vous confirmez tout, sauf la lecture.
• Projet personnel ou prototype sans vrais clients : commencez avec Always Ask ou Ask When Needed. Réservez Never Ask à une copie isolée jetable aux droits restreints, sans données ni clés précieuses ; l’absence de clients ne le rend pas sûr.
• Un projet avec de vrais clients et un accès au serveur : n’activez pas Never Ask. Définissez des interdictions deny dans config.toml et accordez à l’agent un accès à la base de données en lecture seule.

Et sauvegardez la base de données sur une machine distincte du projet. Les autres règles de sécurité sont réunies dans un article distinct.

Adaptez le mode de confirmation aux droits d’accès de votre projet et vérifiez où des interdictions sont nécessaires.

Découvrez Ailoot.