Apr 01, 2026 Approfondimenti, In evidenza, News, RSS, Tecnologia, Tecnologia

---

Un recente studio della Unit 42 di Palo Alto ha messo in luce un aspetto ancora poco esplorato della sicurezza dei sistemi basati su agenti AI: la possibilità che un agente distribuito in ambienti enterprise possa trasformarsi in un “doppiogiochista” (un  double agent) capace di compromettere l’intera infrastruttura cloud. L’analisi si concentra sulla piattaforma Vertex AI di Google Cloud, evidenziando come configurazioni permissive e modelli di accesso predefiniti possano essere sfruttati per escalation di privilegi, esfiltrazione di dati e accesso a risorse interne sensibili.

Il punto centrale è che un agente AI compromesso non agisce come un attaccante esterno, ma come un insider con privilegi legittimi, ampliando enormemente il potenziale impatto di una violazione. In ambienti come Google Cloud Vertex AI, dove gli agenti possono orchestrare servizi e interagire con risorse distribuite, questo scenario diventa particolarmente critico.

Permessi eccessivi e abuso dei Service Agent

L’analisi tecnica ha evidenziato come il modello di autorizzazione di Vertex AI possa esporre a rischi significativi. In particolare, il Per-Project, Per-Product Service Agent (P4SA) associato agli agenti AI presenta, in configurazioni predefinite, privilegi eccessivamente ampi.

Attraverso un agente malevolo, i ricercatori sono riusciti a estrarre credenziali di servizio direttamente dal metadata endpoint interno di Google Cloud. Il risultato è che l’agente può impersonare identità privilegiate e operare con accessi estesi su risorse cloud, violando il principio del least privilege. Questa condizione consente di ottenere accesso completo in lettura ai bucket di Google Cloud Storage, includendo permessi come storage.buckets.list e storage.objects.get.

Dal progetto cliente all’infrastruttura Google: escalation inattesa

Uno degli aspetti più rilevanti della ricerca riguarda il passaggio dal contesto cliente al contesto “producer”, ovvero l’infrastruttura gestita da Google stessa.

Utilizzando le credenziali sottratte, è stato possibile accedere a repository privati di Artifact Registry contenenti immagini container interne, tra cui componenti del Reasoning Engine. Questo implica che un attaccante può ottenere accesso a codice proprietario e dettagli implementativi della piattaforma stessa, con implicazioni dirette sulla sicurezza della supply chain. L’accesso non era disponibile per identità standard, ma risultava abilitato per il service agent compromesso, dimostrando una separazione dei privilegi non allineata ai principi di sicurezza più rigorosi.

Artifact Registry e visibilità sulla supply chain interna

Un ulteriore livello di rischio emerge dalla possibilità di enumerare repository e pacchetti all’interno dell’Artifact Registry. La configurazione osservata ha consentito di scoprire immagini e componenti non documentati, offrendo una visibilità anomala sulla supply chain software interna. Questo significa che un attaccante potrebbe mappare l’infrastruttura applicativa, individuare componenti vulnerabili e pianificare attacchi mirati, anche senza accesso diretto ai contenuti.

Si tratta di un classico scenario di information disclosure che, in ambienti AI-driven, assume una portata molto più ampia.

Tenant project e esposizione di asset sensibili

Durante il deployment di un agente, Vertex AI utilizza tenant project gestiti da Google. Anche in questo caso, le credenziali compromesse hanno permesso accesso a bucket contenenti artefatti sensibili.

Tra questi figurano file come Dockerfile.zip, requirements.txt e soprattutto code.pkl. Quest’ultimo introduce un rischio particolarmente critico: la serializzazione tramite pickle. È noto, infatti, che la deserializzazione di oggetti pickle provenienti da fonti non affidabili può portare a remote code execution, trasformando l’agente in un punto di persistenza per attacchi avanzati.

OAuth scope e rischio di espansione verso Google Workspace

Un elemento strutturale emerso riguarda la configurazione degli OAuth scope associati agli agenti. Gli scope assegnati includono accessi a servizi come Gmail, Drive e Calendar. Anche se l’accesso effettivo richiede permessi IAM aggiuntivi, la presenza di scope così ampi rappresenta un rischio latente.

La combinazione di token esposti e scope eccessivi potrebbe estendere l’attacco oltre il perimetro cloud, coinvolgendo servizi di collaborazione aziendale, ampliando drasticamente la superficie di compromissione.

Supply chain AI e agenti malevoli: un nuovo vettore

La ricerca evidenzia anche un rischio emergente legato alla diffusione di agenti AI preconfigurati. La possibilità di distribuire agenti tramite ADK e Agent Engine apre la strada a scenari in cui codice malevolo viene integrato in componenti apparentemente legittimi. In questo modo, la supply chain AI diventa un vettore di attacco, dove agenti compromessi si presentano come strumenti produttivi ma operano come backdoor persistenti. Questo fenomeno richiama dinamiche già osservate nel mondo open source, ma con un impatto amplificato dalla capacità operativa degli agenti AI.

Mitigazioni e modello di sicurezza: verso il BYOSA

A seguito della disclosure responsabile, Google ha aggiornato la documentazione e suggerito l’adozione del modello Bring Your Own Service Account (BYOSA). Questo approccio consente di sostituire il service agent predefinito con account configurati secondo il principio del least privilege. Di fatto, la sicurezza degli agenti AI deve essere trattata come quella del codice di produzione, con controlli rigorosi su permessi, scope e integrazioni. Parallelamente, sono stati verificati controlli robusti per impedire modifiche ai container di produzione, riducendo il rischio di attacchi supply chain cross-tenant.

---

• agenti AI, AI security, Artifact Registry, Cloud security, cybersecurity AI, data exfiltration, GCP vulnerabilità, Google Cloud sicurezza, OAuth security, Privilege escalation, securityinfo, service agent, supply chain AI, Vertex AI

---

---