--- author: OOMOL author_url: https://oomol.com/zh-tw/about/ datePublished: 2026-10-14 title: 你的 AI 助手需要多少權限，才能替你工作？ description: 從近期個人 Agent 的權限爭議出發，理解帳號授權、可執行操作和結果接收人的區別，並用 OOMOL 與 OpenConnector 為助手建立清楚的存取邊界。 lang: zh-TW canonical_url: https://oomol.com/zh-tw/blog/ai-assistant-access/ markdown_url: https://oomol.com/zh-tw/blog/ai-assistant-access.md --- ![手控制資訊流中的閘門，郵件與待傳送訊息呈現 AI 的權限邊界](/blog/ai-assistant-access/zh-tw-cover.webp) *AI 生成的編輯插畫：讀取資訊與傳送訊息，分別授權。* 讓 AI 幫你整理郵件、準備會議、跟進工作，聽起來已經很自然。真正讓人猶豫的，是點擊授權按鈕的那一刻：它能看到多少資訊？能代表你做什麼？這些權限以後還能收回來嗎？ 最近的一場討論，把這些問題擺到了檯面上。[Business Insider 在 10 月 9 日刊登的採訪](https://www.businessinsider.com/personal-ai-agent-grok-bot-posted-bank-details-company-slack-2026-10)中，XMTP Labs CEO Shane Mac 稱，他的個人財務 Agent 將報告發到了公司 Slack。文章是經編輯的當事人口述，並非獨立技術審計。 這篇採訪隨後被[轉發到 Reddit 的 r/technology](https://www.reddit.com/r/technology/comments/1x1ysae/my_personal_ai_agent_posted_my_bank_details_on/)。討論裡，有人反對讓 AI 接觸敏感資訊，也有人追問個人帳號和工作帳號為什麼會混在一起。這些反應呈現了一個具體的顧慮：當助手同時能讀取資訊和發送訊息時，使用者怎樣掌握資訊的去向？ 10 月 12 日，[CNA 發布的 TikTok 影片](https://www.tiktok.com/@channelnewsasia/video/7695633148977204488)也討論了使用者是否給 AI Agent 過多權限。根據影片說明，相關發言關注的是使用者能否理解自己授予的存取權。 這些內容不能證明每個 Agent 都會出問題，卻說明權限已經進入公眾對個人助手的討論。對於想認真使用 AI 的人，授權應該跟著任務走。 ## 同一個信箱，整理和發送需要不同的權限 假設你給助手一個任務：每天早上找出需要回覆的郵件，列出重點，並準備幾份回覆建議。 完成這件事，需要搜尋和讀取郵件。回覆建議可以先顯示在對話中，由你檢查。自動發送郵件、刪除郵件、修改轉寄設定，都應該是另外的授權決定。 如果一開始就開放所有操作，助手得到的能力會超出這個任務。以後你調整提示詞，帳號的實際存取範圍也未必隨之改變。 可以先把任務拆成三個問題： - **可以讀取什麼？** 哪個帳號、哪段時間、哪些材料？ - **可以執行什麼？** 只做搜尋和讀取，還是也允許發送、修改、刪除？ - **結果交給誰？** 顯示在目前對話，還是發到一個明確的個人收件地址？ 這三件事需要分別處理。來源應用程式的授權決定可存取的資料，連接層可以限制可呼叫的操作，助手的工作流程還要確定參數和結果接收人。 ![授權需要分別決定讀取什麼、執行什麼以及把結果交給誰；來源應用程式、連接層和助手流程各自承擔不同控制](/blog/ai-assistant-access/zh-tw-permission-decisions.webp) *三個層面需要分別設定。圖中是任務設計建議，不代表一個開關可以完成全部限制。* ## 「唯讀」也需要清楚的資訊去向 唯讀權限很適合第一階段的助手：先整理資訊，讓人檢查結果，再逐步增加操作能力。 但讀取本身也會把資訊帶入助手的處理過程。即使助手不能修改來源資料，如果另一個工具允許它發送訊息，讀到的資訊仍可能被帶到其他地方。 因此，一份個人晨間簡報，可以先直接顯示在你的私人對話裡。團隊簡報則應該使用團隊認可的資料來源和接收位置。個人財務、家庭行程和公司訊息，值得分別安排連線與輸出管道。 對於發送訊息的流程，還應明確帳號和接收目標，盡量使用穩定的目標識別碼，並在需要時顯示最終內容供使用者確認。相似的群組名稱、聯絡人名稱和帳號標籤，都不適合當成唯一判斷依據。 這是工作流程需要落實的設計。允許呼叫「發送訊息」，並不自動代表系統已經判斷了每一份內容是否適合每一位接收人。 ## 給助手一組可以解釋的能力 在 OOMOL 中，可以把這些決定落實到帳號連線和介面呼叫範圍上。[權限控制文件](https://oomol.com/zh-tw/docs/access-control/)將 Provider 授權範圍、連線存取權和允許呼叫的操作分別說明。 例如，郵件整理助手可以使用一個只允許搜尋和讀取郵件的連線。需要代表你發信時，再為發送任務設定相應能力。同一個帳號也可以建立多個連線，用於不同的操作範圍和成員存取範圍。 具體能選擇哪些授權範圍，取決於來源服務的支援；能限制哪些操作，也要核對目前連線提供的介面。記錄層級的可見範圍仍受來源應用程式權限和請求參數影響。 OOMOL 的自訂介面限制還有一個容易忽略的細節：它會停用 Proxy 和動態 `call_tool` 入口。這樣，呼叫只能落到明確允許的操作上，避免另一個通用入口超出已經勾選的範圍。這項行為來自上述權限文件，設定時可以一併檢查。 如果團隊需要自己管理連線服務，[OpenConnector](https://openconnector.io/)提供開源、自部署的路徑。它讓團隊在自己的環境中管理連線憑證、操作策略和執行記錄，再透過 MCP 或 HTTP 等入口向助手提供應用程式操作。[自部署指南](https://oomol.com/zh-tw/docs/openconnector-self-hosting/)說明了執行端驗證、允許和禁止的操作，以及遮蔽敏感資訊的執行記錄的設定。 這些能力幫助團隊建立和檢查存取邊界。回傳給助手的業務資料，仍需要按敏感資訊處理；訊息接收人、內容檢查和執行確認，也需要在助手或應用程式的工作流程中落實。 ## 從一個小而有用的任務開始授權 第一版助手可以只做一件事：讀取今天的會議和相關郵件，把需要你注意的事項放到私人對話裡。 等你確認它選對了帳號、找對了材料、能標明來源，再考慮增加建立待辦或發送訊息的能力。每增加一項操作，都應該能回答：它服務於哪個任務，作用於哪個帳號，結果會到哪裡？ 需要暫停時，也應知道該收回什麼。中斷帳號連線、撤銷呼叫憑證和取消排程任務，分別對應不同的控制點；已經發送出去的資訊不會因此自動消失。 想開始，可以在 [OOMOL Connections](https://console.oomol.com/connections) 設定一個任務所需的連線，按[權限控制指南](https://oomol.com/zh-tw/docs/access-control/)收窄允許的操作，再交給你的助手一個明確請求： > 幫我整理今天需要關注的郵件，只搜尋和讀取，不發送或刪除。把結果顯示在目前對話裡，並保留原郵件連結。 當助手的能力與任務對應起來，授權會更容易理解，後續增加能力也更有依據。