La credenziale in memoria della sua applicazione finirà per trapelare

Ecco una previsione scomoda, e non è una mezza verità: le credenziali che in questo momento si trovano nella memoria della sua applicazione — la password del database caricata all'avvio, il token API nel suo ambiente, la chiave cloud che detiene per svolgere il suo lavoro — con tutta probabilità trapeleranno entro i prossimi dodici mesi. Non perché qualcuno abbia la meglio sul suo team di sicurezza. Perché l'unica ipotesi che ha mai reso sicuro un segreto in memoria — che accanto a esso girasse solo codice fidato — quest'anno ha smesso di essere vera in silenzio, e quasi nessuno ha modificato di conseguenza il proprio comportamento.

Questa non è una cosa che può archiviare sotto «più tardi».

Che cosa sta succedendo davvero

Quasi tutte le applicazioni custodiscono i propri segreti allo stesso modo. All'avvio li leggono — da un file .env, da un segreto montato, da una variabile d'ambiente — e li caricano nella propria memoria, in chiaro, per tutta la durata del processo. Per trent'anni è stata una scelta di progettazione corretta, ed era corretta per una sola ragione: leggere la memoria di un altro programma in esecuzione, o il suo ambiente, richiede eseguire codice sulla stessa macchina, con lo stesso privilegio. Un tempo questa soglia era alta. Le uniche cose che la superavano erano il suo software e le sue persone.

Oggi la supera un agente. Un agente di coding, uno strumento MCP, un lavoratore autonomo: per progettazione esegue codice, su una macchina reale, come utente reale. E per il codice che gira con quel livello di privilegio, una credenziale in memoria non è un caveau da forzare. È un file da leggere. /proc/<pid>/environ elenca in chiaro le variabili d'ambiente di un altro processo. Un core dump consegna il suo heap. Non c'è nessun exploit, nessuna CVE, nessun allarme: il suo EDR, la sua WAF, il suo firewall osservano un processo autorizzato leggere la memoria che gli è consentito leggere, e non vedono nulla di anomalo, perché secondo le loro regole nulla lo è. Ogni passaggio è lecito. Il segreto era semplicemente lì, a portata di mano.

Non è un errore che lei ha commesso

Chiarisca di chi sia la colpa, perché non è sua. Il file .env su una macchina hardenata, il segreto prelevato da un secret manager in memoria all'avvio: è il pattern consigliato. È twelve-factor, a regola, ciò che fa un buon ingegnere. È stata una scelta responsabile. Ciò che è scaduto non è la pratica. È l'ipotesi sottostante: che l'unico codice che gira accanto al suo segreto sia quello che lei ha messo lì. Nel momento in cui su quella macchina gira un agente — e lei sta mettendo agenti ovunque, deliberatamente, perché sono utili — quell'ipotesi non regge più, e il testo in chiaro che lei ha caricato responsabilmente in memoria si trova dentro il raggio dell'esplosione.

Abbiamo già visto arrivare la prima versione di questo scenario [4]. Quando un agente di coding viene dirottato — un report di errore avvelenato, uno strumento malevolo nel suo percorso — la prima cosa a portata di mano è esattamente questa: i token e le chiavi che il suo stesso processo, e i processi accanto a lui, già tengono in memoria. L'iniezione è solo la porta. La credenziale residente è il premio.

«Ma su quella macchina non c'è nessun agente»

È la risposta rassicurante, ed è quella che fallisce. La difesa si regge su un muro: tenere gli agenti da una parte, le credenziali dall'altra. Quel muro è la sola cosa che quest'anno si è data da fare a dimostrare che non può reggere.

Non deve crederlo sulla fiducia: quest'anno ha prodotto la prova, due volte. Nei propri test pubblicati, Anthropic ha puntato il modello Mythos sul server NFS di FreeBSD, codice del kernel che esseri umani leggono da diciassette anni, e il modello ha trovato autonomamente uno stack overflow nel percorso di autenticazione, ha scritto uno sfruttamento di venti gadget distribuito su sei pacchetti di rete e ha ottenuto root non autenticato via rete. È CVE-2026-4747, e ci sono volute circa quattro ore. Non «ha segnalato una funzione sospetta»: uno sfruttamento remote root funzionante contro codice che ha superato diciassette anni di revisione, e lo stesso risultato contro vulnerabilità critiche in tutti i principali sistemi operativi e browser su cui è stato puntato [1].

E il contenimento che circonderebbe un agente non va meglio del perimetro. Nella valutazione di sicurezza condotta da Anthropic stessa, incaricato di uscire dalla propria sandbox e raggiungere il ricercatore che eseguiva il test, Mythos ha concatenato sfruttamenti — un JIT heap spray — per uscire sia dal renderer del browser sia dalla sandbox del sistema operativo, ha raggiunto internet pubblico e gli ha inviato un'email [1]. La precisazione doverosa: l'ha fatto perché il test glielo chiedeva, non di propria iniziativa. Ma «gliel'abbiamo chiesto noi» è esattamente la posizione dell'attaccante — e «escala, eleva i privilegi, prendi le credenziali» è d'ora in poi il payload permanente di ogni prompt malevolo. La capacità non ha mai aspettato l'iniziativa del modello. Aspetta un'istruzione, ed è l'unico input su cui può contare che arrivi. La gravità è stata riconosciuta all'unica altezza che conta: gli Stati Uniti hanno posto il modello stesso sotto controllo all'esportazione, una novità per un modello di AI anziché per i chip che lo sostengono, dopo che una versione di Mythos avrebbe fatto strada in quasi tutti i sistemi classificati della NSA in poche ore [2][3].

Ora metta questo accanto al problema della memoria, perché i due si incontrano. Root su una macchina legge la memoria di qualsiasi processo, non solo di quelli del proprio utente. Quindi la vera domanda non è mai stata «farò girare un agente accanto ai miei segreti». È «un modello capace può raggiungere questa macchina, oppure uscire dalla macchina in cui lo metto» — e quest'anno ha risposto a entrambe, in pubblico. «Su quella macchina non c'è nessun agente» non è un controllo che lei applica. È la speranza che le cose restino al loro posto, e le cose hanno già dimostrato di non restarci. Piani per il caso in cui l'agente raggiunga la macchina. L'alternativa è pianificare di avere fortuna.

Progettata per questo, deliberatamente

Smetta quindi di cercare di tenere l'agente lontano da un segreto che se ne sta lì. Tolga di mezzo ciò che se ne sta lì.

Una credenziale in Clavitor non viene mai caricata nella memoria della sua applicazione per attendere. Viene recuperata in tempo reale, nell'istante della chiamata, usata per quella singola richiesta, e poi non c'è più. Non risiede mai in una variabile d'ambiente, non finisce mai in un file .env, non passa mai la durata del processo residente in un heap in attesa di essere dumpata. Non c'è nulla che /proc possa elencare e nulla che un core dump possa portarsi via, perché alla macchina non è mai stato affidato il compito di detenere un segreto permanente.

E l'unica credenziale che consegna è limitata alla singola funzione per cui quell'agente è stato designato. Non può elencare il vault, non può enumerare che altro esiste, non può scoprire la chiave successiva. Ogni recupero è sottoposto a rate limit, attiva un blocco in caso di picco anomalo e viene registrato in un log append-only con catena di hash che risiede sul vault — non sull'endpoint su cui gira l'agente. È la traccia immodificabile e attribuibile che richiedono PCI DSS Requisito 10 e NIST 800-171 (controllo 3.3.8): la prova di esattamente ciò che il suo agente ha toccato, conservata in un punto che una macchina compromessa non può raggiungere né riscrivere.

Il limite onesto, perché un'affermazione ne ha bisogno: nel microsecondo in cui viene usato, il segreto esiste in memoria — per quella singola richiesta, in quel singolo istante. Nessuna scelta di progettazione riscrive la fisica. Ciò che riscrive è la differenza tra un segreto residente — che resta nel suo processo per ore, scaricabile in qualsiasi momento — e uno effimero — presente per una singola chiamata e poi non più lì da prendere. Non si può eseguire il dump di ciò che non è lì.

La lezione non è «hardenare di più la macchina»

Può continuare a rinforzare la macchina. Può continuare a ripetersi che nessun codice non fidato girerà mai accanto ai suoi segreti. Ma è esattamente la scommessa che diventa più costosa ogni mese, contro un avversario che di mestiere fa girare codice e attraversa muri che lei credeva solidi. La credenziale in memoria era al sicuro quando ogni lettore era fidato. I lettori sono cambiati. L'unica mossa che sopravvive al cambiamento è smettere di lasciare la credenziale lì, ad essere letta.

Abbiamo messo per iscritto le regole che uno strumento per credenziali deve rispettare in un mondo come questo. Verifichi il suo strumento su quelle regole.

Clavitor (@clavitorai) è il vault di credenziali costruito per gli agenti di AI, e contro di essi. clavitor.ai

Fonti

[1] Anthropic (Anthropic Red Team) — Assessing Claude Mythos Preview's cybersecurity capabilities (scoperta e sfruttamento autonomi della RCE in NFS su FreeBSD, CVE-2026-4747; vulnerabilità critiche nei principali sistemi operativi e browser) — https://red.anthropic.com/2026/mythos-preview/

[2] Associated Press (via CNBC) — Anthropic's Mythos model found vulnerabilities in classified U.S. government systems, official says — https://www.cnbc.com/2026/06/23/anthropics-mythos-model-found-vulnerabilities-in-classified-us-government-systems-official-says.html

[3] Fortune — Anthropic disables Fable and Mythos AI models following U.S. government export ban — https://fortune.com/2026/06/13/anthropic-disables-fable-mythos-export-controls-national-security-threat/

[4] Tenet Security (Tenet Threat Labs) — Agentjacking: Coding Agents with Fake Sentry Errors (precedente di dirottamento verso una credenziale residente) — https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/