Allow-list dei tool MCP per policy

Un MCP server registrato pubblicizza qualsiasi tool voglia — e un agent chiamerà volentieri uno qualsiasi di essi. La postura sicura è l’inverso: decidi la breve lista di tool che ti servono davvero, consenti esattamente quelli, e nega il resto. È un’allow-list, e su OrcaRouter la costruisci a partire da regole tool_name_glob valutate sulla superficie mcp. Ogni tools/call che attraversa il gateway MCP passa attraverso la tua policy del firewall prima di raggiungere il server reale. Quindi l’allow-list non è consultiva — una chiamata a un tool che non hai consentito non viene mai dispacciata.

​

1. Perché un’allow-list default-deny per secure mcp tools

Una deny-list — “blocca i tool pericolosi” — fallisce nel momento in cui un server aggiunge un nuovo tool, ne rinomina uno, o connetti un secondo server. L’insieme dei tool pericolosi è aperto; l’insieme che intendevi usare è piccolo e noto. Un’allow-list inverte il default così l’ignoto viene rifiutato, non ammesso:

• I nuovi tool sono negati per default. Un server che fa crescere un tool delete_repo dopo che l’hai connesso non può essere chiamato finché non lo aggiungi all’allow-list.
• Lo scope è per server. Il namespace <server>.<tool> ti lascia consentire github.create_issue negando tutto il resto sotto github.*.
• Un punto di strozzatura. La stessa policy governa il server bundled e ogni server BYO dietro il gateway, così c’è un unico posto dove leggere l’allow-list.

​

2. I due pezzi

Un’allow-list è un default_verdict più un insieme ordinato di regole. Il glob è confrontato con il nome del tool con namespace — github.create_issue, shell.exec. * matcha qualsiasi tool (usalo con parsimonia; una regola allow con * annulla l’intera allow-list). Un <server>. iniziale dà scope al glob a un solo server.

​

3. Un esempio concreto

Hai connesso un server github e vuoi solo che gli agent leggano e aprano issue — mai eliminare o amministrare nulla. Nella console, apri Firewall → Policies, imposta il verdetto di default della policy su deny, e aggiungi due regole allow: Questa è l’intera allow-list. Con il default a deny:

• github.create_issue → matcha la regola 1 → allow, fa il dispatch.
• github.delete_repo → non matcha nulla → deny per default.

Una chiamata MCP negata torna al modello come un errore di tool (firewall deny: …) — la stessa forma che restituisce qualsiasi tool che fallisce — così l’agent può adattarsi anziché andare in crash. (Sulla superficie inbound un deny è invece un HTTP 400 con codice di errore firewall_blocked.)

​

4. Stringere con gli argomenti

Un nome di tool sull’allow-list può comunque essere chiamato con argomenti errati. Restringi ulteriormente aggiungendo una clausola args_match (JSONPath + un operatore come eq, contains, regex, in o cidr_match) alla regola, o stratificando una regola deny sopra l’allow per una forma di argomento specifica — per esempio, consenti github.create_issue ma fai deny quando il repo target non è su una lista approvata. Vedi il riferimento delle regole del firewall per l’insieme completo di operatori.

​

5. Fai il rollout in sicurezza

Fai scattare un default-deny per tutto un server in produzione e rischi di rompere un agent che dipendeva in silenzio da un tool che hai dimenticato. Due impostazioni lo rendono meno rischioso: Una volta che il log shadow è pulito — nessuna chiamata legittima sarebbe stata negata — togli shadow_mode e l’allow-list viene applicata.

​

6. Verifica che funzioni

Dopo l’enforcing, conferma che i tool negati vengano effettivamente rifiutati:

• Dry-run di un tools/call contro la policy (Developer+) per vedere il verdetto e quale regola — o il default — l’ha prodotto, senza inviare traffico reale. Passa un nome di tool, una superficie e args di esempio; il motore li valuta e restituisce la traccia del verdetto senza registrare un evento.
• Osserva gli eventi. Ogni chiamata bloccata registra un evento del firewall che un Developer+ può leggere nella console; la pagina eventi di audit copre il feed e i suoi campi.

​

Correlati