🚦 Política de autonomia

Até aqui você conectou ferramentas e montou um time. Falta a pergunta que decide se dá para dormir tranquilo: o que o agente pode fazer sem você?

A runtime/POLITICA.md responde com cinco níveis, de N0 a N4. A primeira linha do arquivo resume a ideia: quanto maior o impacto da ação, mais o humano participa.

O que olhar na tabela: é a cópia exata da seção "Níveis de autonomia" da POLITICA.md. A diferença entre N1 e N2 é quem aperta o botão: no N1 é você, no N2 é o agente, com o seu sim.

Como ler o desenho: cada degrau dá mais liberdade ao agente. O degrau âmbar (N2) é onde o kit coloca tudo o que tem impacto. Os degraus azuis são para ações que, se derem errado, você desfaz sem dor.

Os níveis sozinhos não dizem nada. Eles ganham sentido quando você liga cada tipo de ação a um nível máximo. É a segunda tabela da POLITICA.md, a do teto.

As duas últimas colunas mostram como cada teto vira configuração: no Claude Code e no Codex. Você verá as duas nos tópicos 4 e 5.

O que olhar na tabela: o teto cai conforme o estrago possível sobe. Ler não quebra nada (N4). Gastar e apagar não têm volta (N1): o agente prepara e quem faz é você.

Leia runtime/POLITICA.md e responda em uma linha qual é o teto de 'Enviar'.

respondeu "N2" lendo a POLITICA

Quando o Claude Code pede licença, ele oferece "sim", "não" e uma opção para não perguntar mais. Na décima pergunta seguida, a tentação é clicar na terceira. Em um dos vídeos de mods, havia até um ajudante que aprovava as permissões sozinho.

A POLITICA.md fecha essa porta com uma frase: uma permissão "sempre permitir" nunca passa do teto da ação. Você pode liberar leitura para sempre. Não pode liberar pagamento para sempre.

No Claude Code, a política vira o arquivo .claude/settings.json, que já vem no kit. O Claude Code lê esse arquivo sozinho ao abrir na pasta.

A parte que importa aqui é a lista deny: comandos que o agente não roda, peça quem pedir. São os bloqueios básicos que a POLITICA.md cita para "apagar" e para o push forçado.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)"
    ]
  },
  "enabledMcpjsonServers": [
    "ponte-modelo"
  ],
  "hooks": { ... }
}

Como ler o desenho: os dois pedidos passam pela mesma caixa âmbar. O que não está na lista segue pela seta azul. O que está na lista para na seta vermelha, sem pergunta e sem depender de você estar olhando.

O Codex não lê o .claude/settings.json. Nele, a política entra pelo sandbox, escolhido com a opção -s a cada chamada. A tabela do teto já diz qual usar.

A ponte runtime/pontes/codex-exec.sh, que você usou no módulo 2.1, só aceita dois valores. Qualquer outro é recusado antes de o Codex ser chamado.

O que olhar na tabela: enviar, gastar e apagar não têm sandbox na ponte. Para essas linhas a POLITICA diz "sem auto-aprovação" ou "não executar": o Codex prepara, e a ação fica com você.

runtime/pontes/codex-exec.sh "x" . danger-full-access

sandbox recusado pela POLITICA, saída 2

case "$sandbox" in
  read-only|workspace-write) ;;
  *) echo "sandbox recusado pela POLITICA: $sandbox" >&2; exit 2 ;;
esac

Além dos níveis e do teto, a POLITICA.md tem uma seção curta chamada Integração. São três regras sobre como as ferramentas se ligam umas às outras.

Elas protegem o que nenhum deny pega: a conta, a senha e a estabilidade do seu sistema.

Como ler o desenho: pela ponte âmbar passa só texto: o pedido vai, a resposta volta. Os logins ficam cada um na sua caixa. O tracejado vermelho é o caminho que a regra 2 proíbe.