Leina 
Wanta 
權限控制
OOMOL Connector 提供 connection 級別的精細權限控制。你可以分別限制 Provider 授權範圍、connection 的介面呼叫範圍，以及哪些 Team 成員可以使用這個 connection。同一個 App 帳號還可以建立多個 connections，為不同成員設定不同的介面權限。
一次呼叫最終能做什麼，取決於以下權限範圍的交集：
Provider OAuth scopes
∩
個人或團隊的 connection 訪問權
∩
允許呼叫的 actions
∩
CLI、MCP 或 SDK 的身份範圍
↓
最終可以執行的 actions個人決定自己的帳號授權給 OOMOL 什麼，以及 connection 允許呼叫哪些介面；Team 建立者和管理員決定哪些成員可以使用哪些 connections。成員最終可以呼叫的介面由其可存取的 connections 決定。
個人權限控制
個人連線由連線帳號的人管理，主要包括以下控制：
| 可以控制 | 在哪裡管理 |
|---|---|
| 連接或斷開 App 帳號 | Connections |
| 選擇或更新 OAuth scopes | App 的 connection 頁面 |
| 查看並設定目前 connection 允許呼叫的 actions | App connection 頁面中的介面呼叫範圍 |
| 更換 API key、自訂憑證或重新授權 | App 的 connection 頁面 |
| 建立、輪替或撤銷 Connector API key | API Keys |
連線支援選用 OAuth scopes 時，Console 會在跳轉到 Provider 授權頁之前顯示權限清單。只選擇目前任務需要的 scopes；標記為高風險的權限只有在確實需要時才啟用。
OOMOL 只能在 Provider 支援時逐項選擇 scopes，最終授權內容以 Provider 的授權頁面為準。需要減少既有權限時，更新授權或重新連線；需要完全停止使用時，斷開 connection。
可呼叫的 actions
每個 action 都會宣告執行所需的 scopes 或 Provider permissions。一個 action 只有同時滿足以下條件時，才應該對呼叫方可用：
- 對應 connection 處於可用狀態。
- Provider 授權包含 action 所需的 scopes。
- 個人或 Team 權限策略允許該 action。
- 目前 CLI、MCP 或 SDK 身分可以使用對應 connection。
在 Console 中開啟 Connections，進入對應 App 後，可以查看 action、輸入 schema 和所需 scopes，並透過介面呼叫範圍設定該 connection 允許呼叫的 actions：
- 無限制：允許使用全部 actions、Proxy 和
call_tool。 - 自訂限制：只允許明確勾選的 actions，同時停用 Proxy 和
call_tool。
缺少權限的 action 需要先更新 Provider 授權；被權限策略禁止的 action 不應出現在可探索清單中，直接執行也會被拒絕。
個人連線的 action 範圍可以在介面呼叫範圍中設定，並繼續受到 OAuth scopes 和 connection 狀態的限制。Team connection 也使用相同的介面呼叫範圍；成員透過獲得 connection 存取權來獲得其中允許的 actions。
團隊權限控制
團隊權限是在 Provider 授權之外增加的一層 connection 存取控制。Team 不直接為單個成員設定 action allowlist，而是先設定每個 connection 的介面呼叫範圍，再透過成員權限決定誰可以使用這個 connection。
在成員權限中，可以選擇兩種連線存取範圍：
- 全團隊可存取：Team 中的所有成員都可以使用這個 connection。
- 指定成員存取：只有明確勾選的成員可以使用這個 connection。
| 可以控制 | 在哪裡管理 |
|---|---|
| 新增或移除成員 | 團隊管理 |
| 設定管理員或一般成員角色 | 團隊管理中的成員清單 |
| 啟用或停用成員 | 團隊管理中的成員清單 |
| 設定哪些成員可以使用 connection | connection 的成員權限 |
| 設定 connection 允許呼叫的 actions | connection 的介面呼叫範圍 |
成員最終可以呼叫的 actions，是其所有可存取 connections 所允許 actions 的聯集。選擇「無限制」時，OAuth scopes 和 Provider 帳號自身權限仍會限制實際可呼叫能力。
為不同成員指派不同權限
一個 connection 對應一組介面呼叫範圍和成員權限設定。如果同一個 App 帳號需要針對不同成員提供不同能力，可以將這個帳號連接多次，再分別設定每個 connection。
例如，同一個 Gmail 帳號可以建立兩個 connections：
- 郵件唯讀：在介面呼叫範圍中只允許搜尋、讀取和下載郵件等 actions；在成員權限中選擇只需要查看郵件的成員。
- 郵件傳送：允許傳送郵件所需的 actions；再把可以代表團隊寄信的成員指派到這個 connection。如果這些成員也需要讀取郵件，同時勾選相應的讀取 actions。
成員只能探索和呼叫自己有權存取的 connections 中允許的 actions。如果一個成員同時被指派到多個 connections，其實際可用權限是這些 connections 所允許 actions 的聯集。
成員獲得連線使用權後，可以透過該 Team 的 CLI、MCP 或其他受支援入口呼叫允許的能力，但不會看到 Provider 的原始 token。
誰可以管理
| 身分 | 權限職責 |
|---|---|
| Connection 擁有者 | 決定 Provider 帳號授予哪些 scopes，並可以重新授權或斷開連線 |
| Team 建立者 | 管理 Team、成員、角色，以及 connections 的成員權限和介面呼叫範圍；擁有預設連線存取權 |
| Team 管理員 | 協助管理成員、角色及 connection 權限設定 |
| Team 成員 | 使用獲准存取的 connections 及其中允許的 actions，不能讀取原始憑證 |
團隊版按席位計費，具體席位和費用請前往 Console 帳單頁面查看。權限還可能受到目前方案、成員啟用狀態和 Provider 自身帳號權限的限制。
常見操作
減少個人連線的權限
- 開啟 Console 的 Connections。
- 進入對應 App 和 connection。
- 選擇更新授權或重新連線。
- 取消不再需要的選用 scopes，並在 Provider 頁面確認。
暫停某位成員的存取
- 開啟團隊管理，並選擇正確的 Team。
- 在成員清單中停用該成員，或只撤銷其連線權限。
- 確認該成員使用 Team 身分的後續呼叫不再具有相應存取權。
停用成員不會刪除 Team 的 Provider connection；斷開 Provider connection 則會影響依賴該 connection 的所有呼叫。
權限控制與執行確認
即使權限允許呼叫 action，Agent 在傳送訊息、修改外部資料、擴大共享範圍或刪除內容前，仍應確認目標 connection、action 和最終參數。
Proxy 與 call_tool
| 能力 | 用途 | 為什麼自訂限制會停用它 |
|---|---|---|
| Proxy | 使用 connection 的憑證直接請求 Provider API，適用於尚未建模為 action 的 endpoint | 請求的 endpoint 和 method 不在已勾選的 action allowlist 中 |
call_tool | 對支援動態 MCP tools 的 App，按工具名稱和參數呼叫上游 MCP tool | 上游工具不一定分別建模為可勾選的 actions，工具清單也可能發生變化 |
Proxy 和 call_tool 仍受 connection 的 Provider 授權範圍限制，但具名 action allowlist 無法完整約束它們。自訂限制會關閉這兩個入口，確保呼叫只能落到明確勾選的 actions。只有確實需要存取尚未建模的 API 或動態 MCP tools 時，才使用無限制，並相應收緊成員權限。
繼續閱讀團隊管理，了解 Team、角色和成員存取範圍。