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.
Definir uma decisão para uma classe de ações
Secção intitulada “Definir uma decisão para uma classe de ações”- Aceda a Definições → Espaço de trabalho → Permissões dos agentes
- 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)
- Na linha da classe de ações, escolha Permitir, Perguntar primeiro ou Negar
- 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.
Compreender como uma decisão é resolvida
Secção intitulada “Compreender como uma decisão é resolvida”A resolução dá primeiro prioridade à especificidade e depois à restritividade:
- 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í
- Se nenhuma regra corresponder, aplica-se a predefinição do modo — um modo só de leitura (plan, review, orchestrate) recusa onze das treze classes
- 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.
Classes de ações e predefinições
Secção intitulada “Classes de ações e predefinições”| 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.
Testar uma regra com a sonda «E se?»
Secção intitulada “Testar uma regra com a sonda «E se?»”Antes de alterar uma regra, verifique como a política atual já a resolve.
- Na mesma página, desça 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 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.
Definir o dial de autonomia de um espaço
Secção intitulada “Definir o dial de autonomia de um espaço”O dial é por agente e por espaço e compõe-se com as regras em vez de as substituir.
- Abra o espaço
- Abra Gerir participantes a partir do cabeçalho do espaço
- 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.
Saber onde as guardrails não chegam
Secção intitulada “Saber onde as guardrails não chegam”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_serverencontra um backend, envolve a CLI do Claude Code e a ferramentabashdo 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 sembwrapesocattambé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.