Vai al contenuto principale
Ogni MCP server che registri, ogni skill che un agent installa e ogni host che un tool raggiunge è una dipendenza che non hai scritto. La supply chain di un agent è dinamica — cresce a runtime, spesso senza un umano nel loop — quindi il classico modello “rivedi il lockfile al build time” non regge. Una skill della community può essere dirottata dopo che ti fidi di lei; un MCP server remoto può aggiungere silenziosamente un tool; un tool di fetch può essere pilotato verso un host controllato dall’attaccante. La risposta di OrcaRouter è governare la supply chain dove agisce — al gateway, al primo uso — invece di provare a esaminare ogni dipendenza al momento dell’installazione. Questa pagina è la landing per il caso d’uso ai supply chain security; i riferimenti Firewall e Skill portano la meccanica completa.

​
1. Sicurezza della supply chain AI per gli agent, al gateway

Il punto di strozzatura è il percorso di relay. Che una capability sia stata registrata a mano, auto-installata dall’agent o tirata da un registry della community, la sua prima chiamata a tool attraversa api.orcarouter.ai — ed è lì che il Firewall la valuta. Quattro controlli si compongono in un’unica postura:

Gateway MCP, eval per chiamata

Ogni tools/call viene valutato contro la tua policy prima del dispatch — il manifest non è mai la fonte di verità.

Fasce di rischio & quarantena delle skill

Le capability installate vengono scansionate, valutate e messe in attesa di revisione finché un umano non le approva.

Credenziali MCP cifrate

I segreti di auth del server sono cifrati a riposo e iniettati al dispatch — mai esposti al modello, all’agent o agli argomenti delle chiamate.

Allow-list di egress

Fissa dove le chiamate a tool possono inviare dati, così una dipendenza compromessa non può esfiltrare verso un host che non hai mai approvato.
La detection è al gateway, al primo uso — non nel tuo package manager o filesystem. È deliberato: è l’unico percorso che vede ogni agent e ogni chiamata a tool indipendentemente da come la capability è arrivata lì.

​
2. La minaccia: una dipendenza che cresce dopo che ti fidi di lei

VettoreCosa succede
Rug-pullUn MCP server registrato aggiunge un tool (shell.exec, un nuovo fetch) che non hai mai approvato.
Skill creepUna skill installata usa tool o host che il suo manifest non ha mai dichiarato.
Furto di credenzialiL’implementazione di un tool di un server compromesso legge il proprio segreto di auth per telefonare a casa.
Esfiltrazione di egressUna catena recupera→invia spedisce i tuoi dati a un host controllato dall’attaccante.
La causa radice comune: “mi fido di questo server” viene trattato come permanente, e l’agent continua a chiamare tool nuovi o modificati senza ulteriore revisione.

​
3. Un esempio concreto — registrare e fissare un MCP server

Registri un MCP server di terze parti dalla console (Settings → Firewall → MCP servers; le scritture richiedono Developer+). Il segreto di auth del server è memorizzato cifrato — lo fornisci una volta, il gateway lo inietta al dispatch, ed è mascherato a ogni lettura successiva. Un record di MCP server porta:
CampoValori
auth_modenone, bearer, oauth, basic
statusok, degraded, down (impostato dalla health probe)
credentialscifrate a riposo, mai restituite in chiaro
Dopo la registrazione, fai la probe dalla console per enumerare i suoi tool attuali. La probe è un’operazione di sessione-workspace (/api/workspace/firewall/*) che richiede Developer+, non una chiave di relay — registrazione, probe e scrittura delle regole avvengono tutte sul piano di gestione: 
# Console / management plane — workspace session, Developer+.
# (The relay sk-orca-... key is for /v1/* traffic only.)
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/<id>/probe \
  -H "Authorization: Bearer <workspace-session-token>"
La probe persiste la raggiungibilità del server e fa uno snapshot di un hash di baseline del suo set di tool pubblicizzato (trust-on-first-use). Poi dai scope a una regola del Firewall con tool_name_glob: <server>.* su pending_approval finché non hai visto una storia di chiamate pulita — ogni chiamata da quel server è trattenuta per un umano prima di girare. Una volta che ti fidi, rilassa la regola a audit o allow. Da quel punto in poi il gateway MCP valuta ogni tools/call sulla superficie mcp prima del dispatch — così se un rug-pull aggiunge in seguito un tool non dichiarato, la tua policy, non il manifest del server, decide se gira.
Rifai la probe dopo ogni bump di versione upstream (POST /api/workspace/firewall/mcp_servers/:id/probe, Developer+). Se il set di tool pubblicizzato devia dalla baseline approvata, lo schema_status del server passa a changed e il dispatch fa fail closed finché un admin non rifà la baseline (approve_schema) o lo mette in quarantena — il rug-pull non può andare live silenziosamente.

​
4. Fasce di rischio & quarantena delle skill

Ogni capability installabile — che tu l’abbia registrata o che il gateway l’abbia auto-rilevata a runtime — viene passata attraverso lo scanner di skill. I findings si aggregano in una fascia di rischio e una modalità di applicazione:
low · medium · high · critical. La fascia è derivata da passaggi deterministici dello scanner sul manifest e sugli scope dichiarati (uso di tool non dichiarati, egress di rete fuori dagli scope approvati, scritture su filesystem non sicure, testo del manifest a forma di injection).
allow (decidono le regole della tua policy), quarantine (qualsiasi verdetto diverso da deny escala a pending_approval — un umano approva ogni chiamata), block (forza deny su tutti i tool di questa skill indipendentemente dalle regole). Una skill di fascia high va automaticamente in quarantena; critical blocca.
Una capability che un agent auto-installa, o un tool che un rug-pull aggiunge, è trattenuta in pending_approval indipendentemente dal suo punteggio di scan finché un umano non la rivede. Un operatore non può aggiungere silenziosamente un tool e fare in modo che i tuoi agent inizino a usarlo.
La modalità di applicazione si stringe sempre e solo — approvare una skill non rilassa mai un block che una scansione fresca ha impostato.

​
5. Allow-list di egress — contieni il “telefonare a casa”

L’esito di supply-chain più dannoso è una dipendenza compromessa che esfiltra. La superficie egress del Firewall valuta la destinazione in uscita (host / IP / CIDR) che un tool riporta, così puoi fissare dove i dati sono autorizzati a andare. Scrivi tu stesso una regola di egress: una allow-list host/CIDR con un predicato cidr_match nega tutto ciò che è fuori lista. Combinala con una regola di sequenza che spezza la catena recupera→egress, e un tool avvelenato che prova a spedire un documento recuperato a un host sconosciuto viene negato al gateway.
Il livello di autonomia tight include un preset SSRF, ma nega i nomi di tool a forma di fetch (http_fetch, web_search, fetch_url, request) — non è una denylist CIDR/cloud-metadata. Se ti serve il blocco dell’egress su RFC-1918 / metadata / CIDR specifici, scrivi tu stesso la regola di deny host/CIDR di egress. Vedi Firewall: Regole per l’operatore cidr_match e lo scoping dell’egress.

​
6. Credenziali cifrate — un server compromesso non può leggere le tue chiavi

I segreti di auth del server sono cifrati a riposo e iniettati dal gateway al momento del dispatch. Non raggiungono mai il modello, l’agent o gli argomenti delle chiamate a tool — così un server compromesso o malevolo non può esfiltrare le tue chiavi API leggendo il proprio blob di credenziali. La console restituisce sempre il segreto mascherato — anche a un Admin. Il valore decifrato viene consegnato su esattamente un percorso: una richiesta che porta un token con scope firewall-gateway (un tipo di token dedicato che un Admin conia esplicitamente per il gateway/proxy), così una chiave di relay ordinaria trapelata non può enumerare le tue credenziali MCP.

​
7. Raccogliere il tutto per un audit

La governance della supply-chain è anche un artefatto di audit. OrcaRouter mappa sul OWASP Top 10 for LLM Applications — incluso il controllo LLM05 Supply Chain — come parte del motore di compliance, accanto a framework come soc2, iso_27001, iso_42001, nist_ai_rmf e l’eu_ai_act. Installare un compliance pack (POST /api/compliance/packs/:key/install, Admin del workspace, piano a pagamento) materializza i guardrail e le policy del firewall corrispondenti e parte in una postura observe-first. I report di compliance includono una sezione AI-supply-chain evidence — i provider upstream verso cui il tuo workspace ha effettivamente instradato, più una revisione di accesso privilegiato e igiene delle chiavi — e sono firmati Ed25519 e pubblicamente verificabili. Sfogliare il catalogo e la readiness è gratuito per ogni Member; vedi Compliance per il ciclo di vita completo.
La governance MCP è due layer complementari: valutazione del firewall per chiamata sulla superficie mcp (applicazione su ciò che una dipendenza fa), più una baseline di integrità dello schema dei tool (hash trust-on-first-use del set di tool pubblicizzato, ri-controllato a ogni probe — la deriva fa passare lo schema_status del server a changed e fa fail closed il dispatch finché un admin non rifà la baseline o lo mette in quarantena). Insieme alle fasce di rischio e alla quarantena delle skill, è applicazione sia su ciò che una dipendenza fa sia un record verificabile di ciò che ha dichiarato.

​
8. Una baseline di supply-chain

Registralo, fai la probe del suo set di tool e dai scope a una regola <server>.* su pending_approval o audit. Leggi i findings dello scan — qualsiasi finding di tool-non-dichiarato o egress-esterno è un motivo per tenerlo in quarantena. Verifica chi controlla l’URL dell’endpoint.
Tieni una allow-list di egress fissata per ogni agent con tool di fetch/search/export. Osserva la vista Tool scoperti per capability comparse senza una regola, e il feed delle anomalie per percorsi novel da tool a tool.
Disabilita il server (PUT .../mcp_servers, "enabled": false) — le sue credenziali non vengono mai decifrate mentre è disabilitato. Rifai la probe per far emergere nuovi tool, riscansiona la skill e rivedi la coda pending_approval invece di approvare in blocco.

​
9. Minacce & concetti correlati

Firewall: MCP server

Registra MCP server dietro il gateway, fai la probe dei loro tool e applica un verdetto per chiamata prima che qualsiasi chiamata raggiunga il server reale.

Firewall: Skill

Scansiona e assegna un punteggio di rischio a ogni capability installabile. Metti in quarantena o blocca le skill rischiose prima che i loro tool girino.