Last updated: October 15, 2026
TL;DR Foundry governance has two layers. Mandatory controls, like markings and organizations, travel with data through every pipeline. Discretionary controls, like project roles, restricted views, and object security policies, decide who sees what but don’t follow data into exports or AI calls. Use markings for categories like PII, object security policies for row and cell access on the Ontology, and AIP marking allowlists to control what language models can see. Our Ontology services team designs these models.
Palantir Foundry data governance combines mandatory controls, such as markings that travel with data through every derived dataset, with discretionary controls, such as roles, restricted views, and object security policies that limit who sees which rows and properties.
Most Foundry security incidents we hear about aren’t hacks. They’re surprises. A dataset someone thought was restricted feeds an export that isn’t. An AI function returns a field the user was never meant to see. A marking gets removed to fix a broken pipeline and nobody notices what else it was protecting.
The stakes keep rising. IBM’s 2025 Cost of a Data Breach report put the average breach at $4.44 million globally and a record $10.22 million in the US. It also found 13% of organizations reported breaches of AI models or applications, and of those, 97% said they lacked proper AI access controls.
Foundry gives you strong tools for this. The catch is that they’re not interchangeable, and choosing the wrong one creates exactly the gaps above. This guide explains each control, when to use it, how it behaves with AI, and the governance design we use with clients. If the Ontology is new to you, read our Ontology explainer first.
How Does Security Work in Palantir Foundry?
Through two kinds of controls. Mandatory controls, including markings, organizations, and classifications, travel with data through every derivation. Discretionary controls, including project roles, restricted views, and object security policies, grant access in place and don’t follow data downstream.
Palantir’s security overview lays this out clearly. Data and resources live in projects. Discretionary controls are granted to users on individual resources, through the Owner, Editor, Viewer, and Discoverer roles. Mandatory controls travel with each unit of data through derivation.
That one distinction explains most governance mistakes we see.
| Control | Type | What it protects | Follows data downstream? | Best for |
|---|---|---|---|---|
| Project roles | Discretionary | Resources in a project | No | Day-to-day access to work |
| Markings | Mandatory | Whole files, datasets, projects | Yes | Categories like PII, PHI, finance, legal |
| Organizations | Mandatory | Silos between groups | Yes | Separating business units or customers |
| Classifications (CBAC) | Mandatory | Government classification levels | Yes | Classified environments |
| Restricted views | Discretionary | Rows in a dataset | No | Row-level filtering on datasets |
| Object security policies | Discretionary | Object rows and properties | No | Row, column, and cell security on the Ontology |
| Mandatory control properties | Mandatory, per row | Whole object rows by marking | Within the object type | Rows that carry their own markings |
The practical rule. If protection has to survive every pipeline, export, and AI call, it needs a mandatory control. If it’s about who sees which rows in an app, discretionary controls are fine, as long as you know where they stop.
What Are Markings, and How Do They Work?
Markings are labels for sensitive data categories, like PII, with a list of who may access them. They’re all-or-nothing, a user must hold every marking on a resource, and they travel to everything derived from marked data until someone with special permission removes them.
Palantir’s markings documentation is worth reading in full. A few lines matter most.
- Access to a marking is binary, all-or-nothing
- A user must be a member of all the markings on a file, folder, or project to access it
- All resources derived from marked data assume the marking unless it’s explicitly removed
- Removing a marking is a sensitive action that needs the Expand Access permission on the marking itself, and project ownership isn’t enough
- Markings should not be used to provision access
That last point surprises people. Markings aren’t how you give someone access. Roles do that. Markings are a ceiling. Even an Owner of a project can’t see marked data without the marking.
Propagation is the superpower. Palantir’s propagation docs explain that a dataset built from a marked input inherits the marking. So a PII marking on a raw customer table flows into every join, aggregate, and output built from it, without anyone remembering to add it.
It’s also the trap. Remove a marking to unblock one pipeline and you remove it from everything downstream. Palantir’s own guidance on protecting sensitive data recommends simulating a marking on your pipeline to see where it propagates before you apply it. Do the same before you remove one.
Restricted Views vs Object Security Policies, Which Should You Use?
For data modeled in the Ontology, object security policies, which Palantir recommends for most use cases. They control rows and properties, giving cell-level security. Restricted views filter dataset rows and still back some object types, but they’re the older pattern.
Restricted views limit dataset access to rows a user is allowed to see, using granular policies that compare user attributes with column values. A sales rep sees their region’s rows. A clinic manager sees their clinic’s patients.
Object security policies do the same on Ontology objects, and more. Property security policies hide specific properties, and combining the two gives cell-level security, where a user who fails a property policy sees a null instead of the value. Palantir says object security policies are recommended over restricted views for most Ontology use cases, citing near-instant policy updates and support for streaming and branching.
| Need | Use | Why |
|---|---|---|
| Rows of a dataset by region or team | Restricted view | Built for dataset row filtering |
| Rows of an object type | Object security policy | Recommended for the Ontology |
| Hide one property, like salary or diagnosis | Property security policy | Column-level on objects, shows null |
| Rows that carry their own sensitivity labels | Mandatory control property | Row-level mandatory control |
| Encrypt values so even admins see ciphertext | Cipher | Cryptographic obfuscation |
Can you restrict one column on a dataset? Not with a restricted view alone. A Palantir engineer confirmed on the Community forum in 2024 that column-level restricted views aren’t a native primitive. The usual answers are property policies on the Ontology, Cipher, or splitting the sensitive columns into their own dataset with stricter controls.
What Are Mandatory Control Properties?
A mandatory control property is a column on an object type that holds markings or organizations for each row. Users must satisfy those values to see the row at all, and other properties appear null if they don’t. It’s available only on Object Storage v2.
Per Palantir’s mandatory control properties docs, the property secures all other properties in the same data source, must be required, and must be mapped to a marking column on a restricted view. Users need all of the markings in that column, or at least one of the listed organizations.
When does this beat object security policies? When the sensitivity lives with each record. A case management system where some cases are flagged legal-hold, or a supplier list where certain suppliers are under a non-disclosure agreement. The label sits on the row, and the platform enforces it as a mandatory control.
A Community question from December 2025 asked the difference between mandatory control properties and restricted views, and the answer pointed to classification-style labels. That’s the right mental model. Use these when rows carry real security labels, not for ordinary team filtering.
How Do You Control What AI and LLMs Can See in Foundry?
With an AIP marking allowlist. Administrators choose which mandatory markings are allowed in requests to AIP language models, for interactive and automated use. A request is rejected if the user’s token carries any marking outside the list. Model-specific policies can override the default.
This is the most important AI governance control in Foundry, and few teams set it deliberately. Palantir’s documentation on controlling LLM data access says the policy applies to interactive AIP use and automated workflows, and that AIP rejects a request if the token includes any mandatory marking outside the allowlist, even when the specific data in the request doesn’t carry that marking. A scoped session can narrow the markings a user brings into a session, and a model-specific policy completely replaces the enrollment default.
So you can say PII-marked data may go to the internally hosted model but not to an external one. Or that legal-hold data never reaches any model.
Know the other half too. The propagation docs warn that once rows are read, they carry no metadata or tag that could re-apply a discretionary policy. That covers function returns, Action edits, AIP Logic tool calls, OSDK responses, and exports. A restricted view can filter what an AI function reads. It can’t stop the function from passing what it read somewhere else.
On the provider side, Palantir’s AIP security and privacy page states that no customer data is used to retrain third-party models, that prompts and completions aren’t retained by the third party, and that regional endpoints exist for some models in the US, UK, and EU.
Our guides to AIP Logic and Evals and Ontology MCP cover the AI side in more depth, including what changes when outside agents connect.
What Other Governance Tools Does Foundry Include?
Checkpoints for purpose justification, Approvals for access requests, Sensitive Data Scanner for finding PII, Cipher for encryption and hashing, organizations for hard silos, and audit logs that can stream to your SIEM.
Here’s the supporting cast, each worth knowing.
- Checkpoints asks users to justify sensitive actions and records who, when, why, and what, across more than 60 interactions in Foundry
- Approvals routes requests for marking access, project access, and group membership to the right approvers
- Sensitive Data Scanner, formerly Foundry Inference, scans datasets once or on a schedule to find sensitive data, though it may not be on by default
- Cipher encrypts, decrypts, or hashes values with managed keys, like bulk-encrypting a column and decrypting single values for authorized users
- Organizations enforce strict silos, with every user in exactly one organization and optional guest access to others
- Audit logs record user actions, with the newer audit.3 schema cutting latency to 15 minutes or less and supporting direct ingestion into SIEMs through a public API
Checkpoints and Approvals together give you what most privacy regulations ask for in spirit. A recorded reason for access, and a person who approved it.
One reminder about audit logs. Palantir notes their contents should be treated as sensitive because they contain personal data. Govern the audit trail like the data it describes.
How Should You Design a Governance Model in Foundry?
Start with a small marking taxonomy based on data categories, put row and cell rules on the Ontology with object security policies, set an AIP marking allowlist on day one, require justification for sensitive access, and send audit logs to your SIEM. Review all of it quarterly.
Here’s the design sequence we use.
- Classify data categories first. PII, PHI, payment data, legal, finance, and anything regulated in your industry
- Create one marking per category, not per team. Teams change. Categories don’t
- Apply markings at ingestion, on raw datasets, and simulate propagation before you do
- Plan where markings legitimately come off, such as after a pipeline drops or hashes the PII columns, and restrict who holds Expand Access
- Model row and property rules with object security policies on the Ontology
- Set the AIP marking allowlist, and decide per model which markings may reach it
- Turn on Checkpoints for sensitive actions and route access through Approvals
- Stream audit.3 logs to your SIEM and review marking removals monthly
Step 4 is the one teams skip. Palantir’s own example pattern uses a raw-data marking that comes off after PII is processed. That’s healthy, if it’s planned. Unplanned removals are where leaks start.
Healthcare teams have extra obligations, and our post on Palantir in healthcare covers how this looks with patient data. For pipeline design, our Pipeline Builder guide shows where to drop or hash sensitive columns.
What Goes Wrong With Foundry Governance?
Markings used to grant access, markings removed to unblock pipelines, restricted views trusted to protect exports and AI calls, no AIP allowlist, and nobody reviewing audit logs. Every one is a design gap, not a platform flaw.
What we find most often in reviews.
Too many markings. A marking per team and per project, and within a year nobody knows what half of them protect.
Discretionary controls doing a mandatory job. A restricted view protects the app. The export built from the same data goes to a shared drive unfiltered.
The unplanned removal. Someone with Expand Access removes a marking to fix a failing build at 6 p.m. on a Friday. Everything downstream quietly opens up.
No AI policy. AIP gets switched on and the allowlist is left at the default. Is that default right for your data? Somebody should decide on purpose.
Logs nobody reads. Audit data that streams nowhere, or streams somewhere nobody looks.
On compliance, Palantir publishes FedRAMP, DoD Impact Level, SOC 2, and ISO 27001 attestations through its trust materials, and resellers like Carahsoft summarize them. Confirm current status directly with Palantir for your contract. And remember that platform attestations cover the platform. Your configuration is still your responsibility.
Govern the Data, Not Just the Apps
Three takeaways. Use mandatory controls, mainly markings and organizations, for anything that must stay protected through pipelines, exports, and AI. Use object security policies for row and cell access on the Ontology, and know discretionary controls stop at the boundary. And set the AIP marking allowlist deliberately, before the first AI workflow goes live.
PAL4C Labs is an independent, Palantir-exclusive consultancy. We design Ontologies, security models, and AIP workflows for operations, healthcare, and regulated teams, and we’re not affiliated with Palantir.
Inherited a Foundry environment with markings nobody can explain? Send us your current marking list and the AI features you’re turning on. We’ll run a governance review with you, covering propagation, Ontology policies, the AIP allowlist, and audit routing, and hand back a prioritized fix list.
Governance Questions Foundry Teams Ask
Mandatory Control Property vs Restricted View, What’s the Difference?
Mandatory control properties enforce markings or organizations stored on each object row as mandatory controls, and they hide the whole row if the user lacks them. Restricted views filter dataset rows with granular policies as a discretionary control. Use the first when records carry real security labels.
Can We Restrict a Single Column in Foundry?
On the Ontology, yes, with property security policies, which show users a null instead of the value. On datasets there’s no native column-level restricted view, so teams use Cipher, split sensitive columns into a separate dataset, or model the data as objects.
Do Markings Carry Over to Downstream Datasets?
They do. Datasets built from marked inputs inherit the marking automatically until someone with Expand Access on that marking removes it. Simulate propagation before applying or removing one.
How Do We Stop AIP From Seeing PII?
Set the AIP marking allowlist in Control Panel so requests carrying a PII marking are rejected, either for all models or for specific ones. Scoped sessions can also limit which markings a user brings into a session.
Does Palantir or the LLM Provider Train on Our Data?
Not according to Palantir’s AIP security page. It states customer data isn’t used to retrain third-party models and that prompts and completions aren’t retained by the third-party provider. Confirm the terms for your specific models and contract.
How Do We Send Foundry Audit Logs to Splunk or Another SIEM?
Use the audit.3 log schema, which Palantir says can be ingested directly into SIEMs through a public API with latency of 15 minutes or less. Treat the logs themselves as sensitive.
How Do We Require a Reason Before Someone Opens Sensitive Data?
Use Checkpoints, which prompts users for a justification on sensitive actions and stores who, when, why, and what. Pair it with Approvals for access requests that need a sign-off.