La sicurezza dell'IA è un problema ingegneristico — come risolverla a ogni livello della pila degli agenti

La sicurezza dell’IA come disciplina ingegneristica

L’affermazione che la sicurezza dell’intelligenza artificiale sia un problema di ingegneria implica tre elementi fondamentali: requisiti di sicurezza ben definiti, controlli applicabili e verificabili, e responsabili nominati che possano dimostrare l’efficacia delle protezioni. Quando le capacità degli agenti aumentano, l’industria deve accelerare lo sviluppo di pratiche di security engineering, rendere più accessibili gli strumenti difensivi e condividere rapidamente le soluzioni che funzionano.

Cambiamenti tecnologici e costanti fondamentali di sicurezza

Internet e il cloud hanno trasformato il modo in cui il software viene eseguito, ma le responsabilità di base della sicurezza sono rimaste le stesse: stabilire identità, controllare gli accessi, limitare l’esposizione e verificare che le difese operino correttamente. Gli agenti IA introducono nuove capacità — ragionamento, utilizzo di strumenti e adattamento in base ai dati incontrati — che richiedono l’applicazione di questi principi a condizioni operative diverse.

Pressioni e opportunità per le organizzazioni

Le organizzazioni desiderano sfruttare la produttività offerta dall’IA, ma le pratiche per governare e proteggere questi sistemi sono ancora in evoluzione. Questa tensione genera la necessità di costruire difese fin dalle prime fasi di sviluppo, evitando che le opportunità di innovazione vengano ostacolate da vulnerabilità non gestite.

La dipendenza della sicurezza dall’intera pila dell’agente

Un’applicazione IA si basa su codice, dati, identità, servizi e infrastruttura. La sicurezza dipende da come questi componenti interagiscono, e gli agenti IA estendono tale sistema. I modelli forniscono capacità; gli harness organizzano contesto, strumenti e flussi di lavoro; gli ambienti di runtime offrono l’infrastruttura in cui le azioni vengono eseguite. Ogni livello della pila porta proprie responsabilità di sicurezza, perciò è necessario implementare controlli in tutti gli strati mentre dati, istruzioni e azioni attraversano il sistema.

Esempio pratico di rischio nella pila

Consideriamo un agente che deve aggiornare il profilo di un cliente. Se l’agente riceve un documento allegato contenente istruzioni malevole e tenta di esportare i dati del cliente verso una destinazione non autorizzata, diversi meccanismi di difesa dovrebbero intervenire:

• Una policy di rete blocca il trasferimento verso l’indirizzo esterno.
• I log protetti registrano la chiamata allo strumento, la decisione di autorizzazione e il risultato, consentendo al team di sicurezza di identificare lo strumento usato e la destinazione tentata.
• Il permesso di aggiornare il record non dovrebbe estendersi automaticamente al diritto di esportare i dati; l’agente può richiedere accessi aggiuntivi, ma non può concederli autonomamente.

Costruire la sicurezza nel modo in cui gli agenti operano

Il confine di sicurezza deve rimanere valido anche quando un agente prende decisioni errate. L’ambiente di esecuzione determina cosa l’agente è autorizzato a fare e deve imporre limiti su file, destinazioni di rete e processi indipendentemente dal ragionamento dell’agente. Istruzioni e salvaguardie possono guidare il comportamento, ma è necessario un confine applicabile e verificabile.

Ogni agente deve disporre di un’identità tracciabile e di credenziali limitate al compito assegnato. Le organizzazioni devono definire chiaramente quali informazioni gli agenti possono accedere, quali sistemi possono modificare e quali azioni richiedono approvazione umana. All’interno di questi limiti, le azioni consequenziali e le modifiche di permesso devono comunque passare attraverso un processo di revisione.

È inoltre fondamentale verificare la provenienza e l’integrità di strumenti, skill e dipendenze utilizzate dagli agenti. In caso di errore, i record protetti di chiamate a strumenti, decisioni di autorizzazione e risultati consentono agli investigatori di ricostruire l’accaduto. Procedure chiare per revocare accessi e contenere incidenti rendono queste evidenze operative.

Esempi di runtime sicuri e partnership

Tra le soluzioni più rilevanti troviamo NVIDIA OpenShell, un runtime open source che applica politiche fuori dal controllo dell’agente e fornisce esecuzione sandboxata, governando l’accesso a dati, rete e risorse di sistema.

Alcuni partner dell’Open Secure AI Alliance stanno ampliando OpenShell:

• Cisco DefenseClaw aggiunge un livello di governance.
• JFrog si integra per scansionare e verificare le skill degli agenti, imponendo politiche su quali skill possono essere utilizzate.

Evidence engineering: testare la sicurezza prima del rilascio

Prima di distribuire un agente, i team devono produrre evidenze che i controlli blocchino tentativi di ottenere credenziali oltre lo scopo dell’agente o di inviare dati sensibili a destinazioni non autorizzate. I test devono coprire anche tentativi di modificare permessi o interferire con il monitoraggio, e devono essere ripetuti dopo modifiche sostanziali a modelli, strumenti o workflow.

Un responsabile nominato utilizza i risultati per decidere se il sistema è pronto per il deployment e garantisce che i test falliti portino a azioni correttive. I fallimenti scoperti durante il test o l’operatività devono essere riprodotti, investigati e risolti. Ogni scoperta può diventare un test ripetibile, consentendo ai team di verificare che la correzione continui a funzionare nelle versioni future.

Esempi di piattaforme che supportano questo approccio includono:

• CrowdStrike SafeMind per simulazioni di attacco ricorrenti volte a rafforzare le difese.
• Palo Alto Networks Prisma AIRS per red teaming continuo mentre modelli e applicazioni evolvono.

Strumenti adeguati al momento giusto

Indagare su fallimenti richiede strumenti capaci di adattarsi al compito, ai dati e all’ambiente. I modelli chiusi offrono capacità e servizi gestiti, mentre i modelli open consentono ai difensori di ispezionare componenti rilevanti, adattare strategie e operare su infrastrutture sotto il proprio controllo.

Durante un incidente, questo controllo permette al team di riprodurre il problema e testare una correzione sui propri sistemi, mantenendo le evidenze sensibili all’interno dell’ambiente aziendale