Palantir's Security Model: Why Governments Trust It with Classified Data

“

Series: S1 Palantir Decoded · Article 12 | Level: Beginner | Reading Time: 15 min

#TL;DR

Palantir's security model originates from military intelligence compartmentalization (TS/SCI), embedding the "Need-to-Know" principle into the platform's foundation -- not bolted-on access control, but security-first architecture from the very first line of code.
Palantir simultaneously implements RBAC (role-based), ABAC (attribute-based), and PBAC (policy-based) access control models, supporting row-level, column-level, and cell-level fine-grained permissions with dynamic data masking.
coomia-dip implements this through PolicyEngineService with three-model evaluation, 6 masking modes (full/partial/hash/range/generalization/null), 7-tier data classification (A1-D), and query rewriting for transparent access control.

#Introduction: When "Data Breach" Means Lives Lost

For most enterprises, data security is a compliance issue -- fines, reputation damage, customer churn.

But for Palantir's core customers, data security is life or death:

Code

Data security stakes for Palantir's customers:

+-----------------------------------------------------+
|  US Department of Defense (DoD)                      |
|  - Handles TS/SCI intelligence (Top Secret/          |
|    Sensitive Compartmented Information)               |
|  - Breach consequence: Agent identities exposed,     |
|    military operations compromised, casualties       |
|                                                       |
|  Central Intelligence Agency (CIA)                   |
|  - Handles human intelligence source information     |
|  - Breach consequence: Informants killed,            |
|    intelligence networks collapsed                   |
|                                                       |
|  UK GCHQ                                             |
|  - Handles signals intelligence and comms monitoring |
|  - Breach consequence: Surveillance capabilities     |
|    exposed, national security damaged                |
|                                                       |
|  NHS (UK National Health Service)                    |
|  - Handles medical records for 65 million people     |
|  - Breach consequence: Patient privacy violation,    |
|    legal proceedings                                 |
|                                                       |
|  JPMorgan Chase                                      |
|  - Handles trading data and client financial info    |
|  - Breach consequence: Regulatory penalties,         |
|    market manipulation risk                          |
+-----------------------------------------------------+

These customers do not accept "we did our best." They need mathematically provable security guarantees.

This is the design starting point of Palantir's security model -- not to pass compliance audits, but to protect lives.

#Part 1: Military Information Compartmentalization -- Origins of Palantir's Security Model

#1.1 The TS/SCI Classification System

The US government's information classification system is the direct inspiration for Palantir's security model:

Code

US Government Information Classification Levels:

+------------------------------------------------+
|  TOP SECRET / SCI                               |
|  (Sensitive Compartmented Information)           |
|  - Disclosure would cause "exceptionally grave"  |
|    damage to national security                   |
|  - Requires special clearance + need-to-know     |
|                                                  |
|  +------------------------------------------+   |
|  |  SCI Compartments                         |   |
|  |                                            |   |
|  |  +--------+ +--------+ +--------+        |   |
|  |  | HCS    | | SI     | | TK     |        |   |
|  |  | Human  | | Signals| | Space  |        |   |
|  |  | Intel  | | Intel  | | Intel  |        |   |
|  |  | Source | |        | |        |        |   |
|  |  +--------+ +--------+ +--------+        |   |
|  |                                            |   |
|  |  Even with TS clearance, you cannot        |   |
|  |  access a compartment without that         |   |
|  |  compartment's specific authorization      |   |
|  +------------------------------------------+   |
+------------------------------------------------+
|  SECRET                                         |
|  - Disclosure would cause "serious" damage       |
+------------------------------------------------+
|  CONFIDENTIAL                                   |
|  - Disclosure would cause damage to national     |
|    security                                      |
+------------------------------------------------+
|  UNCLASSIFIED                                   |
|  - Public information                            |
+------------------------------------------------+

#1.2 The "Need-to-Know" Principle

Military security is not just about "do you have clearance" -- it is about "do you need to know":

Code

Traditional permission model:      Military security model:

Question: Do you have              Q1: Is your clearance level
  permission?                          sufficient?
  |                                    |
  +-- Yes -> Allow                     +-- No -> DENY
  +-- No  -> Deny                      +-- Yes -> Q2:
                                            Do you have the required
                                            compartment access?
                                              |
                                              +-- No -> DENY
                                              +-- Yes -> Q3:
                                                  Do you NEED to know
                                                  this information?
                                                    |
                                                    +-- No -> DENY
                                                    +-- Yes -> ALLOW

Even if you are a General (highest authority),
if you are not part of this mission, you cannot
see mission-related intelligence.

Palantir embedded this three-layer check model directly into the platform:

Code

Palantir's Three-Layer Access Check:

+------------------------------------------+
|  Layer 1: Authentication                  |
|  "Who are you?"                           |
|  - SSO / SAML / OAuth 2.0                |
|  - MFA (Multi-Factor Authentication)      |
|  - PKI Certificates (military)            |
+-----------------+------------------------+
                  | Passed
                  v
+------------------------------------------+
|  Layer 2: Authorization                   |
|  "What are you allowed to do?"            |
|  - RBAC: Role checks                      |
|  - ABAC: Attribute checks                 |
|  - PBAC: Policy checks                    |
+-----------------+------------------------+
                  | Passed
                  v
+------------------------------------------+
|  Layer 3: Data-Level Control              |
|  "What data can you see?"                 |
|  - Row filtering: Only your dept's data   |
|  - Column control: Sensitive cols hidden   |
|  - Dynamic masking: Partial obfuscation    |
+------------------------------------------+

#Part 2: RBAC + ABAC + PBAC -- Triple Model Coordination

#2.1 RBAC -- Role-Based Access Control

RBAC is the foundational permission layer -- determining what users can do based on their role:

Code

RBAC Role Hierarchy Example:

                    +------------+
                    | Platform   |
                    | Admin      |
                    | (Global)   |
                    +-----+------+
                          |
              +-----------+-----------+
              |           |           |
        +-----+----+ +---+------+ +--+--------+
        | Data     | | Business | | Security  |
        | Admin    | | Admin    | | Admin     |
        | (Config) | | (Ops)    | | (Perms)   |
        +-----+----+ +---+------+ +--+--------+
              |           |           |
        +-----+---+   +--+--+    +---+---+
        |     |   |   |     |    |       |
      +-+-+ +-++ +-++ +-++ +-++ +-++ +--++
      |Ana| |Ed| |Vi| |Op| |Vi| |Au| |Co|
      |lys| |it| |ew| |er| |ew| |di| |nf|
      |t  | |or| |er| |at| |er| |to| |ig|
      |   | |  | |  | |or| |  | |r | |  |
      +---+ +--+ +--+ +--+ +--+ +--+ +--+

RBAC Permission Matrix:

Role	Read Data	Modify Data	Execute Action	Manage Perms	View Audit
Viewer	Own dept	-	-	-	-
Analyst	Global	-	-	-	-
Operator	Own dept	Own dept	Own dept	-	-
Editor	Global	Global	Global	-	-
Biz Admin	Global	Global	Global	Own dept	Own dept
Sec Admin	Global	-	-	Global	Global
Platform Admin	Global	Global	Global	Global	Global

#2.2 ABAC -- Attribute-Based Access Control

RBAC tells us "what you can do," ABAC tells us "under what conditions":

Code

ABAC Policy Example:

Policy: "Regional Data Access"
+---------------------------------------------+
|  Subject Attributes (User):                  |
|    - user.department = "East Region"         |
|    - user.clearance_level >= "SECRET"        |
|    - user.employment_status = "ACTIVE"       |
|                                               |
|  Resource Attributes (Data):                 |
|    - data.region = "East Region"             |
|    - data.classification <= "SECRET"         |
|                                               |
|  Environment Attributes (Context):           |
|    - time.current BETWEEN 08:00 AND 22:00   |
|    - network.type = "INTERNAL"               |
|    - device.compliant = true                 |
|                                               |
|  Action: READ                                |
|                                               |
|  Decision: PERMIT                            |
|  Condition: user.department == data.region   |
|        AND  user.clearance >= data.class     |
|        AND  network.type == "INTERNAL"       |
+---------------------------------------------+

ABAC's power lies in expressing extremely fine-grained access conditions:

Scenario	Can RBAC do it?	ABAC Policy
Only see own region's data	Need role per region	`user.region == data.region`
Business hours only	Cannot	`time BETWEEN 08:00 AND 22:00`
Internal network only	Cannot	`network.type == "INTERNAL"`
Within contract period	Cannot	`contract.end_date > now()`
High-sec requires dual approval	Cannot	`data.class >= SECRET AND approvers >= 2`

#2.3 PBAC -- Policy-Based Access Control

PBAC is the highest-level policy abstraction -- defining organizational security policies:

Code

PBAC Policy Layers:

+--------------------------------------------+
|  Organizational Policies                    |
|                                              |
|  Policy 1: "Data Sovereignty"               |
|  - China-region customer data cannot leave  |
|    the country                              |
|  - EU data must comply with GDPR            |
|                                              |
|  Policy 2: "Least Privilege"                |
|  - All permissions default to DENY          |
|  - Explicit grant required for access       |
|                                              |
|  Policy 3: "Separation of Duties"           |
|  - Creator cannot approve own content       |
|  - Data admins cannot modify audit logs     |
|                                              |
|  Policy 4: "Temporal Decay"                 |
|  - Temporary permissions auto-expire        |
|  - Departed employee access revoked         |
|    immediately                              |
+--------------------------------------------+

How the three models work together:

Code

Evaluation flow when an access request arrives:

Request: User A wants to read Order #12345

+----------+
| RBAC     | -> User A's role is "Buyer",
| Check    |    has read permission -> PASS
+----+-----+
     |
     v
+----------+
| ABAC     | -> Buyers can only see own dept data
| Check    |    Order #12345 belongs to "East Procurement"
|          |    User A belongs to "East Procurement" -> PASS
+----+-----+
     |
     v
+----------+
| PBAC     | -> Org policy: Internal network required
| Check    |    for procurement data
|          |    Current network: Internal -> PASS
|          |
|          | -> Org policy: Business hours access
|          |    Current time: 14:30 -> PASS
+----+-----+
     |
     v
   ALLOW (but may require data masking)

#Part 3: Dynamic Data Masking

#3.1 Why "Dynamic" Masking?

Traditional data masking is static -- creating a masked copy of the data. The problems:

Code

Static masking issues:

Original database:
+----------+----------------+-------------+----------+
| Name     | ID Number      | Phone       | Income   |
+----------+----------------+-------------+----------+
| John Doe | 123-45-6789    | 555-123-4567| $85,000  |
+----------+----------------+-------------+----------+
         |
         | Create masked copy
         v
Masked copy:
+----------+----------------+-------------+----------+
| Name     | ID Number      | Phone       | Income   |
+----------+----------------+-------------+----------+
| J***     | 123-**-****    | 555-***-4567| $85,000  |
+----------+----------------+-------------+----------+

Problem 1: Two copies of data, hard to synchronize
Problem 2: Everyone sees the same masked result -- inflexible
Problem 3: Masked data often unusable for analytics

Palantir's dynamic masking is real-time and role-based -- same data, different views for different users:

Code

Dynamic masking -- same data, different views:

Original data (single copy):
+----------+----------------+-------------+----------+
| Name     | ID Number      | Phone       | Income   |
+----------+----------------+-------------+----------+
| John Doe | 123-45-6789    | 555-123-4567| $85,000  |
+----------+----------------+-------------+----------+

Customer service sees:          Risk analyst sees:
+------+------+---------+---+  +--------+-----------+---------+---------+
| J*** | **** | ***-4567| **|  |John Doe| 123-**-***| ***-4567| $85,000 |
+------+------+---------+---+  |        | 9         |         |         |
 (Name initial + last 4 phone)  +--------+-----------+---------+---------+
                                 (More detail, SSN partially masked)

Compliance auditor sees:        System admin sees:
+--------+-----------+---------+---------+  Full original text
|John Doe| 123-45-***| 555-123 | $85,000 |  (has complete access)
|        | 9         | -4567   |         |
+--------+-----------+---------+---------+
 (SSN partially masked)

#3.2 Six Masking Modes

Mode	Effect	Use Case	Example
Full	Complete replacement	No view permission	`John Doe` -> `***`
Partial	Preserve some characters	Identity verification	`555-123-4567` -> `555-***-4567`
Hash	Irreversible transform	Data correlation analysis	`John Doe` -> `a7b3c9`
Range	Show range, not exact value	Statistical analysis	`$85,200` -> `$80K-90K`
Generalization	Reduce precision	Trend analysis	`1990-03-15` -> `1990s`
Null	Return null	Complete hiding	`John Doe` -> `null`

#3.3 Masking Rule Configuration

Python

# Masking policy configuration example
masking_policy = {
    "object_type": "Customer",
    "rules": [
        {
            "property": "ssn",
            "rules_by_role": {
                "customer_service": {
                    "mode": "full",
                    "reason": "CS does not need SSN"
                },
                "risk_analyst": {
                    "mode": "partial",
                    "keep_first": 3,
                    "keep_last": 4,
                    "mask_char": "*",
                    "reason": "Risk needs first/last for verification"
                },
                "compliance_officer": {
                    "mode": "partial",
                    "keep_first": 5,
                    "keep_last": 4,
                    "mask_char": "*",
                    "reason": "Compliance needs area code"
                },
                "admin": {
                    "mode": "none",
                    "reason": "Admin full access",
                    "requires_mfa": True
                }
            }
        },
        {
            "property": "phone_number",
            "default_mode": "partial",
            "keep_first": 3,
            "keep_last": 4,
            "mask_char": "*"
        },
        {
            "property": "annual_income",
            "rules_by_role": {
                "customer_service": {"mode": "null"},
                "risk_analyst": {"mode": "range", "step": 10000},
                "default": {"mode": "null"}
            }
        }
    ]
}

#Part 4: Row-Level and Column-Level Security

#4.1 Column-Level Security

Different roles see different columns:

Code

Employee Data Table:

Admin view (all columns visible):
+------+--------+--------+--------+--------+--------+
| EmpID| Name   | Dept   | Title  | Salary | Rating |
+------+--------+--------+--------+--------+--------+
| E001 | Alice  | Engg   | Sr Eng | 145000 |  A     |
| E002 | Bob    | Sales  | Mgr    | 165000 |  B+    |
+------+--------+--------+--------+--------+--------+

Department manager view (salary hidden):
+------+--------+--------+--------+--------+
| EmpID| Name   | Dept   | Title  | Rating |
+------+--------+--------+--------+--------+
| E001 | Alice  | Engg   | Sr Eng |  A     |
| E002 | Bob    | Sales  | Mgr    |  B+    |
+------+--------+--------+--------+--------+

Regular employee view (basic info only):
+------+--------+--------+--------+
| EmpID| Name   | Dept   | Title  |
+------+--------+--------+--------+
| E001 | Alice  | Engg   | Sr Eng |
| E002 | Bob    | Sales  | Mgr    |
+------+--------+--------+--------+

#4.2 Row-Level Security

Different roles see different rows:

Code

Orders Data Table:

Global admin sees all data (1,247 rows):
+--------+--------+----------+----------+
| Order  | Region | Customer | Amount   |
+--------+--------+----------+----------+
| PO-001 | East   | Client A | $7,500   |
| PO-002 | North  | Client B | $2,600   |
| PO-003 | East   | Client C | $4,500   |
| PO-004 | South  | Client D | $9,700   |
| ...    | ...    | ...      | ...      |
+--------+--------+----------+----------+

East region manager sees only East data (423 rows):
+--------+--------+----------+----------+
| Order  | Region | Customer | Amount   |
+--------+--------+----------+----------+
| PO-001 | East   | Client A | $7,500   |
| PO-003 | East   | Client C | $4,500   |
| ...    | ...    | ...      | ...      |
+--------+--------+----------+----------+

Key: The user has no idea other regions' data even exists!

#4.3 Combined Row-Column Fine-Grained Control

In real scenarios, row-level and column-level security often need to combine:

Code

Combined effect: East region customer service rep

Row filter:    region = "East"
Column filter: hide [salary, performance]
Dynamic mask:  phone number partial mask

Result:
+----------+--------+--------+-------------+
| Customer | Region | Tier   | Phone       |
+----------+--------+--------+-------------+
| Alice    | East   | VIP    | 555-***-4567|
| Charlie  | East   | Normal | 555-***-2345|
+----------+--------+--------+-------------+

Three security layers active simultaneously:
1. Row filter   -> Only East region customers
2. Column filter -> Sensitive columns hidden
3. Dynamic mask  -> Phone number partially hidden

#Part 5: Data Classification and Labeling

#5.1 Why Data Classification?

Different sensitivity levels require different protection levels:

Code

Data Classification Hierarchy:

+---------------------------------------------+
|  Level 4: Top Secret                         |
|  - Military operation plans                  |
|  - Core algorithm source code                |
|  - Unreleased M&A information                |
|  Protection: Encrypted storage + approval    |
|  access + full audit + air-gapped            |
+---------------------------------------------+
|  Level 3: Confidential                       |
|  - Customer PII (Personally Identifiable)    |
|  - Financial statements (pre-release)        |
|  - Employee compensation data                |
|  Protection: Encrypted storage + role-based  |
|  + access audit                              |
+---------------------------------------------+
|  Level 2: Internal                           |
|  - Internal procedures                       |
|  - Meeting minutes                           |
|  - Project plans                             |
|  Protection: Intranet + basic role control   |
+---------------------------------------------+
|  Level 1: Public                             |
|  - Product manuals                           |
|  - Company website content                   |
|  - Published financial reports               |
|  Protection: No special requirements         |
+---------------------------------------------+

#5.2 Automatic Classification Tagging

Palantir supports automatic data labeling:

Code

Automatic Classification Rule Engine:

Data ingestion
    |
    v
+----------------------------------+
|  Classification Rule Engine       |
|                                    |
|  Rule 1: Regex Matching           |
|  - SSN pattern     -> PII tag     |
|  - Phone pattern   -> PII tag     |
|  - Credit card     -> FINANCIAL   |
|                                    |
|  Rule 2: Column Name Matching     |
|  - *password*  -> CREDENTIAL      |
|  - *salary*    -> COMPENSATION     |
|  - *ssn*       -> PII             |
|                                    |
|  Rule 3: Data Source Tagging      |
|  - From HR system  -> INTERNAL    |
|  - From CRM        -> CUSTOMER    |
|  - From gov API    -> GOVERNMENT  |
|                                    |
|  Rule 4: ML Classification        |
|  - NLP sensitive text detection   |
|  - Pattern recognition for        |
|    anomalous data formats         |
+----------------------------------+
    |
    v
Data auto-tagged: [PII, FINANCIAL, Level-3]

#Part 6: Audit Trail -- Who Saw What

#6.1 Full-Chain Audit

Palantir records not just "who changed what" but also "who saw what":

Code

Audit Event Types:

+----------------------------------------------+
|  Data Access Audit (Read Audit)               |
|                                                |
|  Time: 2026-03-24 14:30:52                     |
|  User: zhang.wei@company.com                   |
|  Operation: SEARCH                             |
|  Object Type: Customer                          |
|  Query: region="East" AND tier="VIP"           |
|  Rows Returned: 47                              |
|  Columns Accessed: [name, phone, tier]         |
|  Masking Applied: phone -> partial_mask        |
|  Source IP: 10.0.12.47                          |
|  Device ID: DEV-A3B7C9                          |
|  Session Duration: 12min                        |
+----------------------------------------------+

+----------------------------------------------+
|  Data Export Audit                             |
|                                                |
|  Time: 2026-03-24 15:12:08                     |
|  User: li.si@company.com                       |
|  Operation: EXPORT_CSV                         |
|  Object Type: Order                             |
|  Rows Exported: 1,247                           |
|  Columns: [order_id, customer, amount, status] |
|  Masking Status: amount -> range_mask          |
|  Approval: Approved by manager                 |
|  File Hash: sha256:a7b3c9...                   |
|  Watermark: User identity watermark embedded   |
+----------------------------------------------+

#6.2 Anomalous Behavior Detection

Code

Anomaly Detection Rules:

Normal pattern (baseline):
  - Zhang queries ~50 customer records daily
  - Access hours: 09:00 - 18:00
  - Primarily accesses East region data

Alert triggered:
  +--------------------------------------+
  | ALERT: Anomalous Data Access Pattern |
  |                                        |
  | User: zhang.wei                       |
  | Anomaly: Bulk download at 3:00 AM    |
  | Details:                               |
  |   - Time: 03:17 (outside work hours)  |
  |   - Query vol: 2,847 (normal: 50/day)|
  |   - Region: All (normal: East only)  |
  |   - Operation: EXPORT (unusual)      |
  |                                        |
  | Risk Level: HIGH                      |
  | Auto-Response:                        |
  |   - Suspend user access               |
  |   - Notify security admin             |
  |   - Preserve complete operation log   |
  +--------------------------------------+

#Part 7: Air-Gapped Deployment Security

#7.1 What Is Air-Gapped Deployment?

Military and high-security environments require systems completely isolated from the internet:

Code

Air-Gapped Deployment Architecture:

+---------------------------------+
|          Internet                |
|                                   |
|  +----------+  +----------+     |
|  | Public   |  | SaaS     |     |
|  | Cloud    |  | Services |     |
|  +----------+  +----------+     |
+---------------------------------+
        X  Physical Air Gap  X
        X  No network connection X
+---------------------------------+
|       Secure Enclave             |
|                                   |
|  +----------------------------+  |
|  |  Palantir Foundry           |  |
|  |  (Fully standalone)         |  |
|  |                              |  |
|  |  - All services run locally |  |
|  |  - Data never leaves enclave|  |
|  |  - Updates via physical media|  |
|  |  - Independent PKI system   |  |
|  +----------------------------+  |
|                                   |
|  Physical Security:              |
|  - Biometric access control     |
|  - 24/7 surveillance            |
|  - EM shielding (TEMPEST)       |
+---------------------------------+

#7.2 Compliance Certifications

Security certifications held by Palantir:

Certification	Level	Meaning
FedRAMP	High	Can handle most sensitive unclassified federal data
IL2	CUI	Controlled Unclassified Information
IL4	Secret	Secret-level military information
IL5	Mission-Critical	Critical mission systems
IL6	Top Secret	Highest classification level
SOC 2 Type II	-	Independent security control audit
ISO 27001	-	Information security management system

Code

IL levels and deployment requirements:

IL2:  Commercial cloud (AWS GovCloud)
IL4:  Government-dedicated cloud (isolated regions)
IL5:  DoD-dedicated infrastructure
IL6:  Standalone air-gapped environment (physical isolation)

Palantir is one of very few software platforms
that can simultaneously meet IL2 through IL6.

#Part 8: How coomia-dip Implements Security

#8.1 PolicyEngineService -- Three-Model Evaluation

coomia-dip PolicyEngineService implements unified RBAC + ABAC + PBAC evaluation:

Code

coomia-dip PolicyEngineService Architecture:

Access Request
    |
    v
+----------------------------------------------+
|  PolicyEngineService                          |
|                                                |
|  +----------------------------------------+  |
|  |  1. RBAC Evaluator                      |  |
|  |     - Load user roles                   |  |
|  |     - Match role permission matrix      |  |
|  |     - Result: PERMIT / DENY /           |  |
|  |              INDETERMINATE              |  |
|  +-------------------+--------------------+  |
|                       |                       |
|                       v                       |
|  +----------------------------------------+  |
|  |  2. ABAC Evaluator                      |  |
|  |     - Collect subject attributes (user) |  |
|  |     - Collect resource attributes (data)|  |
|  |     - Collect env attributes (time/net) |  |
|  |     - Evaluate attribute matching rules |  |
|  |     - Result: PERMIT / DENY /           |  |
|  |              INDETERMINATE              |  |
|  +-------------------+--------------------+  |
|                       |                       |
|                       v                       |
|  +----------------------------------------+  |
|  |  3. PBAC Evaluator                      |  |
|  |     - Load organizational policies      |  |
|  |     - Check data sovereignty            |  |
|  |     - Check separation of duties        |  |
|  |     - Check temporal/compliance         |  |
|  |     - Result: PERMIT / DENY /           |  |
|  |              INDETERMINATE              |  |
|  +-------------------+--------------------+  |
|                       |                       |
|                       v                       |
|  +----------------------------------------+  |
|  |  Decision Combiner                      |  |
|  |  - Strategy: DENY_OVERRIDES             |  |
|  |  - Any DENY -> final DENY              |  |
|  |  - All PERMIT -> final PERMIT          |  |
|  |  - Any INDETERMINATE -> default DENY   |  |
|  +----------------------------------------+  |
+----------------------------------------------+

#8.2 Six Masking Modes Implementation

Python

# coomia-dip masking engine code example
from ontology_sdk.security import MaskingEngine, MaskingMode

engine = MaskingEngine()

# Full mask
engine.mask("John Doe", MaskingMode.FULL)
# Result: "***"

# Partial mask
engine.mask("555-123-4567", MaskingMode.PARTIAL,
            keep_first=3, keep_last=4)
# Result: "555-***-4567"

# Hash
engine.mask("John Doe", MaskingMode.HASH,
            algorithm="sha256")
# Result: "a7b3c9d2"

# Range
engine.mask(85200, MaskingMode.RANGE, step=10000)
# Result: "80000-90000"

# Generalization
engine.mask("1990-03-15", MaskingMode.GENERALIZATION,
            level="decade")
# Result: "1990s"

# Null
engine.mask("sensitive_data", MaskingMode.NULL)
# Result: None

#8.3 Seven-Tier Data Classification (A1-D)

coomia-dip implements a 7-tier data classification system:

Code

coomia-dip Data Classification System:

+------+--------------+--------------------------------+
| Tier | Identifier   | Description                    |
+------+--------------+--------------------------------+
| A1   | TOP_SECRET   | Highest - breach causes        |
|      |              | catastrophic damage             |
| A2   | SECRET       | Breach causes severe damage    |
| A3   | CONFIDENTIAL | Breach causes significant      |
|      |              | damage                          |
| B1   | RESTRICTED   | Authorized personnel only      |
| B2   | INTERNAL     | Organization internal only     |
| C    | SENSITIVE    | Needs basic protection          |
| D    | PUBLIC       | No access restrictions          |
+------+--------------+--------------------------------+

Protection requirements per tier:

A1: Encrypted storage + encrypted transport +
    dual-person approval + full audit +
    air-gapped env + access time window
A2: Encrypted storage + encrypted transport +
    approval access + full audit
A3: Encrypted storage + encrypted transport +
    role control + access audit
B1: Encrypted storage + role control +
    access audit
B2: Role control + basic audit
C:  Basic auth + operation logging
D:  No special requirements

#8.4 Query Rewriting -- Transparent Access Control

One of coomia-dip's most powerful security features is query rewriting -- user queries are automatically injected with security filter conditions before execution:

Code

Query Rewriting Example:

User's original query:
  SELECT * FROM orders WHERE amount > 10000

User context:
  role: regional_manager
  region: "East"
  clearance: B1

Query rewriting engine processes:
+------------------------------------------+
|  1. Row-level security injection:         |
|     WHERE region = 'East'                |
|                                            |
|  2. Column-level security filtering:      |
|     Remove [internal_notes, margin] cols  |
|                                            |
|  3. Classification level filtering:       |
|     WHERE classification_level <= 'B1'   |
|                                            |
|  4. Masking function injection:           |
|     customer_phone -> MASK(customer_phone,|
|                        'partial', 3, 4)   |
+------------------------------------------+

Actually executed query:
  SELECT order_id, region, customer_name,
         MASK(customer_phone, 'partial', 3, 4)
            as customer_phone,
         amount, status
  FROM orders
  WHERE amount > 10000
    AND region = 'East'
    AND classification_level <= 'B1'

The user is completely unaware of the security
filtering -- they think they queried all data,
but they only see what they are permitted to see.

Python

# coomia-dip query rewriting SDK example
from ontology_sdk import OntoPlatform

platform = OntoPlatform(endpoint="grpc://localhost:9090")

# User code -- no need to worry about security filtering
orders = platform.objects.search("Order") \
    .filter(amount__gt=10000) \
    .select("order_id", "customer_name",
            "customer_phone", "amount") \
    .all()

# Under the hood, the SDK automatically:
# 1. Checks user permissions
# 2. Injects row-level filters (only returns
#    rows the user can access)
# 3. Filters columns (removes unauthorized columns)
# 4. Applies masking (masks sensitive fields)
# 5. Records audit log

# Developers write ZERO security code
# Security is the platform's responsibility,
# not the application's responsibility

#Part 9: Security Design Philosophy -- Why This Model Works

#9.1 "Security as Architecture" Not "Security as Plugin"

Code

Traditional approach: Security bolted on after

+----------+
| App Code | <-- Build features first
+----+-----+
     | Then add
     v
+----------+
| Security | <-- Can be bypassed
| Middleware|
+----+-----+
     |
     v
+----------+
| Database | <-- Direct access = bypass security
+----------+

Palantir / coomia-dip approach: Security is architecture

+----------------------------------------+
|              Ontology Layer             |
|  +----------------------------------+  |
|  | Every data access goes through   |  |
|  | the security engine              |  |
|  |                                    |  |
|  | Object -> Permission -> Masking  |  |
|  |   |          |           |        |  |
|  | Storage  RBAC/ABAC    Dynamic    |  |
|  |          /PBAC        Transform  |  |
|  +----------------------------------+  |
|                                        |
| No "bypass" path -- Ontology is the   |
| ONLY data access channel              |
+----------------------------------------+

#9.2 Zero Trust Principles

Principle	Implementation
Never trust, always verify	Re-evaluate permissions on every request
Least privilege	Default deny, explicit grant
Assume breach	End-to-end encryption + audit
Defense in depth	RBAC + ABAC + PBAC multi-layer checks
Continuous monitoring	Real-time anomaly detection + auto-response

#Key Takeaways

Palantir's security model originates from military intelligence compartmentalization -- this is not marketing but genuine design heritage. The "need-to-know" principle, compartment isolation, and multi-factor authentication are military-grade concepts embedded directly into the platform architecture. RBAC + ABAC + PBAC triple-model coordination ensures comprehensive access control across roles, attributes, and organizational policies.
Dynamic data masking and query rewriting are the most elegant security implementations in Palantir's model -- same data, different views for different roles, with developers writing zero security logic in application code. Security is the platform's responsibility, not the application's. This completely eliminates the risk of "developers forgetting to add permission checks."
coomia-dip implements three-model unified evaluation through PolicyEngineService, 6 masking modes covering all scenarios, and 7-tier data classification (A1-D) providing complete grading from public to top secret -- the query rewriting mechanism makes security controls completely transparent to the application layer. Any operation accessing data through the Ontology is automatically protected by the security engine.

#Next Article Preview

“

Article 13: Palantir's Apollo Deployment Engine -- Software That Manages Itself

Secure software that cannot be reliably deployed makes security meaningless. Apollo is Palantir's continuous deployment engine managing hundreds of Foundry instances worldwide -- from the Pentagon's air-gapped environments to commercial clouds. Next, we will examine how Apollo achieves zero-downtime deployment, automatic rollback, and cross-environment consistency.

#palantir #security #rbac #abac #access-control #data-masking #audit #coomia-dip #fedramp