Saltar para o conteúdo

Configurar guardrails

Este guia mostra-lhe como configurar as guardrails: as regras que decidem se a ação de um agente é executada, se pede aprovação primeiro ou se é recusada.

As guardrails abrangem as treze classes de efeitos que cada ferramenta mutável declara. São aplicadas do lado do servidor, no momento em que a ferramenta é chamada, nunca por uma instrução num prompt.

  1. Aceda a Definições → Espaço de trabalho → Permissões dos agentes
  2. Escolha um âmbito com o controlo segmentado: Espaço de trabalho, Agente (e depois escolha o agente) ou Espaço (e depois escolha o espaço)
  3. Na linha da classe de ações, escolha Permitir, Perguntar primeiro ou Negar
  4. Para remover uma regra que definiu, pressione o botão de reposição que aparece no fim dessa linha (Repor para o valor herdado) — a decisão recai sobre o âmbito mais amplo

Cada linha mostra a decisão efetiva como uma etiqueta de estado e um distintivo com a sua origem: Este âmbito, Herdado ou Predefinição. A matriz resolve-se no modo Agente (chat), pelo que Predefinição do modo nunca aparece aqui — use a sonda «E se?» com um modo só de 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 âmbito do espaço de trabalho e, em seguida, execute a sonda «E se?» abaixo com git push origin main. O resultado indica deny com origem workspace.

A resolução dá primeiro prioridade à especificidade e depois à restritividade:

  1. Regras de Espaço, depois de agente, depois de espaço de trabalho. O primeiro âmbito com uma regra correspondente decide e a resolução termina aí
  2. Se nenhuma regra corresponder, aplica-se a predefinição do modo — um modo só de leitura (plan, review, orchestrate) recusa onze das treze classes
  3. Se o modo não tiver nada a dizer, aplica-se a predefinição

Dentro de um mesmo âmbito, uma regra de comando resolve-se pelo prefixo correspondente mais longo e um conflito igualmente específico resolve-se 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 combina-as pelo mais restritivo.

Uma decisão Perguntar primeiro apresenta um único pedido de aprovação que abrange todas as classes resolvidas como prompt. Sem um aprovador ligado, a ação é negada, tanto para comandos de shell como para chamadas de ferramentas do harness. Isto é intencional: uma execução sem controlo é pior do que uma recusada.

Classe de ação Predefinição
Eliminar um ficheiro Perguntar primeiro
Escrever fora da árvore de trabalho 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 num rastreador externo Perguntar primeiro
Aceder à 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 nova ferramenta lançada sem declarar as suas classes falha um teste de trinquete em CI, pelo que nada chega com um conjunto de efeitos silenciosamente vazio.

Antes de alterar uma regra, verifique como a política atual já a resolve.

  1. Na mesma página, desça até E se?
  2. Escolha uma Ação (uma das treze classes)
  3. Opcionalmente, preencha Comando (por exemplo git push origin main), Agente, Espaço e Modo
  4. Leia o resultado: a decisão, o motivo e Origem:

A sonda executa o mesmo resolvedor que o percurso de aplicação usa, sobre as suas regras em vigor, pelo que a resposta é exata. Se o resultado o surpreender, altere uma regra na matriz acima e volte a sondar.

O dial é por agente e por espaço e compõe-se com as regras em vez de as substituir.

  1. Abra o espaço
  2. Abra Gerir participantes a partir do cabeçalho do espaço
  3. Em Autonomia, na linha do agente, escolha um nível:
Nível Efeito
Padrão Sem definição no espaço — comporta-se como Agir com aprovação
Somente propor Todas as ferramentas controladas são negadas de imediato, com uma mensagem a dizer ao agente para propor a ação em vez disso
Agir com aprovação As ações de risco passam pelo portão de aprovação de falha fechada
Agir livremente Pré-aprova tudo o que não tenha sido resolvido como uma negação firme

O dial só alcança o harness integrado. O adaptador Claude Code executa as suas próprias ferramentas fora deste portão.

A tabela Onde as regras são aplicadas, no fundo da mesma página, é a versão na aplicação disto: por classe de efeito, indica se cada executor a interceta no portão de política, se a deixa à sandbox ou se não a consegue intercetar de todo.

  • O adaptador Claude Code só é controlado em parte das suas próprias chamadas de ferramentas. O Claude Code é lançado com --dangerously-skip-permissions, pelo que as suas chamadas de read, write e edit nunca passam pelo controlo. Os seus comandos de bash chegam a ele através de um hook que classifica a linha de comandos, e os seus pushes passam pelo gateway de push como os de qualquer agente. São também controlados a superfície de ferramentas MCP a que ele chama de volta e o comando de shell que o Control Center lança para o iniciar.
  • O verbo de saída de um modo (submit_plan, propose_orchestration) está fixado e nunca pode ser negado — de outro modo, um modo ficaria estruturalmente incapaz de produzir o seu único resultado.
  • Se a sandbox sustenta estas regras depende do anfitrião. Onde o cc_server encontra um backend, envolve a CLI do Claude Code e a ferramenta bash do harness, pelo que uma regra que não escreveu continua a ter um piso do SO por baixo. No Windows não existe nenhum e no Linux ou WSL2 sem bwrap e socat também não existe — aí, as guardrails mais a superfície de ferramentas do modo são toda a aplicação, e não uma segunda linha dela. Veja em que caso se encontra com Configurar políticas de sandbox.