Saltar para o conteúdo principal
Quando um modelo responde, ele não retorna apenas texto — ele emite tool_calls: invocações concretas com argumentos reais escolhidos pelo modelo. A superfície response do agent firewall inspeciona exatamente essas, no momento em que deixam o modelo e antes de chegarem ao seu loop de agente. É a superfície onde você filtra o que o modelo de fato decidiu fazer, com os argumentos que ele de fato escolheu. Esta página cobre o caso de uso de filtragem na superfície response — quando recorrer a ela em vez de inbound, a única reviravolta de veredito que ela adiciona, e como ela se comporta num stream. Para o vocabulário de regras completo e a semântica de veredito, veja Schema de regra e Vereditos.

​
1. Filtre chamadas de response de ferramenta de llm, com argumentos em escopo

O stage inbound vê as ferramentas que você anuncia — apenas nomes, ainda sem argumentos em tempo de chamada. O stage response vê os tool_calls que o modelo emite, que carregam os argumentos que o modelo escolheu. Essa é a razão inteira para filtrar aqui: é a única superfície que vê a chamada real + argumentos para uma ferramenta executada pelo cliente (não-MCP), então cláusulas de argumento, sequências e regras de estado de run todas aterrissam em response. A distinção em uma linha:
StageVêUse-o para
inboundDefinições de ferramenta anunciadasTornar uma ferramenta invisível ao modelo
responsetool_calls emitidos + argumentosFiltrar a chamada que o modelo de fato fez
Então inbound responde quais ferramentas existem; response responde o que o modelo fez com uma. Recorra a response (ou deixe stage vazio para cobrir ambos) quando uma ferramenta legitimamente aparece em algumas requisições mas uma chamada particular dela é perigosa — ou quando você só controla o loop do agente, não o conjunto de ferramentas anunciado.
Uma regra sem stage roda em cada superfície, incluindo response. Fixe a response apenas quando uma regra deva só inspecionar chamadas emitidas — por exemplo uma cláusula de argumento que de qualquer forma não tem nada para corresponder na superfície inbound. Veja Stages.

​
2. Um exemplo concreto

Permita shell.exec em geral, mas remova-o da resposta do modelo no momento em que seu argumento command parece destrutivo. No console do seu workspace, abra uma política (ou crie uma) e adicione uma regra fixada à superfície response: 
{
  "label": "block destructive shell calls",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
O matcher de argumento vive em args_match_json — uma string JSON contendo {"clauses":[…]}, cada cláusula um triplo path / op / value (op é um entre eq, contains, regex, gt, lt). O formulário do console o constrói para você; a forma crua é mostrada aqui para que o nome do campo seja inequívoco. A ferramenta permanece anunciada — o modelo ainda pode propor shell.exec — mas quando a chamada emitida carrega um command destrutivo, o firewall remove esse tool_call da resposta antes que seu agente sequer o veja. Um shell.exec benigno (digamos, ls -la) passa intocado. Este é o padrão “permita a ferramenta, controle a chamada” para o qual a superfície response existe; a cláusula de argumento é o que o torna possível.
As regras avaliam em ordem de prioridade, a primeira correspondência vence. Coloque uma exceção de allow estreita num número de priority menor que um deny amplo para que a exceção rode primeiro. Veja Prioridade de regra.

​
3. O que um veredito faz na superfície response

A superfície response inspeciona cada tool_call emitido e reescreve a resposta no lugar. Chamadas mantidas são encaminhadas byte-a-byte; apenas uma chamada correspondida muda:
O tool_call correspondido é removido da resposta do modelo antes de chegar ao seu agente. Diferente de um deny inbound — que retorna HTTP 400 com o código firewall_blocked — um deny de superfície response não falha a requisição; o resto da resposta (outras chamadas de ferramenta, qualquer texto) flui com a chamada ofensora simplesmente ausente.
As substrings correspondidas nos argumentos da chamada são substituídas pelos argumentos redigidos do motor e a chamada limpa é encaminhada — útil quando a ferramenta está bem mas o modelo colocou um segredo ou valor de PII num argumento. O sanitize redige apenas os argumentos da chamada de ferramenta; ele nunca toca no conteúdo que uma ferramenta retorna. Se o motor não tem nada para substituir, a chamada é removida (fail-closed). Veja Sanitizar respostas.
A retenção human-in-the-loop abre na superfície inbound, não response. Uma regra pending_approval que primeiro corresponde numa chamada emitida é, portanto, removida (fail-closed) — mantê-la encaminharia uma chamada não revisada sem decisão humana. Crie retenções HITL para disparar inbound; veja Aprovações.
allow e audit ambos encaminham a chamada; audit é o default_verdict usual — registre tudo, bloqueie nada, até você estar pronto para aplicar.
cap_cost e pending_approval são conceitos inbound nesta superfície. cap_cost é inerte em response (o modelo já rodou), e pending_approval resolve para uma remoção em vez de uma retenção. Coloque limites de custo e retenções HITL na superfície inbound — veja Limite de custo e Aprovações.

​
4. Streaming: retido, depois filtrado

Numa resposta não-stream a resposta inteira é parseada e filtrada de uma vez. Num stream, os tool_calls de um modelo chegam como deltas por índice através de muitos frames SSE — e uma vez que um delta é encaminhado, seu agente já o tem e ele não pode ser retraído. Então o gateway retém os frames de chamada de ferramenta: eles nunca são encaminhados no meio do stream. Ao fim do stream o firewall monta cada chamada (nome + argumentos completos), avalia-a, e emite apenas as chamadas sobreviventes.
Os frames de conteúdo ainda fazem streaming normalmente — tokens de texto chegam ao seu cliente conforme chegam. Apenas os frames de tool_call são retidos para avaliação, então uma chamada negada ou sanitizada é filtrada antes que a chamada de ferramenta montada seja entregue. A semântica de veredito e regra é idêntica à superfície não-stream. Para os detalhes em nível de frame, veja Internals de streaming e Streaming de provedor.

​
5. Faça o rollout com segurança

A aba Test do console roda uma política contra uma chamada de ferramenta de amostra e retorna o veredito, a regra correspondente e o motivo — nada é despachado, nada é persistido. Confirme que seu glob e cláusula de argumento correspondem à chamada que você pretendia antes de vincular uma chave. Veja Testar regras.
Ligue o shadow mode e cada veredito de enforcement — incluindo um deny de superfície response — é rebaixado para audit, motivo prefixado [shadow] would …. Você mede exatamente o que a regra removeria contra o tráfego real antes que ela mude uma única resposta.
Cada avaliação escreve um evento de firewall com o veredito, a superfície, a ferramenta e a regra correspondente. Filtre o log de events pela superfície response para ver sua regra disparando nas chamadas emitidas que você esperava. Veja Analytics.

​
6. Vincule a política e quem pode configurá-la

Uma política não faz nada até que uma chave resolva para ela. Vincule no console definindo firewall_policy_id na chave, ou torne a política o padrão do workspace. A resolução: a política vinculada da chave (quando ela existe e está habilitada), senão o padrão do workspace — e uma política vinculada desabilitada cai de volta para o padrão do workspace. Veja Gerenciar políticas. Toda a configuração roda no console sob sua sessão (/api/workspace/firewall/*):
AçãoPapel
Ler políticas, presets, ferramentas descobertas, SimulateMember
Dry-run (Test), ler o log de events e agregados de runDeveloper+
Criar / editar / deletar regras e políticasDeveloper+

​
Relacionados

Validar argumentos

As cláusulas de argumento que tornam a filtragem de superfície response precisa.

Sanitizar respostas

Redija segredos dos argumentos de uma chamada em vez de removê-la.

Stages do firewall

Como response se compara a inbound, mcp e egress.

Bloquear ferramentas

A contraparte inbound: negue uma ferramenta antes que o modelo a receba.

Chamadas de ferramenta perigosas

A ameaça que a filtragem de response endereça.

Referência do Firewall

A referência completa de regra + correspondência.