Spcnet.it

2026-08-19 15:56:10

5 controlli infrastrutturali per mettere in sicurezza gli agenti AI (oltre il prompt)

Quanti team stanno collegando agenti AI a Slack, a un’interfaccia web o a server MCP proteggendo l’accesso solo con un prompt di sistema ben scritto? Secondo un’analisi pubblicata su DZone e basata su findings del Red Team di NVIDIA, è proprio questo l’errore architetturale più diffuso nelle implementazioni enterprise di agenti AI: “i guardrail basati sul prompt falliscono sotto pressione avversaria”. Un attaccante sufficientemente motivato può camuffare attività malevole da comportamenti legittimi, scalare privilegi gradualmente o nascondere esecuzione di codice dentro interazioni apparentemente normali.

Il punto chiave, riassunto efficacemente dall’articolo originale, è questo: il modello non è il punto di applicazione della sicurezza, è la cosa che va difesa. Va trattato come qualsiasi altro componente non fidato della vostra infrastruttura — proprio come fareste con un processo che esegue codice arbitrario ricevuto da input esterni. In questo articolo ripercorriamo i cinque controlli infrastrutturali proposti, con esempi pratici applicabili su Kubernetes e nello stack Microsoft.

1. Identità e propagazione dell’autenticazione

Il primo errore comune è usare credenziali condivise per l’agente, indipendentemente da chi lo stia effettivamente invocando (via Slack, web UI o endpoint MCP). Questo rende impossibile distinguere un’azione legittima da un abuso e complica ogni audit successivo.

La soluzione è propagare l’identità dell’utente umano fino ai sistemi a valle, invece di far agire l’agente con un account di servizio onnipotente. Lo standard di riferimento è OAuth 2.0 Token Exchange (RFC 8693), che permette di scambiare il token dell’utente con un token downstream a scope ridotto e vita breve:

POST /oauth2/token HTTP/1.1
Host: identity.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token={USER_TOKEN}
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=ticketing-api
&scope=tickets.read tickets.comment

Il token risultante è specifico per l’audience richiesta (in questo caso l’API di ticketing), ha uno scope minimo e una scadenza breve. Ogni chiamata a valle porta con sé l’identità originale dell’utente, non quella generica dell’agente: questo è ciò che rende possibile un audit trail affidabile.

2. Presupporre l’esecuzione di codice e limitarne gli effetti

Un agente con accesso a strumenti di code execution va trattato esattamente come un processo che esegue input non fidato, perché di fatto è quello che è. I controlli minimi da applicare a livello di container:

• filesystem di root read-only;
• noexec su tutti i mount scrivibili, per impedire l’esecuzione di binari scaricati a runtime;
• drop di tutte le capability Linux non strettamente necessarie;
• configurazione dell’agente montata come read-only da un mount point separato, così che l’agente stesso non possa alterare la propria configurazione;
• allowlist esplicita dei binari eseguibili.

Un esempio di `securityContext` Kubernetes coerente con questi principi:

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
volumeMounts:
  - name: tmp
    mountPath: /tmp
    # mount separato per lo storage scrivibile, con noexec applicato a livello di nodo
  - name: agent-config
    mountPath: /etc/agent
    readOnly: true

3. Egress default-deny

Un agente compromesso o manipolato tramite prompt injection che possa raggiungere qualunque host su Internet è un rischio enorme: esfiltrazione dati, comando e controllo, o accesso agli endpoint di metadata del cloud provider (il classico 169.254.169.254, spesso usato per rubare credenziali IAM). La difesa è una NetworkPolicy Kubernetes default-deny in uscita, con eccezioni esplicite solo verso ciò che serve realmente:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ai-agent-default-deny-egress
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Egress
  egress:
    # consente solo DNS e il proxy autenticato interno
    - to:
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53
    - to:
        - podSelector:
            matchLabels:
              app: egress-proxy
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-cloud-metadata
  namespace: agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

Le connessioni realmente necessarie devono passare attraverso un proxy autenticante con allowlist basata su FQDN, con logging completo di ogni richiesta e dell’identità utente associata: in questo modo ogni chiamata in uscita è tracciabile e limitata a destinazioni note.

4. Nessun segreto persistente

Iniettare segreti tramite variabili d’ambiente, file di configurazione o, peggio, direttamente nel context window del modello è una pratica rischiosa: un agente che legge il proprio ambiente, o che viene indotto a farlo tramite prompt injection, può esfiltrare quei segreti con facilità.

L’approccio consigliato è il token brokering per singolo task, con TTL molto brevi (minuti, non ore) e revoca esplicita al completamento del task, non solo alla scadenza naturale:

• ogni task riceve un token appena sufficiente per l’operazione richiesta;
• il token viene revocato non appena il task termina, indipendentemente dalla sua scadenza nominale;
• ogni emissione di segreto viene registrata con l’identità dell’utente umano che ha originato la richiesta.

Strumenti come Azure Key Vault (con identità gestite e token a vita breve) o soluzioni dedicate di secret brokering per workload agentic vanno preferiti rispetto a qualunque forma di credential injection statica.

5. Controllo della supply chain dei pacchetti

Un agente con capacità di installare pacchetti (npm, pip, NuGet) durante l’esecuzione è una superficie di attacco enorme, soprattutto se può installare da repository VCS arbitrari o eseguire script di post-install non controllati. I controlli minimi:

• uso di repository proxy interni (Artifactory o equivalente) come unica fonte consentita;
• blocco esplicito delle installazioni da URL o VCS diretti (es. pip install git+https://...);
• abilitazione di ignore-scripts=true per prevenire l’esecuzione di script post-install, un vettore di attacco noto nell’ecosistema npm;
• verifica dell’hash dei pacchetti installati.

# .npmrc per l'ambiente dell'agente
registry=https://artifactory.contoso.com/api/npm/npm-proxy/
ignore-scripts=true
audit=true

Validare i controlli con test automatici, non con documentazione

Il consiglio più pratico dell’articolo è forse questo: questi cinque controlli vanno implementati come test case automatici nella pipeline CI/CD, non lasciati a una checklist di sicurezza scritta a mano. Alcuni esempi di assertion da includere:

• un chiamante non autenticato deve essere rifiutato;
• un tentativo di scrittura su file di configurazione nascosti (dotfile) deve fallire;
• ogni connessione in uscita non allowlisted deve essere bloccata e loggata;
• nessun segreto deve essere presente nelle variabili d’ambiente del processo agente;
• l’endpoint di metadata cloud deve risultare irraggiungibile;
• un’installazione di pacchetto da VCS diretto deve essere bloccata dal proxy.

Conclusione

Gli agenti AI non introducono nuovi principi di sicurezza: richiedono di applicare con rigore quelli che già conosciamo — least privilege, isolamento, gestione dei segreti a vita breve, egress controllato — a un tipo di workload che, per sua natura, esegue codice e prende decisioni sulla base di input non completamente prevedibili. Chi gestisce infrastrutture Kubernetes o Azure ha già gli strumenti per implementare questi controlli; il passo mancante, spesso, è semplicemente la decisione di applicarli con la stessa serietà riservata a qualunque altro workload che esegue codice non fidato.

Fonte originale: “5 Infrastructure Controls for Securing AI Agents” su DZone.

RFC 8693: OAuth 2.0 Token Exchange

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.

^{IETF Datatracker}

Spcnet.it

2026-08-19 15:56:13

Un agente AI è un sistema distribuito, non un chatbot: pattern di durable orchestration in .NET

Negli ultimi mesi molti team hanno scoperto a proprie spese che il problema più grande di un agente AI in produzione non è la qualità del prompt, ma la sua affidabilità operativa. Un articolo recente su DZone, “Your AI Agent Is a Distributed System, Not a Chatbot”, mette a fuoco un punto che chi progetta sistemi backend conosce bene da anni: se un componente deve sopravvivere a crash, timeout, retry e attese umane di ore, non puoi trattarlo come una semplice chiamata sincrona a un modello. Devi trattarlo come un sistema distribuito, con tutto ciò che questo comporta: stato persistente, checkpoint, idempotenza e recovery.

In questo articolo riprendiamo quei concetti e li caliamo nella pratica con .NET, mostrando come Azure Durable Functions (o alternative come Temporal) permettano di costruire agenti AI multi-step che non perdono lo stato quando qualcosa va storto — cosa che, in produzione, prima o poi succede sempre.

Perché un chatbot stateless non basta

Un chatbot classico è un ciclo request/response: l’utente scrive, il modello risponde, fine. Un agente AI enterprise, invece, tipicamente deve:

• orchestrare più chiamate a modelli e strumenti in sequenza o in parallelo;
• interrogare sistemi esterni (CRM, ticketing, knowledge base, database);
• attendere l’approvazione di un umano, che può richiedere minuti oppure ore;
• gestire fallimenti parziali senza dover ripartire da zero;
• garantire che un’azione con effetti collaterali (un rimborso, un invio email, una scrittura su un sistema esterno) non venga eseguita due volte per colpa di un retry.

Nessuno di questi requisiti è nuovo: sono gli stessi problemi che i sistemi distribuiti risolvono da decenni con pattern come saga, checkpointing e idempotency key. La differenza è che oggi il “servizio downstream” spesso è un LLM, e la latenza dominante non è più quella di rete, ma quella dell’attesa umana.

Durable orchestration: lo stato che sopravvive al crash

Il pattern architetturale proposto è un runtime di orchestrazione durevole, che mantiene lo stato del workflow indipendentemente dal ciclo di vita del processo che lo esegue. In .NET, l’implementazione più diretta è Azure Durable Functions, che introduce tre concetti chiave:

• Orchestrator function: decide “cosa succede dopo”, applica le retry policy e coordina le chiamate, ma non esegue lavoro con effetti collaterali direttamente;
• Activity function: esegue il lavoro reale (chiamata al modello, query, side effect) ed è il livello dove si applica l’idempotenza;
• Checkpointing automatico: dopo ogni `await`, il runtime salva lo stato dell’orchestrazione, così un crash del processo non fa perdere il progresso già fatto.

Un’alternativa nota, citata anche nell’articolo originale, è Temporal, che applica lo stesso principio con un modello di programmazione simile ma un runtime a sé stante, spesso preferito in contesti multi-linguaggio o Kubernetes-native.

Il pattern fan-out/fan-in per agenti multipli

Quando un task richiede il contributo di più agenti specializzati (per esempio: un agente diagnostico, uno di ricerca sulla knowledge base, uno che consulta lo storico dei casi e uno che verifica le policy aziendali), il pattern corretto è il fan-out/fan-in: l’orchestratore lancia tutte le attività in parallelo e aggrega i risultati solo quando sono tutte terminate.

Ecco un esempio realistico in C# con il modello isolato di Azure Functions, ispirato agli esempi ufficiali Microsoft:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var caseId = context.GetInput<string>();

    // Fan-out: 4 agenti specializzati lanciati in parallelo
    var diagnosticTask = context.CallActivityAsync<AgentFinding>(
        "RunDiagnosticAgent", caseId);
    var knowledgeTask = context.CallActivityAsync<AgentFinding>(
        "RunKnowledgeSearchAgent", caseId);
    var historyTask = context.CallActivityAsync<AgentFinding>(
        "RunHistoricalCaseAgent", caseId);
    var policyTask = context.CallActivityAsync<AgentFinding>(
        "RunPolicyAgent", caseId);

    // Fan-in: si attende che tutti i task completino
    AgentFinding[] findings = await Task.WhenAll(
        diagnosticTask, knowledgeTask, historyTask, policyTask);

    // Sintesi della raccomandazione finale
    var recommendation = await context.CallActivityAsync<Recommendation>(
        "SynthesizeRecommendation", findings);

    return new InvestigationResult(caseId, findings, recommendation);
}

Il vantaggio rispetto a un semplice `Task.WhenAll` in un servizio stateless è che, se il processo host crasha mentre due agenti su quattro hanno già risposto, l’orchestrazione riparte dal checkpoint e non richiama gli agenti già completati.

Human-in-the-loop senza tenere aperta la compute

Il collo di bottiglia più comune non è il modello, ma l’attesa di un’approvazione umana. Un workflow che tenesse una funzione serverless “in ascolto” per ore sarebbe insostenibile in termini di costo e di timeout. Il pattern corretto è sospendere l’orchestrazione in attesa di un evento esterno:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    // ... fan-out/fan-in come sopra ...

    await context.CallActivityAsync("NotifyHumanReviewer", recommendation);

    // Il workflow si sospende senza consumare risorse compute
    // fino a quando l'evento non arriva, anche dopo diverse ore
    var decision = await context.WaitForExternalEvent<HumanReviewDecision>(
        "HumanReviewCompleted");

    if (decision.Approved)
    {
        await context.CallActivityAsync("ApplyResolution", recommendation);
    }

    return new InvestigationResult(caseId, findings, recommendation, decision);
}

L’evento viene “consegnato” all’orchestrazione in pausa tramite una chiamata separata (per esempio da una Function HTTP-triggered collegata a un pulsante “Approva” nella UI), e il runtime si occupa di riprendere l’esecuzione esattamente dal punto in cui era stata sospesa.

Idempotenza: il vero rischio nascosto

Un runtime durevole garantisce tipicamente semantica at-least-once: dopo un crash, un’attività può essere rieseguita. Questo va benissimo per operazioni pure (una query di lettura), ma è pericoloso per operazioni con side effect (un rimborso, un invio email, una scrittura irreversibile). Il momento critico è il cosiddetto crash window: l’intervallo tra il completamento effettivo di un’azione e il salvataggio del suo checkpoint.

La soluzione è associare a ogni operazione critica una idempotency key deterministica, così che una riesecuzione accidentale venga riconosciuta e ignorata a livello applicativo:

[Function("ApplyGoodwillRefund")]
public static async Task ApplyGoodwillRefund(
    [ActivityTrigger] RefundRequest request)
{
    string idempotencyKey = $"{request.CaseId}:goodwill-refund";

    if (await _paymentService.WasAlreadyProcessedAsync(idempotencyKey))
    {
        return; // operazione già eseguita, nessun effetto collaterale duplicato
    }

    await _paymentService.ProcessRefundAsync(request, idempotencyKey);
}

Questo pattern, ben noto a chi lavora con gateway di pagamento, va applicato sistematicamente a ogni activity che tocchi sistemi esterni non idempotenti per natura.

Successo parziale, non tutto-o-niente

Se uno dei quattro agenti fallisce (per esempio, il servizio di knowledge search va in timeout), il sistema non dovrebbe far fallire l’intera indagine. Meglio trattare i risultati come esiti strutturati, distinguendo tra “successo”, “fallito” e “degradato”, e permettere che la sintesi finale proceda comunque, segnalando esplicitamente quali fonti mancano:

public record AgentFinding(
    string AgentName,
    AgentStatus Status,   // Success, Failed, Degraded
    string? Result,
    string? FailureReason);

Questo approccio “graceful degradation” è preferibile a un fallimento totale che obbliga a rieseguire da capo un’indagine costosa in termini di tempo e token consumati.

Osservabilità come requisito di prodotto

In un sistema dove un’indagine può durare ore e coinvolgere quattro o più agenti, la tracciabilità non è un dettaglio tecnico: è parte dell’esperienza utente e, in molti contesti regolamentati, un requisito di audit. Vale la pena tracciare sistematicamente:

• workflow instance ID, correlation ID e case ID;
• lo stage corrente e la durata di ogni singolo agente;
• il numero di retry e il motivo di ogni fallimento;
• la latenza di revisione umana (spesso il fattore dominante);
• la tracciabilità delle evidenze usate per la raccomandazione finale, per scopi di audit.

Conclusione

Il messaggio di fondo è semplice ma spesso trascurato: il workflow conta più del prompt. Un agente AI ben progettato non è quello con il prompt più raffinato, ma quello costruito su un runtime capace di sopravvivere a crash, gestire attese umane di ore senza sprecare risorse, ed evitare effetti collaterali duplicati. Per chi lavora nello stack .NET, Azure Durable Functions offre oggi gli strumenti necessari per applicare questi pattern senza dover reinventare un motore di orchestrazione da zero; per contesti poliglotta o già containerizzati, Temporal resta un’alternativa solida con la stessa filosofia.

Fonte originale: “Your AI Agent Is a Distributed System, Not a Chatbot” su DZone.

Durable Functions Overview: Stateful Serverless Workflows

Learn how Durable Functions extends Azure Functions to build reliable, stateful workflows in a serverless environment. Get started with supported languages, storage providers, and quickstarts.

^{learn.microsoft.com}

(in)sicurezza digitale

2026-08-19 15:54:25

Handala: lo spionaggio iraniano del MOIS che si finge amico dei giornalisti su WhatsApp

Si parla di:
Toggle

Da due anni si spacciava per movimento hacktivista filo-palestinese. Il Dipartimento di Giustizia americano ha invece confermato ciò che gli analisti sospettavano da tempo: dietro il collettivo “Handala” opera il Ministero dell’Intelligence iraniano (MOIS), e il suo bersaglio attuale sono i giornalisti israeliani, contattati su WhatsApp e Telegram con la stessa cura con cui si costruisce una fonte, per rubare loro le credenziali e, in alcuni casi, l’intero telefono.

Lo Shin Bet e l’Autorità nazionale per la cybersicurezza israeliana hanno diffuso il 16 agosto 2026 un avviso congiunto, raro per esplicitezza, in cui si afferma che “gli operativi dell’intelligence iraniana stanno tentando di raccogliere informazioni sensibili su sviluppi politici e di sicurezza, ottenere accesso a fonti giornalistiche, materiali di lavoro e corrispondenza”. Non è un’allerta generica: arriva dopo mesi di segnalazioni da parte di redazioni come Haaretz, i cui cronisti sono stati impersonati per avvicinare colleghi e contatti.

Chi è davvero Handala

Il nome richiama la celebre vignetta del fumettista palestinese Naji al-Ali, e per due anni il brand “Handala Hack Team” ha coltivato un’immagine da collettivo hacktivista indipendente, rivendicando data breach e defacement contro obiettivi israeliani sui propri canali Telegram. È la stessa tattica di copertura vista in altri cluster iraniani — un layer “civile” che permette a Teheran di condurre operazioni offensive negando plausibilmente il coinvolgimento statale, mentre online si costruisce consenso e narrativa a supporto della causa filo-palestinese.

A marzo 2026 il Dipartimento di Giustizia USA ha reso pubblica un’incriminazione che collega individui operanti sotto l’ombrello Handala al MOIS, inquadrando le loro attività in un più ampio programma di “operazioni psicologiche cyber-abilitate” — disinformazione, intimidazione e raccolta di intelligence combinate nello stesso apparato. Lo stesso ecosistema di attori legati a Teheran è stato osservato a marzo colpire con un wiper l’azienda Stryker e violare la casella di posta personale del direttore dell’FBI, segno di un’operatività che spazia dal sabotaggio industriale allo spionaggio mirato su singole persone.

Come funziona l’avvicinamento

La campagna descritta da Shin Bet non punta a exploit zero-day, ma a ingegneria sociale paziente e su misura, costruita specificamente attorno al mestiere del giornalista. Gli operatori contattano il bersaglio fingendosi conoscenti, colleghi o addirittura firme note — tra i nomi usati come esca, secondo le ricostruzioni giornalistiche, anche quello del noto reporter Barak Ravid — con proposte di collaborazione, richieste di intervista o l’offerta di materiale esclusivo su sviluppi politici e militari, l’esca perfetta per chi vive di scoop.

Da lì si dipartono tre vettori distinti, spesso combinati nella stessa conversazione:

• Link a pagine di login contraffatte che imitano Google, per catturare credenziali dell’account principale e, con esso, l’accesso a mail, contatti e cronologia dei documenti condivisi;
• Link a Google Drive falsificati che rimandano a documenti “esclusivi” ma in realtà instradano verso pagine di raccolta credenziali identiche a quelle originali;
• File malevoli inviati come allegati — presunti dossier, registrazioni o documenti di interesse — che una volta aperti concedono accesso completo al dispositivo mobile, inclusi messaggistica, microfono e geolocalizzazione.

L’obiettivo dichiarato dalle autorità israeliane non è solo la singola casella di posta: è la ricostruzione della rete di fonti del giornalista, l’accesso a materiali di lavoro non ancora pubblicati e, in prospettiva, la possibilità di alimentare operazioni di influenza usando conversazioni sottratte, come già avvenuto in altri episodi in cui gruppi legati a Teheran hanno pubblicato messaggi privati rubati per screditare bersagli israeliani.

Perché conta per chi si occupa di difesa

Il caso Handala è un promemoria scomodo per chi lavora in redazioni, ONG e uffici stampa che trattano materiale sensibile su Medio Oriente: l’anello debole non è quasi mai l’infrastruttura tecnica, ma la fiducia interpersonale che il mestiere stesso richiede di concedere a sconosciuti. Un attaccante di livello statale che parla la lingua del settore — propone uno scoop, cita eventi reali, imita lo stile di un collega — supera in un colpo solo gran parte delle difese tecniche standard, perché la vittima interagisce volontariamente con il contenuto malevolo.

Per i team di sicurezza che proteggono realtà editoriali o organizzazioni esposte, le raccomandazioni diffuse da Shin Bet restano il primo presidio praticabile:

• Verificare l’identità di chi propone collaborazioni o interviste tramite un canale separato da quello di primo contatto, prima di aprire qualunque link o allegato;
• Non inserire mai credenziali dopo aver seguito un link ricevuto in chat, per quanto il mittente sembri legittimo — meglio digitare manualmente l’indirizzo del servizio;
• Attivare l’autenticazione a due fattori tramite app authenticator (non SMS) su tutti gli account di posta e cloud storage;
• Impostare indirizzi di recupero account separati e monitorati;
• Segmentare i dispositivi usati per il lavoro giornalistico da quelli personali, quando possibile, e mantenere aggiornati i sistemi operativi mobili.

Handala dimostra ancora una volta come i confini tra hacktivismo, spionaggio statale e guerra dell’informazione si siano ormai dissolti: lo stesso gruppo che rivendica breach “per la causa” su Telegram può, il giorno dopo, star raccogliendo materiale per un dossier destinato ai servizi. Per i difensori, l’unica postura sensata è trattare ogni contatto non sollecitato — anche il più credibile — come potenzialmente ostile.

Indicatori e riferimenti

Attore: Handala (Handala Hack Team) — collegato al MOIS iraniano
Vettori: WhatsApp, Telegram
TTP: impersonificazione di giornalisti/contatti noti, phishing credenziali Google,
     Google Drive link contraffatti, allegati malevoli per compromissione mobile
Target: giornalisti e figure pubbliche israeliane (es. redazioni come Haaretz)
Incriminazione USA: marzo 2026 (Dipartimento di Giustizia, MOIS)
Allerta ufficiale: Shin Bet + National Cyber Directorate, 16 agosto 2026
Canale di segnalazione IL: hotline 119 (National Cyber Directorate)

404 Media

2026-08-17 14:56:24

‘Show How 3M Is 0% at Fault:’ Expert Witness Used ChatGPT to Write Report Defending Company in Deadly Explosion Lawsuit

An expert witness testifying in a lawsuit about liability for a Houston explosion that killed three people and destroyed roughly 200 homes used ChatGPT to write significant portions of his “expert report.” The man, who was hired by the industrial product conglomerate 3M, exposed his AI prompts publicly. They showed that he asked ChatGPT to help him “create an exceptional expert witness report defending the standard of care at 3M,” and that the report should “show how 3M is 0% at fault for the explosion at Watson Grinding.”

The incident shows that artificial intelligence has made its way into courtrooms not just in AI-generated legal briefings, hallucinated cases, and adversarial “prompt injections,” but in expert witness testimonies. Court transcripts, deposition documents, and discovery records shared with 404 Media show extensive AI use in an extremely high profile case, where multiple people died and hundreds of millions of dollars in total liability are at stake in ongoing litigation about the explosion. The case also shows that the specific prompts used to create this type of expert testimony can be discoverable during a case, and that those prompts can be quite embarrassing. (Prompts provided in the case are here).

The case is one of several about liability for a 2020 explosion at Watson Grinding, a manufacturing facility in Houston that was caused by a “degraded and poorly crimped rubber welding hose,” which leaked a flammable gas that eventually exploded in the facility, according to the U.S. Chemical Safety and Hazard Investigation Board. Dozens of homeowners have sued 3M and Watson Grinding; the plaintiffs alleged that 3M didn’t properly service the facility’s gas detection system and made other errors that contributed to the explosion.

As part of the case, 3M hired a man named Josh Autenrieth of Knighthawk Engineering to prepare an “expert report” about the explosion. During discovery in the case, Will Moye, one of the plaintiffs’ attorneys, found a five-page document called “Citation Overlay,” which appeared to have been generated by AI. Moye recognized the Citation Overlay document as being from ChatGPT, and demanded all of the prompts Autenrieth used from 3M’s lawyers. The deposition was paused for three hours while they were gathered, and Moye was given 350 pages of ChatGPT conversations that Autenrieth had when creating the report. Those documents included ChatGPT’s public links to Autenrieth’s full conversations. Court transcripts suggest that 3M paid Knighthawk Engineering roughly $90,000 for its analysis, and a filing by 3M shows that Autenrieth’s rate was $475 per hour.
From the cover page of the report
The conversations show much of Autenrieth’s process from start to finish, which included telling ChatGPT that he was “being retained as a professional expert witness by 3M in defense of them in their lawsuits and other legal proceedings behind the January 2020 explosion at Watson Grinding.” He told ChatGPT that he needed “to create an expert witness report to defend 3M’s standard of care for their work,” and that, specifically, it needed “to counter the defense witness [sic] outlandish and false claims particularly about working on equipment you are not trained to and without the right permitting.” He asked ChatGPT to help him find violations of various working standards, then attached hundreds of court records.

Autenrieth then asked ChatGPT to read all of the attached records and to defend 3M, “illustrating the lack of [Process and Safety Management] and safety by Watson Grinding, defeating [the defense witness’] comments […] and show how 3M is 0% at fault for the explosion at Watson Grinding and how my background and experience is well suited to render this professional opinion.”

ChatGPT created a roughly 30-page report that included the line “From a technical and standard-of-care standpoint, 3M is 0% responsible for the January 24, 2020 explosion.” This line did not make it into the final report filed with the court, because when Autenrieth later asked ChatGPT to “review this as the opposing council,” ChatGPT determined that writing “‘0% responsible’ is an easy target” for a lawyer to poke holes in, and is one of several "phrases [that] let opposing counsel paint you as an advocate rather than an expert."

In another chat, Autenrieth uploaded an image of a gas detector and asked ChatGPT “what am I looking at?,” and asked “what are model names of industrial gas detectors.” Moye said that the gas detector in question is “the subject of the whole case.”

Autenrieth used ChatGPT to help him make various edits to the report it had generated, and repeatedly uploaded different versions of the report, getting revisions from the tool, then uploading new versions of the report (in some of the chats he changed the subject from his expert witness testimony to having ChatGPT generate t-shirt images). He also asked ChatGPT to “grade” his report (it got a 97/100), and “what are the 5 main things in my report the prosecution could attack and how do I defend them?” He then asked ChatGPT if his resume was sufficient to be an expert witness; “will prosecution go after me for never having been [an expert witness] before based on wording and how do I defend that?”

The report that Autenrieth submitted to the court is structured the same as the initial output given by ChatGPT and large swaths of it are identical to what ChatGPT first outputted and the revisions that it recommended in Autenrieth’s subsequent chats.

“This expert relied on AI not as an assistive device, but exclusively relied on ChatGPT to form his opinions and write his report,” Moye told 404 Media in a phone interview. “He acknowledged [at trial] the prompts he put in were biased toward 3M to help 3M win the case […] it’s really egregious.” Moye added that many of the prompts took place the night before Autenrieth was deposed as an expert witness. “They hired him for the sole purpose of changing the outcome of the case. They hired him and he used ChatGPT to write these reports, so really, ChatGPT was the expert in the case. There’s just no question about that.”

Moye told 404 Media that 3M eventually tried to get Autenrieth disqualified from the trial, but that after he learned Autenrieth extensively used AI to generate his report, he took the somewhat unusual step of calling the other side’s expert witness as his own witness. “I said, I’m calling you to trial because I need a jury to hear from you because this is bad, bad stuff. And that’s exactly what I did,” Moye said.

In trial transcripts, Autenrieth admits to using ChatGPT, but said repeatedly that he is an expert in gas detection: “I've got a body of work and 20-plus years of experience in the industry.” He did not explain why he used ChatGPT, but said “my opinions were put in there, and AI helped me to draft a straw man to build off of,” and added “I put information and opinions in up front before it ever generated […] if the output wasn't of my opinion or what I agreed to, I did alter it.” In the examination at trial, Moye and Autenrieth agree that the submitted report is “90 to 85 percent ChatGPT.” Autenrieth also said that he prompted ChatGPT about the case several times while “sitting in traffic” to “jog my memory” about several different manufacturers of gas detectors.

Beyond this being a highly interesting case on its own merits, it shows that ChatGPT transcripts can be obtained by opposing lawyers in discovery or during depositions. Moye said “every lawyer needs to make sure their own experts aren’t generating work product in a way that’s insincere, and then knowing you can subpoena the prompts [...] I’ve got lawyers all over the place saying, 1) ‘Holy shit, man. How did you get the prompts?,’ and 2) ‘How many cases do I have where this is happening to us?’”

Autenrieth is not the first expert caught using AI during a trial, though most known cases have been international, according to a database of cases in which AI was used to create evidence. In a case in France, a lawyer used AI to make an argument about rainwater patterns in a flooding dispute; that evidence was thrown out. In Canada, AI was used to generate opinions about whether specific types of plants caused a bug infestation at an apartment complex. The judge in that case wrote “I place no weight on the [AI evidence]. Expert evidence must come from a known individual with known qualifications who has specific knowledge about the issue at hand.”

The jury in the 3M case awarded more than $61 million to the plaintiffs, apportioning 30 percent of the responsibility to 3M and 70 percent to Watson Grinding. Previous decisions awarded $118 million and 38 million to victims of the blast, and there are several more upcoming cases.

Knighthawk Engineering, Autenrieth, and 3M did not respond to a request for comment

Harris County jury orders 3M to pay $61.5 million settlement after Watson Grinding explosion lawsuit | Houston Public Media

The explosion, which took place near a residential area in northwest Houston in 2020, killed three people and damaged hundreds of nearby homes and businesses.

^{Natalie Weber (Houston Public Media)}

404 Media

2026-08-18 13:27:22

X's Algorithm Feeds Off Ragebait and Impacts Democrats More, Study Finds

X’s algorithm learns what you hate and shows you more of it, according to a new study just published in the Proceedings of the National Academy of Sciences (PNAS). The paper, titled Value misalignment of X’s feed algorithm is a reflection of value tensions in engagement, found that the site’s algorithm prioritized engagement above all else when it generated a user’s For You Page. It also showed that X serves more ragebait to people who say they are Democrats, although the exact reason for that is unclear.

“In 2026 that’s maybe not the most surprising headline ever,” Ziv Epstein, a postdoctoral researcher at Stanford University, and co-author of the paper, told 404 Media. “So we actually dug in a little deeper to figure out why this is actually happening, and it turns out that X's feed algorithm, like a lot of these social media algorithms, is optimized for engagement [but] it turns out that not all types of engagement are considered equally.”
playlist.megaphone.fm?p=TBIEA2…
The study’s goal was to understand how a user’s self-professed values system might shape what they see on X. “We recruited a nationally representative sample of N = 715 Americans who are active users of X in September and October 2024, quota matched on ethnicity, gender and partisanship, to install a browser extension to collect their [For You Page] and Following feeds,” the study said.

Epstein said the study was observational and meant to get people asking questions about what they want to see on social media, how their feed is designed, and by whom. “There are these social media algorithms that have enormous amounts of power in our lives, they shape the information that we consume, and we have very little transparency into how they operate and what their implications are,” he said. “And so, we were very interested in trying to understand the particular effects of this particular algorithm, and so I think that has kind of important implications for civil society and just fighting some of the technofeudalistic tendencies of platforms to control these algorithms.”

For the study, researchers collected a “values inventory” of the volunteers using a research tool called the Schwartz Theory of Basic Values. The values inventory in the study is presented as a wheel with 19 points that corresponded to features like “tolerance,” “dominance,” “hedonism,” and “openness to change.” Users also reported their political alignments.

Then researchers watched how users engaged with posts on X and how those posts reflected their self-reported values. “We observe that the inventory of posts from followed accounts reflects users’ self-stated values — but that there is an overall negative correlation (misalignment) between users’ explicit values and the values in content that the algorithm is more likely to amplify,” the study said.

When a user on X sees a post that makes them mad — like a press release from a politician from a political party they don’t like — sometimes they’ll fight about the post in the replies. It doesn’t matter who you follow or what your stated values are, X reads replying as engagement and will send more of the infuriating posts the user’s way.

“When we look at commenting, the act of replying to posts, that's where we actually see some kind of meaningful misalignment between people’s values and the values of the content they’re replying to,” Epstein explained.

Most of the participants liked and reposted content on X and got served more of the same sort of content. Replying was rare, just 6.8% of the interactions according to the study, but had an outsized impact on the algorithm. “Replying is only a fraction of engagement, but there does seem to be some evidence that these algorithms are prioritizing and learning more from this kind of rarer form of engagement,” Epstein said. “So it’s this feedback loop of outrage baiting. The algorithm learns that you get outraged and then continues to serve more content in that direction and that seems to be particularly true of the Democratic users of our study.”

Though this happened across the political spectrum, the study found that ragebaiting occurred more for users that identified themselves as Democrats. “Democrat users confront the abundant value-misaligned content by replying to it, which the algorithm in turn preferentially learns from and continues to feed them,” the study said. “This highlights a core tension with how engagement-maximizing algorithms operate on social media: frictions between users’ stated preferences and their behaviors of reactive confrontation are exploited by engagement-maximizing algorithms to create runaway feedback loops of increasing value misalignment.”

Epstein said he’d need to do more research to find out why X seems to serve ragebait to Democrats more often than Republicans. It could be that there’s more rightwing content on X overall or it could be that Democrats tend to engage with posts they disagree with more often. “There might be some kind of differential effects on information diets there, or it might be something more psychological about how different you know partisan identities are triggering different kinds of actions and reactions, but ultimately I don't want to speculate too much,” he said.

I asked Epstein if he worried that prioritizing “values” in a social media algorithm might lead to more siloed user bases and more echo chambers. “I do think that if we go kind of down this path of thinking through and imagining value line social media feeds, we do have to be very aware of the potentials of value echo chambers, right?” he said. “Where people just, you know, they have the certain values that they have, and all the content they see is just aligned with those values. I think that is a very scary and dark reality.”

But he also said that values are intentional and that thinking about the kind of stuff you want to see on a social media site before you pull up your feed is a positive. “You're pumping the brakes, you're taking a breath, and you're thinking about what you actually really care about. In this world — and I don't have the data for this — but I would speculate that a lot of people actually do care about seeing a diverse set of content and engaging meaningfully across these lines, and you know maybe that isn't a particular value on my 19-dimensional wheel, but this is just a starting point of thinking about our intentions and thinking very deliberately about the kind of information we want to be exposed to, versus the the knee-jerk reaction that we're kind of learning in this very kind of short, shallow attention span, emotion and negative affect-driven model of these very myopic forms of engagement.”

X did not return 404 Media’s request for comment, but Nikita Bier — X’s former head of product — confirmed that the site’s algorithm had at one time been set to favor replies. “This is no longer true,” Bier said in a post on X. “The largest contributor of seeing ragebait was the reply predictor and we were aware that angry replies were causing people to see more of that content. So last month, we gave the reply predictor a 15x boost if it’s a friend’s post — and it reduced ragebait by [an] order of magnitude.”

Update 8/18/26 at 1:30PM: This story has been updated to include a comment from X’s former head of product

Nikita Bier (@nikitabier) on X

@jason_koebler This is no longer true: The largest contributor of seeing ragebait was the reply predictor and we were aware that angry replies were causing people to see more of that content.

^{Nikita Bier (X (formerly Twitter))}