Valutazione della sicurezza e hardening

Il nostro approccio consiste nel violare i sistemi di IA nello stesso modo in cui operano gli attaccanti reali, per poi blindarli contro i percorsi di attacco individuati da una valutazione — dall'estrazione del modello alla compromissione della supply chain. I penetration test tradizionali coprono le vostre API, l'infrastruttura e i flussi di autenticazione, ma non verificano mai se un attaccante possa sottrarre il vostro modello sottoposto a fine-tuning, inserire una backdoor nella vostra catena di dipendenze o dirottare la vostra pipeline RAG. Questa metodologia di valutazione deve essere costruita specificamente per le modalità di fallimento proprie dei sistemi di IA.

Superfici di attacco che il vostro team di sicurezza non ha mai testato

I penetration test tradizionali coprono le vostre API, la vostra infrastruttura e i vostri flussi di autenticazione. Non verificano se un attaccante possa estrarre il vostro modello sottoposto a fine-tuning attraverso 50,000 query accuratamente strutturate. Non rilevano se un adattatore LoRA avvelenato nella vostra catena di dipendenze HuggingFace abbia introdotto una backdoor tre mesi fa. Non valutano se la vostra pipeline RAG eseguirà istruzioni incorporate in un documento recuperato. Questi sono i percorsi di attacco che compromettono realmente i sistemi di IA in produzione.

Non si tratta di rischi teorici presentati a convegni. Protect AI ha individuato 352,000 file sospetti su 51,700 modelli su HuggingFace ad aprile 2025. Gli attacchi basati su IA sono aumentati dell' 89% su base annua, con il 97% delle organizzazioni violate che non disponeva di controlli di accesso di base sui propri sistemi di IA. L' attacco alla supply chain di Mercor all'inizio del 2026 ha compromesso migliaia di aziende attraverso una singola dipendenza open source.

Cosa testiamo realmente — e cosa trascura la maggior parte delle valutazioni

Strutturiamo le valutazioni attorno al framework MITRE ATLAS , che cataloga ora 84 tecniche su 16 tattiche specificamente rivolte ai sistemi di IA. Ma un framework è una mappa, non un test. La nostra metodologia è costruita per eseguire gli attacchi che cataloga, non solo per spuntarli da un elenco.

Deployment di LLM e prompt injection

Testiamo la prompt injection indiretta attraverso ogni canale di ingestione: recupero RAG, output di strumenti, documenti caricati dagli utenti e contenuti email inviati agli agenti. L'iniezione diretta conquista i titoli, ma Anthropic ha abbandonato del tutto la propria metrica sull'iniezione diretta a febbraio 2026 perché l'iniezione indiretta tramite il contesto di recupero è ciò che compromette realmente i sistemi in produzione. Testiamo inoltre la manipolazione multi-turno, l'estrazione del system prompt e le specifiche modalità di fallimento di qualunque stack di guardrail abbiate implementato.

Sicurezza a livello di modello

Valutiamo il rischio di estrazione eseguendo campagne di query strutturate contro le vostre API e misurando quanto del comportamento del modello un attaccante possa replicare. Valutiamo la robustezza avversariale sia con metodi basati su gradiente (quando abbiamo accesso al modello) sia con attacchi black-box basati su trasferimento (il modo in cui operano gli attaccanti reali). Eseguiamo audit della vostra pipeline di addestramento per individuare vulnerabilità di data poisoning, verificando sia i dati di addestramento diretti sia le dipendenze a monte da cui provengono (dettagliato nella nostra ricerca sulla protezione delle aziende dall'avvelenamento dei modelli).

Integrità della supply chain

Tracciamo ogni artefatto del modello fino alla sua sorgente: pesi pre-addestrati, dataset di fine-tuning, livelli di adattatori e versioni del framework di serving. Verifichiamo la presenza di vulnerabilità note nella vostra infrastruttura di ML — PyTorch, vLLM e Triton Inference Server hanno tutti registrato CVE nel 2025–2026 — e verifichiamo che la serializzazione del vostro modello utilizzi formati sicuri. I $12 miliardi di perdite derivate da modelli ML compromessi nel 2025 sono giunti in grandissima parte da attacchi alla supply chain, non dallo sfruttamento diretto dei modelli (vedere la nostra ricerca sulla protezione del ciclo di vita della supply chain ML).

Sistemi agentici

Testiamo la superficie di attacco definita dalla Top 10 di OWASP per l'IA agentica : dirottamento degli obiettivi (goal hijacking), uso improprio degli strumenti, abuso di identità, avvelenamento della memoria e fallimenti a cascata nei flussi di lavoro multi-agente. La crisi di OpenClaw nel 2026 — in cui 21,000+ istanze di un agente IA con 135,000 stelle sono state esposte a vulnerabilità critiche — ha mostrato cosa accade quando gli agenti vengono rilasciati senza questi test (dettagliato nella nostra ricerca sulla messa in sicurezza della frontiera umano-IA).

Hardening che cambia il modo di operare del vostro sistema

Una valutazione senza remediation è solo un costoso file PDF. Il nostro approccio integra i controlli di hardening direttamente nel vostro sistema.

• Inference-layer defense: rilevamento delle anomalie nelle query che identifica il traffico con pattern di estrazione — copertura sistematica degli input, probing dei confini e scansioni programmatiche di parafrasi — distinguendolo dall'utilizzo legittimo. Le pipeline di validazione degli input sono calibrate sul vostro specifico modello di minaccia, non su filtri regex generici che non rilevano gli attacchi semantici e bloccano le query legittime.
• Supply chain hardening: pipeline di verifica dei modelli che controllano la provenienza degli artefatti, convalidano i formati di serializzazione, scansionano alla ricerca di pattern malevoli noti e impongono requisiti di firma prima che qualunque artefatto del modello entri nella vostra pipeline di deployment — oltre al monitoraggio delle dipendenze che intercetta i pacchetti a monte compromessi prima che raggiungano la produzione.
• Agentic system hardening: perimetri di privilegio attorno all'accesso agli strumenti, validazione degli output tra i passaggi dell'agente e monitoraggio comportamentale che rileva quando il pattern di esecuzione di un agente diverge dal suo flusso di lavoro previsto.

Il vostro SIEM è stato progettato per rilevare anomalie nel comportamento umano. Un agente che esegue 10,000 query in sequenza appare normale a tali sistemi anche quando opera sotto il controllo di un attaccante.

Quando non avete bisogno di questo servizio

Se utilizzate un'API gestita (OpenAI, Anthropic, Google) senza fine-tuning, senza RAG, senza l'uso di strumenti e senza dati sensibili nei prompt, il vostro rischio di sicurezza riguarda la gestione delle chiavi API e il trattamento dei dati. Una revisione standard della sicurezza applicativa è sufficiente — non avete bisogno di una valutazione specifica per l'IA.

Se il vostro modello è un semplice classificatore eseguito internamente senza API esposte all'esterno e senza pipeline di riaddestramento, la vostra superficie di attacco è limitata e una breve revisione del modello di minaccia è proporzionata. Eseguire test completi di robustezza avversariale su un classificatore di sentiment interno protetto da firewall significa spendere $30,000 per proteggere un rischio da $500.

Lo diciamo con franchezza perché la credibilità conta più del fatturato. Le organizzazioni che necessitano di questo lavoro sanno di averne bisogno: chiunque disponga di modelli sottoposti a fine-tuning, pipeline RAG che elaborano contenuti esterni, sistemi agentici con accesso a strumenti, modelli in settori regolamentati o sistemi di IA che prendono decisioni con impatti finanziari o di sicurezza.

La pressione normativa è reale e prevede scadenze precise

L'applicazione dell'EU AI Act inizia ad agosto 2026. I sistemi di IA ad alto rischio richiedono una gestione documentata dei rischi, test di robustezza tecnica e controlli di data governance. La mancata conformità comporta sanzioni fino al 7% del fatturato annuo globale o EUR 35 milioni. Il NIST ha pubblicato il suo Cybersecurity Framework Profile for AI a dicembre 2025, mappando i rischi specifici dell'IA sui controlli CSF 2.0. Questi framework compaiono ormai nei requisiti di approvvigionamento e nelle revisioni del rischio a livello di consiglio di amministrazione.

La difficoltà risiede nel fatto che nessun singolo framework copre tutto. Mappiamo i risultati della vostra valutazione sui framework richiesti dai vostri regolatori, revisori e clienti — producendo evidenze che soddisfano i requisiti di conformità poiché derivano da test reali, non da semplici spunte di controllo.

Strumenti di piattaforma vs. valutazione su misura

Le piattaforme automatizzate di sicurezza dell'IA (HiddenLayer, Mindgard, Giskard) eseguono pattern di attacco noti su larga scala. Sono utili per test di regressione continui dopo una valutazione iniziale, ma non sostituiscono la valutazione iniziale stessa. Uno scanner non comprende la vostra logica di business, non sa quali output del modello comportino conseguenze critiche per la sicurezza e non può valutare se il vostro modello di minaccia corrisponda alla vostra effettiva architettura di deployment.

Utilizziamo questi strumenti laddove apportano valore. Il red teaming automatizzato e continuo appartiene alla vostra pipeline di CI/CD una volta stabilito cosa testare. Tuttavia, i percorsi di attacco più critici nel vostro sistema specifico richiedono, per essere individuati, qualcuno che comprenda sia le modalità di fallimento dell'IA sia il vostro contesto operativo.

Per le organizzazioni che utilizzano molteplici fornitori di IA (OpenAI, Anthropic, Google, modelli open-source), valutiamo i perimetri di sicurezza di ciascun fornitore in modo indipendente e testiamo i punti di integrazione in cui i dati fluiscono tra di essi. La superficie di attacco di uno stack multi-vendor non è la semplice somma dei rischi di ciascun fornitore — è il livello di interazione, dove i presupposti sulle garanzie di sicurezza di un fornitore vengono meno nel passaggio all'altro.