Kimi Code Never Ask: tilstande og farlige kommandoer

I Kimi Code godkender Never Ask-tilstanden (/auto) alt automatisk: Den udfører rm -rf, shutdown og reboot uden at stille et eneste spørgsmål. Agenten spørger kun, før den udfører disse kommandoer, i de 2 andre tilstande, Always Ask og Ask When Needed.

Jeg arbejder selv i Claude Code med ”tillad alt” slået til; ellers ville vi sidde og klikke: ja, ja, ja.

Selv en personlig prototype kan eksponere værdifulde filer og legitimationsoplysninger. Brug en isoleret kopi eller container med begrænsede tilladelser og en verificeret sikkerhedskopi. Giv desuden agenten en separat databaseidentitet med kun den nødvendige adgang i kundesystemer. Så kan den ikke slette databasen, selv hvis den virkelig gerne vil.

Lad os se på, hvad hver Kimi Code-tilstand gør, hvor beskyttelsen virker, og hvordan du indstiller et forbud. Lad os komme i gang.

Se Ailoot-dokumentationen for oplysninger om, hvordan du bruger tjenesten.

Hvad er forskellen på Kimi Codes 3 tilstande?#

Hvis du allerede har installeret Kimi Code, har du set godkendelsespanelet: Agenten vil redigere en fil eller køre en kommando og venter på dit ”ja”. Tilstandene hed tidligere Manual, YOLO og Auto, og derfor bruger de stadig de gamle kommandoer: /yolo og /auto.

Always Ask. Standardtilstanden. Agenten læser filer uden at spørge, men du bekræfter hver redigering og hver kommando separat. Det er den langsomste tilstand.

Ask When Needed. Aktiveres med /yolo. Den godkender selv almindelige redigeringer og kommandoer, men spørger, før den får adgang til .env (filen med projektets adgangskoder og nøgler) og SSH-nøgler til servere, før farlige kommandoer som shutdown (sluk computeren) og rm -rf (slet en hel mappe uden om papirkurven), og før den forlader planlægningstilstand. Agenten kan også selv stille dig et spørgsmål.

Never Ask. Aktiveres med /auto. Alle godkendelser gives automatisk, også for følsomme filer og for at forlade planlægningstilstand. Agenten stiller dig ingen spørgsmål og beslutter alt selv.

Planlægningstilstand aktiveres separat med Shift-Tab eller /plan: Agenten skriver først en plan og venter på din godkendelse, før den rører filerne.

Når jeg selv arbejder uden bekræftelser#

I Claude Code er ”tillad alt” min standardindstilling, og den er slået til i hver ny chat. Uden den går vibe coding for langsomt. En vibe coder forstår i forvejen meget lidt og skal så blive ved med at trykke på knapper: ja, ja, ja, nej, nej, nej.

Men i denne tilstand kan agenten gøre hvad som helst helt hovedløst, også slette en database. Bagefter siger den ”undskyld, jeg beklager”, men nogle gange kan det, den har gjort, ikke længere gøres godt igen. Så denne tilstand er for de frygtløse, og ansvaret er dit.

Mine regler er disse. Brug kun tilstand uden bekræftelser til personlige projekter, eksperimenter og prototyper i en isoleret kopi eller container uden værdifulde filer eller produktionshemmeligheder, med begrænsede tilladelser og en sikkerhedskopi. Fraværet af kunder beskytter ikke dine personlige filer eller nøgler, og isoleringen skal stadig kontrolleres. Men hvis du aktiverer denne tilstand i det samme projekt, som har adgang til en produktionsserver, er 1 prompt nok til, at agenten sletter databasen dér i løbet af natten og udruller ændringer til det aktive websted.

Hvorfor et forbud med ord ikke redder dig#

Mange skriver ”rør ikke databasen” i agentens instruktioner. Regn ikke med, at det redder dig. Du siger: makker, gå ikke herind. Men den går alligevel ind og tager det, den har brug for, når den har brug for det. Især den kinesiske Kimi: Den overtræder ethvert forbud, du indfører. Amerikanske modeller er meget bedre trænet til ikke at gøre det.

Jeg bruger stadig Kimi i mit arbejde. Kimi K3 er meget opmærksom; jeg bruger den til at tjekke projekter for lækkede nøgler og indsamle oplysninger. Engang brugte jeg alle dens begrænsninger op på et par dage. Kimi laver ikke ballade og gør alt, hvad du beder om. Derfor skal du isolere den, når du arbejder med den. Jeg har beskrevet, hvordan jeg testede den på mine egne opgaver her.

Du har brug for 2 former for isolering:

1. En kommandoblokliste i indstillingerne. Den blokerer matchende værktøjskald; et mønster for én kommandostavemåde er ikke en fuldstændig grænse mod andre værktøjer eller tilsvarende handlinger. Brug den sammen med tilladelser i operativsystem, container og database.
2. Skrivebeskyttet databaseadgang. På den aktive database har agenten en separat bruger med skrivebeskyttede rettigheder. Så kan agenten ikke slette databasen, selv i Never Ask.

Hvor virker beskyttelsen mod farlige kommandoer?#

Kimi Codes indbyggede beskyttelse mod farlige kommandoer er slået til som standard. I Always Ask og Ask When Needed beder den om bekræftelse, før den udfører shutdown, reboot (genstart) eller rm -rf. I Never Ask udføres disse kommandoer uden at blive standset.

Der er 2 undtagelser:

• rm -rf kører uden at spørge, hvis det kun sletter indholdet i de midlertidige mapper /tmp eller /temp (siden version 0.43.0);
• i Ask When Needed spørger Kimi Code ikke om terminalkommandoer, som den ikke kan analysere på forhånd (siden version 2.0.1).

I version 0.40.0 blokerede Auto-tilstanden farlige kommandoer; blokeringen blev fjernet i 0.41.0.

Du kan slå beskyttelsen fra med dangerous_command_guard = false i afsnittet [permission] i indstillingsfilen ~/.kimi-code/config.toml eller med variablen KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Udviklerne anbefaler kun at gøre dette på steder, hvor farlige kommandoer allerede opfanges eksternt.

Sådan indstiller du et permanent forbud i Kimi Code#

Når agenten vil ændre noget, viser Kimi Code et godkendelsespanel:

• Approve: brug piletasterne og Enter, eller tryk direkte på 1, 2 eller 3;
• Reject: Esc, Ctrl-C eller Ctrl-D;
• Approve for this session: samme type kald godkendes indtil sessionens afslutning;
• Permanent rules: en permanent tillad- eller deny-regel i indstillingsfilen.

Permanente regler skrives i indstillingsfilen ~/.kimi-code/config.toml i blokke med [[permission.rules]]. Kimi Code kontrollerer dem i rækkefølge, og den første regel, der matcher, gælder, så placér forbud over tilladelser. Hver regel har en decision: allow (tillad straks), deny (afvis straks) eller ask (spørg hver gang).

Et forbud mod rm -rf og et spørgsmål før alle andre terminalkommandoer:

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

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

For terminalkommandoer sættes mønsteret i parenteser: Bash(command-pattern); ved læsning af filer bruges Read(path-pattern). MCP-værktøjer, AgentSwarm og dine egne værktøjer kan kun forbydes ved deres fulde navne.

Hvis du ikke er teknisk anlagt og ikke vil åbne indstillingsfilen, kan du blot indsætte prompten nedenfor i agenten: Den finder selv ud af, hvad der skal begrænses. Bed den bare om først at fortælle dig, hvor meget det vil sænke dig. Hvis du er vant til at arbejde uden bekræftelser, vil noget holde op med at fungere, når du har tilføjet forbuddene. Her er min prompt:

Analysér mit projekt, og fortæl mig, om du har adgang til produktionsserveren, stagingdatabasen og produktionsnøglerne. Hvis du har det, skal du konfigurere beskyttelse mod farlige kommandoer: forbyd sletning af hele mapper, kommandoer, der uigenkaldeligt omskriver ændringshistorikken, og direkte kommandoer mod produktionsdatabasen. Vis først en plan i formatet ”før – efter”, og fortæl ærligt, hvor meget det vil sænke mig.

Jeg har beskrevet, hvordan du indstiller det samme i Claude Code i en separat artikel. Se også hvordan Auto-tilstanden i Claude Code kontrollerer agentens handlinger.

Hvilken tilstand skal du vælge?#

• Du vil se hvert trin, agenten tager: Always Ask, standardtilstanden. Du bekræfter alt undtagen læsning.
• Et personligt projekt eller en prototype uden rigtige kunder: Start med Always Ask eller Ask When Needed. Overvej kun Never Ask til en isoleret kopi, der kan kasseres, med begrænsede tilladelser og uden værdifulde data eller nøgler; projektet bliver ikke sikkert alene ved at mangle kunder.
• Et projekt med rigtige kunder og adgang til en server: Aktivér ikke Never Ask. Indstil deny-forbud i config.toml, og giv agenten skrivebeskyttet databaseadgang.

Tag også en sikkerhedskopi af databasen på en maskine, der er adskilt fra projektet. De øvrige sikkerhedsregler er samlet i en separat artikel.

Tilpas bekræftelsestilstanden efter dit projekts adgangsrettigheder, og kontrollér, hvor der er brug for forbud.

Lær Ailoot at kende.