Saltar para o conteúdo principal
Você escreveu uma regra de firewall — um deny em shell.exec, uma allow-list de egress, uma cláusula de argumento que só dispara em rm -rf — e agora quer saber que ela faz exatamente o que você pensa antes de mudar uma única chamada de ferramenta de produção. O firewall lhe dá três maneiras não-destrutivas de testar regras de firewall, cada uma respondendo a uma pergunta diferente:

Dry-run de uma chamada

O sandbox Test alimenta uma chamada de ferramenta sintética através do motor real e retorna o veredito — nada despachado, nada registrado. Developer+.

Replay de uma postura

Simulate reproduz um nível de autonomia contra seu tráfego recente e conta quantas chamadas ele bloquearia. Legível por Member.

Rode contra tráfego ao vivo

Shadow mode avalia uma política inteira em chamadas reais mas rebaixa cada veredito de enforcement para audit. Raio de explosão zero.
Todos os três configuram através do console (ou das rotas de gerenciamento /api/workspace/firewall/*, que autenticam com sua sessão / token de acesso — não uma chave de relay sk-orca-…). As chamadas de relay /v1/* do seu agente nunca mudam enquanto você testa.

​
1. Teste regras de firewall com o sandbox Test de dry-run

O sandbox Test é o loop mais apertado: entregue a ele uma única chamada de ferramenta sintética e ele roda o motor de avaliação real — resolução de política completa, regras percorridas em ordem de prioridade, primeira-correspondência-vence — depois retorna o veredito, a regra que o produziu e o motivo legível por humanos. A chamada é um dry run: nada é despachado a nenhuma ferramenta, e nada é escrito no feed de events ou no inventário de Discovered-tools. Ela responde a uma pergunta precisamente: dado este nome de ferramenta exato e estes argumentos, o que minha política decide — e qual regra decide?
O sandbox Test é Developer+. Ele pode pré-visualizar contra uma política rascunho não salva por id e a resposta revela o nome de política correspondida e o label da regra, então fica mais perto de um preview de superfície de escrita que de uma leitura simples — diferente do Simulate e das outras visões de leitura, que são abertas a cada membro.

​
Um dry run concreto

Digamos que você adicionou uma regra que deve negar shell.exec apenas quando o comando contém rm -rf. Você quer confirmar duas coisas numa sentada: o comando perigoso é negado, e um inocente ainda passa.
1

Teste a chamada perigosa

Em Security → Firewall, abra a aba Test, escolha a superfície response, insira o nome de ferramenta shell.exec e os argumentos {"command": "rm -rf /data"}, e rode. A resposta nomeia o veredito e a regra correspondida:
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

Teste a chamada inocente

Rode-a de novo com {"command": "ls -la"}. A cláusula de argumento não corresponde mais, então a regra cai para o padrão da política — você deve ver allow ou audit e um rule_label vazio. Se rm -rf nega e ls -la não, sua cláusula de argumento tem escopo correto.
3

Pré-visualize um rascunho antes de vinculá-lo

Passe um policy_id para avaliar contra uma política rascunho específica em vez daquela para a qual seu tráfego resolve atualmente — para que você possa provar que uma nova política está certa antes de vincular uma chave a ela ou promovê-la a padrão do workspace.
Leia gap na resposta. gap: true significa que uma política resolveu mas nenhuma regra dentro dela correspondeu à chamada (e o workspace está em observe mode) — a ferramenta escapou por cada regra e caiu para o padrão. Esse é um buraco de cobertura a fechar antes de você lançar, não um veredito em que confiar.
O sandbox Test usa as mesmas superfícies que a avaliação ao vivo — inbound, response, mcp, egress (padrão inbound) — então teste cada regra na superfície a que ela está fixada. Em inbound não há argumentos em tempo de chamada, então uma regra sanitize escala para um block ali exatamente como faria em produção; veja stages para por que a superfície importa.

​
2. Simule um nível de autonomia antes de aplicá-lo

O sandbox Test verifica uma chamada. Simulate responde à pergunta de nível de postura: se eu mudasse este workspace inteiro para um nível de autonomia mais estrito, quanto do meu tráfego recente ele bloquearia? O Simulate reproduz as regras de deny de um nível candidato contra seus eventos de firewall recentes e retorna o impacto potencial — apenas nomes de ferramenta e contagens, nunca argumentos. Ele é somente-leitura e legível por Member, então qualquer um na equipe pode pré-visualizar o raio de explosão do tight antes que um Developer se comprometa com ele.
  • tight — default-deny, nega shell destrutivo, nega ferramentas com formato de fetch (o vetor de SSRF), PII Shield + Secrets Blocker aplicados. O Simulate mostra quanto do seu tráfego real este piso capturaria.
  • balanced — audit padrão, nega shell destrutivo, PII Shield em apenas-audit (sinaliza PII). A postura inicial recomendada.
  • permissive — apenas observe; nada aplicado.
O Simulate não muda nada — é um e-se sobre eventos passados. Aplicar um nível de autonomia (uma escrita Developer+) materializa linhas reais e editáveis de política e guardrail autonomy_*, com desfazer em um clique a partir do snapshot de auditoria. Pré-visualize com Simulate, depois aplique quando a contagem parecer certa.

​
3. Shadow mode: teste contra tráfego ao vivo sem raio de explosão

O sandbox Test e o Simulate são previews offline. O Shadow mode é o ao vivo: uma flag por política que avalia a política em tráfego de agente real, percorre cada regra, escolhe um veredito — depois rebaixa cada veredito de enforcement (deny, sanitize, pending_approval) para audit e prefixa o motivo com [shadow] would …. A chamada sempre passa; nada é bloqueado, redigido ou retido. Isso faz o feed de events se ler como uma run de produção com o enforcement desligado. Filtre por [shadow] e você tem uma lista completa de cada chamada que a política está prestes a começar a bloquear — antes que ela bloqueie uma.
Método de testeRoda contraPergunta que responde
Sandbox TestUma chamada sintética”Qual veredito esta chamada exata recebe, e qual regra decide?”
SimulateEventos recentes”Quantas chamadas um nível de autonomia mais estrito bloquearia?”
Shadow modeTráfego ao vivo”O que esta política bloquearia através do tráfego de produção real?”
O shadow mode é o mais profundo dos três — cobertura ao vivo completa com raio de explosão zero. Ele tem sua própria página: Faça o rollout de uma política de firewall com shadow mode percorre o toggle, os motivos [shadow] would … e a virada para aplicar.

​
4. Uma ordem prática de teste

As três ferramentas se compõem em um caminho de rollout seguro — verificação mais barata primeiro, cobertura mais ampla por último:
1

Dry-run das regras que você acabou de escrever

Use Test para confirmar que cada nova regra dispara nas chamadas que deve e passa as que não deve — incluindo os casos negativos. Rápido, Developer+, nada persistido.
2

Avalie a postura (opcional)

Se você está recorrendo a um nível de autonomia em vez de regras escritas à mão, Simule o nível e leia a contagem de potencialmente-bloqueadas contra o tráfego real antes de aplicá-lo.
3

Shadow contra tráfego ao vivo

Ligue o shadow mode e deixe uma janela representativa de chamadas reais fluir. Leia os eventos [shadow] would …; aperte qualquer regra que revele um falso positivo — ainda em shadow, raio de explosão zero.
4

Aplique

Quando o feed dispara no que você espera e em nada que você não espera, desligue o shadow. A próxima chamada aplica de verdade.
O teste pré-visualiza a política, não as skills governadas. Uma skill em modo block ou quarantine ainda aplica mesmo sob uma política em shadow — a disposição de revisão da skill vence. Colocar uma política em shadow nunca foi um pedido para tirar uma skill da quarentena.

​
5. Referência da API

Estas rotas de gerenciamento usam seu token de sessão / acesso e têm escopo de workspace:
Método & pathPapelPropósito
POST /api/workspace/firewall/testDeveloper+Dry-run de uma chamada de ferramenta sintética contra a política resolvida (ou um policy_id rascunho). Retorna veredito, policy_name, rule_label, reason, gap, shadow_mode. Nada despachado ou registrado.
GET /api/workspace/firewall/simulate?level=MemberReproduz um nível de autonomia contra eventos recentes; retorna contagens de potencialmente-bloqueadas.
GET /api/workspace/firewall/policies/:idMemberLê a flag shadow_mode atual de uma política.
PUT /api/workspace/firewall/policiesDeveloper+Alterna shadow_mode na política.
O corpo do Test recebe surface (padrão inbound), um tool_name obrigatório, um args_json opcional, e um policy_id opcional para sobrescrever a resolução.

​
Para onde ir a seguir

Shadow mode

O rollout de tráfego-ao-vivo: [shadow] would …, o filtro de events, e a virada para aplicar.

Validar argumentos

Dê escopo a uma regra por quais argumentos — as cláusulas que o sandbox Test deixa você verificar contra rm -rf vs ls -la.

Vereditos

O que allow / audit / deny / sanitize / pending_approval / cap_cost cada um faz quando um teste deixa de ser um teste.

Log de events

Onde os vereditos em shadow aterrissam — filtre, aprofunde em runs e regras correspondidas.
Para a gramática de correspondência de regras que esses testes exercitam, veja a referência completa de regras do firewall; para onde o teste se encaixa no modelo mais amplo, veja modos de enforcement.