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

Nell’aprile 2023, Samsung ha scoperto che i suoi ingegneri avevano leakato informazioni sensibili a ChatGPT. Ma quello era accidentale. Ora immaginate se quei repository di codice avessero contenuto istruzioni deliberate, invisibili agli esseri umani ma elaborate dall’AI, progettate per estrarre non solo il codice ma ogni chiave API, credenziale di database e token di servizio che l’AI potesse accedere. Questo non è ipotetico.I ricercatori sulla 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. Il 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 AI, quel confine è evaporato.

A differenza del software deterministico che segue percorsi prevedibili, i Large Language Model 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 AI, 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 basati sulla sintassi, che cercano modelli malintenzionati come DROP TABLE o tag , falliscono completamente contro gli attacchi basati sul 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ò firewallare l’intento quando è mascherato da conversazione innocua?

La realtà zero-click che nessuno sta discutendo

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

Considerate 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 AI 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 LLM stesso; è l’agenzia che gli diamo. Nel momento in cui abbiamo integrato questi modelli con strumenti e API, permettendogli di recuperare dati, eseguire codice e accedere a segreti, abbiamo trasformato assistenti utili in vettori di attacco perfetti. Il rischio non scala con l’intelligenza del modello; scala con la sua connettività.

Perché l’approccio attuale è condannato

L’industria è attualmente ossessionata dall'”allineamento” dei modelli e dalla costruzione di migliori firewall per i prompt. OpenAI aggiunge più barriere di protezione. Anthropic si concentra sull’AI costituzionale. Tutti stanno cercando di creare modelli che non possono essere ingannati.

Questa è una battaglia persa.

Se un AI è abbastanza intelligente da essere utile, è abbastanza intelligente da essere ingannato. Stiamo cadendo nella cosiddetta “trappola della sanificazione”: assumendo che un miglior filtro di input ci salverà. Ma gli attacchi possono essere nascosti come testo invisibile nei commenti HTML, sepolti profondamente nella documentazione o codificati in modi che non abbiamo ancora immaginato. Non si può sanificare ciò che non si può comprendere contestualmente, e il contesto è esattamente ciò che rende potenti i LLM.

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

Attualmente, siamo 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 e non una migliore fuga di stringhe, abbiamo bisogno di una soluzione architettonica per la sicurezza AI.

La risposta giace in un principio che suona semplice ma richiede di ripensare a come costruiamo i sistemi: gli agenti AI 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 AI come identità univoche e verificabili piuttosto che utenti che necessitano di password. Quando un agente AI 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. Mai archiviare o anche “vedere” segreti a lunga durata

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 progettate appositamente come la Provisioning Zero Trust di Akeyless puntano tutti verso questo futuro senza segreti. I dettagli di implementazione variano, ma il principio rimane: se l’AI 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’AI. Le chiavi API a lunga durata che siedono nelle variabili di ambiente saranno viste come ora vediamo le password in testo normale: un relitto imbarazzante di un tempo più ingenuo.

Invece, ogni agente AI opererà sotto una rigorosa separazione dei privilegi. Accesso in sola lettura per default. Whitelisting delle azioni come standard. Ambienti di esecuzione sandbox come requisito di conformità. Smetteremo di cercare di controllare cosa pensa l’AI e ci concentreremo interamente su cosa può fare.

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

La scelta che affrontiamo

L’integrazione dell’AI nello sviluppo del software è inevitabile e in larga misura 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 desideri rimanere competitiva può ignorarli.

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

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

La domanda per ogni CISO, ogni leader di ingegneria 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 lunga durata o troverà un agente AI che, nonostante essere compromesso, non ha segreti da rubare?

La scelta che facciamo ora determinerà se l’AI diventerà il più grande acceleratore dello sviluppo del software o la più grande vulnerabilità che abbiamo mai creato. La tecnologia per costruire sistemi AI 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 LLM.NIST sta sviluppando linee guida su architetture zero-trust. Le cornici esistono. La sola domanda è la velocità di implementazione rispetto all’evoluzione degli attacchi.

Bio: Refael Angel è il co-fondatore e CTO di Akeyless, dove ha sviluppato la tecnologia di crittografia Zero-Trust brevettata della società. Un ingegnere software esperto con una profonda esperienza in crittografia e sicurezza cloud, Refael ha lavorato in precedenza come ingegnere software senior nel centro R&D di Intuit in Israele, dove ha costruito sistemi per la gestione delle chiavi di crittografia in ambienti cloud pubblici e ha progettato servizi di autenticazione delle macchine. Ha conseguito una laurea in Scienze informatiche presso il Jerusalem College of Technology, che ha ottenuto all’età di 19 anni.