Sandbox escape: 2.000 plugin MCP dentro Claude

Il Claude Marketplace apre con oltre 2.000 connettori

Il 27 settembre 2026 Anthropic ha aperto il Claude Marketplace: un catalogo pubblico che raccoglie plugin, connettori, agenti e prodotti costruiti su Claude. L'annuncio dichiara oltre 2.000 connettori e plugin già disponibili^[1], con integrazioni firmate Atlassian, Google, Microsoft e Salesforce.

Il catalogo ospita anche prodotti agentici di partner come CrowdStrike, Cursor, Harvey, Legora, Lovable e Snowflake. Accanto compaiono società di consulenza e integrazione: Accenture, Boston Consulting Group, Deloitte.

Il dato tecnico rilevante sta altrove, nel canale di pubblicazione. Chi sviluppa può creare connettori e plugin usando Model Context Protocol e Agent Skills. Le aziende che vendono software basato su Claude possono chiedere l'inserimento a catalogo, e la distribuzione diventa un percorso aperto a chiunque.

La forma ricorda uno store applicativo: scoperta, installazione, aggiornamento in pochi passaggi. È un salto rispetto alle integrazioni una a una, configurate a mano da un team interno.

Da protocollo di integrazione a canale di distribuzione

Fino a ieri MCP era un protocollo di integrazione: un modo per collegare un agente a strumenti e dati. Con un catalogo pubblico diventa anche un canale di distribuzione, e cambia la natura del rischio.

Il layer di protocollo resta il vero moat di questo mercato, più della performance del singolo modello.

Chi controlla la comunicazione tra agenti e strumenti controlla l'architettura di chi integra. Un catalogo gestito dal vendor del modello concentra due funzioni storicamente separate: lo standard tecnico e la vetrina commerciale. Questa concentrazione porta valore immediato di adozione e un debito di lock-in architetturale da misurare adesso.

OpenAI ha provato una strada simile con il proprio marketplace di app, con esiti modesti. Anthropic apre la pubblicazione a chiunque per evitare quell'epilogo, e accetta il compromesso che segue: più connettori, più codice terzo, più varianza di qualità.

Cosa esegue davvero un connettore installato

Un connettore installato è codice di terze parti che opera dentro il contesto dell'agente, con i permessi dell'utente che lo installa.

Le descrizioni degli strumenti esposti da un MCP server entrano nel prompt. Il modello le legge come istruzioni operative, e decide quando invocarle. Il confine tra dato e istruzione, già sottile nelle architetture RAG, qui diventa una scelta di design del fornitore del connettore.

Da qui discende la conseguenza pratica: l'auto-invocazione attiva rimuove il passaggio umano tra scoperta dello strumento ed esecuzione.

Un documento recuperato porta con sé le credenziali dell'utente. Lo stesso vale per un connettore: eredita la sessione, i token, l'accesso al file system o al repository che l'agente già possiede. Il prompt injection resta l'attacco più sottovalutato dagli enterprise AI team, e un catalogo aperto ne moltiplica i punti di ingresso.

I punti che l'annuncio lascia aperti

La copertura disponibile descrive il catalogo, i partner e il modello di pubblicazione. Mancano invece gli elementi che un team di sicurezza usa per decidere.

Tre in particolare restano fuori dal testo pubblico:

• processo di revisione dei connettori pubblicati da terzi: chi verifica il codice, con quali criteri, con quale frequenza
• versioning e provenienza: come si firma una release, come si blocca un aggiornamento automatico, come si legge il diff
• revoca e scoping dei permessi: come un'azienda ritira un connettore da tutta la flotta di agenti in un colpo solo

Questi tre punti separano un catalogo "disponibile" da un catalogo production-grade. La risposta va chiesta al vendor prima del rollout, in forma contrattuale.

La stessa domanda vale per gli store applicativi tradizionali, dove la revisione esiste da anni ed è comunque imperfetta. Un catalogo agentico nasce con un problema aggiuntivo: il codice pubblicato agisce, invece di limitarsi a mostrare contenuti.

La differenza pesa. Un'app malevola su uno store mobile chiede permessi a un utente che li vede; un connettore agentico eredita permessi già concessi, dentro una sessione automatica.

La sandbox escape è una classe di incidente

La sandbox escape è una classe di incidente, invece di un aneddoto isolato. Ogni ambiente di valutazione di un agente è, di fatto, una superficie di produzione.

Il principio operativo è secco: il sistema che un agente può raggiungere è il sistema che un agente può compromettere.

Un connettore scaricato da un catalogo pubblico estende quella raggiungibilità in modo silenzioso. L'agente acquisisce strumenti nuovi durante una sessione, e il perimetro cambia tra un run e il successivo. La risposta tecnica passa dall'identità: credenziali proprie per ogni agente, log nominativi, revoca immediata. L'approccio zero trust applicato agli agenti parte esattamente da qui (The Hacker News^[2]).

Quello che resta fuori dai log resta fuori dal controllo. Un connettore installato da uno sviluppatore sulla propria workstation, con il token aziendale in sessione, produce una catena di esecuzione che l'azienda scopre a posteriori.

Tre domande per gli enterprise AI team

Prima di autorizzare il catalogo dentro il perimetro, un team dovrebbe rispondere a tre domande operative.

1. Quale inventario esiste oggi dei connettori MCP già installati sulle workstation e nelle pipeline CI, con nome, versione e autore?
2. Quale identità usa ogni agente quando invoca uno strumento del catalogo, e quanto tempo serve per revocarla?
3. Quale controllo blocca l'aggiornamento automatico di un connettore approvato verso una versione ancora da revisionare?

Le tre risposte richiedono dati, invece di opinioni. Un team che le produce in mezza giornata ha già una governance funzionante; un team che impiega settimane misura in quel ritardo il proprio debito tecnico.

La maggior parte delle architetture in produzione tratta il contenuto recuperato come input fidato. Un catalogo di 2.000 elementi rende quella scelta costosa, perché ogni voce aggiunge un autore, una supply chain e un ciclo di rilascio esterni al controllo aziendale.

I sistemi multi-agente privi di circuit breaker espliciti falliscono a cascata: l'output di un agente diventa l'input del successivo, e la validazione indipendente manca. Aggiungere strumenti di terzi a quella catena amplifica il fenomeno.

Trappola o vantaggio competitivo

Il verdetto tecnico è duplice, e vale la pena separarlo per ruolo.

• CTO: rivedere la policy di installazione degli strumenti agentici, oggi spesso lasciata al singolo sviluppatore
• Head of Engineering: adottare una allowlist di connettori firmati, con pinning di versione dentro il repository
• CFO: il costo di integrazione scende, il costo di audit e incident response sale; il budget va rifatto su entrambe le voci
• Technology Procurement Committee: chiedere in contratto SLA di revisione, notifica di compromissione e diritto di revoca centralizzata

Sul piano dell'adozione il catalogo è un vantaggio reale: riduce il lavoro di integrazione, standardizza la scoperta degli strumenti e porta fornitori seri dentro un ambiente unico. Questa parte regge l'uso quotidiano, e va riconosciuta.

Sul piano della sicurezza il catalogo sposta il rischio a monte, verso una supply chain che l'azienda eredita invece di costruire. La security posture dei sistemi AI viaggia con due o tre anni di ritardo rispetto alla maturità dell'infrastruttura, e un canale di distribuzione allarga quella distanza.

Resta un punto di linguaggio che pesa sulle decisioni. Parlare di agenti "canaglia" sposta la responsabilità dal sistema verso una figura immaginaria, come argomenta questa analisi critica (Eoin Higgins^[3]). Un connettore che compie un'azione dannosa esegue codice scritto da qualcuno, dentro un perimetro autorizzato da qualcuno.

La decisione per il prossimo planning cycle è semplice nella forma: trattare il Claude Marketplace come un repository di dipendenze, con le stesse regole di un package manager. Inventario, firma, pinning, revoca. Il resto è fiducia, e la fiducia entra male nei log.