Kimi Code Never Ask: modos e comandos perigosos

No Kimi Code, o modo Never Ask (/auto) aprova tudo automaticamente: executa rm -rf, shutdown e reboot sem fazer uma única pergunta. O agente só pergunta antes destes comandos nos outros 2 modos, Always Ask e Ask When Needed.

Eu próprio trabalho no Claude Code com a opção «permitir tudo» ativada; caso contrário, ficaríamos ali a clicar: sim, sim, sim. Mas uma vez em cada 10, o agente faz as coisas à sua maneira.

Mesmo um protótipo pessoal pode expor ficheiros e credenciais valiosos. Use uma cópia isolada ou um contentor com permissões limitadas e uma cópia de segurança verificada; nos sistemas de clientes, atribua também ao agente uma identidade de base de dados separada, apenas com o acesso necessário.

Vamos ver o que faz cada modo do Kimi Code, onde funciona a proteção e como configurar uma proibição. Vamos a isso.

Para obter informações sobre como utilizar o serviço, consulte a documentação do Ailoot.

Em que diferem os 3 modos do Kimi Code?#

Se já instalou o Kimi Code, já viu o painel de aprovação: o agente quer editar um ficheiro ou executar um comando e fica à espera do seu «sim». Os modos chamavam-se anteriormente Manual, YOLO e Auto, daí continuarem a utilizar os comandos antigos: /yolo e /auto.

Always Ask. O modo predefinido. O agente lê ficheiros sem perguntar, mas confirma cada edição e cada comando separadamente. É o modo mais lento.

Ask When Needed. Ativa-se com /yolo. Aprova por si só as edições e os comandos comuns, mas pergunta antes de aceder a .env (o ficheiro que contém as palavras-passe e as chaves do projeto) e às chaves SSH do servidor, antes de comandos perigosos como shutdown (desligar o computador) e rm -rf (apagar uma pasta inteira, sem passar pelo lixo), e antes de sair do modo de planeamento. O agente também pode fazer-lhe perguntas.

Never Ask. Ativa-se com /auto. Todas as aprovações acontecem automaticamente, incluindo as de ficheiros sensíveis e a saída do modo de planeamento. O agente não lhe faz perguntas e decide tudo por si.

O modo de planeamento é ativado separadamente, com Shift-Tab ou /plan: primeiro, o agente escreve um plano e aguarda a sua aprovação; só depois mexe nos ficheiros.

Quando trabalho sem confirmações#

No Claude Code, a opção «permitir tudo» é a minha predefinição e fica ativada em cada conversa nova. Sem ela, programar desta forma é demasiado lento. Quem programa assim já percebe muito pouco e ainda tem de estar sempre a carregar em botões: sim, sim, sim, não, não, não.

Mas, neste modo, o agente pode fazer qualquer coisa imprudente, incluindo apagar uma base de dados. Depois diz «desculpe, peço imensa desculpa», mas por vezes já não é possível corrigir o que fez. Por isso, este modo é para quem não tem medo, e a responsabilidade é sua.

Estas são as minhas regras. Em projetos pessoais, experiências e protótipos, use o modo sem confirmações só numa cópia isolada ou num contentor sem ficheiros valiosos nem credenciais de produção, com permissões limitadas e cópia de segurança. A ausência de clientes não protege os seus ficheiros ou chaves, e o isolamento também precisa de ser verificado. Mas, se ativar este modo no mesmo projeto que tem acesso a um servidor de produção, basta 1 pedido para o agente apagar a base de dados durante a noite e implementar alterações no site em produção.

Porque é que uma proibição escrita por palavras não o protege#

Muitas pessoas escrevem «não mexas na base de dados» nas instruções do agente. Não conte com isso para se proteger. Diz-lhe: amigo, não entres aqui. Mas ele entra na mesma e vai buscar o que precisa quando precisa. Isto acontece sobretudo com o Kimi chinês: viola qualquer proibição que configure. Os modelos americanos são muito mais bem treinados para não o fazer.

Continuo a usar o Kimi no meu trabalho. O Kimi K3 é muito atento; uso-o para verificar se há chaves expostas nos projetos e para recolher informações. Uma vez, esgotei todos os seus limites em poucos dias. O Kimi não se porta mal e faz tudo o que lhe pedimos. Por isso, precisa de isolamento quando trabalha com ele. Descrevi aqui como o testei nas minhas próprias tarefas.

Precisa de 2 formas de isolamento:

1. Uma lista de bloqueio de comandos nas definições. Bloqueia chamadas correspondentes às ferramentas; um padrão para uma forma de escrever um comando não cobre outras ferramentas ou ações equivalentes. Combine-a com permissões do sistema operativo, do contentor e da base de dados.
2. Acesso à base de dados só de leitura. Na base de dados em produção, o agente tem um utilizador separado com permissões apenas de leitura. Assim, nem mesmo no modo Never Ask o agente consegue apagar a base de dados.

Onde funciona a proteção contra comandos perigosos#

A proteção integrada do Kimi Code contra comandos perigosos está ativada por predefinição. Nos modos Always Ask e Ask When Needed, pede confirmação antes de shutdown, reboot (reiniciar) ou rm -rf. No modo Never Ask, estes comandos são executados sem interrupção.

Há 2 exceções:

• rm -rf é executado sem perguntar se apagar apenas o conteúdo das pastas temporárias /tmp ou /temp (desde a versão 0.43.0);
• no modo Ask When Needed, o Kimi Code não pergunta sobre comandos de terminal que não consegue analisar antecipadamente (desde a versão 2.0.1).

Na versão 0.40.0, o modo Auto bloqueava comandos perigosos; esse bloqueio foi removido na versão 0.41.0.

Pode desativar a proteção com dangerous_command_guard = false na secção [permission] do ficheiro de definições ~/.kimi-code/config.toml ou com a variável KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Os programadores recomendam fazê-lo apenas nos casos em que os comandos perigosos já são intercetados externamente.

Como configurar uma proibição permanente no Kimi Code#

Quando o agente quer alterar alguma coisa, o Kimi Code mostra um painel de aprovação:

• Aprovar: utilize as teclas de seta e Enter, ou prima diretamente 1, 2 ou 3;
• Rejeitar: Esc, Ctrl-C ou Ctrl-D;
• Aprovar para esta sessão: o mesmo tipo de chamada é aprovado até ao fim da sessão;
• Regras permanentes: uma regra permanente de autorização ou proibição no ficheiro de definições.

As regras permanentes são escritas no ficheiro de definições ~/.kimi-code/config.toml, em blocos [[permission.rules]]. O Kimi Code verifica-as por ordem e aplica a primeira correspondência; por isso, coloque as proibições antes das permissões. Cada regra tem uma opção decision: allow (permitir imediatamente), deny (negar imediatamente) ou ask (perguntar sempre).

Uma proibição para rm -rf e uma pergunta antes de qualquer outro comando de terminal:

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

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

Para comandos de terminal, o padrão fica entre parênteses: Bash(command-pattern); para ler ficheiros, Read(path-pattern). As ferramentas MCP, AgentSwarm e as suas próprias ferramentas só podem ser proibidas pelos respetivos nomes completos.

Se não tem conhecimentos técnicos e não quer abrir o ficheiro de definições, basta colar o pedido abaixo no agente: ele descobrirá o que precisa de ser restringido. Peça-lhe apenas que lhe diga primeiro o quanto isso o vai atrasar. Se está habituado a trabalhar sem confirmações, algumas coisas deixarão de funcionar depois de adicionar as proibições. Eis o meu pedido:

Analisa o meu projeto e diz-me se tens acesso ao servidor de produção, à base de dados de staging e às chaves de produção. Se tiveres, configura a proteção contra comandos perigosos: proíbe a eliminação de pastas inteiras, os comandos que reescrevem irreversivelmente o histórico de alterações e os comandos diretos para a base de dados de produção. Mostra primeiro um plano no formato «antes - depois» e diz-me honestamente quanto isso me vai atrasar.

Expliquei como configurar a mesma coisa no Claude Code num artigo separado. Veja também como o modo Auto no Claude Code verifica as ações do agente.

Que modo escolher#

• Quer ver cada passo que o agente executa: Always Ask, o modo predefinido. Confirma tudo, exceto a leitura.
• Um projeto pessoal ou protótipo sem clientes reais: comece por Always Ask ou Ask When Needed. Considere Never Ask apenas numa cópia isolada e descartável, com permissões restritas e sem dados ou chaves valiosos; a ausência de clientes não lhe confere segurança.
• Um projeto com clientes reais e acesso ao servidor: não ative Never Ask. Configure proibições deny em config.toml e dê ao agente acesso à base de dados apenas para leitura.

E faça uma cópia de segurança da base de dados num computador separado do projeto. As restantes regras de segurança estão reunidas num artigo separado.

Adapte o modo de confirmação às permissões de acesso do seu projeto e verifique onde precisa de proibições.

Conheça o Ailoot.