Introduzione: perché la governance di MCP è urgente

Quando Snyk ha annunciato la disponibilità generale di MCP Governance in Evo ADS, la domanda più frequente è stata: “Da dove comincio lunedì?”. I dati raccolti su oltre 10.000 ambienti di sviluppo mostrano che 4.524 server MCP unici sono attivi, ma uno sviluppatore su dodici con un server MCP installato ha già avuto una vulnerabilità alta o critica. Molti di questi server sono stati creati in pochi secondi, senza revisione, semplicemente per far funzionare un agente di intelligenza artificiale.

Evo ADS risponde a questa esigenza fornendo un punteggio di rischio per ogni server MCP, permettendo di governare per rischio anziché per lista bianca rigida. Le decisioni avvengono direttamente sul terminale dove gli agenti operano, tramite hook leggeri che non richiedono proxy o interruzioni dei flussi di lavoro.

Passo 1 – Scoprire cosa è già in esecuzione

I server MCP non transitano mai attraverso CI o revisioni delle dipendenze: basta modificare un file di configurazione e l’agente ottiene nuovi strumenti. Per questo il primo passo è identificare ciò che è già presente.

Due viste per una copertura completa

MCP sui laptop degli sviluppatori: distribuendo l’installer di Evo ADS su tutta la flotta, il sistema rileva i server a cui gli agenti si collegano, inclusi installazioni locali isolate che non hanno mai toccato un repository.

MCP nei repository di codice: Evo AI‑SPM, integrato con lo SCM di Snyk, individua i riferimenti a server MCP all’interno del codice sorgente.

Entrambe le viste sono accessibili in Evo UI sotto Inventory → MCP servers. È inoltre possibile interrogare i dati tramite l’Evo MCP Server usando workflow agentici personalizzati, ottenendo una panoramica unificata dell’intero estate MCP senza blocchi o interruzioni.

Passo 2 – Definire cosa è “accettabile”

Decidere se il server n. 47 è sicuro non dovrebbe richiedere una lunga discussione su Slack. Evo ADS affianca a ogni server le evidenze necessarie per approvare o rifiutare rapidamente.

L’inventario dettagliato

Ogni riga dell’inventario fornisce:

Nome del server, origine (es. NPM), tipo di trasporto (SSE o STDIO) e se è locale.

Origine del fornitore: “Official” o “Unknown”, quest’ultimo segnale di attenzione.

Fonte: numero di occorrenze in codice, su macchine e a runtime.

Stato della whitelist: Allowed o Not allowed.

Punteggio di rischio unificato, filtrabile e ordinabile.

Conteggio dei problemi per gravità (critical, high, medium, low).

Ordinando per punteggio di rischio è possibile scansionare rapidamente le voci più pericolose.

Profilo di rischio per ogni server

Cliccando su un server si apre la vista dettagliata con tre schede: metodi di autenticazione, distribuzione (codice, macchine, ultima scansione) e frequenza di chiamata negli ultimi sette giorni. La scheda Risk profile sostituisce la ricerca su Slack: mostra il punteggio (da 0 a 1000) suddiviso in attributi come “prompt injection”, “capabilities destructive” e “untrusted content”. Ogni attributo può essere espanso per vedere la motivazione e le evidenze.

Esempio reale: un server con descrizioni di strumenti contenenti la frase “ignore previous instructions” in 8/12 istanze ha ottenuto un punteggio di 931 (Critico) nonostante fosse già presente nella whitelist. Questo evidenzia che la whitelist è una decisione temporale, mentre il punteggio di rischio indica la necessità di una revisione.

Come viene calcolato il punteggio

Il punteggio combina tre segnali:

Comportamento del server: istruzioni e descrizioni degli strumenti inviate all’agente.

Fiducia: reputazione delle URL e identità dei manutentori.

Implementazione locale: codice sorgente, manutenzione e dipendenze, se disponibili.

Circa il 20 % dei server non ha firma riconoscibile e quindi non riceve un punteggio; questi vanno gestiti manualmente.

Impostare la baseline

La whitelist registra le decisioni di approvazione. Ogni server ha un toggle “Approved/Not approved” che si riflette nella colonna Allowlist status. È possibile popolare la whitelist partendo da:

Un inventario esistente.

Una lista curata di fornitori ufficiali.

I server già scoperti da Evo ADS.

Per ogni candidato si verifica il punteggio, la provenienza del fornitore e le evidenze “Why this risk?”. Un server a basso punteggio, ufficiale e autenticato è un sì immediato; uno critico richiede una motivazione documentata o un rifiuto.

Passo 3 – Osservare prima di bloccare

Attivare il blocco fin da subito può interrompere flussi di lavoro non ancora mappati. Evo ADS offre una Modalità Monitor che simula il blocco, generando issue per ogni server non consentito senza impedire l’esecuzione.

Creare la prima policy di monitoraggio

Dal pannello Policies → Issues → Create policy, seleziona il template “Monitor not allowed MCP servers”. Ogni server a rischio sarà segnalato come issue da revisionare.

Utilizzando l’inventario, analizza ogni issue con il profilo di rischio: verifica il punteggio, l’affidabilità del fornitore e gli attributi che hanno influito sul risultato. Decidi se aggiungere alla whitelist o rifiutare. Dopo una o due settimane di monitoraggio avrai identificato pattern ricorrenti (es. un server che appare su cinquanta macchine) e potrai affinare la policy.

Passo 4 – Applicare l’enforcement in modo mirato

Quando la policy di monitoraggio è stata validata, è possibile attivare l’enforcement reale. Il template “Block not allowed MCP servers” (Policies → Policies → Create policy) impedisce agli agenti di chiamare server non in whitelist e con rischio alto o critico.

Se il template non corrisponde esattamente al tuo profilo di rischio, è possibile partire da “Start from scratch” e definire criteri personalizzati, ad esempio includendo soglie di punteggio diverse o escludendo certi attributi.

La regola blocca solo i server che sono contemporaneamente fuori whitelist e classificati come High o Critical. I server a basso rischio rimangono in modalità log, garantendo che gli sviluppatori non vengano interrotti ma lasciando comunque un audit trail.

Implementazione pratica e consigli finali

Per una adozione efficace, segui questi suggerimenti:

Automatizza la scoperta: distribuisci l’installer Evo ADS su tutti i nodi entro la prima settimana.

Aggiorna regolarmente la whitelist: rivedi le decisioni almeno una volta al mese, tenendo conto dei nuovi punteggi.

Coinvolgi gli sviluppatori: usa la modalità monitor per far comprendere il valore della policy senza penalizzare il lavoro.

Monitora i log di enforcement: analizza le segnalazioni per identificare falsi positivi o nuove categorie di rischio.

Documenta le eccezioni: ogni server spostato da “Not allowed” a “Allowed” deve avere una motivazione registrata nel sistema.

Seguendo questi quattro passaggi – scoperta, definizione, osservazione e enforcement – le organizzazioni possono passare da un approccio reattivo (blocchi massivi) a una governance basata sul rischio, mantenendo alta la produttività degli sviluppatori e riducendo drasticamente l’esposizione a vulnerabilità critiche.

Conclusioni

Evo ADS trasforma la gestione dei server MCP da attività manuale e dispendiosa a processo automatizzato, scalabile e basato su dati concreti. Con un inventario continuo, un punteggio di rischio dettagliato e policy flessibili, le aziende possono dire “sì” a MCP in tutta sicurezza, garantendo che gli agenti IA operino solo su server affidabili e controllati.