Qualcuno usa gli agenti AI per fare reconnaissance sul mio sito: settimane di log analizzate

Analizzando i log di accesso di un'applicazione che gestisco, mi è capitato di notare una manciata di richieste a path che non hanno alcuna ragione legittima di essere chiesti: /.env, /.ssh/id_rsa, /.aws/credentials, /config/database.php. Fin qui niente di nuovo, sono i bersagli classici di qualunque scanner automatico. La differenza interessante è lo user-agent: alcune di queste richieste non arrivavano dai soliti bot di scansione, ma da agenti come ChatGPT-User e Perplexity-User, cioè dai fetcher che gli assistant AI usano quando un utente incolla un link e chiede di leggerlo. Ho un background offensivo e tratto i log con la lente dell'attaccante, quindi la prima domanda che mi sono posto è stata: è una campagna di reconnaissance orchestrata via AI, oppure è rumore? La risposta onesta, ed è il cuore di questo articolo, è la seconda. Ma il vettore merita di essere capito, perché racconta qualcosa su come gli agenti AI cambiano la superficie di esposizione di un sito.

La cosa interessante non è il volume, che è trascurabile, è il vettore: un assistant AI può essere trasformato in un proxy di reconnaissance. Chi indaga lo fa dal proprio browser; qui qualcuno lo fa dire a un'AI, che bussa al posto suo, dal suo IP, con le sue regole.

Parto da una premessa di metodo, perché è la parte che vale di più e quella che la pubblicistica di settore sistematicamente tradisce: i dati vanno raccontati per quello che sono, non per quello che fanno scena. Sarebbe facile intitolare questo pezzo "sei settimane di reconnaissance AI analizzate" e venderlo come un'analisi forense di una campagna sofisticata. Sarebbe disonesto, e un lettore tecnico che guardasse i numeri reali perderebbe immediatamente fiducia, che è l'esatto opposto di quello che voglio. Quindi: i tentativi sono pochi, isolati, distribuiti nel tempo, e non compongono una campagna. Vediamo come si fa a stabilirlo, e perché il vettore resta comunque istruttivo.

Cosa sono davvero questi user-agent e perché bussano ai miei segreti?

Gli assistant AI non sono un'unica cosa: bussano alla tua porta con almeno tre tipi di agente diversi, e confonderli è il primo errore di chi legge i log senza il contesto. La distinzione è netta e i tre provider principali la organizzano allo stesso modo.

I primi due tipi sono crawler automatici, governabili via robots.txt. Il terzo, gli on-demand fetcher, è quello che conta qui: si attivano solo quando una persona chiede esplicitamente all'assistant di leggere un URL specifico. Non fanno crawling di massa, fanno una singola fetch on demand. E qui c'è il dettaglio che li rende un vettore di reconnaissance, per quanto debole: poiché la richiesta è iniziata da un utente e non da un crawler, le regole di robots.txt possono non applicarsi nello stesso modo, come documenta la stessa OpenAI per il suo agente (vedi la pagina ufficiale sui bot OpenAI). Tradotto per chi pensa offensivo: posso chiedere a un assistant di andare a vedere https://tuosito.it/.env, e l'agente ci va, dalla sua infrastruttura, anche se un crawler educato non lo farebbe.

La spiegazione più probabile di ciò che vedo nei log, quindi, non è un attaccante sofisticato che ha costruito un orchestratore: è qualcuno, curioso o pigro, che ha chiesto a un assistant di provare quei path, oppure uno strumento che falsifica lo user-agent per sembrare innocuo. In entrambi i casi il volume resta quello che è: pochi colpi, non una raffica.

Se gestisci applicazioni esposte e vuoi capire come imposto il threat modeling e l'hardening tenendo conto anche di questi vettori emergenti, nel mio hub dedicato all'AI per la sicurezza aziendale raccolgo gli articoli con la metodologia offensiva che applico in difesa.

Come si distingue una campagna dal rumore di fondo

Questa è la competenza che fa la differenza tra un'analisi e un allarme, ed è puro information gain di prima mano. Una campagna di scanning reale ha una firma statistica inconfondibile: genera centinaia o migliaia di richieste a path inesistenti, quindi una valanga di risposte 404, concentrate nel tempo, spesso da una manciata di IP, con pattern di enumerazione riconoscibili (prova /.env, poi /.env.bak, poi /.env.old, poi /config/.env, in sequenza ravvicinata). Il rapporto tra risposte di errore (4xx) e risposte valide (2xx) si impenna.

Nel mio caso, il quadro era l'opposto: una manciata di richieste a path sensibili, isolate, sparse su settimane, con un numero di 4xx totali risibile rispetto al traffico legittimo. Nessuna enumerazione, nessuna concentrazione temporale, nessun IP che martella. La metrica che uso per decidere è semplice e la consiglio a chiunque legga i propri log:

# Conta i 4xx per path e ordina: una campagna emerge come un picco netto,
# il rumore resta una coda piatta di colpi isolati.
awk '$9 ~ /^4/ {print $7}' access.log | sort | uniq -c | sort -rn | head -30

# Isola le richieste degli on-demand fetcher AI verso path sospetti
grep -E 'ChatGPT-User|Claude-User|Perplexity-User' access.log \
  | grep -E '\.env|\.ssh|\.aws|\.git|credentials' | wc -l

Se il secondo comando ti restituisce numeri a una o due cifre su un arco di settimane, non hai una campagna, hai del rumore curioso. Dirlo chiaramente non è debolezza analitica, è la condizione perché la tua analisi sia credibile quando invece troverai qualcosa di serio. Chi grida al lupo sui dodici colpi isolati non viene creduto quando il lupo arriva davvero.

Va detto che l'estremo alto dello spettro esiste, ed è documentato: Anthropic ha riportato il primo caso di spionaggio cyber orchestrato in larga parte da un'AI agentica, usata come orchestratore autonomo contro decine di organizzazioni (la disclosure pubblica è qui). Ma quello è un attore statale con risorse dedicate, non il curioso che fa dire a ChatGPT di guardare il tuo .env. Tenere separati i due livelli è esattamente la disciplina di cui parlo: l'esistenza di una minaccia sofisticata da qualche parte nel mondo non autorizza a riqualificare il proprio rumore di fondo come un attacco mirato.

Cosa guadagna davvero un attaccante usando un'AI come proxy?

Vale la pena fare l'analisi a mente fredda, perché capire cosa un vettore offre e cosa nega è il modo serio di valutarne il rischio, invece di reagire alla parola "AI". Usare un on-demand fetcher come proxy di reconnaissance dà a chi indaga tre piccoli vantaggi reali. Il primo è un IP diverso dal proprio, l'infrastruttura del provider, che lo separa dal bersaglio e ostacola l'attribuzione immediata. Il secondo è il già citato disallineamento con robots.txt: l'agente, agendo per conto di un utente, può raggiungere risorse che un crawler educato eviterebbe. Il terzo è la negabilità: nei log compare uno user-agent dall'aria innocua, non un tool di scanning riconoscibile.

Ma i limiti sono molto più pesanti dei vantaggi, ed è per questo che non vedo (ancora) abuso serio attraverso questo canale. Gli on-demand fetcher non eseguono JavaScript: vedono solo l'HTML iniziale, quindi tutto ciò che è renderizzato lato client è invisibile, e gran parte delle applicazioni moderne lo è. Il throughput è bassissimo, una fetch alla volta su richiesta esplicita, l'opposto di ciò che serve a un'enumerazione. La richiesta è comunque loggata e attribuibile a quel canale, e i provider applicano rate limit e policy d'uso. In più, l'attaccante deve passare attraverso un sistema che ha le sue safeguard: chiedere a un assistant di esfiltrare credenziali è esattamente il tipo di richiesta che i classifier di sicurezza intercettano.

Come strumento offensivo, l'assistant-come-proxy è goffo: lento, cieco al JavaScript, tracciabile e mediato da un guardiano. È un grimaldello, non una chiave. Per questo il segnale che vedo è rumore, e per questo lo dico senza drammatizzare.

La conclusione operativa è che la difesa non va costruita contro lo strumento del momento, ma contro la classe di richiesta. Che il tuo .env lo chieda un assistant, uno scanner o un curioso, la risposta corretta del tuo server è sempre la stessa, e non dipende da chi bussa.

La contromisura vera: l'AI non è il problema, i segreti serviti lo sono

Qui arriva la parte che ribalta la prospettiva, ed è il motivo per cui penso offensivo per difendere meglio. Il problema non è che un agente AI chieda il tuo .env. Il problema è se glielo servi. Un /.env accessibile via web è una vulnerabilità grave a prescindere da chi lo chiede: che sia ChatGPT-User, uno scanner cinese o un browser umano, il danno è identico. Il vettore AI è una curiosità; la falla, se esiste, è la tua hygiene. Le contromisure sono note da sempre e non c'entrano nulla con l'AI:

• I segreti non stanno nel webroot. Il file .env, le chiavi SSH, le credenziali cloud non devono essere fisicamente raggiungibili da una richiesta HTTP. Se lo sono, hai un problema di architettura, non di bot.
• Non fidarti mai dello user-agent per la sicurezza. È una stringa che il client sceglie liberamente: bloccare ChatGPT-User non ti protegge da chi lo falsifica, e blocca solo gli usi legittimi. L'user-agent serve per le decisioni di crawling e di analisi, mai come controllo di accesso.
• Monitora il rapporto 4xx/2xx come segnale, non i singoli colpi. È l'inversione di quel rapporto, non la singola richiesta a .env, a dirti che qualcosa è cambiato.

A queste si aggiunge una difesa in profondità a livello di server, utile anche quando i segreti sono già fuori dal webroot: negare ogni accesso ai file e alle directory che iniziano con un punto. Su Nginx è una manciata di righe:

# Nega ogni accesso ai file e alle directory che iniziano con un punto
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

Questa regola copre anche un bersaglio che nei log vedo più spesso del .env, e più pericoloso: la directory /.git. Quando un deploy avviene con un git pull direttamente nel webroot, l'intera cronologia del repository resta servita via HTTP, e da lì si ricostruiscono codice sorgente, credenziali committate per errore e logica applicativa interna. È una falla classica, banale da sfruttare con strumenti pubblici, e che nessuno mira con un'AI perché gli scanner automatici la trovano da soli in massa. Il punto, di nuovo, è che il vettore conta poco: conta che la directory non sia raggiungibile. La regola corretta a monte è non fare deploy con git nel webroot e tenere il repository fuori dalla radice servita.

C'è poi il livello che chiude il cerchio, ed è di processo più che di configurazione: i segreti vanno iniettati a runtime, non depositati nell'albero del progetto. Variabili d'ambiente fornite dal sistema di orchestrazione o da un secret manager, mai un file di credenziali che vive accanto al codice e che basta un errore di configurazione del web server a esporre. Quando il segreto non esiste come file raggiungibile, la domanda "chi ha provato a leggerlo" diventa una curiosità statistica, non un incidente: ed è esattamente la postura in cui voglio trovarmi quando leggo i log, quella in cui i tentativi che vedo sono interessanti da studiare proprio perché non possono fare danno.

Su come si mette in sicurezza un'applicazione partendo dalla mentalità dell'attaccante ho scritto in dettaglio analizzando la difesa dai prompt injection nei sistemi agentici e il threat modeling dei sistemi ad agenti autonomi; e sul recupero di un sito già compromesso, con l'hardening che ne segue, ho raccolto la procedura in sito PHP hackerato, guida al ripristino e all'hardening.

La lezione che porto a casa da queste settimane di log non è "gli agenti AI ti attaccano", che sarebbe un titolo a effetto e una mezza bugia. È più sobria e più utile: gli assistant AI hanno aggiunto un nuovo tipo di client alla tua porta, uno che un utente può puntare dove vuole, ignorando in parte le convenzioni dei crawler; il volume di abuso reale, oggi, è trascurabile, ma il vettore esiste e crescerà. La difesa giusta non è inseguire lo user-agent di turno, è la solita igiene applicata con disciplina: niente segreti raggiungibili, difesa in profondità sui dotfile, e soprattutto la capacità di leggere i propri log distinguendo onestamente il rumore dal segnale. Se vuoi una valutazione della superficie di esposizione della tua infrastruttura fatta con questa mentalità offensiva, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.