Lacuna di sicurezza Anthropic Google: gli agenti AI hanno seguito documenti attendibili fino a codice non posseduto

Anthropic e Google sono ora coinvolte in una controversia sulla sicurezza, dopo che alcuni ricercatori hanno riferito che agenti di coding hanno eseguito pacchetti citati in documentazione aziendale attendibile. Secondo quanto riportato, un pacchetto di test è stato eseguito in un ambiente Fortune 500 entro quattro minuti. Claude, OpenAI Codex e Hermes di Nous Research sono poi comparsi nei registri dei processi, secondo i ricercatori.

La scoperta non dimostra che Anthropic, Google o OpenAI abbiano distribuito malware deliberatamente. La maggior parte dei pacchetti registrati per l’esperimento conteneva beacon innocui, che segnalavano soltanto quando venivano eseguiti. La scoperta più grave riguardava un pacchetto npm non correlato, ritenuto dannoso e collegato a istruzioni pubblicate in passato sul sito del provider di autenticazione Clerk.

Questa distinzione è importante perché la copertura iniziale può far pensare che tre fornitori di AI abbiano violato reti aziendali. Le prove indicano invece un fallimento della supply chain software. Gli agenti hanno considerato attendibili istruzioni dall’aspetto ufficiale, hanno raggiunto registri pubblici di pacchetti e hanno eseguito nomi che nessuno aveva messo in sicurezza.

Google entra in questa vicenda sulla sicurezza Anthropic Google attraverso il suo supporto al controllo dei file llms.txt in Lighthouse, il suo software di auditing per siti web. Claude e Codex entrano in gioco attraverso gli agenti che avrebbero seguito le istruzioni di installazione. Il problema comune non è un singolo modello o una singola azienda. È il confine sempre più sfumato tra documentazione e azione eseguibile.

Un tempo quel confine appariva netto. Uno sviluppatore poteva leggere una guida di configurazione, verificare un pacchetto e decidere se installarlo. Un agente di coding autonomo può comprimere questi passaggi in un’unica operazione, spesso usando le autorizzazioni già disponibili per lo sviluppatore.

Il risultato pone una nuova domanda di sicurezza per ogni organizzazione che distribuisce agenti di coding: quando un software legge un documento, chi verifica che il documento indichi ancora qualcosa di affidabile?

Gli agenti AI aziendali hanno eseguito nomi che nessuno possedeva

I ricercatori hanno trasformato documentazione obsoleta nella prova eseguibile che un testo attendibile può diventare un punto di ingresso.

Il ricercatore di sicurezza Alon Hertz e i suoi colleghi hanno esaminato documentazione leggibile dalle macchine su 6.214 domini attivi. Il loro campione includeva appaltatori della difesa, grandi aziende tecnologiche e organizzazioni Fortune 500.

I ricercatori hanno riferito di aver trovato 8.265 file llms.txt e llms-full.txt. Un file llms.txt è una convenzione emergente che organizza i contenuti di un sito web per i modelli linguistici e gli agenti AI. Il suo equivalente più esteso può fornire documentazione più ampia in un unico file leggibile dalle macchine.

Tra i file raccolti, 120 siti web citavano almeno un pacchetto non registrato o un dominio non rivendicato. Il team ha contato 227 comandi che coinvolgevano pacchetti o destinazioni inesistenti.

Non si trattava necessariamente di istruzioni ostili. Alcuni sembravano normali comandi di installazione che puntavano a nomi di pacchetto mai registrati. Altri citavano domini scaduti o servizi non più rivendicati.

Una riga come pip install package-name diventa pericolosa quando il nome del pacchetto è disponibile su PyPI. Lo stesso principio vale per npm, RubyGems, NuGet, crates.io, Packagist o un sottodominio di hosting abbandonato.

I ricercatori hanno registrato una piccola selezione di questi nomi disponibili. Hanno poi pubblicato pacchetti contenenti codice progettato per contattare il loro server al momento dell’esecuzione. Il resoconto della ricerca di Hertz afferma che il primo callback è arrivato da un ambiente Fortune 500 entro quattro minuti.

Secondo quanto riportato, altri due sistemi hanno eseguito il codice entro la prima ora. Nel tempo, il team ha ricevuto diverse decine di callback da startup e grandi imprese.

Il callback ha registrato la catena dei processi genitori, che identifica i programmi coinvolti nell’avvio di un processo. Secondo i ricercatori, tali registri collegavano alcune installazioni a Claude, OpenAI Codex e Hermes di Nous Research.

L’esperimento non ha richiesto la compromissione di tali modelli. Non si è nemmeno basato su una vulnerabilità software appena scoperta, un messaggio di phishing o una password di dipendente rubata. Secondo quanto riferito, gli agenti hanno trovato istruzioni pubblicate su siti web legittimi e le hanno seguite con gli accessi disponibili nei rispettivi ambienti.

Questo è il ribaltamento centrale. La documentazione aziendale normalmente rafforza la sicurezza mostrando agli sviluppatori il modo approvato per configurare il software. Qui, riferimenti abbandonati all’interno di quella documentazione hanno creato l’opportunità per qualcun altro di definire cosa avrebbe eseguito il comando approvato.

La scoperta richiede anche un linguaggio prudente. I ricercatori non hanno identificato pubblicamente le imprese interessate, rilasciato ogni nome di pacchetto o fornito telemetria sufficiente perché soggetti esterni possano riprodurre ogni attribuzione aziendale. Anthropic, OpenAI e Nous Research non hanno commentato prima della pubblicazione del rapporto originale.

Anche con questi limiti, l’esperimento dimostra un meccanismo credibile. Un registro pubblico di pacchetti attribuisce significato a chiunque controlli un nome. La documentazione ufficiale può conservare quel nome molto tempo dopo che il suo significato originario è scomparso.

Perché la catena di fiducia Anthropic Google ha fallito

Gli agenti non hanno ignorato il modello di fiducia. Hanno seguito un modello di fiducia che non corrispondeva più al modo in cui opera il software autonomo.

La documentazione tradizionale presuppone che un lettore umano si trovi tra le istruzioni e l’esecuzione. Quel lettore può notare un nome di pacchetto insolito, ispezionarne il publisher o chiedersi perché un comando di configurazione non abbia un repository di supporto.

Un agente può eseguire gli stessi controlli, ma solo quando le sue istruzioni e il suo ambiente lo richiedono. Altrimenti, ottimizza per completare il compito richiesto. Trovare documentazione ufficiale ed eseguire il relativo comando di installazione può apparire come il percorso valido più breve.

Il collegamento Anthropic Google evidenzia come diverse decisioni ragionevoli prese in modo indipendente possano combinarsi in un’unica catena rischiosa. I siti web pubblicano istruzioni leggibili dalle macchine. Gli strumenti Lighthouse di Google incoraggiano gli sviluppatori a rendere tali istruzioni individuabili. Gli agenti di coding cercano contesto autorevole. I gestori di pacchetti rendono facile recuperare ed eseguire dipendenze.

Nessuno di questi componenti deve essere dannoso. Il pericolo emerge quando l’agente tratta l’intera catena come autenticata.

Le linee guida Lighthouse di Google descrivono un audit per la disponibilità e la formattazione di llms.txt. Lighthouse non certifica ogni comando o dipendenza nominata all’interno di un file. Superare un audit di formattazione non dice quindi nulla sulla proprietà del pacchetto, l’identità del publisher o la sicurezza del codice.

Allo stesso modo, HTTPS dimostra che un file proviene dal dominio mostrato nella connessione del browser. Non dimostra che ogni pacchetto citato appartenga ancora all’operatore di quel dominio.

Un registro pubblico può inoltre fornire un pacchetto scritto correttamente da un account controllato da un attaccante. Ciò differisce dal typosquatting classico, in cui gli attaccanti registrano un errore di battitura simile a un pacchetto popolare. I nomi di questo esperimento sarebbero stati copiati direttamente dalla documentazione ufficiale.

Questo rende le istruzioni più persuasive sia per gli agenti sia per gli esseri umani. Uno sviluppatore che esamina una trascrizione del terminale potrebbe vedere un dominio ufficiale, un gestore di pacchetti familiare e un nome di dipendenza plausibile. Ogni segnale visibile può apparire ordinario.

Il comportamento di ricerca dell’agente aggrava il problema. Un utente può menzionare solo un fornitore nel richiedere un’integrazione. L’agente può individuare la documentazione del fornitore, scoprire llms.txt, selezionare un comando di installazione e richiamare il gestore di pacchetti senza ricevere dall’utente un link sospetto.

Per questo l’incidente è più ampio della prompt injection. La prompt injection coinvolge di solito contenuti ostili che tentano di reindirizzare un agente. Qui, l’istruzione stessa può essere innocua e storicamente legittima. Il fallimento della sicurezza avviene in seguito, dopo che la proprietà della destinazione citata cambia o non è mai esistita.

Anche la convenzione emergente llms.txt non equivale a uno standard web formale con un’architettura di sicurezza consolidata. La sua utilità deriva dal fornire ai modelli un contesto conciso e strutturato. La stessa comodità può concentrare istruzioni operative in un luogo che gli agenti sono incoraggiati a considerare attendibile.

La lacuna di sicurezza Anthropic Google è quindi un problema di provenienza. Per provenienza si intendono le prove che mostrano da dove proviene un artefatto e chi lo controlla. L’agente ha verificato la posizione del documento, ma apparentemente non ha stabilito la provenienza della dipendenza eseguibile dietro il comando.

Il vero avversario è l’autonomia senza provenienza

Il conflitto determinante non è Claude contro Codex. È l’esecuzione autonoma contro la proprietà verificata del software.

Claude, Codex e Hermes usano modelli, interfacce e sistemi di autorizzazione diversi. Trattare questo evento come un semplice confronto tra questi strumenti farebbe perdere di vista la condizione operativa condivisa alla base delle installazioni riportate.

Ogni agente di coding può leggere il contesto del progetto, consultare documentazione, modificare file e richiamare strumenti di sviluppo. Queste capacità rendono utili gli agenti perché eliminano i passaggi manuali tra ricerca ed esecuzione.

Spostano però anche una decisione di sicurezza nel flusso di lavoro dell’agente. Qualcuno deve stabilire se una dipendenza è autentica, se la sua versione è accettabile e se i suoi script di installazione debbano essere eseguiti.

I gestori di pacchetti eseguono regolarmente codice durante l’installazione. Un pacchetto npm può definire script del ciclo di vita, mentre un pacchetto Python può eseguire comportamenti relativi all’installazione attraverso il proprio processo di build. Il comportamento esatto varia, ma l’installazione non equivale al download di testo inerte.

L’esempio di Clerk mostra perché questo è importante. I ricercatori hanno scoperto che un file di istruzioni sul sito web legittimo di Clerk citava npx clerk-next-fix-auth-protection. L’utilità npx può scaricare un pacchetto ed eseguire il comando che espone senza aggiungerlo in modo permanente al manifest di un progetto.

Secondo l'indagine sulla sicurezza, qualcuno aveva rivendicato quel nome di pacchetto e lo aveva usato per distribuire malware attivo. Clerk ha poi corretto la documentazione.

Resta poco chiaro se quel pacchetto abbia causato infezioni attraverso un agente AI. Il reportage rileva inoltre che un binario esistente del legittimo plugin ESLint di Clerk era sicuro. Una macchina priva di quel binario legittimo potrebbe invece recuperare il pacchetto controllato dall’attaccante.

La differenza è abbastanza sottile da sfuggire a un revisore frettoloso. Entrambi i percorsi iniziano con un comando pubblicato dal vero fornitore. Entrambi usano l’infrastruttura npm. Il percorso pericoloso dipende dal fatto che il binario previsto esista già localmente.

Questo è il compromesso pratico che le imprese devono affrontare. Gli agenti offrono più valore quando possono risolvere dipendenze, eseguire test e correggere errori senza attendere l’approvazione dopo ogni comando. Le stesse autorizzazioni consentono a una decisione di fiducia errata di trasformarsi in esecuzione di codice.

Il fornitore del modello può ridurre questo rischio attraverso sandboxing e approvazioni. L’impresa deve comunque configurare tali controlli, mantenere politiche di rete e decidere quali fonti di pacchetti un agente può raggiungere.

Il fornitore del software possiede un'altra parte del problema. La sua documentazione è diventata una risorsa operativa anziché contenuto di marketing statico. Riferimenti a pacchetti, domini di esempio, comandi copiati e pagine di configurazione archiviate richiedono ora la stessa gestione del ciclo di vita del codice eseguibile.

Anche gli operatori dei registry influenzano il risultato. La riserva dei namespace, la verifica dei publisher, la scansione dei pacchetti sospetti e la cronologia della proprietà possono essere d'aiuto. Tuttavia, i registry non possono sempre sapere che un nome non rivendicato compare nella documentazione di terze parti.

Questa ripartizione delle responsabilità rende poco utile la semplice attribuzione di colpe. La vicenda Anthropic Google è importante perché attraversa i confini tra prodotti. Uno strumento di ricerca o documentazione può rendere più facili da trovare le istruzioni, un agente AI può interpretarle e un registry può fornire l'artefatto indicato.

La sicurezza fallisce quando ogni partecipante presume che un altro abbia verificato la titolarità.

Le protezioni esistenti per gli agenti non eliminano il rischio

Claude e Codex offrono già controlli significativi, ma funzionano solo quando le organizzazioni mantengono i loro confini restrittivi.

Le linee guida di sicurezza di Claude di Anthropic descrivono la prompt injection come testo ostile che tenta di manipolare le istruzioni di un assistente. Documentano inoltre controlli delle autorizzazioni e restrizioni per i comandi che recuperano contenuti web arbitrari.

Claude Code può usare il sandboxing per limitare l'accesso al filesystem e alla rete. I processi figlio ereditano tali restrizioni del sistema operativo, contribuendo a impedire che un comando autorizzato sfugga silenziosamente a un processo meno limitato.

OpenAI descrive un approccio analogo a più livelli. Il suo modello di sicurezza di Codex combina confini di sandbox, policy di approvazione, accesso di rete gestito, regole e telemetria consapevole degli agenti.

OpenAI afferma che i suoi deployment gestiti non concedono a Codex un accesso in uscita illimitato. Le destinazioni previste possono essere consentite, i domini sconosciuti possono richiedere approvazione e i team di sicurezza possono esportare log che coprono prompt, chiamate agli strumenti, approvazioni e decisioni di rete.

Queste protezioni contano, ma non invalidano automaticamente le conclusioni dei ricercatori. Le organizzazioni possono configurare gli agenti con un accesso più ampio. Gli sviluppatori possono approvare comandi. Le installazioni locali possono ereditare autorizzazioni e connettività di rete dall'utente che le esegue.

Un package registry è inoltre una destinazione prevista in molti ambienti di sviluppo. Bloccare ogni accesso a npm o PyPI interromperebbe build ordinarie, aggiornamenti delle dipendenze e configurazioni di test. Consentire tali domini rimuove un evidente segnale di rete che potrebbe distinguere un'installazione malevola.

Il software di endpoint detection and response affronta una sfida simile. Un agente di coding avvia un normale package manager, che contatta un registry noto tramite una connessione cifrata. Il processo può assomigliare alla normale attività di uno sviluppatore finché il pacchetto scaricato non compie qualcosa di chiaramente ostile.

Il beacon della ricerca era intenzionalmente minimale. Secondo quanto riportato, contattava un server e registrava il contesto di esecuzione. Un attaccante reale potrebbe tentare il furto di credenziali, la ricognizione dell'ambiente, la persistenza o la modifica del codice sorgente.

Tuttavia, le prove pubbliche non mostrano che i pacchetti sperimentali abbiano compiuto tali azioni. Non dimostrano neppure che decine di aziende abbiano subito una compromissione della produzione. Hanno eseguito codice proof-of-concept, il che è grave ma più circoscritto di una violazione confermata.

Questa distinzione scettica dovrebbe orientare la risposta aziendale. I team non dovrebbero presumere che ogni utilizzo di Claude, Codex o Hermes crei un'infezione. Dovrebbero identificare le condizioni necessarie affinché questo percorso funzioni.

L'agente necessita dell'accesso alla documentazione pertinente. Necessita dell'autorità per invocare un package manager. L'ambiente deve consentire il recupero dal registry. Il pacchetto deve eseguire codice significativo e i controlli esistenti devono non riuscire a contenerne il comportamento.

Rimuovere anche solo una di queste condizioni può interrompere la catena. Limitare l'accesso alla rete è un'opzione. Richiedere l'approvazione umana per l'installazione delle dipendenze è un'altra. Eseguire gli agenti in container temporanei può limitare le conseguenze quando un pacchetto viene effettivamente eseguito.

Le organizzazioni possono anche imporre un proxy interno per le dipendenze. Il proxy può consentire pacchetti e versioni approvati, rifiutando al contempo namespace sconosciuti. Questo approccio sposta la decisione di fiducia da un agente che legge documentazione pubblica.

I prompt di approvazione da soli sono meno affidabili quando presentano soltanto un comando familiare. Un revisore necessita di contesto su proprietà del pacchetto, età, identità del publisher, cronologia dei download e presenza della dipendenza in una distinta dei materiali software approvata.

La lezione non è che le protezioni siano inutili. È che i controlli progettati attorno a comandi palesemente malevoli possono non rilevare comandi legittimi che si risolvono in una proprietà non affidabile.

La documentazione ora appartiene alla supply chain del software

Le aziende devono trattare ogni riferimento eseguibile nella documentazione come una dipendenza che può scadere, deviare o cambiare proprietario.

La risposta immediata inizia con un inventario. Le organizzazioni dovrebbero cercare comandi di installazione in llms.txt, llms-full.txt, portali per sviluppatori, guide archiviate, esempi di codice, articoli di supporto e riferimenti API generati.

Ogni pacchetto, dominio, repository, immagine container e sottodominio ospitato citato necessita di un proprietario. Un nome che nessuno riconosce non dovrebbe rimanere pubblico mentre è in corso un'indagine.

I team dovrebbero verificare che i nomi dei pacchetti pubblici corrispondano ai reali account del registry dell'organizzazione. Dovrebbero inoltre controllare se i pacchetti con scope siano disponibili laddove nella documentazione più datata compare un nome globale privo di scope.

Le pipeline di documentazione necessitano di test automatizzati. Una build può verificare che ogni pacchetto esista, appartenga a un publisher approvato, si risolva in un repository atteso e non abbia cambiato proprietario.

Il semplice controllo dei link non è sufficiente. Un pacchetto malevolo o un dominio recuperato può restituire una risposta riuscita. La pipeline deve convalidare l'identità anziché la disponibilità.

Le aziende dovrebbero riservare i nomi prima di pubblicare la documentazione. È simile alla registrazione difensiva di domini attorno a un prodotto importante, ma i namespace dei pacchetti richiedono manutenzione continua.

Lo stesso principio vale quando un progetto viene ritirato. Rimuovere un pacchetto senza rimuovere le relative istruzioni di installazione crea un vuoto di proprietà. Abbandonare un sottodominio di hosting lasciando attivi i link può consentire a un'altra parte di ereditare un percorso fidato.

La documentazione generata dall'AI merita un ulteriore controllo, ma le pagine scritte da esseri umani non sono esenti. I ricercatori hanno trovato prove che alcuni riferimenti dubbi precedessero l'attuale era degli agenti. Copiare quelle pagine in llms-full.txt ha reso più facile per il software autonomo assimilare vecchi errori.

Le aziende che implementano agenti necessitano di un piano di controllo complementare. Le sessioni degli agenti dovrebbero essere eseguite con identità dedicate anziché con l'account senza restrizioni di uno sviluppatore. Le credenziali dovrebbero essere circoscritte al repository e al compito corrente.

L'installazione dei pacchetti dovrebbe avvenire in un ambiente isolato con accesso limitato ai segreti. Se una dipendenza necessita di accesso alla rete durante l'installazione, tale accesso dovrebbe essere esplicito e registrato.

I team dovrebbero conservare il contesto di ragionamento dell'agente insieme alla telemetria del sistema operativo. Un log di processo può mostrare che npm è stato avviato, mentre i registri nativi dell'agente possono mostrare quale documento ha fornito il nome del pacchetto.

Questo contesto è importante durante la risposta agli incidenti. Gli investigatori devono distinguere una dipendenza di progetto approvata da un pacchetto selezionato dopo che un agente ha consultato istruzioni esterne.

Le allowlist delle dipendenze possono ridurre il rischio, ma richiedono un percorso di eccezione per i nuovi pacchetti. Tale eccezione dovrebbe raccogliere prove di provenienza e richiedere un responsabile umano nominato.

Le organizzazioni dovrebbero inoltre mantenere un registro ricercabile delle fonti consultate dagli agenti. Può includere snapshot della documentazione, metadati dei pacchetti, decisioni di approvazione e modifiche al codice generate. Una base di conoscenza tecnica controllata può aiutare i revisori a ricostruire perché un agente abbia selezionato una dipendenza.

La lezione più ampia va oltre llms.txt. Gli agenti di coding consumano descrizioni di issue, file di repository, risultati di ricerca, documentazione dei pacchetti, risposte del Model Context Protocol e guide interne generate.

Ciascuna di queste fonti può contenere un'istruzione. Se l'agente dispone di strumenti, l'istruzione può diventare un'azione.

Questo rende l'integrità della documentazione parte della sicurezza della supply chain del software. L'azienda non può proteggere solo repository di codice sorgente e server di build, lasciando fuori dal proprio controllo le istruzioni leggibili dalle macchine.

Tre segnali mostreranno se il settore ha imparato

La prossima fase dipende dal miglioramento congiunto della documentazione, delle autorizzazioni degli agenti e dell'identità nei registry.

Il primo segnale è la divulgazione e la mitigazione nei 120 siti web interessati. Il team di Hertz afferma di aver contattato le organizzazioni colpite e i team di sicurezza pertinenti, ma il registro pubblico non identifica la maggior parte dei domini.

Occorre osservare se le aziende stanno verificando i file llms.txt, riservando nomi di pacchetti e pubblicando avvisi di incidente. Una bonifica coordinata rafforzerebbe l'argomentazione secondo cui il settore riconosce la documentazione leggibile dalle macchine come infrastruttura sensibile per la sicurezza.

Il silenzio non dimostrerebbe che non siano state apportate correzioni. Molte organizzazioni riparano riferimenti esposti senza divulgazione pubblica, in particolare quando i ricercatori hanno usato codice innocuo e non hanno rilevato alcun furto di dati confermato.

Il secondo segnale è un controllo di provenienza a livello di prodotto da parte dei fornitori di agenti. Claude, Codex e Hermes possono già richiedere approvazione prima dei comandi, ma l'approvazione diventa più utile quando l'interfaccia spiega la dipendenza dietro il comando.

Un cambiamento significativo avvertirebbe che un pacchetto è nuovo, non verificato, non correlato all'account publisher noto del fornitore o assente dal grafo delle dipendenze esistente del progetto. Un sistema più solido potrebbe richiedere un'approvazione esplicita ogni volta che la documentazione pubblica punta a un pacchetto non riconosciuto.

Una funzione del genere rafforzerebbe la risposta di sicurezza Anthropic Google perché affronterebbe il punto decisionale prima dell'esecuzione. Un altro avviso generico sui comandi shell offrirebbe una protezione minore.

Il terzo segnale è l'integrazione tra registry e policy aziendali. I package manager e i proxy interni possono esporre la cronologia del publisher, l'età del namespace, lo stato della firma e i cambiamenti di proprietà. Le piattaforme di agenti possono utilizzare tali metadati prima di selezionare o installare una dipendenza.

Una policy aziendale potrebbe consentire automaticamente pacchetti consolidati, isolando al contempo quelli sconosciuti per la revisione. Potrebbe inoltre rifiutare un pacchetto il cui nome compare nella documentazione ufficiale ma che non ha un collegamento verificabile con il publisher.

Questo segnale indebolirebbe l'avvertimento più ampio dei ricercatori se controlli di provenienza affidabili bloccassero il percorso di attacco su più agenti. Rafforzerebbe il loro avvertimento se gli agenti continuassero a installare nomi rivendicati di recente nonostante dati di identità disponibili.

Le prove attuali supportano una conclusione misurata. Secondo quanto riportato, i ricercatori hanno dimostrato l'esecuzione di codice in ambienti aziendali reali e hanno collegato parte dell'attività a importanti agenti di coding. Non hanno dimostrato che i fornitori dei modelli abbiano installato intenzionalmente malware né che ogni callback segnalato rappresentasse una compromissione grave.

Il risultato più importante è strutturale. Documentazione fidata, esecuzione autonoma e registry pubblici formano ora una supply chain che molti programmi di sicurezza non inventariano.

Sviluppatori e acquirenti aziendali dovrebbero porre domande dirette prima di ampliare le autorizzazioni degli agenti. L'agente può accedere ai registry pubblici dei pacchetti? Verifica l'identità del publisher? I comandi di installazione sono isolati? I team di sicurezza possono ricostruire quale documento ha causato un'azione?

Il divario di sicurezza tra Anthropic e Google non si colmerà solo con un migliore comportamento dei modelli. Responsabili della documentazione, registri, fornitori di agenti e amministratori aziendali controllano ciascuno un anello diverso.

Prima di concedere a un agente di coding maggiore autonomia, verifica l’intera catena con una dipendenza non riconosciuta. Se l’agente la installa senza indicarne la provenienza, l’ambiente sta trattando la documentazione come autorità anziché come evidenza.