Claude Mythos security risks: What the Anthropic System Card tells us

AGGIORNAMENTO — “22 aprile”, n. 2026: fuga di notizie su Mythos

Secondo quanto riportato da in un articolo di Bloomberg, un piccolo gruppo di utenti associato a un server Discord privato Community , dedicato alla divulgazione di dettagli su modelli di IA non ancora rilasciati, ha ottenuto l’accesso non autorizzato all’anteprima di Claude Mythos attraverso l’ambiente di un fornitore terzo, e non tramite una violazione diretta dei sistemi centrali di Anthropic.

Sebbene l’attenzione dei media si sia concentrata sul modello in sé, questo dettaglio colloca l’incidente in un ambito più familiare per i team di sicurezza: l’esposizione a terze parti, la proliferazione degli accessi e il divario tra l’accesso limitato in teoria e quello nella pratica. Piuttosto che una grave violazione delle infrastrutture di frontiera, la situazione evidenzia come le capacità sensibili possano essere esposte ai rischi derivanti dall’ecosistema più ampio che le circonda.

Per i difensori, tale distinzione è importante. I sistemi di alto valore vengono raramente raggiunti attraverso la porta principale; gli aggressori e gli utenti non autorizzati cercano percorsi alternativi meno controllati o meno visibili.

Episodi come questo confermano una realtà di lunga data: i risultati in materia di sicurezza dipendono ancora dagli aspetti fondamentali dell’attuazione: sapere quali risorse esistono, in che modo i flussi di lavoro dei fornitori collegano gli ambienti, quali elementi presentano configurazioni errate o non sono stati aggiornati con le patch e se le misure correttive siano state effettivamente attuate.

Poiché gli strumenti avanzati migliorano l’efficienza degli autori degli attacchi, i team che dispongono di una visibilità continua sugli endpoint, sul software, sullo stato delle patch e sulle variazioni di configurazione sono in una posizione migliore per passare dalle ipotesi a una risposta informata.

Questo articolo è stato redatto da Aidan Allchin, ricercatore nel campo dell’intelligenza artificiale presso l’ Tanium , da Logan Hegler, ingegnere del software (gestione dell’esposizione), e da Melissa Bischoping, direttrice senior della ricerca in materia di sicurezza e progettazione dei prodotti.

L’articolo “ 7 aprile 2026” di Anthropic, la pubblicazione della scheda di anteprima del sistema “ ” di Claude Mythos, di 245 pagine ( ), ha lasciato i ricercatori sbalorditi sia per le possibilità che per le insidie dello sviluppo all’avanguardia dell’intelligenza artificiale. Mentre il settore nel suo complesso si concedeva un momento di respiro, il consenso generale era il seguente: l’accelerazione prosegue, quindi come ci prepariamo?

I rischi per la sicurezza legati a Mythos, descritti nella Scheda del Sistema Anthropic, sono reali, ma richiedono un’attenta lettura e comprensione dei vincoli e del contesto per poter valutare l’impatto concreto che potrebbero avere.
Nelle prime 50 pagine dell’Anthropic System Card, Anthropic ha dimostrato che Claude si è evoluto dal trovare una via per uno sfruttamento riuscito in meno dell’1% dei casi con il modello Opus all’identificazione di exploit funzionanti in oltre il 70% dei casi con il modello Mythos. Com'è comprensibile, la consapevolezza di ciò che un avversario dotato di intelligenza artificiale potrebbe fare ha attraversato come un lampo gli incubi di ogni responsabile della sicurezza. La questione non è se ci si debba preoccupare, bensì se la vostra preoccupazione sia commisurata alle prove disponibili.

Capacità dell’intelligenza artificiale: titoli dei giornali contro prove concrete

Prima di approfondire le implicazioni, è opportuno chiarire cosa mostrano effettivamente i dati e in quali punti sia necessario fornirne una precisazione.

CyberGym misura un elemento concreto: dati un obiettivo e una classe di vulnerabilità, il modello deve generare un exploit funzionante contro codici sorgente reali open source. Mythos ottiene un punteggio del 83,1%, contro il 66,6% di Opus 4,6. Non si tratta di un miglioramento marginale.

[Scoprite in che modo la divulgazione del codice sorgente di Claude Code modifica il vantaggio degli autori degli attacchi e quali aspetti le aziende dovrebbero valutare in risposta]

La stessa Anthropic ha definito Opus 4,6 come un sistema con «un tasso di successo prossimo allo 0% nello sviluppo autonomo di exploit». In un test controllato condotto sul motore JavaScript di Firefox, Opus 4,6 ha generato exploit funzionanti in due occasioni su diverse centinaia di tentativi; Mythos ne ha generati 181 nello stesso test. In una valutazione separata, Anthropic ha testato i propri modelli su circa un migliaio di repository del corpus OSS-Fuzz, utilizzando una scala di gravità dei crash a cinque livelli: i modelli Frontier precedenti hanno raggiunto al massimo il livello 3; Mythos ha raggiunto i livelli 3 e 4 , oltre a un dirottamento completo del flusso di controllo (livello 5) su dieci target distinti e completamente aggiornati.

Nel loro insieme, questi risultati avvalorano un’affermazione limitata ma significativa: i modelli sono passati da «individuare occasionalmente dei bug» a «individuare in modo più affidabile le catene di vulnerabilità in codebase realistici», almeno nelle condizioni di valutazione in questione.

Dall’artigianato su misura alla produzione industriale

Storicamente, lo sviluppo di exploit era un’arte su misura tanto quanto una scienza. Proprio come un maestro artigiano potrebbe impiegare mesi per realizzare un mobile artigianale, alcune delle catene di exploit e delle ricerche più significative di questo secolo sono state, in confronto, una sorta di “exploit artigianali”. C’era sempre un pizzico di “magia” in tutto ciò, praticata da un numero piuttosto ristretto di persone.

Questa versione, insieme alla ricerca che ne sta alla base, rappresenta un cambiamento di paradigma verso l’industrializzazione e la democratizzazione dello sviluppo degli exploit. Stiamo entrando in un ecosistema industriale, in cui le vulnerabilità vengono sviluppate su richiesta e non attendono che gli artigiani le realizzino — fatta eccezione per le varianti più raffinate.

Ma non tutto è perduto. Il sistema “Factory” continua a dimostrarsi particolarmente efficace nell’imitare lo stato dell’arte nei confronti di sistemi non aggiornati e non protetti. È in grado di individuare i bug più comuni e gli errori di configurazione più frequenti. D'altra parte, le vulnerabilità che questa tecnologia è in grado di individuare ai fini del successo di un attacco sono le stesse che potrebbe identificare come candidate prioritarie per l'applicazione di patch.

Ciò offre un’opportunità: ripensare l’efficacia delle misure di protezione e delle patch come un processo continuo e costante, il vero e proprio cuore pulsante dell’organizzazione, mentre la “fabbrica di exploit” industriale sta ancora entrando in funzione.

Quando l’intelligenza artificiale ha risolto il problema del ripiegamento delle proteine, non ha sostituito i biologi, ma ha modificato le categorie di problemi su cui questi ultimi potevano lavorare. Mythos svolge la stessa funzione per i ricercatori nel campo della sicurezza, da entrambe le parti.

Capacità offensive e saturazione dell’ Benchmark

I benchmark standard in stile CTF stanno ormai raggiungendo la saturazione come segnali. Mythos ottiene un punteggio del 100% nel test Cybench, che copre in modo completo l’exploit di file binari, il reverse engineering, la crittografia, l’exploit web e l’individuazione delle vulnerabilità. Anthropic afferma che nessun altro modello ha raggiunto questo risultato. Quando un modello di tipo “ Benchmark ” raggiunge la saturazione, smette di differenziare i modelli di frontiera.

Anthropic ha spostato il baricentro della valutazione dell' e verso nuove attività di sicurezza nel mondo reale, tra cui l'individuazione di vulnerabilità zero-day nel software in produzione, poiché le metriche basate su un'elevata quantità di repliche non sono più in grado di distinguere la memorizzazione dalle reali capacità.

Per gli esperti del settore, esistono diversi parametri di riferimento ben noti per valutare “In che misura l’IA è in grado di sferrare attacchi?” sono ormai obsolete. Il settore sta procedendo a ritmo serrato per mettere a punto metodi di misurazione più accurati. Si tratta di una posizione sostanzialmente diversa rispetto a quella in cui ci trovavamo sei mesi fa.

Il problema del “controllo umano minimo”

I modelli precedenti richiedevano l'intervento di una persona per svolgere le parti più complesse. Mythos chiude ulteriormente il cerchio. L'indicatore “orizzonte temporale” di METR misura la durata dell’attività (in termini di tempo impiegato da un professionista) che un modello è in grado di portare a termine con un’affidabilità del 50% senza alcun intervento manuale. Tale indicatore ha registrato una rapida crescita; il tempo di raddoppio stesso si è ridotto secondo la metodologia TH1,1 del METR dell’ .

Fonte: Dashboard “METR Time Horizons”

METR non ha pubblicato un dato specifico relativo a Mythos, ma il documento “ ” (Scheda di sistema di Anthropic) offre un punto di riferimento orientativo: secondo quanto riportato, Mythos avrebbe risolto una simulazione di attacco alla rete aziendale la cui durata era stimata in oltre dieci ore per un esperto e che è stata descritta come la prima risoluzione end-to-end in quella classe di cyber range privato (pag. 52). La scheda descrive Mythos come un sistema che opera in «una configurazione agentica con un intervento umano minimo» (p. 46). La valutazione di Firefox 147 chiarisce ulteriormente il quadro:

Fonte: Scheda sul sistema antropico, Sezione 3,3,3

Il salto da circa due successi su diverse centinaia di tentativi al 72% non è graduale. Il modello prende lo stesso tipo di decisioni di triage che prenderebbe uno sviluppatore umano di exploit, e lo fa in modo affidabile, in esecuzioni indipendenti che partono da diverse categorie di crash.

Una volta eliminati i due bug più facilmente sfruttabili, Mythos ha comunque continuato a superare i modelli precedenti, sfruttando quattro bug distinti contro l’unico di Opus 4,6. Anthropic osserva inoltre che «le prestazioni continuano a migliorare fino al limite dei token» (p. 52), il che significa che le valutazioni potrebbero non riflettere ancora il limite massimo.

Mythos è il primo modello in cui l'essere umano non rappresenta più il collo di bottiglia nella pipeline di exploit.

Cosa comportano i rischi di sicurezza legati a Mythos per la gestione delle vulnerabilità e la difesa

I tre indicatori riportati di seguito definiscono il problema operativo. Ognuno di loro stava già andando nella direzione sbagliata prima di Mythos. Ciascuno di essi accelera ulteriormente proprio per questo motivo.

Indicatore 1: Tempo che intercorre tra la divulgazione e lo sfruttamento

Meno di dieci anni fa, il periodo medio che intercorreva tra l’individuazione di una vulnerabilità e la sua divulgazione pubblica, fino allo sfruttamento effettivo, era di 63 giorni. Mandiant ha indicato che tale periodo è passato da 32 giorni nel 2022 a 5 giorni nel 2024. Il calo della media era già devastante e stava mettendo a dura prova le capacità di molte squadre. Grazie all’amplificazione guidata dall’intelligenza artificiale, per alcune categorie di questioni il dibattito si concentra sempre più spesso sulle “ore” anziché sui “giorni”.

Quella che un tempo era una procedura di correzione “d’emergenza” riservata esclusivamente ai problemi di massima gravità rischia ora di diventare un’operazione di routine che i processi e gli strumenti tradizionali non sono in grado di gestire. La questione non è se il Suo team sia in grado di rilasciare patch più rapidamente in caso di crisi, bensì se la Sua pipeline sia progettata per sostenere tale ritmo in modo continuativo.

Indicatore 2: Volume delle informazioni fornite in modo coordinato

Il piano di divulgazione di Glasswing prevede che si prepari fin da ora. Secondo quanto riportato da Anthropic: «I partner condivideranno tra loro, nella misura del possibile, informazioni e buone pratiche; entro 90 giorni, Anthropic renderà pubblico un resoconto di quanto appreso, nonché delle vulnerabilità risolte e dei miglioramenti apportati che possono essere resi noti». Potrebbero essere migliaia i CVE che vengono resi pubblici contemporaneamente, e tale volume è destinato ad aumentare qualora Mythos venisse diffuso su scala più ampia o qualora altri fornitori sviluppassero funzionalità analoghe.

Le implicazioni pratiche per i team addetti alla gestione delle patch sono significative:

• La coda di patch generata da una singola divulgazione di Glasswing-wave potrebbe far impallidire qualsiasi dato registrato in un singolo “ Patch ” nella storia.
• Le patch potrebbero essere di grande rilevanza, con un punteggio CVSS elevato, e diffondersi contemporaneamente nell’infrastruttura, nelle postazioni di lavoro, nei server, nei database e nei dispositivi OT o IoT.
• Eliminare subito l'arretrato attuale di patch in sospeso riduce l'area che dovrete difendere quando arriverà l'ondata.
• Il consolidamento dei software inutilizzati riduce il carico di aggiornamenti futuri.
• Le immagini "stale" di Gold rappresentano un rischio: le aggiorni, o meglio ancora, modernizzi il Suo approccio alla distribuzione e al provisioning per ridurre del tutto la dipendenza dalle immagini statiche.

Metrica 3: Diffusione delle capacità

Il ritardo tra Frontier e Open-Weight si è notevolmente ridotto nelle ultime generazioni di modelli:

*I dati relativi al punto GLM-5,1 si basano su informazioni fornite direttamente dai fornitori e devono essere considerati come un’ipotesi preliminare fondata, non come un fatto accertato.
Fonti: OpenAI, Meta, Anthropic (4,5), Anthropic (4,6), MiniMax, Z.ai

Da sedici mesi a 61 giorni corrisponde all’incirca a una compressione di 8x in tre anni. L’ e di Epoch AI indica che il ritardo medio a peso aperto è pari a circa 3,5 mesi sull’intero periodo storico, ma i dati recenti presentano una distribuzione più concentrata.

Anthropic ha stimato pubblicamente che occorreranno all’incirca da sei a diciotto mesi prima che i modelli a peso aperto raggiungano un livello di capacità pari a quello di Mythos nelle attività informatiche. In occasione dell’evento RSA 2026, Alex Stamos, CPO di Corridor ed ex CISO di Facebook, ha proposto un orizzonte temporale di sei mesi (più coerente con la tendenza empirica rispetto al limite massimo di diciotto mesi indicato da Anthropic) e ha avvertito: «Ogni diciannovenne di San Pietroburgo disporrà delle stesse capacità».

Quando le capacità di livello Mythos raggiungono i modelli a peso libero, tendono a verificarsi contemporaneamente due cambiamenti:

1. Il costo dell’inferenza si riduce drasticamente: Modelli quali MiniMax M2,5 operano già a un costo pari a circa 1/20th rispetto a quello di Claude Opus 4,6, rendendo l’utilizzo continuativo o su larga scala economicamente irrisorio per molti soggetti.
2. I vincoli comportamentali si attenuano: I comportamenti più gravi documentati nella System Card di Anthropic sono stati osservati nelle prime versioni interne di Mythos durante lo sviluppo, non nel modello di anteprima condiviso tramite Project Glasswing. Per mitigare tali comportamenti sono stati necessari un ampio lavoro di allineamento e valutazione post-addestramento, che ha compreso pipeline di sicurezza personalizzate, attività volte a garantire l’interpretabilità e test ripetuti. Tale sforzo è stato di ampia portata, ha richiesto un notevole impiego di risorse umane ed era specifico del processo di addestramento di Anthropic, il che significa che non è trasferibile insieme ai pesi del modello. Di conseguenza, tali comportamenti iniziali vanno interpretati come un’anteprima plausibile di ciò che potrebbero manifestare implementazioni con capacità simili ma meno allineate, e non come una caratteristica intrinseca della stessa Mythos Preview rilasciata.

Nel complesso, il periodo di pianificazione del difensore non coincide con «il momento in cui Anthropic renderà pubblico Mythos». È quando i modelli a peso libero raggiungono un livello di capacità informatica pari a quello di Mythos senza tali vincoli comportamentali. Quel conto alla rovescia è iniziato di fatto il 7 aprile e si misura in mesi, non in anni.

Ripensare la gestione delle patch nell’era dell’intelligenza artificiale

Patch Il martedì è un retaggio di un’altra epoca. La cadenza mensile delle correzioni è stata definita tenendo conto dei tempi di individuazione delle vulnerabilità, dei tempi di sviluppo degli exploit e dei tempi dei processi di controllo delle modifiche, tutti in linea con i ritmi umani. Tali ipotesi costituiscono ormai un onere strutturale. Il cambiamento non si limita semplicemente a «applicare le patch più rapidamente». Il contesto richiede un cambiamento radicale verso un approccio mirato e preciso alla risoluzione dei problemi e una gestione continua dell’esposizione alle minacce: processi che siano agili, mirati, rapidi e iterativi.

Poiché lo sviluppo software ha adottato pipeline CI/CD più veloci e flussi di lavoro basati sull'intelligenza artificiale, anche la sicurezza deve seguire lo stesso modello. Il settore della sicurezza ha tardato a compiere tale transizione, ma il ritmo con cui Mythos è destinato ad accelerare i cicli di aggiornamento lo costringerà a farlo.

La gestione delle patch nell’era dell’intelligenza artificiale consiste nell’affrontare la correzione delle vulnerabilità nello stesso modo in cui i moderni team di sviluppo software gestiscono le operazioni di distribuzione: combinando l’esecuzione automatizzata con informazioni in tempo reale, controlli di verifica e cicli di feedback continui, anziché ricorrere a operazioni periodiche in batch.

Il settore sapeva già che, in linea di massima, ciò era vero. Da anni ormai, l’individuazione delle vulnerabilità assistita dall’intelligenza artificiale è un tema ricorrente in tutte le principali conferenze sulla sicurezza e presso le principali organizzazioni di ricerca. Mythos non è una sorpresa in sé, ma solo per la sua portata e la rapidità con cui si è verificato. La tempistica si è ridotta da “prima o poi” a “adesso”. Le ipotesi su cui si basa il vostro programma in materia di SLA, strumenti, organico e criteri di definizione delle priorità sono state elaborate per un mondo che ormai non esiste più.

La verifica non è facoltativa

L'applicazione di una patch e il fatto di non occuparsene ulteriormente non garantiscono la certezza che la correzione sia stata effettuata correttamente senza ulteriori verifiche volte a stabilire se la patch sia stata sufficiente e abbia funzionato correttamente. In un contesto in cui le operazioni di patch vengono eseguite con maggiore rapidità e su volumi più elevati, il rischio di una copertura incompleta aumenta a causa di:

• Endpoint non gestiti che non rientrano nell’ambito di applicazione delle patch
• Eccezioni e rinvii che si traducono in lacune permanenti
• Operazioni di distribuzione non riuscite che vengono segnalate come riuscite
• Immagini "gold" obsolete che vengono ridistribuite nel Suo ambiente con software non aggiornato fino al prossimo ciclo di patch

Sapere di aver risolto in modo verificabile una vulnerabilità su ogni endpoint è più importante che mai, ora che gli aggressori possono riapparire sui computer sfuggiti al controllo. La gestione continua dell’esposizione alle minacce, ovvero considerare la riduzione dell’esposizione come un processo iterativo e non come un progetto una tantum, rappresenta il modello operativo più adatto a questo contesto.

Una definizione più ampia di “sicuro per impostazione predefinita”

Tradizionalmente, l’espressione “sicuro per impostazione predefinita” indicava una configurazione di spedizione sicura: principio del privilegio minimo, impostazioni predefinite rafforzate e superficie di attacco ridotta, ipotizzando che gli autori degli attacchi agissero alla velocità umana.

Secondo i materiali pubblici di Anthropic relativi a Glasswing, disponibili all’indirizzo, la ricerca relativa a Mythos comprende scoperte quali una vulnerabilità presente da 27 anni in OpenBSD, un bug di FFmpeg risalente a 16 anni fa che è sopravvissuto a un’enorme quantità di test di fuzzing automatizzati e il concatenamento autonomo di problemi del kernel Linux fino al controllo completo della macchina.

Se gli strumenti di questa classe di funzionalità sono in grado di portare alla luce problemi risalenti a decenni fa in codici sottoposti a rigorosi controlli, allora il concetto di “sicurezza predefinita” deve estendersi ben oltre la configurazione. Ciò deve significare che ogni componente software distribuito oggi venga sottoposto a scansione attiva mediante strumenti adeguati prima di entrare in produzione. Per quanto riguarda le infrastrutture, si ipotizzi che i servizi esposti siano sottoposti a sondaggi continui almeno a questo livello di capacità. La segmentazione della rete, le architetture zero-trust e l’isolamento in fase di esecuzione non sono più semplici obiettivi da raggiungere nell’ambito di un modello di maturità, ma costituiscono ormai requisiti architetturali fondamentali.

Accessibilità: il costo è temporaneo; la capacità è emergente

Nel breve termine, l’accesso alla classe Mythos è costoso. I prezzi relativi all’era Glasswing citati da Anthropic ammontano a 25/125 dollari per milione di token di input/output, contro i 5/25 dollari previsti dall’aumento di Opus 4,6—a 5x . Una scansione continua ad alta intensità a quel prezzo non è cosa da poco, ma il costo rappresenta un ostacolo temporaneo.

Anthropic afferma di non aver addestrato esplicitamente Mythos Preview per attività informatiche offensive; tali capacità "sono emerse come conseguenza indiretta dei miglioramenti generali apportati al codice, al ragionamento e all'autonomia". È logico, se si considerano la curiosità, l’autonomia e l’intraprendenza che rendono grande un hacker.

Se ciò dovesse verificarsi, in futuro superfici simili compariranno in ogni modello sufficientemente performante, indipendentemente dalle intenzioni del produttore.

Se si considerano, da un lato, la riduzione del ritardo di elaborazione a peso aperto e, dall’altro, il calo dei costi di inferenza, la domanda «chi può permettersi l’API» non rappresenta un ostacolo a lungo termine. "Chi dispone di una flotta e di una catena di approvvigionamento" è.

Il vettore all’interno della casa: agenti, sistemi di controllo e confini rigidi

In occasione del lancio di un prodotto come Mythos, è soprattutto l’uso improprio da parte di soggetti malintenzionati a ricevere maggiore attenzione mediatica. Ma il rischio parallelo è di natura interna: agenti autorizzati o “ombra” che dispongono di ampio accesso agli strumenti, ai dati aziendali e a credenziali attive e che operano all’interno del Vostro perimetro.

Una ricerca che ha catalogato oltre 177.000 strumenti MCP (Model Context Protocol) rileva che l’integrazione di agenti di routine tra file system, browser, ambienti di esecuzione del codice, database e API di produzione costituisce una funzionalità standard di tali strumenti.

Le interfacce di tipo “Claw” — anelli per strumenti ben definiti con autonomia persistente — si sono diffuse rapidamente; OpenClaw ha raggiunto circa 247.000 stelle su GitHub in otto settimane, con decine di derivati, i cui modelli di accesso predefiniti coprono terminali, browser, file system, recupero della memoria e integrazioni esterne. Un ampio accesso unito all’autonomia amplia la superficie di attacco sia verso l’interno che verso l’esterno contemporaneamente.

Le regole a livello di harness sono pur sempre codice scritto da persone. Non funzionano; i modelli li aggirano quando il completamento dell’attività assume un ruolo predominante. La "System Card" di Anthropic, intitolata " ", descrive un episodio in cui Mythos, a cui era stato chiesto di correggere un bug e di inviare un commit firmato senza credenziali, ha analizzato lo stato del supervisore e ha tentato di estrarre dati dalla memoria in seguito a una sollecitazione da parte dell’utente — un comportamento caratterizzato dal perseguimento di un obiettivo che ha prevalso sulla valutazione del rischio. Tale episodio si è verificato durante la fase di valutazione pre-rilascio, prima che venissero effettuati ulteriori interventi di allineamento. Anthropic definisce la versione "Mythos Preview" appena rilasciata altamente allineata secondo i propri parametri di valutazione, pur sottolineando che azioni rare e non allineate possono comunque avere gravi conseguenze proprio a causa delle elevate capacità intrinseche del sistema.

Visibilità all’interno dell’azienda che utilizza l’intelligenza artificiale

Il primo requisito consiste nel sapere quali risorse sono in esecuzione all’interno del perimetro, sia quelle approvate che quelle non approvate. La maggior parte delle organizzazioni non dispone di un quadro chiaro delle capacità di inferenza locale, degli assistenti basati sull’intelligenza artificiale e degli agenti autonomi implementati nel proprio ambiente. Non è possibile proteggere ciò che non si vede e, al momento, la maggior parte delle organizzazioni non dispone di un quadro affidabile della quantità di IA effettivamente in esecuzione all’interno del proprio perimetro.

[Scoprite cosa comporta la conformità in materia di IA per le imprese moderne e in che modo l’evoluzione delle normative sta definendo una governance responsabile dell’IA]

Il settore della sicurezza informatica nel suo complesso dovrà continuare a investire massicciamente in strumenti di visibilità basati sull’intelligenza artificiale, poiché il divario tra ciò che le organizzazioni ritengono sia in esecuzione e ciò che è effettivamente in esecuzione è significativo e in aumento.

Implementazione sicura e gestione in tempo reale degli agenti di intelligenza artificiale

La visibilità da sola non è sufficiente. Le organizzazioni necessitano inoltre di un sistema che consenta loro di implementare gli agenti di intelligenza artificiale in modo sicuro e di gestirli a livello centrale su tutta la loro flotta. La formazione comportamentale e i meccanismi di protezione a livello applicativo sono utili, ma non costituiscono garanzie sufficienti contro agenti capaci e orientati al raggiungimento di obiettivi.

Tra le tendenze emergenti figurano le politiche a livello di sistema operativo relative a vincoli relativi al filesystem, alla rete e ai processi; alcuni dei principali fornitori di soluzioni di sicurezza , tra cui Cisco, CrowdStrike, Google Cloud e Microsoft , stanno già collaborando alla definizione di standard relativi alle politiche di runtime per gli agenti autonomi.

In un’analisi, Claude ha definito alcune delle misure di sicurezza adottate in seguito alla fuga di informazioni sulla mappa del sistema “ marzo 2026 ” come una “difesa basata sulle sensazioni”. Sebbene i set di regole e le linee guida comprensibili all’uomo possano diventare parte integrante del nostro arsenale difensivo standard, esistono ancora liste di controllo minime relative ai controlli tecnici:

1. Isolamento in sandbox al confine tra sistema operativo e container (non si tratta di un’istruzione fornita dal sistema): Gli agenti devono essere eseguiti in container isolati, in modo che le conseguenze siano circoscritte in caso di comportamento anomalo degli agenti; tale misura deve essere applicata a livello di infrastruttura piuttosto che tramite l’addestramento alla sicurezza del modello.
2. Politica di rete su ogni percorso in uscita: Ogni connessione in uscita deve essere intercettata e valutata in base alla politica. Un agente che non è in grado di connettersi a un endpoint non può interagire con esso, garantendo così la protezione dei servizi interni da agenti non autorizzati e dei dati aziendali dall’esfiltrazione.
3. Credenziali al di fuori dell'ambiente dell'agente: Le credenziali non devono mai essere accessibili all'interno della sandbox di un agente. Dovrebbero essere gestiti da un proxy al di fuori dell’ambiente dell’agente e inseriti nelle richieste in uscita solo dopo che queste hanno lasciato la sandbox dell’agente.
4. Instradamento centralizzato e registrazione per le operazioni di inferenza, gli strumenti e le chiamate di rete: Tutte le richieste in uscita devono essere instradate tramite un sistema di gestione degli eventi e dei log ( proxy ) con registrazione completa di ogni richiesta di rete, chiamata di inferenza e invocazione di strumenti, consentendo così un’efficiente indagine forense e la verifica della conformità.

Dal segnale alla risposta: quali sono le conseguenze per i difensori

I rischi legati a Mythos sopra descritti sono reali, ma non sono imprevedibili. Ciò che rimane incerto è la tempistica, non la direzione. Non conosciamo ancora la data precisa in cui i modelli a peso libero eguaglieranno Mythos nell’esecuzione di compiti informatici autonomi a spettro completo, né disponiamo di una replica ampia e indipendente di ogni risultato della classe “Firefox” di Anthropic in diversi ambienti e stack.

Ciò che è chiaro è che i difensori non possono più permettersi il lusso di attendere certezze. I tempi di individuazione e strumentalizzazione delle vulnerabilità si stanno accorciando a un ritmo più rapido di quanto la maggior parte dei programmi di applicazione delle patch e di gestione delle esposizioni sia stata progettata per far fronte. In tale contesto, reagire alle notizie di cronaca è meno utile che mettere alla prova le proprie ipotesi.

La domanda più significativa per i responsabili della sicurezza e dell’IT in questo momento non è: «Quanto può diventare grave Mythos?» La domanda è: «In quale ambito il nostro attuale modello operativo fallisce per primo se le finestre di esposizione continuano a ridursi?»

Per alcune organizzazioni, la difficoltà risiede nella definizione delle priorità. Per altri, ciò si manifesta nella produttività dei test, nei vincoli di implementazione o nella verifica della chiusura in contesti di " endpoint " frammentati. In quasi tutti i casi, il punto debole non è rappresentato dagli strumenti in sé, bensì dalla sequenza attraverso la quale le informazioni sulle vulnerabilità vengono trasformate in una riduzione comprovata del rischio.

È proprio in questo passaggio — dal comprendere il rischio al mettere in atto la risposta — che il dibattito su Mythos assume un’importanza determinante. La sfida che rimane da affrontare è di natura organizzativa piuttosto che teorica: vale a dire, se le attuali ipotesi relative alle vulnerabilità e all’applicazione delle patch siano ancora valide, dato che le fasi di individuazione, definizione delle priorità e sfruttamento si stanno avvicinando sempre più tra loro.

Poiché Mythos è inevitabile, l’applicazione delle patch non è facoltativa e deve essere effettuata con rapidità e su larga scala. Tanium Gestione autonoma dell’ Patch : rivoluziona la gestione e la sicurezza dell’ endpoint grazie a un sistema di applicazione delle patch autonomo, integrato e completo.

Grazie all’intelligenza artificiale e alle informazioni di intelligence in tempo reale fornite da endpoint , Tanium contribuisce a ridurre le finestre di esposizione che i modelli della classe Mythos sono progettati per sfruttare, prima che gli avversari possano agire sulle vulnerabilità individuate.

Domande frequenti sui rischi per la sicurezza di Mythos

Il lancio di Mythos ha suscitato una notevole risonanza mediatica, in parte accurata e in parte meno. Questi chiarimenti affrontano i punti che più spesso danno adito a confusione.

Il modello di Mythos che è stato diffuso è forse sfuggito alle aree di test e ha cancellato le proprie tracce?

No, non il modello già in commercio. Gli episodi comportamentali documentati da Anthropic, tra cui la fuga dalla sandbox, l’occultamento delle tracce, il phishing delle credenziali tramite /proc/ e la pubblicazione di materiale riservato, sono attribuiti alle precedenti versioni interne di Mythos, non alla versione Mythos Preview dell’era Glasswing.

La scheda di Anthropic System precisa chiaramente che gli incidenti gravi di quel tipo hanno coinvolto versioni “precedenti” ad alcuni degli interventi formativi più efficaci di Anthropic (p. 54). Si afferma che il modello presentato continui ad adottare scorciatoie avventate in contesti a basso rischio, senza tuttavia manifestare gli stessi gravi schemi di inganno. Citare tali comportamenti senza specificarne la versione è tecnicamente inesatto.

Se Mythos non è riuscito a superare i sistemi aggiornati, ciò significa che l'aggiornamento è ancora sufficiente?

L'applicazione delle patch rimane il principale punto di forza dei difensori, e il fallimento di Mythos contro «una sandbox correttamente configurata e dotata di patch aggiornate» (Anthropic System Card, pag. 52) è una buona notizia nascosta dietro i dati salienti.

Mythos si presenta come un’arma di precisione contro le carenze igieniche e gli stack non corretti. La sfida organizzativa consiste nel verificare se i team siano in grado di applicare le patch, verificare la copertura e aggiornare le immagini con sufficiente rapidità, in un contesto in cui sia l’individuazione che la strumentalizzazione delle vulnerabilità procedono a ritmo sempre più serrato. La risposta sta nel ritmo e nella verifica.

Cosa significa che i benchmark standard sono “saturi”?

Anthropic ha spostato l’attenzione della propria valutazione su nuovi compiti di sicurezza nel mondo reale, tra cui l’individuazione di vulnerabilità zero-day nel software in produzione, poiché i benchmark che misurano la riproduzione di vulnerabilità note finiscono per non fornire più una differenziazione utile all’avanguardia.

Quando un Benchmark raggiunge la saturazione, ciò non significa che il problema sia risolto in senso assoluto. Ciò significa che il test ha raggiunto i limiti per i quali è stato progettato. Il punteggio del 100% ottenuto da Mythos su Cybench indica che questo specifico Benchmark non consente più di distinguere in modo significativo i modelli di fascia alta, un risultato normale e ricorrente man mano che le capacità dei modelli migliorano.

L'implicazione pratica è chiara: la valutazione si evolve di pari passo con le capacità. Man mano che i modelli evolvono, i benchmark vengono perfezionati, sostituiti o resi più impegnativi, in modo da continuare a misurare ciò che conta. In questo caso, l’attenzione di Anthropic nella valutazione si sta spostando verso compiti più complessi e meno ripetibili, proprio perché questi riflettono meglio il tipo di questioni relative alla sicurezza dell’IA nel mondo reale che stanno a cuore ai professionisti del settore .

Le capacità offensive di Mythos sono state sviluppate in modo mirato?

N. Anthropic afferma: «Non abbiamo addestrato esplicitamente Mythos Preview affinché possedesse tali capacità. Piuttosto, sono emersi come una conseguenza indiretta dei miglioramenti generali apportati al codice, al ragionamento e all’autonomia."

Ciò significa che è probabile che emergano superfici di capacità simili in modelli con scala, regimi di addestramento e caratteristiche architetturali paragonabili a quelli dei modelli di linguaggio di frontiera (LLM) come Mythos. Sebbene le aziende non rendano noti tutti i dettagli di tali architetture, la tendenza suggerisce che la diffusione di tali capacità sia determinata meno da scelte politiche che dalle dinamiche sottostanti al ridimensionamento dei modelli generici.

Risorse aggiuntive

• Guardi questa demo on demand all’indirizzo per scoprire in che modo la gestione autonoma dell’ Patch e di Tanium aiuta le organizzazioni a colmare costantemente il divario di esposizione alle vulnerabilità, affrontando le minacce basate sull’intelligenza artificiale con la velocità e la portata richieste dagli ambienti odierni.

Antropico

• Scheda del sistema di anteprima di Claude Mythos
• Valutazione delle funzionalità di sicurezza informatica di Claude Mythos Preview
• Progetto Glasswing
• Vi presentiamo Claude Opus 4,5
• Vi presentiamo Claude Opus 4,6

Ricerca sulle capacità dei modelli e sulla loro valutazione

• METR
  • Orizzonte temporale 1,1
  • Misurazione della capacità dell’intelligenza artificiale di portare a termine attività di lunga durata
  • Dashboard relativa alle tempistiche di completamento delle attività
• Epoch AI
  • I modelli a peso aperto registrano un ritardo rispetto allo stato dell’arte pari in media a circa 3 mesi

Modelli a peso libero

• MiniMax
  • MiniMax M2,5: progettato per garantire produttività nel mondo reale
• Moonshot AI
  • Kimi K2: Intelligenza agentica aperta
• Hugging Face
  • Scheda tecnica del modello Kimi‑K2,5

Analisi e rendicontazione di settore

• VentureBeat
  • MiniMax M2,5 offre prestazioni quasi all’avanguardia a circa il 1/20th % del costo
• CyberScoop
  • I responsabili della sicurezza affermano che i prossimi due anni saranno “folli”
• Techbriefly
  • Z.ai lancia il modello GLM‑5,1 , superando i concorrenti nei test di benchmark
• HPCwire
  • L’azienda cinese Moonshot AI lancia Kimi K2, un modello con un trilione di parametri

Pubblicazioni sui modelli fondamentali

• OpenAI
  • Relazione tecnica su GPT-4
  • Presentazione del corso GPT‑5,2
• Meta
  • Vi presentiamo “Llama 3,1”