結構化資料與文件，為何難以同時治理
企業要回答的問題，很少只靠一種資料。業務想知道「上一季 APAC 區域的退貨率為何飆高」，答案的數字住在結構化的銷售與退貨表裡，但解釋「為什麼」的合約條款、供應商備忘錄與產品規格書，卻散落在 PDF 與簡報中。GenAI 代理要真正派上用場，就必須同時讀懂這兩種資料——把表格裡的量化事實，和文件裡的因果脈絡兜在一起。
Databricks 的判斷是：做一個能同時讀表與讀文件的代理不難，難在「一個代理若什麼都能讀，憑什麼擋住它把不該說的話說給不該聽的人」。最常見的偷懶做法，是給代理大範圍存取權，再靠提示工程在模型這一層過濾結果。Doyoung Jung 在Databricks 發布的做法說明裡把這條路稱為危險的賭注——模型可以被操縱、可以被繞過。一旦防線只建立在「模型會自律」上，治理就形同沒有保障，見〈提示注入的三層防禦〉。
把安全邊界還給 Unity Catalog
替代方案的一句話總結是：Unity Catalog 而不是模型，才是安全邊界。Genie Agents 以終端使用者的憑證執行，所有權限檢查都針對「發問的那個人」的身分，在查詢那一刻逐筆評估。結果是代理無力回傳使用者無權檢視的紀錄，因為每個答案都先在資料層過濾好，才離開 Lakehouse。
這套設計把治理的單點從模型移回資料平台本身。對審計人員來說，「我在提示裡加了指示叫它別顯示受限資料」並不是一個站得住腳的治理控制；真正可稽核的，是寫在資料層、與身分綁定的存取規則。也因此治理能隨代理擴展，而不是愈長愈失控。換言之，重點不在於模型多聰明，而在於當它犯錯或被攻擊時，資料層仍能保住底線。
身分是一切的起點
存取控制再精密，也只和它所評估的身分一樣可靠。Databricks 的第一步是把身分基礎打通：Automatic Identity Management（AIM）會把使用者、群組、群組成員與服務主體，從 Microsoft Entra ID 或 Okta 自動同步進 Databricks，不需要另外架設 SCIM 應用程式。Just-in-Time（JIT）佈建則讓一個從沒登入過 Databricks 的使用者，在首次登入時就被佈建好，而且一到位就帶著原本就有的群組成員資格。
身分同步不是一次性的設定，而是持續的。當員工調區、離職，變更會從身分提供者自動傳播過來，Genie Agents 因此繼承了既有的治理規則而無需額外設定。整條鏈是：身分提供者到 AIM 同步、再到 Unity Catalog 策略評估，最後是依群組權限形塑後的 Genie Agent 回應。身分一旦失準，後面四層管控都會跟著失準，所以這一步是整個治理架構的地基。
結構化資料的四層管控
在結構化資料這一側，治理落在四個層次上。第一層是物件權限，用 GRANT SELECT 控管誰能讀哪個目錄、資料庫或資料表。第二層是屬性式存取控制（ABAC）——這在 Unity Catalog 已正式推出——做法是反轉逐表設定：用受治理標籤（如 pii:email）標記敏感欄位，再寫一道套用於該標籤出現之處的策略，新資料表一旦被標記就自動繼承保護，省去逐一設定的功夫。
第三層是資料列層級篩選，由 SQL UDF 在查詢時逐列評估可見範圍。第四層是資料行層級遮罩，同樣靠 SQL UDF 決定回傳原值或遮罩值。這兩層都掛載在與既有授權相同的群組上——例如 is_account_group_member('brickstore_apac')。四層疊起來，結構化資料的「誰能看到哪幾列、哪幾欄」就有了可稽核、可組合的答案，而不必把這些判斷交給模型臨場發揮。
文件治理靠 Unity Catalog Volumes
文件這一側則交給 Unity Catalog Volumes。PDF、圖片（JPG、PNG、TIFF）、Office 文件（DOC、DOCX、PPT、PPTX）以及純文字、Markdown，都放進 Volume 裡，使它們成為可授予權限的物件，用 GRANT READ VOLUME 控管存取。代理讀的可以是掃描合約、簡報或規格書。
關鍵在於「必要來源」這個設計：把一個 Volume 接上 Genie Agent 時，它就成為必要來源，代理在載入時會逐一驗證使用者對每個掛載來源的存取權——只要有一個掛載 Volume 缺少 READ VOLUME，那個使用者根本無法使用該代理。而 Volume 是最小的可保護單位，權限套用於整個 Volume，而非個別檔案。實務上這意味著：不同受眾的文件要分裝到不同 Volume（甚至不同代理），Volume 說明要寫清楚、避免跨 Volume 內容重複，並只放入相關檔案。
同一問題，不同身分，不同結果
把上述機制放進生產環境，最直接的驗證是：兩個使用者問同一個問題，只因群組成員不同，就拿到不同的結果。Databricks 示範了 APAC 與 AMER 兩位經理查詢相同的資料表與 Volume——兩人都拿到正確答案，但各自限縮在自己的區域，而且電子郵件欄位被遮罩。沒有人寫下「如果使用者是 APAC，就隱藏其他區域」這樣的指示；代理的指令對兩人完全相同。
差別完全在資料層發生，零逐人提示工程。這也帶出一條測試守則：用化身（impersonation）來測，而不是讀完策略就假設沒問題——以不同群組成員的身分實際去問，才能確認治理真的生效。同樣的查詢、同樣的代理，只因身分不同而回傳不同範圍的資料，正是「安全邊界在資料層」最具體的證明。
落地建議與常見陷阱
把這套做法濃縮成幾條可操作的建議。先標記、再下策略：用 ABAC 加受治理標籤，取代逐一資料表的遮罩。一個 Volume 只服務一種受眾：不同讀者群的文件要拆開，避免一個 Volume 裡混入不該被某群組看見的內容。用化身測試、而非用肉眼檢視策略。而一旦要透過 MCP 或 API 對外暴露代理，身分處理會換成另一套模式（U2M、M2M、OBO），不能再直接套用互動式情境的假設。
而在 Databricks 上，Genie 的資料存取本就由 Unity Catalog 治理，並逐使用者套用資料列篩選與資料行遮罩，使用者只能看到獲授權的資料，官方文件亦如此記載。把結構化資料與文件交給同一個代理，並不等於把治理也一起交出去；前提是安全邊界始終留在資料平台，而不是模型。
