AI Agent 許可權邊界：資料和動作如何受執行時約束

先給結論：企業 AI agent 不能當超級使用者——它必須繼承使用者許可權、遵守記錄範圍與欄位級安全，高風險動作要確認，每一步都要可審計。許可權不能靠模型自覺，必須靠執行時強制。

企業引入 AI agent 時，最危險的不是它答錯一個問題，而是它像一個沒有邊界的超級使用者。

它能查客戶、看合同、讀報銷、改狀態、發通知、發起審批。能力越強，越需要回答清楚：它到底繼承誰的許可權？

它能不能看到普通員工看不到的資料？它能不能修改使用者本人不能修改的欄位？它能不能直接執行原本需要審批的動作？

這些問題如果回答不清楚，AI 就很難進入核心業務系統。

ObjectOS 的基本原則很簡單：AI 可以成為業務助手，但不能成為許可權體系之外的超級使用者。它讀資料、呼叫動作、觸發流程，都應該經過同一套物件、許可權、確認和審計邊界。

企業 Agent 的許可權邊界

許可權不能靠模型自覺

很多 AI 專案會在提示詞裡寫：

你只能訪問當前使用者有許可權的資料。執行危險動作前必須詢問使用者。不要洩露敏感欄位。

這些要求有必要，但它們不是安全邊界。

真正的許可權必須由平臺執行。模型可以被提醒，但不能被當成許可權系統；工具可以被描述，但不能直接繞過業務規則；agent 可以發起動作，但不能跳過確認和審計。

如果一個銷售沒有許可權檢視其他區域的商機，AI 也不應該通過“彙總分析”看到這些商機。如果一個員工不能檢視同事薪酬欄位，AI 也不應該在回答裡洩露。如果一個審批需要經理確認，AI 不能因為“理解了使用者意圖”就直接批准。

企業 AI 的底線是：AI 不比當前使用者擁有更多業務權力。

agent 應該繼承當前使用者的上下文

一個安全的 AI 應用，首先要知道“是誰在問”。

使用者在介面裡向 AI 提問時，平臺不應該只把問題發給模型，還應該把當前使用者、角色、組織、租戶、許可權和請求追蹤資訊帶入工具執行上下文。

這樣 agent 查資料時，看到的就是當前使用者本來能看到的資料；agent 執行動作時，也只能執行當前使用者有資格發起的動作。

這看起來像技術細節，實際是產品體驗的基礎。

因為業務使用者不會接受“同一個問題，在頁面上查不到，在 AI 裡卻查得到”。管理者也不會接受“許可權系統管住了人，卻沒有管住 AI”。

記錄範圍決定 AI 能看哪些資料

物件級許可權只能回答“能不能看客戶物件”“能不能編輯商機物件”，但企業還需要回答“能看哪些客戶”“能改哪些商機”。

例如：

銷售只能看自己負責的客戶；
區域經理可以看本區域客戶；
財務只能看與預算相關的專案；
客服主管可以看團隊工單，但普通客服只能看分配給自己的工單；
外部供應商只能看自己的訂單和資質。

這些就是記錄級邊界。AI 查詢“所有高風險客戶”時，“所有”必須自動限定在當前使用者的可見範圍內。

如果 agent 的資料工具直接查資料庫，再把結果交給模型過濾，就已經太晚了。正確做法是：平臺在查詢層就注入記錄範圍，AI 根本拿不到不該看的記錄。

欄位級安全防止敏感資訊洩露

即使使用者能看到一條記錄，也不代表能看到所有欄位。

客戶記錄裡可能有內部風險評分；商機裡可能有底價和利潤率；合同裡可能有敏感條款；員工服務請求裡可能有個人隱私；採購記錄裡可能有供應商評估細節。

AI 很擅長總結，也正因為擅長總結，它更容易把多個欄位裡的敏感資訊合併成一句看似自然的回答。

因此欄位級安全非常重要。使用者無權讀取的欄位，應該在進入 AI 上下文之前就被遮蔽；使用者無權修改的欄位，AI 也不能通過動作引數悄悄改掉。

這不是“讓模型少說一點”，而是“讓模型根本拿不到”。

動作許可權比資料許可權更敏感

讀資料已經有風險，做動作風險更高。

企業 agent 可能會執行這些動作：

建立任務；
更新客戶階段；
關閉工單；
發起審批；
傳送郵件；
標記合同風險；
批准或退回報銷；
刪除重複記錄。

這些動作不應該因為 AI 發起就自動放行。它們應該和人點選按鈕一樣，經過動作許可權、引數校驗、風險判斷、必要確認和審計記錄。

ObjectOS 裡，業務動作由 Action 後設資料描述。一個動作是否開放給 AI，需要明確配置；高風險動作還應該進入確認或審批。這讓企業可以把 AI 能做什麼、必須確認什麼、不能做什麼分清楚。

人工確認是治理，不是效率障礙

很多團隊擔心確認會降低 AI 效率。實際上，確認是讓 AI 進入真實業務的前提。

一個合理的落地路徑通常是：

先讓 AI 只讀資料、生成建議；
再讓 AI 建立草稿、任務和內部備註；
對狀態變更、審批發起、外部通知加入使用者確認；
對高風險動作使用審批；
最後才把低風險、高頻、可回滾的動作自動化。

這樣團隊既能獲得效率，也不會把關鍵責任直接交給模型。

更重要的是，確認應該發生在平臺執行時，而不是隻依賴模型說“我會先問你”。當 AI 發起動作時，平臺生成待確認項；使用者確認後，平臺執行動作並記錄日誌。這才是可審計的企業流程。

審計讓 AI 行為可解釋

當 AI 進入業務系統，審計問題會變得更具體：

AI 看過哪些物件和欄位？
它基於哪些資料給出建議？
它發起了哪個動作？
誰確認了這個動作？
動作修改了哪些記錄？
流程在哪個節點暫停或繼續？
失敗後有沒有補救？

這些問題不應該靠聊天記錄猜。平臺需要把 AI 查詢、動作、流程、審批和結果放進同一條追蹤鏈裡。

只有這樣，業務負責人才能覆盤效率提升，合規團隊才能檢查風險，管理員才能發現異常呼叫。

評估企業 agent 平臺時該問什麼

如果你在評估 AI agent 是否能進入業務系統，可以直接問這些問題：

agent 查詢資料時，是否繼承當前使用者許可權？
記錄級許可權是否在查詢層執行，而不是事後過濾？
敏感欄位是否在進入模型前就被遮蔽？
AI 能呼叫哪些動作，是顯式開放還是自動暴露？
危險動作是否有執行時確認和審批？
AI 操作是否和人工操作進入同一套審計？
管理員能否看到 agent 做過什麼、為什麼做、誰批准？
系統級許可權是否只用於內部任務，而不是普通使用者對話？

這些問題比“模型回答得是否流暢”更重要。因為企業 AI 的風險，不在於它不會說，而在於它說了不該說的資料，或者做了不該做的動作。

ObjectOS 的差異

ObjectOS 不把 AI agent 當成一個外接聊天外掛，而是讓它在業務執行時內工作。

它通過物件後設資料理解業務資料，通過許可權模型限定可見範圍，通過欄位級安全保護敏感資訊，通過 Action 後設資料開放可執行動作，通過流程和審批處理人工確認，通過日誌保留完整證據。

這樣，AI 可以更接近真實工作，但不會站到許可權體系之外。

對企業來說，這才是 AI agent 從演示走向生產的關鍵：不是讓 AI 擁有無限能力，而是讓 AI 在正確邊界內擁有足夠能力。