Palantir 的 row 權限停在讀取當下，markings 預設跟著資料走

Palantir 有一頁專談權限怎麼往下游傳，叫 Access control propagation。頁尾的 FAQ 問了一題：“Does respecting Foundry’s security model guarantee policy enforcement downstream?”（Palantir 官方文件，Access control propagation 頁）

答案分兩步。第一步說，遵守安全模型的應用程式在使用者的權限下讀資料，這保證使用者讀不到沒授權的東西。第二步是：“It does not guarantee that what the user reads remains under the source policy after the read.”（同頁）

答案是不保證。

這個答案有範圍。row 與 column 的 granular 政策停在讀取的當下；markings、CBAC、organizations 這些 mandatory 控制不一樣。propagation 頁寫它們隨衍生資料走，Markings 頁寫衍生資源承接標記，除非明確移除。兩頁並讀，本文說它們「預設」跟著走。

所以聽到有人說「這個系統有權限層」，光憑這句話判斷不了它管到哪裡。要另外問三件事：規則掛在哪，什麼時候檢查，資料離開之後規則在哪裡。

第一篇寫過看到物件要過的兩關，第二篇拆過 action 送出前的三道關卡；這篇從資料讀到手之後問起，先拆 Palantir，再對照 Cube、Looker、dbt、Snowflake、Databricks、Microsoft 的官方頁面。

讀一個 Ontology 物件，granular 政策與 marking 檢查都要過

Object permissioning 的 Overview 頁把 Ontology 的授權結構分成兩個 levels：“We can conceptualize the Ontology’s authorization structure on these two levels: ontology resources, and objects and links.”（Overview（Object permissioning）頁）第一個 level 是 object type、link type、action type 這些定義 schema 的資源。第二個 level 是物件與連結本身，帶著實際的主鍵與屬性值。這篇談的是第二個 level。

物件資料的存取，Ontology permissions 頁寫成兩條路。一條是 object 與 property security policies，直接設在 object type 上，獨立於底層資料源的權限。另一條是 data source policies，由底層資料源的權限決定物件可見性。Managing object security 頁寫，in most cases 推薦用前一條管理物件安全。

Object security policies 頁把讀取一個物件實例與它的屬性所需的條件列成三項：object type 的 Viewer 存取；通過 granular 政策（若有設定）；通過 marking、organization 或 classification 檢查。本文的讀法是，第一篇講的第二把鑰匙，在設了 object security policy 時，拆成了 granular 政策與 marking 等檢查兩件。

接下來的問題是：這三項裡，哪些在資料被讀出去之後還跟著走。

mandatory 控制跟著資料走，row 與 column 政策卻停在讀取

Security 區的 Overview 頁用一句話交代兩家的差別：“Data security in the Palantir platform is provided through a combination of mandatory and discretionary controls, which differ in how they propagate.”（Overview（Security）頁）propagation，就是控制會不會跟著資料往下走。

mandatory 這一家，propagation 頁列了三種：markings、CBAC、organizations。同頁寫，mandatory 控制隨資料走，經過衍生，也經過下游的使用。CBAC 專頁另寫，CBAC 在 Foundry 上預設未啟用。

discretionary 這一家，同頁列了與 row 和 column 保護相關的幾種：project roles、restricted views、object security policies、property security policies。後三種是 granular 的 row 與 column 政策。restricted views 是 read-layer 資源；object security policies 是在 object set layer 評估的 row 級過濾；property security policies 是物件屬性的 column 級過濾。

這幾種 row 與 column 控制讀完之後怎樣，同頁寫得很直接：“After the read, the rows that the user did receive are ordinary data.”（同頁）讀出來的資料列不帶 metadata、classification 或 tag，後面的程式碼沒有東西可以用來重新套用政策。

roles 的說法在 Projects and roles 頁：“Roles, by contrast, govern access to the resource itself; they do not extend to data after it has been read from the resource.”（Projects and roles 頁）同頁也寫 role grants 會往子資源繼承。這個繼承走的是資源階層，由 project 往下到子資源，不是沿資料依賴。

讀出去之後，七個出口都不帶來源政策

propagation 頁有一個小節叫 Where discretionary controls stop，開頭一句是：“The following operations do not carry the source policy:“（Access control propagation 頁）後面列了七項，表一用中文譯寫。

表一｜七個出口（row 與 column 的 granular 政策；propagation 頁小節 Where discretionary controls stop）

小節最後寫：“In each case, the running user could not have read what they were not authorized to read; the access guarantee holds.”（同頁）不成立的是 propagation：保護來源資料的限制，管不到資料被讀走之後的去處。

這張清單沒有 webhook 與 notification，頁面也沒說它是否窮舉。Action types 的 Permissions 頁另寫，通知內容含收件人無權存取的資料時，通知不會送給他。webhook 這邊，同頁寫設定 webhook plugin 需要額外權限；來源政策是否隨 webhook 送出的資料延續，Action types 的 overview、Side effects、Webhooks 三頁正文都沒寫。

落到設計上，資料只要經過這七項之一，例如進 AIP Logic、走 OSDK 回應或被匯出，row 與 column 政策就不跟著走。保護要延伸到下游，propagation 頁給的處方是：“Use a mandatory control (a marking, CBAC classification, or organization); mandatory controls propagate.”（同頁）

markings 隨衍生資料走，移除要專門的權限

propagation 頁舉了三個傳播的例子。marking 與 CBAC 兩例沿資料依賴往下走：用被標記的輸入建出來的資料集，承接 transaction 上的標記；被標 classification 的欄位複製進下游資料集，仍保有那個 classification。organization 的例子是容器關係：在 organization-scoped project 裡產生的資源，承接 project 的 organization 限制。

CBAC 有一個範圍：沿資料依賴往下走的是 data classification，project classification 不沿資料依賴繼承（Classification-based Access Controls 頁）。

Markings 頁寫，衍生資源承接標記，除非標記被明確移除。官方給的理由是資料擁有者：marking 隨資料傳播，是為了讓資料擁有者對自己的資料資產多一層控制。移除則被寫成 sensitive action：“Similarly, removing a Marking is considered a sensitive action.”（Markings 頁）

移除的路徑有兩條。一條是從 marking 原本套用的檔案、資料夾或 Project 移除，下游會立即跟著移除。另一條是在 transformation 裡移除，只影響沿資料依賴的下游。

transform 這條，Remove inherited markings and organizations 頁寫的做法是 stop_propagating 與 stop_requiring 兩個 input transform properties。前者對應 markings，後者對應 organizations，兩者都不含 Roles。repository 要有至少一條受保護分支，並強制至少一位核准者。輸出資料集建置完成後，就不再帶被傳播的 markings 或 organizations。

移除要什麼權限，兩頁的用詞不同。Markings 頁寫，要 Marking 本身的 Expand Access 權限，這是集中管理的權限。Remove inherited markings and organizations 頁在核准移除的段落寫，移除 markings 要 Remove marking 權限，移除 organizations 要 Expand access 權限。

propagation 頁的 FAQ 把取捨寫成一句話：“Removing the marking trades a control that travels through derivation for one that does not.”（Access control propagation 頁）Manage granular policies 頁也提醒：別因為以為 granular 政策已經管住存取，就移除繼承來的 marking。

同一個 object security policy 裡，granular 部分停在讀取，mandatory 部分繼續走

兩頁對 Read-time enforcement only 這個小節的寫法不同。Object security policies 頁以整個 object 與 property security policy 為主詞：政策過濾使用者能讀到的東西，不延伸到下游輸出或匯出，沒有附例外。Managing object security 頁把主詞縮到政策裡的 granular row 與 column 控制，保留不延伸的那句，再加一句：“However, mandatory and classification-based controls within the same policy continue to apply to derived data.”（Managing object security 頁）

mandatory 那一半從哪裡來，Object security policies 頁寫：預設情況下，object security policy 會從資料來源繼承所有 mandatory controls。繼承的方向是從資料來源進到政策。政策也可以新增 mandatory controls，或移除不再需要的繼承項；頁面的例子是在 Markings 設定裡停止繼承 PII 與 VIP 標記。這是政策自己的設定，和 transform 裡的 stop_propagating 是兩個地方的做法。

政策被物化成資料集時，取最嚴的權限，並以物化資料集建置當下產生的安全政策保護 transaction。頁面也寫，目前有 object security policy 的 object type 只能物化成 Foundry datasets。

granular 那一半管到格子。Object security policies 頁寫 object 與 property security policy 合起來達成 cell-level security：通過物件政策、沒通過屬性政策的使用者，看到的是 null，不是屬性值。

政策的範圍在 Ontology 之內，不控制非 Ontology 情境的原始資料集。Managing object security 頁還舉了 media reference 的例子：若 media set 的權限與 object type 不同，使用者有可能沒有某個 media reference 屬性的存取，卻仍能直接從 media set 取得媒體項目。該段寫，本節描述的存取控制機制只管屬性值的可見性。

action 的 read／write authorization（beta）可以刻意切斷 marking 的傳播

讀到這裡，「mandatory 一定跟著走」容易讀成無條件。propagation 頁確實有一句不帶例外的寫法：“Propagation means that no derived artifact can expose data to a user who lacks the required marking, classification, or organization membership.”（Access control propagation 頁）

action 的輸出另有一頁講。Read and write authorizations 頁（下稱 rw-auth 頁）標 beta，寫：“Mandatory markings are intended to propagate along data dependencies so derived data retains the protections of its inputs. For actions, the action’s logic sets the security applied to output data.”（Read and write authorizations 頁）Action types 的 Permissions 頁把兩處並排連結：Read-time enforcement only 小節連到 propagation 頁，Read and write authorizations 小節連到 rw-auth 頁。

rw-auth 頁寫，action 的輸出可以和輸入的安全等級相同、較高或較低。write authorization 設得比 read authorization 寬鬆時：“This intentionally severs mandatory marking propagation and may result in data declassification.”（同頁）

切斷有條件。兩者設得不同時，存檔或發佈 action type 的人要有權限 declassify 被切斷的 mandatory marking。這項檢查在存檔時做，runtime 不重查。

同頁也寫這兩項目前選填。未設 read authorization 時，存檔或發佈不做 declassification 檢查，頁面寫：“The action can therefore read data above its write boundary and write less restrictive data, which can cause a data spill.”（同頁）處方是：只要 action 可能讀到有 marking 的資料，就設定 read authorization。

write authorization 會驗證結果的安全性，低於設定下限就擋下 action。但平台自己管理的寫入，例如 action log 與 edit history 物件，不受 write authorization 約束。

所以切斷路徑不只一條。本文讀到的受控路徑有兩條：transform 的 stop_propagating 與 stop_requiring，要受保護分支與審批；action 的 read／write authorization，目前選填，存檔時檢查。Markings 頁寫的在原本套用處移除、object security policy 的停止繼承，也是移除的做法；這些是否就是全部，頁面沒寫。照本文的讀法，mandatory 預設隨衍生資料走，另有受控的切斷路徑。

AI 工具呼叫時查權限，資料進了模型脈絡就與來源政策脫鉤

Why create an Ontology? 頁寫 AI 的工具使用：“Tool usage is dynamically enforced through the same security architecture that governs data access and all forms of memory.”（Why create an Ontology? 頁）下一句寫，工具呼叫至少依賴對底層物件、屬性、連結的存取。這是存取層面的句子。

propagation 頁把 AIP Logic tool calls 列在七個出口裡（表一），寫的是資料進入模型脈絡之後。本文的讀法是兩頁講不同的時點：why-ontology 那句講呼叫的當下，propagation 頁講資料已經讀進脈絡之後。

OSDK 也分成同樣的兩段。Ontology SDK overview 頁寫，OSDK 用的 token 只限定在應用程式要存取的 ontological entities，再加上使用者自己對資料的權限。同頁的 Read-time enforcement only 小節寫：“These controls do not extend to the OSDK response payload or to anything your application does with the data.”（Ontology SDK overview 頁）處方是搭配 marking 或 CBAC。

寫到資料離開之後的，是 Snowflake、Databricks、Microsoft 的 row 級專頁

Cube 與 Looker 的頁面，把規則寫在請求或查詢的當下。Cube 的 Access policies 頁寫，access policy 在處理請求時評估，並與相關的自訂安全規則合併（Cube 官方文件，2026 年 9 月查閱）。Looker 的 User attributes 頁寫，access filter 依執行查詢的使用者過濾，做法是在 SQL 的 WHERE 加條件（Looker 官方文件，2026 年 9 月查閱）。

Looker 的 access_filter 只掛在單一 Explore 上，哪個 Explore 忘了加，那個 Explore 的資料就不受限。資料送出去之後，Looker 的排程會對每位收件人各跑一次，但那是 dashboard 或 Look 的篩選器設成 user attribute 的用法，不是 access_filter。action 送出的資料是否受 access_filter 約束，action 參數頁與 BigQuery 寫回頁都沒寫。Cube 這邊，匯出與排程寄送的存取行為，本文讀到的頁面沒寫。

dbt Semantic Layer 頁談存取控制，只有一句：“To ensure secure access control, the Semantic Layer implements robust access permissions mechanisms.”（dbt 官方文件，2026 年 9 月查閱，dbt Semantic Layer 頁）機制的內容與套用時點，頁面沒寫。Write queries with exports 頁寫，exports 把 saved query 的輸出寫成資料平台內的表或視圖，像一般的表，並用 production 環境的預設憑證。

Microsoft 的 Fabric IQ ontology 頁標 preview（Microsoft 官方文件，2026 年 9 月查閱，What Is Ontology (Preview)? 頁）。頁面寫 Fabric workspace 與 item 權限控制 ontology items 的存取；撰寫與查詢尊重綁定資料的存取，包括 OneLake security 與來源端執行的 RLS、OLS、CLS。規則頁寫 ontology 不對資料執行規則、也不執行 action，沒寫由誰執行。

寫了資料離開之後怎麼處理的，是三家專談 row 級規則的頁面。

Snowflake 的 Understanding row access policies 頁（Snowflake 官方文件，2026 年 10 月查閱）寫，row access policy 是 schema-level 物件，掛在 table 或 view 上，查詢執行時以 policy owner 的 role 評估，不是執行查詢者的 role。clone 出來的表，對應到與來源表相同的政策。

CTAS 建的新表是另一種寫法：“If a row access policy is set on the base table, the new table contains the filtered rows based on the row access policy definition. The new table does not have a row access policy set on a column.”（同頁）新表含過濾後的列，欄位上沒設 row access policy。

分享有條件。provider 對分享的 table 或 view 設了政策，且政策條件呼叫 CURRENT_ROLE、CURRENT_USER 或 secure UDF 時，這些函式在 consumer 帳號回 NULL。頁面給的原因是，被分享資料的擁有者通常不控制帳號裡的使用者或 role。

semantic view 留著一個沒接起來的問題。sv-sql 頁寫，查 semantic view 只需要 semantic view 本身的 SELECT 權限，不需要底層表的 SELECT，並說這與標準 view 所需的權限一致（2026 年 10 月查閱）。semantic views 概述頁寫，Cortex Agents 目前讀 semantic view 定義裡的資訊，直接對實體表產生 SQL（2026 年 9 月查閱）。row access policy 頁正文沒有出現 semantic view 一詞，另兩頁也沒有出現 row access policy 與 masking policy。查 semantic view 時底層表的政策是否套用，這幾句各自存在，頁面沒有把它們連起來。

Databricks 的 Row filters and column masks 頁開頭說明，本頁談的是 table-level 形式，由 table owner 管：row filter 綁單一表，column mask 綁單一欄；ABAC 政策則掛在 catalog 或 schema。clone 要連 ABAC 的例外一起讀。限制清單寫 deep 與 shallow clone 不支援，ABAC 下則是：“In ABAC configurations, users who are explicitly excluded from a policy can still perform clone operations on the underlying data.”（Databricks 官方文件，2026 年 10 月查閱，Row filters and column masks 頁）view、AI Search index、Iceberg REST 與 Unity REST 另有不支援的限制，見表二。

Microsoft 的 Row-level security (RLS) with Power BI 頁（Microsoft 官方文件，2026 年 10 月查閱）寫，RLS 以 DAX 篩選器限制特定使用者對 semantic model 資料的存取。篩選器定義在角色內、掛在表上，不適用 workspace 的 Admin、Member、Contributor。頁面的重點是 Viewer：即使給了 Build 權限，RLS 仍適用，例子是 Analyze in Excel：“if Viewers with Build permissions use Analyze in Excel, their view of the data is restricted by RLS.”（同頁）

service principal 是另一種寫法：“Service principals can’t be added to an RLS role. Accordingly, RLS isn’t applied for apps using a service principal as the final effective identity.”（同頁）嵌入情境另有一條路：走 Power BI REST API 的 EffectiveIdentity 物件，傳入使用者名稱與角色。export、訂閱寄送與快取，頁面沒寫。

三家對資料離開之後的寫法不同：Snowflake 寫了跟著，也寫了條件；Databricks 寫某些操作不支援；Microsoft 依身分決定套不套。Cube、Looker、dbt 讀到的是概念頁，沒寫這類行為。這是本文對頁面類型的整理，不是對產品行為的判斷。

聽到「有權限層」，先問資料離開之後規則在哪裡

表二把本文讀的八個來源放進同一張表，欄位是三個問題，再加一欄頁面沒寫的部分。

表二｜權限掛點與資料離開之後（2026 年 9 至 10 月查閱）

三題裡，最能分出差別的是第三題。Palantir 的 propagation 頁明寫，讀出去之後 row 與 column 政策不跟著。三家的 row 級專頁，寫了 clone、分享或身分例外怎麼處理。Cube 與 Looker 的頁面停在請求或查詢的當下，dbt 的頁面沒寫時點。

所以聽到「這個系統有權限層」，先問第三題。文件答不出來的，設計時就別假設規則會跟著資料走出去。在 Palantir 裡，要讓保護跟著資料走，文件給的路是 marking、CBAC 或 organization 這類 mandatory 控制，不是 row 與 column 政策。

範圍與版本

本文讀的是 2026 年 9 至 10 月的官方頁面，頁面之後會變。Palantir 的頁面全部抓於 2026 年 10 月 1 日。比較頁裡，Cube 的 Access policies、Looker、dbt、Fabric IQ、Snowflake 的 semantic views 概述與 Databricks metric views 抓於 9 月 29 日，其餘抓於 10 月 1 日。8 月 26 日抓的 OSDK 頁快照，不含 Read-time enforcement only 小節。

Read and write authorizations 頁標 beta，頁面寫它可能不在每個 enrollment 上提供；Fabric IQ 的 ontology 與規則頁標 preview。關於這兩處的句子，描述的是文件在這個狀態下的寫法。Remove inherited markings and organizations 頁未標 beta。

幾個讀法是本文的，不是官方的。三個問題是本文的問法，不是官方分類；Palantir 自己用的詞是 two levels、read layer、object set layer，本文讀到的頁面沒有把這套稱為 security layer 或 permission layer。「mandatory 預設隨衍生資料走、另有受控的切斷路徑」，是並讀 propagation、Markings、Remove inherited 與 rw-auth 幾頁的調和；若官方把 propagation 頁那句不帶例外的寫法改寫並加上例外，這個調和就用不上。

「第二把鑰匙拆成兩件」與「why-ontology 和 propagation 講不同時點」也是本文的讀法，官方若另頁改寫，讀法跟著改。兩頁用詞不同的地方，包括移除 marking 的權限、Object security policies 頁與 Managing object security 頁、propagation 頁與 rw-auth 頁，本文只並列；官方若在別頁調和，並列就要改。

「寫了衍生物行為的是 row 級專頁」是對已讀頁面類型的整理，不推誰跑在誰的底層；這些產品的其他頁面若另有寫，這個讀法要改。沒讀到的頁面不是答案：Cube 的 Row-level 與 Member-level 專頁、dbt 的權限子頁、Databricks metric views 的 Control access 內頁、Fabric IQ ontology 的專屬權限頁，本文讀到的快照都沒有內容。表二與正文寫「頁面沒寫」的地方，不等於做不到，也不是誰優誰劣。

常見問題

Q：Palantir 的權限會跟著資料走嗎？ 看是哪一種控制。Palantir 官方文件（2026 年 10 月查閱）的 propagation 頁寫 mandatory controls（markings、CBAC、organizations）隨衍生資料走；Markings 頁寫衍生資源承接標記，除非明確移除，兩頁並讀，本文稱為「預設」跟著走。restricted views、object security policies、property security policies 這些 granular 的 row 與 column 政策，propagation 頁寫不延伸到讀取之外；Projects and roles 頁寫 roles 管資源本身，不延伸到讀出之後的資料。官方另寫了至少兩條受控的切斷路徑：transform 的 stop_propagating（markings）與 stop_requiring（organizations），要受保護分支與審批；action 的 read 與 write authorization（beta），目前選填。

Q：row-level security 讀出去之後還受保護嗎？ 各家頁面寫法不同，要逐家看。Palantir 的 propagation 頁寫讀出之後的資料不帶來源政策，列了函式回傳、AIP Logic、OSDK 回應、匯出等七個出口。Snowflake 的 row access policy 頁寫 clone 跟著政策，CTAS 新表含過濾後的列、欄位上未設政策。Databricks 的 table-level 專頁寫 clone 不支援（ABAC 下被排除者仍可 clone）。Microsoft 的 RLS 頁寫 Viewer 即使有 Build 權限，RLS 仍適用，例子是 Analyze in Excel；service principal 為 final effective identity 時不套用。頁面沒寫的地方，不等於做不到。

Q：markings 和 object security policy 差在哪？ markings 是 mandatory 控制，掛在資源與資料上，隨衍生資料走。object security policy 過濾物件實例（row），property security policy 過濾屬性（column），兩者合起來達成 cell-level security。官方寫兩種政策的 granular 部分不延伸到下游；同一個政策裡的 mandatory 部分預設從資料來源繼承、可以新增或移除，並繼續適用於衍生資料。官方在 most cases 推薦用 object 與 property security policies 管理物件安全。

Q：semantic layer 的權限會不會跟著匯出走？ 本文讀到的 Cube 與 Looker 頁面把規則寫成請求或查詢時套用，匯出與排程寄送的存取行為，Cube 頁面沒寫。Looker 的排程會對每位收件人各跑一次，但那是 dashboard 或 Look 的篩選器設成 user attribute 的用法，不是 access_filter。dbt 頁面對 access permissions 只有一句籠統說明，exports 寫成資料平台裡像一般表的東西。頁面沒寫，不等於做不到。