Kimi Code Never Ask: moduser og farlige kommandoer

I Kimi Code godkjenner Never Ask-modus (/auto) alt automatisk: den kjører rm -rf, shutdown og reboot uten å stille ett eneste spørsmål. Agenten spør bare før disse kommandoene i de 2 andre modusene, Always Ask og Ask When Needed.

Jeg jobber selv i Claude Code med «tillat alt» aktivert; ellers ville vi sittet og klikket: ja, ja, ja.

Selv en personlig prototype kan eksponere verdifulle filer og tilganger. Bruk en isolert kopi eller container med begrensede rettigheter og en verifisert sikkerhetskopi. I kundesystemer gir du i tillegg agenten en egen databaseidentitet med bare nødvendig tilgang. Da kan den ikke slette databasen, selv om den virkelig har lyst.

La oss se på hva hver Kimi Code-modus gjør, hvor beskyttelsen virker, og hvordan du setter et forbud. Da setter vi i gang.

Se Ailoot-dokumentasjonen for informasjon om hvordan du bruker tjenesten.

Hva er forskjellen på de 3 Kimi Code-modusene?#

Hvis du allerede har installert Kimi Code, har du sett godkjenningspanelet: agenten vil redigere en fil eller kjøre en kommando og venter på at du skal si «ja». Modusene het tidligere Manual, YOLO og Auto, og derfor bruker de fortsatt de gamle kommandoene: /yolo og /auto.

Always Ask. Standardmodusen. Agenten leser filer uten å spørre, men du bekrefter hver redigering og hver kommando separat. Dette er den tregeste modusen.

Ask When Needed. Aktiveres med /yolo. Den godkjenner vanlige redigeringer og kommandoer selv, men spør før den åpner .env (filen med prosjektets passord og nøkler) og SSH-nøkler til serveren, før den kjører farlige kommandoer som shutdown (slå av datamaskinen) og rm -rf (slette en hel mappe uten å bruke papirkurven), og før den går ut av planmodus. Agenten kan også stille deg et spørsmål selv.

Never Ask. Aktiveres med /auto. Alle godkjenninger skjer automatisk, også for sensitive filer og når planmodus avsluttes. Agenten stiller deg ingen spørsmål og bestemmer alt selv.

Planmodus aktiveres separat med Shift-Tab eller /plan: agenten skriver først en plan og venter på at du godkjenner den. Deretter gjør den endringer i filene.

Når jeg selv jobber uten bekreftelser#

I Claude Code er «tillat alt» standardvalget mitt, og det er aktivert i hver nye chat. Uten det går vibe coding for sakte. En vibe coder kan allerede veldig lite, og må i tillegg fortsette å trykke på knapper: ja, ja, ja, nei, nei, nei.

Men i denne modusen kan agenten gjøre absolutt hva som helst, også slette en database. Da sier den «beklager, jeg beklager», men noen ganger er det den har gjort umulig å rette opp. Denne modusen er altså for de fryktløse, og du er ansvarlig for den.

Dette er reglene mine. For personlige prosjekter, eksperimenter og prototyper bør modus uten bekreftelser bare brukes i en isolert kopi eller container uten verdifulle filer og produksjonstilganger, med begrensede rettigheter og sikkerhetskopi. Fravær av kunder beskytter ikke personlige filer eller nøkler, og isolasjonen må fortsatt kontrolleres. Men hvis du aktiverer denne modusen i det samme prosjektet som har tilgang til en produksjonsserver, er 1 prompt nok til at agenten kan slette databasen der i løpet av natten og rulle ut endringer til det aktive nettstedet.

Hvorfor et forbud formulert med ord ikke redder deg#

Mange skriver «ikke rør databasen» i instruksjonene til agenten. Ikke regn med at det redder deg. Du sier: kompis, ikke gå inn her. Men den går inn likevel og tar det den trenger når den trenger det. Særlig kinesiske Kimi: den bryter ethvert forbud du setter. Amerikanske modeller er mye bedre trent til å la være.

Jeg bruker fortsatt Kimi i arbeidet mitt. Kimi K3 er svært oppmerksom; jeg bruker den til å kontrollere prosjekter for lekkede nøkler og til å samle informasjon. En gang brukte jeg opp alle grensene dens i løpet av et par dager. Kimi lager ikke bråk og gjør alt du ber om. Derfor trenger du isolering når du jobber med den. Jeg beskrev her hvordan jeg testet den på mine egne oppgaver.

Du trenger 2 former for isolering:

1. En blokkeringsliste for kommandoer i innstillingene. Den blokkerer matchende verktøykall. Et mønster for én skrivemåte er ingen fullstendig grense mot andre verktøy eller tilsvarende handlinger. Bruk den sammen med tillatelser i operativsystem, container og database.
2. Skrivebeskyttet databasetilgang. På databasen i drift har agenten en egen bruker med skrivebeskyttede tillatelser. Da kan agenten ikke slette databasen, selv i Never Ask-modus.

Hvor beskyttelsen mot farlige kommandoer virker#

Kimi Codes innebygde beskyttelse mot farlige kommandoer er aktivert som standard. I Always Ask og Ask When Needed ber den om bekreftelse før shutdown, reboot (starte på nytt) eller rm -rf. I Never Ask kjøres disse kommandoene uten at agenten stopper opp.

Det finnes 2 unntak:

• rm -rf kjøres uten å spørre hvis den bare sletter innholdet i de midlertidige mappene /tmp eller /temp (fra og med versjon 0.43.0);
• i Ask When Needed spør Kimi Code ikke om terminalkommandoer den ikke kan tolke på forhånd (fra og med versjon 2.0.1).

I versjon 0.40.0 blokkerte Auto-modus farlige kommandoer; denne blokkeringen ble fjernet i 0.41.0.

Du kan slå av beskyttelsen med dangerous_command_guard = false i [permission]-delen av innstillingsfilen ~/.kimi-code/config.toml, eller med variabelen KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Utviklerne anbefaler at du bare gjør dette der farlige kommandoer allerede fanges opp eksternt.

Slik setter du et permanent forbud i Kimi Code#

Når agenten vil endre noe, viser Kimi Code et godkjenningspanel:

• Godkjenn: bruk piltastene og Enter, eller trykk direkte på 1, 2 eller 3;
• Avslå: Esc, Ctrl-C eller Ctrl-D;
• Godkjenn for denne økten: samme type kall godkjennes fram til økten er over;
• Permanente regler: en permanent allow- eller deny-regel i innstillingsfilen.

Permanente regler skrives i blokker med [[permission.rules]] i innstillingsfilen ~/.kimi-code/config.toml. Kimi Code sjekker dem i rekkefølge, og den første regelen som samsvarer, gjelder. Legg derfor forbud over tillatelser. Hver regel har en decision: allow (tillat umiddelbart), deny (avslå umiddelbart) eller ask (spør hver gang).

Et forbud mot rm -rf og spørsmål før alle andre terminalkommandoer:

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

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

For terminalkommandoer står mønsteret i parenteser: Bash(command-pattern); for lesing av filer bruker du Read(path-pattern). MCP-verktøy, AgentSwarm og dine egne verktøy kan bare forbys ved å bruke hele navnet deres.

Hvis du ikke er teknisk og ikke vil åpne innstillingsfilen, kan du bare lime inn prompten nedenfor i agenten: den finner selv ut hva som må begrenses. Be den først fortelle deg hvor mye dette vil gjøre arbeidet ditt tregere. Hvis du er vant til å jobbe uten bekreftelser, kan enkelte ting slutte å fungere når du har lagt til forbudene. Her er prompten min:

Analyser prosjektet mitt og fortell meg om du har tilgang til produksjonsserveren, stagingdatabasen og produksjonsnøkler. Hvis du har det, konfigurer beskyttelse mot farlige kommandoer: forby sletting av hele mapper, kommandoer som skriver om endringshistorikken på en irreversibel måte, og direkte kommandoer mot produksjonsdatabasen. Vis først en plan i formatet «før - etter», og fortell ærlig hvor mye dette vil gjøre arbeidet mitt tregere.

Jeg har beskrevet hvordan du konfigurerer det samme i Claude Code i en egen artikkel. Se også hvordan Auto-modus i Claude Code kontrollerer agentens handlinger.

Hvilken modus bør du velge?#

• Du vil se hvert steg agenten tar: Always Ask, standardmodusen. Du bekrefter alt bortsett fra lesing.
• Et personlig prosjekt eller en prototype uten faktiske kunder: begynn med Always Ask eller Ask When Needed. Vurder Never Ask bare i en isolert engangskopi med begrensede rettigheter og uten verdifulle data eller nøkler. Prosjektet blir ikke trygt bare fordi det mangler kunder.
• Et prosjekt med faktiske kunder og tilgang til serveren: ikke aktiver Never Ask. Sett deny-forbud i config.toml, og gi agenten skrivebeskyttet databasetilgang.

Ta også sikkerhetskopi av databasen på en maskin som er separat fra prosjektet. De andre sikkerhetsreglene er samlet i en egen artikkel.

Tilpass bekreftelsesmodusen til prosjektets tilgangstillatelser, og sjekk hvor det trengs forbud.

Bli kjent med Ailoot.