--- title: "Use Security Folder to Enable Trustless Modeling and Data Protection" slug: "security-folder-trustless-modeling" description: "Secure your Pigment Application by managing Modeler permissions and isolating sensitive formulas using the Security Folder for trustless modeling." tags: ["Access Rights", "Data Security", "Formula Exploitation", "Security and Compliance", "Security and Permissions ", "Trustless Modeling"] updated: 2025-05-30T10:12:02Z published: 2025-08-22T11:56:47Z --- > ## Documentation Index > Fetch the complete documentation index at: https://kb.pigment.com/llms.txt > Use this file to discover all available pages before exploring further. # Use the Security Folder for Trustless Modeling If your Pigment application includes modelers without security permissions who aren’t fully trusted with all data within that application, this guide is for you. It explains how formula changes can unintentionally expose sensitive data and how to isolate and secure vulnerable parts of your model. ## Before you begin Access rights in Pigment are dynamic and tied to the model's state. This means modelers with the Configure Blocks permission—but without Define Application Security permission—can still impact how access rights are applied by modifying formulas. ### Examples of how formulas can expose data **​​​​​​​1. Reveal data by changing List Properties’ formulas** In this example, the model has the below two Dimension Lists: 1. `Access Level` ![A table displaying names labeled from L1 to L5 in a structured format.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/access-level-trustless-modeling.png) 1. `Employee` ![Table displaying employee names, salaries, and access levels for various positions.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/employee-trustless-modeling.png) **The Security Setup** The goal was to prevent our test user Non-Security Modeler from editing any items in the `Employees` Dimension and from seeing the salaries of any employees with an `Access Level` higher than `L4`. Therefore Non-Security Modeler was granted **Read/No Write** access rights to the **Specific List Properties** of `Employees`: ![Configuration settings for employee access rights in a table format with rules defined.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/apply-ar-employees.png) Then Non-Security Modeler was granted no access rights (**No Read/No Write**) to the **List Item Values** of all Items in **Employees**, for L4 and L5: ![Access rights configuration table showing employee roles and permissions for data access.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/AR-Acess-level.png) **The formula exploitation** A modeler without access rights to edit the `Access Level` Dimension directly can still edit the ‘Access Level’ Property attached to the `Employee` Dimension, as the below image shows: ![](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/d1eae743-9f5a-4eba-9a15-c8939cebff25 (1).gif) **2. Reveal data by changing a Metric’s formulas** ​​​​​​In this example, the model is as above but has additional Metrics to allow certain Members to manage access rights. These include: 1. A Boolean Metric defining User access level ![User access levels for Lucas Fridman and Non-Security Modeler displayed in a table.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/boolean-level.png) 1. Another Boolean applying the User access levels to employee data, through a formula: ![Table displaying user access levels for employees in a project management tool.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/boolean-metric.png) 1. ​​​​​​​An access rights Metric that turns the User access levels into access rights: ![Access level settings for users, showing permissions for Non-Security Modeler role.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/acess-rights-metric-levels.png) 2. And finally a second access rights Metric `AR_Employees` that applies the access rights to all employees: ![Access rights settings for employees displayed in a table format with user permissions.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/ar-levels.png) ​​​​​​​The employees’ salaries are held in a dedicated Metric `Employee Monthly Salaries`: ![Table displaying employee monthly salaries for various months and individuals.](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/employee-monthly-salaries.png) **The Security Setup** The Users’ access rights are now governed by the access rights Metric `AR_Employees`, applying to all Metrics structured on` Employee`. **The formula exploitation** A modeler without access rights to see all the data in `Employee Monthly Salaries` can still edit the Boolean Metrics’ formulas, as the below image shows: ![](https://cdn.document360.io/e47cfe35-dc28-40c7-a083-6cf003073d8e/Images/Documentation/trustless-modeling-2.gif) ## Mitigation The best mitigation is having fully trustworthy modelers working on your Application’s data. As this can’t always be guaranteed, you can strengthen security as follows: 1. Move the Blocks containing the ‘vulnerable’ formulas into the Application’s Security folder. 2. Grant `CanDefineSecurity` permission only to fully trustworthy users. Non-security modelers are no longer able to indirectly impact security, as access to Blocks within the Security folder is restricted.