# Apply CLS to your database (/core/embed/permissions-and-row-level-security/how-to/apply-cls-to-your-database)



<CalloutContainer type="info">
  <CalloutDescription>
    **Target Audience**: Developers & Non technical users
  </CalloutDescription>
</CalloutContainer>

### Goal [#goal]

Restrict which columns users can see based on identity context passed via authentication tokens — without creating separate dashboards per role.

***

### Prerequisites [#prerequisites]

* A [connected database](/core/build/data-connections/how-to/add-a-database) containing columns you want to protect (e.g., `salary`, `email`, `seller`).
* An [existing dashboard](/core/build/dashboards-and-layouts/how-to/create-a-dashboard-with-ai) or [chart](/core/build/charts/how-to/create-a-chart) that uses the target table.
* A [valid API key](/core/embed/authentication/how-to/generate-an-api-key) to generate test tokens in the sandbox.

***

### Steps [#steps]

#### 1. Verify sensitive columns [#1-verify-sensitive-columns]

* Navigate to the **Databases** tab and select the target **Database** and **Table**.
* Click **Preview** to confirm the columns you want to restrict (e.g., a `salary` column or a `seller` identifier).

#### 2. Define custom token attributes [#2-define-custom-token-attributes]

* Navigate to **Users** and select the **User model** tab.
* Locate the **Token Attributes** menu under **Custom Attributes**.
* Click **Add an attribute**.
* Input a factual **name** (e.g., `role`) and select the **data type** (e.g., `String`).
* Click **Save changes** to register the attribute for use in authentication tokens.

#### 3. Configure column-level rules [#3-configure-column-level-rules]

* Return to the **Databases** section and select your **Database** and **Table**.
* Click the **Access rules** tab.
* In the column-level section at the top of the page:
  * **Empty state**: choose `all` (every column visible) or `none` (no column visible) as the default catch-all.
  * Click **Add column section** to create a section for sensitive columns.
  * Select the columns to protect (e.g., `salary`).
  * Click **Add condition** and define when those columns should be visible — for example: &#x2A;included if \[role] is equal to \[HR]*.
  * The catch-all section at the bottom covers all other columns (and any columns added to the table later).

#### 4. Enable and save CLS [#4-enable-and-save-cls]

* Click **Save** to activate the security policy.
* Verify that the CLS enabled indicator appears next to the table name.
* You may repeat this configuration for additional tables that require the same column-level logic.

#### 5. Validate the CLS policy [#5-validate-the-cls-policy]

* Within the table view, click **Preview access rules** in the top right corner.
* Enter a test value for your custom attribute (e.g., `role` = `HR`) and click **Generate preview**.
* Confirm that sensitive columns appear only when the condition is satisfied.
* Change the attribute value (e.g., `role` = `Sales`) and regenerate the preview to confirm those columns are hidden.

#### 6. Generate a test token and embed [#6-generate-a-test-token-and-embed]

* Navigate to **Settings > Embed & access** and scroll to the **Token Generation Sandbox**.
* Enter your **API Key** and assign a value to your custom attribute (e.g., `role` = `HR`).
* Click **Generate Token**.
* Use this token in your embedded component (e.g., `<tc-dashboard auth-token="YOUR_TOKEN">`) to confirm the column-scoped view in your host application.

***

### Conclusion [#conclusion]

The database now enforces Column-Level Security based on the identity context passed via authentication tokens. Combine CLS with [Row-Level Security (RLS)](/core/embed/permissions-and-row-level-security/how-to/apply-rls-to-your-database) on the same table for full row-and-column isolation in multi-tenant environments.

For operator details and policy semantics, see [Column-Level Security (CLS)](/core/build/security-and-governance/column-level-security-cls).