Usi agenti con Gmail o Drive? Verifica il client OAuth prima dell'11 novembre

Che cosa cambia dall'11 novembre

La distinzione più utile è il protocollo. Google specifica che il requisito riguarda i server MCP; le applicazioni che chiamano direttamente le API REST di Workspace non sono interessate da questo cambiamento. Prima di modificare un'integrazione, accerta quale percorso usa: un connettore può parlare MCP anche se il risultato finale arriva da Gmail o Drive, mentre un'app tradizionale può interrogare le API REST senza passare dai nuovi server MCP.

Censisci connessioni e client prima di toccare le credenziali

Prepara una tabella per ogni agente o integrazione: nome, servizio Workspace consultato, ambiente, progetto Google Cloud, ID del client OAuth, scope richiesti, proprietario tecnico e frequenza d'uso. Parti dai log e dalla documentazione dei connettori, poi confronta l'inventario con i client OAuth della console. Non copiare token o segreti nel foglio: bastano identificativi e riferimenti al vault autorizzato.

Cerca in particolare un client condiviso da software con scopi diversi. Le note Google avvertono che un client usato sia per agenti sia per altre funzionalità deve essere separato. Un cambio sull'applicazione condivisa può influire su flussi di accesso non collegati all'agente; una nuova registrazione dedicata rende invece più facile concedere solo gli scope necessari, verificare l'origine delle chiamate e ritirare l'accesso senza coinvolgere altri prodotti.

Dichiara l'uso previsto e prova il flusso end-to-end

Per i client destinati agli agenti, segui la procedura corrente della console Google Cloud e imposta la dichiarazione prevista per un client AI agent. Le etichette dell'interfaccia e i requisiti di pubblicazione possono cambiare durante una Developer Preview: consulta la guida ufficiale immediatamente prima dell'intervento. Verifica anche consenso, schermata OAuth, utenti di test e scope, senza ampliare i permessi solo per far passare una richiesta.

In un ambiente di prova esegui un accesso nuovo, poi una lettura controllata da Gmail o Drive con dati non sensibili. Verifica che l'agente riceva soltanto le informazioni autorizzate, che un utente non autorizzato venga respinto e che i log mostrino il client atteso. Ripeti per ciascun servizio e con un token rinnovato: un test con sessione già attiva potrebbe non attraversare il percorso OAuth da controllare.

Pianifica la migrazione prima della data limite

Una volta collaudati i client dedicati, aggiorna un'integrazione alla volta e registra risultato, ora, responsabile e possibilità di rollback. Monitora errori di autenticazione e richieste negate; se un client resta condiviso o il proprietario non è identificabile, non cambiarlo per supposizione: isola il connettore, chiarisci l'uso e programma una prova. La data indicata è l'11 novembre, quindi l'obiettivo è completare test e verifica prima, non il giorno stesso.

Se un flusso fallisce, torna alla configurazione precedente solo quando è ancora compatibile e sicura; altrimenti sospendi l'agente, non allargare gli scope e non riutilizzare credenziali personali. Aggiorna il runbook con il client corretto e un contatto responsabile. Questo approccio mantiene separati agenti, applicazioni normali e chiamate REST, riducendo sia l'interruzione sia il rischio di concedere accessi eccessivi.