L’ANALISI
GLM-5.3 e cyber: il modello non è il solo controllo da verificare
Anthropic misura exploit end-to-end e aggiramento dei rifiuti di GLM-5.3. Ecco come separare capacità, accesso agli strumenti, isolamento, logging e rollback.
In breve: Il dato operativo non è soltanto che GLM-5.3 costruisce exploit più avanzati: è che i rifiuti del modello possono cambiare radicalmente con il contesto o con una modifica dei pesi. Per un deployment serio servono controlli esterni al modello: identità separate, sandbox, allowlist, egress limitato, log, kill switch e patch rapide.
Che cosa è stato misurato
Anthropic riferisce 50 exploit end-to-end riusciti su 410 tentativi di ExploitBench. Su un benchmark interno di binary exploitation, GLM-5.3 ha completato il controllo del flusso nel 4% delle prove, contro il 6% di Claude Mythos Preview. Sono risultati di laboratorio, non incidenti osservati in produzione.
Perché il salto è materiale
Z.ai descrive GLM-5.3 come lo stesso modello base di GLM-5.2 con post-training più ampio e dichiara più del doppio dei risultati del predecessore in benchmark di exploitation. Le due fonti concordano sul salto di capacità, pur avendo interessi e protocolli diversi.
I rifiuti non sono una barriera sufficiente
Nei test Anthropic il modello ha rifiutato gli ordini malevoli diretti, ma ha interagito nel 64% dei casi con una falsa storia di copertura e nel 92% con reasoning precompilato. Dopo una modifica dei pesi chiamata abliteration, la quota è salita al 100%. Queste percentuali descrivono quel setup e non ogni possibile configurazione.
Il confine va spostato fuori dal modello
Un agente cyber non dovrebbe ottenere rete, segreti o strumenti perché il modello ha accettato un prompt. Autorizzazioni minime, ambienti effimeri, egress controllato e approvazioni per le azioni ad alto impatto devono restare indipendenti dai rifiuti generativi.
Condizioni e limiti
Anthropic è autore della valutazione e concorrente del produttore; Z.ai pubblica a sua volta risultati interni. Alcune simulazioni sono dichiarate imperfette e i benchmark dipendono da budget, harness e tool. Serve una replica indipendente prima di confrontare deployment reali.
Checklist per un deployment controllato
- Bloccare l’accesso predefinito a rete pubblica, credenziali e sistemi di produzione.
- Eseguire il modello in sandbox effimere con filesystem e processi isolati.
- Separare identità del modello, orchestratore e operatore umano.
- Applicare allowlist agli strumenti e approvazione obbligatoria alle azioni distruttive.
- Registrare prompt, tool call, risultati, hash del modello e configurazione.
- Definire kill switch, timeout, limiti di spesa e limiti di tentativi.
- Misurare il tempo tra disclosure, patch e distribuzione del fix.
- Ripetere test benigni e avversariali dopo ogni cambio di pesi o runtime.