Saltar para o conteúdo principal
A postura mais segura para um agente autônomo é default-deny: bloqueie cada ferramenta por padrão, depois permita explicitamente apenas o punhado que seu agente deve usar. Qualquer coisa nova que um agente pegue — uma skill da comunidade, um servidor MCP mal configurado, uma ferramenta que um jailbreak convenceu o modelo a usar — é negada porque você nunca optou por ela, não porque você se lembrou de bloqueá-la. Esta página é o padrão de allow-listing de ferramentas para agentes em api.orcarouter.ai: um veredito padrão deny mais uma ou mais regras allow chaveadas em um tool_name_glob. Para a linguagem de correspondência completa por trás dessas regras, veja Regras do Firewall.
As allow-lists são criadas no console sob Security → Firewall, ou via as rotas de gerenciamento /api/workspace/firewall/* (sua sessão / token de acesso — não uma chave de relay sk-orca-…). Apenas as chamadas /v1/* do seu agente usam a chave de relay. Criar ou editar uma política é uma ação Developer+.

​
1. Por que default-deny para agentes

Uma block-list (“nega shell.exec, nega db.delete, …”) só é tão completa quanto a última ameaça em que você pensou. Uma allow-list inverte o ônus da prova: o gateway nega tudo que a política não permite explicitamente, então uma ferramenta desconhecida fica fechada por construção.

Veredito padrão = deny

O piso da política. Sem nenhuma regra correspondendo, cada chamada de ferramenta é bloqueada.

Regras de allow optam de volta pelas ferramentas

Cada regra allow nomeia as ferramentas que você de fato usa — por nome exato ou por glob.
O motor percorre as regras de uma política em ordem de prioridade e a primeira correspondência vence; se nada corresponder ele cai para o default_verdict da política. Então uma allow-list é apenas: regras allow de alta prioridade para suas ferramentas reais, com um piso deny capturando todo o resto.

​
2. Um exemplo: allow-list das ferramentas de um agente de pesquisa

Digamos que seu agente só precise buscar na web e ler de uma base de conhecimento — ferramentas chamadas web.search e kb.read. Todo o resto (shell, escritas de arquivo, mutações de banco de dados, qualquer ferramenta que uma injeção de prompt possa conjurar) deve ser negado. Construa a política como deny padrão + duas regras allow:
1

Crie a política com um padrão deny

Security → Firewall → Policies → New policy. Nomeie-a, deixe Enabled ligado, e defina o veredito padrão como deny. Este é o piso fechado — veja Criar uma política.
2

Adicione uma regra de allow por família de ferramenta

No editor de regras adicione duas regras, ambas verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search é uma correspondência exata; kb.* é um glob de prefixo que permite kb.read, kb.search e qualquer ferramenta kb.* futura sem reeditar a política.
3

Vincule-a à chave do seu agente

Defina o firewall_policy_id da chave para esta política (ou torne-a o padrão do workspace). O corpo de requisição do seu agente fica inalterado.
Agora web.search e kb.read passam; uma chamada a shell.exec não corresponde a nenhuma regra de allow, atinge o piso deny e volta como HTTP 400 com o código firewall_blocked na superfície inbound — veja como é um block.
Crie regras de allow como nomes exatos ou prefixos estreitos (kb.*), não sufixos amplos. Um *.read frouxo permitiria kb.read e secrets.read — o oposto do que uma allow-list serve. Mantenha o glob tão apertado quanto a nomenclatura da ferramenta permitir.

​
3. O glob em uma tela

tool_name_glob é uma gramática pequena e case-sensitive — sem regex, tempo linear. As formas que importam para uma allow-list:
PadrãoPermite
web.searchExatamente essa ferramenta.
kb.*Prefixo — kb.read, kb.search (não kb sozinho).
*.searchSufixo — web.search, kb.search e search sozinho.
*.tools.*Infixo — byo.tools.fetch e similares.
Para a gramática completa (regras de infixo, casos de borda, globs de nome de skill), veja Sintaxe de glob e a referência de Regras do Firewall.
Um glob *.suffix também corresponde ao verbo sem namespace — *.search permite uma ferramenta literalmente chamada search, não apenas web.search. Provedores e servidores MCP sem namespace expõem ferramentas sob verbos sem namespace, então um sufixo na allow-list é mais amplo do que parece. Prefira nomes exatos ou prefixos quando quiser uma allow-list apertada.

​
4. Faça o rollout sem quebrar seu agente

Default-deny é a postura com maior probabilidade de bloquear uma ferramenta que você esqueceu que precisava. Faça-o em etapas:
Ligue o shadow mode. A política avalia e registra exatamente como faria ao vivo, mas rebaixa cada deny para audit com o motivo prefixado [shadow] would …. Rode tráfego real, depois leia o feed de events.
Ferramentas descobertas lista cada ferramenta que o workspace viu, marcada covered ou gap. Os eventos “would-deny” do shadow-mode mais os gaps dizem exatamente quais regras de allow você ainda precisa.
O sandbox de Test faz dry-run da 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 web.search permite e shell.exec nega, depois desligue o shadow.
Uma chamada inbound negada não custa tokens de modelo — ela é bloqueada antes de o modelo upstream rodar — e é marcada como skip-retry, então uma ferramenta bloqueada não vai queimar um orçamento de retry rebloqueando. Veja Vereditos.

​
5. Para onde ir a seguir

Bloquear ferramentas específicas

O inverso — mantenha um piso default-allow e negue ferramentas nomeadas.

Validar argumentos

Permita uma ferramenta, mas apenas com argumentos seguros (db.query mas não DROP TABLE).

Prioridade de regra

Como a primeira-correspondência-vence ordena suas regras de allow acima do piso de deny.

Vereditos

allow, audit, deny, sanitize, pending_approval, cap_cost.
Para a ameaça que este padrão endereça, veja agência excessiva e chamadas de ferramenta perigosas. Para por que default-deny é a linha de base de agentes, veja por que zero trust.