Le app AI trasformano la fiducia in Google Workspace in una moderna catena di attacco

La sicurezza di Google Workspace ha raggiunto un punto di tensione, nonostante anni di password più robuste, autenticazione a più fattori e controlli anti-phishing migliorati. Le ultime notizie Google per i team di sicurezza riguardano accessi che gli attaccanti non devono sottrarre direttamente. Possono ereditarli tramite un'applicazione AI approvata, una sessione del browser compromessa o un token OAuth abbandonato.

Questa distinzione cambia il problema difensivo. I programmi di sicurezza si concentrano tradizionalmente sul fermare un attaccante alla schermata di accesso. Gli attacchi moderni iniziano sempre più spesso con accessi che Google considera già autorizzati.

Gli strumenti AI accentuano questa tensione perché necessitano di connessioni estese per fornire risposte utili e compiere azioni. Un assistente potrebbe leggere Gmail, cercare in Drive, esaminare Calendar e trasferire risultati a un altro servizio. Ogni connessione crea un rapporto di fiducia che può sopravvivere ai cambi di password e rimanere attivo senza un'interazione evidente dell'utente.

La lezione immediata non è che ogni strumento AI sia dannoso. È che l'autorizzazione è diventata parte del perimetro aziendale. Una recente analisi di Material Security, rilanciata da BleepingComputer, sostiene che molte organizzazioni la trattino ancora come rumore amministrativo di fondo.

L'incidente Vercel dell'aprile 2026 mostra perché questo approccio non è più sufficiente. Secondo le comunicazioni relative alla violazione, gli attaccanti hanno prima compromesso un fornitore AI di terze parti. Hanno poi utilizzato la sua connessione autorizzata per raggiungere l'account Google Workspace di un dipendente Vercel.

L'attacco non seguiva la consueta storia di qualcuno che aggira le difese di accesso di Vercel. La fiducia ha attraversato confini organizzativi tramite un'integrazione che un utente aveva approvato in precedenza.

Le notizie Google spostano l'attenzione dalle password rubate agli accessi ereditati

Il cambiamento importante non è una nuova vulnerabilità di Google, ma un modo più efficace di sfruttare accessi legittimi.

OAuth è un framework di autorizzazione che consente a un'applicazione di accedere a risorse selezionate in un altro servizio. Consente, ad esempio, a uno strumento di pianificazione di leggere un calendario senza ricevere la password Google dell'utente.

Questa separazione offre concreti vantaggi di sicurezza. Gli utenti non devono condividere le credenziali con ogni servizio connesso. Gli amministratori possono inoltre limitare le applicazioni, esaminare gli ambiti richiesti e revocare le autorizzazioni.

Lo stesso modello crea un obiettivo di valore. Un token OAuth rappresenta un permesso che ha già superato un processo di approvazione. Chiunque rubi o controlli quel token può agire tramite l'applicazione approvata, nei limiti degli ambiti concessi.

Il rapporto sui rischi OAuth di Material Security ha esaminato ambienti Google Workspace in produzione e rilevato un'ampia superficie di autorizzazione distribuita. I risultati pubblici citano una mediana di 1.807 connessioni di applicazioni OAuth per azienda.

Il rapporto afferma inoltre che il 47,2 percento delle autorizzazioni osservate non veniva utilizzato da oltre 90 giorni. Tra queste autorizzazioni inattive, 1.526 mantenevano ancora l'accesso completo a Gmail.

Questi dati provengono dal dataset clienti di un fornitore di sicurezza, non da un censimento rappresentativo di tutti i tenant Workspace. Le dimensioni dell'azienda, il settore e il livello di maturità della sicurezza esistente possono influenzare i totali. I risultati evidenziano comunque un problema strutturale: le vecchie autorizzazioni spesso rimangono valide anche quando il loro scopo aziendale scompare.

L'adozione dell'AI accelera questo accumulo. Material ha classificato 356 applicazioni pubbliche nella categoria AI e automazione. Afferma che 325 sono apparse per la prima volta negli ambienti analizzati dopo il 1° gennaio 2024.

Ciò significa che il 91 percento della popolazione osservata di applicazioni AI è arrivato nell'arco di 16 mesi. Secondo quanto riportato, oltre la metà di tali applicazioni disponeva di ambiti sensibili o soggetti a restrizioni.

Un ambito definisce ciò a cui un'applicazione può accedere o che può modificare. Ambiti estesi possono consentire a un'app di leggere email, esaminare contenuti Drive, inviare messaggi o eliminare informazioni.

Le organizzazioni affrontano quindi un difficile problema di classificazione. Una richiesta di accesso a Drive potrebbe supportare un utile assistente di ricerca. La stessa autorizzazione può esporre contratti, documenti strategici, credenziali e dati dei clienti se l'applicazione viene compromessa.

La minaccia non richiede che un'applicazione sia dannosa fin dall'inizio. Un fornitore legittimo può diventare il punto d'ingresso dopo la compromissione di un dispositivo dipendente, un account sviluppatore, una chiave di firma o un ambiente cloud.

Questa possibilità trasforma la normale approvazione delle app in una decisione di supply chain. L'utente vede una schermata di consenso, ma l'organizzazione eredita i futuri fallimenti di sicurezza del fornitore.

Un singolo strumento AI compromesso può attraversare due confini di sicurezza

L'incidente Vercel illustra come un attaccante possa passare attraverso un fornitore AI anziché attaccare direttamente il bersaglio finale.

Vercel ha reso noto un incidente di sicurezza nell'aprile 2026 che ha coinvolto uno strumento AI di terze parti compromesso e l'account Google Workspace di un dipendente. Le informazioni pubbliche hanno identificato quel fornitore come Context.ai.

Secondo le informazioni disponibili, un dipendente Vercel aveva collegato AI Office Suite di Context.ai usando un'identità aziendale. La connessione aveva ricevuto autorizzazioni Google Workspace estese.

Un attore della minaccia ha successivamente ottenuto il controllo di accessi rilevanti detenuti da Context.ai. Secondo quanto riportato, tali accessi fornivano un percorso verso l'account Workspace del dipendente e quindi verso i sistemi interni di Vercel.

La sequenza ha creato due esposizioni di supply chain collegate. Context.ai dipendeva dalle proprie identità dei dipendenti e dalla propria infrastruttura. Vercel, a sua volta, dipendeva dall'integrità dell'applicazione OAuth di Context.ai.

Ricercatori indipendenti hanno attribuito la compromissione iniziale di Context.ai a un'infezione da infostealer. Un infostealer è un malware progettato per raccogliere password, cookie del browser, token e altro materiale di autenticazione.

Le segnalazioni hanno collegato l'infezione a software presentato come exploit per Roblox. Tuttavia, non tutti i dettagli della compromissione iniziale hanno ricevuto conferma indipendente da Vercel.

Ciò che Vercel ha confermato è più rilevante per la pianificazione aziendale. L'autorizzazione esistente di un'applicazione di terze parti ha aiutato l'attaccante a raggiungere l'account Workspace aziendale di un dipendente.

Secondo quanto riportato, l'attaccante ha avuto accesso a variabili d'ambiente non designate come sensibili. Vercel ha consigliato ai clienti coinvolti di verificare l'attività e ruotare le credenziali esposte.

Un resoconto dell'epoca ha riportato che l'attaccante chiedeva un pagamento per i dati sottratti. Vercel ha coinvolto Mandiant, informato le forze dell'ordine e contattato un gruppo limitato di clienti coinvolti.

Vercel ha inoltre dichiarato che le variabili d'ambiente sensibili erano crittografate a riposo e non sono state accessibili. I suoi progetti open source, tra cui Next.js e Turbopack, non sarebbero stati coinvolti.

L'incidente non dovrebbe essere semplificato sostenendo che OAuth stesso abbia fallito. OAuth ha eseguito l'autorizzazione consentita da utenti e amministratori.

Il fallimento è emerso dall'intera catena di fiducia. Un fornitore è stato compromesso, un'applicazione disponeva di accessi estesi e tale accesso raggiungeva una preziosa identità aziendale.

Le difese tradizionali di accesso coprivano solo una parte di questa sequenza. L'attaccante non doveva ripetere la decisione di consenso originaria una volta disponibile un'autorizzazione utilizzabile.

Anche il cambio di password può lasciare intatte alcune autorizzazioni delle applicazioni. Questo rende la risposta più complessa del semplice ripristino delle credenziali e della chiusura delle sessioni attive del browser.

I team devono identificare quali token esistono, quali ambiti detengono e quali applicazioni connesse possono ancora agire. Devono poi revocare l'accesso senza interrompere i flussi di lavoro aziendali necessari.

Questo è il ribaltamento centrale della moderna catena di attacco. L'applicazione progettata per ridurre la condivisione delle password può diventare una via persistente per aggirare le difese incentrate sulle password.

Gli agenti AI rendono meno informativi i consueti record OAuth

Gli agenti AI possono apparire ordinari nei log di autorizzazione, pur comportandosi in modo molto meno prevedibile rispetto alle integrazioni convenzionali.

Un'applicazione tradizionale svolge generalmente un insieme ristretto di funzioni. Un servizio di firma di documenti potrebbe recuperare un file, raccogliere firme e restituire la copia completata.

Il suo comportamento può cambiare, ma gli amministratori possono comunque confrontare le autorizzazioni richieste con uno scopo relativamente stabile. Un accesso eccessivo a Gmail o Calendar dovrebbe apparire sospetto per questo tipo di servizio.

Un agente AI non segue lo stesso modello comportamentale. La sua azione successiva può dipendere da un prompt dell'utente, contenuti recuperati, strumenti disponibili, output del modello e istruzioni fornite da un sistema esterno.

A livello di autorizzazione, queste differenze possono scomparire. Un'autorizzazione di sola lettura a Drive rilasciata a un assistente AI può sembrare identica a quella rilasciata a un'utilità documentale fissa.

L'analisi degli agenti di Material sostiene che i segnali di sicurezza si stiano spostando dalle autorizzazioni verso il comportamento post-autorizzazione. L'identità del fornitore e l'ambito restano utili, ma non possono descrivere pienamente ciò che farà un agente generalista.

Model Context Protocol, comunemente chiamato MCP, può aumentare questa incertezza. MCP è uno standard per collegare sistemi AI a strumenti e fonti di dati esterne.

Un agente connesso tramite MCP potrebbe cercare in Workspace, passare contenuti selezionati a un altro strumento, riassumerli e attivare un'azione successiva. Il flusso di lavoro può attraversare più servizi nell'ambito di una sola richiesta utente.

Questo solleva diverse questioni di sicurezza a cui una schermata di consenso non può rispondere. Gli amministratori devono sapere quali informazioni l'agente ha effettivamente consultato, dove ha inviato tali informazioni e se la sua attività corrispondeva all'intenzione dell'utente.

Il prompt injection aggiunge un ulteriore livello. Il prompt injection si verifica quando contenuti non attendibili manipolano le istruzioni o l'uso degli strumenti di un sistema AI.

Un agente potrebbe incontrare istruzioni ostili all'interno di un'email, un documento condiviso, una voce di calendario o una pagina web. Se tratta quel contenuto come un'istruzione, le sue autorizzazioni legittime possono diventare il meccanismo di un'attività dannosa.

Questo rischio differisce dal malware classico. Non è necessariamente eseguito alcun file sul dispositivo dell'utente e il fornitore AI potrebbe non essere compromesso.

Il sistema può invece utilizzare impropriamente strumenti validi durante l'elaborazione di contenuti avversari. I controlli di sicurezza devono distinguere l'automazione autorizzata dall'automazione autorizzata che si comporta pericolosamente.

Questo non significa che ogni agente connesso debba essere sottoposto a un monitoraggio illimitato di prompt o contenuti privati. Una sorveglianza eccessiva crea rischi propri in materia di privacy, conformità e governance.

Significa che le organizzazioni necessitano di evidenze a livello di attività. Segnali utili includono un volume di download insolito, nuovi comportamenti di inoltro, una rapida enumerazione delle caselle di posta, combinazioni di servizi inattese e accessi al di fuori del normale schema di un utente.

L'AI aumenta anche il numero di connessioni che richiedono revisione. I dipendenti possono adottare assistenti direttamente, spesso prima che i team di procurement o sicurezza li valutino.

Un marchio riconoscibile non garantisce che l'applicazione mostrata nella schermata di consenso appartenga a quel marchio. Il rapporto di Material descrive un'applicazione denominata “gamma.com.ai” che assomigliava al legittimo servizio di presentazioni Gamma.

Material afferma che l'editore non era collegato a Gamma e cercava accesso in diversi ambienti cliente. Il rapporto presenta il caso come impersonificazione OAuth, in cui la familiarità visiva favorisce l'approvazione.

La schermata di autorizzazione mostrava comunque un dominio e le autorizzazioni richieste. La decisione umana è fallita perché un nome familiare ha ridotto il livello di controllo.

Questo percorso di attacco non richiede una pagina di password contraffatta. Induce l'utente a concedere un'autorizzazione legittima alla parte sbagliata.

L'MFA Protegge l'Accesso, Non Ogni Decisione Successiva

L'autenticazione a più fattori resta essenziale, ma non può convalidare ogni token, applicazione e azione del browser che segue un accesso riuscito.

L'MFA blocca molti attacchi basati sulle password perché una password rubata da sola non è sufficiente. I metodi resistenti al phishing, incluse passkey e chiavi di sicurezza hardware, offrono una protezione più solida contro la ritrasmissione in tempo reale delle credenziali.

Google ha ampliato il supporto per le passkey e i controlli amministrativi in Workspace. Queste misure riducono l'esposizione al tradizionale takeover degli account.

Tuttavia, il consenso OAuth avviene spesso dopo l'autenticazione. Un utente accede correttamente, completa l'MFA e poi approva un'applicazione.

Il token risultante registra una decisione autorizzata. Il riutilizzo di quel token potrebbe non attivare nuovamente la stessa verifica di autenticazione.

Il furto di sessione del browser crea una lacuna correlata. Un cookie di sessione è un dato che consente a un servizio di riconoscere un browser precedentemente autenticato.

Un aggressore che ruba un cookie valido può ereditare quello stato autenticato. Google documenta le procedure di risposta ai cookie di sessione per indagare sulle sessioni sospette e forzare la disconnessione.

I token delle applicazioni e le sessioni del browser non sono identici. Entrambi dimostrano perché l'evento di accesso non può definire l'intero perimetro di sicurezza.

Gli aggressori usano anche il phishing adversary-in-the-middle, noto come AiTM, per ritrasmettere credenziali e secondi fattori attraverso una sessione contraffatta attiva. Questa tecnica può catturare la sessione autenticata creata dopo il completamento dell'MFA.

L'autenticazione resistente al phishing aumenta la difficoltà perché le credenziali sono legate crittograficamente al sito legittimo. Le organizzazioni dovrebbero comunque presumere che malware, applicazioni compromesse e token rubati possano creare altri percorsi.

Microsoft ha documentato l'abuso del reindirizzamento OAuth che coinvolge URL di provider di identità affidabili. Le campagne manipolano parametri di protocollo o applicazioni connesse per indirizzare le vittime verso destinazioni controllate dagli aggressori.

Il modello più ampio riguarda più di Google. Microsoft 365, Salesforce, le piattaforme di sviluppo cloud e i servizi dati dipendono tutti da token e integrazioni di terze parti.

Diverse campagne importanti hanno preso di mira queste relazioni. Gli incidenti che hanno coinvolto Salesloft Drift hanno mostrato come token di integrazione rubati potessero fornire accesso a valle agli ambienti dei clienti.

Il confronto è importante perché esclude una spiegazione limitata a Google. Il software enterprise opera sempre più come un grafo di fiducia delegata.

I difensori devono mantenere l'MFA ampliando al contempo il proprio modello. L'autenticazione risponde alla domanda se un'identità abbia soddisfatto un requisito di accesso. L'autorizzazione risponde a ciò che quell'identità o la sua applicazione connessa può fare in seguito.

I team di sicurezza devono considerare anche la persistenza. Revocare una sessione del browser non revoca necessariamente un'autorizzazione dell'applicazione. La sospensione di un utente può lasciare accessi connessi che richiedono un'indagine separata.

I piani di risposta agli incidenti dovrebbero elencare esplicitamente queste azioni. Altrimenti, un team potrebbe reimpostare le password, chiudere le sessioni e concludere erroneamente che l'accesso sia terminato.

Questa risposta ampliata è impegnativa dal punto di vista operativo. Le grandi organizzazioni possono avere migliaia di autorizzazioni, account di servizio, permessi delegati e flussi di automazione.

Revocare tutto non è una politica credibile nel lungo periodo. Interromperebbe la produttività e incoraggerebbe i dipendenti a trovare alternative meno visibili.

L'obiettivo difendibile è una fiducia selettiva. I team dovrebbero identificare le applicazioni, verificare gli editori, limitare gli ambiti, monitorare il comportamento e rimuovere l'accesso quando il suo scopo scade.

Il Compromesso È tra AI Utile e Fiducia Non Misurata

Bloccare ogni integrazione ridurrebbe un rischio distruggendo i flussi di lavoro connessi che rendono utile l'AI aziendale.

Gli assistenti AI hanno bisogno di contesto per andare oltre risposte generiche. Un assistente che redige un aggiornamento per un cliente potrebbe aver bisogno di email, note delle riunioni, cronologia dell'account e documenti di progetto.

Limitarlo a una finestra di chat vuota riduce l'esposizione. Ma rimuove anche gran parte del valore che i dipendenti si aspettano dall'AI aziendale.

Le organizzazioni si trovano quindi di fronte a un compromesso, non a una decisione di sicurezza binaria. Devono consentire accessi utili senza permettere che le autorizzazioni si accumulino indefinitamente.

Il primo passo è la visibilità. Gli amministratori hanno bisogno di un inventario a livello di dominio di applicazioni, autorizzazioni, utenti, ambiti, editori e attività recenti.

L'inventario dovrebbe distinguere le applicazioni pubbliche di terze parti dagli strumenti interni. Dovrebbe inoltre identificare le autorizzazioni legate a ex dipendenti, collaboratori esterni, account di test e progetti inattivi.

Esaminare soltanto i nomi non è sufficiente. I team dovrebbero verificare l'identità dell'editore, i domini dell'applicazione, le destinazioni di reindirizzamento, gli ambiti richiesti e se lo strumento ha completato le pertinenti verifiche della piattaforma.

La verifica non è una garanzia permanente. Un fornitore legittimo può comunque subire una violazione, essere acquisito o essere modificato dopo l'approvazione.

Il controllo degli ambiti fornisce un ulteriore livello. Le applicazioni dovrebbero ricevere i permessi minimi necessari per un flusso di lavoro definito.

Un servizio di trascrizione non dovrebbe ricevere accesso completo a Gmail senza una chiara esigenza. Un assistente che cerca solo in cartelle Drive selezionate non dovrebbe ricevere automaticamente accesso a ogni file.

Anche il tempo conta. L'accesso concesso per una valutazione dovrebbe scadere al termine di tale valutazione. Le organizzazioni dovrebbero evitare di trasformare esperimenti temporanei in credenziali permanenti.

Gli amministratori Google possono limitare l'accesso delle applicazioni di terze parti e classificare i servizi come affidabili, limitati o bloccati. Questi controlli funzionano meglio quando sono supportati da un processo di approvazione in grado di procedere alla velocità dei dipendenti.

Un sistema di revisione che richiede settimane spingerà l'adozione nell'ombra. Un sistema che approva nomi riconoscibili senza esaminare i permessi produrrà una proliferazione delle autorizzazioni.

Il monitoraggio comportamentale affronta ciò che l'approvazione non può prevedere. I team dovrebbero rilevare quando un'applicazione legge improvvisamente molti più dati, accede a utenti insoliti o inizia a eseguire nuove azioni.

Questo è particolarmente importante per gli agenti AI. Le loro capacità generaliste rendono le descrizioni statiche indicatori più deboli del comportamento previsto.

La ricerca della Cloud Security Alliance inquadra le catene OAuth AI SaaS come una superficie di attacco sistemica per l'impresa. La sua analisi della catena di fiducia collega l'incidente Context.ai ad altre compromissioni di token a valle.

Il rapporto sostiene che le imprese dovrebbero trattare la gestione del ciclo di vita OAuth come una funzione di sicurezza primaria. Ciò include emissione, inventario, monitoraggio, rotazione, revoca e risposta agli incidenti.

I team di sicurezza dovrebbero comunque trattare con cautela le statistiche dei fornitori. Material vende prodotti di sicurezza per Workspace e la sua ricerca sostiene il problema affrontato dalla sua piattaforma.

Il suo dataset offre comunque domande verificabili per qualsiasi organizzazione. Gli amministratori possono misurare il proprio numero di autorizzazioni, la quota inattiva, gli ambiti sensibili, la crescita delle applicazioni AI e le lacune nella revoca.

La risposta più solida è costituita da prove raccolte nel tenant dell'azienda stessa. Un audit locale può confermare se il modello riportato si applica e dove si trovano le connessioni a rischio più elevato.

Cosa Dovrebbero Monitorare Ora i Team di Sicurezza

Tre segnali mostreranno se la difesa di Workspace si sta adattando all'autorizzazione nell'era dell'AI o se sta semplicemente aggiungendo un'altra dashboard.

Il primo segnale è una migliore visibilità post-autorizzazione da parte di Google e dei fornitori di sicurezza. Gli amministratori hanno bisogno di qualcosa in più di un record che mostri che un'applicazione ha ricevuto un determinato ambito.

Hanno bisogno di risposte utilizzabili sull'attività successiva dell'applicazione. Ciò include quali risorse ha consultato, come è cambiato il suo modello e se i dati si sono spostati tra servizi connessi.

Google offre già funzionalità di indagine e controllo degli accessi, ma la copertura dipende dall'edizione, dalla configurazione e dalla telemetria disponibile. Il test chiave è capire se i team possano tracciare le azioni di un agente AI senza assemblare prove provenienti da diverse console non correlate.

Se l'indagine a livello di attività diventa più chiara, il modello di sicurezza qui descritto ottiene un sostegno pratico. Se i log restano incentrati sul consenso iniziale, i difensori continueranno a giudicare agenti dinamici attraverso metadati statici.

Il secondo segnale è il modo in cui i fornitori di AI restringono e gestiscono i permessi. I prodotti maturi dovrebbero spiegare perché ogni ambito è necessario e offrire flussi di lavoro utili con impronte di autorizzazione più ridotte.

Dovrebbero supportare fonti dati selettive, accessi di breve durata quando pratico, revoca rapida e registri trasparenti dell'attività degli strumenti. Dovrebbero inoltre separare l'automazione rivolta agli utenti dalle azioni amministrative ad alto rischio.

Ambiti predefiniti troppo ampi indebolirebbero le affermazioni secondo cui il mercato sta imparando dagli incidenti recenti. Controlli più granulari mostrerebbero che i fornitori riconoscono l'autorizzazione come una questione di progettazione del prodotto.

Il terzo segnale è se le organizzazioni misurano l'esposizione OAuth durante le normali attività di sicurezza. Una revisione annuale non può tenere il passo con la velocità con cui i dipendenti adottano strumenti AI.

I team dovrebbero monitorare autorizzazioni inattive, nuovi editori, ambiti sensibili, utenti dismessi e cambiamenti improvvisi nel comportamento delle applicazioni. Queste misure dovrebbero comparire nelle revisioni ricorrenti dell'identità e della sicurezza cloud.

Le esercitazioni sugli incidenti dovrebbero anche testare la compromissione di un token di terze parti. Chi risponde deve sapere come identificare gli utenti interessati, revocare le autorizzazioni, chiudere le sessioni, ruotare i segreti a valle e conservare le prove.

Le ultime notizie su Google non dimostrano che Workspace sia diventato intrinsecamente insicuro. Mostrano che le ipotesi di sicurezza costruite attorno alla protezione dell'accesso non coprono più l'intero percorso verso i dati aziendali.

Password e MFA restano necessarie. Semplicemente, non sono il controllo finale una volta che i dipendenti autorizzano le applicazioni ad agire su email, file, calendari e sistemi connessi.

La domanda più difficile è se le organizzazioni possano vedere e governare tale attività delegata senza bloccare il lavoro utile. I responsabili della sicurezza dovrebbero iniziare con una misurazione diretta: quante applicazioni connesse possono accedere ai dati aziendali in questo momento e chi è ancora responsabile di ogni decisione?