A linha de base de Agentes Seguros é o controle de autonomia — não há
objeto separado de “linha de base”. Aplicar um nível de autonomia atomicamente
escreve uma política de firewall e um guardrail (nomeados para o nível) e os
torna a postura ativa do seu workspace, em uma transação. Você pode abrir e
editá-los depois. O desfazer em um clique restaura o estado anterior a partir
de um snapshot de auditoria.
1. O que o controle de autonomia faz
Três níveis, cada um cobrindo as mesmas duas camadas:| Nível | Postura do Firewall | Guardrails | Observe mode |
|---|---|---|---|
tight | Default-deny; shell destrutivo e egress SSRF negados | PII Shield + Secrets Blocker aplicados | Desativado |
balanced | Audit por padrão; shell destrutivo negado | PII Shield em modo somente auditoria (sinaliza PII) | Desativado |
permissive | Sem política de enforcement | Sem guardrails | Ativado — cada chamada de ferramenta é registrada como um gap de cobertura |
balanced é a postura inicial recomendada. Ela audita tudo que seus
agentes fazem e sinaliza PII, enquanto ainda nega as ações mais destrutivas
(shell destrutivo) — para que você veja o comportamento real dos seus agentes
antes de decidir o que mais restringir. Para um passo que não bloqueia
nada, comece em permissive.
tight é o alvo correto uma vez que você entende o comportamento normal
do seu agente. Ele aplica uma postura default-deny pronta para uso: shell
destrutivo negado, egress SSRF negado e ambos os guardrails PII Shield e
Secrets Blocker ativos (inspecionando suas requisições por PII e segredos).
permissive desliga todo o enforcement mas mantém o observe mode ativo,
para que cada chamada de ferramenta ainda seja registrada. Use-o para auditar
um agente completamente novo sem risco de bloqueios acidentais — depois mude
para balanced ou tight uma vez que você sabe o que ele faz.
2. Como aplicar um nível
Pré-visualize a mudança (opcional mas recomendado)
Simule o nível antes de aplicá-lo. A visão Simulate no console
(em Firewall → Posture) ou a API mostra exatamente quais regras e guardrails
estariam ativos — nada muda.Papel: Member (somente leitura, sem mudança).
Escolha um nível no console
Vá em Firewall → Posture no console. Selecione
balanced, tight ou
permissive no controle de nível de autonomia e confirme. A mudança entra
em vigor na próxima chamada de ferramenta — sem redeploy.Papel: Developer+ necessário para aplicar.Ou aplique via API
audit_id — guarde-o. Você precisará dele para
desfazer.Papel: Developer+.Observe eventos e correspondências
Após aplicar, vá em Firewall → Events / Runs para ver vereditos de
chamadas de ferramenta e Guardrails → Matches para ver hits de política
de conteúdo. Ambos os feeds atualizam em tempo real. Se algo disparar que
você não esperava, revise antes de restringir mais.
Desfaça se necessário
Qualquer mudança de autonomia pode ser desfeita com uma chamada. O desfazer
restaura o estado anterior exato — políticas, regras, guardrails,
configurações — do snapshot de auditoria, não uma redefinição genérica.Papel: Developer+.O
audit_id é retornado quando você aplica o nível (Passo 3) e também
está visível em Firewall → Audit.3. O caminho recomendado
Comece combalanced → simule tight → observe → restrinja.
- Aplique
balanced— você obtém uma trilha de auditoria completa; apenas shell destrutivo é negado, todo o resto é auditado. Execute seus agentes normalmente por um ou dois dias. - Simule
tight— executeGET /api/workspace/firewall/simulate?level=tighte compare o que seria negado com o que você viu no feed de Events. Se chamadas de shell destrutivo ou requisições outbound no estilo SSRF fazem parte do seu tráfego normal, corrija isso no agente primeiro. - Observe Events e Matches — Firewall → Events mostra cada veredito de chamada de ferramenta; Guardrails → Matches mostra hits de política de conteúdo. Ambos são filtráveis por veredito, ferramenta, run e sessão.
- Aplique
tight— uma vez que a saída de simulação não contém surpresas, apliquetight. O desfazer está a uma chamada de distância se algo quebrar em produção. - Ajuste com regras — use as Regras do Firewall para criar exceções ou adicionar controles que os níveis de preset não cobrem. O nível de autonomia é o seu piso; regras personalizadas adicionam precisão.
4. Requisitos de papel
| Ação | Papel mínimo |
|---|---|
Simular um nível (GET .../simulate) | Member |
| Ler a trilha de auditoria | Member |
| Ver correspondências de guardrail | Member |
| Ver Events e Runs do firewall | Developer+ |
| Aplicar um nível de autonomia | Developer+ |
| Desfazer uma mudança de autonomia | Developer+ |
5. O que isso não é
- Não é uma caixa preta. Aplicar um nível de autonomia escreve uma política de firewall real e um guardrail (nomeados para o nível) e os torna a postura ativa do seu workspace. Você pode abrir, inspecionar e editá-los depois — é um ponto de partida rápido, não um preset bloqueado.
- Reversível, com limites. O desfazer em um clique restaura o estado anterior de Firewall e Guardrails de um snapshot de auditoria. Para um workspace muito grande cujo snapshot excede o limite de tamanho do log de auditoria, o apply ainda tem sucesso mas o desfazer não está disponível para essa mudança — você re-aplica o nível que quer. Raro, mas vale saber.
- Não é um substituto para chaves com escopo. O controle de autonomia define a postura padrão do workspace. Chaves de API individuais ainda podem ser conectadas a políticas específicas para controle mais fino. Veja Guardrails vs. Firewall para como as camadas se compõem.
O controle de autonomia é projetado para os primeiros 30 minutos — fique protegido rapidamente, entenda o comportamento real dos seus agentes e depois restrinja a partir de uma posição de visibilidade em vez de suposições.
Quickstart
Configuração completa de zero trust em 5 minutos, incluindo chaves com
escopo e guardrails.
Firewall
Detalhes em nível de regra — vereditos, superfícies, predicados de
argumento e aprovação HITL.
