Palantir's Row-Level Permissions End at the Read. Markings Don't.

本文另有中文版：Palantir 的 row 權限停在讀取當下，markings 預設跟著資料走

“Does respecting Foundry’s security model guarantee policy enforcement downstream?” The question sits in the FAQ of Palantir’s Access control propagation page (Palantir documentation, read in October 2026).

The answer starts with what applications that respect the security model do guarantee, which is that a user cannot read what they are not authorized to read, and then says “It does not guarantee that what the user reads remains under the source policy after the read”.

The next sentence names the two guarantees: “User-permission inheritance provides the access guarantee; it does not provide the propagation guarantee”.

Palantir’s pages draw that line by control family. Granular row and column policies stop at the read, and project roles govern the resource, not the data read from it. Markings, CBAC and organizations travel with derived data. So when someone says a system has a permission layer, the phrase leaves three things open: where the rule attaches, when it is checked, and where it is once the data has left. This piece puts those questions to Palantir’s pages first, then to pages from Cube, Looker, dbt, Databricks, Snowflake and Microsoft.

Part 1 covered the two gates for seeing an object, and Part 2 the three checks before an action is submitted. This piece starts after the read.

The Ontology’s Permission Structure Has Two Levels, and the Data Side Has Two Paths

Palantir’s Overview page for Object permissioning splits the structure first: “We can conceptualize the Ontology’s authorization structure on these two levels: ontology resources, and objects and links”. Resources such as object types, link types and action types define the schema, and objects and links are the data. This piece is about the data level.

The data level has two documented paths. One is object and property security policies configured on the object type itself; the other is data source policies, which rely on the permissions of the backing data source. The Managing object security page says “Object and property security policies are recommended for managing object security in most cases”. The same page’s section on when to use data source policies names cases where restricted views remain appropriate, such as a dataset used outside the Ontology that needs granular control there.

Object security policies filter object instances, which correspond to rows. Property security policies filter property values. The Object security policies page says the combination of the two is used to achieve cell-level security, and a user who passes the first but not the second sees a null value in place of the property value.

The Object security policies page lists three conditions for access to an object instance and its properties: Viewer access to the object type, passing a granular policy if one is configured, and passing any marking, organization or classification checks. Granular checks and mandatory checks sit in one list, and the sections below pull them apart.

Property values can also point outside the Ontology. The Managing object security page says the mechanisms in that section control the visibility of the property values, not of the additional resources they refer to. It gives an example: “If the media set has different permissions from the object type, then it is possible for a user to not have access to a media reference property, but still be able to fetch the media item directly from the media set”.

So when someone says object-level security in Palantir terms, the first judgment is which level and which data path the statement refers to. Neither answer says anything yet about where data goes after the read.

The Propagation Page Lists Seven Operations That Do Not Carry the Source Policy

The Security overview page says mandatory and discretionary controls differ in propagation: “Data security in the Palantir platform is provided through a combination of mandatory and discretionary controls, which differ in how they propagate”. For granular row and column access controls (restricted views, object security policies and property security policies), the propagation page says they filter what a user can read and do not extend beyond that read.

After the read, the page says, “the rows that the user did receive are ordinary data”. They carry no metadata, classification or tag that later code could use to re-apply the policy.

The page then lists operations that do not carry the source policy. Table 1 sets out the seven in this piece’s paraphrase.

Table 1. The seven operations listed in the Where discretionary controls stop section of the Access control propagation page (granular row and column policies)

For each of the seven, the propagation page says the running user could not have read what they were not authorized to read, so the access guarantee holds. Then it names the gap: “What does not hold is propagation: the constraint that protected the source data does not constrain what happens with that data after the read”.

Webhooks and notifications are not among the seven, and the page does not say whether the list is meant to be exhaustive. The Permissions page for action types says a notification is sent only to recipients who have access to the data in it, that webhook side effects are not enabled by default, and that configuring a webhook plugin takes additional permissions. The Action types overview, Side effects and Webhooks pages do not say, in their body text, whether the source policy continues with the data they send.

The list works as a checklist. When a design routes data through any of the seven, the row and column policy stays behind, and the question becomes what governs the data at the destination. For protection that has to reach downstream, the propagation page gives its own answer: “Use a mandatory control (a marking, CBAC classification, or organization); mandatory controls propagate”.

Markings, CBAC and Organizations Propagate Through Derivation, and Removing a Marking Is a Sensitive Action

The other family behaves differently. The propagation page says “Mandatory controls travel with data through derivation and downstream consumption”, and adds that the platform enforces them regardless of any user’s role or any application’s logic.

Three controls belong to the mandatory family. Markings apply to datasets, transactions, files and columns. Organizations are mandatory boundaries between groups of users and groups of resources.

Classification-based Access Controls (CBAC) are described on the propagation page as column-level mandatory controls keyed to user clearance levels, while the CBAC page itself speaks of file, data and project classifications, and says “Classification-based Access Controls are not enabled by default on Foundry”.

On the propagation page, a dataset built from a marked input inherits the marking on its transactions, so the movement runs from upstream data to downstream data. The CBAC page adds a limit: “Project classifications do not affect the data classification of datasets in a project, so project classifications are not inherited along data dependencies”.

The Markings page says derived resources assume a marking “unless the Marking is explicitly removed”. This piece calls that the default, a reading of the propagation page and the Markings page together with the cut routes described below. In the part of the Markings page about one Marking per sensitive data owner, the reason given is owner control: the data owner must grant the Marking to anyone who is to use derived resources.

Removing a marking is treated as a sensitive action. The Markings page describes two routes. A marking can be removed from the file, folder or Project where it was applied, and the removal reaches downstream files and data dependencies. Or, in the page’s words, “Alternatively, a Marking can be removed in a transformation, which would only remove the Marking along data dependencies”.

Two pages describe the permission needed, with different wording. The Markings page says “The Expand Access permission on the Marking itself, a centrally managed permission, is required to remove a Marking”, and adds that the Owner role on a marked dataset does not substitute for it. The Remove inherited markings and organizations page says “Special user permissions are necessary to approve the removal of inherited Organizations and Markings”, and names Remove marking permissions for markings and Expand access permissions for organizations.

The propagation page’s FAQ states the trade-off in one sentence: “Removing the marking trades a control that travels through derivation for one that does not”.

Granular Policies and Roles Stop at the Read, While an Object Security Policy’s Mandatory Controls Continue

A single object security policy can hold both behaviors. The Object security policies page says “By default, an object security policy will inherit all mandatory controls from its data sources”, where inherit runs from the data source into the policy. The policy can then add mandatory controls and remove inherited ones, and the page’s example stops inheriting two markings so that users without them can see object instances.

Two pages then say what these policies do downstream. The Object security policies page takes the whole object or property security policy as its subject: the policies filter what a user can read, users can never read object instances or property values they are not authorized to see, and “These controls do not extend to downstream outputs or exports”, with no exception sentence.

The Managing object security page limits the subject to the granular row and column controls within the policy, keeps the do-not-extend sentence, and adds “However, mandatory and classification-based controls within the same policy continue to apply to derived data”.

Roles sit in the discretionary family. The propagation page defines project roles as the Owner, Editor, Viewer and Discoverer grants that determine who can read or modify resources in a project, and says projects are the primary container for role grants while mandatory controls provide the hard boundary that derived artifacts cannot escape. The Projects and roles page draws the line this piece has been following: “Roles, by contrast, govern access to the resource itself; they do not extend to data after it has been read from the resource”.

Roles also inherit, in a different direction. The Projects and roles page says “Importantly, like mandatory controls, role grants inherit to child resources”. That movement runs down the resource hierarchy, from a project or folder to its child resources, not along the data dependencies that carry a marking.

Documented Ways to Cut Propagation Exist, and the Action Route Is Beta

Reading the previous sections as “mandatory follows the data, without exception” would be a mistake. The propagation page’s own sentence, “Propagation means that no derived artifact can expose data to a user who lacks the required marking, classification, or organization membership”, has to be read together with the routes below. This piece’s reading is that propagation is the default and that Palantir documents controlled ways to cut it.

The first route runs through pipelines. The Remove inherited markings and organizations page says “This process of removing inherited Markings and Organizations can be done by using the stop_propagating and stop_requiring input transform properties”. The page says the key phrases apply to Organizations and Markings, not to Roles.

The route needs process: “The repository needs to have at least one protected branch (for example, main). This branch must also enforce at least one required approver”. After the output dataset is built, it no longer has the propagated Markings or Organizations.

The second route runs through actions. The Read and write authorizations page (beta) says the feature may not be available on every enrollment, and that it adds security boundaries to an action type. Its section on mandatory marking guarantees sits beside the propagation page’s guidance, and the two put the weight in different places.

Where the propagation page says mandatory controls propagate, the authorizations page says “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”.

The Permissions page for action types points to both: its Read-time enforcement only section says granular controls do not extend to the action’s write and refers readers to the propagation page, and a later section refers readers to the authorizations page.

On the authorizations page, an action can produce output at the same, higher or lower security than the data it reads. When write authorization is set less restrictive than read authorization, the page says “This intentionally severs mandatory marking propagation and may result in data declassification”. When the two differ, Foundry checks whether the user saving or publishing the action type may declassify every marking severed in between, and does not repeat the check at runtime.

The page also says read and write authorizations are currently optional. With no read authorization configured, Foundry does not perform the declassification check at save or publish time, and the page says “The action can therefore read data above its write boundary and write less restrictive data, which can cause a data spill”.

Other removal practices exist. The Markings page describes removing a marking at its origin, and an object security policy can stop inheriting markings. The transform route and the action route are the two this piece read as controlled cut routes, not a complete list.

When someone says markings follow the data, the question to ask is which route the derivation took: ordinary derivation, a transform with stop_propagating behind a protected branch, or an action whose read and write authorizations differ.

AI Tool Calls and SDK Responses Appear on the Exits List, While the Tool-Use Sentence Speaks About Access

Two sentences in Palantir’s pages mention AI tool use, and they do not describe the same moment. The Why Ontology page says “Tool usage is dynamically enforced through the same security architecture that governs data access and all forms of memory”, and adds that tool invocations depend on access to the underlying objects, properties and links.

The propagation page speaks about the data afterward. For AIP Logic tool calls it says “Once in context, the data can be summarized, transformed, and returned through any of the model’s output paths with no remaining association to the source policy”.

This piece’s reading is that the two pages describe different points in time: the Why Ontology sentence covers access to objects at invocation, and the propagation sentence covers data after it enters the model’s context.

The OSDK page shows the same split from the developer’s side. The OSDK uses a token scoped to the ontological entities an application may access, in addition to the user’s own permissions. Under a subsection titled Read-time enforcement only, the page says “These controls do not extend to the OSDK response payload or to anything your application does with the data”, and names the remedy: pair the controls with a marking or CBAC.

Cube and Looker Pages Write the Rule as Applied While a Request Runs, and dbt’s Page Has One General Sentence

Cube’s Access policies page (Cube documentation, read in September 2026) says “When processing a request, Cube will evaluate the access policies and combine them with relevant custom security rules”. The Security context page (read in October 2026) adds that the generated SQL includes row-level constraints from the access control rules. For data leaving through exports or scheduled delivery, the Cube pages read do not describe access behavior.

Looker’s pages (Looker documentation, read in September 2026) are specific about scope. The access_filter page says “If you forget to add access_filter to an Explore that should have it, the data will not be restricted and users will be able to see all the data in that Explore”, and that the parameter belongs to a single Explore.

Two Looker statements concern scheduled output and data actions, and neither is about access_filter. The User attributes page says a schedule whose dashboard or Look filter uses a user attribute runs once for each recipient, and every recipient must have a Looker account. It also says data actions can be configured to include certain user attributes in their JSON payload. The pages read on the action parameter and on BigQuery write-back do not say whether data sent by an action is bound by access_filter.

dbt’s Semantic Layer page (dbt documentation, read in September 2026) has one sentence on the subject: “To ensure secure access control, the Semantic Layer implements robust access permissions mechanisms”. Nothing on the page describes what the mechanism contains or when it applies.

The dbt Exports page does say where exported data lands: exports write the output of saved queries to a table or view within the data platform, under the production environment’s default credentials, and the page says “Essentially, exports are like any other table in your data platform”. Because the access permissions sentence does not say what the mechanism contains, the pages read do not say whether it extends to an export table.

Microsoft’s Fabric IQ ontology (preview) page (Microsoft documentation, read in September 2026) says “Fabric workspace and item permissions control access to ontology items. Authoring and querying respect access to bound data, including OneLake security and source-enforced row-level security (RLS), object-level security (OLS), and column-level security (CLS), alongside programmatic access and CI/CD capabilities”.

The Define Business Rules (preview) page says a business rule is a natural-language definition that the ontology does not run against data or use to execute actions, and does not say what runs it. The pages read do not say under whose identity an agent reaches the bound source, or whether a materialized graph inherits source RLS.

Dedicated Row-Level Pages From Snowflake, Databricks and Microsoft Describe Clones, CTAS Tables, Sharing and Scope Exceptions

The pages that write down what happens to derivative objects, or where a rule’s scope ends, share a type: each is a dedicated page on row-level rules, and none is a concept page. This piece’s reading is about page type. The Snowflake row access policy page, the Databricks page on the table-level form of row filters and column masks, and the Microsoft Power BI RLS page describe derivative behavior or scope exceptions, while the Cube, Looker, dbt, Snowflake semantic view and Databricks metric view pages read do not.

Snowflake’s Understanding row access policies page (Snowflake documentation, read in October 2026) says the policy is evaluated under the role of its owner, not the role of the operator running the query. On cloning it says “A cloned table maps to the same policies as the source table”.

For a table created from a query, the page says “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”.

Sharing has a condition. The page says “If the provider assigns a policy to a shared table or view and the policy conditions call the CURRENT_ROLE or CURRENT_USER function, or the policy conditions call a secure UDF, Snowflake returns a NULL value for the function or the UDF in the consumer account”. The page gives the reason: the owner of the shared data does not typically control the users or roles in the consumer account.

Semantic views leave a question open. The semantic views SQL page (read in October 2026) says “To query a semantic view, you don’t need the SELECT privilege on the tables used in the semantic view”, and that this matches the privileges needed to query standard views. The row access policy page says the policy applicable to a table is always executed first when views are nested. The Overview of semantic views page (read in September 2026) says that currently Cortex Agents reads the semantic view definition and generates SQL against the physical tables directly. No page read states whether a table’s row access policy applies when a semantic view is queried.

Databricks’s page (Databricks documentation, read in October 2026) says it describes the table-level form of row filters and column masks, which are configured on individual tables and managed by the table owner, and it restricts rows and column values at query time. On this table-level page, deep and shallow clones are not supported on tables with row-level security or column masks, with an ABAC exception: “In ABAC configurations, users who are explicitly excluded from a policy can still perform clone operations on the underlying data”. The page’s other unsupported lines, for views, AI Search indexes and REST access, are in Table 2.

Microsoft’s Power BI RLS page (Microsoft documentation, read in October 2026) says “Even if Viewers are given Build permissions to the semantic model, RLS still applies”, and uses Analyze in Excel as an example: Viewers with Build permissions using it remain restricted by RLS. Workspace Admin, Member and Contributor roles are outside RLS.

For service principals the page says “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”. The same page describes a path for embedding: passing an EffectiveIdentity object with a username and roles when generating an embed token. The page does not discuss export, subscription delivery or caching.

Ask a Permission Layer Where Its Rule Is Once the Data Leaves

Table 2 applies the three questions from the opening to eight sources. The last two columns separate what the page says about data leaving from what the pages read leave unsaid.

Table 2. Where the rule attaches, when it is applied, and what the pages say about data leaving (pages read in September and October 2026)

Of the three questions, the third is the one that separates these sources. Palantir’s propagation page keeps the access guarantee apart from propagation and names seven operations where the source policy stays behind. The dedicated row-level pages from Snowflake, Databricks and Microsoft describe clones, tables created from queries, sharing and identity exceptions, although Databricks’s table-level page lists unsupported operations rather than making a propagation statement. The Cube and Looker pages stop at the moment a request or query runs, and the dbt page offers one general sentence.

So when a colleague says a system has a permission layer, ask the third question first. Where the documentation gives no answer, a design should not assume the rule leaves with the data. In Palantir, the documented way to make protection travel is a marking, CBAC classification or organization, not a row or column policy.

Scope and Versions

Palantir’s pages were read on October 1, 2026. Among the comparison pages, the Cube Access policies, Looker, dbt, Fabric IQ, Snowflake semantic view overview and Databricks metric views pages were read on September 29, 2026, and the others on October 1. A snapshot of the OSDK overview page taken on August 26 does not contain the Read-time enforcement only subsection. Pages change, so a sentence worth relying on is worth checking against the live page.

Read and write authorizations are labeled beta, and their page says the feature may not be available on every enrollment. The Fabric IQ ontology and business rules pages are labeled preview. Statements about them describe documentation in that state. The Remove inherited markings and organizations page carries no beta label.

Several readings here are this piece’s own. The three questions are a way of reading these pages, not a vendor classification; Palantir’s pages use the terms two levels, read layer and object set layer, and the Palantir pages read do not call the whole arrangement a security layer or a permission layer. Calling propagation the default, with controlled cut routes, reconciles the propagation, Markings, Remove inherited and authorizations pages; if Palantir adds exception wording to the propagation page’s sentence that no derived artifact can expose data to a user who lacks the required controls, that reconciliation no longer holds.

The point-in-time reading of the Why Ontology and propagation sentences would change if Palantir wrote the first to include propagation. Where two pages word the same point differently, as with the permission needed to remove a marking, the two object security pages, and the propagation and authorizations pages, this piece sets them side by side, and a reconciling page elsewhere would change that.

The observation that derivative behavior appears on dedicated row-level pages is about page type among the pages read, not about product behavior, and other pages from those products could change it. Pages not read are not answers: the Cube Row-level and Member-level pages, dbt’s permission subpages, the Databricks metric views Control access page and the Fabric IQ ontology permissions page had no content in the snapshots read for this piece. Where this piece says a page does not say something, it describes the pages read, not what the products do.

Frequently Asked Questions

Q: Do Palantir’s permissions follow the data once it leaves the system? It depends on the control family. Palantir’s Access control propagation page says mandatory controls (markings, Classification-based Access Controls, organizations) propagate through derivation, and the Markings page says derived resources assume a marking unless it is explicitly removed; “default” is this piece’s word for reading the two pages together. The propagation page says restricted views, object security policies and property security policies do not extend beyond the read, and the Projects and roles page says roles govern the resource itself and do not extend to data after it has been read. The documentation describes at least two controlled cut routes: the transform properties stop_propagating (markings) and stop_requiring (organizations), which need a protected branch and an approver, and read and write authorizations on action types, which are labeled beta and currently optional.

Q: Is row-level security still enforced after the data has been read? The pages read give different answers by product. Palantir’s propagation page lists seven operations, such as function return values, OSDK responses and exports, that do not carry the source policy. Snowflake’s row access policy page says a cloned table maps to the same policies. Microsoft’s Power BI page says that even if Viewers are given Build permissions, RLS still applies, and uses Analyze in Excel as its example. Databricks’s page on the table-level form of row filters and column masks says clones are not supported on such tables, with an exception for users explicitly excluded in ABAC configurations.

Q: What is the difference between markings and an object security policy in Palantir? In the documentation, markings are a mandatory control that propagates through derivation. An object security policy filters object instances (rows), a property security policy filters property values (columns), and the two together achieve cell-level security. The documentation says the granular parts of these policies do not extend to downstream outputs or exports. The two meet inside one policy: an object security policy inherits the mandatory controls of its data sources by default, and the Managing object security page says the mandatory and classification-based controls within the same policy continue to apply to derived data.

Q: Do semantic layer permissions follow data into exports? The pages read answer that only in part for the semantic layer family. Cube’s and Looker’s pages describe rules applied while a request or query runs, and the dbt page read has one general sentence about access permissions. The pages that describe derivative behavior such as clones, CTAS tables and sharing, or scope exceptions such as Analyze in Excel for Viewers with Build permissions, are the dedicated row-level pages of Snowflake, Databricks (table-level) and Microsoft. A page that does not mention exports is not evidence that no rule applies.