Mysterium ha esposto endpoint AI, e l’auto-hosting ha perso il suo alibi di sicurezza

Mysterium ha esposto endpoint AI su una scala che trasforma un errore di configurazione in un avvertimento per l’intero settore. I suoi ricercatori hanno identificato 36.769 sistemi raggiungibili, mentre solo 741 restituivano una richiesta di autenticazione HTTP.

Lo studio del 10 settembre ha esaminato server di modelli, interfacce chat, builder di agenti e console per vector store. Questi componenti costituiscono il livello operativo tra un modello AI e le persone, i documenti, le credenziali e le applicazioni che lo circondano.

Questo crea un conflitto scomodo per l’AI auto-ospitata. Le aziende eseguono spesso i modelli localmente per mantenere il controllo sui prompt e sui dati sensibili. Eppure molte installazioni sembrano raggiungibili senza una barriera a livello di rete, spostando la fiducia verso la sicurezza applicativa, l’applicazione delle patch e una configurazione corretta.

Il conteggio non dimostra che tutti i 36.769 sistemi abbiano esposto informazioni private. Alcune applicazioni potrebbero comunque richiedere agli utenti di accedere dopo il caricamento. Tuttavia, i risultati mostrano che migliaia di servizi AI si annunciano direttamente agli scanner Internet.

Questa distinzione conta. Una pagina di accesso visibile è comunque un’applicazione esposta che deve resistere a nuove vulnerabilità, password rubate, impostazioni predefinite deboli e sonde automatizzate. Un servizio dietro una rete privata o un gateway autenticato presenta un bersaglio più ridotto.

Il confronto, quindi, non è semplicemente tra AI locale e AI ospitata. È tra controllo in linea di principio e controllo nell’implementazione. I risultati di Mysterium suggeriscono che le organizzazioni scelgono l’auto-hosting senza gestire con costanza il perimetro di sicurezza che lo rende prezioso.

Endpoint AI esposti da Mysterium nell’intero stack AI operativo

La scoperta centrale non riguarda un singolo prodotto vulnerabile. Riguarda uno stack AI riconoscibile che può essere mappato dalla rete Internet pubblica.

Mysterium ha dichiarato che i suoi ricercatori hanno usato un indice di scansione di terze parti invece di sondare direttamente le macchine identificate. Il censimento originale ha cercato impronte dei servizi, inclusi titoli delle pagine, testo delle risposte e porte associate a software AI comuni.

Il dataset finale conteneva 36.769 endpoint autoidentificati. I prodotti per il serving dei modelli rappresentavano la maggior parte di questa popolazione, guidati da 18.529 istanze Open WebUI. Open WebUI offre un’interfaccia basata su browser per interagire con modelli linguistici ospitati localmente.

Solo uno di questi endpoint Open WebUI ha restituito una richiesta di autenticazione HTTP durante lo studio. Ciò non stabilisce che le applicazioni rimanenti consentissero un accesso agli account senza restrizioni. Stabilisce però che quasi nessuna aveva una barriera HTTP rilevabile posta davanti all’applicazione.

Ollama, un servizio per scaricare ed eseguire modelli su hardware locale, rappresentava altri 6.935 endpoint confermati. Secondo Mysterium, ognuno restituiva anonimamente la risposta root del prodotto. Di quel gruppo, 729 restituivano una richiesta di autenticazione.

I ricercatori hanno inoltre identificato 4.880 endpoint vLLM, di cui tre restituivano una richiesta. vLLM è un server di inferenza: accetta richieste e le esegue attraverso un modello linguistico per produrre risposte.

I gruppi più piccoli includevano 150 endpoint LocalAI, 69 server llama.cpp e 63 deployment Xinference. Questi prodotti servono pubblici diversi, ma condividono uno scopo operativo: rendere i modelli accessibili ad applicazioni o utenti.

Il dataset andava oltre l’inferenza. Mysterium ha contato 5.223 endpoint associati a builder di agenti e strumenti di workflow, inclusi Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow e Open WebUI Pipelines.

Questa categoria comporta un profilo di rischio diverso. Un server di inferenza elabora prompt, ma un builder di agenti spesso collega i modelli a database, sistemi di messaggistica, servizi cloud e applicazioni interne. Può archiviare token o invocare strumenti dotati di permessi reali.

Flowise rappresentava 1.341 endpoint raggiungibili, nessuno dei quali restituiva una richiesta di autenticazione. Lo studio ha inoltre contato 891 deployment RAGFlow, 792 endpoint Dify, 788 endpoint ComfyUI e 675 istanze n8n.

La visibilità dei vector store era molto più bassa. I ricercatori hanno trovato 914 console Milvus Attu e sei endpoint Weaviate. Un vector store conserva rappresentazioni numeriche dei contenuti affinché un’applicazione AI possa recuperare documenti pertinenti durante una conversazione.

Questi numeri non dovrebbero essere interpretati come prova che i database vettoriali siano raramente esposti. Mysterium ha affermato che la sua fonte non eseguiva scansioni sulle porte native di due prodotti principali. Il censimento ha catturato principalmente console web visibili, lasciando la categoria più sensibile dal punto di vista dei dati scarsamente misurata.

Il rapporto ha anche rilevato 22.024 risposte aggiuntive sulla porta predefinita di Ollama. I ricercatori le hanno escluse dal totale confermato perché una risposta della sola porta offriva evidenze più deboli rispetto a un banner di prodotto riconoscibile.

Questa esclusione prudente rafforza la conclusione principale. La cifra di 36.769 è una soglia minima confermata all’interno di un indice di scansione, non un inventario completo dell’infrastruttura AI pubblica.

Perché la sicurezza dell’AI auto-ospitata si infrange sul perimetro

L’auto-hosting protegge i dati solo quando l’organizzazione controlla anche chi può raggiungere l’host.

Le ragioni a favore dei modelli locali iniziano di solito dalla custodia dei dati. Prompt, documenti caricati, passaggi recuperati e risposte generate possono rimanere su apparecchiature controllate dall’organizzazione. Questa configurazione può ridurre la dipendenza da un fornitore esterno di modelli.

Tuttavia, la sola posizione non crea riservatezza. Un modello in esecuzione su hardware aziendale può comunque essere pubblico se il suo servizio rimane in ascolto su un indirizzo esposto a Internet. Un deployment interno può diventare esterno tramite una regola firewall, un security group cloud, un’impostazione del container o un tunnel configurato frettolosamente.

Molti prodotti AI locali restano in ascolto solo sull’indirizzo di loopback per impostazione predefinita. Il loopback limita le connessioni al software in esecuzione sulla stessa macchina. Gli operatori talvolta modificano quell’indirizzo in 0.0.0.0, consentendo al servizio di accettare connessioni attraverso ogni interfaccia di rete disponibile.

Questo cambiamento è utile quando uno sviluppatore necessita dell’accesso da un altro dispositivo. Diventa pericoloso quando anche la rete circostante consente il traffico Internet in ingresso.

Un reverse proxy può fornire un livello di autenticazione prima che le richieste raggiungano l’applicazione AI. Una rete privata virtuale può mantenere il servizio fuori dallo spazio degli indirizzi pubblici. Una allowlist IP può limitare l’accesso alle reti approvate.

Mysterium ha trovato poche evidenze di queste protezioni a livello HTTP. Nell’intero censimento, solo il 2,02 percento degli endpoint restituiva una richiesta di autenticazione. Cinque query di prodotto erano incomplete a causa dei limiti di frequenza della fonte, pertanto i ricercatori non hanno assegnato conteggi delle richieste a tali gruppi.

L’interpretazione restrittiva è importante. Una richiesta HTTP non è l’unico possibile controllo di sicurezza. Un’applicazione può caricarsi pubblicamente e applicare comunque le proprie regole di accesso, sessione o autorizzazione.

Tuttavia, affidarsi all’autenticazione dell’applicazione modifica il modello di minaccia. L’applicazione diventa continuamente raggiungibile da scanner e attaccanti. Ogni patch mancante, errore di autorizzazione, percorso amministrativo esposto e credenziale predefinita assume maggiore rilevanza.

I recenti record di vulnerabilità mostrano perché questa preoccupazione sia concreta. Gli avvisi di sicurezza di Tenable del 2026 hanno elencato problemi ad alta gravità che interessano Open WebUI e diversi componenti Flowise.

Gli avvisi relativi a Flowise includevano directory traversal, injection di query a grafo, autenticazione mancante sugli endpoint NVIDIA NIM e divulgazione di informazioni personali. Avvisi separati riguardavano esposizione di credenziali, fallimenti nell’autorizzazione e scritture arbitrarie di file in altri strumenti AI.

Questi record non significano che ogni deployment visibile su Internet sia vulnerabile. Versioni, configurazioni e controlli compensativi differiscono. Dimostrano che il livello applicativo non può fungere da sostituto permanente dell’isolamento di rete.

Anche i tempi di applicazione delle patch creano un altro problema. Uno sviluppatore può avviare in pochi minuti un utile proof of concept e poi lasciarlo in funzione per mesi. Il servizio potrebbe non entrare mai nell’inventario degli asset usato dai team di sicurezza e infrastruttura.

Questo ciclo di vita produce shadow AI: sistemi adottati o costruiti senza la normale supervisione organizzativa. Il progetto rimane visibile al suo creatore ma invisibile ai team responsabili di revisioni degli accessi, aggiornamenti, log e risposta agli incidenti.

Il risultato è un perimetro di sicurezza costruito su presupposti. Il data scientist presume che il firewall cloud blocchi il traffico. Il team infrastrutturale presume che l’applicazione richieda autenticazione. Il proprietario dell’applicazione presume che il deployment sia temporaneo.

Uno scanner Internet verifica questi presupposti senza bisogno di contesto organizzativo. Se il prodotto risponde, si identifica e presenta una superficie applicativa, ha già oltrepassato un confine che l’auto-hosting avrebbe dovuto preservare.

I builder di agenti trasformano l’esposizione in rischio della supply chain

Gli endpoint AI esposti più gravi fanno più che rispondere alle domande, perché possono agire tramite credenziali e sistemi connessi.

Una supply chain AI include il modello, i pacchetti software, l’infrastruttura di serving, i database di recupero, plugin, strumenti e servizi esterni utilizzati per produrre un risultato. Una debolezza in qualsiasi componente connesso può influenzare il sistema o ampliare l’accesso di un attaccante.

Le supply chain software tradizionali comportano già rischi ereditati. Le applicazioni dipendono da pacchetti mantenuti da sviluppatori esterni, immagini di container create altrove e workflow automatizzati che detengono credenziali di deployment.

Le applicazioni AI aggiungono a questa catena prompt, file dei modelli, contenuti di recupero, istruzioni degli agenti e definizioni degli strumenti. Alcuni di questi artefatti sembrano dati, benché possano modificare ciò che un agente fa.

Fortinet ha descritto le skill degli agenti come un nuovo livello di dipendenza per gli assistenti di programmazione. La sua analisi delle skill ha osservato che una skill può usare istruzioni in linguaggio naturale per indicare a un agente di accedere ai file, eseguire comandi shell o trasmettere informazioni.

Questo comportamento non richiede sempre una vulnerabilità software convenzionale. Un’istruzione dannosa può diventare operativa quando un agente le dà fiducia e dispone del permesso di usare lo strumento richiesto.

Un builder di workflow esposto a Internet combina questi rischi. Può rivelare quali integrazioni utilizza un’organizzazione, accettare input non attendibili o esporre percorsi che interagiscono con credenziali archiviate. Un workflow compromesso potrebbe quindi raggiungere sistemi molto oltre il server AI originale.

Consideriamo un assistente di recupero usato da un team di ingegneria. L’applicazione potrebbe connettersi a un repository di codice sorgente, un archivio di documentazione, un sistema di issue tracking e un endpoint di modello. Il suo database vettoriale potrebbe contenere frammenti di documenti interni.

Se l’interfaccia pubblica presenta un difetto di autorizzazione, il bottino dell’attaccante non è limitato all’inferenza gratuita del modello. A seconda del prodotto e della configurazione, l’attaccante potrebbe accedere a contenuti recuperati, definizioni di workflow, metadati delle connessioni o token.

Un agente di assistenza clienti presenta un percorso simile. Potrebbe connettersi a email, registri degli ordini, strumenti di messaggistica e un database clienti. Anche una credenziale con ambito ristretto diventa preziosa quando il workflow può combinare informazioni tra servizi.

Ecco perché i 5.223 endpoint di builder di agenti meritano un’attenzione distinta rispetto ai server di modelli. La popolazione più piccola può comportare un raggio d’impatto operativo più ampio.

Il rapporto sui rischi cloud di Tenable di febbraio offre un contesto per le imprese. La sua telemetria ha mostrato che il 70 percento delle organizzazioni analizzate aveva integrato almeno un pacchetto AI o Model Context Protocol di terze parti.

Model Context Protocol, o MCP, è uno standard che consente alle applicazioni AI di connettersi a strumenti e fonti di dati. La sua utilità deriva dal concedere ai modelli un accesso strutturato a capacità esterne.

Tenable ha inoltre riferito che il 18 percento delle organizzazioni aveva assegnato ai servizi AI autorizzazioni amministrative sottoposte raramente a controlli. L'azienda ha rilevato che le identità non umane, inclusi agenti e account di servizio, presentavano un rischio misurato più elevato rispetto agli utenti umani.

Questi risultati provengono dalla telemetria cloud e dei clienti di Tenable, non dal censimento di Internet di Mysterium. I dataset non dovrebbero essere uniti in un'unica stima di prevalenza. Insieme, mostrano due lati dello stesso problema operativo.

Mysterium ha misurato i servizi raggiungibili. Tenable ha misurato autorizzazioni, pacchetti di terze parti e condizioni delle identità all'interno di ambienti aziendali. L'esposizione pubblica diventa più rilevante quando il servizio raggiungibile controlla anche un'identità non umana con privilegi.

La pressione ricade sia sugli sviluppatori sia sui team di sicurezza. Gli sviluppatori necessitano di accesso rapido a modelli e integrazioni. I team di sicurezza necessitano di un inventario, responsabilità chiare, privilegi limitati e prove che ogni servizio pubblico abbia una ragione deliberata per esistere.

Nessuno dei due obiettivi può essere raggiunto soltanto attraverso policy del modello. Un modello che rifiuta un prompt dannoso non ripara una console amministrativa pubblica. Le protezioni del provider non ruotano un token compromesso né rimuovono un container abbandonato.

Le organizzazioni che utilizzano l'AI per lavorare con conoscenze interne devono inoltre classificare ciò che entra nei sistemi di retrieval. Una base di conoscenza ricercabile può migliorare l'accesso al materiale tecnico, ma il suo storage e i suoi connettori ereditano la sensibilità di tale materiale.

La questione della sicurezza si sposta quindi a monte. Prima che un agente riceva un prompt, qualcuno deve decidere quali dati può recuperare, quali strumenti può invocare e quale rete può raggiungerlo.

Cosa non dimostra la cifra di 36.769

Il censimento dimostra la raggiungibilità pubblica, ma non stabilisce 36.769 compromissioni riuscite o fughe di dati.

La misurazione di Internet può produrre una cifra impressionante senza rispondere a ogni domanda sulla sicurezza. Le impronte dei prodotti identificano i servizi, mentre una risposta HTTP rivela qualcosa sul loro perimetro. Nessuno dei due elementi rivela automaticamente lo stato interno di autorizzazione dell'applicazione.

Alcuni endpoint nel dataset probabilmente mostravano una pagina di login. Altri potrebbero aver limitato funzioni importanti dopo il caricamento dell'interfaccia. Alcuni potevano essere sistemi di ricerca, honeypot, dimostrazioni intenzionalmente pubbliche o installazioni di test vuote.

Mysterium ha riconosciuto questo limite. Il rapporto non ha affermato che ogni applicazione visibile consentisse l'accesso anonimo a funzionalità private. Ha descritto l'assenza di un controllo di rete o HTTP come esposizione comune.

Questa limitazione impedisce un calcolo diretto di record violati, organizzazioni vulnerabili o utenti interessati. I ricercatori non hanno pubblicato un elenco dei proprietari dei target, e farlo potrebbe creare ulteriori rischi.

La misurazione dell'autenticazione varia inoltre a seconda del prodotto. Solo 12 delle 17 categorie di prodotti disponevano di conteggi delle challenge risolti. Un trattino nel dataset indicava una query incompleta, non l'assenza confermata di autenticazione.

Anche l'analisi geografica era limitata. Mysterium ha riportato l'attribuzione per Paese soltanto per un sottoinsieme delle risposte di Ollama sulla sua porta predefinita. Qualsiasi affermazione ampia su quali Paesi o settori siano più esposti andrebbe oltre le prove disponibili.

Il conteggio degli endpoint può inoltre includere più servizi gestiti da una sola organizzazione. Al contrario, un endpoint può trovarsi davanti a un ambiente condiviso più ampio. Il numero di indirizzi raggiungibili non corrisponde al numero di aziende interessate.

La copertura dello scanner introduce un'altra incertezza. Un indice, una pianificazione delle query o un'impronta diversi possono restituire una popolazione differente. I servizi vanno online e offline, modificano i banner, si spostano dietro proxy o ricevono patch.

Queste limitazioni non cancellano il risultato. Trasformano la conclusione da “36.769 sistemi compromessi” a qualcosa di più preciso: migliaia di servizi AI riconoscibili erano raggiungibili tramite un indice di scansione pubblico.

Questa condizione è preziosa per gli aggressori prima ancora che inizi lo sfruttamento. L'identificazione del prodotto aiuta ad automatizzare l'associazione con le vulnerabilità. Uno scanner può cercare un'interfaccia nota, stimarne la versione e testare su larga scala le route applicabili.

La differenza tra esposizione e compromissione assomiglia a una porta sbloccata affacciata sulla strada. Vedere la porta non dimostra che qualcuno sia entrato. Mostra però che la proprietà dipende maggiormente da ogni restante controllo interno.

Anche la cifra del 2,02 percento riportata nel rapporto richiede cautela. L'autenticazione HTTP di base non è intrinsecamente migliore dell'autenticazione moderna delle applicazioni in ogni architettura. Un proxy gestito male può introdurre proprie debolezze.

Il principio più solido è la difesa in profondità. Un servizio AI sensibile non dovrebbe dipendere da un singolo login applicativo quando sono disponibili networking privato, gateway autenticati, proxy identity-aware e regole di ingresso limitate.

Esiste inoltre un incentivo commerciale dietro parte del commento più ampio sull'esposizione AI. I fornitori di sicurezza traggono vantaggio quando le organizzazioni acquistano prodotti di discovery, scansione, identità e monitoraggio. Le loro raccomandazioni dovrebbero essere valutate rispetto alle prove tecniche.

Mysterium stesso è un'azienda VPN, il che rende la privacy di rete rilevante per la sua attività. Questo non invalida il suo dataset. Rende più importanti metodi trasparenti, impronte riproducibili e conferme indipendenti.

Lo studio ha pubblicato le proprie impronte e spiegato risultati esclusi, lacune dovute ai limiti di velocità e categorie sottostimate. Queste scelte rendono la misurazione centrale più facile da verificare rispetto a un'affermazione basata soltanto su telemetria privata.

Il prossimo passo utile per la ricerca è la validazione controllata. Team indipendenti dovrebbero ripetere le query, campionare il comportamento degli endpoint senza accedere a contenuti sensibili e monitorare come cambia la popolazione dopo la divulgazione.

Un conteggio in calo suggerirebbe che operatori o manutentori del software abbiano risposto. Un conteggio stabile indicherebbe che il deployment insicuro è strutturale anziché temporaneo.

Il vero compromesso è tra velocità di deployment e controllo verificabile

Lo studio di Mysterium sugli endpoint AI esposti mette in discussione l'idea che l'hosting autonomo garantisca automaticamente la privacy.

L'AI ospitata concentra la fiducia in un provider. I clienti fanno affidamento su contratti, isolamento del servizio, controlli sulla conservazione, policy di accesso e programma di sicurezza del provider.

L'hosting autonomo ridistribuisce questa fiducia. L'organizzazione controlla hardware e deployment, ma eredita anche patching, gestione delle identità, progettazione di rete, logging, backup e risposta agli incidenti.

Questa può essere la scelta giusta per informazioni regolamentate o carichi di lavoro specializzati. Per impostazione predefinita, non è la scelta più semplice. Il server locale deve essere gestito come infrastruttura sensibile, non come un esperimento desktop che è diventato condiviso.

La velocità crea la tensione centrale. I framework AI sono progettati per ridurre la distanza tra un'idea e un'applicazione funzionante. Un ricercatore può avviare un'interfaccia, collegare un modello, connettere documenti e condividere rapidamente il risultato.

Ogni comodità può nascondere una decisione operativa. Esporre una porta rende più semplice la collaborazione. Memorizzare un token in un workflow accelera l'integrazione. Concedere autorizzazioni ampie evita errori di autorizzazione ripetuti.

Queste decisioni si accumulano in un ambiente che funziona prima che qualcuno abbia definito il suo confine di sicurezza. L'applicazione diventa utile, attrae utenti e si avvicina alla produzione mantenendo al contempo i suoi controlli sperimentali.

Anche i processi di sicurezza tradizionali possono contribuire al divario. Se ottenere un ambiente approvato richiede settimane, i dipendenti svilupperanno soluzioni aggirando il processo. Bloccare ogni servizio AI senza offrire un percorso utilizzabile incentiva alternative non gestite.

Le organizzazioni hanno bisogno di un percorso di deployment sufficientemente rapido da competere con l'infrastruttura ombra. Tale percorso dovrebbe fornire per impostazione predefinita networking privato, identità gestita, archiviazione dei segreti, logging, responsabilità per le patch e date di scadenza.

Gli esperimenti di breve durata meritano date di scadenza perché i sistemi temporanei raramente si rimuovono da soli. Un'istanza cloud creata per una dimostrazione può rimanere online dopo che il suo proprietario cambia ruolo o dimentica il progetto.

L'inventario deve includere l'intera catena operativa. Trovare un server di modelli senza il suo vector store, il motore di workflow, l'host dei container e gli account di servizio lascia i difensori con un quadro frammentato.

L'identità merita uguale attenzione. Un agente dovrebbe ricevere le autorizzazioni più ristrette necessarie per il suo compito. Le credenziali amministrative non dovrebbero diventare la risposta standard quando un'integrazione fallisce.

Le credenziali memorizzate in workflow pubblici o precedentemente esposti dovrebbero essere ruotate. Rimuovere l'accesso a Internet chiude un percorso, ma non invalida un token che un aggressore potrebbe già possedere.

I log devono coprire le azioni, non soltanto le conversazioni. I team devono sapere quale strumento abbia invocato un agente, quale identità abbia usato, quale risorsa abbia raggiunto e se l'azione corrispondesse a un workflow approvato.

Questo è particolarmente importante quando le istruzioni dell'agente provengono da terze parti. Un template, plugin o skill importato può alterare il comportamento senza assomigliare a codice eseguibile. Le revisioni devono esaminare sia i pacchetti convenzionali sia i file di controllo in linguaggio naturale.

Anche i manutentori del software affrontano pressioni. Le impostazioni predefinite sicure dovrebbero rendere più difficile l'esposizione accidentale. I prodotti possono avvisare quando i servizi si associano a interfacce pubbliche, richiedere credenziali al primo avvio e separare le route amministrative dagli endpoint rivolti agli utenti.

La documentazione è importante perché i tutorial spesso diventano architettura di produzione. Una guida rapida che espone un servizio senza spiegare le conseguenze per la rete può propagare lo stesso errore in migliaia di installazioni.

I provider cloud e di modelli rimangono parte del confronto. Le piattaforme gestite possono ridurre il lavoro di configurazione, ma introducono rischi legati alla concentrazione nel provider e alle autorizzazioni dell'account. La risposta non è che un modello di hosting vinca sempre.

La scelta difendibile è quella i cui controlli possono essere verificati. Un'organizzazione dovrebbe sapere dove viene eseguito il modello, chi può raggiungerlo, quali dati elabora, quali identità utilizza e con quale rapidità l'accesso può essere revocato.

Tre segnali mostreranno se l'esposizione diminuisce

Il prossimo test è verificare se manutentori e operatori trasformano un censimento ampiamente riportato in una remediation misurabile.

Il primo segnale è una nuova scansione di Internet che utilizzi le stesse impronte. Le misure più rivelatrici saranno il totale degli endpoint confermati e la quota protetta da autenticazione a livello di rete.

Un conteggio inferiore degli endpoint suggerirebbe che gli operatori abbiano rimosso l'accesso pubblico non necessario. Un tasso di autenticazione più elevato mostrerebbe che i servizi sono rimasti utili acquisendo al contempo un perimetro.

Nessun cambiamento da solo è sufficiente. Un endpoint può scomparire da un'impronta perché il suo banner è cambiato, pur rimanendo raggiungibile. I ricercatori dovrebbero quindi documentare le modifiche alle query e preservare misurazioni comparabili.

Il secondo segnale è l'azione dei principali manutentori. Open WebUI merita particolare attenzione perché rappresentava 18.529 endpoint, circa la metà della popolazione confermata da Mysterium.

Avvisi sul binding pubblico, credenziali iniziali obbligatorie, modelli di deployment più sicuri e indicazioni più chiare sui reverse proxy rafforzerebbero l'argomentazione complessiva del rapporto. Il silenzio o modifiche puramente cosmetiche ai banner lascerebbero il problema operativo in gran parte irrisolto.

I builder di agenti dovrebbero ricevere un esame ancora più rigoroso. Flowise, RAGFlow, Dify, n8n, Langflow e strumenti simili necessitano di impostazioni predefinite sicure che riconoscano il loro accesso a segreti e sistemi esterni.

Il terzo segnale è costituito dalle evidenze relative a vulnerabilità e incidenti. Nuovi avvisi riguardanti autorizzazione, divulgazione di credenziali, esecuzione remota o accesso degli agenti agli strumenti mostrerebbero come l'esposizione pubblica possa trasformarsi in un vettore d'attacco.

Uno sfruttamento confermato rafforzerebbe l'urgenza, ma i difensori non dovrebbero attenderlo. L'assenza di incidenti divulgati non dimostra la sicurezza quando i proprietari degli asset potrebbero non disporre di log o visibilità.

Le organizzazioni possono agire prima che arrivino questi segnali. Dovrebbero censire i servizi AI, verificare quali interfacce siano raggiungibili pubblicamente e identificare le persone responsabili di ogni deployment.

Tutto ciò che non richiede accesso pubblico dovrebbe essere associato a un'interfaccia privata. I servizi che devono restare raggiungibili dovrebbero trovarsi dietro gateway autenticati, con identità limitate e patch aggiornate.

I builder di agenti richiedono un trattamento aggiuntivo come infrastruttura per i segreti. I team dovrebbero riesaminare le integrazioni archiviate, ruotare le credenziali esposte, ispezionare i workflow importati e registrare le azioni degli agenti sui sistemi connessi.

Il conteggio di Mysterium degli endpoint AI esposti diventerà inevitabilmente obsoleto. È prevedibile. La domanda importante è se il prossimo conteggio rifletterà controlli migliori o soltanto una raccolta più ampia di servizi trascurati.

Per sviluppatori, acquirenti aziendali e utenti dell'AI, il test pratico è semplice: l'organizzazione può dimostrare chi può raggiungere ciascun sistema e cosa quel sistema può fare? Se la risposta dipende da supposizioni, il deployment non sta offrendo il controllo che l'hosting autonomo aveva promesso.