Vai al contenuto principale
Un MCP server di terze parti è un bundle non revisionato di tool, una credenziale live, e fresco raggio d’azione di rete. Nel momento in cui un agent ne contatta uno direttamente, nessuno sta osservando la chiamata — e “il server ha cambiato i suoi tool dopo che l’hai approvato” è un attacco reale, non un’ipotesi. Prima di puntare un agent su un server che qualcun altro gestisce, vuoi un pre-flight ripetibile. Questa pagina è quel pre-flight: una checklist breve e ordinata per esaminare un mcp server su OrcaRouter usando controlli che già esistono — valutazione per chiamata, allow-listing default-deny, limiti di egress, credenziali cifrate, e quarantena delle skill. Ogni passo linka al how-to mirato per l’approfondimento. Eseguila una volta per ogni nuovo server; ri-esegui i passi sensibili al drift ogni volta che il server cambia.
Ogni passo di configurazione qui viene fatto dalla console (o dalla REST API con il tuo session/access token) ed è role-gated. Solo le route del gateway del firewall e le chiamate relay /v1/* portano una chiave in stile sk-orca-....

​
1. La checklist per esaminare le connessioni mcp server

Lavora dall’alto verso il basso. I primi tre passi sono obbligatori per qualsiasi server che non gestisci tu stesso; il resto lo irrobustisce.

1. Fai il probe prima di fidarti

Scopri la vera lista di tool e la raggiungibilità prima di scrivere una singola regola.

2. Default-deny, poi allow-list

Permetti solo i tool che hai revisionato; tutto il resto è negato.

3. Cifra la credenziale

Memorizza l’auth così è cifrata a riposo, mascherata in lettura, mai vista dal modello.

4. Blocca l'egress

Vincola dove i tool del server possono arrivare in rete.

5. Metti in quarantena le skill auto-installate

Metti in attesa qualsiasi cosa l’agent installi da solo finché un essere umano non la revisiona.

6. Prima shadow, poi osserva

Fai il rollout in solo-audit, poi leggi eventi e anomalie prima di enforce.

​
2. Fai il probe prima di fidarti

Non puoi revisionare tool che non hai mai visto, e la lista di tool pubblicizzata di un server è la cosa più probabile a cambiare sotto di te. Registra il server, poi fai il probe — il gateway esegue un MCP initialize + tools/list contro l’endpoint e restituisce i tool reali con i loro schemi di input, più uno status di raggiungibilità di ok, degraded o down. 
# Route della console, chiamata con il tuo session/access token (UserAuth). Developer+.
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Leggi ogni nome di tool e cosa accettano i suoi argomenti. Un server che pubblicizza uno shell.exec o un http_fetch che non ti aspettavi è una finding, non un dettaglio — è proprio il punto di fare prima il probe.
Rifai il probe ogni volta che un server cambia mani o sospetti drift. Un nuovo tool che compare nella lista — il “rug pull” — è esattamente ciò che stai sorvegliando. Vedi Difesa dai rug-pull.
Il riferimento completo di registrazione e probe vive in Firewall: MCP server; la procedura end-to-end è Connettere un MCP server.

​
3. Default-deny, poi allow-list dei tool che hai revisionato

Un’allow-list è la differenza tra “il server può fare sei cose” e “il server può fare qualsiasi cosa il suo operatore decida domani”. Imposta il default_verdict della policy su deny, poi aggiungi una regola per tool che hai revisionato e di cui ti fidi. Poiché il gateway mette a namespace ogni tool <server>.<tool>, puoi dare scope alle regole a un solo server senza toccare gli altri. 
// Policy sulla superficie mcp: nega per default, consenti solo ciò che hai revisionato.
// tool_name_glob supporta un wildcard di segmento completo: "github.*" (prefisso),
// "*.exec" (suffisso), o "*.shell.*" (infisso). I glob a metà segmento come
// "github.get_*" ricadono su un match esatto e non si espandono.
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
Ora github.create_issue gira, github.get_issue gira, e un github.delete_repo appena introdotto è negato finché non l’hai revisionato e permesso. Un tools/call negato torna al modello come un errore di tool (firewall deny: …) — l’agent si adatta invece di andare in crash. Vedi Allow-list dei tool MCP per la ricetta completa, e Regole del firewall per il DSL di matching.

​
4. Cifra la credenziale — non costruire mai l’auth a mano

Un server di terze parti quasi sempre ha bisogno di una credenziale, e una credenziale è la cosa che meno vuoi che stia in chiaro o raggiunga il modello. Registra l’auth del server attraverso OrcaRouter così è cifrata a riposo, mascherata in lettura, e iniettata solo al momento del dispatch. auth_mode è uno tra none, bearer, oauth o basic: 
# Route della console, UserAuth, Developer+.
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}"
  }'
La credenziale è cifrata e mascherata nel momento in cui viene memorizzata — non raggiunge mai il modello o il client, e in lettura vedi solo la maschera. Su un update, rimanda indietro la maschera per mantenere il valore memorizzato; invia un auth_json nuovo solo quando stai ruotando. Vedi Autenticare e Rotazione delle credenziali.

​
5. Blocca l’egress: dove possono arrivare i suoi tool?

I verdetti per chiamata decidono quale tool gira; l’egress decide dove può arrivare. Un tool che “restituisce dati” e un tool che “esfiltra i tuoi segreti verso l’host di un attaccante” possono essere lo stesso tool con un argomento diverso — il controllo di egress è ciò che li distingue. Il gateway già valida ogni endpoint remoto e il suo IP di dial risolto contro una policy SSRF a ogni hop, rifiutando i range intranet e l’indirizzo cloud-metadata e ri-controllando l’IP per sconfiggere il DNS rebinding. Sopra a questo, scrivi la tua regola egress deny per gli host e i CIDR che questo server non dovrebbe mai toccare: 
// Una regola di stage egress dà scope al suo verdetto alla destinazione in uscita.
// egress_json porta liste allow + deny di host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
Non c’è un preset che fornisce regole CIDR per te — scrivi tu stesso la deny list di host/CIDR, con scope a ciò di cui questo server ha legittimamente bisogno. Vedi Limiti di egress e Esfiltrazione dei dati.

​
6. Metti in quarantena ciò che l’agent installa da solo

Il server che hai registrato è un rischio; le skill, i BYO MCP server e i plugin che un agent auto-installa dopo sono un altro. OrcaRouter scansiona ogni capability installabile, le assegna una banda di rischio, e ne deriva una modalità di applicazione — allow, quarantine o block — che si sovrappone a ogni verdetto di regola. Qualsiasi cosa auto-rilevata al primo uso è in quarantena finché un essere umano non la revisiona: una capability che nessuno ha approvato non ottiene un lasciapassare solo perché ha scansionato benigna. Una capability quarantine escala qualsiasi cosa che non sia un deny a pending_approval, così i suoi tool girano solo dopo che hai guardato.
Non cercare di registrare ogni skill a mano. Pre-approva quelle di cui ti fidi e lascia che il resto venga auto-rilevato e messo in quarantena — poi revisiona dai dati reali. La modalità si stringe sempre più su una ri-scansione, mai più lasca. Vedi Firewall: skill e Avvelenamento dei tool MCP.

​
7. Prima shadow, poi osserva la traccia

Non fare scattare un server nuovo di zecca direttamente a enforcing. Metti la policy in shadow mode — i verdetti enforcing sono declassati a audit e loggati come [shadow] would … — così puoi vedere cosa sarebbe stato bloccato prima che lo sia davvero. Quando la traccia di audit sembra giusta, togli la shadow mode ed enforce. Dopo che è live, i controlli continuano a sorvegliare:
Ogni chiamata governata registra il suo verdetto, superficie e regola matchata. Leggili per confermare che l’allow-list e le regole egress si comportano come previsto. Vedi Eventi di audit MCP.
Picchi di rate e costo rispetto a un baseline appreso, più loop di retry e percorsi di tool nuovi, emergono come anomalie — leggibili da qualsiasi Member.
Attiva l’observe mode per loggare come lacune le chiamate che una policy non copre ancora, così stringi da ciò che un agent fa davvero, non da supposizioni.

​
8. Il percorso rapido: scegli un livello di autonomia

Se preferisci non costruire a mano i passi 3–5 per un server di cui non ti fidi del tutto, applica un livello di autonomia e modifica da lì. I livelli scrivono righe di policy e guardrail reali e modificabili — sono un punto di partenza, non una black box:
LivelloCosa imposta
permissiveObserve mode attivo — logga tutto, enforce nulla.
balancedPolicy default-audit che nega shell distruttiva, più il guardrail PII Shield in modalità solo-flag.
tightPolicy default-deny che nega shell distruttiva e tool a forma di fetch (http_fetch/web_search/fetch_url/request — il vettore SSRF), più i guardrail PII Shield e Secrets Blocker applicati. I segreti negli argomenti sono colti dal guardrail Secrets Blocker sulla richiesta, non da una regola tool-arg.
Per un server di terze parti che stai ancora esaminando, parti da tight, fai il probe, poi rilassa tool specifici in un’allow-list. L’undo a un clic ripristina la snapshot pre-apply.
Le letture di impostazioni, policy, tool scoperti, anomalie, MCP server registrati e skill sono aperte a qualsiasi Member; le letture di event, run e aggregate richiedono Developer+, e ogni scrittura richiede Developer+. Rivelare la chiave in chiaro di un token è anch’esso Developer+.

​
9. Dove andare dopo

Connettere un MCP server

Registra, fai il probe ed esponi un server attraverso il gateway.

Allow-list dei tool MCP

Default-deny su un server e permetti solo i tool revisionati.

Difesa dai rug-pull

Cogli un server o una skill che cambia dopo che l’hai approvato.

Panoramica sulla sicurezza MCP

La mappa completa della superficie di governance MCP.
Nuovo al modello? Leggi Guardrails vs. firewall per dove si colloca la governance MCP, poi Agency eccessiva e Chiamate a tool pericolose per le minacce che questa checklist chiude.