Negli ultimi due anni molte organizzazioni hanno spostato l'intelligenza artificiale dentro casa. La motivazione è quasi sempre la stessa, ed è ragionevole: tenere modelli, prompt e documenti sulla propria infrastruttura invece di inviarli a un servizio cloud di terze parti. In Italia questo argomento ha un peso particolare, perché si intreccia con le preoccupazioni su GDPR e trasferimenti extra-UE che hanno guidato molte scelte tecnologiche.

Una ricerca pubblicata l'11 settembre da Mysterium VPN suggerisce che quel vantaggio, in migliaia di casi, è stato annullato nel modo più banale possibile: mettendo il server su internet senza niente davanti.

I numeri

I ricercatori hanno censito 36.769 endpoint AI self-hosted raggiungibili e identificabili attraverso un indice pubblico di scansione (Netlas), distribuiti tra server di modelli, piattaforme di costruzione di agenti e vector store. Di questi, solo il 2,02% restituisce una sfida di autenticazione HTTP.

La metodologia merita attenzione, perché è più prudente di quanto il titolo lasci intendere. Un servizio che risponde 200 non è automaticamente privo di autenticazione: anche una pagina di login risponde 200. I ricercatori hanno quindi usato le risposte 401 e 403 come prova dell'esistenza di un gate, e hanno formulato l'affermazione più forte solo dove il fingerprint dell'applicazione dimostrava di per sé l'accesso anonimo. Non si sono collegati ai sistemi, non hanno estratto dati né eseguito modelli: «abbiamo contato le porte, non le abbiamo aperte». I 36.769 endpoint sono dichiarati come limite inferiore, non come misura dell'intera internet.

La distribuzione è istruttiva:

  • Open WebUI: 18.529 istanze raggiungibili, una sola dietro un gate di autenticazione. È il front-end per LLM locali più diffuso, e come popolazione non ha perimetro.
  • vLLM: 4.880 endpoint, tre con autenticazione.
  • Ollama: 6.935 host restituiscono il fingerprint «Ollama is running» dalla root senza credenziali, 6.046 con un esplicito HTTP 200. Qui l'accesso anonimo è verificabile dalla risposta stessa del servizio.
  • LocalAI (150) e llama.cpp (69): nessuna autenticazione rilevata.
  • Agent builder e piattaforme di workflow: 5.223 istanze esposte, tra cui Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow e Open WebUI Pipelines. Su 1.341 istanze Flowise, zero hanno restituito una sfida di autenticazione.
  • Vector store: 920 endpoint, quasi tutti console Attu per Milvus. I ricercatori sono espliciti nel dire che questo è il dato meno affidabile in senso rassicurante: le porte native di Qdrant e Milvus non erano scansionate dalla fonte, quindi un database può essere pubblicamente raggiungibile senza comparire nel censimento. «Nessuno dovrebbe leggere questo studio come prova che i vector database self-hosted siano ben protetti. Semplicemente non riuscivamo a vederli».

Il dato non è isolato. A gennaio uno studio congiunto di SentinelOne e Censys aveva identificato circa 175.000 host Ollama esposti in 130 Paesi, quasi la metà dei quali con capacità di tool-calling in grado di eseguire codice o interagire con sistemi esterni. La differenza tra le due cifre dipende dalla fonte di scansione e dalla severità del fingerprint, non da un miglioramento della situazione.

Tre livelli di rischio, non uno

È utile separare cosa si perde a ciascuno strato, perché la reazione difensiva cambia.

Il server del modello espone capacità di calcolo. Un'API Ollama raggiungibile rivela quali modelli sono installati e permette di generare testo usando l'hardware del proprietario. È il fenomeno che la community chiama LLMjacking: qualcun altro ottiene tempo GPU, il proprietario riceve la bolletta. Nella campagna documentata da SentinelOne, gli accessi rubati vengono rivenduti su marketplace clandestini a prezzi scontati del 40–60%. C'è poi un rischio meno immediato ma più insidioso: un modello esposto senza autenticazione e senza guardrail risponde a chiunque, e può essere usato per generare contenuti che risulteranno tecnicamente originati dall'infrastruttura dell'azienda.

L'agent builder espone credenziali. Ed è qui che il problema cambia natura. Un workflow n8n o Flowise contiene, per funzionare, chiavi API di servizi terzi, credenziali di database, token Slack, segreti di webhook, password di CRM. Non sono sistemi difettosi: fanno esattamente ciò per cui sono stati progettati. Il problema nasce quando si mette quella funzionalità direttamente su internet. Mysterium cita a questo proposito CVE-2026-40933, una vulnerabilità critica di Flowise che consente a un attaccante autenticato di eseguire comandi arbitrari tramite l'adapter MCP, corretta nella versione 3.1.0.

E non serve nemmeno una vulnerabilità. Ad agosto i ricercatori di GitGuardian hanno esaminato i token API n8n esposti in commit pubblici su GitHub: 4.576 token unici associati a 1.255 hostname, e delle 896 istanze raggiungibili durante i test 321 hanno accettato almeno un token trafugato. Nessun exploit, solo un segreto finito in un repository.

Il vector store espone il contenuto. È lo strato che in un'analisi di rischio dovrebbe stare per primo e che invece viene quasi sempre considerato per ultimo, perché somiglia a un'infrastruttura tecnica. Ma il database vettoriale contiene ciò che l'organizzazione ha caricato nel proprio sistema AI: documenti interni, ticket di assistenza, contratti, anagrafiche clienti, basi di conoscenza riservate. È l'archivio, non l'indice.

Cosa significa per le aziende italiane

Il primo punto riguarda il GDPR, e va detto senza giri di parole. Se un vector store contiene embedding derivati da documenti con dati personali — ticket di supporto, corrispondenza con clienti, cartelle del personale, pratiche — quel database è un archivio di dati personali a tutti gli effetti, e la sua esposizione su internet senza autenticazione è una violazione dell'articolo 32 prima ancora di essere un incidente. Quando la si scopre, non si è davanti a un problema tecnico da sistemare in silenzio: si è davanti a una valutazione ex articolo 33 sulla notifica al Garante, con l'aggravante che in assenza di logging di accesso sarà impossibile dimostrare che nessuno abbia letto nulla. E l'onere della prova, in materia di accountability, sta sul titolare.

Il secondo punto è il paradosso che rende questa storia specificamente italiana. Molte installazioni self-hosted nascono proprio dalla volontà di non mandare dati a un servizio cloud americano. Quella scelta, fatta con attenzione, è difendibile e in alcuni contesti preferibile. Fatta male produce un risultato peggiore dell'alternativa che voleva evitare: il fornitore cloud, con tutti i suoi problemi di trasferimento internazionale, almeno chiede una chiave API. Un Open WebUI su 0.0.0.0 non chiede niente a nessuno. Chi ha giustificato l'installazione locale con un argomento di conformità ha, oggi, l'onere di dimostrare che quella conformità esiste davvero.

Il terzo punto riguarda chi ha materialmente installato questi sistemi. Le piattaforme di cui parliamo si installano in pochi minuti, spesso da un singolo sviluppatore o da un reparto che vuole sperimentare senza attendere i tempi dell'IT. È shadow IT, con la differenza che questa volta lo shadow IT ha accesso ai database di produzione tramite i connettori del workflow. Un'azienda italiana di media dimensione che non abbia mai fatto un censimento specifico ha una probabilità concreta di avere almeno un'istanza di questo tipo attiva e sconosciuta — magari su un VPS pagato con carta aziendale, fuori dall'inventario.

Sul piano normativo, per i soggetti NIS2 l'inventario degli asset e la gestione del rischio della catena di fornitura previsti dall'articolo 21 della direttiva coprono anche questa infrastruttura: un endpoint AI non censito è un asset non gestito, e la mancanza di censimento è di per sé un rilievo. Per chi rientra nell'AI Act, l'articolo 15 richiede robustezza e cybersicurezza dei sistemi ad alto rischio lungo tutto il ciclo di vita, e un sistema pubblicamente manipolabile difficilmente soddisfa quel requisito.

C'è un'ultima osservazione che vale la pena fare, perché è il punto in cui questa ricerca è più utile. Non stiamo parlando di attacchi sofisticati ai modelli, di avvelenamento dei dati di addestramento o di tecniche inedite di prompt injection — i temi su cui si concentra quasi tutto il dibattito sulla sicurezza dell'AI. Stiamo parlando di uno sviluppatore che fa il bind su 0.0.0.0, mette il servizio su una macchina cloud di fretta e dimentica che internet la può vedere. L'AI è nuova. Lasciare la porta aperta no.

Cosa fare subito

  • Fare un censimento onesto. Verificare su quali IP pubblici dell'organizzazione rispondono i servizi tipici: porta 11434 (Ollama), 3000 (Open WebUI, Flowise), 5678 (n8n), 8000 e 8080 (vLLM, LocalAI), 19530 e 6333 (Milvus, Qdrant). I fingerprint pubblicati nella ricerca sono utilizzabili con i normali servizi di scansione per cercare le proprie esposizioni prima che lo faccia qualcun altro.
  • Legare i servizi a localhost o a una rete privata ogni volta che l'accesso da internet non è un requisito esplicito. È la misura che risolve da sola la maggior parte dei casi censiti.
  • Mettere un gate davanti, non dentro. Se l'accesso remoto serve, va messo dietro VPN, reverse proxy con autenticazione o accesso a rete zero-trust, senza affidarsi esclusivamente al login dell'applicazione — che in diversi di questi prodotti è opzionale o disattivato per default.
  • Trattare n8n e Flowise come si tratta un password manager. Se contengono chiavi che raggiungono sistemi di produzione, il livello di protezione dev'essere quello, non quello di un tool di sperimentazione.
  • Ruotare i segreti presenti nei workflow se l'istanza è stata esposta anche solo temporaneamente, e cercare token API dei propri hostname nei repository pubblici. Il caso n8n dimostra che i segreti trafugati restano validi finché non li si cambia.
  • Censire cosa c'è dentro i vector store e classificarlo. Se contengono dati personali vanno inseriti nel registro dei trattamenti, e la loro esposizione va gestita come una potenziale violazione, non come un errore di configurazione.
  • Aggiornare Flowise almeno alla 3.1.0 e verificare le versioni di tutte le piattaforme di orchestrazione in uso: sono software giovani, con cicli di rilascio rapidi e vulnerabilità frequenti.
  • Includere l'infrastruttura AI nelle scansioni di superficie esterna ricorrenti. Se il perimetro viene verificato ogni trimestre ma il censimento non contempla queste porte, il controllo continuerà a dare esito positivo su un'esposizione che c'è.