Come vedere quali strumenti di AI hanno accesso al vostro Google Workspace
Potete vedere ogni strumento di AI con accesso OAuth al vostro Google Workspace dalla console di amministrazione, in Security → Access and data control → API controls → App access control. Elenca ogni app di terze parti autorizzata nel vostro dominio — inclusi assistenti AI, estensioni del browser e bot per prendere appunti alle riunioni — insieme ai dati Google a cui ciascuna è stata autorizzata ad accedere.
Questa guida illustra questo percorso, cosa mostra effettivamente la console, dove si ferma e come mantenere l'elenco aggiornato una volta ottenuto.
Dove trovo l'accesso delle app di terze parti nella console di amministrazione Google?
- Accedete a admin.google.com come super amministratore o come amministratore con il privilegio Services.
- Andate su Menu → Security → Access and data control → API controls.
- Fate clic su Manage App Access (indicato anche come App access control in alcune versioni della console).
Vi troverete di fronte a un elenco suddiviso in Configured apps (le app per cui la vostra organizzazione ha impostato esplicitamente un livello di accesso) e Accessed apps (ogni app attualmente in uso, che l'abbiate configurata oppure no). Per ogni app potete vedere:
- Il nome dell'app, l'editore e l'OAuth client ID.
- Se dispone del badge di verifica di Google.
- I singoli scope di servizio Google richiesti — Drive, Gmail, Calendar, Admin Directory, e così via — espandibili per ogni app.
- Quanti utenti del vostro dominio l'hanno autorizzata.
- Il livello di accesso che potete impostare: Trusted, Limited, Specific Google data o Blocked.
Potete anche esportare l'elenco completo in formato CSV e applicare livelli di accesso diversi a diverse unità organizzative anziché all'intero dominio in blocco.
Come faccio a capire quali di queste app sono strumenti di AI?
La console di Google non etichetta nulla come "AI" — elenca ogni app connessa via OAuth allo stesso modo, che si tratti di un componente aggiuntivo per fogli di calcolo o di un assistente basato su un modello linguistico di grandi dimensioni. In pratica, gli strumenti di AI compaiono sotto nomi come quello di un fornitore di AI diretto (OpenAI, Anthropic, Perplexity), un bot per appunti di riunione (Otter.ai, Fireflies, Fathom), un assistente di scrittura (Grammarly, Jasper), oppure un componente aggiuntivo più specifico ("GPT for Sheets and Docs", "AI Email Writer") il cui nome dell'editore non lascia intuire nulla sulla sua funzione. Riconoscerli è un esercizio manuale di riconoscimento di schemi: scorrete i nomi delle app e degli editori, e controllate gli scope richiesti — un'app che chiede drive.readonly o gmail.readonly accanto a un nome che non riconoscete merita un'occhiata più attenta, indipendentemente dalla categoria.
Come faccio a verificare quali strumenti di AI ha autorizzato una persona specifica?
La vista a livello di dominio descritta sopra vi dice che un'app ha degli utenti; non vi dice *chi*, né quando l'ha autorizzata. Per questo:
- Andate su Menu → Directory → Users e aprite l'account della persona.
- Aprite la scheda Security.
- Scorrete fino a Connected applications.
Questa sezione elenca ogni app di terze parti che questo specifico utente ha autorizzato, il livello di accesso (gli scope che può utilizzare) e la data di autorizzazione. Un amministratore con il privilegio User Security Management può revocare direttamente da quella pagina una qualsiasi di queste autorizzazioni. Questo è l'unico punto in cui la console mostra *quando* un'app è stata autorizzata — ma significa controllare una persona alla volta, senza esportazione in blocco e senza possibilità di filtrare per "solo strumenti di AI".
Quali sono i reali limiti di fare questo controllo manualmente?
La schermata App access control a livello di dominio aggrega i conteggi ma perde il dettaglio per singolo utente; la schermata Connected Applications per singolo utente ha il dettaglio ma non una vista d'insieme. Nessuna delle due vi dice:
- Se l'accesso viene ancora utilizzato, oppure è stato concesso una volta e poi dimenticato.
- Cosa ha effettivamente fatto l'app con i dati a cui può accedere — la console mostra a cosa *può* accedere, non a cosa *ha* effettivamente avuto accesso.
- Come è cambiato il quadro nel tempo, poiché non esiste una cronologia storica delle autorizzazioni concesse o degli scope ampliati.
- Quali delle app elencate siano strumenti di AI, a meno che non riconosciate personalmente ogni nome di fornitore.
Per un Workspace con una manciata di app connesse, esaminare manualmente entrambe le schermate è realistico. Oltre poche decine di app e alcune centinaia di utenti, mantenere l'elenco aggiornato smette di essere un'attività una tantum e diventa un'attività ricorrente — le stesse informazioni, ricontrollate indefinitamente. Ed entrambe le schermate richiedono un ruolo di amministratore con il privilegio adeguato (Services per la vista a livello di dominio, User Security Management per quella per singolo utente) — un Workspace con più amministratori ha comunque bisogno che una persona controlli entrambe regolarmente, non è un compito che ricade naturalmente su chiunque se ne accorga per caso.
Cosa non può dirvi la vista manuale, e come risponde 8200.dev a questa domanda?
Il percorso manuale risponde a *cosa può accedere ai dati*. Non risponde a *chi lo ha usato, quando, e se è ancora necessario* — le domande che in realtà determinano se un'app debba mantenere il proprio accesso. Agent Guard di 8200.dev inventaria ogni agente AI e ogni app connessa via OAuth in tutte le vostre fonti connesse in un'unica vista aggiornata continuamente, assegna a ciascuna un punteggio di rischio e spiega il risultato in un linguaggio semplice invece che come una stringa di scope. La scoperta (discovery) è di sola lettura: la connessione a Google Workspace utilizza uno scope di sola lettura sui metadati di Drive, e l'inventario più approfondito delle app OAuth mostrato sopra è disponibile una volta che un'organizzazione attiva l'auditing delle app OAuth, che riautorizza con gli scope aggiuntivi di sola lettura dell'Admin SDK richiesti da Google per quella vista specifica — nulla di tutto ciò modifica l'accesso autonomamente; ogni azione resta una raccomandazione finché l'organizzazione non decide di agire.
Consultate l'elenco completo dei connettori per scoprire come questo si estenda oltre Google Workspace a Microsoft 365, Slack, GitHub e gli stessi fornitori di AI.
Guide correlate
- SaaS Security Posture Management: cos'è e cosa verificare
Cosa verifica davvero la SaaS security posture management (SSPM), come controllarla manualmente app per app, e perché deve essere continua, non un audit una tantum.
- Come verificare le app OAuth di terze parti su Slack, GitHub e Microsoft 365
Le schermate amministrative esatte per verificare le app OAuth autorizzate in Slack, GitHub e Microsoft 365, e cosa ciascuna piattaforma può e non può mostrarvi.
- Come vedere quali app hanno accesso al vostro Microsoft 365
Il percorso esatto in Microsoft Entra per elencare tutte le app con accesso al tenant Microsoft 365 e la differenza tra consenso admin e utente.