E dal 12 novembre non potrai più cambiare idea
Google vuole sapere se il tuo client OAuth è un agente AI
Qualche giorno fa mi è arrivata una mail da Google con un oggetto di quelli che non lasciano tranquilli: “Action Required”. Dentro, l’elenco dei miei progetti Google Cloud “impattati”. Uno solo, per fortuna, ma è quello dove gira il backend dei miei add-on.
La prima reazione è stata: cosa ho rotto? Niente, in realtà. Ma la questione merita qualche riga, perché le date sono strette e c’è un dettaglio che rende l’errore difficile da correggere.
Cosa sta succedendo
Google sta portando i server MCP (Model Context Protocol) su Gmail, Drive, Calendar, Docs, Sheets e compagnia. In pratica, agenti AI esterni potranno lavorare sui dati Workspace degli utenti attraverso un protocollo standard. Comodo per chi sviluppa, un po’ meno per chi amministra un dominio aziendale e vuole capire chi sta toccando cosa.
La risposta di Google è un nuovo flag sui client OAuth: is_agentic. Serve a distinguere il traffico di un agente da quello di un’applicazione tradizionale.
Le date da segnarsi:
- 12 ottobre 2026: in Google Cloud Console (Google Auth Platform, sezione Clients) si può modificare un client esistente e marcarlo come usato da un agente AI.
- 11 novembre 2026: i server MCP di Workspace rifiutano le richieste dei client non marcati.
- 12 novembre 2026: l’impostazione diventa permanente. Se vuoi cambiarla, devi creare un nuovo Client ID e aggiornare tutte le configurazioni.
Quest’ultimo punto è quello che conta davvero. Un mese di tempo, poi la scelta è bloccata.
Devo fare qualcosa?
Dipende da cosa fa la tua applicazione. Se chiami le normali API REST (Sheets API, Drive API, Gmail API) da codice tuo, deterministico, non sei un agente e non devi toccare nulla. È il caso della stragrande maggioranza degli script e degli add-on.
Il mio caso era esattamente questo. Il progetto segnalato ospita il backend di un add-on per Google Sheets che usa anche l’AI, ma in modo “classico”: il codice legge i dati del foglio, li manda al modello, riceve un testo. Il token OAuth dell’utente lo usa il mio codice, non il modello. Quindi niente flag.
E qui arriva la parte che mi ha fatto riflettere: marcare il client come agentic “per sicurezza” sarebbe stato un errore. I client agentic finiscono sotto controlli di sicurezza dedicati, che gli amministratori Workspace possono restringere o bloccare. Se lo fai sul client principale di un’app usata da migliaia di persone, rischi che un admin prudente spenga tutto in un clic. E dal 12 novembre non torni indietro.
Il caso più ambiguo
Diverso il discorso se il modello decide da solo quali chiamate fare alle API Google, con tool use che esegue richieste su Drive o Gmail usando il token dell’utente. Google è chiara: va marcato come agentic anche un agente che oggi usa solo le REST API e non ancora gli MCP.
La regola che suggeriscono, e che trovo sensata, è separare. Se la tua app ha sia funzioni “umane” sia flussi agentici, usa due client OAuth distinti. Il flag non dà scope in più e non salta il consenso dell’utente: serve solo a isolare il traffico dell’agente, così chi amministra può governarlo senza penalizzare il resto.
E Apps Script?
C’è un problema concreto, segnalato da Romain Vialard e ripreso da Martin Hawksey su AppsScriptPulse: il client OAuth gestito automaticamente da Apps Script non è modificabile in Cloud Console, quindi non si può marcare come agentic. L’unica strada, per ora, è un progetto GCP standard con un Client ID creato da te, gestito tramite la libreria OAuth2 per Apps Script. Non l’ho ancora provato, quindi lo riporto con cautela.
Cosa farei adesso
- Controlla la casella di posta: la mail di Google elenca i progetti coinvolti.
- Per ogni client OAuth chiediti una cosa sola: chi usa il token, il mio codice o un modello che decide in autonomia?
- Se la risposta è “il mio codice”, lascia tutto com’è.
- Se è “il modello”, crea un client separato e marcalo, prima dell’11 novembre.
- Verifica le impostazioni entrando direttamente nella console, non dai link della mail.
La direzione è chiara: gli agenti AI dentro Workspace avranno un’identità propria, e gli admin vorranno vederla. Meglio arrivarci con i client già in ordine.
Fonti: documentazione Google “Manage OAuth Clients” e l’articolo di Martin Hawksey su AppsScriptPulse.

!

Non ci sono commenti
Nessuno ha ancora commentato questo articolo, fallo tu per primo!
scrivi un commento