AI Agent 資料安全邊界：如何在企業許可權內工作

先給結論：可上線的 AI agent 必須像一個受控使用者：繼承使用者身份，許可權落到物件、記錄、欄位和動作；先只讀再執行，高風險動作要審批可回滾，每步可審計。真正的區別是：它是受控使用者，還是影子管理員。

很多企業討論 AI agent 時，第一反應是問：

它能不能接 CRM、ERP、工單、合同、訂單這些真實業務系統？

這個問題問得還不夠準。更關鍵的問題是：

它以誰的身份訪問？能看什麼？能改什麼？出問題時能不能知道它做過什麼，並立刻停下來？

如果這些問題沒有答案，agent 越聰明，風險越大。它會變成一個披著 AI 外衣的“影子管理員”：能跨系統查資料、能呼叫工具、能修改記錄，但不受任何人的崗位許可權約束。

企業級 agent 的目標不是讓 AI 獲得超級許可權，而是讓它在清晰邊界內幫助使用者完成工作。

AI Agent 的安全邊界

第一層邊界：agent 必須繼承使用者身份

agent 不應該擁有一個獨立的萬能賬號，更不應該直接拿資料庫管理員許可權。

它應該代表當前登入使用者行動。銷售只能看自己負責的客戶，agent 也只能看這些客戶；客服只能處理自己佇列裡的工單，agent 也只能在這個佇列內查詢和建議；工程師不能看合同金額，agent 也不能因為“需要分析”就繞過去。

這條規則看似簡單，卻決定了整個系統是否可控：

使用者離職，agent 的訪問能力隨之消失；
使用者轉崗，agent 的可見範圍隨許可權變化；
使用者無權訪問的記錄、欄位和動作，agent 也無權訪問；
審計日誌可以把每次 agent 行為關聯回真實使用者。

不要把這件事交給提示詞。提示詞可以提醒模型“不要越權”，但真正可靠的邊界必須由執行時許可權系統強制執行。

第二層邊界：許可權要落到物件、記錄、欄位和動作

企業許可權不是一句“允許訪問 CRM”就夠了。

一個安全的 agent 需要同時尊重四類邊界：

物件級許可權：使用者是否能訪問客戶、訂單、工單、合同這些物件。

記錄級許可權：使用者能訪問哪些具體記錄，例如自己的客戶、所在區域的訂單、某個團隊的工單。

欄位級許可權：使用者能不能看合同金額、成本、身份證號、內部備註等敏感欄位。

動作級許可權：使用者能不能建立任務、修改階段、關閉工單、傳送報價、調整折扣、變更許可權。

很多 agent 專案失敗，不是模型不夠好，而是許可權模型太粗。系統只知道“這個 agent 可以查客戶”，卻不知道它不能查所有客戶，不能讀取敏感欄位，不能執行高風險動作。

ObjectOS 的思路是把業務物件、欄位、動作和許可權都變成宣告式後設資料。agent 不是直接碰表，也不是直接調任意 API，而是通過受控工具在這些後設資料定義的邊界內工作。

第三層邊界：先只讀，再建議，再執行

讓 agent 一開始就自動修改業務資料，通常不是好主意。

更穩妥的上線節奏是三步：

只讀階段：agent 可以查詢和總結資料。例如“找出超過 SLA 的工單”“總結這個客戶最近 90 天的問題”“列出可能延期的訂單”。它不寫入，不觸發外部動作。

建議階段：agent 可以生成待確認的操作建議。例如“建議把這 12 個工單升級為高優先順序”“建議給這些客戶建立跟進任務”。人確認後再落庫。

受控執行階段：對低風險、邊界明確、可回滾的動作，agent 可以自動執行。例如建立內部任務、更新普通狀態、補全非敏感欄位。高風險動作仍然需要審批。

這個分層很重要。它讓企業可以逐步擴大 agent 的許可權，而不是在“完全不用”和“全自動執行”之間二選一。

第四層邊界：高風險動作必須審批和可回滾

有些動作天然需要更高門檻：

刪除記錄；
批次修改客戶、訂單、合同、庫存或財務資料；
修改金額、折扣、賬期、信用額度；
對外發送正式郵件、報價、合同或通知；
修改角色、許可權、組織關係；
呼叫會產生真實成本的外部服務。

這些動作不能只靠模型判斷“應該沒問題”。系統需要在執行前展示影響範圍、原因和差異，讓有許可權的人確認。

同時，系統要記錄執行前後的狀態。出錯時至少能撤銷、補償或人工恢復。如果 agent 一次準備改 500 條記錄、命中敏感客戶、超過金額上限，系統應該自動剎車並升級給人。

審批不是為了拖慢 AI，而是為了讓 AI 能進入生產環境。

第五層邊界：每一次讀取和操作都要可審計

很多傳統系統只記錄人做了什麼，沒有準備好記錄 agent 做了什麼。

但 agent 的行為鏈更復雜：它可能先讀取資料，再做分析，再生成建議，再呼叫工具，再等待確認，最後修改記錄。出了問題，如果只能看到“某條記錄被改了”，遠遠不夠。

審計至少應該回答這些問題：

誰觸發了這次 agent 任務；
agent 讀取了哪些物件和記錄；
哪些欄位被隱藏或拒絕訪問；
呼叫了哪些工具和動作；
生成了什麼建議；
哪些動作被人確認，哪些被自動執行；
執行前後資料如何變化；
哪些步驟失敗、越權或升級審批。

審計不是事後甩鍋，而是讓團隊有能力逐步放寬許可權。沒有審計，企業只能保守地把 agent 關在業務系統外面。有了審計，IT 和業務團隊才能知道哪些場景已經穩定，哪些場景還需要人守著。

一個判斷標準：它是受控使用者，還是影子管理員？

評估一個企業 agent 架構，可以問 6 個問題：

agent 是否以真實使用者身份執行？
它是否繼承物件、記錄、欄位和動作許可權？
它是否通過受控工具訪問資料，而不是直接讀取整庫？
它是否支援只讀、建議、執行的分級授權？
高風險動作是否需要審批、可回滾、可剎車？
每一次讀取、建議和修改是否可審計？

如果答案大多是否定的，這不是企業級 agent，而是一個新的安全盲區。

ObjectOS 的立場

ObjectOS 預設接受一個現實：真正有價值的 AI 一定會進入業務系統。

它需要讀客戶、訂單、工單、合同和審批；它需要理解業務物件之間的關係；它也需要在授權後推動流程。但它不能繞過企業已有的身份、許可權、審批和審計。

所以 ObjectOS 把物件、欄位、流程、許可權和動作都放進統一後設資料層，讓 agent 通過這層結構工作。AI 能更接近真實業務，同時每一步都有身份、有邊界、有記錄。

企業不缺會聊天的 AI。企業缺的是能安全使用業務資料、能被授權、能被審計、能隨時停下來的 AI。