Vai al contenuto principale
Un agent MCP è un agent con portata. Ogni Model Context Protocol server a cui si connette è un nuovo insieme di tool, credenziali e destinazioni di rete che nessuno ha esaminato — e l’agent può tirarne dentro uno nuovo a metà esecuzione. Questa ricetta mostra le quattro mosse che trasformano un setup MCP sparpagliato in uno governato sul gateway hosted: un unico gateway MCP sottoposto ad audit, la quarantine delle skill, il diniego dell’egress e l’auth cifrata dei server. Configuri tutto dalla console (o dalla REST API) contro il tuo workspace. Il tuo agent continua a parlare MCP esattamente come prima.

​
1. Perché proteggere un agent MCP

Punta un agent direttamente su cinque MCP server e hai cinque confini di fiducia, cinque store di credenziali e zero traccia di audit condivisa. Il tools/call che legge un record di un cliente e quello che esegue un comando shell sembrano identici al modello, e un server della community può silenziosamente richiedere shell.exec e uno scope di rete esterno la prima volta che si carica. La soluzione è rendere OrcaRouter l’unico punto di strozzatura che ogni chiamata attraversa. Per proteggere il traffico di un agent MCP end to end instradi tutto il dispatch MCP attraverso il gateway MCP del Firewall, così ogni tools/call viene valutato dalla policy prima di raggiungere il server reale — con le skill a cui è assegnato un punteggio di rischio, l’egress governato e le credenziali cifrate a riposo.
Questa è una ricetta — cuce insieme feature esistenti in un’unica passata di hardening concreta. Per il riferimento completo, segui i link in Firewall, MCP server e Skill.

​
2. Parti dalla baseline Secure Agents

Prima di scrivere qualsiasi cosa su misura, imposta una postura. Nella console apri Firewall → Posture e applica il livello di autonomia balanced (ruolo Developer). In una transazione auditerà le chiamate a tool e segnala le PII mentre nega le azioni più distruttive — osservi prima di applicare ampiamente, con undo a un clic. Quando i feed Events e Runs sembrano giusti, passa a tight: default-deny, shell distruttiva negata, egress a forma di SSRF negato, più i guardrail PII Shield e Secrets Blocker applicati. Quel singolo interruttore è il pavimento su cui questa ricetta costruisce.
Preferisci salire di livello senza ribaltare l’intero workspace? Scrivi le regole qui sotto in un’unica policy nominata e attiva la sua shadow mode — valuta e logga ma declassa ogni verdetto applicativo a audit (motivazione prefissata [shadow] would …) finché non sei sicuro. Vedi modalità di applicazione.

​
3. Instrada ogni tools/call attraverso un unico gateway MCP

Registra ogni MCP server una volta; il gateway aggrega i loro tool sotto un’unica connessione (con namespace <server>.<tool>) ed esegue ogni tools/call attraverso il motore del firewall. Registra un server dalla console (o dalla REST API, Developer+): 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-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 punta il tuo client MCP sul gateway — non sui server a monte — usando una chiave dedicata con scope firewall-gateway: 
https://api.orcarouter.ai/api/v1/firewall/mcp
Ora github.create_issue e shell.exec compaiono fianco a fianco sotto un’unica connessione, e ogni dispatch è valutato prima di girare. Una chiamata bloccata torna al modello come un errore di tool (firewall deny: …), non un crash di trasporto, così l’agent può adattarsi.
Una chiave di relay normale riceve 403 sulla rotta del gateway /api/v1/firewall/mcp. Conia un token di gateway dedicato (is_firewall_gateway) per la connessione MCP; leggere il plaintext di quella chiave di gateway richiede Admin+.
Prima di poter scrivere regole contro i tool di un server, sondalo per scoprire i loro nomi e schemi: 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. Metti in quarantine le skill che l’agent tira dentro

Il gateway MCP governa le chiamate; la governance delle skill governa le capability che un agent carica. Ogni skill installabile, MCP server BYO o plugin viene scansionato in una fascia di rischio e una modalità di applicazione che si sovrappone a ogni verdetto di regola:
ModalitàEffetto a runtime
allowDecidono i verdetti delle regole; la skill non aggiunge nulla.
quarantineQualsiasi cosa al di sotto di deny viene messa in attesa per pending_approval.
blockI tool della skill vengono forzati a deny.
Il punto per un agent MCP: una capability che nessuno ha approvato non riceve un lasciapassare. Quando un agent auto-installa qualcosa e i suoi tool attraversano per la prima volta il gateway, il Firewall lo auto-rileva e lo mette in quarantine finché un umano non lo esamina — anche se ha superato la scansione pulita. Pre-approva i server di cui ti fidi; lascia che il resto finisca nella coda di revisione.
Mantieni balanced/observe attivo mentre apprendi cosa il tuo agent installa davvero, poi promuovi le skill di fiducia ad allow e lascia in quarantine la coda lunga. Vedi Skill.

​
5. Nega l’egress a forma di SSRF

Un tool MCP compromesso o confuso che raggiunge il cloud-metadata o un host di intranet è il classico percorso di esfiltrazione. Due layer lo coprono. Primo, il gateway valida ogni endpoint MCP remoto e il suo IP di dial risolto contro una policy SSRF in fase di registrazione e a ogni hop di dispatch — i range di intranet e l’indirizzo di cloud-metadata vengono rifiutati, ri-controllati per sconfiggere il DNS rebinding. Questo è integrato; non lo configuri. Secondo, il livello di autonomia tight fornisce un preset di egress SSRF che nega i nomi di tool a forma di fetch — http_fetch, web_search, fetch_url, request, e le loro forme con namespace <server>.* — così un tool il cui intero compito è “vai a recuperare questo URL” viene fermato prima di comporre il numero. Per governare dove i tool possono arrivare per destinazione, scrivi la tua regola egress con una deny list di host/CIDR — quella è la superficie per fissare la portata in uscita: 
// regola del firewall, stage egress — nega l'uscita verso un range interno.
// egress_json è una *stringa* JSON: {"deny":[…],"allow":[…]} di host/CIDR.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
Nessun preset fornisce regole egress CIDR — il preset SSRF corrisponde sui nomi di tool, non sulle destinazioni. Scrivi tu stesso la deny list host/CIDR quando ti serve il controllo a livello di destinazione. Vedi liste di egress e fermare l’esfiltrazione.

​
6. Mantieni cifrate le credenziali dei server

L’auth_json di ogni MCP server è cifrato a riposo e mascherato in lettura; il gateway inietta le credenziali al momento del dispatch, così non raggiungono mai il modello o il client. Valori di auth_mode supportati:
{ "token": "…" } — un token bearer statico, inviato come Authorization: Bearer.
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — OAuth client-credentials; il gateway recupera e rinnova il token.
{ "username": "…", "password": "…" } — HTTP Basic auth.
"" — un server non autenticato. Il default.
In lettura il segreto è mascherato; rimanda indietro la mask in update per mantenere il valore memorizzato. Lo status del server (ok / degraded / down) dall’ultima sonda ti dice se è raggiungibile prima di farci affidamento.

​
7. Aggiungi un guardrail di contenuto sulla richiesta

Il Firewall governa le azioni; abbinalo a un Guardrail così anche il testo che si muove attraverso il tuo agent MCP viene filtrato. Il preset Secrets Blocker coglie le credenziali in una richiesta prima che il modello — o qualsiasi tool — le veda, e un PII Shield maschera gli identificatori all’ingresso. Entrambi arrivano con il livello di autonomia tight, oppure collega un guardrail nominato alla chiave di relay dell’agent tramite guardrail_id.
Il verdetto sanitize del firewall redige gli argomenti delle chiamate a tool, mai il contenuto che un tool restituisce. Rimuovi i segreti dalla richiesta con il guardrail Secrets Blocker; sanitizza gli argomenti che un agent emette con una regola del firewall. Coprono metà diverse del flusso.

​
8. Verifica e osserva

Conferma che la policy faccia ciò che ti aspetti prima di fidartene, poi tieni d’occhio i feed:

Testa una chiamata a tool

Esegui in dry-run un tools/call di esempio contro la tua policy e vedi il verdetto, la regola corrispondente e la motivazione — nulla dispatchato, nulla loggato.

Discovered tools

Ogni tool che il workspace ha visto, marcato covered o gap — scrivi regole direttamente dal traffico MCP reale.

Events & Runs

Ogni dispatch, il suo verdetto e la superficie che ha colpito, aggregato per esecuzione dell’agent.

Feed delle anomalie

Picchi di rate/costo, loop di retry e percorsi di tool nuovi rispetto a una baseline appresa.

​
9. Dove andare dopo

MCP tool poisoning

Il modello di threat dietro la quarantine e il gateway MCP.

Agenzia eccessiva

Perché default-deny e HITL contano per l’uso autonomo dei tool.

Ricetta per agent autonomo

Hardening di un agent ad alta autonomia end to end.

Fermare l'esfiltrazione

Blinda l’egress in uscita in profondità.