Sicurezza MCP: le 6 migliori piattaforme enterprise del 2026

Runlayer è la migliore piattaforma di sicurezza MCP in assoluto per gli agenti enterprise nel 2026. Ma dal 22 agosto la regola d'acquisto è cambiata: la roadmap di MCP ha portato l'identità degli agenti e l'autorità delegata tra le priorità. Delle sei piattaforme selezionate, nessuna pagina prodotto pubblica esaminata cita tutti e quattro gli elementi della roadmap e nessuna pubblica un prezzo in dollari. Vince quindi il pilot che dimostra identità, perimetro dei privilegi e verificabilità prima della firma del procurement.

Le migliori piattaforme di sicurezza MCP in sintesi

Runlayer è al primo posto perché riunisce un catalogo governato, policy sensibili all'identità fino al singolo account agente e al singolo tool, ispezione a runtime e audit di ogni richiesta su oltre 300 client AI. Proofpoint è l'acquisto più solido per le security operations quando rilevare gli MCP shadow e ricostruire le transazioni conta più dell'adozione da parte dei dipendenti. Stacklok è la scelta giusta quando Kubernetes e il self-hosting non sono negoziabili.

Prezzi e funzionalità riportati nel confronto sono stati verificati sulle pagine online dei vendor il 24 agosto 2026. «Preventivo personalizzato» non è un modo elegante per nascondere una stima: significa che, nelle pagine di prodotto o di pricing esaminate, il vendor non pubblicava alcun importo in dollari.

La regola decisionale è semplice: è il confine di controllo a determinare la piattaforma. Un catalogo sterminato di server non compensa l'incapacità di identificare l'attore, restringere il perimetro dei tool, controllare il risultato, revocare l'accesso e ricostruire l'azione dopo un incidente.

Perché dal 22 agosto 2026 è cambiata la regola d'acquisto

La prossima piattaforma MCP enterprise deve proteggere l'agente come attore autonomo, non come semplice sessione utente a cui è stata aggiunta un'automazione. La nuova roadmap di MCP spiega che l'autorizzazione attuale ruota attorno a una persona che approva l'accesso nel browser. Nel frattempo, però, aumentano gli agenti cloud dotati di identità propria, capaci di operare per utenti assenti o di delegare a sotto-agenti un'autorità più limitata.

Model Context Protocol, o MCP, è l'interfaccia comune con cui un'applicazione AI scopre e richiama tool, fonti dati e servizi. Questa comodità trasforma il modello: non si limita più a rispondere, ma agisce. Un tool di consultazione in sola lettura, un connettore CRM con permessi di scrittura e uno strumento per il deployment in produzione possono apparire allo stesso agente come funzioni richiamabili, pur avendo impatti aziendali del tutto diversi.

La roadmap indica quattro elementi fondamentali per il prossimo modello di autorizzazione:

• DPoP, ovvero Demonstrating Proof of Possession, associa un token a una chiave crittografica, rendendo più difficile riutilizzare un token copiato.
• Workload Identity Federation consente a un workload in esecuzione di scambiare l'identità della propria piattaforma con un accesso di breve durata, invece di conservare una chiave API incollata nella configurazione.
• ID-JAG, acronimo di Identity Assertion JWT Authorization Grant, permette al provider di identità aziendale di partecipare al flusso di autorizzazione MCP.
• Lo scambio standard dei token trasferisce l'autorità tra domini di sicurezza senza trasformare un unico segreto di lunga durata nella chiave universale.

L'estensione esistente Enterprise-Managed Authorization centralizza già l'accesso degli utenti presso il provider di identità aziendale. Il client ottiene un ID-JAG e lo scambia con un token di accesso MCP, mentre gruppi, ruoli e policy di accesso condizionale restano sotto il controllo dell'impresa. L'estensione è però facoltativa, il supporto varia da client a client e la roadmap affronta un problema più complesso: un workload autonomo deve dimostrare sia chi è sia quale autorità limitata sta esercitando e per conto di chi.

Da qui nasce il divario di delega: una piattaforma può autenticare un account agente senza riuscire a provare che uno specifico sotto-agente fosse autorizzato a compiere quella precisa azione, per quello specifico utente e in quel preciso momento. Account di servizio condivisi, autorizzazioni OAuth copiate e token statici nascondono la catena. Un log delle transazioni può mostrare quale gateway ha inoltrato la chiamata, ma non il mandato umano, il perimetro delegato o la prova crittografica che la giustificavano.

Questo cambia anche la voce di budget. Un gateway scelto soltanto per allowlist e log del traffico potrebbe richiedere, con la crescita dei workload autonomi, un livello di identità separato, un gestore di segreti, una sandbox e un prodotto di discovery. Il preventivo più basso può trasformarsi nell'architettura più costosa se lascia aperto il divario di delega.

Va chiarito un punto: al 24 agosto 2026 nessuna delle sei pagine prodotto esaminate citava pubblicamente DPoP, Workload Identity Federation, ID-JAG o lo scambio standard dei token. Non significa che i vendor siano privi di piani riservati o funzionalità non pubblicate. Significa che, finché un pilot non dimostra il flusso esatto, ogni promessa va considerata allineamento alla roadmap, non conformità al protocollo.

Come sono state scelte le piattaforme di sicurezza MCP

La shortlist privilegia i prodotti che trattano il controllo di MCP in azienda come un problema di sistema operativo: inventario, identità, confini di esecuzione, policy a runtime e prove. Uno scanner capace di trovare codice rischioso può essere utile, così come un gateway API generico può instradare il traffico; nessuno dei due, però, entra tra i primi sei senza un enforcement continuo e specifico per MCP.

I criteri partono dalle linee guida NSA sulla sicurezza MCP di maggio 2026 e vi aggiungono la nuova roadmap dell'identità:

• Discovery: individuare server, client, tool e versioni, sia autorizzati sia shadow.
• Identità e delega: distinguere una persona, un account agente, un workload e un sotto-agente delegato.
• Autorizzazione: applicare il principio del privilegio minimo a livello di server, tool, risorsa e azione.
• Controllo della supply chain: approvare i progetti supportati, registrarne la provenienza e correggere i server vulnerabili.
• Confini di esecuzione: isolare i tool in sandbox e arrestare i movimenti laterali dopo una compromissione.
• Ispezione a runtime: validare i parametri e trattare ogni output concatenato come input non attendibile.
• Revoca e risposta: rimuovere rapidamente l'accesso e bloccare una chiamata non sicura mentre è in corso.
• Evidenze: registrare parametri, identità, decisioni delle policy ed esiti nel SIEM esistente, il sistema di gestione delle informazioni e degli eventi di sicurezza.

Anche la NSA avverte che i proxy consapevoli di MCP sono ancora pochi e in fase di maturazione. Per questo nessun prodotto riceve un giudizio perfetto nel confronto: un gateway è un punto di controllo, non un programma di sicurezza completo.

Il confronto è stato condotto sulle pagine online. In questa analisi sono state controllate le pagine di prodotto, documentazione e pricing dei vendor; i calcoli riportati più avanti derivano dai pacchetti dichiarati e da ipotesi di pianificazione esplicite. Sono stati esclusi i prodotti la cui documentazione pubblica descriveva soltanto scansione, test, gestione dei segreti o routing generico, senza prove sufficienti di un piano di controllo enterprise.

Sei valutazioni complete e tre esclusioni motivate rendono la shortlist subito utilizzabile per decidere: ogni candidato deve rendere visibili il proprio limite operativo, l'onere di deployment, la logica di prezzo e la prova da richiedere. Un elenco di loghi più lungo nasconderebbe questi compromessi.

1. Runlayer: la migliore per un rollout governato degli agenti enterprise

Runlayer è la scelta migliore quando dipendenti e agenti di produzione usano molti client AI, ma la sicurezza ha bisogno di un unico percorso governato verso i tool. MCP Gateway delimita l'accesso in base a utente, gruppo, ruolo, account agente, client, connettore, tool, risorsa, stato OAuth, rete e condizione di runtime prima dell'esecuzione di una chiamata. Tra i prodotti del gruppo è quello che, pubblicamente, si avvicina di più al nuovo problema dell'identità, anche se le pagine di Runlayer non dichiarano ancora il supporto al futuro lavoro della roadmap su DPoP, federazione o ID-JAG.

Ideale per: aziende che standardizzano l'accesso MCP tra team di engineering, sicurezza, IT, operations e business.
Elemento distintivo: un unico catalogo e piano di policy per oltre 300 client AI, con attore, client, connettore, tool, esito della policy, metadati di sicurezza e risultato disponibili per la verifica.
Prezzo: preventivo personalizzato; nelle pagine prodotto verificate non compaiono prezzi in dollari né una tabella dei piani.
Prova gratuita: nessuna prova self-service pubblicizzata; il percorso pubblico è Book a Demo.

Runlayer prevale perché considera la governance MCP un'infrastruttura per l'adozione, non un'appliance di sicurezza aggiunta a rollout concluso. Un dipendente può richiedere dal catalogo un connettore autorizzato; un amministratore può approvarlo per un gruppo, un account agente, un client, un tool o una risorsa; il gateway verifica quindi lo stato OAuth e della sessione, applica la policy, analizza la chiamata e ne registra l'esito. La sequenza serve sia al platform team che vuole abilitare gli agenti sia al team di sicurezza che deve contenerli, anche quando il modo di confezionare funzionalità riutilizzabili cambia tra Notion Skills e Claude Skills API.

Un caso concreto è quello di un'azienda SaaS di medie dimensioni: gli sviluppatori usano Cursor e Claude Code, le operations lavorano con ChatGPT e un agente di produzione aggiorna Salesforce e Jira. La stessa frammentazione dei client ricorre nei browser creati per gli agenti AI: la configurazione locale moltiplica i sistemi di policy e le tracce di audit. Runlayer offre a tutti questi client lo stesso connettore approvato e lo stesso confine di policy, senza imporre loro una nuova interfaccia.

Il limite dichiarato riguarda la futura prova della delega. «Account agente» è un soggetto di controllo utile, ma un pilot enterprise deve ancora dimostrare se la piattaforma distingue l'autorità propria dell'agente da quella delegata da un utente, restringe tale delega per un sotto-agente, vincola i token contro il replay e revoca la catena senza disabilitare ogni workload che condivide il connettore.

Un pilot pratico per Runlayer

La prima classificata merita il piano di pilot più concreto. I passaggi seguenti riprendono il workflow documentato di catalogo, approvazione, policy, client e audit, senza fingere che il prodotto sia stato installato durante questa analisi.

1. 1

   Registrare tre livelli di rischio

   Aggiungere un server MCP interno in sola lettura, un connettore SaaS con permessi di scrittura e un tool capace di un'azione irreversibile. Mantenere visibili nel catalogo i proprietari dei server e le classificazioni dei dati.

2. 2

   Associare ogni attore

   Collegare il provider di identità aziendale, quindi creare soggetti di policy separati per un utente umano, un account agente di produzione e un'identità di test per il sotto-agente. Scartare qualsiasi configurazione che ripieghi su un unico account di servizio condiviso.

3. 3

   Restringere il perimetro sotto il livello server

   Consentire all'utente di vedere il connettore, permettere all'agente principale di richiamare tool selezionati e negare al sotto-agente il tool irreversibile. Aggiungere condizioni di rete e runtime nei punti in cui il workflow attraversa un confine di fiducia.

4. 4

   Collegare due client differenti

   Instradare la stessa funzionalità governata attraverso un client per sviluppatori e uno rivolto al business. Verificare che la policy segua identità e contesto, non un file di configurazione locale.

5. 5

   Dimostrare la catena delle evidenze

   Per una richiesta consentita e una negata, esportare attore, client, connettore, tool, esito della policy, metadati di sicurezza e risultato. Revocare poi l'accesso a livello di identità e verificare che la chiamata successiva fallisca senza attendere la scadenza di un token di lunga durata nella cache.

Il livello 1Password va collocato qui, non sopra il gateway

1Password è il complemento più solido per le credenziali in questa categoria: risolve il problema della loro custodia senza presentarsi come piano di policy MCP. Con l'integrazione attuale di Runlayer, un amministratore può inserire un riferimento op:// al posto di una chiave in chiaro; Runlayer risolve il valore effettivo al momento della connessione tramite l'SDK di 1Password, lo usa per la richiesta e non conserva né il valore grezzo né una cache su disco.

Anche la rotazione è utile sul piano operativo. A ogni recupero l'integrazione confronta gli hash SHA-256, registra gli eventi di accesso e rotazione del segreto senza annotarne il valore e usa la credenziale aggiornata alla connessione successiva. La pagina dei prezzi di 1Password presenta Unified Access con un preventivo su misura e include Enterprise Password Manager, Device Trust, SaaS Manager e Privileged Access.

Il limite è altrettanto importante: l'iniezione delle credenziali, da sola, non stabilisce l'autorità delegata. Anche un segreto protetto può autorizzare un agente con privilegi eccessivi. Runlayer resta responsabile delle policy su attore, tool e runtime; 1Password impedisce che la credenziale upstream finisca nel database del gateway.

2. Proofpoint AI MCP Security: la migliore per discovery e analisi forense degli audit

Proofpoint AI MCP Security è la scelta migliore quando il programma è guidato dall'organizzazione di sicurezza e non si può dare per scontato che il traffico MCP attraversi già un gateway autorizzato. Riunisce shadow discovery, hardening dei server, un registro verificato, policy centralizzate, ispezione dei contenuti e analisi forense delle transazioni in un'unica proposta. Il perimetro è più ampio di quello di un proxy e l'impostazione è più orientata alla sicurezza rispetto al piano di controllo di Runlayer, nato anzitutto per favorire l'adozione.

Ideale per: imprese che, prima di approvare un percorso standard, devono trovare gli MCP non gestiti presenti su laptop, cloud, host di terze parti e gateway esistenti.
Elemento distintivo: ricostruzione completa della transazione, dall'attore iniziale attraverso applicazione, modello e server MCP, con esportazione OpenTelemetry verso il SIEM e lo stack di osservabilità esistenti.
Prezzo: preventivo personalizzato; la pagina verificata non pubblica prezzi in dollari né una tabella dei piani.
Prova gratuita: nessuna prova pubblica; per procedere occorre richiedere una demo.

Il vantaggio più netto di Proofpoint è una discovery collegata alla remediation. La piattaforma dichiara di poter individuare autenticazione o cifratura mancanti, host remoti non autorizzati e server locali non protetti, per poi instradare il traffico verso percorsi governati. Per una banca che trova configurazioni MCP sparse sui computer degli sviluppatori, fin dal primo giorno questo vale più di un altro catalogo di tool.

Il registro e il workflow di packaging riducono il lavoro sulla supply chain, ma non lo eliminano. Proofpoint dichiara oltre 800 server già verificati e la possibilità di confezionare un server in un container protetto in meno di 15 minuti. L'impresa deve comunque stabilire se siano accettabili i tool del server, i privilegi upstream, il maintainer, il processo di aggiornamento e la zona dati. Inserire una funzionalità pericolosa in un container ne riduce il rischio di esecuzione; non la rende adatta all'uso.

L'analisi forense è il motivo per pagare il sovrapprezzo della suite, se il pilot ne conferma il valore. La piattaforma descrive una catena che acquisisce chi ha avviato l'interazione, quale applicazione e modello l'hanno elaborata, quali server sono stati chiamati, anomalie, escalation dei privilegi ed esportazione OpenTelemetry. Va chiesto di ricostruire dal SIEM una chiamata negata e una chiamata distruttiva autorizzata, senza aprire la console Proofpoint. Se le evidenze si interrompono al gateway, la promessa di audit resta una promessa da dashboard.

Il limite è la precisione dell'identità. Pubblicamente, Proofpoint descrive OAuth 2.0, controllo dell'accesso per utenti e agenti ed enforcement delle policy. Non mostra però il nuovo flusso per l'identità dei workload o la delega ai sotto-agenti. Occorre esigere soggetti distinti per utente, agente e sotto-agente, quindi provare revoca e replay del token invece di accettare «autorizzazione basata sull'agente» come dimostrazione.

3. Stacklok Enterprise: la migliore per ambienti Kubernetes self-hosted

Stacklok Enterprise è la migliore piattaforma per un'organizzazione che usa già Kubernetes e vuole estendere a MCP i controlli esistenti su runtime, identità, rete e GitOps. Il core open source, ToolHive, offre il percorso di valutazione; il prodotto enterprise aggiunge un livello operativo rafforzato e il supporto. Nella shortlist è il modello di responsabilità più chiaro per deployment in private cloud, on-premises o sottoposti a una regolamentazione rigorosa.

Ideale per: platform team con Kubernetes in produzione, provider di identità consolidati, policy di rete e osservabilità.
Elemento distintivo: i server MCP sono eseguiti come pod, i namespace diventano confini di fiducia e i ServiceAccount Kubernetes insieme ai claim OIDC vengono associati ai permessi MCP.
Prezzo: ToolHive è open source con licenza Apache 2.0; Stacklok Enterprise è disponibile su preventivo personalizzato, dopo una demo.
Prova gratuita: ToolHive può essere scaricato e valutato; la pagina prodotto verificata non pubblicizza una prova Enterprise.

Il punto di forza di Stacklok è la continuità architetturale. Il platform team può trattare un server MCP come qualsiasi altro workload, assegnandogli namespace, percorso di ingresso, policy di rete, service account, log e cronologia dei deployment. La terminologia dell'identità serve a poco se il confine di sicurezza scompare nel processo del tool; Kubernetes mette a disposizione controlli che il team sa già verificare e gestire.

Un caso concreto è quello di un'azienda di software sanitario che deve mantenere nel proprio ambiente i dati delle chiamate ai tool. La pagina di Stacklok indica che registry, runtime, gateway e portal poggiano su Kubernetes, mentre ServiceAccount e claim OIDC vengono associati ai permessi MCP. OpenTelemetry, lo standard aperto per tracce e metriche, invia l'attività allo stesso canale di osservabilità — Grafana, Datadog, Splunk o un'altra soluzione — già gestito dall'azienda.

ToolHive offre inoltre il modo più trasparente di iniziare senza acquistare una promessa. La licenza Apache 2.0 consente al team di esaminare ed eseguire il core, registrare un piccolo gruppo di server approvati e capire l'onere operativo prima di un contratto enterprise. La valutazione deve includere il comportamento durante gli upgrade, la rotazione dei certificati, la distribuzione delle policy, la firma dei server, il contenimento di un'uscita dal container e il rollback dopo un incidente.

Lo stesso punto di forza, rovesciato, è anche il limite: Stacklok non sostituisce un platform team. Una startup con un solo agente ospitato e senza esperienza Kubernetes non dovrebbe adottare un cluster soltanto per usare MCP. Una licenza apparentemente a costo zero può diventare un oneroso problema di gestione interna quando l'organizzazione deve costruirvi attorno deployment affidabile, patching, supporto e discovery.

Serve anche una risposta complementare per il traffico shadow. Un cluster governato può essere eccellente mentre gli sviluppatori continuano a eseguire server locali dai client AI al di fuori del cluster. Il pilot deve mostrare come la discovery su endpoint o rete individua questi percorsi e in che modo le policy li convogliano verso il gateway approvato.

4. Operant AI: la migliore per test rapidi e copertura dall'endpoint al cloud

Operant AI è la piattaforma più rapida da valutare perché offre ai clienti qualificati una sandbox di 7 giorni, senza carta di credito e in modalità di sola osservazione per impostazione predefinita. La copertura si estende dagli endpoint dei dipendenti agli agenti di produzione, fino al traffico MCP e dei modelli: è quindi utile quando gli agenti di coding sui laptop e quelli nel cloud formano un'unica superficie d'attacco connessa. La piattaforma documenta inoltre l'enforcement delle identità non umane, o NHI, invece di limitare le policy agli utenti umani.

Ideale per: organizzazioni che vogliono valutare insieme agenti di coding sugli endpoint, agenti cloud, server MCP e applicazioni AI.
Elemento distintivo: una sandbox di 7 giorni senza carta di credito dà accesso all'intera piattaforma; il costo dei pilot a pagamento viene detratto integralmente dall'abbonamento del primo anno.
Prezzo: preventivo su misura in base a endpoint, agenti e profondità della governance; sono disponibili formule mensili, annuali, a volume e pluriennali.
Prova gratuita: sandbox predisposta per 7 giorni per i clienti qualificati, in modalità di sola osservazione per impostazione predefinita.

I pacchetti Operant sono insolitamente chiari, anche senza importi in dollari. Pro include il monitoraggio della shadow AI di Endpoint Protector e il monitoraggio a runtime di Agent Protector, mentre Cloud MCP Gateway e AI Gatekeeper sono add-on. Scale comprende le versioni complete di Endpoint Protector e Agent Protector, oltre a Cloud MCP Gateway; AI Gatekeeper resta un add-on. Enterprise riunisce tutte e quattro le aree di prodotto e aggiunge difese personalizzate, scalabilità multi-regione, SSO, SCIM, template per la gestione dei dispositivi, accesso tramite API e webhook, oltre a deployment VPC, on-premises e air-gapped.

Questa struttura rende evidente quando occorre salire di livello. Se il requisito è soltanto osservare le prime attività di endpoint e agenti, Pro può aprire la conversazione. Nel momento in cui diventa obbligatorio applicare centralmente i controlli sul traffico MCP, il confronto corretto parte da Scale oppure da un preventivo Pro con l'add-on del gateway. Un deployment privato regolamentato porta invece a Enterprise.

La sandbox di 7 giorni basta per una verifica mirata, non per un rollout enterprise. I clienti approvati ricevono un'istanza completamente predisposta, con tutti i moduli e le integrazioni sbloccati per la durata della prova. Occorre portare un client di coding, un agente cloud e tre server MCP. Si parte in modalità di sola osservazione e si registra il grafo rilevato; poi si abilita il blocco per un server non attendibile, un caso di tool poisoning e un percorso con dati sensibili. Infine si verifica che l'avviso conservi il contesto di identità e azione necessario alla risposta.

Il limite è la sovrapposizione, insieme all'opacità del prezzo. Un'azienda che già paga per endpoint discovery, DLP, sicurezza API, un gateway AI e un SIEM potrebbe duplicare diversi controlli. Occorre far quotare il bundle Operant rispetto ai controlli che sostituisce, chiedendo di separare nel preventivo endpoint, agenti di produzione, gateway MCP, tipi di dati, retention, modalità di deployment ed eccedenze.

5. Netskope One Agentic Broker: la migliore per chi usa già Netskope DLP

Netskope One Agentic Broker è la soluzione più adatta quando Netskope gestisce già i controlli aziendali per la sicurezza web e la prevenzione della perdita di dati. Individua server MCP, client, tool, risorse e richieste di prompt; valuta i server pubblici tramite Cloud Confidence Index, applica policy di accesso e registra le attività a livello di tool. Il motivo per acquistarlo è la continuità dei controlli con Netskope One DLP, non la vittoria in un confronto isolato tra funzionalità MCP.

Ideale per: clienti Netskope esistenti che governano l'uso di MCP pubblici e remoti da client di coding, chat e sviluppo.
Elemento distintivo: valutazione del rischio dei server pubblici e policy DLP consapevoli di MCP all'interno di uno stack consolidato per l'accesso sicuro.
Prezzo: ordine personalizzato per il cliente, con licenze basate su utenti monitorati, pacchetti di transazioni o entrambi.
Prova gratuita: nessuna prova pubblica indicata nella pagina prodotto verificata.

Il vantaggio per chi acquista Netskope è poter sfruttare policy e contesto dei dati già esistenti. Un'azienda che classifica già i dati sensibili e applica l'accesso web tramite Netskope può estendere quel controllo a MCP senza esportare il traffico dei tool verso un nuovo motore DLP. Questo può abbreviare la progettazione delle policy e l'instradamento degli incidenti, attività che spesso costano più del gateway.

Le condizioni di licenza meritano più attenzione della pagina delle funzionalità. Una licenza utente include una quota mensile fissa di transazioni; pacchetti di transazioni possono integrare o sostituire le licenze per utente. Le transazioni inutilizzate non vengono riportate. Netskope invia una notifica all'80 percento della quantità prevista dalla licenza e le condizioni specificano che, se la quota viene superata, il servizio può essere sospeso per il resto del mese.

Uno scenario di pianificazione mostra perché l'unità di misura conta. 1,000 utenti monitorati x 50 transazioni MCP di richiesta-risposta per giorno lavorativo x 22 giorni lavorativi equivalgono a 1.1 milioni di transazioni al mese. Sono ipotesi di carico, non dati d'uso osservati. Vanno sostituite con i risultati del pilot, dimensionando poi sul mese di picco anziché sulla media: la capacità inutilizzata va persa, mentre un'eccedenza può fermare il servizio.

La dipendenza da DLP è un'altra voce di budget. La documentazione tecnica Netskope indica che la licenza add-on è necessaria per creare e applicare policy DLP. Un preventivo che include Agentic Broker senza DLP può dimostrare visibilità, ma omettere il controllo che ha motivato la scelta di Netskope.

Il limite è il perimetro. La pagina prodotto mette in risalto server MCP pubblici e traffico dei client; la documentazione copre invece server remoti e un inventario che include anche implementazioni locali e containerizzate. Nel pilot vanno dimostrati discovery locale, routing dei server privati, identità autonoma dei workload e continuità delle policy al di fuori di un browser o di un dispositivo del dipendente.

6. Salt Agentic Security Platform: la migliore per ambienti ricchi di API

Salt Agentic Security Platform è la scelta più adatta quando le azioni agentiche a rischio più elevato attraversano già un vasto ambiente API mappato male. Agentic Security Graph collega agenti, server MCP, tool e API, quindi sovrappone discovery, analisi della postura, policy e rilevamento a runtime all'intero percorso dell'azione. Nella shortlist offre la visione più ampia dalle API agli agenti, ma non è l'acquisto più immediato per chi cerca un gateway MCP pronto da inserire.

Ideale per: banche, retailer, piattaforme SaaS e altre imprese in cui il rischio degli agenti è inseparabile dalle API shadow, interne, dei partner e pubbliche.
Elemento distintivo: un solo grafo mappa ogni agente, server MCP e API, con il contesto di postura e runtime lungo tutto il livello d'azione.
Prezzo: preventivo personalizzato; nelle pagine verificate non compaiono prezzi in dollari né una tabella pubblica dei piani.
Prova gratuita: nessuna condizione pubblica per una prova self-service; Try Salt porta alla richiesta di una demo.

L'elemento più recente a sostegno di Salt è la sua libreria di policy. Il 20 luglio 2026 l'azienda ha dichiarato che Policy Hub aveva raggiunto 100 policy predefinite: 61 si attivavano automaticamente, più di 12 riguardavano AI e sicurezza agentica ed erano presenti associazioni con otto framework di conformità. Le policy coprono configurazione MCP, autorizzazione degli agenti, sicurezza dei dati, OAuth, architettura API, rischio di terze parti e comportamento a runtime.

Un caso concreto è quello di un retailer il cui agente di assistenza può emettere rimborsi tramite un'API interna. Il server MCP potrebbe essere configurato correttamente, mentre l'API sottostante per i rimborsi accetta privilegi eccessivi o sequenze anomale. Il grafo di Salt è progettato per collegare agente, tool MCP, API, dati e comportamento, così che il team di sicurezza possa vedere il percorso dell'azione anziché il solo prompt.

Questo spiega anche il sesto posto. Il materiale pubblico è esplicito su discovery, postura, policy, rischio API e protezione a runtime, ma lo è meno rispetto a Runlayer, Proofpoint o Stacklok sul workflow quotidiano del piano di controllo MCP: approvazione del catalogo, routing del gateway, iniezione delle credenziali, policy per tool e distribuzione ai client. Per un cliente di sicurezza API può essere il complemento giusto. Per una nuova piattaforma MCP, una demo deve provare questi meccanismi prima di considerare il grafo equivalente al gateway.

Quale piattaforma scegliere in ogni scenario

La scelta parte dal confine più difficile da controllare nell'ambiente aziendale; a parità di condizioni, decide l'identità.

Scegliere Runlayer quando dipendenti e agenti usano molti client e l'azienda ha bisogno di un catalogo autorizzato più semplice delle configurazioni shadow. Vince quando abilitazione, account agente, privilegi a livello di tool, controlli a runtime e audit devono convivere nello stesso piano operativo.

Scegliere Proofpoint quando la sicurezza parte da un ambiente sconosciuto. Discovery, remediation, hardening dei server, ispezione dei contenuti e analisi forense delle transazioni ne fanno il primo acquisto più solido per programmi dedicati agli MCP shadow e guidati dagli audit.

Scegliere Stacklok quando MCP deve essere eseguito nell'ambiente Kubernetes aziendale e il platform engineering gestisce già identità, policy di rete, GitOps e osservabilità. Il core open source è anche il modo migliore per esaminare il runtime prima di un contratto commerciale.

Scegliere Operant quando occorre valutare insieme agenti di coding dei dipendenti, agenti cloud, server MCP e applicazioni AI. La sandbox pubblica di 7 giorni offre il percorso di verifica con meno attriti; i piani Scale ed Enterprise includono i livelli di enforcement MCP più rilevanti.

Scegliere Netskope quando Netskope protegge già web, cloud e dati sensibili. La scelta cambia se DLP non è già a budget, la capacità transazionale è imprevedibile o il runtime è soprattutto privato e autonomo anziché pubblico e orientato agli utenti.

Scegliere Salt quando MCP rappresenta un segmento di un grafo di azioni API più ampio. La scelta cambia se l'urgenza è avere un catalogo approvato, un broker di credenziali e un gateway MCP rivolto ai client, anziché postura API e comportamento a runtime.

Una prova può ribaltare ogni decisione: chiedere al vendor di mostrare un agente che opera per conto di un utente, delega un compito più ristretto a un sotto-agente, richiama un tool consentito, riceve un rifiuto per un tool più potente e lascia una catena di evidenze completa e revocabile. Se la piattaforma non riesce a farlo, discovery, dashboard e dimensioni del catalogo non colmano il divario di delega.

Quanto costa una piattaforma di sicurezza MCP enterprise

Il mercato pubblico non permette di stilare una classifica in base al prezzo di listino. Tra Runlayer, Proofpoint, Stacklok Enterprise, Operant, Netskope e Salt, al 24 agosto 2026 nessuna delle sei pagine pubbliche di prodotto o pricing esaminate mostrava un prezzo in dollari. Stacklok fa eccezione soltanto per il core open source: ToolHive si può scaricare con licenza Apache 2.0, mentre la distribuzione enterprise segue comunque un percorso commerciale.

Le unità usate nei preventivi non sono confrontabili direttamente:

• Runlayer, Proofpoint, Stacklok e Salt partono da demo o perimetri enterprise personalizzati.
• Operant stabilisce il prezzo in base a endpoint, agenti di produzione, prodotti, profondità del deployment e requisiti di governance.
• Netskope applica licenze per utenti monitorati, pacchetti di transazioni o entrambi, con DLP separato.
• 1Password propone Unified Access tramite un preventivo su misura per la piattaforma di identità che affianca il gateway.

Ogni proposta va normalizzata sullo stesso carico annuale: identità, agenti, server MCP, tool, transazioni mensili, retention, ambienti, regioni dei dati, modello di deployment, supporto, add-on necessari e gestione delle eccedenze. Una tariffa base ridotta ma priva della licenza DLP o vincolata da un tetto alle transazioni non è la piattaforma meno costosa.

Quando i prezzi dei vendor sono riservati, il modello build-versus-buy offre un tetto utile. Vanno impiegati i costi orari complessivi della propria organizzazione: quello che segue è un modello di pianificazione, non un prezzo di mercato.

• Piano di controllo interno: due ingegneri x otto settimane x 40 ore x $150 l'ora = $96,000 di lavoro interno, prima del supporto continuativo.
• Pilot del vendor: quattro settimane x (30 ore di platform engineering più 10 ore di security engineering) x $150 l'ora = $24,000 di lavoro interno, prima della licenza.
• Punto di pareggio della licenza nel primo anno: $96,000 meno $24,000 = $72,000.

Il modello esclude volutamente da entrambi i lati runtime cloud, scanner di terze parti, gestione dei segreti, DLP, storage SIEM e operations continuative. Questi costi vanno aggiunti in modo simmetrico. Un controllo non può essere conteggiato come risparmio del vendor se è già fornito da un altro prodotto esistente; allo stesso modo, una licenza open source gratuita non equivale a costi operativi nulli.

Questa è la conseguenza economica della nuova roadmap. Identità e delega sono ormai due prove distinte: un preventivo per il gateway che omette il livello di identità è incompleto. Il budget deve coprire l'intera catena dell'autorità, non soltanto il punto obbligato del traffico.

Le soluzioni da evitare

Spesso il prodotto sbagliato è semplicemente uno strumento utile a cui è stato assegnato il compito sbagliato.

MCPJam come controllo di sicurezza in produzione

MCPJam è un valido ambiente di test MCP, non il livello di enforcement a runtime richiesto da questa decisione d'acquisto. La sua pagina prezzi online ruota attorno a Inspector, debugger OAuth, logger JSON-RPC, registro, crediti di valutazione e collaborazione.

Il pricing è insolitamente trasparente: Free costa $0 al mese, con 200 crediti al giorno e 25 iterazioni di valutazione al giorno; Team costa $30 per postazione al mese con fatturazione annuale, con 10,000 crediti per postazione al mese e 5,000 iterazioni di valutazione al mese; Enterprise è personalizzato, con impegno annuale, SSO/SAML, RBAC personalizzato, retention degli audit, DPA e SLA.

MCPJam va usato per ispezionare, eseguire il debug e valutare i server prima del rollout. Crediti di test, SSO e SLA enterprise non dimostrano enforcement inline delle chiamate ai tool, identità dei workload, discovery di rete o contenimento a runtime.

Promptfoo MCP Proxy come intero piano di controllo

Promptfoo MCP Proxy è un controllo mirato e credibile per allowlist, accesso di applicazioni e utenti, monitoraggio delle attività, avvisi sui dati sensibili e policy centralizzate. Resta sotto le piattaforme in classifica perché la sua pagina MCP pubblica non documenta delega degli account agente, identità dei workload, sandbox, runtime governato per i server o i nuovi standard della roadmap.

L'offerta più ampia di Promptfoo comprende un piano Community Free Forever con un massimo di 10,000 probe di red teaming al mese, oltre ai piani Enterprise e On-Premise con prezzo personalizzato. È adatto quando servono red teaming e un proxy mirato. Non si può trasformare un proxy ristretto in un sistema operativo MCP enterprise senza dimostrare discovery, identità, confini di esecuzione e delega.

1Password Unified Access come sostituto del gateway

1Password Unified Access appartiene all'architettura, ma non va collocato nella casella del gateway. Gestisce identità, accessi privilegiati, attendibilità dei dispositivi, discovery SaaS, credenziali a runtime e audit attraverso un preventivo su misura. L'integrazione documentata con Runlayer mostra la corretta separazione: 1Password custodisce il segreto e lo risolve al momento della richiesta; Runlayer decide se l'attore e la chiamata al tool sono consentiti.

Acquistare soltanto il livello dei segreti lascia irrisolti inventario dei server, routing MCP, tool poisoning, validazione dei parametri, ispezione dei contenuti e policy per singolo tool. Acquistare soltanto il gateway può creare un altro database di segreti. La coppia è credibile proprio perché ciascun prodotto resta nel proprio ambito.

Checklist per un pilot di sicurezza MCP

Un vendor supera la prova soltanto se produce evidenze dell'azione, non una slide sulla funzionalità.

1. 1

   Individuare il percorso non autorizzato

   Posizionare un server locale, uno remoto e uno dietro il gateway approvato. La piattaforma deve trovare tutti e tre, oppure darne esplicitamente conto, e identificare client, tool, versione, proprietario e zona dati.

2. 2

   Separare utente, agente e sotto-agente

   Assegnare a ogni attore un'identità distinta. L'agente può ereditare un mandato limitato dell'utente; il sotto-agente deve ricevere una delega più ristretta. Scartare qualsiasi architettura che trasformi la catena in un unico token riutilizzabile.

3. 3

   Applicare i controlli al confine del tool

   Consentire un tool di lettura, autorizzare con condizioni un tool di scrittura e negare un tool irreversibile. Verificare che l'agente non possa aggirare il rifiuto passando da un client diverso, un alias del server o un tool concatenato.

4. 4

   Avvelenare entrambe le direzioni

   Inserire un'istruzione nella descrizione di un tool e un'istruzione malevola nel risultato di un tool. La piattaforma deve ispezionare i metadati in ingresso e l'output concatenato, non soltanto il prompt originale dell'utente.

5. 5

   Limitare l'esecuzione

   Tentare dal server un'azione imprevista su file, rete o processi. Verificare che sandbox e confini di rete fermino i movimenti laterali anche quando il motore delle policy non riconosce l'intento.

6. 6

   Rubare e riutilizzare un token

   Copiare un token di test e usarlo dal workload sbagliato o dopo la revoca. Chiedere come DPoP, federazione, scambio dei token, scadenza, destinatario e associazione alla chiave cambieranno il risultato con l'evoluzione della roadmap.

7. 7

   Ricostruire l'azione

   Esportare nel SIEM attore, utente delegante, client, agente, server, tool, parametri, decisione della policy, hash del risultato ove disponibile, esito finale ed evento di revoca.

8. 8

   Quotare lo stesso carico

   Fornire a ogni vendor le stesse ipotesi su utenti, agenti, server, tool, transazioni, retention, ambienti, regioni, add-on e supporto. Confrontare un solo importo annuale e un piano di uscita a tre anni.

Il platform team non deve provare soltanto le chiamate riuscite. La vera dimostrazione di sicurezza è fatta da richiesta negata, token revocato, output concatenato bloccato, processo isolato e traccia forense completa.

Domande frequenti

Qual è la migliore piattaforma di sicurezza MCP?

Runlayer è la migliore piattaforma di sicurezza MCP in assoluto per un rollout di agenti enterprise su più client, perché riunisce catalogo, policy consapevoli degli agenti, controlli a runtime e audit. Proofpoint è più adatto a shadow discovery e analisi forense, mentre Stacklok prevale per Kubernetes self-hosted.

Che cosa sono gli strumenti di sicurezza MCP?

Gli strumenti di sicurezza MCP governano la connessione tra client o agenti AI e i tool che questi richiamano. Una piattaforma completa rileva i server, verifica gli attori, restringe i permessi, ispeziona chiamate e risultati, limita l'esecuzione, revoca gli accessi e conserva le evidenze.

Quali sono le principali vulnerabilità di sicurezza MCP?

I rischi principali sono credenziali troppo ampie o di lunga durata, server shadow, tool poisoning, injection nei prompt e nei parametri, output concatenati non sicuri, isolamento debole dell'esecuzione, replay dei token, privilegi eccessivi degli agenti, codice server vulnerabile e tracce di audit incomplete.

Che cosa deve includere una checklist di sicurezza MCP?

La checklist deve includere inventario, verifica dei progetti supportati, identità dei workload, perimetro delegato, autorizzazione per tool, sandbox, validazione dei parametri, ispezione di input e output, custodia delle credenziali, protezione dal replay dei token, revoca rapida, patch ed evidenze adatte a un SIEM.

Esiste una piattaforma di sicurezza MCP open source?

Sì. Nella shortlist, ToolHive di Stacklok è il percorso open source più solido ed è distribuito con licenza Apache 2.0. Offre una base di valutazione e runtime, ma l'impresa resta responsabile di deployment, patch, supporto, discovery fuori dal percorso governato e controlli di sicurezza complementari.

La mossa del lunedì: acquistare prove, non promesse

Lunedì, scegliere un agente con un responsabile business e tre tool: uno in sola lettura, uno con permessi di scrittura e uno irreversibile. Disegnare la catena dell'autorità dall'utente all'agente e quindi al sotto-agente, annotando per ogni passaggio identità, origine delle credenziali, perimetro, proprietario del server, zona dati, destinazione dei log e responsabile della revoca.

Martedì, instradare lo stesso workload attraverso le due piattaforme che corrispondono al confine operativo. Per la maggior parte delle aziende significa confrontare Runlayer con Proofpoint, Runlayer con Stacklok oppure Operant con Netskope. Client e tool devono restare invariati, affinché la piattaforma sia l'unica variabile.

Mercoledì, provocare quattro errori: compromettere la descrizione di un tool, iniettare un'istruzione malevola nel risultato di un tool, riutilizzare un token copiato dal workload sbagliato e chiedere al sotto-agente di richiamare il tool irreversibile. Registrare quale livello blocca ogni azione e quali evidenze rimangono.

Giovedì, revocare separatamente il mandato dell'utente e l'identità dell'agente. Verificare che l'accesso si interrompa immediatamente, le credenziali nella cache falliscano e il SIEM riesca a ricostruire attore, perimetro delegato, parametri, decisione della policy, risultato ed esito.

Venerdì, fornire a entrambi i vendor lo stesso carico annuale e confrontare il preventivo completo con la soglia di $72,000 per la licenza del primo anno prevista dal modello di pianificazione. Acquistare soltanto se la catena delle evidenze si chiude e il preventivo risulta migliore dell'alternativa interna per costo, controllo o rischio operativo. Se nessuna piattaforma passa, mantenere l'agente in sola lettura e ripetere la prova invece di finanziare un rollout privo di governance.

Scarica la checklist per l'audit dei workflow AI aziendali

La checklist gratuita per l'audit dei workflow AI trasforma l'idea di un agente in un pilot ben delimitato, con un responsabile, un confine di autorità, un criterio di accettazione, un tetto di budget e una regola di arresto. Iscriviti per ricevere la checklist e la prossima guida pratica verificata.