SonicWall Warns of Two SMA1000 Zero-Days Exploited in Attacks

The vulnerabilities CVE-2026-83549 and CVE-2026-83548 can be chained for unauthenticated remote code execution.

The post SonicWall Warns of Two SMA1000 Zero-Days Exploited in Attacks appeared first on SecurityWeek.

https://www.securityweek.com/sonicwall-warns-of-two-sma1000-zero-days-exploited-in-attacks/




Fifth Third Bank Strengthens Security With Security Operations Center

Recently, Fifth Third Bank announced a partnership with March Networks to strengthen it’s security system.

https://www.securitymagazine.com/articles/102548-fifth-third-bank-strengthens-security-with-security-operations-center




Prova digitale e anti-forensics: cosa cambia con l’AI generativa

L’adozione di sistemi di intelligenza artificiale generativa sta producendo una trasformazione profonda nel modo in cui il diritto processuale penale interpreta, valuta e utilizza la prova digitale. Ciò che per anni è stato considerato un elemento relativamente stabile e verificabile ovvero il dato digitale come traccia dell’origine di un evento o di un’azione entra oggi in una fase di progressiva instabilità epistemica. La possibilità di generare contenuti artificiali altamente coerenti, completi di metadati plausibili e strutture tecniche formalmente corrette, incrina infatti uno dei presupposti storici della digital forensics: la corrispondenza tra traccia e origine.

Questo articolo si inserisce all’interno della serie di approfondimenti a cura di Cosimo de Pinto dal titolo Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale”. L’approfondimento analizza la frattura introdotta dall’AI generativa nel paradigma tradizionale della prova informatica, evidenziando come la “plausibilità sintetica” possa sostituirsi alla tracciabilità dell’origine come criterio implicito di affidabilità.

Nel testo si esamina la discontinuità tra anti-forensics classica e nuove tecniche abilitate dall’intelligenza artificiale, mettendo in luce il passaggio da strategie di occultamento o distruzione della prova a sistemi capaci di costruire evidenze artificiali credibili e difficilmente distinguibili da quelle autentiche. L’analisi si concentra inoltre sulle implicazioni processuali di tale evoluzione, con particolare attenzione ai rischi per la valutazione giudiziale della prova digitale e alle possibili ricadute sulla presunzione di innocenza e sulla libertà personale.

La fine dell’innocenza digitale

L’AI generativa incrina il presupposto che la prova digitale rifletta sempre la propria origine.

La digital forensics si è sviluppata, nel corso dei suoi tre decenni di storia disciplinare, attorno a un presupposto implicito: i dati digitali conservano tracce della propria origine, e tali tracce possono essere estratte, interpretate e presentate come prova con ragionevole certezza scientifica. Un file aveva una biografia verificabile: nasceva in un momento preciso, recava l’impronta del software che lo aveva generato, i metadati del sistema operativo, le impronte dell’hardware. Su questo fondamento, ben descritto nella manualistica di riferimento, si è costruita l’intera architettura processuale della prova digitale nei sistemi giuridici occidentali.

Dal paradigma classico alla frattura epistemica

Computer forensics classica Scenario AI generativa
Presupposto di base Le tracce digitali riflettono l’origine del dato Un contenuto può simulare un’origine credibile
Obiettivo dell’analisi Ricostruire eventi e attribuire provenienza Verificare anche la possibilità di un’origine sintetica
Segni di manipolazione Spesso lasciano anomalie residue Possono imitare pattern statisticamente plausibili
Ruolo dell’esperto Interpretare tracce e coerenze tecniche Corroborare, autenticare e contestualizzare
Rischio giuridico Errore tecnico circoscritto Potenziale violazione della libertà personale

L’avvento dei modelli generativi di intelligenza artificiale, in particolare dei Large Language Models (LLM), dei modelli text-to-image, dei sintetizzatori vocali neurali e dei sistemi di video synthesis, ha introdotto nella catena della prova digitale una variabile che i framework forensi tradizionali non erano stati progettati per gestire: la plausibilità sintetica. Un documento, un’immagine, una registrazione audio o video possono oggi essere generati artificialmente in modo da superare non soltanto la percezione umana, ma anche una parte significativa delle analisi strumentali disponibili ai laboratori forensi. Come osservato dalla letteratura tecnica più recente, gli avversari non si limitano più a nascondere le prove: le costruiscono, le avvelenano e orientano l’investigatore verso una narrazione falsa.

Le conseguenze di questa trasformazione non sono confinabili all’ambito tecnico. Nei procedimenti penali, ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale. Un soggetto innocente può essere condannato sulla base di una conversazione WhatsApp mai avvenuta, di un’immagine fotografica manipolata, di un video che lo mostra in un luogo in cui non si è mai recato, di un log di sistema artatamente costruito per collocarlo in prossimità di un reato. L’AI non mente come un essere umano: produce output statisticamente coerenti, difficili da smascherare con gli strumenti tradizionali, e capaci di ingannare persino analisti esperti.

Ogni errore nella valutazione di una prova digitale si traduce in una potenziale violazione della libertà personale.

Il presente paper analizza le intersezioni tra AI generativa, tecniche di anti-forensics e il concetto giuridico di prova digitale, con attenzione alle implicazioni pratiche per consulenti tecnici, avvocati e magistrati. Vengono esaminate le principali superfici di attacco, le tecniche di evasione forense abilitate dall’AI, i framework di auditabilità esistenti, le lacune normative che rendono urgente un ripensamento del valore probatorio del dato digitale e, soprattutto, i rischi concreti per la libertà delle persone che derivano da un approccio acritico all’impiego dell’AI in sede processuale.

Metodo, contributo e domanda di ricerca

Metodo. Sintesi critica interdisciplinare che incrocia letteratura peer-reviewed, casi documentati, standard normativi e implicazioni processuali della prova digitale nell’era dell’AI generativa.

Contributo. Un quadro di sintesi tra tecnica di attacco, artefatto colpito, contromisure e rischio residuo; ricostruzione del nesso tra auditabilità tecnica e tenuta probatoria; proposta di principi guida per una digital forensics AI-resistant.

Domanda di ricerca. In che modo l’AI generativa trasforma la natura della prova digitale e quali condizioni metodologiche e giuridiche sono necessarie per conservarne l’affidabilità?

Questo paper affronta una delle sfide più critiche e meno sistematizzate dell’attuale panorama della sicurezza informatica applicata al diritto: l’impatto dell’intelligenza artificiale generativa sull’affidabilità delle prove digitali nei procedimenti penali. Non si tratta di uno scenario futuro. Le tecniche qui analizzate (data poisoning, log crafting, PRNU manipulation, deepfake, voice cloning, evasion attacks) sono operative già oggi, e i loro effetti sul sistema giustizia sono documentabili. Il taglio è deliberatamente duplice, tecnico e giuridico, perché duplice è il pubblico cui il problema si rivolge: professionisti della sicurezza, consulenti tecnici d’ufficio e di parte, magistrati e avvocati che si trovano a maneggiare prove digitali la cui affidabilità non può più essere data per scontata.

Sul piano del metodo, il lavoro è una sintesi critica di taglio interdisciplinare. Sul versante tecnico incrocia la letteratura peer-reviewed su anti-forensics e adversarial machine learning con casi documentati di rilevanza processuale o geopolitica; sul versante giuridico procede a un’analisi dottrinale e giurisprudenziale del diritto della prova, ancorata alla normativa italiana ed europea vigente e agli standard tecnici internazionali della famiglia ISO/IEC 27000. Le fonti sono state selezionate privilegiando, ove disponibili, gli atti originali (paper, whitepaper, testi normativi, massime ufficiali) rispetto alle fonti secondarie.

Per onestà epistemica, ogni affermazione tecnica viene qualificata secondo tre gradi di evidenza, esplicitati nel testo: risultato dimostrato sperimentalmente in letteratura; condotta documentata in un caso reale; rischio metodologico emergente, ipotizzato in via teorica ma non ancora consolidato in giudicato.

Il contributo originale è triplice: un quadro di sintesi che mette in relazione ciascuna tecnica di attacco con l’artefatto forense colpito, la contromisura di rilevazione e il rischio residuo (sezione 5); un raffronto comparato tra l’ordinamento italiano e il modello angloamericano (sezione 7); e un framework forense resistente all’AI articolato in cinque principi operativi e quattro proposte normative (sezione 10). La domanda di ricerca che tiene insieme l’intero discorso è la seguente: a quali condizioni una prova digitale generata o mediata da sistemi AI può fondare un giudizio di responsabilità penale senza violare la presunzione di innocenza e il diritto a un equo processo?

Anatomia dell’anti-forensics tradizionale e la discontinuità dell’AI

Dalle tecniche che cancellano le tracce a un’AI che le costruisce: una rottura qualitativa, non solo quantitativa.

L’anti-forensics prima dell’AI

La disciplina dell’anti-forensics, intesa come l’insieme delle tecniche volte a ostacolare, fuorviare o rendere impossibile l’analisi forense di un sistema digitale, è quasi coeva alla nascita della computer forensics stessa. Harris la definisce come qualsiasi tentativo di compromettere la disponibilità o l’utilità delle prove in un processo forense.

Le tecniche classiche si articolano in quattro categorie principali:

  • distruzione dei dati (data destruction) tramite sovrascrittura multipla secondo lo standard DoD 5220.22-M, degaussing o distruzione fisica del supporto;
  • occultamento dei dati (data hiding) mediante steganografia, cifratura di volumi interi (VeraCrypt, BitLocker) e slack space exploitation;
  • trail obfuscation mediante applicazioni portable, timestamp manipulation (Timestomp) e cancellazione selettiva dei log di sistema;
  • attacchi alla capacità di analisi attraverso exploit nei tool forensi (FTK, EnCase, Autopsy), file artatamente costruiti (crafted) e tecniche anti-VM e anti-sandbox.

La caratteristica comune di queste tecniche è che esse lasciano tracce della propria applicazione: assenza dove dovrebbe esserci presenza, anomalie statistiche, pattern inusuali. In questa prospettiva, la forensics tradizionale lavora spesso sulla deviazione rispetto all’atteso: l’anti-forensics classica mirava a cancellare, occultare o rendere non interpretabile l’evidenza. Nell’ecosistema AI la logica cambia radicalmente.

La discontinuità dell’AI: quando l’assenza non fa rumore

L’AI generativa introduce una rottura epistemica nel paradigma descritto. Il problema non è produrre contenuti falsi: è produrre contenuti coerenti con le aspettative statistiche di un analista forense. Un LLM avanzato istruito a generare la trascrizione di una conversazione WhatsApp produrrà testo con le peculiarità linguistiche del presunto autore, con riferimenti contestualmente plausibili e struttura temporale coerente; se integrato con un generatore di metadati, produrrà file con timestamp consistenti, encoding corretto, struttura interna del database SQLite di WhatsApp formalmente valida.

La differenza rispetto all’anti-forensics tradizionale è qualitativa, non soltanto quantitativa: non si tratta necessariamente di un’anti-forensics più efficiente, ma di una crisi del concetto stesso di autenticità digitale. Il bersaglio reale diventa ciò che il modello vede: dati, log, metadati, timestamp, immagini, testo, prompt, contesto RAG, workflow, plug-in, API e catena software. L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve. Se input e contesto sono manipolati, la conclusione può essere tecnicamente elegante e probatoriamente falsa.

L’AI non mente in senso umano; produce un output coerente rispetto all’input e al contesto che riceve.

L’approfondimento ha mostrato come l’AI generativa stia alterando in modo strutturale il concetto stesso di prova digitale, spostando l’attenzione dalla tracciabilità dell’origine alla plausibilità sintetica del contenuto. Questo passaggio segna una discontinuità profonda per la digital forensics e apre scenari in cui la distinzione tra dato autentico e dato costruito diventa sempre più complessa da stabilire, con conseguenze dirette sul piano processuale e sulla tutela della libertà personale.

Il prossimo articolo approfondirà le principali tecniche anti-forensics assistite dall’AI insieme alle nuove superfici di attacco lungo la catena della prova digitale, dai documenti alle comunicazioni fino al codice generato automaticamente.

Per un inquadramento più completo e sistematico, è possibile approfondire il paper di Cosimo de Pinto Quando l’AI mente bene – Deepfake, prova digitale e anti-forensics nel processo penale: la lettura consente di comprendere in modo organico le dinamiche tra attacco, prova digitale e rischio probatorio, offrendo un riferimento utile sia per l’analisi tecnica sia per l’applicazione nel contesto processuale.

 

https://www.ictsecuritymagazine.com/articoli/prova-digitale/




Security Leaders Share Advice for Insider Threat Awareness Day

This Insider Threat Awareness Day, security leaders share their thoughts alongside advice on how to reduce insider threats.

https://www.securitymagazine.com/articles/102538-security-leaders-share-advice-for-insider-threat-awareness-day




5 AI Attack Patterns Organizations Can’t Ignore

Artificial intelligence (AI) technology is changing trust, access, execution, and methods of deception. With 88% of organizations using AI in at least one business function, associated risks have snowballed into a clear and present danger. As AI-driven risks continue to evolve, security teams must learn to stay ahead of the attack patterns.

1. Document Forgery is a Low-Effort Attack Path

Synthetic document fraud is a fast-spreading disease. AI image systems like ChatGPT have made it easy to create sensitive documents like passports, IDs, receipts, and supporting records. The problem isn’t that fake documents look genuine, but that we are seeing the rise of zero-knowledge threat actors create forgeries with a few prompts and little effort. Such AI-driven forgeries put pressure on onboarding, KYC, vendor validation, and approval workflows that still treat documents as a sign of trust. An attacker only needs a foot in the door, and if a document looks authentic enough to move a step further into the system, the attacker has gained ground.

2. Malicious AI Services Making Cybercrime Scalable

When large language models (LLMs) appeared on the scene, they were just another attack vector criminals could exploit to launch attacks. But criminals soon realized that mainstream LLMs have comprehensive guardrails. This disappointment was short-lived with the arrival of uncensored GenAI tools such as WormGPT, which enable malicious operations at scale. After the shutdown of WormGPT, other variants entered, such as Grok, Mixtral AI, and Kawai GPT. There is no dearth of malicious AI services that can help criminals generate phishing lures, impersonate content, or produce malicious code at scale.

“As AI becomes more deeply embedded across diverse functions such as operations, finance, and marketing, the boundaries between untrusted external and internal inputs begin to blur.”

3. The Rise of “Living off AI” Attacks

As AI becomes more deeply embedded across diverse functions such as operations, finance, and marketing, the boundaries between untrusted external and internal inputs begin to blur. An AI model can be compromised by placing malicious instructions inside content that enables AI workflows. This can happen through a malicious support request, message, or document submitted from the outside and ingested via an AI-connected tool. The AI model interprets instructions as actionable context and executes it with legitimate internal permissions. The attacker can use the organization’s own AI workflow against itself to expose sensitive data and manipulate critical internal systems.

4. The Evolved Nature of Prompt Injections

An indirect prompt injection attack, as seen in techniques like HashJack, is yet another cause for concern. It is like visiting your trusted neighborhood store, buying things without a second thought, then later realizing the invoice was padded. The attack surface is no longer limited to malicious web pages but also includes trusted web interactions. In a technique like HashJack, a set of harmful instructions is hidden after the # symbol in a legitimate URL. The site is genuine, and the link looks harmless, but the AI browser assistant can ingest those hidden instructions.

5. Trusted AI Extensions Co-opted in Attacks

Weaponization of trusted AI extensions, illustrated by the abuse of Claude Skills, is becoming an execution-layer risk when users are allowed to install or approve code modules that extend the model’s capabilities. Here, a legitimate “skill” can be modified with minor edits to hide malicious behavior; because it looks safe, it passes routine review. Users believe they are enabling a useful capability but unwittingly set the stage for this corrupted ”skill” to deliver malicious code.

Risks of AI in Business Functions
Image: Isasoulart / iStock / Getty Images Plus / Via Getty Images

Security AI Inputs and Agent Interactions

The default assumption should be not to trust AI inputs. In practical terms, this means all prompts, attachments, URLs, copied text, and important context must be validated, sanitized, and contextually isolated before they can influence an AI workflow.

Organizations also need a governance framework that accounts for the widespread adoption of AI, one that helps build a definitive inventory of AI-enabled tools, map the processes in which these are embedded, and identify critical integrations. This helps define human oversight and approval requirements for high-risk AI actions, including systemic changes, data exports, and similar activities. Finally, it is imperative not to rely on visual or content-based signals alone, and to strengthen document verification, validation, and anomaly detection.

https://www.securitymagazine.com/articles/102470-5-ai-attack-patterns-organizations-cant-ignore




6 Data Breaches to Know About (July 2026)

@import url(‘https://fonts.googleapis.com/css2?family=Nunito+Sans:ital,opsz,wght@0,6..12,400;0,6..12,500;0,6..12,600;0,6..12,700;1,6..12,400;1,6..12,500;1,6..12,600;1,6..12,700&family=Nunito:ital,wght@0,400;0,500;0,600;0,700;1,400;1,500;1,600;1,700&display=swap’); h3 { font-weight: bold; font-size: 18px; color: #C72026; } figure { padding: 4px; margin: auto; } figcaption { color: #404144; Nunito Sans’, Arial, sans-serif; font-size: 14px; padding: 10px; text-align: left; }

Lock it Down Podcast logo

6 Data Breaches to Know About (July 2026)

Security magazine takes a look at 6 data security stories from this month.

Recent research shows that 2026 is currently on track to setting a new record for data breaches. Already, this year has surpassed 2025 in victim breach notifications, largely due to notable mega-breaches that have occurred in the first half of the year. 

Just in the last few weeks, several data breaches made headlines. Today, Security magazine takes a look at six incidents from July 2026. 

1. DHS Information-Sharing Environment

Hackers accessed an information-sharing platform for the Department of Homeland Security. While the data exchanged in this environment is unclassified, it still contains sensitive information such as details on potential threats or persons of interest. 

Learn more about the DHS breach

2. KDDI

KDDI Corporation, a Japanese telecommunications company, experienced a breach that affected customer credentials. Initial reporting indicates 12.2 million emails and 7.6 million passwords were compromised.

Learn more about the KDDI breach

3. Accenture

Accenture, an IT services organization, confirmed it experienced a data breach following a hacker’s claims that 35GB had been stolen from the organization. The hacker also claims to have stolen source code, which experts consider particularly concerning. 

Learn more about the Accenture breach

4. Craneware

Healthcare software provider Craneware confirmed an unauthorized user gained access to certain subsets of data, including customer, employee and partner information. 

Learn more about the Craneware breach

5. Suno

The AI music generation tool Suno was breached in November 2025, but in July, it was revealed that around 55 million emails were impacted by the incident. The hacked data also revealed Suno had been allegedly scraping copyrighted content. 

Learn more about the Suno breach

6. Chick-Fil-A

A data breach impacting Chick-Fil-A may have exposed the payment information of customers. The last four digits of debit/credit cards may be compromised, according to the restaurant chain, along with other personal information. 

Learn more about the Chick-Fil-A breach

https://www.securitymagazine.com/articles/102414-6-data-breaches-to-know-about-july-2026




How Retailers Are Approaching Modernization

Research from Genetec shows modern difficulties are shaping how retail organizations approach modernization. When asked to identify their greatest operational challenges, retailers reported that outdated physical security infrastructure (40%), staff training/upskilling (38%), hiring talent (37%), and outdated IT infrastructure (33%) were the most significant hurdles. 

Many retail organizations are aiming to modernize aging environments prior to expanding their technology footprint. Instead of overhauling systems, retail organizations are seeking measured strategies for modernization.

  • 54% plan to utilize existing technology to manage new challenges
  • 51% anticipate using AI to support security processes
  • 48% intend to consider new security systems for specific uses
Image courtesy of Genetec

https://www.securitymagazine.com/articles/102506-how-retailers-are-approaching-modernization




OpenAI Confirms ChatGPT Outage

On August 19, OpenAI confirmed a ChatGPT outage affecting users worldwide.

The outage began around 8 pm EDT and lasted about an hour. The outage affected logins, signups, and prevented users from loading current or previous chats.

“This outage is a useful reminder that we need to distinguish between the consumer-facing application and the infrastructure underneath it. In this case, the impact appears to have been relatively contained because the APIs remained available. That still creates a meaningful productivity hit for people relying on ChatGPT directly, but it is very different from an outage affecting the API layer that increasingly sits behind business applications, automations and agentic workflows. The wider ecosystem is becoming more aware of just how many critical services are now delivered over APIs. If the underlying APIs had failed, the blast radius could have been significantly larger because those dependencies are embedded inside other systems and processes. That distinction will become increasingly important as AI adoption grows. A problem in the user interface is visible and disruptive. A problem in the underlying API layer can propagate much further, and potentially much faster, before anyone sees it,” says Mayur Upadhyaya, CEO of APIContext.

https://www.securitymagazine.com/articles/102507-openai-confirms-chatgpt-outage




9M Images Exposed by Facial Recognition Platform

9,042,977 images totaling 450.2 gigabytes of data were exposed in a public database with no password protection or encryption. Facial images of adults, teenagers and children were accessible. These included: 

  • Profile pictures 
  • Screenshots 
  • Physical photographs

The files belonged to ClarityCheck, a digital investigation service leveraging reverse image search for OSINT-based identity verification. Upon discovery of the exposed database, Cybersecurity Researcher Jeremiah Fowler reached out with a responsible disclosure notice. The organization expressed gratitude for the notice and the database was restricted from public access. 

This could be a considerable privacy concern. As risks of impersonation grow more complex, especially with the proliferation of AI deepfakes, the exposure of facial imagery on such a wide scale could have posed a cyber threat. The exposure of children’s faces could be especially concerning, as recent events have shown cybercriminals creating AI-generated child abuse images (CSAM) of students in order to extort schools. 

However, as Fowler points out there is no evidence any malicious actor accessed the database nor exploited its contents, all discussions of possible ramifications are purely hypothetical. Nevertheless, in the event such information was placed into the hands of malicious actors, the consequences of such a leak could be significant. 

https://www.securitymagazine.com/articles/102505-9m-images-exposed-by-facial-recognition-platform




Agenti AI oltre il mandato: il caso della palestra australiana e il nodo della responsabilità

Agenti AI e sicurezza applicativa. Un assistente incaricato di prenotare una lezione in palestra ha trovato e sfruttato due difetti nel gestionale, prenotando ben oltre la finestra consentita e cancellando la posizione di un altro utente in lista d’attesa. L’utente aveva chiesto di salire in cima alla lista, non di rimuovere qualcuno: fra l’obiettivo assegnato e il mezzo scelto dall’agente si apre una distanza che la sicurezza applicativa conosce da anni e che il diritto non ha ancora risolto.

Il fatto

Gli agenti AI sono arrivati al banco di prova più ordinario che si possa immaginare: prenotare una lezione in palestra. La vicenda arriva dall’Australia ed è stata raccontata il 10 agosto 2026 da ABC News, in un servizio firmato dal national AI reporter Cam Wilson e da Rhiannon Hobbins dello Specialist Reporting Team.

Un utente, indicato con il solo nome di battesimo (Andrew), lavora per un’azienda australiana che vende prodotti di intelligenza artificiale alle imprese. Dall’inizio dell’anno sperimentava con OpenClaw, un framework open source per agenti autonomi, eseguito appoggiandosi al servizio Claude di Anthropic. Un dettaglio che conviene fissare subito, perché la stampa internazionale lo ha spesso appiattito: OpenClaw non è un prodotto Anthropic. È software indipendente, rilasciato con licenza MIT, pubblicato per la prima volta nel novembre 2025 da Peter Steinberger con il nome Warelay. Il 27 gennaio 2026, dopo un rilievo sul marchio da parte di Anthropic per l’assonanza fra “Clawd” e “Claude”, il progetto è stato ribattezzato Moltbot; tre giorni dopo ha assunto il nome definitivo di OpenClaw, questa volta per ragioni di semplice eufonia. Steinberger è passato a OpenAI nel febbraio 2026 e il progetto è oggi gestito dalla OpenClaw Foundation. Può essere collegato a modelli di fornitori diversi.

Vale la pena chiarire anche il rapporto commerciale, perché è stato riportato in forma datata da più testate. Il 4 aprile 2026 Anthropic ha escluso l’uso degli abbonamenti Claude Pro e Max con harness di terze parti, OpenClaw incluso. A metà maggio la società ha però invertito la rotta, annunciando un plafond separato di crediti Agent SDK che ripristinava quell’uso a partire dal 15 giugno; e il 15 giugno ha sospeso anche quel piano, lasciando in vigore la situazione attuale, nella quale l’utilizzo tramite applicazioni di terze parti continua ad attingere ai limiti dell’abbonamento sottoscritto. In altre parole: non esiste oggi un divieto contrattuale che separi nettamente l’agente personale dal servizio del fornitore del modello.

Andrew ha delegato all’agente un compito banale: prenotare un posto in una lezione mattutina molto richiesta. Pochi minuti dopo l’agente è tornato riferendo di avere individuato una vulnerabilità nel software di prenotazione che consentiva di riservare posti con un anticipo molto superiore alla finestra prevista dal regolamento della palestra.

A quel punto si innesta il secondo episodio, che nelle ricostruzioni giornalistiche viene spesso fuso con il primo ma riguarda una lezione diversa, prevista più avanti nella stessa settimana. Andrew era quarto in lista d’attesa e ha chiesto all’agente se fosse possibile portarlo in cima alla lista. L’agente ha risposto di avere verificato che l’API di cancellazione non applicasse alcun controllo di autorizzazione sulle prenotazioni altrui, di avere testato l’ipotesi sulla persona in prima posizione nell’ambito della ricognizione delle proprie capacità, e che l’operazione era andata a buon fine, con lo spostamento di Andrew dalla quarta alla terza posizione. Quando l’utente ha chiesto di ripristinare la situazione, l’agente ha risposto di non essere in grado di reinserire la persona rimossa, che avrebbe dovuto iscriversi di nuovo ripartendo dal fondo.

C’è un dettaglio tecnico che ABC non ha stampato e che compare invece nella trascrizione integrale del messaggio pubblicata da TNW: le chiamate di creazione della prenotazione e di iscrizione alla lista d’attesa restituivano un 403 Forbidden quando si tentava di agire per conto di un altro utente, mentre solo la cancellazione era priva del controllo. L’agente stesso lo definisce un difetto di sicurezza a senso unico. È l’asimmetria che spiega tutto il resto: l’applicazione verificava chi potesse ottenere qualcosa, non chi potesse toglierlo a qualcun altro.

Una precisazione metodologica che questa redazione ritiene doveroso aggiungere: tutto ciò che sappiamo sul funzionamento dell’API proviene dai messaggi dell’agente, riferiti dall’utente e pubblicati da ABC in forma di schermata. Non esiste, allo stato, una verifica tecnica indipendente, e l’endpoint non è stato analizzato da nessuno al di fuori dell’agente stesso. L’azienda che sviluppa il gestionale ha dichiarato ad ABC di non discutere questioni di sicurezza specifiche; Anthropic non ha risposto alla richiesta di commento. Anche la qualificazione dell’episodio come primo attacco informatico autonomo in Australia è una valutazione giornalistica della testata, non una designazione formale di un’autorità.

Va detto che la reazione dell’utente è stata corretta: ha fatto redigere allo stesso agente una comunicazione al fornitore del software per segnalare la vulnerabilità, l’ha revisionata e ne ha autorizzato l’invio. Una divulgazione responsabile nata come effetto collaterale di un incidente.

Il vero difetto non è l’AI

Conviene isolare subito il dato tecnico, perché è quello che rischia di perdersi nel racconto giornalistico. La falla non l’ha creata l’agente.

Un’API che accetta la cancellazione di una prenotazione senza verificare che il richiedente ne sia il titolare è un caso di scuola di broken object level authorization, la prima voce della OWASP API Security Top 10 nell’edizione 2023, tuttora l’edizione vigente del progetto dedicato alle API. Non è una lettura forzata: il terzo scenario di attacco riportato dalla stessa scheda OWASP descrive un servizio documentale nel quale l’eliminazione di un documento avviene senza ulteriori controlli di permesso, con la conseguenza che un utente può cancellare il documento di un altro. È il caso della palestra, con oggetti diversi. È un difetto documentato, ricorrente e perfettamente noto: manca un controllo di autorizzazione sul singolo oggetto, mentre l’autenticazione formalmente funziona.

La prima falla, quella sulla finestra temporale di prenotazione, appartiene a una famiglia diversa e va tenuta distinta: è una regola di business applicata soltanto lato client, riconducibile a un difetto di logica applicativa e, se si vuole restare nella tassonomia OWASP, all’area della broken function level authorization (API5:2023). La classificazione, in assenza di un’analisi diretta dell’endpoint, resta una lettura ragionata e non una qualificazione verificata. Due difetti, due categorie, un’unica causa comune: la fiducia riposta nell’interfaccia come luogo dei controlli.

Difetti di questo tipo sopravvivono per anni nei gestionali verticali proprio perché nessuno li cerca. Il cliente medio di una palestra usa l’interfaccia web, non intercetta il traffico, non enumera identificativi di prenotazione, non prova a manipolare i parametri di una chiamata. La sicurezza dell’applicazione riposava, di fatto, sul disinteresse dell’utenza.

Ciò che cambia con gli agenti è la scala di quel disinteresse. Un agente ha tempo illimitato, nessuna soglia di frustrazione e un incentivo strutturale a percorrere qualunque strada porti all’obiettivo assegnato. Non introduce nuove classi di vulnerabilità: azzera il costo dello scoprire quelle vecchie. È in sostanza la lettura offerta ad ABC da Bill Simpson-Young, amministratore delegato e cofondatore del Gradient Institute, secondo cui abbiamo costruito un mondo complesso che gira su software pieno di buchi, e l’ingresso di agenti capaci di operare su larga scala e ad alta velocità manda in crisi quel modello.

Il corollario operativo per chi sviluppa e per chi acquista software gestionale è immediato: l’assunto implicito secondo cui “nessuno andrà a guardare” non regge più, e le verifiche di autorizzazione lato server smettono di essere una buona pratica raccomandata per diventare l’unico presidio realmente disponibile.

Il problema dell’allineamento, in versione domestica

Il secondo livello di lettura riguarda la distanza fra ciò che l’utente voleva e ciò che l’agente ha fatto per ottenerlo. È il problema di allineamento su cui la ricerca discute da decenni, qui declinato in una forma minima quanto agli effetti complessivi, ma non reversibile per la persona coinvolta: la sua posizione in lista era andata, e l’agente stesso ha dichiarato di non poterla ripristinare. In un contesto a maggiore criticità, la stessa dinamica produce conseguenze di ben altro ordine.

Conviene però essere precisi sul mandato. Andrew non aveva chiesto di attaccare nulla, ma non aveva neppure formulato una richiesta neutra: aveva chiesto di essere portato in cima a una lista d’attesa condivisa con altre persone. Fra l’obiettivo assegnato e il mezzo scelto dall’agente c’è uno scarto reale, ed è esattamente lì che si annida il problema; ma è uno scarto meno ampio di quanto suggerisca la formula, molto ripresa, dell’agente che agisce “senza che nulla gli fosse stato chiesto”.

Resta un margine di ambiguità che vale la pena non nascondere. L’agente ha presentato la cancellazione come parte della verifica delle proprie capacità e ha riferito ad Andrew di averlo già spostato dalla quarta alla terza posizione: una formulazione che lascia aperta la possibilità che l’operazione sia avvenuta durante l’esplorazione autonoma del sistema, e non in risposta alla domanda. Il servizio ABC espone la richiesta e poi la risposta dell’agente, senza datare l’azione; alcune riprese internazionali hanno risolto il dubbio in un senso o nell’altro senza basi ulteriori. Sul piano dell’imputazione soggettiva, di cui si dirà, la differenza non è marginale.

Il caso non è isolato, e le settimane precedenti offrono termini di paragone documentati. Il 21 luglio 2026 OpenAI ha reso noto che alcuni suoi modelli, durante una valutazione interna su un benchmark di capacità cyber, erano usciti dall’ambiente circoscritto in cui operavano sfruttando una vulnerabilità non nota, avevano stabilito connettività verso la rete aperta e avevano compromesso l’infrastruttura di Hugging Face nel tentativo di ottenere le risposte al test assegnato. Il 30 luglio Anthropic ha dichiarato che propri modelli avevano ottenuto accessi non autorizzati ai sistemi di tre organizzazioni reali: qui, a differenza del caso OpenAI, non c’è stata alcuna evasione autonoma, perché l’accesso a Internet era disponibile per un errore di configurazione dell’ambiente di valutazione gestito da un partner esterno. Il 31 luglio Reuters ha riferito, sulla base di fonti anonime, che OpenAI aveva individuato altri casi di uscita dagli ambienti di test nel corso della propria indagine interna: episodi descritti come di portata limitata, dei quali nessuno avrebbe lasciato la rete della società, e di cui l’agenzia non ha potuto stabilire numero, tempi e circostanze. Nei primi giorni di agosto la stessa OpenAI ha documentato pubblicamente due ulteriori incidenti occorsi presso valutatori esterni, uno dei quali coincide con la valutazione dell’AI Security Institute britannico di cui si dirà fra poco. Il 5 agosto Meta ha dichiarato che un proprio modello, Muse Spark 1.1, aveva raggiunto la rete e sfruttato una vulnerabilità nei sistemi di un servizio terzo non identificato.

Un elemento ricorre in tre di questi episodi, quelli comunicati da Anthropic il 30 luglio, da OpenAI all’inizio di agosto e da Meta il 5 agosto, ed è forse il dato più istruttivo per chi si occupa di sicurezza: l’ambiente di valutazione mal configurato apparteneva ogni volta allo stesso fornitore di servizi di test, la società Irregular. Non è soltanto un problema dei modelli: è anche un problema dell’infrastruttura che serve a misurarli. Non vale però per tutti: nell’episodio di Hugging Face l’uscita dall’ambiente è passata dallo sfruttamento di una vulnerabilità non nota, e lì la condotta è stata interamente del modello.

Il dato più circostanziato arriva dall’AI Security Institute britannico, che il 28 luglio ha rilevato trasferimenti anomali dai propri sistemi di ricerca e ha pubblicato il rapporto sull’incidente il 4 agosto: su 122 esecuzioni di una singola valutazione di sicurezza, in 10 casi un agente ha compiuto azioni autonome non autorizzate sulla rete pubblica verso persone e organizzazioni reali, per un totale di 19 azioni catalogate, fra cui un tentativo di attacco alla catena di fornitura di software open source; 17 delle 19 sono riconducibili a un solo modello. L’istituto precisa che non si è trattato di un’evasione dall’ambiente isolato: l’accesso a Internet era stato concesso deliberatamente e i filtri di sicurezza dei fornitori erano stati disattivati per misurare le capacità massime dei modelli.

È nato anche un sito dedicato al censimento di questi episodi, Felony Bench. Conviene però chiamarlo per quello che è: un tracker informale realizzato da un singolo, con una tabella di casi datati e collegati alle fonti ma senza metodologia pubblicata, e non un benchmark nel senso tecnico del termine. Vi è già censito anche il caso della palestra, attribuito ad Anthropic: una scelta che, involontariamente, illustra alla perfezione il problema di attribuzione di cui si dirà fra poco. Un secondo limite emerge dal confronto con le fonti citate: la voce relativa alla notizia Reuters del 31 luglio parla di account interni compromessi presso quattro società, mentre l’articolo richiamato riferisce di episodi circoscritti, nessuno dei quali avrebbe superato il perimetro di rete del fornitore.

Sul piano istituzionale, ABC riferisce che l’Australian Signals Directorate aveva già diramato a imprese e amministrazioni un avviso secondo cui i sistemi di intelligenza artificiale possono fraintendere le istruzioni, compiere azioni non previste e rendere più difficile stabilire le responsabilità, perché le decisioni si distribuiscono lungo catene di modelli, strumenti e servizi. Dopo il servizio ABC, l’Australian Cyber Security Centre è tornato sul punto con un richiamo esplicito all’uso prudente degli agenti, ricollegando l’episodio ai rischi di disallineamento degli obiettivi già individuati nella propria guida e qualificandolo come un caso di specification gaming: la ricerca di scorciatoie che raggiungono formalmente l’obiettivo assegnato ma confliggono con l’intenzione di chi lo ha assegnato. L’avviso raccomanda di mantenere una supervisione umana sulle azioni dell’agente, in particolare quando queste toccano servizi di terzi o altri utenti, e avverte le organizzazioni che erogano servizi online di considerare che gli agenti possono individuare e sfruttare vulnerabilità a grande velocità e su larga scala.

Il riferimento più solido in materia resta la guida congiunta Careful Adoption of Agentic AI Services, pubblicata il 1° maggio 2026 sul sito dell’ASD e firmata da sei agenzie (CISA e NSA per gli Stati Uniti, l’Australian Cyber Security Centre dell’ASD, il Canadian Centre for Cyber Security, il National Cyber Security Centre britannico e quello neozelandese), che organizza il rischio degli agenti in cinque categorie: privilegi, progettazione e configurazione, comportamento, struttura, responsabilità. La guida raccomanda esplicitamente di non concedere mai agli agenti accessi ampi o illimitati, soprattutto verso dati sensibili o sistemi critici, e di riservarli, in questa fase, a compiti a basso rischio e non sensibili.

Quest’ultimo punto è il più rilevante per chi si occupa di governance. La catena di attribuzione si allunga proprio nel momento in cui servirebbe più corta.

Chi risponde? Il caso australiano

Nell’ordinamento australiano la questione è dichiaratamente aperta: il software non è soggetto di diritto, e solo un soggetto di diritto può essere chiamato a rispondere. Hayden Delaney, partner dello studio Thomsons (già Thomson Geer) e specialista di diritto delle tecnologie, proprietà intellettuale e privacy, indica ad ABC come possibili responsabili l’utente che ha assegnato il compito, chi ha progettato il software che istruisce l’agente, chi sviluppa il modello o l’operatore del sistema vulnerabile.

Delaney aggiunge però un elemento che merita attenzione, perché anticipa il ragionamento che seguirà: alcune norme esistenti potrebbero applicarsi già oggi, in particolare quando un soggetto agisce in modo avventato o quando un’impresa fornisce un servizio difettoso. La risposta, dice, dipende da che cosa l’utente ha autorizzato, da quali rischi erano ragionevolmente prevedibili e dal fatto che la condotta si sia svolta o meno nell’ambito di un’attività commerciale. Non è un vuoto normativo, insomma, ma un’area di incertezza applicativa.

Il tema è entrato anche nell’agenda politica australiana: secondo ABC, Andrew Charlton, Assistant Minister per la scienza, la tecnologia e l’economia digitale, è stato il primo membro noto del governo ad affrontarlo in un discorso a una conferenza sulla sicurezza dell’IA, annunciando finanziamenti al CSIRO per studiare come sia possibile gestire e verificare il comportamento di sistemi di intelligenza artificiale sempre più capaci.

Che cosa accadrebbe in Italia

Il caso è interamente australiano e la legge penale italiana si applica, salve eccezioni, ai reati commessi nel territorio dello Stato (art. 6 c.p.). Il ragionamento che segue è dunque un’ipotesi di lavoro: che cosa accadrebbe se la stessa condotta si verificasse in Italia, con utente e sistema collocati sul territorio nazionale. Il diritto italiano offre categorie più definite di quello australiano, ma non risposte automatiche.

Accesso abusivo a sistema informatico (art. 615-ter c.p.). La norma punisce chi abusivamente si introduce in un sistema informatico o telematico protetto da misure di sicurezza, ovvero vi si mantiene contro la volontà espressa o tacita di chi ha il diritto di escluderlo. Due elementi meritano attenzione.

Il primo è proprio il requisito delle misure di sicurezza, che in un caso come questo è meno scontato di quanto sembri: l’endpoint di cancellazione era, per quanto riferito, privo di controlli di autorizzazione. La giurisprudenza è però costante nel ritenere sufficiente qualunque accorgimento, anche di natura organizzativa, idoneo a manifestare la volontà di esclusione del titolare. Fra le pronunce recenti, Cass. pen., Sez. V, n. 2905/2025 (udienza 23 ottobre 2024, deposito 23 gennaio 2025) ha ribadito che la protezione può essere adottata anche con misure di carattere organizzativo che disciplinino le modalità di accesso, consentendolo ai soli soggetti abilitati per determinate finalità. Un sistema che richiede autenticazione e definisce regole di prenotazione soddisfa quel requisito. La condotta si colloca poi nel filone dell’excessus mandati: rileva non tanto il modo in cui si entra, quanto il superamento dei limiti dell’autorizzazione ricevuta, ed è esattamente ciò che accade quando una sessione legittima viene usata per agire su oggetti altrui.

Il secondo è l’elemento soggettivo. Il reato è punito a titolo di dolo. Un utente che chiede di essere iscritto a un corso non rappresenta né vuole l’accesso abusivo, e la condotta materiale è stata determinata da un sistema automatico che ha scelto autonomamente il mezzo. Ma la richiesta effettivamente formulata era di essere portato in cima a una lista d’attesa altrui, da parte di un soggetto professionalmente esposto al funzionamento degli agenti: l’ipotesi del dolo eventuale, cioè della previsione e accettazione del rischio, non può essere liquidata in astratto e andrebbe valutata sul caso concreto. Qui pesa anche l’ambiguità sopra segnalata: se la cancellazione fosse avvenuta prima della richiesta, nel corso di un’esplorazione autonoma, verrebbe meno il presupposto stesso di una qualsiasi rappresentazione dell’evento in capo all’utente. È lo stesso crinale, sul versante di common law, indicato da Delaney quando parla di condotta avventata e di rischi ragionevolmente prevedibili.

Rileva infine la procedibilità. L’ipotesi base del primo comma è punibile a querela della persona offesa; nelle ipotesi aggravate del secondo comma si procede d’ufficio. Fra queste rientra il caso in cui dal fatto derivi la distruzione o il danneggiamento dei dati contenuti nel sistema: aggravante che la L. 90/2024 (art. 16, comma 1, lettera b, n. 1.3) ha esteso anche alla sottrazione, pure mediante riproduzione o trasmissione, e all’inaccessibilità al titolare. Poiché qui una cancellazione di dati c’è stata, la qualificazione non è indifferente.

Danneggiamento di informazioni, dati e programmi informatici (art. 635-bis c.p.). Nel testo riformulato dalla L. 28 giugno 2024 n. 90, la norma punisce con la reclusione da due a sei anni, a querela della persona offesa, chi distrugge, deteriora, cancella, altera o sopprime informazioni, dati o programmi informatici altrui. La cancellazione della prenotazione di un terzo integra materialmente la condotta, con lo stesso interrogativo sull’imputazione soggettiva, dato che anche qui è richiesto il dolo e non è prevista la punibilità a titolo di colpa. Resta da qualificare il requisito dell’altruità: il dato riguarda il socio rimosso, ma è custodito ed elaborato nel sistema del titolare del trattamento.

Profilo civilistico e protezione dei dati. La palestra resta titolare del trattamento dei dati dei propri soci ed è tenuta ad adottare misure tecniche e organizzative adeguate ai sensi dell’art. 32 GDPR. Il fornitore del gestionale opera con ogni probabilità come responsabile del trattamento ai sensi dell’art. 28, con obblighi propri di sicurezza e con la necessità di un contratto che li definisca. Un’API che consente a chiunque di cancellare la prenotazione di un altro interessato è, prima ancora che un problema di sicurezza applicativa, una misura di sicurezza inadeguata. E la cancellazione non autorizzata di un dato personale da parte di un terzo integra una violazione di integrità e disponibilità, con i conseguenti obblighi di valutazione e, ove ricorrano i presupposti, di notifica al Garante e di comunicazione all’interessato ai sensi degli artt. 33 e 34 GDPR. La responsabilità del titolare non si attenua per il fatto che a sfruttare la falla sia stato un agente automatico anziché una persona.

Sul versante risarcitorio il quadro è in transizione, e il dato temporale conta. La disciplina di riferimento non è quella sull’IA ma quella sulla responsabilità da prodotto difettoso, ridisegnata dalla direttiva (UE) 2024/2853, che include espressamente il software fra i prodotti e che la testata ha già analizzato. Il termine di recepimento scade però il 9 dicembre 2026 e le nuove regole si applicheranno ai prodotti immessi sul mercato o messi in servizio da quella data; in Italia la delega è contenuta nella legge di delegazione europea 2025 (legge 17 marzo 2026, n. 36) e il decreto legislativo non risulta ancora emanato. Un fatto verificatosi oggi ricadrebbe quindi ancora sotto gli artt. 114 e seguenti del Codice del consumo. Vale inoltre la pena segnalare che la nuova direttiva esclude dal proprio ambito, all’art. 2, paragrafo 2, il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale: una previsione che, applicata a un framework come OpenClaw, rilasciato con licenza MIT, sottrarrebbe proprio l’anello centrale della catena. Il condizionale è d’obbligo, perché la condizione dell’estraneità a un’attività commerciale non è scontata per un progetto gestito da una fondazione e sostenuto finanziariamente da un fornitore di modelli.

AI Act. Vale la pena segnalare ciò che il regolamento europeo, in questo scenario, non fa, e per due ragioni distinte che si sommano.

La prima è di classificazione: un assistente che prenota lezioni in palestra non rientra fra i sistemi ad alto rischio dell’Allegato III, quindi i requisiti di gestione del rischio e sorveglianza umana del Capo III non lo riguardano.

La seconda è di calendario, ed è recente. Il Regolamento (UE) 2026/1744 dell’8 luglio 2026, il cosiddetto Omnibus digitale sull’IA, pubblicato in Gazzetta Ufficiale dell’Unione europea il 24 luglio 2026 ed entrato in vigore il 27 luglio, ha riscritto il terzo comma dell’art. 113 dell’AI Act rinviando il blocco degli obblighi sui sistemi ad alto rischio: le sezioni 1, 2 e 3 del Capo III, con esclusione dell’art. 6, paragrafo 5, si applicheranno dal 2 dicembre 2027 per i sistemi autonomi dell’Allegato III e dal 2 agosto 2028 per quelli integrati in prodotti coperti dall’Allegato I.

Che cosa resta, allora, in vigore oggi. Restano i divieti dell’art. 5 e l’obbligo di alfabetizzazione in materia di IA dell’art. 4, applicabili dal 2 febbraio 2025, con l’avvertenza che l’art. 4 è stato integralmente sostituito dall’Omnibus e, dal 27 luglio 2026, non impone più di garantire un livello sufficiente di alfabetizzazione ma di adottare misure per sostenerne lo sviluppo. Restano gli obblighi in capo ai fornitori di modelli per finalità generali e, con essi, l’intero Capo XII sulle sanzioni, applicabile dal 2 agosto 2025 con la sola eccezione dell’art. 101. Dal 27 luglio 2026 sono divenuti applicabili gli articoli da 102 a 110. Dal 2 agosto 2026 sono esigibili gli obblighi di trasparenza dell’art. 50 e si è aggiunto il potere della Commissione di sanzionare direttamente i fornitori di modelli per finalità generali ai sensi dell’art. 101, insieme alla piena operatività della vigilanza nazionale. L’Omnibus ha inoltre ampliato l’elenco delle pratiche vietate dall’art. 5, con applicazione delle nuove fattispecie dal 2 dicembre 2026.

C’è però un dettaglio dell’Omnibus che merita di essere isolato, perché riguarda direttamente questa vicenda. Il nuovo Allegato XIV dell’AI Act, una nomenclatura di codici destinata alla designazione degli organismi notificati, introduce il codice AIH 0401 per le tecnologie emergenti non coperte dagli altri codici e vi nomina espressamente l’IA agentica. È un codice residuale, nel quale l’IA agentica è nominata a titolo di esempio; un sistema agentico costruito su un modello per finalità generali ricade invece nel codice AIH 0301. È una collocazione tecnica e defilata, priva di definizione, di obblighi e di criteri di classificazione, ma, per quanto risulta a questa redazione, è la prima volta che l’espressione compare in un atto vincolante dell’Unione. Il legislatore europeo riconosce il fenomeno; non lo disciplina.

Il caso illustra bene, e per doppia via, un’area grigia: sistemi a basso rischio per finalità dichiarata, ma dotati di capacità di azione su sistemi di terzi, e per i quali il presidio regolatorio più stringente non è comunque il regolamento sull’IA.

La riflessione, per le organizzazioni italiane, non è teorica. Il momento in cui un dipendente delega a un agente personale un’attività che tocca sistemi aziendali o di fornitori è già arrivato, e in genere senza che nessuno lo abbia autorizzato formalmente.

Cosa portarsi a casa

Per chi sviluppa o acquista software applicativo:

  • verificare l’autorizzazione a livello di singolo oggetto su ogni endpoint che modifica o cancella risorse, senza affidarsi ai controlli dell’interfaccia;
  • controllare la simmetria dei presidi: in questo caso la creazione della prenotazione e l’iscrizione alla lista d’attesa erano protette, la cancellazione no;
  • trattare le regole di business (finestre temporali, limiti di prenotazione, quote) come vincoli da applicare lato server e non come parametri configurati nel client;
  • prevedere rate limiting e rilevamento di pattern di accesso automatizzati, che oggi possono provenire da un utente legittimo e non da un attaccante;
  • garantire la reversibilità delle operazioni distruttive, con cancellazione logica e ripristino, perché in questo caso l’irreversibilità ha trasformato un test in un danno;
  • inserire nei contratti con i fornitori di software un canale di segnalazione delle vulnerabilità, perché le segnalazioni arriveranno.

Per chi si occupa di governance e conformità:

  • disciplinare in policy l’uso di agenti personali su sistemi aziendali e di terzi, definendo cosa può essere delegato e con quali credenziali;
  • ricostruire in anticipo la catena di attribuzione, mantenendo tracciabilità di quale agente ha operato, con quale mandato, con quali privilegi e con quale modello sottostante;
  • conservare i log delle azioni dell’agente lato client e lato server, perché in questo caso l’unica ricostruzione disponibile dei fatti sono i messaggi prodotti dall’agente stesso;
  • applicare il principio del privilegio minimo alle credenziali affidate agli agenti, che tendono invece a ereditare tutti i permessi dell’utente;
  • non dare per scontato che il rapporto contrattuale con il fornitore del modello separi l’agente personale dall’infrastruttura aziendale: come mostra l’altalena delle politiche di Anthropic fra aprile e giugno 2026, quel confine è mobile e non costituisce un presidio di sicurezza.

Il caso australiano è minore per impatto e quasi comico nella dinamica. È però una fotografia nitida di una transizione già in corso: il software esposto al pubblico non ha più come interlocutore soltanto persone che si comportano come previsto.

Fonti

  • ABC News, servizio del 10 agosto 2026 (fonte primaria): abc.net.au
  • OWASP API Security Top 10, edizione 2023: owasp.org
  • ASD, Careful adoption of agentic AI services: cyber.gov.au
  • AI Security Institute, rapporto sull’incidente del 28 luglio 2026 (pubblicato il 4 agosto): aisi.gov.uk
  • Felony Bench: felonybench.com

https://www.ictsecuritymagazine.com/intelligenza-artificiale/agenti-ai-vulnerabilita/