Google Workspace MCP 收緊 OAuth：代理標示期限過後，哪些連線需要換 client？
Workspace MCP 代理身分限制生效，解析 11/11 與 11/12 期限、新 OAuth client、服務帳號及 Apps Script 差異，保留一般功能運作。
原本能讀信或查日曆的 AI 代理，突然連不上 Google Workspace，原因不一定是密碼過期。用來代表應用程式的 OAuth client，也開始需要明確標示代理用途。
Google 在 2026 年 10 月 12 日預告這項調整，本週跨過兩個期限：11 月 11 日起拒絕未標示代理用途的 MCP 請求，11 月 12 日仍未標示的既有 client，之後需要以新的代理 client 接續。
OAuth 是讓使用者授權應用程式存取資料的機制，client 則是這個應用程式的身分設定。新要求是在設定中表明，它是否替 AI 代理工作。
這項規則針對 Workspace MCP 連線，沒有讓所有 Google REST API 一起失效。REST API 是程式直接向服務發出請求的介面。一般互動功能與代理若共用身分，官方反而要求分開處理。
完成標示也不會自動取得更多權限。使用者同意、資料範圍與應用驗證仍然有效，服務帳號及 Apps Script 另有各自的做法。
因此，維護既有整合的團隊應先找出失敗請求用的是哪一個 client，再決定建立哪種身分。先把作用範圍分清，才不會連原本正常的功能一起改動。
Workspace MCP 為何要另標示代理身分？
Workspace MCP 讓 AI 應用透過一組工具存取辦公服務。MCP 是模型脈絡協定，用來描述工具與交換呼叫結果，讓代理知道可以做什麼，再把使用者工作接到相應服務。
同一個產品也可能提供傳統整合。例如使用者自己按下按鈕查行程，和代理在連續工作中自主決定查行程，背後都可能存取 Calendar，卻有不同的操作方式與管理需求。
Google 這次要求標示 OAuth client 是否用於 AI 代理，讓身分設定能反映這項用途。設定名稱是「Use this client for an AI-powered agent」，位於 Google Auth Platform 的 Clients 頁面。
這是一項用途標記。它沒有替應用程式多加讀信、改檔或發送內容的權限，原本需要的使用者授權與資料範圍依然存在，企業管理員的相關政策也繼續生效。
依Google Workspace 完整更新紀錄，公告列出 Chat、Gmail、Calendar、Docs、Drive、Sheets 與 Slides 的 MCP 連線要求。各產品的開放條件，仍需按自己的開發者預覽資格確認。
對維護者而言，第一步是辨認應用使用 MCP 還是一般 REST API。官方明確表示，只使用這類介面的非代理整合不受本次改動影響。
如果沒有先分清呼叫路徑，便可能把某一個代理 client 的設定問題，誤判成整間公司的 Workspace 授權全部失效。找出實際失敗的身分，才有辦法縮小修復範圍。
兩個期限已過，既有 client 應如何處理？
這次變動包含預告與執行兩個階段。10 月 12 日公告讓開發者提前調整，11 月期限則決定既有連線是否繼續被接受，因此閱讀先前教學時，需要確認步驟適用的時間。
官方列出的第一個時間點是 11 月 11 日。從這一天起，Workspace MCP 伺服器會拒絕未標示代理用途之 OAuth client 的請求，代表只取得有效 token 仍可能不足以完成連線。
第二個時間點是 11 月 12 日。到這一天仍未標示的 client，會維持非代理身分，之後若要使用 MCP，需要建立新的 client，標示代理用途，再讓應用改用新的設定。
截至 2026 年 11 月 13 日查核，這兩個時間點均已跨過。維護者若正在處理未標示的舊 client，應依公告的新 client 路徑規劃，不能沿用截止前「補勾選即可」的舊步驟。
換身分設定也要一起檢查應用如何取得授權。程式若仍使用舊 client 的識別資訊或舊授權結果，就算新設定已建立，實際請求仍可能沿舊路徑送出。
因此，修復時需對照應用配置、授權流程及執行紀錄，確認發出 MCP 請求的確實是新身分。這是檢查身分一致性，無需把任何使用者密碼放進模型提示詞。
官方文件的一般設定說明可能仍介紹可修改既有 client 的情境，讀者應把它和這次明確期限一起看。對錯過標示分界的舊 client，更新紀錄已給出建立新身分的要求。
這個時間差也解釋了為何先前可用的整合可能突然失敗。服務與使用者都沒改密碼，平台開始執行用途限制，仍會讓特定請求不再被接受。
一般功能與代理共用 client，要拆開哪一段？
如果同一個 OAuth client 同時服務一般互動功能和 AI 代理，官方要求建立獨立的代理 client，只把新的身分標示為 agentic，原有身分留給非代理功能使用。
因為身分已分開，管理政策就能對應實際用途。使用者親自操作的功能可以保留原來路徑，代理工作則透過另外的身分管理，避免修復時擴大影響。
例如一套應用同時有行事曆查詢按鈕與自動安排工作的代理，團隊要先追蹤兩者各自如何取得授權。這是說明架構的假設情境，實際分法仍需依自己的請求紀錄確認。
代理 client 建立後，也不代表能拿到原 client 的全部資料權限。應用仍需依需要提出適當授權要求，使用者與企業管理設定也可能需要重新確認，才形成可使用的存取路徑。
因此，搬移時應保留一份功能與 client 對應紀錄，並分別驗證一般功能與代理工作。若只測代理恢復，卻把普通按鈕改壞，就沒有完成官方希望的用途分離。
Google 的 OAuth client 管理說明亦指出，代理設定不會替 client 增加額外資料存取權限。權限有沒有變更，應看具體要求的範圍與使用者授權，而非勾選名稱本身。
這也意味著「已標記代理」無法作為安全驗證的替代。它讓平台知道身分用途，應用程式仍得決定代理能讀哪些資料、何時需要使用者介入，以及哪些操作完全不提供。
服務帳號與 Apps Script，不能套用同一個勾選步驟
服務帳號是供程式使用的身分，和一般使用者互動授權的 OAuth client 有不同管理方式。企業也可能由管理員設定網域委派，讓服務帳號在明確授權下代表組織使用者。
依官方 Gmail MCP 設定文件，網域委派的服務帳號不在 Auth Platform 的 Clients 中以相同方式管理，因此不需要套用同一個代理勾選項目。
這個例外處理的是身分機制差異。它沒有替服務帳號免除企業管理員對資料範圍的授權，也不代表可以利用服務帳號繞過敏感操作原有的確認要求。
Apps Script 則有另一個容易混淆的地方。它的預設受管 OAuth client 無法依相同方式標示，即使綁定標準 Cloud 專案，也不能假設預設取得的 token 已符合代理身分要求。
官方提供的路徑，是建立自行管理的 OAuth client，並透過相應的授權程式庫取得 token。不能只沿用 ScriptApp.getOAuthToken，就認定請求已改成新代理 client。
只有使用 MCP 的相關腳本需要檢查這條路徑。原本透過其他介面運作、與代理無關的 Apps Script，不能因為看到期限就一律要求更換身分設定。
因此，排查表應先分辨互動式 OAuth、服務帳號網域委派與 Apps Script 受管身分。三者的憑證取得方式不同，若把同一組操作套用所有整合，會增加不必要的改動。
用途標示與重新登入，是不同層次的問題
代理用途標示解決的是「這個應用身分能否呼叫 MCP」。使用者反覆被要求重新登入，則可能涉及 token 的有效期限與更新方式，兩者不宜只憑錯誤畫面混在一起。
存取 token 通常只在一定時間內有效。更新 token 則讓符合條件的應用在原授權範圍內取得新的存取憑證，因此能避免每次期限到就重新要求使用者走完整登入流程。
Gmail MCP 文件提醒，取得離線存取時需要正確的 OAuth 參數，例如 Google 使用的 access_type=offline。只設定另一套規格中的 offline_access 字樣，未必得到預期結果。
如果應用曾被授權過，是否取得新的更新 token，還可能與同意流程參數有關。應按照官方文件核對自己使用的流程，不應把使用者的密碼或完整憑證交給代理反覆嘗試。
這種分層排查能減少錯修。確認請求來自正確代理 client，再檢查授權範圍、token 更新與企業政策，比一開始就刪掉所有授權、重建整套整合更容易定位原因。
身分通過後，內容安全仍需另管。Google 的Workspace MCP 安全說明提到提示與回應檢查，並提醒記錄完整內容可能帶來敏感資料風險。
若搭配其他檢查服務，也應確認服務地區與資料路徑。用途標記不會自動處理跨區傳輸或資料保留，這些設定需要和組織政策一起確認，才能判斷整條流程是否符合需要。
恢復連線後，還要驗證工具做了哪些事
連線恢復只表示身分通過了某一層檢查。對實際工作而言，團隊仍要確認工具取得的資料與使用者要求一致，以及工作完成後留下的結果是否正確。
以 Gmail MCP 文件列出的能力為例，搜尋郵件、讀取討論串與建立草稿，是不同的操作。應用只需要整理摘要時，就沒有理由因換了代理 client 而順便增加其他操作範圍。
建立草稿也只會產生供後續處理的內容，不能直接稱為已把信寄出。驗收時應按工具實際完成的行為核對，避免代理回覆一句「完成」，使用者卻誤以為郵件已送達。
如果工具要求使用者確認，應保留相應互動。官方對部分敏感操作提供確認流程，服務帳號例外或代理用途標記，都不能被當成自動略過確認的依據。
團隊可以先用不含敏感內容的測試工作，分別檢查讀取、建立草稿與拒絕越權要求。這些工作能幫助確認身分切換是否符合預期，本文沒有替任何實際帳號執行授權或寄信。
比較前後紀錄時，也應注意多 client 環境的區分。一般使用者操作與代理請求若仍混成同一個來源，之後告警或查詢問題時，便難以看出受影響的到底是哪一條路徑。
完成用途分離的實際成果，是身分、工具範圍與紀錄能一一對上。這能讓後續調整政策時只影響需要變更的功能，也讓使用者知道自己授權了哪一類工作。
對開發團隊而言，保存設定變更與測試結果亦有助交接。下次遇到連線失敗，維護者能從既有對應關係繼續排查，減少再次把全部 Workspace 整合當成同一個問題的機會。
Workspace MCP OAuth 常見問題
11 月 12 日之後，還能直接標示原來的 client 嗎？
更新紀錄指出，期限前仍未標示的既有 client 會維持非代理身分，之後使用 MCP 需要建立新的代理 client。處理時應以這項明確時間要求對照一般設定文件，避免沿用截止前流程。
勾選代理用途會讓 AI 讀取全部信件嗎？
因為用途標記本身不增加權限，存取資料仍須另外授權。實際資料存取仍受授權範圍、使用者同意與管理員政策限制，應用也需要限制工具用途，不能只以 client 已標示作為放行依據。
一般 Workspace REST API 也受到影響嗎？
公告明確排除只使用 REST API 的非代理整合。若產品同時有一般功能與 MCP 代理，應分開追蹤身分，讓代理改動不影響原本的互動功能。
服務帳號需要去哪裡找到這個設定？
網域委派服務帳號不是以同一個 Clients 設定管理，官方說明不要求相同勾選。企業仍需維持管理員授權與可用資料範圍，並依實際身分模式查看對應的 MCP 文件。
維護既有整合時，可以先列出失敗請求的 client、身分模式與介面，再只修正受影響的代理路徑。當新身分、使用者授權與一般功能各自驗證完成，才有依據判斷這次期限調整已處理妥當。
延伸閱讀：Activepieces0.93.0納入MCP OAuth2與代理工具：登入、保留欄位與PDF填表怎麼接？
延伸閱讀：Vercel 設下靜態憑證期限：OIDC 如何運作，哪些 Marketplace 服務將被警示？
