MCP tool poisoning e rug-pull

Un MCP server di terze parti o una skill installata è una dipendenza della supply chain. Due modalità di fallimento si distinguono:

• Poisoning — il server era malevolo fin dall’inizio. Il suo manifest sembrava benigno; il comportamento pericoloso era nell’implementazione del tool, non negli scope dichiarati.
• Rug-pull — lo hai considerato attendibile, poi è cambiato. È apparso un nuovo tool che l’operatore del server ha aggiunto silenziosamente, o una voce di un registro della community è stata dirottata e aggiornata per chiamare casa.

Entrambe le minacce condividono una causa radice: dopo che hai detto “mi fido di questo server”, i tuoi agent continuano a chiamare i suoi tool — inclusi quelli nuovi o modificati — senza ulteriore revisione.

​

1. Come il MCP tool poisoning raggiunge i tuoi agent

Ogni tools/call che il tuo agent emette viaggia attraverso il set di tool dichiarato del MCP server. Un server avvelenato o con rug-pull sfrutta quella fiducia in alcuni modi:

​

2. Le difese di OrcaRouter

​

2.1 Ogni tools/call viene valutato dal firewall prima di girare

Gli MCP server si connettono ai tuoi agent attraverso il gateway MCP del Firewall su /api/v1/firewall/mcp. Il gateway non inoltra una chiamata a tool finché il motore del firewall non l’ha valutata rispetto alla tua policy. Questo significa che la tua allowlist è la fonte di verità — non il manifest del tool del server. Se un rug-pull aggiunge shell.exec e la tua policy non ha nessuna regola che lo consente, il verdetto è deny e la chiamata non lascia mai il gateway. Il modello riceve un errore di tool (firewall deny: …) e può reagire; il tool aggiunto dall’attaccante è morto all’arrivo. Verdetti che il motore può restituire:

​

2.2 Le capability auto-rilevate vengono messe in quarantena finché non vengono esaminate

Quando un agent auto-installa una capability — o un rug-pull aggiunge nuovi tool che non erano presenti quando hai registrato il server — il Firewall auto-rileva la nuova capability fuori dall’hot path, sintetizza un manifest, lo scansiona e assegna una banda di rischio e una modalità di applicazione. In modo cruciale, le capability auto-rilevate vengono sempre messe in quarantena indipendentemente dal risultato della scansione: vengono trattenute in pending_approval finché un essere umano non le esamina. Così vengono contenuti i rug-pull. Un operatore non può aggiungere silenziosamente un nuovo tool e far sì che i tuoi agent inizino ad usarlo — quelle chiamate vengono trattenute finché non ispezioni e approvi la nuova capability.

​

2.3 La scansione delle skill assegna una banda di rischio e una modalità di applicazione

Ogni capability installabile — che tu l’abbia registrata o che il Firewall l’abbia auto-rilevata — viene passata attraverso lo scanner delle skill. Lo scanner esegue passaggi deterministici sul manifest e sugli scope dichiarati:

• prompt_injection — testo del manifest che tenta di dirottare le istruzioni.
• tool_creep — tool che il manifest usa ma non ha mai dichiarato.
• network_egress — host HTTP(S) al di fuori degli scope di rete approvati.
• fs_write_unsafe — accesso al filesystem in modalità di scrittura fuori da /tmp.

I risultati si aggregano in una banda di rischio (low / medium / high / critical) e una modalità di applicazione: Una skill in banda high viene messa in quarantena automaticamente; critical viene bloccata. Un singolo risultato error (es. tool_creep per un shell.exec non dichiarato) è sufficiente per bloccare una skill anche quando il suo punteggio numerico sembra basso. La modalità si irrigidisce solo — approvare una skill non allenta mai un block impostato da una scansione recente.

​

2.4 Le credenziali sono memorizzate cifrate

I segreti di autenticazione del server sono cifrati a riposo con una chiave dei segreti del workspace e iniettati dal gateway al momento del dispatch. Non raggiungono mai il modello, l’agent o gli argomenti della chiamata. Un server compromesso non può esfiltrare le tue chiavi API leggendo il proprio auth_json.

​

3. Cosa fare dopo un sospetto rug-pull

1. Disabilita immediatamente il server — un server disabilitato viene rimosso dal registro runtime e le sue credenziali non vengono mai decifrate. Usa PUT /api/workspace/firewall/mcp_servers con "enabled": false.
2. Ri-sonda per far emergere i cambiamenti — POST /api/workspace/firewall/mcp_servers/:id/probe esegue tools/list e restituisce qualsiasi nuovo tool apparso dall’ultima sonda.
3. Ri-scansiona il record della skill — POST /api/workspace/firewall/skills/:id/rescan ri-esegue lo scanner rispetto al manifest aggiornato. Se il verdetto peggiora a flagged o blocked, il Firewall emette un evento nel tuo feed.
4. Esamina la coda pending_approval — qualsiasi chiamata trattenuta dal rug-pull è in coda. Ispezionala e negala invece di approvarla in blocco.
5. Controlla il log delle chiamate — controlla il trail degli eventi del Firewall per le chiamate che sono passate prima che rilevasi il cambiamento.

​

4. Abbinare la scansione delle skill con le regole del firewall

La scansione delle skill e le regole del firewall sono complementari e si compongono:

• Una regola con tool_name_glob: community.* impostata su pending_approval garantisce che tu esamini ogni chiamata da un server con sorgente dalla community, indipendentemente dalla banda di rischio.
• Una skill in quarantena sovrascrive una regola allow — anche se la tua policy consente http.fetch in modo ampio, una skill in quarantena che lo possiede trattiene comunque la chiamata.
• Usa skill_name_glob in una regola per vincolare policy più restrittive ai server non attendibili senza influenzare le tue integrazioni di prima parte.

Vedi Firewall: MCP Server per il modello completo del gateway e Firewall: Skill per lo scanner e il riferimento della modalità di applicazione.

​

5. Minacce correlate

• Chiamate a tool pericolose — regole per bloccare azioni di tool distruttive o irreversibili indipendentemente dalla sorgente.
• Esfiltrazione di dati — regole egress che limitano dove le chiamate a tool possono inviare dati.
• Modello di threat — la superficie d’attacco completa che OrcaRouter è progettato a difendere.