Use the Security Folder for Trustless Modeling

  • Published on Aug 22, 2025
  • 2 minute(s) read
Prev Next

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.

  1. Employee

Table displaying employee names, salaries, and access levels for various positions.

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.

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.

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:

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.

  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.

  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.

  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.

​​​​​​​The employees’ salaries are held in a dedicated Metric Employee Monthly Salaries:

Table displaying employee monthly salaries for various months and individuals.

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:

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.

Related articles