Saltar para o conteúdo principal
A resposta curta: os Guardrails governam texto; o Firewall governa ações. Eles são complementares — uma única requisição flui por ambos — e a maneira mais rápida de configurá-los juntos é um nível de autonomia. O restante desta página é para os casos em que você precisa saber qual camada é responsável por uma ameaça específica.
Papel necessário. Qualquer membro do workspace pode ler políticas e o feed de Matches de guardrail; o feed de Events do firewall exige o papel de Developer. Criar ou editar guardrails ou políticas de firewall também exige Developer ou superior.

​
1. A distinção em uma linha

CamadaGovernaVê
GuardrailsTexto — o que o modelo lê e escreveConteúdo do prompt, conteúdo da resposta
Agent FirewallAções — o que o agente fazChamadas de ferramenta, dispatches de MCP, destinos de rede outbound
Os guardrails disparam antes da chamada upstream (no prompt) e depois dela (na resposta). O Firewall dispara em cada chamada de ferramenta que o modelo emite ou que o agente emite — independentemente do modelo ou provedor que serviu o turno.

​
2. Comparação lado a lado

DimensãoGuardrailsAgent Firewall
GovernaTexto do prompt e texto da resposta do modeloChamadas de ferramenta, dispatches de MCP, destinos de egress, custo do agente
VêA mensagem do usuário, o system prompt e a resposta do modeloNome da ferramenta, argumentos da chamada, as tool_calls que o modelo emite, host/IP outbound
Conecta viaguardrail_id na chave de APIfirewall_policy_id na chave de API
Tipos de regrakeyword, regex, pii, max_chars, external, llm_judge, groundingGlob de nome de ferramenta + cláusulas de argumento + escopo de egress + propriedade de skill
Exemplos de ameaçasPII em prompts, segredos de API em respostas, jailbreaks, saída fora de tópico, contexto excessivoChamada de ferramenta perigosa, SSRF, exfiltração de dados, loop de custo descontrolado de agente, servidor MCP não aprovado
Vereditos / açõesblock (HTTP 400 guardrail_blocked), mask, flagallow, audit, deny (HTTP 400 firewall_blocked), sanitize, pending_approval, cap_cost
Quando disparaEstágio de entrada: antes da chamada ao modelo; estágio de saída: após o modelo responderEm cada chamada de ferramenta que o modelo emite ou o agente emite
Shadow / observe modeNão — guardrails disparam ou não disparamSim — shadow mode rebaixa vereditos de enforcement para audit para rollout seguro

​
3. Ameaça → qual camada

Use esta tabela para direcionar um novo requisito de segurança para o controle correto:
AmeaçaUse
PII em uma mensagem do usuárioGuardrails — regra pii de entrada (mask / block)
Segredo na resposta do modeloGuardrails — regra de segredos na saída
Chamada de ferramenta perigosa (shell.exec rm -rf /)Firewall — deny no glob de ferramenta + cláusula de argumento
SSRF / exfiltração de dados via URL outboundFirewall — lista de allow/deny de egress
Injeção de prompt de conteúdo não confiávelAmbos — guardrail de entrada + lista de permissão do firewall
Segredo em um argumento de ferramentaFirewall sanitize + regra de segredos dos Guardrails
Jailbreak / bypass de políticaGuardrails — llm_judge / keyword / regex
Prompt excessivo ou custo de tokensGuardrails — regra max_chars
Gasto descontrolado do agente (loop de custo)Firewall — veredito cap_cost
Servidor MCP não aprovadoFirewall — deny na superfície MCP / pending_approval
Dados sensíveis de um resultado de ferramentaGuardrails — regra de saída na resposta
O “porquê” detalhado para cada combinação está nas páginas de aprofundamento em Ameaças.

​
4. Use ambos — níveis de autonomia os configuram juntos

Guardrails e o Firewall são projetados para se compor, não competir. Uma única requisição passa por ambos os planos:
  1. Guardrail de entrada roda — o texto do prompt é inspecionado e opcionalmente mascarado.
  2. Chamada ao modelo — o prompt (possivelmente sanitizado) alcança o modelo upstream.
  3. Firewall — cada chamada de ferramenta que o modelo emite é avaliada.
  4. Guardrail de saída roda — o texto da resposta do modelo é inspecionado.
A maneira mais rápida de configurar ambos de uma vez é um nível de autonomia — uma única configuração que atomicamente escreve uma política de Firewall e uma política de Guardrails para todo o workspace, com desfazer em um clique:
Nível de autonomiaPostura do FirewallPostura dos Guardrails
tightDefault-deny; bloqueia shell destrutivo + egress SSRFPII Shield + Secrets Blocker ativos
balancedAudit padrão; nega shell destrutivoPII Shield somente auditoria (sinaliza PII)
permissiveSem regras de enforcement; observe mode ativadoSem enforcement
Aplique um nível de autonomia no console do Firewall (POST /api/workspace/firewall/autonomy, Developer+), depois ajuste cada plano independentemente a partir daí.

​
5. Resumo

Os Guardrails são responsáveis pelo texto; o Firewall pelas ações — execute ambos, deixe o nível de autonomia conectá-los e restrinja cada plano independentemente assim que você puder ver o tráfego real dos seus agentes.

Guardrails

Tipos de regra, detecção de PII, LLM judge, eval harness e referência de API.

Agent Firewall

Vereditos, superfícies, níveis de autonomia, aprovação HITL e referência de API.