La memoria degli agenti AI è diventata una superficie di attacco non governata

Il 28 settembre 2026 la sicurezza delle memorie agent è passata da preoccupazione teorica a imperativo operativo. Chris Latimer, CEO di Vectorize, ha documentato in un'intervista a Help Net Security che gli agenti di coding memorizzano API key, credenziali e documenti sensibili in plain text su workstation e servizi cloud. Lo ha fatto nel contesto di un allarme più ampio: la memoria agent, progettata per persistere il contesto tra sessioni, sta ereditando dati protetti dal secure SDLC senza ereditarne i controlli. Il risultato è una migrazione di dati sensibili da repository governati a spazi non governati, con velocità che le pratiche di governance non stanno accompagnando.

Dal secure SDLC alla memoria fluttuante

Latimer descrive un trasferimento di rischio architetturale, non un bug isolato. Le aziende hanno investito anni nel proteggere codice e credenziali attraverso pipeline controllate, segreti gestiti e revisione multipla. Gli agenti autonomi, in particolare i coding agent come Claude Code e strumenti simili, stanno bypassando questa architettura per design: memorizzano il contesto per renderlo disponibile alle sessioni successive, e quel contesto include dati che prima erano confinati in vault e repository auditabili.

La citazione diretta del CEO è esplicita: "Developers are sending API keys, credentials, and sensitive documents into these agents, and those agents push a lot of that information into long-term memory. All these pieces of highly sensitive data that enterprises have gone to great lengths to protect as part of a secure SDLC are now floating around in plain text on developers' workstations, in cloud memory services, and in markdown files". La frase "floating around in plain text" individua lo stato del dato: non cifrato, non soggetto a rotazione, non tracciato per accesso.

Questo non è un errore di configurazione da parte di singoli sviluppatori. È una conseguenza prevedibile dell'architettura agent, dove la persistenza della memoria è funzionale all'autonomia e l'autonomia è il valore di mercato promesso. Il problema è che la superficie di attacco si è spostata senza che i controlli di sicurezza la seguissero.

Memory poisoning: l'iniezione che persiste

Se la memoria agent contiene dati sensibili, è anche scrivibile. Gli attaccanti non devono compromettere il modello: devono compromettere ciò che il modello recupera autonomamente. Penligent, in un advisory tecnico primario, ha mappato tecniche documentate di memory poisoning con riferimenti a ricerche accademiche e dimostrazioni operative.

AWS identifica esplicitamente "Memory Poisoning" e "Tool Misuse" come minacce distinte per sistemi agentici. Unit 42 ha dimostrato injection di prompt indiretta che avvelena silenziosamente la memoria long-term in Amazon Bedrock Agents. MINJA, documentato su arXiv, mostra che l'attaccante non necessita di accesso diretto alla memoria: interagendo con l'agente lo guida a scrivere record malevoli. AgentPoison, anch'esso su arXiv, propone backdoor attraverso l'avvelenamento di RAG e memoria long-term per comportamenti controllati.

La fonte cita AWS con una formulazione precisa: "Memory poisoning is worse because it turns a one-time interaction into a durable control mechanism". La differenza rispetto al prompt injection classico è nella durata: una singola iniezione condiziona comportamenti futuri dell'agente, anche dopo che l'attaccante ha smesso di interagire. La tracciabilità ne risulta degradata: i log mostrano l'agente che agisce autonomamente, non l'istante della contaminazione.

Il vettore privilegiato sono i plugin, le skills e le integrazioni MCP che gli utenti installano con scarsa due diligence. Latimer descrive un attacco concreto: plugin che promette "token illimitati gratis", scansiona la memoria per credenziali e le esfiltra a un endpoint. Il target privilegiato, secondo la stessa fonte, sono "people who have never coded before", utenti che non hanno la sofisticazione per valutare la legittimità dell'offerta.

L'ecosistema MCP ha vulnerabilità certificate

L'attacco non è teorico. CVE-2025-68144, secondo il record NVD ufficiale, riguarda mcp-server-git e la presenza di argument injection nelle funzioni git_diff e git_checkout. La vulnerabilità colpisce versioni precedenti alla 2025.12.17. Il punteggio CVSS è 7.1 HIGH con metriche CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L. L'impatto sull'integrità del sottosistema è segnalato come HIGH (SI:H nella specifica CVSS 4.0).

La fonte primaria tecnica, Penligent, colloca questa vulnerabilità in un quadro più ampio: oltre 40 vulnerabilità archiviate contro implementazioni MCP nel 2026, secondo un documento NSA di maggio 2026 di 17 pagine. L'adozione di MCP ha superato le salvaguardie disponibili. Questo non è un giudizio retroattivo: la NSA lo documenta come condizione rilevata, non come previsione.

La patch indicata è la versione 2025.12.17 con validazione rev_parse aggiunta. La data di rilascio effettiva di questa versione non è verificabile nel testo fornito: non è possibile affermare che sia disponibile al momento della pubblicazione.

Autonomia senza supervisione: i numeri del rischio operativo

Il problema di governance è aggravato dalla velocità di adozione e dalla struttura dei team che adottano. Secondo dati pubblicati su Help Net Security e attribuiti alla ricerca di Raida e Hou (RIT, maggio-luglio 2025), il 78,9% delle pull request agentiche ha un solo revisore. Nei repository con 1-5 contributor, che sono anche i più intensi utilizzatori, la media è di 50,2 agentic pull request. Il merge rate tra PR con singolo revisore e multi-reviewer differisce di meno di un punto percentuale (81,2% contro 80,3%), indicando che la revisione aggiuntiva non altera significativamente l'esito.

Anthropic ha testato l'auto mode di Claude Code su 1.053 comandi. La revisione umana ha bloccato il 13,6% dei comandi pericolosi. L'auto mode ne ha bloccati l'89%. Questo dato, spesso letto come vittoria della sicurezza automatizzata, ha un rovescio: gli sviluppatori approvano il 97% dei prompt di permesso, spesso senza revisione attenta. La sicurezza è delegata a un classificatore con attack miss rate del 7% (migliorato dal 12% iniziale), non a un processo di governance.

Il dato di Trajectory Labs è contestuale: 0% di successo su 720 prompt injection attacks contro Claude in auto mode. Ma contro GPT-5.6 Sol in Codex Auto-review mode il successo è del 5,83%, e contro Codex in full-access mode sale al 19,03%. L'eterogeneità del panorama significa che la sicurezza dell'auto mode non è trasferibile tra piattaforme, e la memoria agent persistente amplifica le conseguenze di una singola compromissione.

"Most likely what you'll find is a big security hole you weren't aware of and that you want to get patched ASAP." — Chris Latimer, CEO Vectorize, sull'audit della memoria agent

Cosa fare adesso

Latimer ha formulato una raccomandazione operativa diretta: i CISO dovrebbero auditarne immediatamente la memoria agent. L'audit, secondo la stessa fonte, è probabilmente destinato a rivelare "a big security hole you weren't aware of". La formulazione è quella di una scoperta attesa, non di una possibilità remota.

Dal dossier emerge un quadro di azioni prioritarie che le fonti convergenti indicano come necessarie:

• Audit della memoria agent per identificare credenziali e dati sensibili in plain text, con particolare attenzione a workstation di sviluppatori e servizi cloud memory.
• Verifica dei plugin, skills e integrazioni MCP installate, con particolare attenzione a quelle promesse tramite social engineering o offerte "troppo belle per essere vere".
• Rivalutazione dei controlli di accesso sulla memoria agent: la maggior parte dei prodotti non supporta access control a gradi per team, e questa mancanza va documentata come rischio accettato o mitigato.
• Rivedere il processo di approvazione delle pull request agentiche, considerando che l'81,2% di merge con singolo revisore indica una governance di fatto delegata all'agente stesso.

La shadow IT del 2025, accelerata

L'angolo editoriale è architetturale, non incidentale. Il secure SDLC è stato bypassato da un cambio di paradigma, non da un bug. I dati sensibili sono migrati da repository con RBAC/ABAC, audit trail e rotazione chiavi a memorie agent che nessuno ha progettato con gli stessi controlli. La velocità di questa migrazione supera quella della shadow IT del 2010 perché i developer installano plugin senza processo di approvazione, e le memorie avvelenate persistono oltre la sessione che le ha generate.

La persistenza è il fattore qualificante. Un attaccante che avvelena la memoria non deve mantenere l'accesso: l'agente continuerà a comportarsi male anche in assenza dell'attaccante. La UK NCSC, citata da Penligent, afferma che "Current LLMs do not reliably enforce a boundary between instructions and data, which is why prompt injection can't be 'patched' the way classic injection classes were". Se il prompt injection non è patchabile nel modello, e la memoria agent rende ogni iniezione duratura, la superficie di attacco diventa strutturale.

Vipin Samar, SVP Database Security di Oracle, è citato nel contesto delle memorie in produzione: "Agents are increasingly acting as autonomous insiders". La formula non è metafora: descrive un'entità con privilegi, persistenza e autonomia decisionale, che opera senza i controlli tradizionali su identità e accesso. Il dossier non specifica che Oracle abbia rilasciato controlli specifici per questa superficie: la citazione è lettura di mercato, non annuncio di prodotto.

Il rischio è immediato perché i massimi utilizzatori sono i più piccoli team, quelli con governance minima e revisione singola. L'89% di efficacia dell'auto mode Anthropic misura un'autonomia che le pratiche di sicurezza non stanno ancora governando. La memoria agent è la superficie dove questa asimmetria si concretizza.

Fonti

• https://www.helpnetsecurity.com/2026/09/28/chris-latimer-vectorize-agent-memory-security/
• https://www.hendryadrian.com/if-you-do-one-security-check-this-quarter-make-it-agent-memory/
• https://www.penligent.ai/hackinglabs/agentic-ai-security-in-production-mcp-security-memory-poisoning-tool-misuse-and-the-new-execution-boundary/
• https://blogs.oracle.com/developers/what-we-learned-about-letting-agents-into-a-production-database
• https://nvd.nist.gov/vuln/detail/CVE-2025-68144?utm_source=chatgpt.com
• https://nvd.nist.gov/vuln/detail/cve-2024-3094?utm_source=chatgpt.com
• https://www.helpnetsecurity.com/2026/07/22/users-of-ai-coding-agents/
• https://www.helpnetsecurity.com/2026/08/10/anthropic-claude-code-auto-mode/

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti