Vai al contenuto principale
La postura più sicura per un agent autonomo è default-deny: blocca ogni tool per default, poi consenti esplicitamente solo la manciata che il tuo agent deve usare. Qualsiasi cosa nuova che un agent raccoglie — una skill della community, un MCP server mal configurato, un tool che un jailbreak ha convinto il modello a usare — viene negata perché non l’hai mai riammessa, non perché ti sei ricordato di bloccarla. Questa pagina è il pattern di allow-listing dei tool per agent su api.orcarouter.ai: un verdetto di default deny più una o più regole allow basate su un tool_name_glob. Per il linguaggio di matching completo dietro quelle regole, vedi Regole del Firewall.
Le allow-list si scrivono nella console sotto Security → Firewall, o tramite le rotte di gestione /api/workspace/firewall/* (la tua sessione / token di accesso — non una chiave di relay sk-orca-…). Solo le chiamate /v1/* del tuo agent usano la chiave di relay. Creare o modificare una policy è un’azione Developer+.

​
1. Perché default-deny per gli agent

Una block-list (“nega shell.exec, nega db.delete, …”) è completa solo quanto l’ultima minaccia a cui hai pensato. Una allow-list inverte l’onere della prova: il gateway nega tutto ciò che la policy non permette esplicitamente, quindi un tool sconosciuto è chiuso per costruzione.

Verdetto di default = deny

Il pavimento della policy. Senza alcuna regola corrispondente, ogni chiamata a tool viene bloccata.

Le regole di allow riammettono i tool

Ogni regola allow nomina i tool che usi davvero — per nome esatto o per glob.
Il motore percorre le regole di una policy in ordine di priorità e vince il primo match; se nulla corrisponde ricade sul default_verdict della policy. Quindi una allow-list è semplicemente: regole allow ad alta priorità per i tuoi tool reali, con un pavimento deny che cattura tutto il resto.

​
2. Un esempio: allow-list dei tool di un agent di ricerca

Diciamo che il tuo agent deve solo cercare sul web e leggere da una knowledge base — tool chiamati web.search e kb.read. Tutto il resto (shell, scritture di file, mutazioni del database, qualsiasi tool che una prompt-injection potrebbe evocare) deve essere negato. Costruisci la policy come default deny + due regole allow:
1

Crea la policy con un default deny

Security → Firewall → Policies → New policy. Nominala, lascia Enabled attivo, e imposta il verdetto di default su deny. Questo è il pavimento chiuso — vedi Crea una policy.
2

Aggiungi una regola di allow per famiglia di tool

Nell’editor delle regole aggiungi due regole, entrambe verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search è un match esatto; kb.* è un glob di prefisso che consente kb.read, kb.search e qualsiasi futuro tool kb.* senza ri-modificare la policy.
3

Collegala alla chiave del tuo agent

Imposta il firewall_policy_id della chiave su questa policy (o rendila il default del workspace). Il corpo della richiesta del tuo agent è invariato.
Ora web.search e kb.read passano; una chiamata a shell.exec non corrisponde ad alcuna regola di allow, colpisce il pavimento deny, e torna come HTTP 400 con codice firewall_blocked sulla superficie inbound — vedi com’è fatto un block.
Scrivi le regole di allow come nomi esatti o prefissi stretti (kb.*), non suffissi ampi. Un *.read lasco consentirebbe kb.read e secrets.read — l’opposto di ciò a cui serve una allow-list. Mantieni il glob stretto quanto la denominazione dei tool ti permette.

​
3. Il glob in una schermata

tool_name_glob è una grammatica piccola e case-sensitive — niente regex, tempo lineare. Le forme che contano per una allow-list:
PatternConsente
web.searchEsattamente quel tool.
kb.*Prefisso — kb.read, kb.search (non il nudo kb).
*.searchSuffisso — web.search, kb.search e il nudo search.
*.tools.*Infisso — byo.tools.fetch e simili.
Per la grammatica completa (regole infisse, casi limite, glob su nome di skill), vedi Sintassi glob e il riferimento delle Regole del Firewall.
Un glob *.suffix corrisponde anche al verbo nudo, senza namespace — *.search consente un tool letteralmente chiamato search, non solo web.search. I provider e gli MCP server senza namespace espongono i tool sotto verbi nudi, quindi un suffisso in allowlist è più ampio di quanto sembri. Preferisci nomi esatti o prefissi quando vuoi una allow-list stretta.

​
4. Fai il rollout senza rompere il tuo agent

Default-deny è la postura più probabile a bloccare un tool che hai dimenticato di avere bisogno. Fallo per fasi:
Attiva la shadow mode. La policy valuta e logga esattamente come farebbe live, ma declassa ogni deny a audit con la motivazione prefissata [shadow] would …. Fai girare traffico reale, poi leggi il feed degli eventi.
Discovered tools elenca ogni tool che il workspace ha visto, marcato covered o gap. Gli eventi “would-deny” della shadow mode più i gap ti dicono esattamente quali regole di allow ti servono ancora.
La sandbox Test esegue un dry-run della policy contro una chiamata a tool di esempio e restituisce il verdetto, la regola corrispondente e la motivazione — nulla dispatchato, nulla persistito. Conferma che web.search consenta e shell.exec neghi, poi disattiva lo shadow.
Una chiamata inbound negata costa zero token del modello — è bloccata prima che il modello upstream giri — ed è marcata skip-retry, così un tool bloccato non brucerà un budget di retry ri-bloccandosi. Vedi Verdetti.

​
5. Dove andare dopo

Blocca tool specifici

L’inverso — mantieni un pavimento default-allow e nega i tool nominati.

Valida gli argomenti

Consenti un tool, ma solo con argomenti sicuri (db.query ma non DROP TABLE).

Priorità delle regole

Come il first-match-wins ordina le tue regole di allow sopra il pavimento di deny.

Verdetti

allow, audit, deny, sanitize, pending_approval, cap_cost.
Per la minaccia che questo pattern affronta, vedi agenzia eccessiva e chiamate a tool pericolose. Per perché default-deny è la baseline degli agent, vedi perché zero trust.