Modelli troppo pericolosi per essere rilasciati: Project Glasswing e il problema dell'auditing di terze parti

Il 7 aprile 2026 Anthropic ha annunciato Project Glasswing, iniziativa cybersecurity che pairs il modello unreleased Claude Mythos Preview con una coalition di 12 partner enterprise (AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks più Anthropic) impegnati a usare il modello per individuare zero-day vulnerabilità in software critico prima degli avversari. Il modello è dichiarato "troppo pericoloso" per il rilascio pubblico perché in poche settimane ha individuato migliaia di zero-day in ogni major OS e in ogni major browser, è capace autonomamente di costruire exploit chain che escapano renderer e OS sandbox, ha risolto in un test corporate-network-attack simulato un task che a un esperto umano avrebbe richiesto 10+ ore. Anthropic ha dedicato 100 milioni di dollari di crediti usage per Glasswing più 4 milioni di donazioni dirette a open-source security organizations. Il giorno dopo, l'8 aprile 2026, il US Treasury Secretary Scott Bessent ha convocato i CEO bancari di Wall Street per un briefing dedicato sui rischi Mythos, mentre il presidente Bundesbank Joachim Nagel ha definito il modello "double-edged sword" notando che tutte le istituzioni rilevanti dovrebbero avere accesso per evitare distorsioni competitive.

Sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) ho passato la prima settimana di maggio 2026 a leggere il system card preview di Mythos su red.anthropic.com, il blog post di Anthropic su Glasswing, il commento critico di Bruce Schneier ("PR play"), e l'analisi di AISLE researchers che ha messo in dubbio la narrazione "frontier-only". Il quadro che ne esce non è solo "Anthropic ha un modello pericoloso e lo distribuisce con cautela". È una rilevazione strutturale di un problema più grande: nel 2026 una singola azienda AI crea il modello, lo valuta internamente, decide cosa è "troppo pericoloso" per il pubblico, sceglie i 12 partner che possono accederci, e narra alla stampa e ai regolatori la sicurezza che ne deriva. Tutto questo senza audit indipendente di terze parti che possa verificare claim, false-positive rate, capacity reale, e bias nella distribuzione del privilegio di accesso. Per il mercato italiano enterprise che si appresta a fare scelte di vendor AI rilevanti nel secondo semestre 2026, il precedente Glasswing apre tre questioni operative concrete che vale la pena nominare.

Tre problemi strutturali che il precedente Glasswing rivela

Problema uno: false claim rate non pubblicato e non verificabile. Anthropic dichiara "migliaia di zero-day individuati", e cita il caso CVE-2026-4747 FreeBSD NFS root vulnerability come esempio operativo. Ma il dato di "migliaia" non è accompagnato da false positive rate, da false negative rate, da metodologia di validazione indipendente, da percentuale di issue effettivamente confermate dai vendor del software target rispetto al claim iniziale del modello. Anthropic come giudice e parte del proprio modello: il claim è interno, il dato di accuracy è interno, la metodologia di evaluation è interna, la narrazione di sicurezza è interna, e la decisione su quali partner ammettere alla coalition è interna. AISLE researchers hanno notato proprio questo punto: la dipendenza assoluta del frame "frontier-only restricted model" dal modello specifico di Anthropic è discutibile, perché l'efficacia reale potrebbe derivare da pattern di engineering applicati al modello e replicabili con strumenti meno restritti. Senza audit terzo non è possibile decidere quale interpretazione è corretta.

Problema due: governance asimmetrica e accountability diffusa. I 12 partner enterprise di Glasswing hanno interesse commerciale a sostenere la narrazione (sono customer privilegiati di un prodotto restricted, e questo aumenta il loro vantaggio competitivo nei rispettivi mercati). I regolatori vengono briefati ma non hanno strumenti tecnici per validare. La stampa generalista riprende i talking point Anthropic. Il pubblico non ha accesso al modello e non può fare benchmark indipendenti. La narrazione non è sbilanciata in modo accidentale; è strutturalmente asimmetrica nel design dell'iniziativa stessa. Il pattern non è nuovo nella storia tech (open source vs closed source ha sempre avuto questo asse), ma l'applicazione a un sistema dichiarato "pericoloso" amplifica le conseguenze in termini di policy pubblica, di governance dei rischi sistemici, e di equilibrio competitivo del mercato della cybersecurity.

Problema tre: concentration risk del privilegio difensivo. Se Mythos è davvero il singolo modello che può trovare classi di vulnerabilità altrimenti irraggiungibili, e se l'accesso è limitato a 12 partner principali più 40 organizzazioni estese, una porzione enorme del software mondiale (incluse PMI italiane di fascia mid-market che dipendono da quello stesso software) è defended o non-defended in funzione di quei 52 attori. AISLE ha osservato che questo crea concentrazione critica della capacity defensive su un singolo provider AI. Se domani Anthropic decide diversamente, o subisce compromise, o cambia pricing, l'intero sistema di "discovery proattiva di vulnerabilità via AI" cambia per tutti.

Se gestisci scelte di vendor AI per la tua azienda nel secondo semestre 2026

Nel mio hub dedicato all'AI per aziende, sezione security raccolgo articoli sui pattern di valutazione dei vendor AI con framework strutturato. Il caso Glasswing è il primo grande precedente di "modello restricted by vendor", e i suoi insegnamenti sono trasferibili a ogni decision di acquisto AI nei prossimi 12-24 mesi.

Cosa può fare una PMI italiana per verificare indipendentemente un vendor AI

Detto tutto questo, il consulente serio non si ferma alla critica strutturale. Porta sul tavolo del cliente PMI italiana cinque pattern operativi per ridurre la dipendenza da un singolo vendor e per costruire una postura di valutazione indipendente.

Pattern uno: benchmark interno su use case specifici del cliente, non sul leaderboard pubblico del vendor. Ho descritto in dettaglio il pattern nel pezzo sul confronto AA Omniscience e nel pezzo sulla lettura critica dei paper AI: costruire un test set proprio del proprio dominio di 50-200 casi, eseguire periodicamente sui modelli candidati, monitorare drift. Senza questo dato, ogni discussione di scelta vendor è ancorata a marketing materials.

Pattern due: multi-vendor architecture by design. La pipeline aziendale dovrebbe poter switchare modello backbone (Claude, GPT, Gemini, Mistral, DeepSeek) con cambiamenti di configurazione, non rifacimenti di integrazione. Questo è esattamente il framework MCP-aware che ho descritto nell'articolo sulle RFP italiane post-donazione MCP a Linux Foundation. L'investment in vendor-neutral architecture si ripaga al primo cambio di contesto.

Pattern tre: clausole contrattuali che pretendono trasparenza minima sui claim del vendor. In RFP italiane del 2026 è ragionevole introdurre clausole come "il fornitore deve fornire al cliente, su richiesta, documentazione metodologica delle proprie evaluation interne sui modelli forniti, includendo dataset di test, metriche di accuracy/false-positive, e identificazione delle limitazioni note". Il fornitore può rifiutare per motivi commerciali, ma il rifiuto stesso è informazione utile per il cliente. Per il pubblico italiano, le linee guida AgID Determinazione 43/2026 che ho citato nel pezzo MCP-RFP stanno andando nella stessa direzione.

Pattern quattro: external audit del modello backbone su use case sensitive. Per scenari ad alto impatto (sanità, finanza, decisioni HR, automazione legale) il cliente PMI italiano dovrebbe finanziare un audit esterno che sondi il modello selezionato sui casi limite del proprio dominio. Costo tipico per audit: 8-20 giornate di consulente specializzato, 8-20k euro. Questo è il deliverable consulenziale più valido del 2026 perché è esattamente il dato che il vendor non fornisce e che la PMI non può produrre da sola.

Pattern cinque: segregazione del rischio sui workload critici. Se l'analisi di pattern uno mostra che il modello del vendor X è il migliore per il caso d'uso A ma debole su B, la pipeline dovrebbe instradare A a vendor X e B a vendor Y, non forzare un singolo vendor su tutto. Il pattern di routing dinamico che ho descritto nel pezzo sull'AA Omniscience è esattamente questo, applicato sistematicamente.

Le critiche di Schneier e AISLE messe in dettaglio

Bruce Schneier, nel suo blog del 9 aprile 2026, ha definito Project Glasswing "very much a PR play" notando che "lots of reporters breathlessly repeating Anthropic's talking points without engaging with them critically". La critica è specificamente metodologica: senza accesso pubblico al modello, senza dataset di evaluation pubblici, senza terzi auditor che abbiano potuto verificare i claim "thousands of zero-day", la narrazione resta basata sulla buona fede di un singolo provider commerciale. Schneier non sta dicendo che Mythos non funziona; sta dicendo che non possiamo sapere quanto bene funziona, e questa è un'asimmetria informativa rilevante per il mercato.

AISLE researchers hanno aggiunto un'osservazione tecnica più sottile: la narrazione "frontier-only restricted model" potrebbe disincentivare organizzazioni che dovrebbero adottare strumenti AI security oggi disponibili (modelli open source, modelli commerciali non restricted, scanner ibridi tradizionali) perché percepiscono che "solo il modello restricted può fare il lavoro". Se la verità è che molto del valore Mythos viene da pattern di engineering che si possono replicare su modelli accessibili, il framing restricted-only nuoce alla difesa collettiva. È un'argomentazione che vale la pena tenere a mente quando si valuta se aspettare l'accesso a un modello restricted o partire subito con strumenti disponibili.

C'è anche un terzo angolo che Schneier ha citato implicitamente e che vale la pena esplicitare: il caso CVE-2026-4747 FreeBSD NFS root-via-unauth è un risultato impressionante (17 anni di esistenza non scoperti, scoperti autonomamente da Mythos), ma è un singolo caso pubblico. Per validare il claim "thousands" servirebbe un sample non-random pubblico di ulteriori casi documentati, e questo non c'è. Il confronto rigoroso fra Mythos e baseline di scanning tradizionale (AFL, libFuzzer, syzkaller, Coverity) richiederebbe dataset condiviso e metodologia replicabile.

Implicazioni per la cybersecurity practice italiana

Per il consulente cybersecurity italiano che lavora con clienti enterprise, il precedente Glasswing ha tre implicazioni operative dirette nel breve termine. Prima, la narrazione "AI per scoperta vulnerabilità" entrerà nelle conversazioni RFP del secondo semestre 2026, e il consulente deve avere un framework per valutare quando l'AI security è value reale e quando è marketing. Pattern decisionale: se il vendor mostra metodologia, dataset di evaluation, false-positive rate documentato, accesso indipendente per audit, il claim merita peso; se non mostra, è marketing.

Seconda implicazione: il pattern di disclosure asimmetrica genera un nuovo tipo di rischio strutturale. Le organizzazioni che fanno parte delle coalition Glasswing-like hanno informazione privilegiata sulle vulnerabilità del software che usano, e possono patcharle prima dei competitor. Questo crea un mercato a due velocità in cui le PMI italiane fuori dalle coalition sono disabled rispetto al pari rischio. Mitigation: pressione regolatoria perché le scoperte di vulnerabilità nel software critico siano sempre comunicate in coordinated disclosure standard (CERT-IT, CVE registry pubblico) entro tempo certo, indipendentemente dal modello AI usato per scoprirle.

Terza implicazione: la concentration di capacity defensive su un singolo modello AI significa che il singolo modello diventa target di alta priorità per attaccanti sophisticated. Una compromise di Mythos (model exfiltration, prompt injection sistematica, supply chain attack su weights) avrebbe conseguenze su scala globale che renderebbero i precedenti incidents AI minori in confronto. Per il sistema-cybersecurity nel complesso questo concentrate-the-target pattern non è ottimale, ed è una considerazione che il consulente serio deve articolare esplicitamente nei suoi report al cliente quando suggerisce dipendenza da vendor restricted.

Cosa significa per le PMI italiane il precedente Glasswing in pratica

L'effetto pratico più immediato del precedente Glasswing è che il pattern "modello restricted by vendor con coalition di partner privilegiati" diventerà replicato. Nei prossimi 12-18 mesi è probabile che OpenAI, Google, Mistral o altri provider lancino iniziative analoghe nel proprio dominio (es. modello restricted per fraud detection, modello restricted per medical diagnostics, modello restricted per legal research). Le PMI italiane che non fanno parte delle coalition saranno escluse dall'accesso premium e dovranno scegliere fra usare modelli pubblici inferiori, o dipendere completamente da uno dei 52 partner di prima fascia per servizi rivenduti.

La conseguenza commerciale per il consulente AI italiano è netta: il valore differenziato non sta più nel "saper integrare il modello migliore", perché il modello migliore non è accessibile. Sta nel "saper costruire pipeline robuste su modelli accessibili, con benchmark interno, multi-vendor architecture e clausole contrattuali appropriate". È un mercato di consulenza diverso, meno glamour ma più stabile e più difendibile contro la commodity di mercato che gli AI consultant generalisti italiani offrono oggi senza framework metodologico solido.

I dati Osservatorio Politecnico Milano 2026 ricordano che il 9% delle grandi imprese italiane ha governance AI strutturata e che solo il 15% ha avviato un progetto strutturato di adeguamento AI Act. Queste sono percentuali che si traducono in impatto operativo concreto sui prossimi 12 mesi: chi non ha il framework decisionale per valutare l'effetto Glasswing sul proprio business, comprerà male ogni vendor AI nel secondo semestre 2026. Se vuoi una conversazione tecnica per costruire un framework di valutazione vendor AI indipendente per la tua organizzazione, oppure un audit di postura sui vendor attualmente in pipeline alla luce del precedente Glasswing e della disclosure asimmetrica che ne deriva, il modulo di preventivo gratuito è il punto da cui inquadrare la richiesta in due minuti, sette domande, prima del prossimo round di selezione fornitori.