Configurar guardrails
Este guia mostra como configurar guardrails: as regras que decidem se a ação de um agente é executada, se pede aprovação primeiro ou se é recusada.
Os guardrails cobrem as treze classes de efeito que toda ferramenta mutável declara. Eles são aplicados no servidor, no ponto em que a ferramenta é chamada, nunca por uma instrução em um prompt.
Definir uma decisão para uma classe de ação
Seção intitulada “Definir uma decisão para uma classe de ação”- Acesse Configurações → Espaço de trabalho → Permissões dos agentes
- Escolha um escopo no controle segmentado: Espaço de trabalho, Agente (e então escolha o agente) ou Espaço (e então escolha o espaço)
- Na linha da classe de ação, escolha Permitir, Perguntar primeiro ou Negar
- Para remover uma regra que você definiu, pressione o botão de redefinição que aparece no fim dessa linha (Limpar para o herdado) — a decisão volta para o escopo mais amplo
Cada linha mostra a decisão efetiva como uma etiqueta de status e um selo da
origem dela: Este escopo, Herdado ou Padrão integrado. A matriz é
resolvida no modo Agente (chat), então Predefinição de modo nunca aparece
aqui — use a sonda hipotética com um modo somente leitura selecionado para
ver essa camada.
Escrever uma regra exige a função admin. Ler a matriz não.
Ponto de verificação: defina Fazer push para um remoto como Negar no
escopo do espaço de trabalho e execute a sonda hipotética abaixo em
git push origin main. O resultado mostra deny com origem workspace.
Entenda como uma decisão é resolvida
Seção intitulada “Entenda como uma decisão é resolvida”A resolução é especificidade primeiro, restrição depois:
- Regras de espaço, depois de agente, depois de espaço de trabalho. O primeiro escopo com uma regra correspondente decide e a resolução para
- Se nenhuma regra corresponder, aplica-se a predefinição de modo — um modo somente leitura (plano, revisão, orquestração) recusa onze das treze classes
- Se o modo não tiver nada a dizer, aplica-se o padrão integrado
Dentro de um mesmo escopo, uma regra de comando é resolvida pelo prefixo correspondente mais longo, e um conflito igualmente específico é resolvido pelo mais restritivo — negar prevalece sobre perguntar primeiro, que prevalece sobre permitir. Uma ação que declara várias classes resolve cada uma de forma independente e depois as combina pelo mais restritivo.
Uma decisão Perguntar primeiro exibe um único pedido de aprovação que cobre
todas as classes resolvidas para prompt. Sem nenhum aprovador conectado,
ela é negada, tanto para comandos de shell quanto para chamadas de ferramentas
do harness. Isso é intencional: uma execução sem controle é pior do que uma
recusada.
Classes de ação e padrões integrados
Seção intitulada “Classes de ação e padrões integrados”| Classe de ação | Padrão integrado |
|---|---|
| Excluir um arquivo | Perguntar primeiro |
| Escrever fora do worktree | Permitir |
| Criar um commit | Permitir |
| Fazer push para um remoto | Perguntar primeiro |
| Abrir um pull request | Perguntar primeiro |
| Publicar uma revisão ou fazer merge | Perguntar primeiro |
| Escrever em um rastreador externo | Perguntar primeiro |
| Acessar a rede | Permitir |
| Ler um segredo | Permitir |
| Instalar um pacote | Permitir |
| Executar um processo | Permitir |
| Alterar a estrutura do espaço de trabalho | Permitir |
| Controlar um recinto (rig) | Permitir |
A taxonomia é fechada. Uma ferramenta nova lançada sem declarar suas classes falha em um teste de catraca no CI, então nada chega com um conjunto de efeitos silenciosamente vazio.
Teste uma regra com a sonda hipotética
Seção intitulada “Teste uma regra com a sonda hipotética”Antes de alterar uma regra, verifique como a política atual já a resolve.
- Na mesma página, role até E se?
- Escolha uma Ação (uma das treze classes)
- Opcionalmente, preencha Comando (por exemplo,
git push origin main), Agente, Espaço e Modo - Leia o resultado: a decisão, o motivo e a Origem:
A sonda executa o mesmo resolvedor usado pelo caminho de aplicação, com base nas suas regras em vigor, então a resposta é exata. Se ela surpreender você, altere uma regra na matriz acima e sonde de novo.
Definir a autonomia de um espaço
Seção intitulada “Definir a autonomia de um espaço”O controle de autonomia é por agente em cada espaço e se compõe com as regras, em vez de substituí-las.
- Abra o espaço
- Abra Gerenciar participantes no cabeçalho do espaço
- Em Autonomia, na linha do agente, escolha um nível:
| Nível | Efeito |
|---|---|
| Padrão | Nenhuma configuração de espaço — se comporta como Agir com aprovação |
| Somente propor | Toda ferramenta controlada é negada de imediato, com uma mensagem dizendo ao agente para propor a ação em vez disso |
| Agir com aprovação | Ações arriscadas passam pelo portão de aprovação com fechamento seguro |
| Agir livremente | Pré-aprova tudo que não resolveu para uma negação rígida |
O controle de autonomia só alcança o harness integrado. O adaptador Claude Code executa as próprias ferramentas fora desse portão.
Saiba onde os guardrails não chegam
Seção intitulada “Saiba onde os guardrails não chegam”A tabela Onde as regras são aplicadas, no fim da mesma página, é a versão dentro do app disto: por classe de efeito, ela diz se cada executor a captura no portão de política, se a deixa para o sandbox ou se não consegue interceptá-la de forma alguma.
- O adaptador Claude Code só passa por um portão em parte das próprias
chamadas de ferramentas. O Claude Code é iniciado com
--dangerously-skip-permissions, então suas chamadas de leitura, escrita e edição nunca passam pela verificação dos guardrails. Seus comandos de bash chegam a ela por meio de um hook que classifica a linha de comando, e seus pushes passam pelo gateway de push como os de qualquer agente. Também passam pelo portão a superfície de ferramentas MCP para a qual ele chama de volta e o comando de shell que o Control Center gera para iniciá-lo. - O verbo de saída de um modo (
submit_plan,propose_orchestration) é fixado e nunca pode ser negado — caso contrário, um modo ficaria estruturalmente incapaz de produzir seu único entregável. - Se o sandbox dá suporte a essas regras depende do host. Onde o
cc_serverencontra um backend, ele envolve a CLI do Claude Code e a ferramentabashdo harness, então uma regra que você não escreveu ainda tem um piso do sistema operacional por baixo dela. No Windows não há nenhum, e no Linux ou WSL2 sembwrapesocattambém não há — ali, os guardrails mais a superfície de ferramentas do modo são toda a aplicação, não uma segunda linha dela. Verifique em qual caso você está em Configurar políticas de sandbox.