Sicurezza AGENTS.md: come file estranei controllano gli agenti AI

In un caso è bastato un anonimo file di testo nella cartella Download perché un agente di coding AI tentasse di installare un pacchetto dannoso. Questo articolo sulla sicurezza AGENTS.md descrive cosa è successo, quali file di istruzioni caricano Codex, Claude Code e Cursor e quali impostazioni e misure possono evitare il danno.

Un ritrovamento sul computer di un cliente e le sue conseguenze

Il fornitore di sicurezza Forever Security ha scoperto quanto segue: sul computer di un cliente, nella cartella Download, si trovava un file di istruzioni chiamato AGENTS.md che doveva indurre un agente di coding AI a installare un pacchetto npm. Il file non è un programma, ma agisce come un'istruzione operativa.

Cosa è successo: ritrovamento nella cartella Download, nuovo test e tassi di successo

Il punto di partenza è stato un ritrovamento reale. Il file si trovava nella cartella Download di uno sviluppatore. Quella cartella era anche la directory di lavoro dell'agente. L'agente voleva installare il pacchetto npm function-color. Secondo quanto riferito da Forever Security, l'azienda lo ha fermato prima che venisse eseguito del codice. I ricercatori non sono riusciti a chiarire come il file sia finito nella cartella.

Il pacchetto function-color si porta dietro un ulteriore pacchetto chiamato function-flag. Questo scarica un malware per Windows e lo avvia. CloudSEK e Checkmarx chiamano la campagna MALFEX.

Nuovo test con Codex

Forever Security ha riprodotto l'attacco in una macchina virtuale isolata. Il file reale istruiva Codex a registrare un server nel file ~/.codex/config.toml e a eseguire un comando che installa il pacchetto. Poiché questa configurazione vale per tutte le sessioni di Codex sul computer, la modifica ha effetto permanente e in ogni cartella. Il tasso di successo è stato di circa il 90 per cento.

Nuovo test con Claude Code

Con Claude Code è stato usato un file diverso. Un CLAUDE.md manipolato si spacciava per la configurazione di un gateway interno e doveva indurre l'agente a scrivere un indirizzo estraneo come destinazione API in un file di impostazioni del progetto. Il traffico API sarebbe così passato da un server dei ricercatori. Questo espone il token di autenticazione della sessione, e il server può restituire comandi che l'agente esegue. Per scritture di questo tipo Claude Code chiede di solito una conferma e spesso rifiuta quelle sospette. Solo una motivazione lunga, che sembrava quasi documentazione per sviluppatori, ha portato all'approvazione in circa la metà dei casi.

I due valori non sono direttamente confrontabili. Si tratta di agenti diversi, file diversi e obiettivi diversi. Dimensione del campione e configurazione del test (sandbox, modalità di approvazione) non sono chiare.

Telemetria: quanto è diffuso l'avvio nella cartella Download?

Circa la metà dei clienti di Forever Security avvia un agente di coding nella cartella Download, e circa un quarto delle sessioni apre un browser. BleepingComputer cita più di 1.300 sessioni di Claude Code da questa cartella. Entrambi sono dati del fornitore sulla propria clientela; non esiste una verifica indipendente. Non è dimostrato che nella pratica gli aggressori depositino davvero file di questo tipo tramite download dal browser. La proof of concept ha scaricato soltanto un file innocuo.

Sicurezza AGENTS.md: perché i file di istruzioni estranei sono un rischio

All'avvio gli agenti di coding leggono i file di istruzioni dalla directory di lavoro. Contengono istruzioni di build, regole di stile o comandi di test. L'agente tratta questo contenuto come indicazioni dell'utente. Non distingue in modo affidabile se il file provenga dal team o da una fonte estranea. È il nucleo di una prompt injection indiretta contro un agente di coding: l'istruzione non arriva dal campo di input, ma dal contesto.

Due proprietà di per sé innocue formano insieme la catena. Primo, gli agenti si fidano dei file nella cartella aperta. Secondo, i siti web possono salvare file nella cartella Download senza chiedere, se il browser è impostato così. Chrome, Edge e Firefox salvano per impostazione predefinita in questa cartella senza chiedere dove salvare e mostrano solo una notifica. Nel test Brave ha chiesto prima. Il file porta il nome e il contenuto stabiliti dal sito.

La documentazione di Claude Code descrive CLAUDE.md come contesto e non come configurazione imposta. Per i blocchi raccomanda gli hook. Da qui deriva la regola di base per tutto il resto: ciò che è scritto solo nel testo di un file, un agente può seguirlo o ignorarlo. Ciò che sta nei permessi, il programma lo impone.

Il browser non è l'unica via

In questo caso la cartella Download è al centro, ma non è sola. Il NVIDIA Developer Blog descrive una via affine: un pacchetto di dipendenza compromesso crea da sé un file AGENTS.md. Anche repository clonati, archivi estratti e script di build possono portare file di istruzioni estranei in una cartella di progetto. Il punto di avvio riduce quindi la superficie di attacco, ma non la elimina.

Valutazione: cosa dicono ricercatori e produttori

I ricercatori di Forever Security dichiarano che per OpenAI e Anthropic non c'è nulla da correggere con una patch. L'agente segue il suo file di istruzioni come previsto, in modo paragonabile a un browser che visualizza una pagina di phishing. Questa è la valutazione dei ricercatori. I due resoconti non contengono una presa di posizione dei produttori su questo attacco. BleepingComputer si limita a segnalare che entrambi i produttori raccomandano di avviare gli agenti nella rispettiva directory del progetto. La responsabilità ricade quindi sugli utenti e sulle organizzazioni che impiegano gli agenti.

I rischi degli agenti autonomi sono un tema più ampio. Gli articoli sul potere senza controllo negli agenti AI e sull'era degli agenti AI spiegano perché gli agenti con propri diritti di azione richiedono misure di protezione diverse dal software tradizionale.

Quali file di istruzioni caricano Codex, Claude Code e Cursor

Conta ciò che vale come cartella del progetto: la cartella in cui viene avviato l'agente. Chi avvia l'agente nella cartella Download trasforma ogni file presente lì in contesto del progetto. La panoramica seguente riassume la documentazione dei produttori (aggiornata al 26/10/2026). La documentazione cambia rapidamente; in caso di dubbio vale la versione attuale.

Codex

Secondo la documentazione, Codex legge prima un file globale nella directory di Codex (~/.codex, modificabile tramite CODEX_HOME), cioè AGENTS.override.md o AGENTS.md. Seguono i file dalla radice del progetto, di solito la directory principale di Git, fino alla cartella corrente. Per ogni cartella viene considerato al massimo un file: AGENTS.override.md, AGENTS.md o un nome alternativo configurato. Il limite complessivo è di 32 KiB. Se non viene trovata una radice del progetto, conta solo la cartella corrente. È esattamente il caso della cartella Download, perché lì di solito non c'è un repository Git.

Claude Code e sicurezza di CLAUDE.md

Secondo la documentazione sulla memoria, Claude Code carica CLAUDE.md e CLAUDE.local.md dalla directory di lavoro e da tutte le directory superiori, se necessario anche dalle sottocartelle. A questi si aggiungono ~/.claude/CLAUDE.md, la policy gestita del sistema e i file in .claude/rules/. Per la sicurezza di CLAUDE.md significa che anche un punto di avvio troppo in alto, come la directory home, amplia la superficie, perché vengono letti anche i file sopra e accanto.

Claude Code legge AGENTS.md (secondo la documentazione dalla versione 2.1.277). Per impostazione predefinita lo fa solo se nella directory di lavoro o sopra non c'è un CLAUDE.md o CLAUDE.local.md. Si può cambiare tramite l'impostazione per le istruzioni del progetto: claude-md-or-agents-md è il valore predefinito, claude-md-and-agents-md legge entrambi, managed-only ammette solo istruzioni gestite centralmente.

Cursor

Secondo la documentazione, Cursor supporta regole di progetto in .cursor/rules/ (file in formato .mdc, anche in sottocartelle) e AGENTS.md nella radice del progetto e nelle sottodirectory. I file annidati valgono per il loro ambito, quello più specifico prevale. Si aggiungono le User Rules personali nelle impostazioni e le Team Rules tramite la dashboard.

I file di configurazione come vero obiettivo

Il caso mostra che il file di istruzioni è spesso solo lo strumento. L'obiettivo sono i file di configurazione in cui una modifica ha effetto duraturo. Per Codex è ~/.codex/config.toml, la cui modifica riguarda tutte le sessioni. Per Claude Code è il file di impostazioni .claude/settings.json, in cui tramite una variabile d'ambiente si può impostare la destinazione API. Entrambi i file vanno quindi nell'elenco dei file che un agente non può modificare senza chiedere.

Proteggere gli agenti di coding AI: permessi, hook e sandbox di Codex

Viene spontaneo chiedersi se basti evitare la cartella Download.

Le misure intervengono in tre punti: cosa l'agente può fare senza conferma, cosa un hook blocca indipendentemente dal modello e cosa la sandbox limita tecnicamente.

Regole di permesso in Claude Code

Claude Code supporta regole dei livelli allow, ask e deny per ogni strumento (documentazione sui permessi). Per impostazione predefinita l'agente chiede prima dei comandi shell e delle modifiche ai file. Una regola deny vale anche quando l'agente vorrebbe seguire un file di istruzioni. Un esempio per il file .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(.claude/**)",
      "Edit(~/.codex/**)"
    ]
  }
}

La notazione segue gli esempi della documentazione: le regole Bash confrontano il testo del comando con * come carattere jolly, le regole di percorso per lettura e modifica usano la sintassi di gitignore, ~/ sta per la directory home. Le modifiche ai file si regolano con Edit(…); secondo la documentazione le regole per Write non vengono confrontate con i percorsi. Un blocco dei comandi inoltre non è una garanzia, perché lo stesso obiettivo si raggiunge spesso con un'altra chiamata. Per ciò che non si può evitare servono hook e sandbox.

Due funzioni di comodità richiedono cautela. L'approvazione con "non chiedere più" vale, a seconda dello strumento, in modo permanente per un repository, e nelle modalità automatiche non è più una persona a decidere su ogni azione. Nessuna delle due va usata in ambienti con codice estraneo.

Hook: blocchi indipendenti dal modello

Un hook PreToolUse viene eseguito prima della chiamata allo strumento e può bloccarla, anche se il modello la ritiene corretta. La guida agli hook mostra lo schema: lo script legge l'input come JSON dallo standard input e termina con un codice di uscita per bloccare. Viene registrato nel file di impostazioni:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-installs.sh"
          }
        ]
      }
    ]
  }
}

Lo script block-installs.sh legge con jq il comando dal campo tool_input.command, lo confronta con una lista di blocco (per esempio npm install o la combinazione di curl e shell) o meglio con una allowlist e, in caso di corrispondenza, riporta una motivazione sullo standard error con exit 2. Una seconda leva poco nota è l'hook InstructionsLoaded. Registra i file di istruzioni caricati. Secondo la documentazione, però, non si attiva per un AGENTS.md caricato tramite l'impostazione, ma solo quando un CLAUDE.md lo importa. Un team non dovrebbe quindi affidarsi solo a questo hook.

Regole centrali con le Managed Settings

Per i team le impostazioni gestite sono la leva più efficace. Secondo la documentazione sulle Managed Settings, permissions.deny, sandbox.enabled ed env possono essere imposti centralmente. Così una destinazione API introdotta di nascosto tramite un file di istruzioni, come nel test con Claude Code, sarebbe molto più difficile da far passare. Come valutazione: si tratta di una deduzione dalla documentazione, non di un effetto dimostrato nel caso di Forever Security.

Codex: approvazioni, livello di fiducia e modalità sandbox

Secondo la documentazione su approvazioni e sicurezza, sandbox e permessi di Codex funzionano su due livelli. La policy di approvazione stabilisce quando Codex chiede (per esempio on-request o never). La modalità sandbox stabilisce cosa è tecnicamente possibile: read-only, workspace-write o danger-full-access. In modalità workspace-write la rete è disattivata per impostazione predefinita.

A questo si aggiunge un livello di fiducia per progetto in ~/.codex/config.toml (trust_level). Secondo la documentazione, nelle cartelle sotto controllo di versione vale la modalità Auto, cioè scrittura nell'area di lavoro con conferma. Nelle cartelle senza controllo di versione vale read-only finché la directory non viene contrassegnata come attendibile. Una cartella come Download, senza contrassegno, è considerata non attendibile. Il rischio nasce quando gli utenti confermano la finestra di dialogo sulla fiducia. Il flag –yolo rimuove sandbox e approvazioni e non va inserito nelle regole del team. Non è stato riferito con quale configurazione Forever Security abbia eseguito il test, quindi non si sa se i livelli di protezione predefiniti abbiano funzionato.

Cursor

Sulle approvazioni dei comandi nel terminale in Cursor non c'è un'indicazione chiara del produttore. Qui quindi solo il consiglio di lasciare attive le approvazioni per i comandi del terminale e di controllare la documentazione aggiornata del produttore.

Sandbox e isolamento: limitare il danno anche se l'agente segue il file

Una sandbox limita ciò che un agente può fare, anche se segue un'istruzione estranea. La sandbox di Claude Code consente l'accesso in scrittura alla directory di lavoro e alle cartelle temporanee. L'accesso alla rete passa da un proxy con un elenco di domini consentiti, vuoto per impostazione predefinita. I percorsi protetti come le impostazioni di Claude Code, il file di avvio della shell .bashrc e gli hook di Git restano in sola lettura. Un esempio:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "allowUnsandboxedCommands": false
  }
}

La documentazione indica anche dei limiti. La sandbox è disattivata per impostazione predefinita. L'accesso in lettura è ampio, le credenziali vanno bloccate in modo mirato. La protezione vale solo per i comandi shell e i loro processi figli, non per gli strumenti integrati per i file, MCP e gli hook. Senza allowUnsandboxedCommands: false un comando fallito può essere ripetuto fuori dalla sandbox. Su Windows non funziona in modo nativo, si usa WSL2. Contro il codice dannoso non è un confine completo. Per un isolamento forte, container o macchine virtuali sono la scelta migliore.

Allowlist di rete e ambiente usa e getta

Una allowlist di questo tipo avrebbe reso più difficili il download del pacchetto e il reindirizzamento dell'API. È una valutazione, non una prova relativa al caso. Il codice sconosciuto va in un ambiente usa e getta: container, VM o dev container, senza le credenziali del profilo principale. I token dovrebbero avere vita breve. In caso di sospetto si raccomanda di considerare il token di autenticazione come trafugato e di rinnovarlo.

Impostazione del browser per i download

Contro i download silenziosi aiuta l'impostazione che chiede dove salvare prima di ogni download. In Chrome si chiama "Chiedi dove salvare ciascun file prima di scaricarlo" e si trova nelle impostazioni alla voce Download. Edge e Firefox offrono opzioni equivalenti, i nomi variano a seconda della versione (Firefox: Impostazioni, Generale, File e applicazioni). Nel test di BleepingComputer Brave ha chiesto di propria iniziativa. In alternativa si può spostare la cartella dei download in un percorso che non serve mai come directory di lavoro. Un alias della shell o un hook che rifiuta l'avvio in ~/Downloads è un'opzione aggiuntiva.

Checklist per i team e linee guida per l'uso degli agenti di coding

L'elenco seguente riassume le misure. Integra le raccomandazioni dei due resoconti con le configurazioni tratte dalla documentazione dei produttori.

• Gli agenti si avviano solo nella directory radice di un repository attendibile. Download, Desktop e directory home sono off-limits.
• I file estranei come AGENTS.md, CLAUDE.md o .cursor/rules vengono letti prima di aprire un progetto appena clonato o estratto.
• Richieste di permesso e sandbox restano attive. Le modalità automatiche e flag come –yolo funzionano solo in ambienti isolati.
• L'accesso alla rete passa da una allowlist, le credenziali restano fuori portata, i token hanno vita breve.
• Le installazioni di pacchetti da parte degli agenti avvengono solo dopo approvazione, con lockfile e verifica del registry. Il caso di function-color e function-flag mostra con quale rapidità un pacchetto ne trascina altri.
• Le impostazioni sono gestite centralmente. Le modifiche a ~/.codex/config.toml e .claude/settings.json vengono monitorate.
• I file di istruzioni caricati vengono registrati, per quanto gli strumenti lo consentono.
• Piano per gli incidenti: fermare la sessione, rinnovare token e chiavi, controllare i file di configurazione, ricostruire le installazioni di pacchetti.

Le organizzazioni con obblighi di sicurezza delle informazioni includono questi agenti nella loro gestione del rischio. Ciò riguarda l'autorizzazione all'uso, la configurazione e la prova che le regole vengono applicate. Un articolo sull'agentic coding descrive come organizzarne l'uso nei team di sviluppo.

Linee guida di esempio

Delle linee guida essenziali si possono formulare in poche frasi. L'ambito comprende tutti i dipendenti e i fornitori di servizi che usano agenti di coding AI su dispositivi aziendali o con dati aziendali. Gli agenti si avviano solo nella directory radice di un repository verificato, mai nelle cartelle Download, Desktop o home. Le modalità automatiche e la disattivazione di sandbox o approvazioni sono consentite solo in ambienti isolati usa e getta senza credenziali. Le installazioni di pacchetti e le modifiche ai file di configurazione richiedono l'approvazione degli sviluppatori. La sicurezza IT è responsabile delle impostazioni centrali, la direzione di progetto del rispetto delle regole nel progetto. I casi sospetti vengono segnalati subito alla sicurezza IT e i token interessati vengono rinnovati immediatamente.

Verificare i propri siti web e sistemi

Il caso riguarda soprattutto i computer degli sviluppatori. Chi offre file da scaricare fa parte della catena con il proprio sito web. Un controllo del sito web mostra quali script e header una pagina distribuisce, ma controlla solo la pagina, non i computer degli sviluppatori. Per una verifica sistematica della sicurezza nei team, i Web Security Checks offrono un punto di partenza.

Conclusione

La responsabilità è dell'utente, la tecnologia pone il limite!

Un file di testo estraneo può controllare un agente di coding perché l'agente tratta i file nella cartella di lavoro come istruzioni. La protezione diventa affidabile solo con limiti imposti: permessi, hook, sandbox, allowlist di rete e impostazioni gestite centralmente.

Resta aperto se gli aggressori sfruttino nella pratica la via dei download dal browser e come il file sia arrivato al cliente. In ogni caso appare importante sensibilizzare dipendenti e sviluppatori (finché non si estingueranno).