企業級 Agent 的資安與合規:資料權限、稽核軌跡與個資法落地要點

去年底,一家金控客戶把我們找去救火。他們的法遵單位半年前否決了一個放款審核 Agent 的上線申請,理由只有一句話：「這東西能讀到全行客戶的徵信資料,但我們說不清楚它到底讀了什麼、給了誰看。」

問題不在模型準不準。模型跑得挺好。問題在於,當稽核走進來問「6 月 12 號下午三點,這個 Agent 幫 A 分行的理專拉出了哪幾筆客戶資料、依據什麼授權」,沒有人答得出來。系統只留了 API 呼叫的成功與失敗,沒留「誰、為了誰、看了什麼欄位」。

這就是企業級 Agent 上線最常卡住的地方。不是能力,是可交代。

AI agent 資安與合規的第一道題:權限不是模型的權限,是使用者的權限

先講一個很多團隊會踩的雷。做 RAG 或 Agentic 工作流時,最省事的做法是給 Agent 一個「服務帳號」,讓它能讀整個知識庫或整個資料表,再靠 prompt 去約束它「只回答跟這位使用者有關的內容」。

這在 Demo 裡沒問題。上了生產線,它就是一顆定時炸彈。

原因很簡單:大型語言模型的輸出不是確定性的,你沒辦法用一段指令保證它永遠不越界。只要有一次 prompt injection、一次上下文污染,它就可能把 B 客戶的資料回給 A 理專。而在個資法的語境下,「系統有能力存取但不該存取」本身就是風險,不需要真的外洩才算違規。

正確的設計原則,是把權限收在 Agent 之外、資料層之內。Agent 每一次檢索,都要帶著當前使用者的身分去查詢,由資料層(而不是模型)決定哪些資料回得來。我們通常這樣落地:

• 檢索時強制注入 row-level security 或租戶隔離條件,Agent 拿不到超出使用者授權範圍的資料,連進到上下文的機會都沒有。
• 工具呼叫(tool call)全部走既有的權限中台,Agent 想動用「查徵信」「發匯款」這種高敏動作,得走跟真人一樣的授權檢核,而不是繞過。
• 敏感欄位在進入模型上下文前先做動態遮罩:身分證字號、卡號、病歷診斷碼,依角色決定看到全碼、部分碼,還是只看到雜湊後的識別碼。遮罩發生在資料層,不是等模型自己「記得不要說」。

一句話:模型可以犯錯,但架構不允許它有犯錯的權限。

稽核軌跡:能還原「誰為了誰做了什麼」才叫合規

決策者最在意的不是「會不會出事」,而是「出事之後我能不能查」。Agent 的稽核比傳統系統難,因為中間多了一層不透明的推理。你得刻意把它記下來。

一條可用的 Agent 稽核軌跡,至少要能回答:哪個真實使用者觸發、Agent 檢索了哪些資料來源與欄位、呼叫了哪些工具與參數、遮罩規則套用的結果、以及最終輸出。這些紀錄要不可竄改、要能依個資保存期限保留與銷毀,而且要跟你既有的 SIEM 對得起來。我們的經驗是,稽核日誌要獨立於應用資料庫存放,權限跟業務資料分開,否則「查稽核的人」跟「被查的系統」共用一套權限,稽核就失去意義。

大中華區個資法規:三套框架,一組共通動作

台灣、中國、香港三地的個資規範細節差很多,但落到 Agent 設計上,決策者要盯的其實是同一組控制點。與其背法條,不如對照下面這張表,把每一條映射到具體的工程動作。

香港《個人資料(私隱)條例》的邏輯相近,重點在保障資料當事人與傳輸限制。共通的落地心法是:把「合規」翻譯成資料層可以強制執行的規則,而不是寫在文件裡的承諾。 因為 Agent 不讀你的政策文件,它只受它拿得到的權限與資料約束。

可維運性:上線那天只是開始

法遵最後會問一個殺傷力很強的問題:「這套控制,半年後還成立嗎?」

Agent 系統會漂移。新的資料源接進來、有人加了一個新工具、模型換版本、遮罩規則因為業務調整被改動。任何一項變動,都可能悄悄打開一個原本關著的權限。所以可維運性不是附加題,是主體。我們會為敏感存取設離線的持續評測,定期拿一組紅隊案例去打(誘導它越權、誘導它吐出遮罩欄位),把通過率當成上線的持續門檻,而不是驗收當天量一次就結束。同時把權限矩陣、遮罩規則、稽核 schema 都版本化,任何變更都留下可回溯的紀錄。

回到開頭那家金控。我們沒有換模型,做的是把權限從 Agent 手上收回資料層、補上完整的稽核軌跡、加上分角色的動態遮罩,再交一份法遵看得懂的控制對照表。第三次送審,過了。

這也是我們在 Tenten 做 Agent 導入時的一貫立場:工程師進場,不只是把模型接起來,而是把資安、稽核與個資合規當成生產系統的一部分一起扛上線。Demo 能跑不算數,能被稽核問到底、還答得出來,才算真的上線。