Módulo 6 - Permissões e segurança

O controle fino: liberar, perguntar e bloquear

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 13/07/2026

O que você vai aprender

  • Diferenciar as regras de liberar, perguntar e bloquear.
  • Pre-aprovar ferramentas confiaveis para reduzir interrupcoes.
  • Bloquear o que nunca deve rodar, mesmo em modos soltos.
  • Entender que bloquear vence liberar.

Três tipos de regra sobre o modo

O modo define o comportamento geral, mas você pode afina-lo com regras para ferramentas e comandos específicos. São três tipos. Liberar pre-aprova algo confiavel, para o agente rodar sem perguntar mesmo no modo cauteloso, como o comando que roda os testes. Perguntar forca a aprovação de algo delicado, mesmo quando o modo em geral não pediria, como qualquer acesso a internet. Bloquear impede de vez que uma ferramenta ou comando rode, valendo em todos os modos. Com essas três, você esculpe um Claude Code sob medida: menos interrupcao no que é seguro, mais atrito no que é delicado, e portas fechadas para o que é proibido.

Diagrama com três caixas de regra sobre o comportamento do modo: liberar, com um sinal verde pre-aprovando o comando de testes; perguntar, com um sinal amarelo forcando aprovação para acesso a internet; e bloquear, com um sinal vermelho impedindo um comando destrutivo, com uma nota de que bloquear vence liberar.
Liberar, perguntar e bloquear: o controle fino que você coloca sobre o modo de permissão.

As regras ficam nos arquivos de configuração do Claude Code, os mesmos que você viu de leve no módulo de memória e que um módulo próprio vai detalhar. Cada regra nomeia uma ferramenta, e as de comando podem nomear até um padrão específico, como liberar só o comando de testes e não qualquer comando de terminal. Isso permite uma pontaria fina: você libera exatamente o que confia, sem abrir a porteira. Configurar isso uma vez para o seu projeto costuma valer muito, porque tira do caminho as aprovações repetitivas de coisas seguras, deixando a sua atenção para o que realmente importa.

Liberar com pontaria, não abrir a porteira

A tentacao ao configurar regras de liberar e ser generoso demais, liberando tudo de uma categoria para nunca mais ser interrompido. E um erro clássico de segurança. Liberar qualquer comando de terminal, por exemplo, pre-aprova também os comandos perigosos, e você perde a rede de proteção justamente onde ela mais importa. O caminho seguro e a pontaria: libere comandos específicos e conhecidos, como o de rodar testes ou o de ver o status do controle de versão, e deixe o resto pedindo aprovação. Assim você ganha fluidez no que faz o tempo todo sem baixar a guarda no que pode dar errado.

Liberar sem pontaria (arriscado)

  • Liberar qualquer comando de terminal.
  • Liberar toda e qualquer escrita de arquivo em qualquer lugar.
  • Liberar tudo para nunca ser interrompido.

Liberar com pontaria (seguro)

  • Liberar só o comando de rodar os testes.
  • Liberar edições apenas dentro da pasta de trabalho.
  • Liberar o repetitivo e seguro; deixar o resto pedindo.

🎮 Jogo da aula

Boa regra de permissão?

Para cada afirmacao sobre regras de permissão, diga se e verdadeira ou falsa.

Vale lembrar de onde vem essa fluidez sem risco: no módulo do fluxo agêntico você viu que ferramentas só de leitura já correm livres, e que comandos de terminal apenas de leitura também. As regras de liberar são para ir além disso, pre-aprovando ações que mudam algo mas que você considera seguras naquele projeto. Como são ações que alteram, o cuidado com a pontaria e maior. Um bom exercício ao configurar e perguntar, para cada regra de liberar, o que acontece de pior se isto rodar sem eu ver? Se a resposta assustar, a regra e ampla demais.

Bloquear o inegociavel

Se as regras de liberar dao fluidez, as de bloquear dao paz. Elas impedem que uma ferramenta ou comando rode, e a forca delas está em valerem em todos os modos, até nos mais automáticos. Isso as torna a defesa certa para o que é inegociavel no seu projeto: comandos destrutivos que você nunca quer que o agente execute, acesso a arquivos sensíveis, qualquer coisa que, se rodasse por engano, causaria estrago sério. E aqui vale a regra que resolve conflitos: bloquear sempre vence liberar. Se por acaso uma regra ampla liberou algo e uma regra de bloquear o proibiu, a trava ganha, por segurança.

Um detalhe que da tranquilidade extra: mesmo sem você configurar nada, o Claude Code já protege por conta própria um conjunto de caminhos sensíveis, como a pasta de controle de versão e a própria configuração dele, que nunca são alterados sem aprovação, salvo no modo sem freios. E o tema da próxima aula. Por ora, a mensagem e que você tem duas camadas de defesa: as proteções que a ferramenta já traz e as regras de bloquear que você adiciona para o seu contexto específico. Juntas, elas garantem que, por mais autonomia que você de ao agente, existam linhas que ele simplesmente não cruza.

Teste rápido

Uma regra libera uma categoria ampla e outra regra bloqueia um comando específico dela. O que acontece com esse comando?

Perguntas frequentes

Onde ficam as regras de permissão?
Nos arquivos de configuração do Claude Code, os mesmos que guardam outras preferências e que um módulo próprio detalha. Cada regra nomeia uma ferramenta, e as de comando podem nomear um padrão específico. Você configura uma vez por projeto e colhe menos interrupcoes no seguro e mais atrito no delicado.
Liberar uma categoria inteira e ma ideia?
Geralmente sim. Liberar toda uma categoria, como qualquer comando de terminal, pre-aprova também os comandos perigosos, e você perde a proteção onde mais importa. Prefira a pontaria: libere comandos específicos e conhecidos e deixe o resto pedindo aprovação. Pergunte-se o que aconteceria de pior se aquilo rodasse sem você ver.
As regras valem em todos os modos?
As de bloquear e as de perguntar sim, inclusive nos modos automáticos. As de liberar tem efeito nos modos que pediriam aprovação; no modo sem freios, como tudo já é liberado, elas não mudam nada, mas as de bloquear e perguntar continuam valendo. Por isso bloquear e a defesa mais confiavel.
O que é bom candidato a bloquear?
Comandos destrutivos que você nunca quer que o agente rode, a leitura de arquivos com segredos como senhas e chaves, e qualquer ação difícil de desfazer. A regra de bloquear cria linhas que o agente não cruza em nenhum modo, o que traz tranquilidade mesmo quando você da mais autonomia.
Preciso configurar regras para usar o Claude Code?
Não. Ele funciona bem sem nenhuma regra extra, com o comportamento do modo escolhido e as proteções que já traz. As regras são um refinamento: valem a pena quando você percebe aprovações repetitivas de coisas seguras ou quer travar algo específico do seu projeto. Comece simples e ajuste conforme a necessidade.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.