L’imperativo senza segreti: Perché i modelli di sicurezza tradizionali si rompono quando gli agenti di intelligenza artificiale toccano il codice

Nell’aprile 2023,  Samsung ha scoperto che i suoi ingegneri avevano fatto trapelare informazioni sensibili a ChatGPT. Ma quello era accidentale. Ora immagina se quei repository di codice avessero contenuto istruzioni deliberate e invisibili agli esseri umani, ma elaborate dall’intelligenza artificiale, progettate per estrarre non solo il codice, ma ogni chiave API, credenziale del database e token del servizio che l’intelligenza artificiale poteva accedere. Questo non è ipotetico. I ricercatori di sicurezza hanno già dimostrato che questi attacchi di “istruzioni invisibili” funzionano. La domanda non è se questo accadrà, ma quando.

Il confine che non esiste più

Per decenni, abbiamo costruito la sicurezza su un’ipotesi fondamentale: il codice è codice e i dati sono dati. L’iniezione di SQL ci ha insegnato a parametrizzare le query. L’attacco di cross-site scripting ci ha insegnato a sfuggire le uscite. Abbiamo imparato a costruire muri tra ciò che i programmi fanno e ciò che gli utenti immettono.

Con gli agenti di intelligenza artificiale, quel confine è evaporato.

A differenza del software deterministico che segue percorsi prevedibili, i grandi modelli linguistici sono scatole nere probabilistiche che non possono distinguere tra istruzioni legittime degli sviluppatori e input malintenzionati. Quando un attaccante fornisce un prompt a un assistente di codifica dell’intelligenza artificiale, non sta solo fornendo dati. Sta essenzialmente riprogrammando l’applicazione al volo. L’input è diventato il programma stesso.

Ciò rappresenta una rottura fondamentale con tutto ciò che sappiamo sulla sicurezza delle applicazioni. I firewall tradizionali basati sulla sintassi, che cercano modelli malintenzionati come DROP TABLE o <script> tags, falliscono completamente contro gli attacchi del linguaggio naturale. I ricercatori hanno dimostrato tecniche di “sostituzione semantica” in cui sostituire “chiavi API” con “mele” nei prompt consente agli attaccanti di bypassare completamente i filtri. Come si può proteggere l’intento quando è mascherato da conversazione innocua?

La realtà del click zero che nessuno discute

Ecco cosa la maggior parte dei team di sicurezza non capisce: l’iniezione di prompt non richiede che un utente digiti qualcosa. Questi sono spesso exploit di click zero. Un agente di intelligenza artificiale che semplicemente esamina un repository di codice per una routine, esamina una richiesta di pull o legge la documentazione dell’API può attivare un attacco senza alcuna interazione umana.

Considera questo scenario, basato su tecniche che i ricercatori hanno già dimostrato: un attaccante malintenzionato incorpora istruzioni invisibili nei commenti HTML all’interno della documentazione di una libreria open-source popolare. Ogni assistente di intelligenza artificiale che analizza questo codice, sia GitHub Copilot, Amazon CodeWhisperer o qualsiasi assistente di codifica aziendale, diventa un potenziale raccoglitore di credenziali. Una libreria compromessa potrebbe significare migliaia di ambienti di sviluppo esposti.

Il pericolo non è il modello di linguaggio stesso; è l’agenzia che gli diamo. Il momento in cui abbiamo integrato questi modelli con strumenti e API, lasciandoli recuperare dati, eseguire codice e accedere a segreti, abbiamo trasformato assistenti utili in vettori di attacco perfetti. Il rischio non aumenta con l’intelligenza del modello; aumenta con la sua connettività.

Perché l’approccio attuale è condannato

L’industria è attualmente ossessionata dall'”allineamento” dei modelli e dalla costruzione di migliori firewall di prompt. OpenAI aggiunge più guardrail. Anthropic si concentra sull’intelligenza artificiale costituzionale. Tutti stanno cercando di creare modelli che non possano essere ingannati.

Questa è una battaglia persa.

Se un’intelligenza artificiale è abbastanza intelligente da essere utile, è abbastanza intelligente da essere ingannata. Stiamo cadendo nella “trappola della sanificazione”: assumendo che un miglior filtraggio degli input ci salverà. Ma gli attacchi possono essere nascosti come testo invisibile nei commenti HTML, sepolti nella documentazione o codificati in modi che non abbiamo ancora immaginato. Non puoi sanificare ciò che non puoi capire contestualmente, e il contesto è esattamente ciò che rende potenti i modelli di linguaggio.

L’industria deve accettare una dura verità: l’iniezione di prompt avrà successo. La domanda è cosa succede quando ciò accade.

Il cambiamento architettonico di cui abbiamo bisogno

Ci troviamo attualmente in una “fase di patching”, aggiungendo disperatamente filtri di input e regole di convalida. Ma proprio come abbiamo imparato che prevenire l’iniezione di SQL richiedeva query parametrizzate, non una migliore fuga delle stringhe, abbiamo bisogno di una soluzione architettonica per la sicurezza dell’intelligenza artificiale.

La risposta si trova in un principio che suona semplice ma richiede una rielaborazione di come costruiamo i sistemi: gli agenti di intelligenza artificiale non dovrebbero mai possedere i segreti che utilizzano.

Non si tratta di una migliore gestione delle credenziali o di soluzioni di vault migliorate. Si tratta di riconoscere gli agenti di intelligenza artificiale come identità univoche e verificabili piuttosto che utenti che necessitano di password. Quando un agente di intelligenza artificiale deve accedere a una risorsa protetta, dovrebbe:

1. Autenticarsi utilizzando la sua identità verificabile (non un segreto archiviato)

2. Ricevere credenziali just-in-time valide solo per quel compito specifico

3. Avere quelle credenziali scadere automaticamente entro secondi o minuti

4. Non archiviare o anche solo “vedere” segreti a lungo termine

Stanno emergendo diversi approcci. Ruoli IAM di AWS per account di servizio, Identità del carico di lavoro di Google, segreti dinamici di HashiCorp Vault e soluzioni specifiche come Akeyless’s Zero Trust Provisioning puntano tutti verso questo futuro senza segreti. I dettagli di implementazione variano, ma il principio rimane: se l’intelligenza artificiale non ha segreti da rubare, l’iniezione di prompt diventa una minaccia significativamente più piccola.

L’ambiente di sviluppo del 2027

Entro tre anni, il file .env sarà morto nello sviluppo aumentato dall’intelligenza artificiale. Le chiavi API a lungo termine che siedono nelle variabili di ambiente saranno viste come vediamo ora le password in testo normale: un relitto imbarazzante di un’epoca più ingenua.

Invece, ogni agente di intelligenza artificiale opererà con una rigorosa separazione dei privilegi. Accesso in sola lettura per impostazione predefinita. L’elenco delle azioni consentite come standard. Ambienti di esecuzione sandbox come requisito di conformità. Smetteremo di cercare di controllare ciò che l’intelligenza artificiale pensa e ci concentreremo interamente sul controllo di ciò che può fare.

Non si tratta solo di un’evoluzione tecnica; è un cambiamento fondamentale nei modelli di fiducia. Stiamo passando da “fidarsi ma verificare” a “non fidarsi mai, verificare sempre e assumere il compromesso”. Il principio del minimo privilegio, a lungo predicato ma raramente praticato, diventa inderogabile quando il tuo junior sviluppatore è un’intelligenza artificiale che elabora migliaia di input potenzialmente malintenzionati ogni giorno.

La scelta che affrontiamo

L’integrazione dell’intelligenza artificiale nello sviluppo del software è inevitabile e in gran parte benefica. GitHub riporta che gli sviluppatori che utilizzano Copilot completano i compiti il 55% più velocemente. I guadagni di produttività sono reali e nessuna organizzazione che desidera rimanere competitiva può ignorarli.

Ma ci troviamo a un bivio. Possiamo continuare lungo il percorso attuale aggiungendo più guardrail, costruendo migliori filtri, sperando di poter creare agenti di intelligenza artificiale che non possano essere ingannati. Oppure possiamo riconoscere la natura fondamentale della minaccia e ricostruire la nostra architettura di sicurezza di conseguenza.

L’incidente Samsung è stato un colpo di avvertimento. La prossima violazione non sarà accidentale e non sarà contenuta in una sola azienda. Man mano che gli agenti di intelligenza artificiale guadagnano più capacità e accedono a più sistemi, l’impatto potenziale cresce esponenzialmente.

La domanda per ogni CISO, ogni leader tecnico e ogni sviluppatore è semplice: quando l’iniezione di prompt avrà successo nel tuo ambiente (e lo farà), cosa troverà l’attaccante? Scoprirà un tesoro di credenziali a lungo termine o troverà un agente di intelligenza artificiale che, nonostante sia compromesso, non ha segreti da rubare?

La scelta che facciamo ora determinerà se l’intelligenza artificiale diventerà il più grande acceleratore dello sviluppo del software o la più grande vulnerabilità che abbiamo mai creato. La tecnologia per costruire sistemi di intelligenza artificiale sicuri e senza segreti esiste oggi. La domanda è se la implementeremo prima che gli attaccanti ci costringano a farlo.

OWASP ha già identificato l’iniezione di prompt come il #1 rischio nella loro Top 10 per le applicazioni dei modelli di linguaggio.  NIST sta sviluppando linee guida sulle architetture di zero trust. I framework esistono. La sola domanda è la velocità di implementazione rispetto all’evoluzione dell’attacco.