Vai al contenuto principale
Un agent che parla il Model Context Protocol (MCP) è sicuro solo quanto i server a cui si connette. Ogni MCP server è un nuovo insieme di tool, una nuova credenziale e un nuovo raggio d’azione di rete — e nel momento in cui un agent ne contatta uno direttamente, nessuno sta osservando la chiamata. È questo l’intero problema che la mcp security deve risolvere: non “questo singolo tool è sicuro” ma “chi governa tutti loro, su ogni chiamata, con un’unica traccia di audit.” La risposta di OrcaRouter è un unico punto di strozzatura sottoposto ad audit. Registri ogni MCP server una volta; gli agent si connettono a un gateway; e ogni tools/call passa attraverso il motore del firewall prima di raggiungere il server reale. Questa pagina è la mappa di quella superficie — il gateway, il verdetto per chiamata, la governance delle skill, l’egress e le credenziali cifrate — con link al how-to mirato per ciascuno.
Ogni azione di gestione qui viene configurata dalla console (o dalla REST API con il tuo session/access token) ed è role-gated. Solo le chiamate relay /v1/* e le route del gateway del firewall portano una chiave in stile sk-orca-....

​
1. Perché la mcp security ha bisogno di un gateway

Punta dieci agent su cinque MCP server della community direttamente e ottieni il peggio di ogni mondo: nessuna policy condivisa, nessuna traccia di audit, credenziali copiate in dieci config di agent, e un tool chiamato shell.exec a un redirect di distanza dal tuo endpoint cloud-metadata. Il gateway comprime tutto questo in un’unica connessione governata.

Una connessione, ogni server

Gli agent si connettono a un singolo endpoint. Il gateway aggrega i tool di ogni server abilitato e raggiungibile sotto un namespace <server>.<tool>.

Policy su ogni chiamata

Ogni tools/call viene valutato dalla tua policy del firewall prima del dispatch.

Credenziali cifrate

I segreti di auth dei server sono cifrati a riposo, mascherati in lettura, e iniettati al dispatch — non raggiungono mai il modello o il client.

Egress sotto controllo

L’endpoint di un server registrato viene validato per default rispetto ai range IP privati e cloud-metadata. Per le destinazioni per-tool, applica la denylist egress SSRF di base o scrivi le tue regole host/CIDR.
Per le fondamenta dietro tutto questo, vedi Proteggere gli agent AI e Perché zero trust.

​
2. I quattro mattoni

La governance MCP su OrcaRouter è fatta di quattro pezzi che cooperano. Scegli quello che corrisponde alla domanda a cui stai cercando di rispondere.
Un singolo endpoint a cui i tuoi agent si connettono invece di contattare i server direttamente. Aggrega i tool di ogni server registrato, con namespace <server>.<tool>, e ri-espone verbatim lo schema di input di ogni tool. Parti da Connettere un MCP server e Autenticare; il riferimento completo vive in Firewall: MCP server.
Il gateway esegue ogni tools/call attraverso il firewall sulla superficie mcp e restituisce un verdetto — allow, audit, deny, sanitize, o pending_approval — prima del dispatch. Vedi Allow-list dei tool MCP e Sanitizzare gli argomenti dei tool.
Le capability che un agent auto-installa — skill, BYO MCP server, plugin — vengono scansionate, classificate in una banda di rischio, e ricevono una modalità di applicazione (allow / quarantine / block) che si sovrappone a ogni verdetto di regola. Vedi Firewall: skill e Difesa dai rug-pull.
Il segreto di auth di ogni server è cifrato a riposo e mascherato in lettura. Vedi Autenticare e Rotazione delle credenziali.

​
3. Come viene valutato un tools/call

Quando un agent chiama un tool attraverso il gateway, la chiamata non va direttamente al server. Viene confrontata con la policy del tuo workspace, la modalità di applicazione della skill proprietaria viene applicata sopra, e solo un verdetto allow / audit / sanitize raggiunge il server reale.
VerdettoCosa vede l’agent
allow / auditInoltrata. audit logga anche un evento.
sanitizeInoltrata con gli argomenti redatti (mai il risultato).
deny / pending_approvalRestituita come un errore di tool, così l’agent può adattarsi invece di andare in crash.
Una chiamata MCP bloccata torna come un errore di tool (firewall deny: …), la stessa forma che restituisce qualsiasi tool che fallisce — l’agent può ritentare in modo diverso, chiedere all’utente o fermarsi. Non è un crash di trasporto.
Il vocabolario dei verdetti, le superfici e il matching delle regole sono documentati per intero sotto Firewall e Regole del firewall; il modello concettuale è in Modalità di applicazione e Come OrcaRouter ispeziona.

​
4. Registrare un server (un esempio concreto)

Registri ogni server una volta. Un record di server porta un name (unico per workspace, nessun .), un endpoint, un auth_mode (none / bearer / oauth / basic), e le sue credenziali cifrate. Fallo dalla console — la scrittura richiede Developer+. 
# Route della console, chiamata con il tuo session/access token (UserAuth).
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\"}",
    "enabled": true
  }'
Poi fai il probe per scoprire i suoi tool e registrare la raggiungibilità (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Ora puoi scrivere regole contro github.* sapendo esattamente cosa accetta github.create_issue. La procedura end-to-end vive in Connettere un MCP server.
I segreti non vengono mai memorizzati in chiaro. auth_json è cifrato a riposo e mascherato in lettura; su un update, rimanda indietro la maschera per mantenere il valore memorizzato. Vedi Rotazione delle credenziali.

​
5. Collegare un agent al gateway

Una volta registrati i server, punta qualsiasi client MCP sul gateway con una chiave con scope firewall-gateway (un token senza quello scope riceve 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
Il gateway parla streamable HTTP e pubblicizza i tool di ogni server abilitato e raggiungibile sotto il namespace <server>.<tool>. Un SDK che fa da proxy delle chiamate da sé può leggere il registro a runtime da GET /api/v1/firewall/mcp_servers con lo stesso token gateway.

​
6. Blocca dove i tool possono arrivare

I verdetti per chiamata governano quale tool gira; i controlli di egress governano dove può arrivare. Due layer cooperano. Primo, quando il gateway si connette all’endpoint di un server registrato, quell’URL viene validato per default rispetto ai range privati (RFC1918), loopback, link-local e cloud-metadata — e l’host viene risolto via DNS così un nome che risolve in un range bloccato viene anch’esso rifiutato. Quindi un server BYO puntato a 169.254.169.254 o a un indirizzo intranet viene rifiutato a meno che tu non l’abbia esplicitamente messo in whitelist. Secondo, per le destinazioni per-tool, una regola egress porta una lista allow/deny di host/CIDR confrontata con la destinazione in uscita della chiamata sulla superficie egress. Il template di use-case di base fornisce una regola egress deny pronta all’uso la cui lista copre già i range privati, loopback, link-local e cloud-metadata (incluso 169.254.169.254 e metadata.google.internal), così applicarla ti dà difesa SSRF/metadata senza scrivere CIDR a mano.
SSRF ed egress sono la differenza tra “questo tool ha restituito dati” e “questo tool ha esfiltrato i tuoi segreti verso l’host di un attaccante.” Applica la denylist egress di base e aggiungi le tue regole host/CIDR — vedi Limiti di egress e Esfiltrazione dei dati.

​
7. Osservalo: eventi, run e anomalie

Ogni chiamata governata lascia una traccia. Gli eventi del firewall registrano il verdetto, la superficie e la regola che ha fatto match; i run raggruppano le chiamate di una sessione; e il feed delle anomalie segnala picchi di rate e costo rispetto a un baseline appreso. Le letture di impostazioni, policy e tool scoperti sono aperte a qualsiasi Member; le letture di event/run/aggregate richiedono Developer+.

​
8. 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 che hai revisionato.

Difesa dai rug-pull

Governa server e skill che cambiano dopo che li hai approvati.

Firewall: MCP server

Il riferimento completo di campi e route.
Nuovo al modello? Leggi Guardrails vs. firewall per vedere dove si colloca la governance MCP, poi Avvelenamento dei tool MCP e Agency eccessiva per le minacce che chiude.