Vai al contenuto principale
Un “rug pull” è la modalità di fallimento MCP in cui un server si comporta bene mentre lo stai osservando e diventa ostile una volta che è fidato: un tool che hai approvato al momento della connessione inizia a contrabbandare argomenti extra, un server della community che hai listato aggiunge in silenzio una nuova capability, o una skill che un agent ha auto-installato passa da benigna a pericolosa in produzione. Il pericolo è che nessuno ri-revisiona una connessione dopo che è live — la decisione di fiducia è stata presa una volta, all’handshake, e mai rivisitata. OrcaRouter non si fida dell’handshake. Difende su tre fronti. Il gateway MCP del Firewall valuta ogni tools/call al momento del dispatch contro la tua policy live. L’insieme di tool pubblicizzato di ogni server registrato è messo a baseline al primo probe e ri-controllato per il drift — se lo schema del tool cambia rispetto al baseline approvato, il server fallisce closed finché un admin non lo ri-approva o lo mette in quarantena. E il layer Skill assegna a ogni capability installata una banda di rischio e una modalità di applicazione — mettendo in quarantena qualsiasi cosa rischiosa o non revisionata finché un essere umano non firma. Un server non può guadagnarsi un lasciapassare comportandosi bene per le prime cento chiamate.

​
1. Perché la protezione dai rug pull MCP ha bisogno della valutazione per chiamata

Una revisione al momento della connessione risponde a una domanda una volta: è sicuro listare questo server? Non può rispondere alla domanda che conta davvero a runtime: questa specifica chiamata, con questi specifici argomenti, è sicura adesso? OrcaRouter risponde alla seconda domanda. Ogni tools/call che attraversa il gateway viene valutato sulla superficie mcp prima di essere dispacciato al server reale, con il nome del tool e gli argomenti in mano. Il verdetto è calcolato fresco ogni volta, così nel momento in cui un tool inizia a fare qualcosa che la tua policy vieta — esfiltrare un segreto in un argomento, raggiungere un host che è negato, chiamare una capability che non hai mai approvato — la chiamata viene fermata, indipendentemente da come si è comportato lo stesso tool un minuto fa.
La valutazione per chiamata governa il comportamento di ogni chiamata — contenuto degli argomenti, destinazioni, il rischio della skill proprietaria — così coglie un rug pull anche quando il tool mantiene una firma identica e solo il suo comportamento diventa ostile. Il rilevamento del drift di schema (§ sotto) è il layer complementare: coglie il caso in cui l’insieme di tool pubblicizzato del server cambia. Entrambi girano.
I verdetti che il motore può restituire sulla superficie mcp:

allow / audit

Inoltrata al server. audit logga la chiamata; allow resta silenzioso.

sanitize

Inoltrata con gli argomenti della chiamata a tool redatti prima (non ri-scrive mai ciò che il server restituisce).

deny

Restituita al modello come un errore di tool (firewall deny: …) così l’agent può adattarsi invece di andare in crash.

pending_approval

La chiamata è messa in attesa di un essere umano che la risolva prima che possa girare.

​
2. Quarantena per banda di rischio delle skill

La seconda metà della difesa dai rug-pull copre la supply chain: le skill, i plugin e i bring-your-own MCP server che un agent installa. Ciascuno viene registrato come record con scope a livello di workspace, scansionato da un motore di rischio deterministico, e classificato in una banda di rischio (low / medium / high / critical) più una modalità di applicazione:
ModalitàEffetto a runtime
allowDecidono i verdetti di regola; la skill non aggiunge nulla.
quarantineQualsiasi cosa che non sia un deny viene escalata a pending_approval — i tool girano solo dopo che un essere umano approva.
blockI tool della skill sono negati senza appello.
È qui che un rug pull viene contenuto. Una capability che un agent auto-installa è auto_detected e in quarantena fino alla revisione — anche se ha scansionato pulito, non gira di sua autorità. E la modalità di una skill si stringe sempre più solo su una ri-scansione: un block o quarantine che imposti non viene mai rilassato in silenzio quando un manifest viene ri-presentato.
La quarantena è applicata indipendentemente dalla shadow mode. Una skill impostata su quarantine o block resta in attesa anche mentre la policy circostante è in rollout shadow — così una capability rischiosa non può sgattaiolare durante un deployment graduale.
Vedi Firewall: Skill per lo scanner completo, i pesi di scoring e i segnali di fiducia.

​
3. Rilevamento del drift di schema dei tool

Il rug pull classico è un server registrato che cambia ciò che pubblicizza — aggiunge un tool, altera lo schema di input di un tool, sostituisce una descrizione. OrcaRouter mette a baseline l’insieme di tool pubblicizzato di ogni server registrato su un probe riuscito e lo sorveglia per il drift.

Baseline al primo probe

Il primo probe riuscito registra un hash canonico dei tool del server (trust-on-first-use sotto una postura di discovery; sotto una postura enforcing un server senza baseline è messo in attesa come pending finché un admin non approva il suo insieme di tool iniziale).

Il drift fallisce closed

A un probe successivo, se l’insieme di tool canonico non corrisponde più al baseline approvato il server è marcato changed e smette di essere servito — il gateway non dispaccerà i suoi tool finché non decidi.

Approva o metti in quarantena

Ri-approva per ri-baselinizzare al nuovo schema, o metti il server in quarantena. Un server in quarantena è anche disabilitato e solo un approve esplicito ripristina il servizio — una semplice modifica non può ri-abilitarlo.

Sottoposto ad audit

Il primo rilevamento di drift da un baseline approvato scrive una voce di audit del workspace, così il cambiamento è messo agli atti.
Lo schema status di un server è uno tra unknown (mai messo a baseline), verified (corrisponde al baseline), changed (driftato, in attesa), pending (senza baseline sotto enforcing), o quarantined. Questo layer coglie il rug pull che sposta lo schema; la valutazione per chiamata (§1) coglie quello che mantiene una firma identica e cambia solo il comportamento.

​
4. Un esempio concreto

Supponi che un MCP server della community notes pubblicizzi un innocuo tool notes.search. Lo listi, lo revisioni, e funziona. Una settimana dopo il server è compromesso e notes.search inizia ad attaccare un argomento di esfiltrazione che fa il POST del tuo contesto verso l’host di un attaccante. Un gateway solo-al-momento-della-connessione lo inoltrerebbe — il nome del tool e lo schema sembrano invariati. OrcaRouter valuta la chiamata: 
# Configura la regola deny nella console (Developer+), non tramite la relay key.
# Regola: sulla superficie mcp, nega notes.search ogni volta che porta un
#         argomento a forma di esfiltrazione.
#   tool_name_glob: notes.search
#   args_match:     { "path": "$.callback_url", "op": "regex",
#                     "value": "^https?://(?!notes\\.example/)" }  → deny
(Gli operatori args_match sono eq, contains, regex, in, cidr_match, gt, lt; cidr_match testa un argomento con valore IP contro un CIDR. Per delimitare dove un tool può arrivare per host/CIDR, usa la lista di destinazioni egress invece di una clausola di argomento.) Al dispatch il motore restituisce deny, e invece di inoltrare la chiamata il gateway consegna all’agent un errore di tool-result MCP — un normale risultato segnalato come errore, non un fallimento di trasporto — così il modello può adattarsi: 
firewall deny: <your rule's reason>
La stessa chiamata che è riuscita la settimana scorsa ora è bloccata — perché la decisione è presa sulla chiamata, non sulla connessione.
sanitize redige gli argomenti che il tuo agent invia, mai il contenuto che un tool restituisce. Se hai bisogno di vincolare dove un tool può arrivare, abbina una regola deny a una lista di destinazioni egress — non fare affidamento su sanitize per ripulire le risposte.

​
5. Come si combina

La valutazione per chiamata coglie un tool fidato che diventa malevolo — stesso nome, nuovo comportamento negli argomenti o nella destinazione. La quarantena delle skill coglie una capability nuova o non revisionata che compare del tutto — un’installazione auto-rilevata, un manifest ri-scansionato che peggiora di nuovo. Un rug pull può prendere entrambe le forme, quindi entrambi girano: la modalità della skill si sovrappone al verdetto della regola per chiamata.
Sì — vedi §3. L’insieme di tool pubblicizzato di ogni server registrato è messo a baseline al primo probe e ri-controllato per il drift; un server driftato fallisce closed finché non lo ri-approvi o lo metti in quarantena. Questo è complementare alla valutazione per chiamata, che coglie anche un tool che mantiene una firma identica e cambia solo il suo comportamento.
Un verdetto pending_approval mette in attesa la chiamata di un essere umano che la risolva nella console (Developer+) o tramite una callback di approvazione HMAC. Vedi modalità di applicazione per come le attese e le approvazioni vengono presentate a un agent.

​
6. Configurarlo

Ogni passo sotto è un’azione di console / gestione autenticata con il tuo session o access token — non la chiave relay sk-orca-…. Solo il traffico relay /v1/* usa la chiave relay.
1

Registra i tuoi MCP server dietro il gateway

Connetti ogni server così i suoi tool sono pubblicizzati sotto un unico endpoint sottoposto ad audit. La registrazione è Developer+.
2

Imposta un verdetto di default e regole sulla superficie mcp

Scrivi regole con tool_name_glob e args_match così le chiamate rischiose si risolvono in deny, sanitize o pending_approval. Vedi il riferimento delle regole del firewall.
3

Revisiona le skill in quarantena

Qualsiasi cosa auto-rilevata sta in quarantine finché un revisore (Developer+) non l’approva. Leggi prima la banda e le findings.
4

Rollout in shadow, poi enforce

Usa le modalità di applicazione per far girare nuove regole in shadow, osserva gli eventi di audit, e passa a enforcing una volta che i verdetti sembrano giusti.
Le letture (impostazioni, policy, tool scoperti, anomalie) sono aperte a qualsiasi Member; ogni scrittura è Developer+. Leggere il testo in chiaro di una chiave firewall-gateway è Developer+.

​
Correlati

Firewall: MCP Server

Il riferimento completo del gateway MCP — registrazione, probing, dispatch.

Firewall: Skill

Passaggi dello scanner, scoring del rischio, e la derivazione della quarantena.

Avvelenamento dei tool MCP

Il modello di threat che la difesa dai rug-pull esiste per contrastare.

Limiti di egress

Scrivi regole deny host/CIDR per delimitare dove i tool possono arrivare.

Checklist di fiducia

La checklist end-to-end per fidarti di un MCP server.

Guardrails vs. Firewall

Quando si applica la policy sui contenuti e quando il firewall.