如何在不放棄控制權的情況下，賦予AI代理存取權限

捷徑做法——先把管理員權限交給代理，細節之後再處理——正好會製造出讓團隊吃虧的那種波及範圍。以下是能避免這種情況的分層模型，並逐一對照實際上線的功能。

把AI代理連接到真實系統最快的方法，就是給它跟新人第一天上班一樣的權限：完整管理員身分、所有工具，細節之後再說。妥善劃定存取範圍需要時間——得有人決定代理可以碰哪些工具、能讀取哪些資料，以及在不用先確認的情況下可以做什麼。在人手已經很緊的小團隊裡，沒有人想當拖慢這個流程的人。於是預設做法變成「先給它權限就好」，然後大家就繼續處理下一件事。

這種直覺是錯的，原因跟代理今天看起來是否值得信任毫無關係。真正的問題在於，一旦它不值得信任的那一天會發生什麼事。一個擁有管理員層級存取權的代理，只要犯了一個尋常的錯誤、被餵進藏在它被要求讀取的文件裡的惡意指令，或者只是對某個工具呼叫會做什麼過度自信卻判斷錯誤，它現在就擁有了管理員的存取範圍。這種失誤不再是一句可以一笑置之的糟糕聊天機器人回覆——而是等同於一個管理員帳號遭入侵的波及範圍，差別是它能以機器的速度、在它碰得到的每一個系統上行動，而沒有人即時盯著，能在損害擴大之前抓住它。

真正能遏制波及範圍的分層架構

為AI代理做好存取權限設計，不是撥一個開關就了事。而是六個獨立的決策層層疊加，每一層都是為了阻止最初的錯誤以某種特定方式演變成更大的災難。跳過任何一層，你並沒有真正簡化什麼——你只是把失效點移到了一個較不容易被看見的地方。

這六層裡沒有一個是特別新奇的東西。每一層都補上了上一層完全沒堵住的漏洞——單靠身分驗證擋不住過度寬鬆的工具存取，單靠工具白名單也擋不住悄悄發生且無法復原的動作。它們只有疊在一起才有效。

身分：只有一個登入，不是影子登入

從身分開始講起，因為之後的一切都是建立在它之上。如果代理的存取權限綁在一個IT部門根本不知道存在的登入上，後面的所有層都沒有意義——你沒辦法撤銷一個你根本不知道存在的授權。FabricLoop的Enterprise方案透過SSO與SAML，把工作空間接入組織實際使用的身分提供者，這正是已經用來控管電子郵件與公司其他軟體登入的同一套機制。這對代理存取權限特別重要，因為這意味著AI連線與一般協作存取走的是同一套身分邏輯，而不是兩套各自獨立的邏輯。當IT在身分提供者中將某人停用時，這單一動作就會移除該人的FabricLoop存取權限，連同綁在其登入之下的所有MCP連線一併移除——而不會留下一個沒人記得要清理的孤兒代理憑證。

雙向都採逐人授權

FabricLoop的AI連線分為兩個方向，而同一個原則——不使用共用、全團隊通用的憑證——在兩個方向上都適用。

進入方向指的是像Cursor、Claude或ChatGPT這類外部工具，以MCP用戶端的身分連進FabricLoop，藉此用某個人真實的權限來讀取或寫入任務、筆記與訊息。FabricLoop自己的設定說明明確指出，這是一個逐人進行的流程：每個人都要到app.fabricloop.com/oauth/consent開啟同意畫面、選擇工作空間，並核准該用戶端能取得的特定工具範圍——不是管理員一次幫全員切換的全工作空間開關。給團隊的指引直接點名了這個設計要防止的失效模式：不要在團隊裡共用某個人的存取權杖，因為每個人都應該各自完成自己的同意流程。結果就是一份逐人可見、也可以逐人撤銷的已連線用戶端清單，而不是一個埋在設定檔裡、存在時間遠超過它被建立的理由的存取權杖。

外出方向則是相反的情況：FabricLoop連接出去，接到它自己MCP目錄裡的第三方應用程式，例如專案追蹤工具或日曆工具。這裡的區分是刻意設計的。管理員為整個工作空間啟用某個應用程式——這是關於這個工具是否被允許存在於組織裡的決策——然後每個想使用它的人，各自連接自己的個人帳號。管理員切換這個開關，並不會把每位員工的身分交給這個應用程式；它只是讓這個選項變成可用，而每個人在連線真正發生任何動作之前，仍然必須以自己的身分完成驗證。

範圍：唯讀或白名單——不是全有或全無

身分回答的是「誰」。逐人授權回答的是「用誰的帳號」。但這兩者都沒有回答真正決定錯誤規模大小的問題：這個連線一旦生效之後能做什麼。這正是第三層的任務。

在任何已連線應用程式的詳細畫面裡，管理員都可以設定顯示名稱、開啟唯讀模式，並選擇工具政策——可以是全部可用的工具，也可以是特定的白名單。這就是「這個代理可以讀取我們的任務看板」和「這個代理可以讀取我們的任務看板，還能刪除記錄、重新指派負責人，並在每個頻道發文」之間的差別。大多數連線都不需要後面那種版本，而大多數人擔心的、代理存取權限出錯的故事，一開始通常就是某個連線在預設情況下被授予了所有工具，因為沒有人想到要勾選那個能限制它的選項。

FabricLoop的安全性頁面將由此產生的授權描述為「範圍受限」，並明確表示這「不是永久、不可見的存取權限」——是可稽核、可撤銷的，這和公司在說明「可判讀性（Legibility）」概念的頁面上使用的措辭一致：AI存取權限應該是一個你能夠明確指出並檢視的東西，而不是關於哪個舊機器人權杖還能用的部落知識。

執行時的行為：代理擬稿，真人送出

在這一層之前的所有層，控制的是代理能碰到什麼。這一層控制的是，代理一旦碰到之後被允許做什麼——而這也是大多數團隊會跳過的一層，因為它給人感覺最慢。

FabricLoop內建的助理Loop，設計的核心是公司在自家產品文件中明確陳述的一項限制：「Loop負責擬稿；你負責送出。它不會自行發文到頻道，也不會自行通知任何人。」請它總結一段對話串，它就總結；請它寫一則更新，它就寫出草稿——而仍然必須有真人審核並送出之後，其他人才會看到。對於以隊友身分存在於頻道裡的代理，同樣的模式也適用：當其中一個代理在等待某人做決定時，它不會自己猜測就繼續執行。它會出現在該頻道「應用程式與代理」分頁裡的「等待你處理」區塊——正是團隊本來就會查看的介面，而不是另一個沒人記得存在的獨立控制台。

這正是代理框架文獻中所稱的ask_human／resume模式的實際樣貌：代理在需要人類判斷的那個點暫停下來，提出詢問，只有在真人回覆之後才會繼續。FabricLoop把這個底層概念稱為人為介入率（Human Intervention Rate）——並不是把「代理多常需要人類介入」當成一個要靠工程手段消除的缺陷，而是每個運行代理的團隊都應該實際去衡量、並針對它做設計的一個數字，而不是等到事件發生時才第一次發現它。

斷路器：真正能停止執行的花費上限

存取控制不只是關於代理能讀取或變更什麼。它也關乎代理會花掉多少成本——一個失控的代理不需要碰到任何敏感資料，只要在沒人盯著的迴圈裡不斷發出昂貴的模型呼叫，就足以造成真正的損害。

FabricLoop付費方案的管理員可以在「使用量與帳單」裡為代理使用量設定每月花費上限，並可以開啟硬性停止機制，一旦花費達到該數字，就會自動暫停新的代理工作。這是一個真正的斷路器，不只是監控儀表板：差別在於，一邊是月底才發現帳單很高，另一邊是新的代理執行一旦超過某人設定的數字，就會自行停止。免費工作空間沒有金額上限，因為沒有正式環境花費需要設限——它們改用內含的僅供測試用額度來運行，這其實也是一種範圍限制，只是執行方式不同。在付費方案上，一旦硬性停止機制被觸發，提高上限是唯一能恢復運行的方式，而這正是你在那個時刻想要的摩擦：必須有人主動決定要花更多錢，而不是系統悄悄回到無上限的預設狀態。

稽核與撤銷：一個人，或所有人，同時處理

最後一層的前提，是假設前五層終究會在某個地方、對某個人失效，並問接下來會發生什麼事。

FabricLoop把撤銷分成兩種，而這個區分很重要。「撤銷我的連線」任何個人都能使用，會立即中斷該人自己的存取權限——這個工具對他停止運作，而不會影響團隊裡其他同樣有連線的人。「為工作空間停用此應用程式」則只有管理員能操作，是更大範圍的動作：它會將整個應用程式歸檔，並一次撤銷所有連往它的連線，適用於問題不是出在某個人的帳號，而是這個應用程式本身的情況。進入方向也有同樣的區分，任何人都可以在「設定 → AI／MCP」裡，立即撤銷自己所連接的MCP用戶端。

如果沒辦法看清楚在有人決定切斷連線之前發生了什麼事，以上這些都沒有意義。FabricLoop的Enterprise稽核日誌不只是登入紀錄——公司描述這些日誌涵蓋了管理員與代理的活動，而公司自己關於可判讀性概念的資料，明確把「MCP稽核事件」列為安全團隊可以查閱的內容，而不只是從情境中推測出來的東西。這就是安全團隊問「有人動過這個嗎？」能得到真正答案，跟得靠翻舊訊息、憑某人對那天下午代理好像在做什麼的記憶去拼湊時間軸，兩者之間的差別。

FabricLoop坦承目前還做不到的事

以上每一項聲明，都是FabricLoop實際已經推出的功能。同樣值得說清楚的是還沒推出的部分，因為一家只告訴你前半段的公司，其實是在要求你單憑信念相信它——而信念並不是可判讀安全態勢的意義所在。

FabricLoop自家的安全性頁面列出了現在成立的事實，接著有一個獨立的區塊，標題直白地寫著「尚未到位」，點名了三個具體的缺口：SOC 2或ISO 27001認證、第三方滲透測試，以及SCIM佈建。這個頁面的框架方式，對一個供應商的安全性頁面來說異常直接：它沒有列出其他供應商有的每一項認證，而是說，這就是現在確實成立的事——以及尚未到位的部分，因為公司寧願直白地說出來，也不願讓客戶之後才發現。

對於正在權衡是否要讓代理連接真實公司資料的團隊來說，這些不是模糊的風險——而是三個具名、可以查核的項目，你可以在安全性審查中提出、追蹤，並在續約前跟進。一份明確列出的缺口清單，比一句籠統的「一切都沒問題」的保證更有價值，正是因為它是可以被檢查的。這正是可判讀性作為一個概念背後的同一個論點：能被明確指出並驗證的存取權限與安全態勢，勝過只要求你相信的存取權限與安全態勢。