Le ha detto al suo agente di correggere gli errori. Uno di quelli era stato scritto da un attaccante.

Uno sviluppatore apre il proprio agente di programmazione basato su IA e digita la richiesta più ordinaria del mondo: «dai un'occhiata agli errori Sentry non risolti e correggili». L'agente recupera l'elenco degli errori tramite il connettore Sentry, legge il problema principale, segue le procedure di rimedio scritte proprio lì nel report e le esegue. Mezzo minuto dopo ha eseguito il codice di un attaccante sulla macchina dello sviluppatore, con i pieni privilegi dello sviluppatore, e nessuno ha fatto niente di sbagliato.

Si tratta di Agentjacking, divulgato questo mese da Tenet Security, e ha funzionato nell'85% dei casi contro i tre agenti di programmazione più diffusi sul mercato: Claude Code, Cursor e Codex [1][2].

Cosa è successo davvero

Prima, cos'è Sentry: uno dei servizi di monitoraggio degli errori più utilizzati nel software. Quando la sua applicazione genera un errore o va in crash, Sentry lo cattura e archivia il report che i suoi sviluppatori esaminano — è presente in una quota enorme delle applicazioni che usa ogni giorno. Per inviare quei report, ogni applicazione incorpora un DSN: una chiave lato client che compare deliberatamente nel sorgente del suo sito web, affinché il browser possa segnalare gli errori. Chiunque può leggerla. E chiunque la possieda può inviare con una POST un evento di errore nel suo progetto Sentry.

Questa è l'intera chiave dell'attacco. Tenet ha costruito un evento di errore finto il cui campo message era formattato per apparire identico alle indicazioni di rimedio di Sentry: markdown ordinato, una «correzione consigliata», un comando da eseguire. Lo hanno inviato con il DSN pubblico. Poi hanno atteso l'azione più naturale per uno sviluppatore — chiedere all'agente di svuotare la coda degli errori.

L'agente interroga Sentry tramite il proprio connettore MCP. Il connettore restituisce l'errore come output di sistema attendibile. L'agente non è in grado di distinguere un report Sentry autentico da uno contraffatto: hanno esattamente la stessa forma, byte per byte. Così fa quanto gli è stato detto ed esegue la «correzione», di norma una chiamata npx a un pacchetto dell'attaccante. Da quel momento ha tutto ciò che ha lo sviluppatore: variabili d'ambiente, credenziali Git, URL di repository privati, le chiavi cloud in ~/.aws/.

Tenet ha individuato 2.388 organizzazioni con DSN iniettabili, da sviluppatori indipendenti fino a aziende della Fortune 100. Nei suoi test controllati, gli agenti hanno effettivamente eseguito le istruzioni iniettate in aziende reali — inclusa, secondo Tenet, una società tecnologica della Fortune 100 da 250 miliardi di dollari il cui agente IA ha letto il falso report di bug ed eseguito il codice di Tenet su due delle sue macchine aziendali [1][3]. Divulgato a Sentry il 3 giugno, il problema è stato riconosciuto dall'azienda lo stesso giorno, che ha rifiutato di risolverlo alla radice definendolo «tecnicamente non difendibile». Ha rilasciato un filtro sui contenuti che blocca una specifica stringa di payload [4].

Non è negligenza da parte di Sentry

Ecco la parte scomoda: in tutta quella catena non c'era alcun bug. Il DSN deve essere pubblico. Il server MCP deve restituire i suoi dati di errore. L'agente deve intervenire sulle diagnostiche che gli ha chiesto di correggere. Ogni passaggio era autorizzato, ed è esattamente per questo che nessun firewall, nessun EDR, nessun system prompt lo ha intercettato.

Il difetto è strutturale e non è solo di Sentry. Qualsiasi strumento che fornisca a un un agente testo influenzabile da un estraneo — un error tracker, una coda di issue, una pagina web acquisita, un documento condiviso — è un canale di iniezione, e l'agente tratta tutto questo come un unico flusso indistinto di istruzioni. La prompt injection, a due anni dall'era degli agenti, è ancora irrisolta: non è possibile tenere in modo affidabile il testo ostile fuori dal ragionamento di un modello. Dà per scontato che non ci riuscirà.

L'iniezione non è la catastrofo

Ecco la parte su cui vale la pena soffermarsi. La ragione per cui Agentjacking è un allarme di massima gravità non è che l'agente sia stato ingannato. È ciò a cui l'agente ingannato poteva accedere. Ha operato con l'accesso permanente pieno dello sviluppatore: ogni chiave nell'ambiente, ogni file di credenziali su disco, l'intero portachiavi a un solo comando di distanza.

Quel raggio d'impatto non è una legge di natura. È una configurazione. L'agente aveva accesso permanente a tutto questo perché è così che oggi vengono memorizzate le credenziali — ambientali, sulla macchina, leggibili da qualsiasi cosa vi venga eseguita. Si tolga questo, e lo stesso dirottamento si scontra con un muro.

Progettato per questo, deliberatamente

Una credenziale Clavitor non si trova mai nell'ambiente in cui l'agente viene eseguito. Non esiste un ~/.aws/credentials da leggere, né una chiave API in una variabile d'ambiente da esfiltrare, perché il valore del segreto non arriva mai dove il codice viene eseguito — l'agente ottiene il risultato dell'uso di una credenziale, non la credenziale stessa. Può raggiungere solo la singola risorsa per cui è stata nominata, e quindi non può enumerare il deposito per scoprire cos'altro contiene. Inoltre la concessione è delimitata e revocabile, così una sessione che inizi a comportarsi come un attaccante può essere interrotta a metà azione.

Ecco il limite, detto con onestà: questo non ferma l'iniezione e non impedisce a un agente dirottato di eseguire un comando. La prompt injection è irrisolta e non sosteniamo di risolverla. Ciò che cambia è il guadagno. Il codice dell'attaccante viene comunque eseguito — e trova un ambiente in cui non c'è nulla di permanente che valga la pena rubare. Il dirottamento riesce e il colpo fallisce.

Abbiamo messo per iscritto le regole che un sistema di credenziali deve rispettare quando l'agente stesso può essere rivolto contro di lei, a cominciare dal fatto che il segreto non deve mai vivere dove il codice viene eseguito e che un agente deve poter raggiungere solo ciò per cui è stato nominato. Verifichi il suo sistema su queste regole: clavitor.ai/rules.

La lezione non è «correggete Sentry»

Sentry non può risolvere questo problema, e lo ha detto. E il prossimo strumento avvelenato non sarà Sentry. Fintanto che i suoi agenti portano con sé credenziali ambientali e permanenti, ogni strumento attendibile che leggono è un'arma carica, e la prompt injection è il grilletto che non può bloccare.

Non riuscirà a tenere fuori il testo malevolo. Smetta quindi di tenere le credenziali alla portata dell'agente che lo legge.

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

Fonti

[1] Tenet Security — "Agentjacking: hijacking coding agents with fake Sentry errors" (85% di successo; 2.388 organizzazioni; meccanismo): https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — "Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code": https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — "A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex": https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — "New 'Agentjacking' Attacks Could Hijack AI Coding Agents" (risposta di Sentry): https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/