Saltar para o conteúdo principal
Uma política de firewall decide uma coisa sobre cada chamada de ferramenta que seu agente faz: um veredito. Ou uma regra corresponde e produz um veredito, ou nenhuma regra corresponde e o veredito padrão da política assume. Esta página cobre ambos — o que cada veredito de firewall faz, como o cap_cost resolve, e por que audit é o padrão a partir do qual você começa. Para onde os vereditos vivem na gramática de regras veja Regras do Firewall; para escolher um veredito padrão ao criar uma política veja Criar e vincular.

​
1. Os seis vereditos de regra

Uma regra produz exatamente um entre seis vereditos. Crie-os no editor de regras do console; o motor percorre as regras em ordem de prioridade e a primeira correspondência vence.
A chamada prossegue intocada. Ela ainda aterrissa no feed de events como um allow, então você mantém uma trilha de auditoria sem bloquear nada. Use-o como uma permissão explícita em uma política default-deny.
Resultado de tráfego idêntico ao allow, mas a chamada é sinalizada como algo que você queria observar. Este é também o valor em que o veredito padrão aterrissa de fábrica — observe tudo, bloqueie nada, até você estar pronto para aplicar.
A chamada nunca chega à ferramenta. Na superfície inbound o relay retorna HTTP 400 com o código de erro firewall_blocked, nomeando a ferramenta e o motivo; na superfície mcp ela volta como um erro de ferramenta para que o modelo possa reagir. Veja como é um block.
Redige substrings correspondentes dos argumentos da chamada de ferramenta (um segredo ou PII que o agente colocou em um campo command ou body) e encaminha a chamada limpa. Ele redige apenas argumentos — nunca o conteúdo que uma ferramenta retorna. Na superfície inbound ainda não há argumentos em tempo de chamada, então o sanitize escala para um deny. Veja sanitizar respostas.
Transforma a chamada em uma revisão fora de banda. O relay retorna HTTP 400 com o código firewall_approval_pending e um id de aprovação; a chamada não chega à ferramenta. Um revisor a resolve no console ou via callback de webhook, e o agente reenvia com um header de aprovação de uso único. Veja aprovações.
Um disjuntor de custo — criado como uma regra mas resolvido para allow ou deny no momento da avaliação. Veja §3 e limite de custo.
O shadow mode achata o enforcement. No shadow mode, todo veredito de enforcement (deny, sanitize, pending_approval e um cap_cost que resolveu para deny) é rebaixado para audit e o motivo recebe o prefixo [shadow] would …. Faça o rollout de uma política de enforcement desta forma e observe o feed de events antes de ativá-la.

​
2. O veredito padrão

O veredito padrão (default_verdict na política) é o que a política faz quando nenhuma regra corresponde a uma chamada de ferramenta. É o piso da sua postura, e ao contrário de um veredito de regra ele aceita apenas três valores:
default_verdictQuando nenhuma regra corresponde…
audit (padrão)Permite a chamada, mas a registra. O lugar seguro para começar.
allowPermite e registra, sem registro de revisão.
denyBloqueia qualquer coisa que uma regra não permita explicitamente — uma postura default-deny.
Uma nova política tem padrão audit: ela observa cada chamada de ferramenta e bloqueia nada até você adicionar regras de enforcement. Os três vereditos exclusivos de regra — sanitize, pending_approval e cap_cost — não podem ser um padrão; um veredito padrão é um fallback abrangente, e esses vereditos só fazem sentido com escopo para uma correspondência específica.
deny como veredito padrão é default-deny: qualquer chamada de ferramenta que suas regras não permitam (allow) explicitamente é bloqueada. Poderoso para um agente travado, mas vai parar chamadas que você esqueceu de adicionar à allowlist. Combine-o com regras de allow explícitas (allow-listing de ferramentas) e faça o rollout sob shadow mode primeiro.

​
3. cap_cost resolve para allow ou deny

cap_cost é o único veredito que não é o que aparece nos seus events. Você cria uma regra com um teto cap_cost_cents, mas no momento da avaliação o motor o resolve para um allow ou deny concreto antes de o evento ser registrado — então o feed de events nunca carrega um veredito cap_cost literal, apenas o allow/deny que o agente de fato viu. O teto é por run de agente: o motor compara o gasto acumulado da run contra seu limite.
  • Abaixo do limite → resolve para allow. (Internamente isso é tratado como não correspondente, então a avaliação continua para a próxima regra em vez de deixar o cap_cost vencer na primeira correspondência como uma concessão.)
  • Acima do limite → resolve para deny, com um motivo nomeando o total da run versus o limite. Este é o resultado terminal de disjuntor.
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost só dispara nas superfícies pré-dispatch (inbound, mcp) — os pontos onde bloquear uma chamada ainda previne o gasto. Nas superfícies pós-dispatch response e egress ele é inerte (não há nada mais a parar), então o motor o pula ali.

​
4. Como um veredito é escolhido

Para qualquer chamada de ferramenta, a resolução é a mesma independentemente de qual veredito vence:
O gateway escolhe a política vinculada à chave chamadora (firewall_policy_id), ou o padrão do workspace — veja resolução.
As regras rodam em ordem priority ASC. A primeira regra cuja superfície, glob de ferramenta, cláusulas de argumento opcionais e escopo de egress opcional todos correspondem produz o veredito.
Se nenhuma regra corresponder, o default_verdict da política se aplica — audit a menos que você o tenha mudado.
Se a chamada é de propriedade de uma skill governada, uma skill em modo block força um deny e uma skill em modo quarantine escala qualquer coisa aquém de deny para pending_approval.

​
5. Comportamento de custo e retry de um deny

Um veredito de firewall na superfície inbound dispara antes da chamada ao modelo upstream, então um deny ali não custa tokens de modelo. O erro é marcado como skip-retry — reexecutar a mesma chamada bloqueada apenas bloquearia de novo, então o gateway diz ao cliente para não fazer retry. Isso é distinto de um block de guardrail, que filtra o texto de prompt/response (PII, segredos) em vez de ações de ferramenta, e retorna seu próprio erro guardrail_blocked. Uma requisição pode passar por ambos os planos.
Cada veredito deixa um rastro. Cada avaliação — allow, audit, deny, o cap_cost resolvido, a aprovação retida — é registrada como um evento de firewall, filtrável por veredito, superfície, ferramenta e run. O feed de events é como você confirma que uma política está produzindo os vereditos que você espera. Veja log de events e analytics.

​
Para onde ir a seguir

Criar e vincular uma política

Escolha um veredito padrão e vincule uma política a uma chave.

Limite de custo

Crie um teto de gasto e como ele resolve por run.

Shadow mode

Rebaixe todo veredito de enforcement para audit enquanto você mede o impacto.

Referência de regras

A linguagem de correspondência completa por trás de um veredito.
Para as ameaças que esses vereditos pretendem deter, veja chamadas de ferramenta perigosas e agência excessiva.