Sicurezza delle applicazioni IA: capacità del modello e confini del sistema.
La sicurezza dipende da dati, accessi, strumenti e azioni consentite. Un modello più capace richiede di rivedere le ipotesi con cui si protegge il sistema.
Le capacità disponibili cambiano
La valutazione NIST del settembre 2026 su GLM-5.3 mostra capacità cyber avanzate in un modello open-weight, ancora sotto la frontiera statunitense nei test aggregati. Segnala una diffusione delle capacità, non la frequenza degli attacchi reali.
La conseguenza che ne ricavo è rivedere periodicamente il modello delle minacce: chi può attaccare il sistema, con quali strumenti, quali dati o funzioni può raggiungere e quale danno può provocare.
Per un servizio esposto, considero quindi ancora più importanti la gestione delle vulnerabilità, l’aggiornamento delle dipendenze e la protezione delle credenziali. Gli stessi strumenti IA possono aiutare anche i difensori, ma le loro segnalazioni richiedono verifica.
I permessi devono restare nell’applicazione
Le istruzioni al modello sono una parte della difesa; i controlli decisivi devono essere applicati dal sistema.
Un documento, una pagina recuperata o l'output di uno strumento può contenere istruzioni ostili. La prompt injection sfrutta questa confusione tra contenuto e istruzioni. Il flusso deve trattare questi elementi come dati non affidabili.
Autorizzazioni e separazione tra utenti vanno verificate dal codice. La proposta di un modello non deve concedere nuovi privilegi né permettere l'accesso a dati che l'utente non potrebbe consultare direttamente.
Limitare le azioni degli agenti
Per ogni strumento collegato al modello, definisco cosa può fare e con quali credenziali. Permessi minimi, operazioni circoscritte e ambienti separati riducono le conseguenze di una richiesta errata o ostile.
- Validare parametri e destinazioni prima di eseguire l'azione.
- Richiedere conferma o una revisione proporzionata al rischio per operazioni rilevanti.
- Prevedere limiti a tentativi, durata e consumo, oltre a una condizione di arresto.
- Registrare le azioni con attenzione ai dati sensibili e poter ricostruire un incidente.
Questi controlli fanno parte del flusso applicativo. Un agente che sa usare più strumenti non deve ricevere automaticamente più autorità.
Valutare la configurazione concreta
Open-weight e servizi proprietari presentano possibilità di controllo e rischi diversi. La disponibilità dei pesi non rende da sola una distribuzione insicura, così come un'API proprietaria non garantisce da sola la sicurezza del prodotto.
Valuto origine e versione del modello, runtime, dipendenze, rete, credenziali, accessi e percorso dei dati. Un ambiente locale richiede comunque manutenzione, aggiornamenti e controllo degli utenti.
Verificare e rivedere nel tempo
Alle prove funzionali affianco richieste ostili, tentativi di accesso non autorizzato e contenuti recuperati che cercano di deviare il flusso. Controllo soprattutto che i confini restino validi quando il modello sbaglia.
Modifiche a modelli, tool, prompt e dati richiedono nuove verifiche. Monitoraggio, segnalazioni e risposta agli incidenti vanno previsti prima del rilascio. È un processo continuo, commisurato alle conseguenze degli errori.
Fonti a supporto
Le valutazioni cyber descrivono i modelli e i test citati. I riferimenti OWASP sostengono i rischi applicativi; le scelte operative vanno adattate al sistema concreto.
- NIST CAISI — GLM-5.3 (si apre in una nuova scheda): capacità cyber e limiti del confronto con la frontiera.
- Anthropic — diffusione delle capacità cyber (si apre in una nuova scheda): valutazioni di exploit e salvaguardie in ambienti di prova.
- OWASP — Prompt Injection (si apre in una nuova scheda): rischi di istruzioni ostili nei contenuti elaborati dal modello.
- OWASP — Excessive Agency (si apre in una nuova scheda): azioni, permessi e autonomia eccessivi nei sistemi con strumenti.