# TrustLogix TrustLogix is a **Data Access Governance** and **Data Security Monitoring (DSM)** platform that provides **visibility, control, and compliance** for data security across cloud and on-prem environments. It enables enterprises to enforce **fine-grained, no-code access policies** while continuously monitoring data access risks, helping organizations prevent insider threats, meet compliance requirements, and optimize access controls. TrustLogix provides a unified security layer for cloud data platforms by offering: **Data Access Governance** * **Role-Based & Attribute-Based Access Controls (RBAC & ABAC):** Define and enforce least-privilege access policies using user attributes, entitlements, and personas. * **Masking & Row-Level Security:** Protect sensitive data by dynamically enforcing data masking and filtering access based on user roles and attributes. * **Domain-Wide Policy Enforcement:** Apply consistent security policies across multiple data sources and domains without manual intervention. **Data Security Monitoring (DSM)** * **Data Access & Privilege Monitoring:** Detect and analyze **who is accessing what data, how often, and whether it's appropriate**. * **High-Privilege Role Tracking:** Identify **excessive permissions, shadow admins, and suspicious activities** that may indicate data misuse or exfiltration. * **Policy Gap Analysis:** Identify **data exposed without security tags, policies not applied, and overlapping grants** across users and data centers. * **Data Sharing & Dark Data Reports:** Provide insights into **public vs. private data sharing** and unused data that increases security risk. * **Entitlement & Access Reviews:** Provide **snapshots of user access privileges** to detect **inactive users, overly granted roles, and unauthorised data exposure**. By combining **access governance, DSPM, and compliance automation**, TrustLogix helps organizations **reduce security risks, enforce least-privilege access, and achieve regulatory compliance** effortlessly. # Data Sources TrustLogix provides a unified security layer for managing **data access governance and monitoring** across various cloud and on-prem data platforms. To leverage TrustLogix’s capabilities, customers need to **register their data sources** within the platform. #### **Supported Data Sources** TrustLogix supports a wide range of structured data platforms, including: * **Snowflake** * **Databricks** * **SQL Server** * **Aurora RDS** * **MySQL** #### **Register Data Sources** Registering data sources with TrustLogix allows organizations to: * **Enforce Access Governance:** Define and enforce **RBAC, ABAC, and masking policies** to ensure least-privilege access. * **Monitor Data and Entitlements:** Track **who is accessing data, how often, and whether access aligns with security policies**. * **Analyze Usage Patterns:** Identify **sensitive data movement, excessive permissions, and policy misconfigurations**. * **Detect and Prevent Security Risks:** Receive real-time alerts on **suspicious data activities**, privilege escalations, and compliance violations. #### **How It Works** 1. **Register the Data Source:** Provide connection details for Snowflake, Databricks, SQL Server, Aurora RDS, or MySQL. 2. **Access To Metadata :** TrustLogix requires metadata related to data catalog and auditlogs to support access governance and monitoring capabilities. 3. **Configure Governance Policies:** Define **role-based, attribute-based, and masking policies** tailored to your security needs. 4. **Enable Monitoring & Reporting:** Gain **real-time visibility into access patterns, entitlement changes, and policy enforcement gaps**. 5. **Automate Compliance & Audits:** Generate **SOC 2, SOX, and CIS benchmark reports** to ensure regulatory compliance. By integrating TrustLogix with your data sources, you gain full control over **data security, access governance, and compliance monitoring** without impacting performance. # Register Data Source Registering a data source in TrustLogix is the first step in enabling **data access governance** and **security posture management**. This process allows TrustLogix to **monitor, analyze, and enforce access policies** across your data platforms, such as Snowflake, Databricks, SQL Server, and other supported databases. {% content-ref url="/pages/W5Mu0gZ0IAJvJxy46UGB" %} [Snowflake](/data-sources/snowflake) {% endcontent-ref %} {% content-ref url="/pages/T3qaXIAtu6MCuONTx2JG" %} [Databricks](/data-sources/databricks) {% endcontent-ref %} {% content-ref url="/pages/7ybz2TjnXEqIUkLNOlwK" %} [SQL Server](/data-sources/sql-server) {% endcontent-ref %} # Snowflake To register a Snowflake account into TrustLogix follow the below steps 1\. Create a data source entry in TrustLogix 2\. Run the auto generated script in Snowflake environment 3\. Gather all required information about Snowflake account 4\. Update the details in TrustLogix and Save #### **Create a Snowflake Data Source In TrustLogix** * Login to TrustLogix console and register a new Snowflake Datasource from Menu → Data sources → Register new data source * Provide the data source name, & click on Register data source * Form will be refreshed with additional fields and script Download option **Run the script in Snowflake environment** * Click on Download button to download the script * Extract the downloaded script, extracted script will contain multiple files * Either choose to run the script as py notebook or as SQL script * Replace the placeholder values in script, like password etc * Run the updated script, script needs to be **executed** as **ACCOUNTADMIN** * After successful run of the script, required objects are created in snowflake * Capture the output of the script and also gather * snowflake account identifier * username and password if authentication type is basic auth * If authentication mode is [Key-Pair ](/data-sources/snowflake/key-pair-authentication-setup)generate keys and keep it ready **Save the captured details in TrustLogix** * Navigate back to TrustLogix data source form page * Enter all the required details in form * Click on save, system will validate the connection details and saves them * If all details are valid, Snowflake data source is successfully registered & shown as active in the list # How To Locate Snowflake Account Identifier #### Steps to find the account Identifier for an account * Step 1 : Open the account selector and review the list of accounts that you previously signed in to.
* Step 2: Select View account details. * The Account Details dialog displays information about the account, including the account identifier and the account URL. * Copy the account identifier from the Account Details dialog.
# Key Pair Authentication Setup Following are the steps to enable Key-Pair authentication for TrustLogix users to authenticate to Snowflake. Depending on the deployment model in the customer environment, one or two users may be used for authentication: 1. **TrustLogix-hosted TrustLet**: One user is mapped in TrustLogix. 2. **Customer-hosted TrustLet**: Two users are mapped in TrustLogix: * Control plane user (for policy creation in UI) * Data plane user (for policy deployments) #### Steps to Set Up Key-Pair Authentication 1. Generate Keys for Snowflake Users 2. Alter Snowflake Users with Public Key Value 3. Update the TrustLogix Configuration *** ### 1. Generate Keys for Snowflake Users Use the **OpenSSL** tool to generate the keys. #### Step 1: Generate the Private Key Run the following command: ```sh openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key_tlx_user.p8 -passout "pass:TrustLogix" ``` * The **key name** and **passphrase** can be customized as per customer requirements. * This generates an encrypted private key similar to: ``` -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQI4GZOWG8 ……. zWYxYMIPtR1aCI5cgyU1Og== -----END ENCRYPTED PRIVATE KEY----- ``` #### Step 2: Generate the Public Key Run the following command using the generated private key: ```sh openssl rsa -in rsa_key_tlx_user.p8 -pubout -out rsa_key_tlx_user.pub -passin "pass:TrustLogix" ``` * Ensure the **private key file name** and **passphrase** match those used in Step 1. * This generates a public key file **rsa\_key\_tlx\_user.pub** in the current directory. ``` -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOC qSqQEjtzp+h+u6nA9S42h6uyR9 xxxx abd3209jwIDAQAB -----END PUBLIC KEY----- ``` **Note**: If deploying TrustLet in a customer environment, generate keys for both control and data plane users: ```sh openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key_tlx_dp_user.p8 -passout "pass:TrustLogix" openssl rsa -in rsa_key_tlx_dp_user.p8 -pubout -out rsa_key_tlx_dp_user.pub -passin "pass:TrustLogix" ``` *** ### 2. Alter Snowflake Users Attach the public key to the users by running the following commands in **Snowsight/WebUI**. #### Step 1: Prepare the Public Key Open the `rsa_key_tlx_user.pub` file and **remove** the `-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----` headers. For example: ```sql ALTER USER TLX_USER SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0BAQEFAAOC qSqQEjtzp+h+u6nA9S42h6uyR9 xxxx abd3209jwIDAQAB'; ``` *** ### 3. Update TrustLogix Authentication Details Once the Snowflake user details are updated, update the authentication details in TrustLogix. #### Step 1: Configure Data Sources in TrustLogix 1. Navigate to **Data Sources** in the TrustLogix console. 2. Open the respective Data Source configuration screen. 3. In the configuration screen, follow these steps: * Select **Authentication Type** as **Key Pair Authentication**. * Upload the `rsa_key_tlx_user.p8` private key using the **Browse** button. * Enter the passphrase used during key generation. * Click **Save**. 4. If all details are correct, the data source details are validated and saved. ## Key Pair Authentication Setup For **Customer-hosted TrustLet** As mentioned in the above section, there are two users needs for Customer-hosted TrustLet or hybrid tenant. Below are the additional steps required for Customer-hosted TrustLet or hybrid tenant. 1. Follow the steps mentioned above to create Data plane user 1. Generate Keys for Snowflake Users 2. Alter Snowflake Users with Public Key Value 2. Set following key and value * Trustlet is hosted on AWS ECS (Amazon Elastic Container Service) ``` tlx///role tlx///username tlx///jdbcurl tlx///warehouse tlx///passphrase tlx///privatekey ``` * Trustlet is hosted on Azure Kubernetes Service (AKS) ``` tlx---role tlx---username tlx---jdbcurl tlx---warehouse tlx---passphrase tlx---privatekey ``` *** ### Final Steps to Confirm Setup After completing the configuration: * Create a **test policy** on a sample dataset. * Deploy the policy. * If the policy creation and deployment flow proceeds without errors (during database/schema selection and deployment), then the **key-pair setup is successful**. # Snowflake with External OAuth Setup ## verview This document provides an overview of how TrustLogix uses Snowflake External OAuth to secure access to our Snowflake data warehouse. It outlines the general process, supported Identity Providers (IdPs), and configuration guides. ### What is External OAuth External OAuth allows Snowflake to leverage an external, trusted Identity Provider (IdP) for user authentication and authorization. This enables a seamless Single Sign-On (SSO) experience for programmatic clients (like Azure AD or Okta) and aligns Snowflake access with TrustLogix's central identity and access management policies. ### Supported **OAuth Provider** TrustLogix supports external authorization servers, custom clients, and partner application integration, which are natively supported by Snowflake. Choose one of the supported providers:
Snoflake DocSnowflake Community Doc Link
OktaOkta
Microsoft Entra IDMicrosoft Entra ID
Ping Identity PingFederate
External OAuth Custom Clients
Microsoft Power BI
Sigma
**Note**: We recommend consulting the official Snowflake documentation for the latest configuration details and prerequisites. ### Configuration Overview The external OAuth setup is a two-part process that establishes a trust relationship between your IdP provider and Snowflake. 1. Configure an App registration as OAuth client. 2. Request and decode the OAuth access token. 3. Create an External OAuth Security Integration in Snowflake 4. Verify the Access Token against the security integration. 5. Alter TrustLogix user in Snowflake 6. Register Snowflake account using the access token. #### Step 1: Configure an App registration as OAuth client. * Refer to the Snowflake official document to register IdP provider applications. * Get the below value from IdP. * OAuth token endpoint. * Application scope * Client ID * Client secret * Use the TrustLogix role in the application scope: Ex:- session:role:\ #### Step 2: Request and decode the OAuth access token. 1. Refer to the Snowflake official document to prepare the CURL command to request the access token using the client\_credentials grant. 2. **Decode the OAuth Access Token** 1. Copy the value of the **access\_token** and decode it on an online decoder of your choice (e.g. [jwt.ms](https://jwt.ms/)), it will provide the details present in the token. 2. Make sure the following attributes from the decoded token match the configuration in the external authorization server. * issuer * audience * roles #### Step 3: Create an External OAuth Security Integration in Snowflake Now configure the Snowflake account to trust and accept the access token generated in Step 2. * ISSUER * AUDIENCE * JWS\_KEY\_ENDPOINT > create security integration external\_oauth\_integration\ > type = external\_oauth\ > enabled = true\ > external\_oauth\_type = \\ > external\_oauth\_issuer = '\'\ > external\_oauth\_jws\_keys\_url = '\'\ > external\_oauth\_audience\_list = ('\')\ > external\_oauth\_token\_user\_mapping\_claim = 'sub'\ > external\_oauth\_snowflake\_user\_mapping\_attribute = 'login\_name'; #### Step 4: Verify the Access Token against the Security Integration Now that the security integration is created in Snowflake, it can accept or reject an access token issued from an OAuth provider client based on the configuration. Use the function [SYSTEM$VERIFY\_EXTERNAL\_OAUTH\_TOKEN](https://docs.snowflake.com/en/sql-reference/functions/system_verify_ext_oauth_token) to confirm whether your token will be accepted by the Snowflake account or not.
Verify Token query ``` SELECT SYSTEM$VERIFY_EXTERNAL_OAUTH_TOKEN('eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjVCM25SeHRRN2ppOGVORGMzRnkwNUtmOTdaRSIsIm.......FTU5nctRpmaA'); ```
A successful validation would look like the below: > Token Validation finished. { "Validation Result":"Passed", "Issuer":"issuer endpoint/", "**Extracted User claim(s) from token**":"3d63xxxxxxxx0652895d" } Please note down the value get from the token validation response `Extracted User claim(s) from token` . We will use it in the next step. #### Step 5: Alter TrustLogix user in Snowflake Finally, alter the TrustLogix Snowflake user and use `Extracted User claim(s) from token` (the value from step 4 in LOGIN\_NAME). Ex: `ALTER USER TLX__CP_USER SET LOGIN_NAME = "3d63xxxxxxxx0652895d" TYPE = 'SERVICE'` #### Step 6: Register a Snowflake account using the access token. * Once the token validation is successful, we can register the Snowflake account in TrustLogix. * Enter all the details in the TrustLogix registration page, and click on save.
* ```
``` ## External OAuth Authentication Setup For **Customer-hosted TrustLet** Below are the additional steps required for Customer-hosted TrustLet or hybrid tenant. 1. Follow these steps mentioned above to create data plane user 1. Configure an App registration as the OAuth Resource server 2. Request and decode the OAuth access token. 3. Alter the External OAuth Security Integration created for the DP user 1. Run the describe command to check the audience list for the security integration created for the CP user. ``` desc security integration EXTERNAL_OAUTH_AZURE; ``` 2. Alter Security Integration to add audience for DP user(include all audience from output of the above command) 
ALTER SECURITY INTEGRATION EXTERNAL_OAUTH_INTEGRATION
      SET EXTERNAL_OAUTH_AUDIENCE_LIST = ('<audience_1>', '<audience_2>', ...);
4. Verify the Access Token against the Security Integration 5. Alter TrustLogix user in Snowflake 2. Set following key and value * Trustlet is hosted on AWS ECS (Amazon Elastic Container Service) ``` tlx///role tlx///username tlx///jdbcurl tlx///warehouse tlx///clientSecret tlx///clientId tlx///scope tlx///tokenUrl ``` * Trustlet is hosted on Azure Kubernetes Service (AKS) ``` tlx---role tlx---username tlx---jdbcurl tlx---warehouse tlx---clientSecret tlx---clientId tlx---scope tlx---tokenUrl ``` > Please note that the value username (`tlx///username` or `tlx---username`) must match the `LOGIN_NAME` used in Step 5. For example: > > `tlx///username` = `672a90b3-xxxx-xxxx-xxxx-xxxx2f7befef` *** ## Final Steps to Confirm Setup After completing the configuration: * Create a **test policy** on a sample dataset. * Deploy the policy. * If the policy creation and deployment flow proceeds without errors (during database/schema selection and deployment), then the **External OAuth setup is successful**. # Databricks To register a Databricks account into TrustLogix follow the below steps 1\. Create a data source entry in TrustLogix 2\. Run the auto generated notebooks in Databricks environment 3\. Gather all required information about Databricks account 4\. Update the details in TrustLogix and Save #### **Databricks User Permissions To Register An Account** * **Account Admin Permission**: Required to register a new Databricks data source in TrustLogix. The user initiating the registration must have Account Admin privileges on the Databricks account. * For Registering New Workspace to an Existing Data Source * **Workspace Admin**: Required to execute the necessary notebooks for workspace registration. * **Metastore Admin**: Required to execute the necessary notebooks for workspace registration. **Note:** Both Workspace Admin and Metastore Admin permissions are required on the Databricks side to successfully register a new workspace to an existing Databricks data source. #### Permissions Required by TrustLogix Service Principal(s) * TrustLogix uses service principals to access your Databricks environment. Two separate service principals are used depending on the feature components. The permissions required vary based on your deployment model. * Permissions required to access **TrustLogix and System Catalogs** for Control Plane and Data Plane service principals based on deployment model * `USE CATALOG, USE SCHEMA, BROWSE, CREATE FUNCTION, CREATE TABLE, SELECT, MANAGE, MODIFY` on `TLX_POLICY_DB` catalog * `USE CATALOG, USE SCHEMA, SELECT` on `system` catalog * `CAN USE` on `TLX_WAREHOUSE` compute * `User` permission on all registered workspaces within the TrustLogix Console * Data Plane Service Principal Permissions for Trustlet or Hybrid tenants * The data plane service principal requires the following permissions on securable catalogs: * `USE CATALOG` - Allow the service principal to use the catalog * `USE SCHEMA` - Allow the service principal to use schemas within the catalog * `BROWSE` - Allow browsing of catalog objects * `SELECT` - Allow read access to tables and views * `MANAGE` - Allow management of catalog objects * Control Plane Service Principal Permissions for Trustlet or Hybrid tenants * The control plane service principal requires the following permissions on securable catalogs: * `USE CATALOG` - Allow the service principal to use the catalog * `USE SCHEMA` - Allow the service principal to use schemas within the catalog * `BROWSE` - Allow browsing of catalog objects * `APPLY TAG` - Allow applying tags to securable objects * SaaS Tenant Deployment * For SaaS tenant deployments, a single TrustLogix service principal is used with the following permissions on securable catalogs: * `USE CATALOG` - Allow the service principal to use the catalog * `USE SCHEMA` - Allow the service principal to use schemas within the catalog * `BROWSE` - Allow browsing of catalog objects * `SELECT` - Allow read access to tables and views * `MANAGE` - Allow management of catalog objects * `APPLY TAG` - Allow applying tags to securable objects * **Important Notes on Service Principal Permissions** * **No Admin Permissions Required**: TrustLogix service principals do **NOT** require Account Admin, Workspace Admin, or Metastore Admin permissions to function properly. * **Principle of Least Privilege**: Service principals are granted only the minimum permissions necessary to perform their designated functions. * **Group Membership Feature Limitation**: The group membership-related feature in Access Analyzer will be **disabled** by default for TrustLogix service principals. * **To Enable Group Membership Feature**: If you need to enable group membership-related features in Access Analyzer, the TrustLogix service principal must have at least **Workspace Admin** or **Account Admin** permissions. #### **Create a** Databricks **Data Source In TrustLogix** * Login to TrustLogix console and register a new Databricks data source from Menu → Data sources → Register new data source * Provide the data source name, & click on Register data source * Form will be refreshed with additional fields and script Download option **Run the notebooks in** Databricks **environment** * Click on Download button to download the notebooks * Extract the downloaded Zip file which will contain **multiple** Python notebook files * Ensure that each of the notebook prerequisites are performed before that particular notebook is run by providing all the arguments like the Account ID, Service Principal Name, Access Token etc. * After successful run of each of the notebooks, required objects are created in Databricks * Capture the output of the notebook and also gather * Account ID * Workspace Deployment Name * SQL Warehouse Identifier * Service Principal Name * Client ID * Client Secret #### How to register additional workspaces to an existing Databricks data source The following are necessary to add additional workspaces to an existing Databricks data source 1. TrustLogix Service Principal Id 2. TrustLogix Client Id 3. TrustLogix DP Service Principal Id(Only for trustlet/hybrid tenant) 4. TrustLogix DP Client Id(Only for trustlet/hybrid tenant) 5. Workspace URL e.g adb-180424056746427.6.azuredatabricks.net Here, 1, 2 belong to the TrustLogix Control Plane Service Principal and 3, 4 belong to the DataPlane Service Principal. You can get the above from the Results section of the initial tlx\_databricks\_grants notebook used while registering Databricks account in the TrustLogix console. **Step-1: Run following notebooks** 1. tlx\_databricks\_grants\_register\_workspace.ipynb 2. tlx\_databricks\_grants\_to\_cp\_service\_principal\_scheduler.ipynb(Only for trustlet/hybrid tenant) 3. tlx\_databricks\_workspace\_admin\_grant.ipynb \#1 and #3 can be run from any workspace. #2 need to be run from new workspace to be registered. > To execute the above notebooks in Databricks, it is suggested that the user or service principal must have a minimum of the following permissions: > > * **Workspace Admin** > * **Metastore Admin** > > Account Admin permission not required. **Step-2: Add the workspaces and warehouses in the TrustLogix console** * Navigate back to TrustLogix data source form page * Update following for the new workspace * Workspace Deployment Name(s) * SQL Warehouse Identifier(s) * Click on save, system will validate the connection details and saves them * If all details are valid, Databricks datasource should be updated successfully **Step-3: Update secrets on AWS SSM (or Azure Key Vault) corresponding to the new workspace** ``` tlx---jdbcurl tlx---warehouse tlx---oauthEndpoint ``` # SQL Server ### Creating a Data Source for SQL Server in TrustLogix #### Prerequisite Steps 1. **Download Required Files**: * Click on the **Download** button to obtain the zip file containing the necessary SQL scripts. 2. **Execute SQL Scripts**: * Use **SQL Server Management Studio (SSMS)** to execute the following SQL scripts from the downloaded zip file: * `tlx_sqlserver_grants.sql` * `tlx_sqlserver_grants_for_aws_rds.sql` * Ensure the scripts are run on the appropriate SQL Server instance. 3. **Capture Configuration Details**: * Note down the following details: * Username and password used in the SQL grants scripts. * Hostname and port of the SQL Server. 4. **Understand TrustLogix User Grants**: * The TrustLogix user will be granted the following permissions: * `CONNECT`, `ALTER`, `ALTER ANY MASK`, `ALTER ANY SECURITY POLICY` on all existing databases for masking and row access policies. * `SELECT`, `ALTER`, `EXECUTE`, `CREATE FUNCTION`, `CREATE TABLE` on `TLX_POLICY_DB` for masking and row access policies. * The TrustLogix user will also be added as a member of the `db_securityadmin` role for each database. #### Connection Configuration 1. **Server Name and Port**: * Enter the hostname of the SQL Server instance in the format `ServerName,1433` (replace `1433` with the actual port if different). * Refer to the guide: *How to obtain the server name?* 2. **Username**: * Provide the username captured from the grants script execution. 3. **Password**: * Enter the password corresponding to the username. #### Final Step * After populating all the fields, click **Save** to complete the registration of the SQL Server data source. # Power BI TrustLogix allows you to centrally manage **data access governance** across multiple data sources, including **Power BI**. By registering Power BI as a data source, you can: * Enforce **row-level security** directly from TrustLogix. * Leverage **entitlement attributes** from Power BI for consistent policy enforcement. Perform the [pre-requisites](/data-sources/power-bi/pre-requisites-for-power-bi-registration) step and keep all required detail handy to complete the registration process **Steps to Register Power BI Data Source** * **Navigate to Data Sources Menu** * Go to: TrustLogix Data Sources Page. * **Register Data Source** * Click **“Register Data Source.”** * Select **“Power BI”** from the list of supported sources. * **Provide Data Source Details** * Enter a **Data Source Name** (e.g., *Power BI DataSource*). * Click **“Register Data Source.”** * **Service Account & Tenant Details(Captured in Pre-Requisites step)** * Enter **Service Account Name** (e.g., *PowerBiService*). * Enter **Tenant ID**. * Enter **Client ID**. * Enter **Client Secret** * **Entitlement Attribute Source** * Choose an **existing data source** as the source of entitlement attributes (e.g., Active Directory, Snowflake, Databricks etc.). * **Save Configuration** * Click **“Save”** to complete the registration. * Data source should be saved successfully # Pre-requisites for Power BI Registration #### Before registering Power BI in TrustLogix, ensure you have the following: #### **Licensing and Roles for Create Service Account** * Ensure that the Power BI Semantic Models are configured to **Premium Per User, Premium Capacity,** or **Fabric Capacity** (refer to image) * Refer to **this** [**documentation** ](https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools)for more detailed information * The User creating the service principal in the following steps is assigned to a **Fabric Administrator** role
#### **Power BI Service Settings (Admin Portal)** * The following developer settings need to be enabled for the service principal to call Fabric Public APIs * If you would like only give access for a certain security group, please select the **Specific security groups** option below instead of The entire organization and assign the security group to that
* Also enable the XMLA endpoint option to Read Write under Premium Per User * if using Premium Capacity, enable under that
#### **Azure AD Service Account** * A **dedicated service account** (Azure Application) using Azure Application Registration that TrustLogix will use to connect to Power BI. * Create App In Azure using App registration * Sign in to the Azure portal and browse to **Azure Active Directory** → **App registrations** * Click **New registration** * Create the application * **Name**: e.g. `TrustLogix-PBI` * **Supported account types**: choose **Accounts in this organizational directory only** * **Redirect URI**: leave blank (not needed for client‑credentials flow) * Click **Register** * **Grant the API Permissions** * The application should have the following API Permissions on Power BI Service: * **Admin consent** to access Power BI APIs
* (Optional) If you would like to use TrustLogix for Group-Based policies in Power BI, please add the following permission as well
* #### **Fetch Tenant ID and Client ID** * Obtain your **Tenant ID and Client ID using Application Overview Page** * The **Client ID** is available in **App Registration → Overview → Application (client) ID** * The **Tenant ID** is available in **App Registration → Overview → Directory (tenant) ID** * #### **Fetch Client Secret** * **Generate a Client Secret under Application Overview Page → Manage → Certificates & Secrets** * Please make note of the expiry date of the Secret and update it as TrustLogix will not be able to auto update the Secret #### **Workspace Assignment to the Service Account** * The service account created above needs to be added to all workspaces that you would like TrustLogix to secure * Ensure that the service account is granted **ADMIN** level access to these workspaces * If you have added the service account to a security group, add the security group as an ADMIN instead
# Best Practices and Known Issues XMLA Restrictions Semantic Model/Report and Policy Lifecycle Management ## XMLA Restrictions and Model Management ### Summary: The Impact of XMLA Write Operations Enabling XMLA write operations unlocks powerful capabilities for Power BI models, but it fundamentally changes how those models interact with the Power BI Service. The most significant change is that you **generally cannot download the semantic model back to a standard .pbix file** once an external tool has modified it ### Impact Analysis: What Changes with XMLA The following table outlines the operational changes, user impacts, and necessary remediations when utilizing XMLA write capabilities | **Area of Impact** | **Operational Change** | **User Impact & Awareness** | **Remediation / Preventative Action** | | -------------------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | File Downloadability | The "full" PBIX (report + data) typically cannot be downloaded from the Service. | Microsoft warns that XMLA writes often block model downloading. | Crucial: Maintain your original PBIX/PBIP in source control (Git/DevOps). - Always keep a master copy (PBIP/PBIX + metadata) outside of the Power BI Service. After every publish/republish of the new version from Source control ensure Policies are deployed to keep the security in place. | | Report Connection | Reports may only download as "Live Connected" files. | You will lose the "report + data" download option; you will only receive a "thin" PBIX. | Rely on source control for the master file rather than the Service. | | Refresh Operations | XMLA refresh behavior differs from the standard Service refresh. | XMLA refreshes are not limited to 48 times/day and have different timeout rules. | No action needed; this is a capability benefit. | | Audit Logs | Refresh history tracks XMLA transactions. | You can verify XMLA write transactions directly in the Refresh history. | Monitor history to validate external tool operations. | | Model Features | Advanced artifacts (Calculation Groups, Translations) can be created. | Be cautious of "round-tripping" (overwriting) these features if you publish them via Desktop. | If you re-publish a semantic model with these features, you must redeploy the associated policies. | | Storage Format | "Large semantic model storage format" is often required. | Microsoft recommends this format for XMLA write performance, but it impacts portability. | If memory issues occur, switch the model storage setting to "Large semantic model storage format." | | General Blockers | Download limits exist regardless of XMLA status. | Features like Incremental Refresh and Automatic Aggregations can also block downloads. | Review the detailed limitations section below. | ### Operational Best Practices To manage these restrictions effectively, adopt the following "Be Aware" checklist: * Maintain a Golden Copy: Always keep a master copy (PBIP/PBIX + metadata) outside of the Power BI Service * Shift Mentalities: Treat model edits as Application Lifecycle Management (ALM)—using source control and controlled deployment—rather than a "download-edit-republish" workflow * Expect "Thin" Files: Assume that report downloads will be "thin" (live connection only) once the model is XMLA-modified ### Downloading Guidelines Can you download the report after an XMLA change? **Generally, NO, or only with significant restrictions** The Alternative Method: Downloading the Semantic Model If you need to access functionality (such as viewing data, RLS, or editing measures), attempt to download the Semantic Model file specifically, rather than the report * How to do it: Navigate to the workspace, select the ellipses (...) next to the semantic model, and select "Download this file" * If successful: You will receive a file allowing you to view table data , view roles/RLS , edit columns/measures , and republish to the Service. #### Limitations: When You Cannot Download The "Download this file" option is unavailable if any of the following apply: * **Role Security**: You are not at least a Contributor in the workspace. * **Model Features**: The model uses Incremental Refresh or Automatic Aggregations. * Note: To download a model with automatic aggregations, you must disable the training and delete the aggregation tables first. * **Source Origin**: The model was migrated from Azure Analysis Services or imported from OneDrive for Work/School. * **Architecture**: The model uses Direct Lake mode. * **Size Constraints**: The model exceeds the capacity SKU limit or 10GB. * **Storage Settings**: Models enabled for Large Semantic Model Storage Format generally cannot be downloaded via REST APIs , though the Service may allow it unless errors occur. * **ALM Pipelines**: Downloading is not supported for files deployed via deployment pipelines. Official Documentation for reference: #### Potential Workaround If you are blocked from downloading, the community has identified a potential workaround using Tabular Editor: * This involves using Tabular Editor to reverse-process a .PBIP file into a .PBIX file * Note: This is an advanced method and may not suit all use cases ## Power BI Model/Report and Policy Lifecycle Management Best Practices ### Summary TrustLogix outlines the end-to-end semantic model workflow lifecycle management for Power BI in environments governed by TrustLogix security policies and backed by Snowflake/Databricks or any other data sources as the data platform. It defines the required personas, responsibilities, access levels, and validation checkpoints necessary to ensure that semantic models are developed, tested, deployed, and operated in a secure, compliant, and controlled manner across Development, Test, and Production environments. As semantic models evolve through the lifecycle — from initial development to production consumption — they must consistently enforce row-level security (RLS), object-level security (OLS), and policy-driven access controls without disrupting report usability or user experience. This requires close coordination between Power BI developers, report owners, security and governance teams, TrustLogix policy administrators, IAM teams, and platform administrators, supported by robust source control and CI/CD practices. This lifecycle framework establishes: * Clear ownership and accountability at each stage of the workflow * Standardized **pre- and post-deployment validation checks** * A **Golden Copy approach** using PBIP/PBIX artifacts for reliable deployments * Controlled policy deployment and re-deployment through TrustLogix using XMLA * Consistent entitlement access patterns between Power BI and Snowflake By following this structured lifecycle approach, organizations can ensure that semantic model changes are predictable, auditable, and secure, while maintaining business agility and minimizing the risk of unintended data exposure in Power BI. ### Personas, Responsibilities & Access Matrix
PersonaPrimary ResponsibilitiesPower BI Access LevelSnowflake Access LevelCI/CD / Tooling Access
IAM / Azure AD Team

- Manage security groups & Service Principals

- Grant required API permissions (e.g., Group.Read)

- Maintain access lifecycle (joiners/movers/leavers)

No workspace access requiredNo Snowflake accessAzure AD / Entra admin
Power BI Platform / Fabric Admin

- Workspace governance and lifecycle management

- Manage deployment pipelines

- Validate pipeline health and target environments

- Manage Service Principals & permissions

Admin (Tenant & key workspaces)No business data access requiredCI/CD admin
Power BI Developer

- Develop PBIX/PBIP reports and semantic models- Implement data model, measures, relationships

- Validate report functionality in Dev

- Ensure PBIP/PBIX is checked into source control (Golden Copy)

- Support RLS/OLS validation during testing

Contributor (Dev & Test workspaces)(No Admin in Prod)Read access to required source tables/viewsNo access to entitlement view directlyRepo read/write (Dev branch)CI pipeline read
Security / Data Governance Team

- Review RLS/OLS & Validate compliance and define data protection rules

- Review TrustLogix policy logic for data protection and compliance adherence

- Approve security sign-off before Prod deployment

Member / Viewer (Prod workspace)(Viewer recommended)Review access to policy DB & entitlement metadata (read-only)Repo read-only
TrustLogix Policy Administrator

- Create and manage TrustLogix policies (RBAC / ABAC)

- Deploy policies to Test and Prod via XMLA

- Re-deploy policies after report/model republish

- Validate entitlement view push to semantic models

Admin (Dev/Test/Prod as required)(to push policies via XMLA)

Admin / Power role on:

TLX_POLICY_DB- TLX_ENTITLEMENT_VIEW

Policy repo read/write XMLA endpoint access
CI/CD Pipeline (Service Principal)

- Deploy PBIP/PBIX artifacts across environments

- Trigger model refresh where applicable

- Trigger policy redeployment as needed

Contributor (target workspace)(Admin only if required)Uses delegated Snowflake role via Power BIPipeline execution
Report Owner (Business / Data Owner)

- Own reporting requirements and data correctness- Review and approve intended security behavior (“who sees what”)

- Validate reports against business expectations

- Approve readiness for Test / Prod

Admin (Prod workspace)Contributor (Dev/Test)No direct Snowflake access required (optional read-only)Repo read-only
End Users / Report Consumers- Consume reports and dashboards- Download reports where permittedViewerNo Snowflake accessNone
### Workflow Lifecycle Management #### **Development Phase** **Before policy deployment checks (Dev → Test / Dev → Prod)** * Source control (Golden Copy): Power BI Developer * Confirm the latest PBIP/PBIX + policy scripts are checked in and are the exact artifacts that CI/CD will deploy. (PBIP is designed for project-based workflows and source control.) * Review process: Object/Report Owner * Ensure report owners have reviewed the reporting requirements and the intended security behavior (RLS/OLS expectations, “who should see what”). * Security validation in lower environment (TrustLogix policy deployment): TrustLogix Policy Administrator and Security Governance Team * Validate RLS logic on the test model (or Dev workspace model) using: * Service “Test as role” on the semantic model Security page (recommended for service behavior). * Confirm the team understands RLS only restricts Viewer users (Admins/Members/Contributors aren’t restricted). * CI/CD readiness: Power BI Platform/Fabric Admin * Confirm the pipeline is targeting the correct environment/stage and that required dependencies are healthy (connections, parameters, deployment rules if used). Deployment pipelines are the recommended structured promotion mechanism. * Entitlement View Access from Power BI: Snowflake Platform team * Each semantic model must have entitlement view access from Power BI * TrustLogix recommended approach * Create a dedicated Power BI Access Role with required permissions on the entitlement view * Assign this role to all functional roles connecting to Snowflake from Power BI **After policy deployment checks (in Test) (Data Governance Team/ Report Owner)** * Refresh transaction succeeded * Trigger/confirm a refresh as required and validate via Refresh history; this is the primary troubleshooting surface for refresh failures and for confirming XMLA-driven refresh/write activity * Since TrustLogix pushes the entitlement view to the semantic models, a refresh might be useful to validate the connections are live * Security validation * Re-test “Test as role” and validate representative user personas (viewer-level) for expected row filtering * Report connectivity / usability * Open downstream reports and confirm visuals render correctly and performance is acceptable. #### Production Phase **Before policy deployment checks (Prod publish readiness) (Report Owner)** * Prod report owner responsibilities * Confirm the report owner has: * Established the prod source connection (and validated credentials/gateway where applicable) * Performed local testing in the Desktop against prod-equivalent sources (as per your standard) * Ensure the PBIX/PBIP is checked in as the deployable Golden Copy. * Review + approvals * Ensure required approvers have signed off (security + data correctness + compliance). * Deployment pipeline status (CI/CD Pipeline Admin) * Confirm CD pipeline is healthy and that the correct prod target is selected * Entitlement View Access from Power BI: (Snowflake Platform team) * Each semantic model must have entitlement view access from Power BI * TrustLogix recommended approach * Create a dedicated Power BI Access Role with required permissions on the entitlement view * Assign this role to all functional roles connecting to Snowflake from Power BI **After policy deployment checks (in Production) (Data Governance Team / Report Owner)** * Successful refresh + monitoring * Validate Refresh history for success and capture failure details if any (credentials/timeouts/data source errors are common root causes) * Since TrustLogix pushes the entitlement view to the semantic models, a refresh might be useful to validate the connections are live * Security validation (viewer behavior) * Test with representative prod users/roles; confirm expected behavior for Viewer users (and document that workspace elevated roles bypass RLS) * Report connection and consumer experience * Confirm key reports load correctly and users can access expected content. * Add a note for consumers: downloads from the Service may be thin/live-connected depending on model configuration and governance. **Note: if there is a change to the underlying semantic model in the future, please follow all the above steps for re deploying the TrustLogix Security Policy** ### Version Control and CI/CD Pipeline Maintenance (CI/CD Pipeline team / Report Owner / Data Governance team) The most effective best practice is to have proper change management via data governance processes and treat the semantic model as a software application, requiring an ALM workflow. Publish PBIX/PBIP Files to Version Control * **Initial Commit**: Commit the master PBIX/PBIP file to a Git repository to establish the Golden Copy. * **Deployment of Policies**: After every successful deployment or update (especially those involving advanced features created via XMLA), you must redeploy the associated policies to ensure they remain in place. * **Metadata Focus**: In an ALM workflow, focus on versioning the model metadata (the PBIP folder structure) rather than the PBIX file itself. This is better suited for Git's file-based tracking. #### Maintain CI/CD Pipelines A robust Continuous Integration/Continuous Delivery (CI/CD) pipeline automates the model and policy deployment process: 1. Continuous Integration (CI): 1. Trigger: Developer commits changes to the Git repository (e.g., adding a new measure, modifying an RLS role). 2. Action: A build pipeline automatically verifies the model metadata using tools like ALM Toolkit or pbi-tools for schema validation. 2. Approvals: 1. Necessary approvals are required to push the file changes to version control. 3. Continuous Delivery (CD): 1. Action: The CD pipeline uses the XMLA endpoint to programmatically deploy the verified metadata and/or policy updates to the Test workspace. 2. Self-Healing Policy: After every publish/republish of the new version from Source control, ensure the CD pipeline automatically deploys policies (RLS, etc.) to keep security in place. 3. Promotion: Once verified in Test, the same CD pipeline promotes the changes to the Production workspace. # Trust DSPM TrustLogix provides organizations with a comprehensive security framework to monitor, analyze, and control data access effectively. By leveraging monitoring, reporting, data sprawl management, and access analysis, organizations can enhance their security posture, ensure compliance, and mitigate data risks efficiently. The core security features include: 1. **Monitoring Policies** – Continuous visibility into data access and usage. 2. **Activity and Compliance Reports** – Comprehensive insights and compliance reports. 3. **Data Sprawl** – Identifying and managing data spread across multiple locations. 4. **Access Analyzer** – Evaluating access permissions and identifying security risks. ### Monitoring Policies TrustLogix Out of the box Monitoring policies and ability to create customer policies provides capability to * Track real-time sensitive data access activities across registered data sources. * Detect unauthorized or suspicious access patterns using Shadow clients. * Monitor overly granted roles and privileges. * Monitor Sensitive data exfiltration Advantages: * Helps prevent data breaches by proactively identifying anomalies. * Improves compliance with regulatory frameworks like SOC 2, NIST, and ISO. * Provides administrators with detailed audit trails for security investigations. ### Reports TrustLogix reporting feature includes the following aspects * Generates detailed reports on data access, entitlement report and dark data. * Provides compliance reports aligned with industry standards. * Customizable dashboards for visual representation of security metrics. Advantages: * Simplifies audits by providing structured, exportable reports. * Offers real-time and scheduled reporting options. * Enhances decision-making with data-driven insights. ### Data Sprawl Data sprawl is unique feature set of TrustLogix which provides data flow UI which * Identifies sensitive data spread across different data sources. * Detects shadow data and unmanaged copies of critical information. * Helps enforce data governance policies by mapping data movement across data sources. Advantages: * Reduces security risks associated with orphaned or redundant data. * Ensures regulatory compliance by preventing unauthorized data proliferation. * Optimizes storage costs by identifying unnecessary data replication. ### Access Analyzer Access Analyzer provides the users, roles, database access layout as visual representation using which user can pivot principal aspect to verify data access across objects and mitigate any overly granted access * Evaluates user access permissions across all integrated data platforms. * Identifies excessive or misconfigured permissions that pose security risks. * Provides recommendations to enforce the principle of least privilege. Advantages: * Strengthens data security by eliminating over-provisioned access. * Reduces insider threat risks by ensuring users have only necessary privileges. * Enhances compliance by aligning access controls with industry best practices. # Monitoring Policies TrustLogix monitoring policies are used to safeguard your critical data and objects within different data sources like Snowflake, Databricks etc. These policies are designed to help data owners and governors to automatically identify, alert, and respond to suspicious activities, such as unauthorized data access, data exfiltration or account modification. ### How TrustLogix Monitoring Works The monitoring process is designed to be seamless and end-to-end. Once your data source is registered within the TrustLogix UI, the system will automatically create the out of the box monitoring policies which are curated data source specific security policies. Some of these policies are enabled by default and the others need to be enabled to receive various alerts and notifications. Refer to section on how to configure various tools that can receive these alerts. Once enabled, the TrustLogix monitoring service will continuously scan your meta data and audit data to identify suspicious activities based on your configured policies. Any detected activity is then represented as a data risk, providing you with a clear, actionable alert. ### TrustLogix System Policies The default system-level policies are a great starting point for monitoring your data source. You can find these policies under the "Monitoring Policies" tab for your registered data source. While these pre-configured policies cover a wide range of common security concerns, you have the flexibility to customize them or create entirely new policies to meet your specific organizational needs. The user can also enable or disable this policy from the TrustLogix UI. ### Creating a Custom Policy Creating a custom policy allows you to tailor your monitoring efforts to your most sensitive data and business-critical operations. The custom policy creation flow is broken down into a few key sections. #### 1. Policy Details First, provide a unique name and a descriptive purpose for your policy. * **Policy Name:** A valid, unique name for your policy. It can contain letters, numbers, underscores or spaces. * **Policy Description:** A brief description of what this policy is intended to monitor. #### 2. Principals and Conditions This section defines **who** or **what** the policy will monitor. * **Principal Type:** Select from `All`, `User`,`User Role` ,`User IP`, `User Application`. Choosing `All` monitors all of the Users, IPs, Roles and Applications. * **Condition Type:** Specify whether the policy applies `In` ,`Not In` , `Like` or `Not Like` a defined list. * **List Type:** Choose a `Allowlist` or `Specific List`. If you choose `Specific List`, you must enter the exact User names, IP addresses, User Roles or Application names to be monitored. * Allow List is prepopulated with some of the trusted applications but you can also add, update or delete them based on your requirement. * Specific List for certain principals and data sources will show a drop down of all the different objects in the data source. #### 3. Monitoring Resources and Actions This is where you specify the **object** that you want to monitor as well as the **activity types** for this particular object. * **Resource Type:** Select the type of data source object you want to monitor, such as `Account`, `Database`, `Schema`, `Table`, `View`, `Privilege`, or `Role`. * **Classification or Specific Names:** * You can monitor objects based on their classification tags which you can define in the data source using the tagging feature or you can define them in TrustLogix UI (e.g., `PII`, `Sensitive`). * Alternatively, you can monitor specific object names (e.g., a particular table or schema). * **Action Type:** Choose one or more actions to monitor. The available actions depend on the selected resource type (e.g., `alter_table`, `delete`, or `copy` for a `Table`). * **Data Size:** For actions like `copy` or `unload`, you can set a data size threshold (in KB, MB, or GB). An alert will only be triggered if the data size involved exceeds this threshold. #### 4. Alert Management Configure how and when you want to be alerted. * **Frequency:** * `Only First Occurrence`: Triggers a single alert the first time the policy matches a record. * `For Every Occurrence`: Triggers an alert every time the policy matches a record. * `After N Occurrences`: Triggers an alert only after the policy has matched the specified number of times. * **Severity:** Set the criticality of the alert to `High`, `Medium`, or `Low` based on business impact. * **Risk Category:** Categorize the type of risk the policy addresses, such as `Data Exfiltration`, `Regulatory Compliance`, or `Misconfigurations`. * **Risk Control:** Select the risk control for your monitoring policy such as `CIS`, `NIST` or `GDPR`. This is an optional field. #### 5. Alert Text and Recommendation Customize the alert message and provide a recommended course of action. * **Alert Text:** This message will appear on your "Risk Activities" page. You can use variables to create dynamic messages. For example, a message like "User `` performed privileged actions on tables classified as `` at ``" will automatically populate with the relevant details. * **Recommendation:** A message that provides remediation or a recommended next step for the corresponding alert. ### Data Classification and Allow list For data sources that do not have the **native Tagging** or Data Classification capability, TrustLogix allows you to manage Data Classifications and Allow lists directly within the platform. #### Data Classification Data can be classified in two ways: 1. **In Snowflake or Databricks platform:** Classify objects directly within your data source using **Tag** capability. 2. **In TrustLogix UI:** Use the TrustLogix console to add classification tags like `PII` or `Sensitive` to different object types. #### Allow list Allow lists are used to define security team approved users, applications, or IP addresses that are not considered "Shadow IT." You can add the following to a Allow list: * **Users** (e.g., `Bob`) * **Applications** (e.g., `Tableau`) * **IP Addresses** (e.g., `10.0.0.8` or a range like `10.0.0.8-10.0.0.18`) * **Roles** (e.g. `ADMINROLE`) Adding a principal to a Allow list ensures that actions from that principal do not trigger a policy designed to detect non Allow listed activity. # Activity and Compliance Reports TrustLogix Activity and Compliance Reports provide an auditable trail of all interactions across your multi-cloud data landscape. By correlating metadata, these reports offer the observability needed to transition to a dynamic Zero-Trust security model. Insights are delivered through dynamic visual charts and diagrams instead of static text, allowing you to identify trends—such as spikes in failed logins or clusters of inactive users—at a glance before drilling into the details. ### Reports *** The Reports page provides a comprehensive suite of deep-dive analytics designed to give security administrators and data owners granular visibility into usage, entitlements, and risk across the entire data estate. These reports move beyond high-level dashboard summaries, allowing users to select specific accounts, apply custom filters, and schedule reports for automated delivery. Once a scheduled or requested report is processed, it can be **downloaded** directly from this page for further audit or compliance use.
**The available reports are categorized into four primary areas:** #### Usage Reports These reports focus on user behavior and data interaction patterns to identify inefficiencies or potential security gaps. * **Inactive Users Report**: Lists all users who have not logged into the system for a specified number of days, helping to identify dormant accounts for cleanup. * Filtered by inactive time threshold (number of days). * **Dark Data Report:** Identifies data objects (tables, views, etc.) that have not been accessed within a defined timeframe, aiding in data lifecycle management and reducing the attack surface. * You can filter this report by a user-defined timeframe (e.g., 30, 60, or 90 days) to accurately identify "cold" data based on your storage and security requirements. * **Classification Report**: Provides a list of objects mapped to specific classifications and identifies the users who currently have access to them. * Filtered by specific classifications. * **Unused Roles By Users**: Lists users who have been granted roles but have not utilized them, highlighting opportunities to implement the principle of least privilege. * You can refine this report by selecting specific roles and specifying the number of days since last use (e.g., roles not used in the last 60 days) to audit exactly who is—or isn’t—utilizing high-privilege access. * **Long Running User Sessions**: Tracks users whose login sessions have exceeded a defined time threshold, which may indicate a security risk or orphaned processes. * You can refine this report by selecting a Session time threshold (in hours) and defining a specific Start and End Date to isolate sessions that exceed your organization’s security policy. * **Snowflake Listing Consumer Usage Report**: Contains the daily count of requests made by listings on the Snowflake Marketplace and data exchanges. * You can generate this report by specifying a Start Date and End Date to analyze consumption trends and request volume over a defined period. * **Snowflake Data Share Consumer Report**: Provides an overview of which tables are being joined together (pairs), broken down by the consumer of the data. * You can generate or filter this report by specifying a Start Date and End Date to analyze consumption trends over a chosen period. * **Snowflake Secondary Roles Report**: Identifies users and their roles where the default secondary role setting is set to 'ALL'. * **User Activity Report**: Generates a complete, detailed log of all user activities performed within a specific data source over a chosen period. * Narrow your audit by User Name(s), specific Actions, Database/Schema/Table hierarchy, and a precise Start/End Date. #### Entitlement Reports These reports provide a clear map of permissions, helping administrators understand exactly "who has access to what" across complex environments. * **Entitlement Report By User**: Lists all objects a specific user has been assigned access to, along with their corresponding privilege sets. * Target your audit by selecting a Data Source, specific User Name(s), and optional parameters for Object Type (e.g., Table, View) or specific Object Name(s). * **Entitlement Report By Role**: Details all objects assigned to specific roles and the associated privileges granted to those roles. * Target your audit by selecting a Data Source, entering specific Role Name(s), and optionally filtering by Object Type (e.g., Database, User and/or Warehouse). * **Entitlement Report By Group**: Provides a consolidated view of all objects and privileges assigned to specific user groups. * Refine your audit by selecting a Data Source, specifying the Group(s) to be reviewed, and optionally filtering by Object Type (e.g., User and/or Catalog). * **Overlapping Privilege Analysis**: Identifies instances where a user has been granted the same privileges through multiple roles for the same database, helping to simplify role hierarchies. * Target the analysis by selecting a Data Source, a specific User Name, the target Database Name, and the specific Object Privilege(s) you wish to audit. * **Unused Privileges By Users**: pinpoints specific users who have been granted privileges but have not actually exercised them. * Refine the report by selecting a Data Source, specifying User Name(s), choosing the Object Privilege(s) to audit, and setting the Last used (days) threshold to identify long-term inactivity. #### Risk Reports * Risk Summary Report: Provides a high-level summary of risks identified by various monitoring policies, broken down by category and policy type to prioritize remediation efforts. * Generate the summary by selecting a Data Source and defining a specific Start Date and End Date to review risk trends over a chosen period. #### TrustLogix Reports * Audit Report: Tracks internal administrative events within the TrustLogix platform itself, such as user logins to the portal and the creation of new access policies. * Access Policy Secured Objects: This report contains the list of objects that are secured by the access policies. * Refine the report by selecting a Data Source, a specific RBAC or ABAC Tag Policy, and the Policy Type to isolate how specific data sets are being secured. ### Data Source Overview Reports * **Identity Security**: Identity related risks in the last 7 days which includes inactive users and overly granted roles etc. * **Dark Data**: Objects that have not been accessed in the last 90 days. * **Shadow IT Client Tools**: Tools connecting in the last 7 days that are not part of the application allow list. * **Data Management**: Data movement activity in the last 7 days * **Data Access**: Data access activity on classified objects in the last 7 days * **Failed Login Activity**: User login failures in the last 7 days # Data Sprawl TrustLogix generates the Data Sprawl report to showcase the following things * All the outbound nodes to which your data source data is being sent to * All the inbound nodes from which data is coming into your data source * Security risk alerts that are tied to the inbound and outbound nodes * Different types of data movements like Share activity, Large data being exported out etc. The primary purpose of this report is to highlight various security issues like the ones below * Is your sensitive data being moved to compromised data sources like a public AWS S3 bucket or Azure ADLS container * Are unsanctioned User Applications connecting to your data source and performing risky activity * Cost impact of moving data to various downstream data sources * Lack of data access controls on different objects within your data sources.
# Access Analyzer # Snowflake Trust Center Scanner Package This page contains the documentation related to the Trust Center Native App policies ### Overview The **TLX Role Reports** scanner package is a comprehensive security and compliance monitoring solution designed for Snowflake data platforms. This package automatically scans your Snowflake account to identify potential security vulnerabilities, compliance gaps, and access control issues that could put your organization's data at risk. Think of it as your automated security auditor that runs continuously in the background, examining user roles, data access patterns, and security configurations to help you maintain a secure and compliant data environment. *** ### What This Package Does The TLX Role Reports scanner package performs automated security assessments across four critical areas: 1. **Unused Role Detection** - Identifies roles that have been assigned but aren't being actively used 2. **Sensitive Data Protection** - Finds sensitive data columns that lack proper masking policies 3. **External Access Monitoring** - Tracks which roles can access external storage systems 4. **Privilege Management** - Monitors users with high-level system roles Each scanner runs independently and provides detailed reports with severity ratings, remediation guidance, and specific entities that need attention. The package integrates seamlessly with Snowflake's Trust Center to provide a unified view of your security posture. *** ### Understanding Severity Levels All scanners in this package use a common severity rating system based on the number of at-risk entities found. The severity is automatically calculated and helps prioritize which issues need immediate attention: * **LOW**: Less than 15 at-risk entities * Indicates a relatively small number of issues that should be addressed as part of regular maintenance * **MEDIUM**: 15-49 at-risk entities * Suggests a moderate security concern that warrants attention in the near term * **HIGH**: 50-500 at-risk entities * Represents a significant security risk that should be prioritized for remediation * **CRITICAL**: More than 500 at-risk entities * Indicates a widespread security issue requiring immediate action and potentially a comprehensive remediation plan The severity level helps you understand the scale of the issue and prioritize your response efforts accordingly. *** ### Scanner Details #### 1. Detect Unused Roles By Users **What It Does:** This scanner identifies users who have been assigned critical roles (like ACCOUNTADMIN, SECURITYADMIN, USERADMIN, or SYSADMIN) but haven't actually used those roles to execute any queries. By default, it flags roles that have been inactive for at least 90 days. **Why It Matters:** When users have powerful roles assigned but never use them, you're essentially leaving "keys to the kingdom" lying around. These unused roles create security risks because: * They expand your attack surface - if a user account is compromised, unused roles provide additional privileges that attackers could exploit * They violate the principle of least privilege - users should only have access to what they actually need * They create compliance and audit challenges - auditors question why users have permissions they don't use * They contribute to "role explosion" - over time, unused roles accumulate and make access management increasingly complex **How It Works:** The scanner compares two data sources: * **User-Role Assignments**: Which users have which roles assigned to them * **Query History**: When each user-role combination was last used to run a query If a role has been assigned but never used, or hasn't been used within the configured time period (default 90 days), it's flagged as a risk. **Recommended Actions:** * Regularly audit role assignments and remove roles that are no longer needed * Implement automated role lifecycle management to revoke unused roles * Review access logs periodically to ensure all assigned roles serve a valid purpose * Consider implementing Just-In-Time (JIT) role activation for critical roles *** #### 2. Detect Sensitive Columns Without Masking Policies **What It Does:** This scanner identifies database columns that have been tagged with privacy category tags (indicating they contain sensitive or personally identifiable information) but don't have masking policies applied to protect that data. **Why It Matters:** Sensitive data like Social Security numbers, credit card information, email addresses, or health records require special protection. Masking policies ensure that when users query these columns, they only see data that's appropriate for their role - for example, a customer service representative might see only the last four digits of a credit card, while a data analyst might see fully masked values. Without masking policies: * **Compliance Violations**: Regulations like GDPR, HIPAA, and PCI-DSS require protection of sensitive data * **Data Exposure**: Users with legitimate access to a table might see sensitive data they don't need * **Audit Failures**: Security audits will flag unprotected sensitive data as a critical finding * **Reputation Risk**: Data breaches involving unprotected sensitive information can severely damage your organization's reputation **How It Works:** The scanner: 1. Finds all columns tagged with privacy category tags (indicating sensitive data) 2. Checks whether those columns have masking policies attached 3. Reports any tagged columns that lack protection **Recommended Actions:** * Apply masking policies to all columns containing sensitive data * Enforce role-based access controls (RBAC) to restrict sensitive data access * Regularly review permissions to ensure only authorized personnel can access PII fields * Implement encryption and anonymization techniques where applicable * Establish a data classification process to ensure all sensitive data is properly tagged *** #### 3. Detect Roles Accessing External Storage **What It Does:** This scanner identifies which roles have usage privileges on external stages - these are connections to storage systems outside of Snowflake (like AWS S3, Azure Blob Storage, or Google Cloud Storage). It shows you which external storage locations are accessible and which roles can access them. **Why It Matters:** External stages allow data to move in and out of Snowflake, which is powerful but also risky: * **Data Exfiltration Risk**: Unauthorized access to external stages could allow someone to export sensitive data outside your Snowflake environment * **Compliance Concerns**: Data movement to external systems may violate data residency or privacy regulations * **Audit Complexity**: As your organization grows and roles multiply, it becomes difficult to track who has access to external data sources * **Attack Surface**: External stages create additional entry points that need to be monitored and controlled **How It Works:** The scanner examines: * All external stages configured in your Snowflake account * Which roles have been granted USAGE privileges on those stages * Groups stages by their external URL to show all roles that can access each external storage location **Recommended Actions:** * Review all roles with external stage access and validate that access is necessary * Restrict external stage access to only roles that require it for legitimate business purposes * Monitor data movement logs to detect unauthorized access attempts * Apply strict policies on data export and ensure security measures are in place for outbound transfers * Consider implementing data loss prevention (DLP) tools to monitor external data access *** #### 4. Detect System Defined Role Assignments **What It Does:** This scanner identifies users who have been granted system-defined roles with elevated privileges. By default, it monitors for the four most powerful system roles: ACCOUNTADMIN, SYSADMIN, SECURITYADMIN, and USERADMIN. It can exclude specific users from the report (via an allowlist) if they're authorized to have these roles. **Why It Matters:** System-defined roles in Snowflake have extensive privileges: * **ACCOUNTADMIN**: Full control over the entire Snowflake account * **SYSADMIN**: Can create and manage all objects except users and roles * **SECURITYADMIN**: Can manage users, roles, and security policies * **USERADMIN**: Can create and manage users and roles Having too many users with these roles creates significant security risks: * **Privilege Escalation**: If a user with high privileges is compromised, attackers gain extensive access * **Accidental Damage**: Users with excessive privileges might accidentally modify or delete critical data * **Compliance Issues**: Regulations often require limiting administrative access * **Audit Challenges**: Auditors expect to see strict controls on who has administrative access **How It Works:** The scanner: 1. Identifies all users who have been granted system-defined roles 2. Excludes users on the allowlist (pre-approved users who should have these roles) 3. Reports remaining users with their assigned system roles **Recommended Actions:** * Regularly audit users with high privileges and validate that those grants are necessary * Implement the principle of least privilege (PoLP) - grant only the minimum access needed * Use Just-In-Time (JIT) privilege escalation to grant elevated privileges only when required * Set up alerts to track and report any unauthorized privilege escalations * Maintain a documented list of authorized administrative users * Consider using role hierarchies instead of direct system role assignments *** ### Understanding Scanner Results Each scanner provides several key pieces of information: #### Risk Identification * **Risk ID**: A unique identifier for this type of risk * **Risk Name**: A human-readable name describing the risk * **Scanner Type**: Vulnerability #### Impact Assessment * **Total At-Risk Count**: The number of entities (users, columns, stages, etc.) that have this risk * **Severity**: Automatically calculated based on the count (LOW, MEDIUM, HIGH, or CRITICAL) * **Impact Description**: An explanation of why this risk matters to your organization #### Detailed Findings * **At-Risk Entities**: A list of specific users, columns, or other objects that need attention * Each entity includes: * Entity ID: A unique identifier * Entity Name: The name of the user, column, or object * Entity Object Type: What kind of entity it is (USER, COLUMN, EXTERNAL\_STAGE) * Entity Detail: Additional context about the specific finding #### Remediation Guidance * **Suggested Action**: Step-by-step recommendations for addressing the identified risks *** ### Best Practices 1. **Run Scans Regularly**: Schedule scans to run on a regular basis (weekly or monthly) to catch issues early 2. **Review Severity Levels**: Pay special attention to HIGH and CRITICAL findings, but don't ignore LOW and MEDIUM issues 3. **Act on Findings**: Use the remediation guidance to address identified risks promptly 4. **Maintain Allowlists**: Keep your allowlists up to date to ensure legitimate access isn't flagged 5. **Document Decisions**: When you choose not to remediate a finding, document why for audit purposes 6. **Integrate with Processes**: Make scanner results part of your regular security review and compliance processes *** ### Support and Resources For more information about role management and security best practices, refer to: * [TrustLogix Blog: Siloed RBAC, Role Explosion, and Its Impact on Data Access Security Management](https://www.trustlogix.io/blog/siloed-rbac-role-explosion-and-its-impact-on-data-access-security-management) *** # Trust AI The TrustAI module within TrustLogix is an intelligent policy enforcement and governance solution designed specifically to manage and secure the data access of Artificial Intelligence (AI) agents and applications. Its core high-level function is to ensure that AI agents operate under the principle of Least Privilege, accessing only the precise data necessary for their tasks, thereby preventing unintended data leaks, misuse, and compliance violations. # MCP Gateway and AI Agent Setup This document provides a detailed, step-by-step walkthrough for configuring the TrustLogix MCP Gateway, setting up the TrustLogix AI Agent, and registering Snowflake MCP services within the TrustLogix platform. *** ## EntraID Configuration & TrustLogix Gateway Registration The TrustLogix MCP Gateway is a centralized proxy deployed by TrustLogix that intercepts all calls to registered MCP servers. To function, this gateway uses a dedicated service principal to securely connect with the TrustLogix platform and downstream MCP servers, allowing it to fetch the authorized MCP server list, enforce active security policies, and act as a secured MCP client to the proxied customer MCP servers. **1. Create the MCP Gateway Azure Application** * Purpose: You must create a dedicated Azure application to manage authentication for the MCP Gateway. * Set up the EntraID Application to configure the TrustLogix service principle for Gateway authentication and authorization. Follow the Azure documentation to create and configure the Azure application: [Azure App Registration](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) * Important Configuration: While setting up the application in the Azure portal, add the following redirect URL: example: https\://{dp.trustlogix.io}/api/mcp/oauth/callback\ Note: Adjust the domain name as provided by the TrustLogix team. * Important Configuration: While setting up the application in the Azure portal, navigate to Expose an API tab and add the scope gateway\_access as a scope.\ When adding the gateway\_access scope, select user consent.\ The resultant scope should be api://{client\_id}/gateway\_access
**2. Register the MCP Gateway in TrustLogix** * Access Console: Log in to the TrustLogix console and select MCP from the left-hand navigation menu. * Enforcement Strategy: Click on Enforcement Option and select MCP Gateway. * Enter Credentials: Input the Client ID, Client Secret, and Token/Authorization Endpoint generated from your Azure application into the Security Credentials (OAuth) section. For Azure, ensure that gateway is configured with v2 Azure endpoint **Note**: Copy the Gateway URL provided in the screen, agent developers will use this in the agent code. They need to use this URL when instantiating the MCP Client ## Configuring AI Agent & Attribute-Based Access To apply the correct security rules, TrustLogix needs to know exactly who is requesting data and which AI agent is acting on their behalf. By synchronizing rich identity metadata from Azure, we provide TrustLogix with the context required to enforce dynamic, Attribute-Based Access Control (ABAC) policies—ensuring that users and AI agents only access the data they are explicitly authorized to see. **1. Define Attributes in TrustLogix** Next, define how TrustLogix categorizes the data it receives from Azure. 1. Navigation: Go to the Attribute Management section in the left-hand menu. 2. Create Attributes: Click Add Attribute and define the Identity Type (select either User or Agent). Select TrustLogix as the target. 3. Sync Sources: Link these newly created attributes to your attribute source integration so TrustLogix can pull relevant metadata—such as Department, Azure Groups, City, or Purpose. 4. Create TrustLogix PIP user attributes using the attribute source integration (e.g., Department, Azure Groups).\ \ **Prerequisite**: If mapping user or agent attributes into any target from an external source like Azure, the TLX Control Plane itself requires a service principal for authorization to Azure when syncing attributes. To set this up, see the relevant [Attribute Source Connection Configuration Docs](https://docs.trustlogix.io/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint#id-3.-follow-the-prerequisite-steps)
**2. Create AI Agent Azure Application** Purpose: You need a service principal Azure application that represents the AI agent identity that is used for authorization to the MCP gateway, and for client\_id unique identifier for agent attribute. 1. Follow the[ ](https://docs.trustlogix.io/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint#id-2.-configure-the-connection-details)[Azure App Registration](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) to create this application. 2. Redirect URL: For this application, navigate to the Authentication settings and set the redirect URL to: example: Customers would put the callback for their AI agent clients. 3. Grant API Permission: For this application, navigate to the API permissions and select Add a permission. In the APIs my organization uses, search for the Gateway application that was created step 1. Select that application, then in Delegated permissions, select gateway\_access. After creating the API permission for the agent to access the Gateway, select Grant admin consent for Default Directory
**3. Create the AI Agent** 1. Navigation: Go to AI Agent in the left-hand menu and click Create AI Agent. 2. Identity: Provide a descriptive name (e.g., "Health Dev Agent"). Enter the Client ID, Client Secret, and Scope of api://{client\_id}/.default 3. Assign Attributes: After validating the credentials, Manually assign metadata to define the agent's persona for policy evaluation. For example: 1. Agent Purpose: Sales 2. Agent License: GLOBAL ## Registering MCP Services & Securing Tools With the identity and attribute pipeline established, the final step is to bring your AI Agent online and connect it to your data environments. By registering the MCP service, TrustLogix automatically discovers the underlying tools it provides (such as specific Snowflake operations). This visibility allows you to create and deploy granular access policies, ensuring strict governance over exactly who—which users and AI personas—is authorized to execute specific tools. \ **Prerequisites for registering Snowflake MCP service and deploying policies** 1\. **Snowflake Account Registration** A snowflake account must be first registered with TrustLogix. See [Snowflake Account Registration Docs](https://docs.trustlogix.io/data-sources/snowflake). Ensure you also run the mcp\_grants SQL script. This script grants Control Plane the necessary privileges to discover MCP servers within snowflake as they are created across the whole account. 2\. **Snowflake JWT Service Principal Setup** This auth option uses a static snowflake service principal via JWT. Refer to [Snowflake Key Pair OAuth for Custom Client Docs](https://docs.snowflake.com/en/user-guide/oauth-custom#using-key-pair-authentication). Make sure to save your private key and passphrase somewhere safe for later 3\. **Snowflake External OAuth (Azure) Service Principal OBO Setup** This auth option sets up the TrustLogix proxy/gateway from step 1 as an external OAUTH azure client service principal in Snowflake. Please refer to [Snowflake External OAuth Integration](https://community.snowflake.com/s/article/Create-External-OAuth-Token-Using-Azure-AD-For-The-OAuth-Client-Itself). This step also requires retrieving an OAUTH token yourself to use in the VERIFY\_EXTERNAL\_OAUTH\_TOKEN function. You can do this using services like Postman, Insomnia, etc. Ensure that for this request, it is of type Client Credentials. This is to retrieve a token that represents the service principal (the gateway) to tie it to a new user in Snowflake registration as part of Step 6. Use the gateway’s configured client id and secret, however for scope, ensure you request for ./default permission on the snowflake resource client id (i.e. api://{sf\_client\_id}/.default). Here, you will register another azure application representing snowflake as a resource. Expose the scope session:role-any so that the default role of the the user you set up in step 6 create system user is used. If you configure another specific role instead to be used, the scope should be session:role:{ROLE}, as specified in step 1 register OAUTH app. \ We then need to give the gateway access to this snowflake resource. Go to the gateway registered client app and navigate to the API permissions and select add permissions. Search for the snowflake resource, and add the exposed session scope. Then grant admin consent to provision the permission. 4\. **Data access grants**\ Ensure that the default role assigned to the underlying service principal in JWT, or in OBO the role specified in the scope, has access to the database, schema that the snowflake MCP resides in, as well as the MCP object itself, and any data that would possibly be queried by the gateway. Access controls will be enforced via the obo propagated logged in user conditions. Finally, register the target service (e.g., Snowflake MCP) and enforce your security policies.
* **Registration**: Under MCP, click Register MCP Service. * **Server Configuration**: Enter the Server Name and select Snowflake as the type **Authentication Options** 1. Authentication Strategy: identity the MCP Gateway will use when connecting to your MCP service. 1. JWT: Service account will be accessing the MCP server 2. Oauth: Oauth based authentication for downstream applications 2. Service Identity (Oauth): identity the MCP gateway will use when connecting to the MCP server 1. Gateway: Reuse the gateway credentials to connect to the MCP server 2. Custom: Provide your own credentials. This involves providing a client id and secret 3. Grant Type (Oauth) 1. Client Credentials 2. Token Exchange: Exchange tokens on behalf of the user 4. Type of Exchange (Token Exchange): 1. Delegation (OBO): Use the service identity selected above to authenticate on behalf of the user 2. Impersonation: Act as the user identity * **Tool Discovery**: TrustLogix will automatically scan the Snowflake MCP to discover available tools, such as sql\_exec\_tool. **Deploy Security Policies** * Server Access Policy: Define who can access the entire MCP server based on attributes (e.g., Purpose Equals Sales). * Tool-Level Policy: Create specific rules for individual tools (e.g., allow sql\_exec\_tool only if Department Equals Finance OR Purpose Equals Sales). * Deployment: Review the summary (showing default behavior as Deny by default) and click Deploy Policies to activate protection.
# AI Agents The AI Agent module in TrustLogix is called TrustAI. It is a core component of the TrustLogix Data Security Platform designed to secure and govern data access by Artificial Intelligence (AI) agents and pipelines. TrustAI ensures that sensitive data remains secure and compliant even as organizations adopt and scale their AI initiatives. The AI Agent module focuses on providing dynamic, policy-based data security specifically for AI systems. Its primary functions include: * Enforcing Business-Aware Access Control: TrustAI utilizes Attribute-Based Access Control (ABAC) policies to define fine-grained access for AI agents. * Dynamic Policy Enforcement: When an AI agent requests data, TrustAI's core intelligence, via a Policy Decision Engine (PDE) exposed through the TrustLogix MCP Server, determines the entitlements in real-time. The server returns a decision (permit, deny, or conditionally allow), which the AI agent then uses to rewrite, filter, or constrain its data query before execution. * Preventing Unintended Data Leakage: By applying data sensitivity policies automatically during AI training and inference, TrustAI ensures that sensitive data is protected. This is crucial for maintaining a least-privilege security posture for AI workflows. # Register an AI Agent Registering and connecting AI Agents to TrustLogix ## 1. Create Agent * To register an AI Agent into the TrustLogix system, you can navigate to the **AI Agents** screen using the top left menu. * Here, you can click **Create Agent**, and provide name, description, and status. {% hint style="info" %} Only AI Agents set to the **"ACTIVE"** status will be available in the policy engine {% endhint %} ## 2. Configure Agent * Once created, you **MUST** set up the agent configuration. Navigate to the created AI Agent, then to the **Configuration** tab. * Here, you have the option to configure the **Entitlement Source** and **OAuth**. {% hint style="warning" %} Currently, only other registered data accounts are supported as entitlement sources. Direct entitlement sync from configurable sources is a planned feature. {% endhint %} * OAuth configuration corresponds to the **AI Agent** identity. * We currently recommend using an existing registered application, as this identity will be used for agent activity monitoring in other registered systems in TrustLogix as well as **Just-In-Time** policies. {% hint style="warning" %} Ensure the provided scope follows **Client-Credential/Self-Issued** scope formats according to your Identity Provider (i.e. Azure uses 'api://{client-id}/.default', Okta uses 'default', etc) {% endhint %} {% hint style="info" %} If connecting to **Databricks**, select "**OAuth User to Machine Per User**" for Auth type. {% endhint %} * After completing the form and clicking **Save**, an optional **API-Key** is generated, which can be used for additional security if securing a **custom** AI Agent by including it in the request headers of the MCP Client. ## 3. Connecting Agent * To communicate with AI Agents, TrustAI utilizes the **MCP** protocol to offer real-time policy decisions with respect to user identity, agent identity, and a host of conditions. * See [MCP Server](/trust-ai/mcp-server) for more details. {% hint style="warning" %} A common concern with connecting via MCP is the non-determinism in whether a policy is evaluated, as the AI Agent must call the tool. \ \ We recommend distributing responsibilities across your agents and orchestrating according to responses from the TrustAI MCP Server.\ \ If managing deployment yourself (i.e. LangSmith), LLM guardrails must be implemented by developers. {% endhint %} # Resources Data that AI Agents and Applications can access are defined as "resources". ## Discoverable Resources AI Agents can access data via "resources". If TrustLogix doesn't currently support discovery/import for a desired resource, they can be manually configured in the console. {% hint style="warning" %} Currently, TrustLogix only supports automatic discovery of database objects in registered data accounts and data products across all data domains. \ \ Additionally, we offer 4 resource types out of the box (File, Folder, API, Data Product) that can be used to manually configure resources. {% endhint %} ## Custom Resource Creation * Custom resource types can be defined in the **Resources Type** tab. Resource types consist of name, description, attributes, and actions. * Once the resource type is created, it can be selected during the manual resource creation in the **Resource** tab. * Along with any custom resources created here, resources that TrustLogix discovers will be automatically selectable during policy creation in the **Access Policies** tab. See [Access Policies](/trust-ai/ai-agents/access-policies) for more details. # Access Policies Access policies for AI Agents are created on "resources" ## Create & Deploy Policy * To create an AI Agent access policy, navigate to the desired AI Agent and go to the **Access Policies** tab * Click **Create Policy** and provide a name and description, then click **Next.** * Next, select the desired **Resource Source** for the policy {% hint style="warning" %} Currently, only Data Sources & Data Products are supported discoverable resource sources. {% endhint %} * After selecting the desired **Resources**, click **Next**. * Policy conditions can be made with respect to **Resource Attributes** and **User Attributes/Entitlements** * After saving and deploying the policy, the policy will be evaluated and decision returned dynamically to the AI Agent when it requests access to the resource via MCP. See [MCP Server](/trust-ai/mcp-server) for more details. # MCP Server Connecting to TrustAI MCP Server * TrustLogix utilizes **MCP** protocol to expose the TrustAI Policy Engine to the registered agents. * The TrustAI **MCP Server** implements [**RFC9728**](https://datatracker.ietf.org/doc/html/rfc9728) in accordance with the [**MCP Authentication Specification**](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)**.** {% hint style="info" %} If securing an agent platform (like ChatGPT, Claude Desktop, Databricks, etc), you must setup a custom external MCP connection. {% endhint %} * When configuring OAuth for the MCP connection (see [MCP Server](/trust-ai/mcp-server) for more details), be sure to use the **same** registered application's OAuth details provided earlier to TrustLogix. * This ensures the proper agent identity is propagated at decision time and is correctly correlated with activity logs from other registered systems. The MCP URL is custom for each agent, and follows the following pattern: > https\://{tlx-mcp-host}/tenants/{tenant-id}/agents/{agent-id}/mcp * If securing a custom agent, developers must implement an additional MCP Client connection in the agent code. * Ensure that the end-user's OAuth token is passed in the Authorization header to properly propagate end user identities. {% hint style="warning" %} It is the developer's responsibility to properly implement authentication, the MCP client, and to add needed changes to system prompts. {% endhint %} # ChatGPT ChatGPT Custom Apps To connect your organization's ChatGPT Enterprise plan agents to TrustLogix, administrators can create a **Custom App** in your organization's workspace settings and publish for users to use.
Users can find the published app and connect to it in ChatGPT UI.
To chat while secured by Trustlogix, users must enable the connection for all chats.
# Claude Desktop Claude Connectors To connect Claude Desktop to TrustLogix, users can add a **Custom Connector**.
Users can then connect and log in. To secure the agent, the connector must be selected for each chat.
# Databricks Connect Databricks Agents to Trustlogix 1. Select **Create** for an **external HTTP connection** in **Unity Catalog** {% hint style="info" %} Make sure to select **OAuth User to Machine Per User** {% endhint %}
2. Next, configure the same Authentication credentials as those provided to Trustlogix when registering the Databricks Agent. {% hint style="info" %} Note: These authentication fields are for retrieving the **user's** OAuth token. As such, OAuth scope should be with respect to **user** scopes (rather than the scope for the **agent**) {% endhint %}
3. Then, configure the corresponding token endpoint. For base path, follow the pattern to include tenant and agent ids. Check the MCP connection box, and select Header Only for exchange method.
4. Users can login/retrieve credentials for the connection and use it as an external MCP server tool source for their agents.
# Guardian Agent Guardian Agent is our next-generation security agent and a conversational security expert designed to revolutionize how you manage security, compliance, and data governance. ### **Key Functionalities** #### **Intelligent Monitoring & Auditing:** * **Agent Activity Tracking:** Instantly identify unauthorized query executions and monitor agent behavior to ensure it aligns with security controls like NIST and ISO42001. * **Permission Forensics:** Quickly trace back which specific permissions or privileges enabled a particular action or query by an agent. #### Advanced Privilege Abuse Detection: * **Role Analysis:** Proactively identify users and agents with excessive privileges, such as the ACCOUNTADMIN role, and analyze historical GRANT and REVOKE operations. * **Assignment Security:** Automatically check for security issues within role assignments and ensure users or agents have appropriate access for their job functions/purpose. #### Sensitive Data Protection: * **Masking Policy Validation:** Verify which sensitive columns lack masking policies and monitor which agents are accessing them. #### Dark Data & Residency Insights: * **Inactive Data Cleanup:** Identify "dark" tables—sensitive data that hasn't been queried in over 90 days—to reduce your risk surface and storage costs. * **Cross-Environment Monitoring:** Detect cross-database or cross-environment access patterns and track data movement or export activities by agents and/or users. #### Comprehensive User Profiling: * Get instant snapshots of user profiles, including their roles, departments, default namespaces, and MFA status. ### Key Benefits * **Automated Compliance:** Stay ahead of regulatory requirements with built-in support for GDPR, CCPA/CPRA, ISO27001, ISO42001, SOC2, and NIST CSF. * **Proactive Risk Mitigation:** Catch dormant admin accounts, potential data exfiltration, and privilege escalations before they can be exploited by agents. * **Operational Efficiency:** Replace hours of manual log analysis and complex SQL queries with simple natural language questions. * **Enhanced Visibility:** Gain a 360-degree view of your data ecosystem, from who has access to how that data is moving across your organization. * **Actionable Insights:** Every query provides not just data, but suggested next steps to help you further harden your security environment. ### What’s Next? We are continuously expanding Guardian Agent’s capabilities. Soon, you’ll be able to download detailed audit records directly as CSV files and enjoy even more refined "Suggested Next Questions" to guide your security investigations. Empower your security team with Guardian Agent today—the future of intelligent data protection.
# Trust Access # Data Access Governance TrustLogix provides a comprehensive **Data Access Governance** feature to enable organizations to manage, monitor, and enforce secure and compliant access to their sensitive data across multiple data sources. Key aspects of the feature include: *** **Centralized Policy Management** * **No-code Policy Definition**: Administrators can define and manage access policies using an intuitive no-code interface. * **Unified Platform**: Provides a single pane of glass to govern data access across diverse platforms like Snowflake, Databricks, SQL Server, Aurora RDS, and MySQL. *** **Access Control Models** TrustLogix supports industry-standard access control frameworks, including: * **RBAC (Role-Based Access Control) using Object Access policy types**: * Uses persona-driven templates to assign access based on user roles (e.g., Finance, HR). * Simplifies management by aligning roles with organizational structure. * **ABAC (Attribute-Based Access Control)**: * Leverages entitlement attributes (e.g., geography, project, or business unit) for fine-grained access control. * Dynamically applies access rules based on user attributes. * Protects sensitive information by enforcing data masking policies based on patterns (e.g., SSNs, credit card numbers) and entitlements. * **Domain Policies**: * Enforces uniform policies across all registered data sources for a specific business domain (e.g., finance or sales). # Object Access Policies #### **Object Access Policies in TrustLogix** **Object Access Policies** are **RBAC (Role-Based Access Control) policies** designed to manage permissions for **system objects** (e.g., accounts, warehouses) and **database objects** (e.g., databases, schemas, tables, views). These policies ensure **controlled access** based on predefined roles and permissions. **Types of Object Access Policies:** 1. **Privilege Template-Based Policies** * Standardized role and privilege assignments for system and database objects. * Ensures consistent access control across environments. 2. **Tag-Based Policies** * Leverages **data classification tags** to enforce access restrictions. * Allows automated policy application based on **data sensitivity** or **compliance requirements**. 3. **Database, Schema, and Table-Level RBAC Policies** * Grants or restricts access **at a granular level**, ensuring least-privilege access. * Supports **role-based access enforcement** for specific objects like tables and views. By defining **Object Access Policies**, organizations can enforce **fine-grained access control**, reduce security risks, and streamline **data governance**. # Privilege Template Policies #### **Privilege Template Policies in TrustLogix** **Privilege Template Policies** simplify access control by providing predefined **access policies** for databases and schemas. These policies are based on [**Privilege Templates**](/configurations/templates), which define the **object types and associated privileges** that will be granted to a **role or user** when the template is applied. #### **How Privilege Template Policies Work** 1. **Define a Privilege Template** * A **template** specifies the **object types (database, schema, table, etc.)** and the **privileges (SELECT, INSERT, DELETE, etc.)** assigned to users or roles. 2. **Apply the Template During Policy Creation** * When creating an **Object Access Policy**, select a **Privilege Template** to automatically enforce predefined permissions. 3. **Role-Based Access Alignment** * Templates are structured around **data access personas**, such as: * **Data Analyst** – Read-only access to analytical datasets. * **Data Engineer** – Read and write access to transform data. * **Data Admin** – Full control over database objects. * **System Admin** – Administrative privileges for system-level management. 4. **Pre-Built & Customizable Templates** * TrustLogix provides **industry-standard privilege templates** out of the box. * Organizations can **customize existing templates** or **create new ones** based on specific access requirements. #### **Creation of Privilege Template Policies** Login as Super User or Policy Administrator Click on Data Sources from main menu. User will see all the allowed data sources in the data sources list view Select the data source for which user wants to create access policies(User can create access policies on data source for which he/she has access to) If Access Policies is not the default tab, Click on Access Policies tab. Click on Create Access Policy button on access policy list view Select Object Access card from the create policy model Enter Policy Name and Policy Description Select Privilege Template as Policy type from the drop down Select the template name from the Privilege Template drop down (Click on Template link below the drop down to see what all object type and privileges are mapped under the selected template) Select the objects based on the chosen objects > ***Schema represents the least object selection privilege in Template policy. All lower-level object privileges are applied at the schema and database levels, depending on the chosen schema option. If the option selected is ALL\_SCHEMAS for a database, it means that grants are applied at the database level, and individual schema selection is not permitted for that database. However, if an individual schema is selected, then grants will be applied at the schema level.*** Select Next button after selecting objects. Select Principal value from the drop down > **Principal value is** > > ***Role for Snowflake*** > > ***Account User or Account Group for Databricks*** Select Save button, to generate the grants for the selected objects and principal Once the selected values are validated, grants will be generated > If the values provided are not valid, the policy creation process will result in an error due to validation failures. Validation can fail for the following reasons: > > 1. Duplicate Policy Creation: A policy already exists for the selected object and principal combination. > 2. Catalog Access: The policy creation will fail if the catalog data is not accessible by control plane role. On successful validation, policy is created and ready for deployment Click on deploy button, on successful deployment the policy status will be moved to Deployed. > ***Policy deployment will be successful only all grants to be properly assigned to the TrustLogix user and no duplicate policy exists. Otherwise, the policy will fail, and any missing grants or configurations must be reported.*** **Benefits of Privilege Template Policies** **Standardized Access Control** – Ensures role-based permissions follow security best practices.\ **Simplified Policy Management** – Reduces manual effort in defining privileges for each user/role.\ **Customizable for Flexibility** – Organizations can tailor policies to their **specific data governance needs**.\ **Enforces Least-Privilege** – Grants only necessary permissions, minimizing security risks. # Tag Based Policies TrustLogix Tag-Based Access Policies provide a flexible and scalable approach to managing access control across data assets. By leveraging metadata tagging, organizations can define and enforce security policies dynamically, ensuring that access controls remain consistent across databases, schemas, and tables. Tag-based policies simplify this process by automatically applying access grants based on object tags, streamlining governance and reducing administrative overhead. #### **Creation of Tag Based Policies** Login as Super User or Policy Administrator Click on Data Sources from main menu. User will see all the allowed data sources in the data sources list view Select the data source for which user wants to create access policies(User can create access policies on data source for which he/she has access to) If Access Policies is not the default tab, Click on Access Policies tab. Click on Create Access Policy button on access policy list view Select Object Access card from the create policy model Enter Policy Name and Policy Description Select Tag as Policy type from the drop down Select the Tag names from the Tags drop down Select the objects privileges from the drop down > ***Object privileges (Select,Insert, Update, Delete, Truncate) is supported, and only Table and View objects are supported via Tag policy*** Choose Future grants option if the selected grants needs to be auto assigned to the principal for any new objects created under this database or schema > ***Future grant option is available only for Snowflake data source*** Select Next button after selecting objects. Select Principal value from the drop down > **Principal value is** > > ***Role for Snowflake*** > > ***Account User or Account Group for Databricks*** Select Save button, to generate the grants for the selected objects and principal Once the selected values are validated, grants will be generated > If the values provided are not valid, the policy creation process will result in an error due to validation failures. Validation can fail for the following reasons: > > 1. Duplicate Policy Creation: A policy already exists for the selected object and principal combination. > 2. Catalog Access: The policy creation will fail if the catalog data is not accessible by control plane role. On successful validation, policy is created and ready for deployment Click on deploy button, on successful deployment the policy status will be moved to Deployed. > ***Policy deployment will be successful only all grants to be properly assigned to the TrustLogix user and no duplicate policy exists. Otherwise, the policy will fail, and any missing grants or configurations must be reported.*** **Benefits of Tag based policies are** **Automated Policy Enforcement** – Ensures security rules are applied dynamically based on object tags.\ **Scalability** – Easily manage access for large-scale data environments without manual intervention.\ **Consistency** – Enforces standardized access policies across all tagged objects, minimizing misconfigurations.\ **Simplified Governance** – Enhances visibility into access controls and reduces administrative effort. # Database and Schema level Policies TrustLogix Database and Schema, Table Access Policies provide a structured and efficient approach to controlling access to data objects within an organization’s data ecosystem. These policies enable administrators to define access grants at different levels like schemas, tables, and views—ensuring granular security enforcement across multiple data sources. ### **Types of Object-Level Access Policies** #### **1. Database - Multi Schema Policies** This policy type allows administrators to **apply access controls across multiple schemas within a database**. Instead of manually defining policies per schema, this approach enables centralized access management, ensuring uniform security configurations. **Use Case:** Grant "analyst" roles read access to a specific schemas in a financial database without setting individual policies for each schema. #### **Creation of Database - Multi Schema Policies** Login as Super User or Policy Administrator Click on Data Sources from main menu. User will see all the allowed data sources in the data sources list view Select the data source for which user wants to create access policies(User can create access policies on data source for which he/she has access to) If Access Policies is not the default tab, Click on Access Policies tab. Click on Create Access Policy button on access policy list view Select Object Access card from the create policy model Enter Policy Name and Policy Description Select Database - Multi Schema as Policy type from the drop down Select the Database name from the Database drop down Select the Schema names from the Schema drop down Select the objects privileges from the drop down > ***Object privileges (Select,Insert, Update, Delete, Truncate) is supported, and only Table and View objects are supported via this policy*** Choose Future grants option if the selected grants needs to be auto assigned to the principal for any new objects created under this database or schema > ***Future grant option is available only for Snowflake data source*** Select Next button after selecting objects. Select Principal value from the drop down > **Principal value is** > > ***Role for Snowflake*** > > ***Account User or Account Group for Databricks*** Select Save button, to generate the grants for the selected objects and principal Once the selected values are validated, grants will be generated > If the values provided are not valid, the policy creation process will result in an error due to validation failures. Validation can fail for the following reasons: > > 1. Duplicate Policy Creation: A policy already exists for the selected object and principal combination. > 2. Catalog Access: The policy creation will fail if the catalog data is not accessible by control plane role. On successful validation, policy is created and ready for deployment Click on deploy button, on successful deployment the policy status will be moved to Deployed. #### **2. Schema - Multi Object Policies** Schema-level policies offer the most granular control by allowing administrators to apply access controls to **specific tables and views within a schema**. This ensures that only authorized users can interact with designated objects, maintaining fine-tuned security. **Use Case:** Allow data engineers to modify specific tables within a schema while restricting access to sensitive views. #### **Creation of Schema - Multi Objects Policies** Login as Super User or Policy Administrator Click on Data Sources from main menu. User will see all the allowed data sources in the data sources list view Select the data source for which user wants to create access policies(User can create access policies on data source for which he/she has access to) If Access Policies is not the default tab, Click on Access Policies tab. Click on Create Access Policy button on access policy list view Select Object Access card from the create policy model Enter Policy Name and Policy Description Select Schema - Multi Objects as Policy type from the drop down Select the Database name from the Database drop down Select the Schema names from the Schema drop down Select object names from the object names drop down Select the objects privileges from the drop down > ***Object privileges (Select,Insert, Update, Delete, Truncate) is supported, and only Table and View objects are supported via this policy*** Select Next button after selecting objects. Select Principal value from the drop down > **Principal value is** > > ***Role for Snowflake*** > > ***Account User or Account Group for Databricks*** Select Save button, to generate the grants for the selected objects and principal Once the selected values are validated, grants will be generated > If the values provided are not valid, the policy creation process will result in an error due to validation failures. Validation can fail for the following reasons: > > 1. Duplicate Policy Creation: A policy already exists for the selected object and principal combination. > 2. Catalog Access: The policy creation will fail if the catalog data is not accessible by control plane role. On successful validation, policy is created and ready for deployment Click on deploy button, on successful deployment the policy status will be moved to Deployed. **Benefits of Object-Level Access Policies** **Granular Control** – Apply policies at the most appropriate level (database, schema, table, or view). # Attribute Based Access Policies ## **Attribute-Based Access Control (ABAC) Policies in TrustLogix** ### **Overview** Attribute-Based Access Control (ABAC) in TrustLogix enables fine-grained data access control based on **entitlement attributes**. These policies are primarily used for: * **Row Access Policies** – Restricting access to rows in a table based on attribute values. * **Masking Policies** – Masking specific columns based on attribute conditions. TrustLogix allows defining ABAC policies using **two approaches**: 1. **Named Object Policies** – Applied to explicitly selected objects (tables, views, and columns). 2. **Tagged Object Policies** – Applied to objects (tables, views, columns) that have been tagged. ABAC policies can be configured through a **no-code condition builder** or using the **SQL Policy Builder** for complex conditions. *** ### **Types of ABAC Policies** #### **1. Row Access Policy** Row Access Policies restrict user access to specific rows within a table based on entitlement attributes. **Subcategories of Row Access Policies:** * **Named Object Row Access Policy**: Applied to specific objects (tables and columns) by their names. * **Tagged Object Row Access Policy**: Applied to objects that have been tagged. #### **2. Masking Policy** Masking Policies control the visibility of data in columns based on entitlement attributes. **Subcategories of Masking Policies:** * **Named Object Masking Policy**: Applied to specific columns using their names. * **Tagged Object Masking Policy**: Applied to tagged columns. *** ### **Policy Components** #### **Entitlement Attributes** ABAC policies use **entitlement attributes** to control access. These attributes define user permissions dynamically and can be matched with: * **Columns in a table** * **Tagged columns** * **Constant values** #### **Object Selection** Policies can be applied to: * **Specific objects (Named Object Policy)** * **Tagged objects (Tagged Object Policy)** #### **Policy Condition Builder** TrustLogix provides a **Condition Builder Interface** to define policy conditions **without SQL**. **Features of the Condition Builder:** * Define rules using **Attributes, Operators, and Values** * Supports **AND/OR** logical operations * Matches conditions using: * **Column Tagged As** (for tagged objects) * **Constant Value** (for fixed values) * Does not support **complex joins or UDFs** #### **SQL Builder Behavior in TrustLogix ABAC Policies** The **SQL Policy Builder** in TrustLogix provides an **advanced** way to define Attribute-Based Access Control (ABAC) policies using SQL expressions. It is primarily used when the **Condition Builder Interface** is insufficient for complex conditions, such as: * **Joins across multiple tables** * **User-Defined Functions (UDFs)** * **Nested conditions with intricate logic** * **Hierarchical access control evaluations** # Row Access Policies Row Access Policies in TrustLogix enable organizations to enforce fine-grained access control by restricting data access at the row level based on user attributes, roles, or predefined conditions. This document details how to create a row access policy and includes all available options in dropdown menus. The **Condition Builder** simplifies policy creation for non-technical users, while the **SQL Builder** offers advanced customization for precise control over data masking rules. ### Steps to Create a Row Access Policy #### Navigate to the Row Access Policy Configuration * Log in to **TrustLogix**. * Click on **Data Sources**. * Select the relevant **Data Source** (e.g., Healthcare Services). * Click on **Access Policies**. * Click **Create Policy**. #### Define Row Access Policy Details * Enter the **Policy Name** (e.g., `Grant_Patient_info_By_Assigned_State`). * Provide a **Policy Description** (e.g., `Grant all patient data to user based on assigned state`). * Click **Next**. #### Select Data Scope * Choose **Named As** or **Classified As**. * Click **Tags** and enter classification keywords (e.g., `SENSITIVE`, `CONFIDENTIAL`). * Select the **Schema/Table** to apply the policy (e.g : `HEALTH_CARE.PATIENT_SCHEMA.PATIENT)` * Click **Close** after selecting the objects. #### Define Access Conditions * Click **Use SQL Editor** or **Use Condition Builder**. * Click **Add Condition**. * The Attribute drop down will list all available principal type options along with entitlement attributes. * Choose one of the option based on the condition wanted to be built. * Select the appropriate operator (`Equals`, `Not Equals`, `Contains`, `Starts With`). * Based on the attribute chosen Match with drop down will show up with available option * Choose the option from the Match with drop down. Value option will be provided with additional options based on selected Match with option * Select or enter the value * Click **Add Condition** or **Add Nested Condition** to add multiple criteria. * Click on Save * Modal window popup to show policy generation progress. If there are no errors policy is created and ready to be deployed * If required, **review and update** conditions before deployment. * If there are any validation error due to duplicate policy or column conditions mismatch correct them get the policy created and ready to be deployed * Click on Deploy button to deploy the policy from the modal. * Click **Use Condition Builder** or **Use SQL Editor**. #### Save and Deploy the Policy * Click **Save** to store the policy. * Click **Deploy** to enforce the policy across the selected data sources. **Condition Builder Options:** * **User-friendly interface** for defining access conditions without requiring SQL knowledge. * **Attribute Selection:** * `Role Name` * `User Group` * `Department` * `Geographical Region` * `Country` > Attributes drop down will list all the attributes created under attribute management screen for this data source * **Operators:** * `Equals` * `Not Equals` * `Contains` * `Starts With` * `Ends With` * `In List` * `Not In List` * **Logical Operators:** * `AND` * `OR` * `Nested Conditions` * **Value Assignment:** * Static values (e.g., `USA`, `EU`, `APAC`). * Dynamic values based on user attributes. **Advantages**: * **User-friendly interface** for defining access conditions without having SQL Knowledge. * Allows **nested conditions** for complex policies. * Provides **drag-and-drop options** to select attributes, operators, and values. * Best suited for **non-technical users** who prefer a guided configuration. * Supports logical operators like **AND**, **OR**, and grouping conditions. **SQL Editor Options:** * **Advanced tool** for writing custom conditions in SQL syntax. * **Allows for:** * Fine-grained control over policy conditions. * Using `JOINs`, `subqueries`, and `complex expressions`. * Applying row-level security based on dynamic queries. * **Example Query:** ```sql SELECT * FROM HEALTH_CARE.PATIENT_SCHEMA WHERE STATE IN (SELECT STATE FROM USER_ATTRIBUTES WHERE USER_ID = CURRENT_USER()); ``` **Advantages :** * **Advanced tool** for writing custom conditions in SQL syntax. * Allows **fine-grained control** over policy conditions. * Supports **JOINs, subqueries, and complex expressions**. * Best suited for **technical users** familiar with SQL. * Provides **query validation** to ensure correctness before applying conditions. # Masking Policies Data masking in TrustLogix allows organizations to protect sensitive information by obscuring data based on defined access policies. This document outlines the steps for creating data masking access policies, including defining conditions, applying masking techniques, and selecting available options. The **Condition Builder** simplifies policy creation for non-technical users, while the **SQL Builder** offers advanced customization for precise control over data masking rules. ### Steps to Create Data Masking Policies #### Navigate to Data Masking Policy Configuration * Log in to **TrustLogix.** * Click on **Data Sources**. * Select the relevant **Data Source** (e.g., Health Care Services). * Click on **Access Policies**. * Click **Create Policy**. #### Define Data Masking Policy * Select **Data Masking** as the policy type. * Enter the policy name (e.g., `Mask_Sensitive_Data`). * Click **Next**. #### Configure Policy Conditions * Select **Named As** or **Classified As** options to define data classification. * Click on **Tags** and enter classification keywords (e.g., `SEN` for sensitive data). * Drop down will list all the tags available in data souce which are tagged at column level. * Click **Close** after selecting the relevant tag. #### Apply Masking Techniques * Select the **Masking Type** from the dropdown options: * `Hashing (SHA2)` * `Partial Masking` * `Null Replacement` * `Regular Expression` * `Plain Text` * Click **Next**. > Masking patterns vary based on the data source type. Not all masking patterns supported across data source type. #### Define Conditions to Unmask the data for users * Click **Use SQL Editor** or **Use Condition Builder**. * Click **Add Condition**. * The Attribute drop down will list all available principal type options along with entitlement attributes. * Choose one of the option based on the condition wanted to be built. * Select the appropriate operator (`Equals`, `Not Equals`, `Contains`, `Starts With`). * Based on the attribute chosen Match with drop down will show up with available option * Choose the option from the Match with drop down. Value option will be provided with additional options based on selected Match with option * Select or enter the value * Click **Add Condition** or **Add Nested Condition** to add multiple criteria. * Click on Save * Modal window popup to show policy generation progress. If there are no errors policy is created and ready to be deployed * If required, **review and update** conditions before deployment. * If there are any validation error due to duplicate policy or column conditions mismatch correct them get the policy created and ready to be deployed * Click on Deploy button to deploy the policy from the modal. #### Understanding Condition Builder and SQL Builder * **User-friendly interface** for defining access conditions without requiring SQL knowledge. * **Attribute Selection:** * `Role Name` * `User Group` * `Department` * `Geographical Region` * `Country` * **Operators:** * `Equals` * `Not Equals` * `Contains` * `Starts With` * `Ends With` * `In List` * `Not In List` * **Logical Operators:** * `AND` * `OR` * `Nested Conditions` * **Value Assignment:** * Static values (e.g., `USA`, `EU`, `APAC`). * Dynamic values based on user attributes. * **Advantages**: * **User-friendly interface** for defining access conditions without having SQL Knowledge. * Allows **nested conditions** for complex policies. * Provides **drag-and-drop options** to select attributes, operators, and values. * Best suited for **non-technical users** who prefer a guided configuration. * Supports logical operators like **AND**, **OR**, and grouping conditions. **SQL Editor Options:** * **Advanced tool** for writing custom conditions in SQL syntax. * **Allows for:** * Fine-grained control over policy conditions. * Using `JOINs`, `subqueries`, and `complex expressions`. * Applying row-level security based on dynamic queries. * **Example Query:** ```sql SELECT * FROM HEALTH_CARE.PATIENT_SCHEMA WHERE STATE IN (SELECT STATE FROM USER_ATTRIBUTES WHERE USER_ID = CURRENT_USER());Condition Builder ``` **Advantages :** * **Advanced tool** for writing custom conditions in SQL syntax. * Allows **fine-grained control** over policy conditions. * Supports **JOINs, subqueries, and complex expressions**. * Best suited for **technical users** familiar with SQL. * Provides **query validation** to ensure correctness before applying conditions. # Using the Dimension Table to build ABAC policy conditions In TrustLogix, dimension tables can be used to create precise and attribute-driven data access policies. These tables are typically used to represent business hierarchies, classifications, or any categorical data (e.g., territories, product types, regions) that are referred to while defining access conditions. #### Prerequisites: Enabling Dimension Table Selection Before you can use a dimension table in the Condition Builder, you must ensure that the dimension is correctly linked to a [**user attribute source configuration** via **Attribute Management.**](/attribute-management/attributes-based-on-source) #### When to Use a Dimension Table Use dimension tables when: * You want to enforce attribute-based row-level policies. * You want to map user attributes to business values like region, business unit, or product line. * You need to evaluate policies using values that roll up into hierarchies. #### Steps to Use a Dimension Table in the Condition Builder **1. Create or Edit a Policy** * Navigate to the **Access Policies** section of your account. * Click **Create Policy** or choose an existing one to edit. * Create a row access policy or a column-based masking policy. **2. Add Data Conditions** * Click the +Data Condition Link. **3. Select the Data Attribute** * Choose the appropriate data attribute (column) from the dropdown list. **4. Define the Operator** * Select the operator, such as `Equals`, `In`, etc. * Operators determine how the selected dimension value will be matched. **5. Set the Comparison Value** * Choose: * **Constant Value from Attribute**: Map to a user-defined attribute (e.g., `gl account name`) which links back to the user's metadata or entitlements. * The mapped dimension table will be used in the policy condition. **6. Choose the values from the dimension table.** * Choose the values from the model window. * If the attribute supports multiple values, you can select multiple values. * Enable multi-selection using the checkbox interface and add desired values. **7. Select additional filters on the dimension table.** * Once the dimension column values are selected, click on the +Filter Conditions link. * Select the required available column name as an additional filter on the dimension table. * Select Constant value and choose an available value. * Proceed with additional filters or conditions as needed. **7. Save and Apply** * Click **Add** or **Save** to apply the condition. * Build and deploy the policy. *** #### Example Use Cases * **Region-based Access**: Allow only users from specific regions to access transactions. * **Business Unit Segmentation**: Restrict access to financial data by `ROLLUP_TYPE` or `GL Account`. * **Tiered Data Access**: Use hierarchy tags like `"BRONZE"` or `"PURCHASE"` to define access scopes. Sample Policy Generate for Snowflake Datasource ``` CREATE OR REPLACE ROW ACCESS POLICY tlx_policy_db.tlx_row_policy.TLX_ABAC_8a48813098092d4b01980c64c0fe06b0 AS (TLX_COUNTRY VARCHAR) RETURNS BOOLEAN -> CASE WHEN ( IS_ROLE_IN_SESSION('DATA_ANALYST') AND TLX_COUNTRY IN ( SELECT DISTINCT COMPANY_CODE FROM ACME_DB.MASTER_DATA.COMPANY_CODE_DIM_HIERARCHY WHERE LEVEL_0 = 'Europe' AND LEVEL_1 = 'France' AND LEVEL_2 = 'Division B' AND ROLLUPTYPE = 'AVG' AND BUSINESS_UNIT = 'BU001' ) ) THEN TRUE ELSE FALSE END ``` # Domain Policies Domain Policies in TrustLogix allow domain owners to create access policies for data domain products spanning multiple data sources. This capability is crucial in environments such as **medallion architecture**, where data moves between layers like **Silver, Gold, and Platinum** across heterogeneous data sources like **SQL Server, Databricks, and Snowflake**. TrustLogix enables users to define a single policy and deploy it across multiple layers while managing access based on assigned principals. ### Steps to Create a Domain Policy #### Navigate to the Domain Policy Configuration * Log in to **TrustLogix**. * Click on the **Main Menu**. * Select **Domain Policies**. * Click **Create Policy**. #### Define Domain Policy Details * Enter the **Policy Name** (e.g., `Grant_Read_Access_On_Sales_Lead`). * Provide a **Policy Description** (e.g., `Grant access on sales lead to data engineer`). * Click **Next**. #### Select Domain and Data Products * Click on the **Domain** dropdown to view all configured domains across all data sources. * Select a **Domain** from the list. * Click on the **Data Product** dropdown to view all data products under the selected domain. * Choose one or more **Data Products**. * Click **Next**. Assign Privileges * Choose the required **Privileges** from the dropdown options: * `READ` * `WRITE` * `DELETE` * Click the **Checkbox** to confirm the selected privileges. * Click **Next**. #### Assign Principals * Click on the **Principal** dropdown to select an entity for access control. * The **Principals will be considered based on the data source type**: * **Role** : Assigns access based on predefined roles. * **User**: Grants access to specific users. * **Group**: Assigns access at a user group level. * Choose the appropriate **Principal Name**. * Click **Save** to validate and generate the policy. #### Deploy the Policy * Click **Deploy** to enforce the policy across applicable data sources. * The policy will be applied to all relevant data layers, ensuring access control consistency. By leveraging Domain, Data Product, Privileges, and Principals, organizations can efficiently manage data security at scale while maintaining compliance and governance best practices. # TrustLogix Policy Synchronization ### Overview Clients currently create and deploy policies on the TrustLogix platform to their respective data sources. However, there is a challenge in keeping the policies intact on objects when recreation of the objects happens as part of the development life cycle (either manually or via CI/CD pipelines). To address this, there is a clear need for automation to keep the policy attachments. The automatic redeployment of the process is required to keep the policy reattached to the recreated objects so that sensitive objects are protected, thereby ensuring their security. TrustLogix has introduced the automation service, called **Policy Sync Service**, to resolve this issue. This document provides end-to-end information on its internal workings. The TrustLogix-managed Policy Sync Service can be activated upon request.
\ Sync Policy types Supported * Object-based RBAC * Object-based ABAC (RLS & Masking) * Tag-based ABAC (RLS & Masking) ### 1. Objectives 1. Ensure governance policies remain enforced after object recreation. 2. Automatically detect drift between defined policies and actual enforcement. 3. Provide both on-demand and time-window (scheduled) remediation. 4. Maintain auditability and deterministic policy deployment. ### 2. Key Concepts * Object Recreation Drift\ When a table/view is recreated, previously attached RBAC/RLS/Masking policies are removed. * Policy Deployment Mode\ Intermediate state where policies are identified as applicable but not yet enforced. * Tag Reference Store (Tag Ref)\ Metadata repository containing object ↔ tag mappings used for tag-based sync. * Last Sync Timestamp\ Watermark used to identify delta objects. ### 3. Assumptions — Tag-Based Policies ### Tag Latency Exists (Up to 2 Hours - Only for Snowflake) In Snowflake: * Tag assignment is immediate. * But tag visibility in metadata views may be delayed. * Tag references in ACCOUNT\_USAGE may have latency. * Tag propagation across replication may be delayed. ### Sync Service Behavioral Assumptions #### If Tag Not Found: System assumes one of: 1. Tag not yet applied 2. Tag applied but not propagated 3. User forgot to apply tag Because of latency, system must: * Move policy to Pending Retry state * Retry up to configured attempts ### 4. Lifecycle — Object-Based Policies ### 4.1 Creation & Initial Enforcement 1. An object (table/view) is created. 2. RBAC policy is defined and applied to objects. 3. ABAC RLS policy is created and attached. 4. Masking policy is applied to sensitive columns. 5. The object enters the Governed State. ### 4.2 Drift Scenario — Object Recreated 1. User drops/recreates objects. 2. Policies are no longer attached. 3. Object enters Ungoverned Drift State. ### 4.3 On-Demand Policy Sync Flow Trigger: User knows event time and runs sync. #### Flow 1. User triggers On-Demand Policy Sync Service. 2. Service reads configured last timestamp. \[First time it will scan last 3 hours logs] 3. Identify objects recreated after timestamp. 4. For each object: 5. Lookup historical policy metadata. 6. Detects RBAC policy mapping. 7. Detects ABAC RLS policy mapping. 8. Detects masking configuration. 9. Mark policies as Deploy Mode in Trustlogix. 10. The Trustlet engine applies policies. 11. Object returns to Governed State. ### 4.3.1 On-Demand Policy Sync On Few Policies ### Flow #### Select only specific suggested policies Allow users to manually choose which policies from the suggestion list should be processed. **Scenario** Drift engine identifies: * 20 policies out of sync * Admin wants to fix only 3 immediately Instead of full sync, admin selects: Policy A Policy C Policy F **System Behavior** * Accept selected policies * Validate policy state (Active / Drifted) * Process only selected policies * Ignore others **Why This Matters** ✔ Reduces execution scope\ ✔ Avoids impacting unrelated policies\ ✔ Enables staged rollout\ ✔ Supports emergency fixes #### Sync Only Those Selected Policies Ensure the system enforces policies strictly within the selected scope. **Scenario** User selects 2 policies: * Policy 1 → mapped to 10 tables * Policy 2 → mapped to 5 views System must: * Evaluate only these 15 objects * Not scan or evaluate other policies **Internal Flow** 1. Fetch selected policies 2. Identify mapped objects 3. Perform drift detection per object 4. Generate delta enforcement plan 5. Deploy only required changes **Result** * Controlled execution boundary * No cross-policy interference * No global scan Note: Un selected policies will be skipped and no action will be taken for those policies. #### Avoid Re-Syncing Already Enforced Policies Prevent re-execution of policies already correctly enforced. **Scenario** Policy appears in drift list due to: * Cached metadata delay * Object recreated but auto-tagged * Manual DBA enforcement already done * Actual Snowflake state is compliant. **Required System Behavior** Before enforcement: 1. Validate current datasource state: 2. Check POLICY\_REFERENCES 3. Check grants 4. Check masking attachments 5. Compare expected vs actual state 6. If identical → Skip deployment ### 4.4 Scheduled Policy Sync Flow (Object-Based) Trigger: Background job (e.g., hourly). #### Flow 1. Scheduler runs sync jobs & scans the logs. 2. Scan metadata for objects recreated in the last 1 hour. \[First time it will scan the last 3 hours of log data.] 3. For each object: 4. Check if object-level policies exist in TrustLogix. 5. Move policies to Deploy Mode. 6. Execute deployment. 7. Log audit record. ### 5. Lifecycle — Tag-Based Policies ### 5.1 Creation & Tagging 1. An object is created. 2. The object is tagged (domain/classification). 3. Columns are tagged (PII, Sensitive, etc.). 4. Tag metadata populated into Tag Ref. 5. ABAC tag-based RLS policy created. 6. ABAC tag-based masking policy created. 7. The object enters the Governed State. ### 5.2 Drift Scenario — Object Recreated 1. The object is recreated. 2. Tags and policies are no longer attached. 3. Object enters Tag Drift State. ### 5.3 On-Demand Tag-Based Sync Flow Pre-requisite: Tag Ref must contain updated mappings. #### Flow 1. The user triggers on-demand sync. 2. Sync service reads the last timestamp. 3. Identify objects tagged/untagged after timestamp. 4. Object tags 5. Column tags 6. Identify applicable ABAC policies. 7. Move policies to Deploy Mode. 8. Deploy policies and reapply grants. 9. Object returns to Governed State. ### 5.4 Scheduled Tag-Based Sync Flow Trigger: Periodic job (e.g., hourly). #### Flow 1. Scheduler runs sync jobs & scans the logs. 2. Sync service reads the last timestamp. 3. Identify objects tagged/untagged after timestamp. 4. Object tags 5. Column tags 6. Identify applicable ABAC policies. 7. Move policies to Deploy Mode. 8. Deploy policies and reapply grants. 9. Object returns to Governed State. ### 5.4.1 Object tags not populated for scheduled sync service ### Flow Handle scenarios where: * A user recreates an object (table/view) * Required governance tags are not yet populated * Tag-based policies cannot be enforced immediately * Scheduled Sync must retry intelligently before skipping This ensures: * No premature policy failures * Controlled retry mechanism * Reduced false drift alerts * Stable enforcement behavior ### 6. Policy States | State | Description | | ------------ | -------------------------------- | | Draft | Policy defined but not evaluated | | Active | Policy attached and enforced | | Drifted | Object exists but policy missing | | Publish Mode | Policy queued for enforcement | | Deployed | Deployment successful | | Failed | Deployment error | ### 7. Metadata & Inputs ### Required Metadata * Object creation timestamp * Object recreation event * Policy catalog (RBAC / RLS / Masking) * Tag Ref mappings * Last sync watermark ### 8. Audit & Observability Each sync run should log: * Sync type (On-Demand / Scheduled) * Time window processed * Objects evaluated * Policies redeployed * Failures ### 9. CI/CD Policy Sync API ### API Endpoint **POST** ``` /api/account/{accountId}/access_policies/sync ``` Description: sync policies based on object names provided. **Request:** ``` Method: POST Headers: Content-Type: application/json Accept: application/json Authorization: Param: ignoreSyncDatabases : true/false Default : false ``` **NOTE:** If client wants to do policy sync only for configured DBs, please enable this flag while sending the request. Please share the DB list to the TrustLogix support team. * Body: JSON ``` [ { "objectName": "BRONZE.PURCHASE.SALES_TRANSACTIONS" } ] Responses: 200 OK: Indicates a successful operation. Body: JSON { "code": 200, "message": "Data access policies sync successfully done.", "data": [ "Policy ID: 123, Policy Name: schema_multi_obj_policy PUBLISHED." ] } ``` ### Authentication API requests require authentication. Please refer to the Trustlogix API documentation for details on how to authenticate your requests. This typically involves a JWT token. # Access Policy Migration Status Flow This document outlines the standard procedural flow, platform prerequisites, and lifecycle of access policies as they are migrated across different data environments(e.g., from Development to Product) ### **Platform Support & Prerequisites** * Supported Data Platforms: Policy migration is seamlessly supported for Snowflake and Databricks. * Account Consistency: Source and target accounts must match in platform type (e.g., Snowflake-to-Snowflake). * Environment & Tenant Flexibility: The source and target can reside within the same overarching account or span across different accounts (such as isolated Dev and Prod accounts). We also fully support cross-tenant policy migration. * Database Mapping: The database name can be the same or different between the source and the target data source accounts. * Policy State: Only deployed access policies are eligible for migration. ### Downloading the CI/CD Migration Script To execute the policy migration, you will need the appropriate CI/CD utility script. Follow these steps to download it: 1. Login to the TrustLogix console. 2. Navigate to Configuration from the left-hand menu. 3. Click on the Utility Script card. 4. Download the Migrate Access Policy script. ### Migration Workflow: Lower to Higher Environment To ensure a secure and consistent promotion of access controls, policies follow a strict path from lower to higher environments. * Development & Testing: Access policies are designed, deployed, and validated within the Development (Dev) environment. * Migration Trigger: The policy is promoted to the higher environment (Prod/UAT), preserving the exact conditions and constraints established in Dev. * Immutability Guarantee: During migration, no changes are made to the original policy in the Dev environment. ### Flow Diagram The following diagram illustrates the automated step-by-step logic applied during a policy migration. ![](/files/joyWp2xZW2xkMSttfwcC) ### Status Flow (Migration Engine Process) ![](/files/9vF50nlL5QZM0Iq867d5) ### Detailed Migration Execution Phases | Status Phase | Platform Action |

Customer View / Details

| | --------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Verification | Policy Discovery | The migration platform scans the target environment to determine if a version of the migrating policy already exists. | | 2. Resolution | Create or Update | If missing, a new policy is created. If present, the existing policy is updated with the new conditions and object selections from Dev. | | 3. Validation | Condition Validation | The platform internally validates the updated policy conditions against the target account structure. The policy state transitions to Published. | | 4. Execution | Automated Deployment | Our automated deployment engine (Trustlet) picks up the Published policy and natively executes the required statements in Snowflake or Databricks. | | 5. Completion | Finalize Status | Upon successful execution, the policy's final status in the target environment is updated to Deployed, completing the migration. | ### Troubleshooting & Failure Handling Handling Migration Failures: In the event of a deployment failure (e.g., due to missing permissions in the target environment), first apply the required permissions. Once resolved, downgrade the target policy version in the JSON configuration file and rerun the migration script. # Application Access Governance(Preview) The TrustLogix Application Module serves as a centralized control plane for registering, configuring, and governing access to specific business applications. It enables administrators to transition from broad, infrastructure-level permissions to granular, application-specific access control. By utilizing this module, organizations can enforce security at the resource level, ensuring that sensitive data and functional modules are only accessible to authorized users under defined conditions. #### Key Capabilities * Application Registration: Formally register new applications within the TrustLogix ecosystem using unique identifiers and service principal credentials for secure API communication. * Dynamic Attribute Management: Integrate external identity sources, such as EntraID, to map user and resource attributes that drive complex policy logic. * Granular Access Policies: Define "Allow" or "Deny" rules for specific actions like View, Read, or Write based on real-time attribute evaluation. * Enriched Response Context: Configure policies to return additional metadata—such as user location or internal department IDs—directly in the policy response to assist consumption-side logic. Seamless Deployment: Generate and deploy policies directly into the Auth Service to provide instantaneous policy enforcement across the application landscape. # Register An Application Register and configure a new application within TrustLogix for access policy enforcement , follow the steps outlined below. This configuration provides the necessary credentials (Client ID, Client Secret, etc.) required for the consumption side to evaluate defined access policies via API. ### Create a New Application First, navigate to the Applications management section of the TrustLogix platform to initialize the registration. * Navigate to: . * Click the "Create Application" button. * Enter the Application Name: Click the "Application Name" field and type your desired name (e.g., "Finance Analysis"). * Enter a Description: Click the "Description" field and provide details for the application (e.g., "Finance Analysis"). * Save: Click "Save" to create the entry. *** ### Configure Service Principal Details Once the application is created, you must configure its Service Principal details. These values are essential for the consumption side to authenticate before calling the policy evaluation API. ***Prerequisites*** ***Configure the IdP Application Details*** > *Create a separate application to integrate the graph endpoint as source in TrustLogix. Please follow* [*prerequisites*](https://docs.trustlogix.io/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint#id-3.-follow-the-prerequisite-steps) *step to get the required details to complete the integration.* > *Get Application(Client) ID and Directory(Tenant) ID from Azure Application Overview page.* > > *Copy Secret value while creating in prerequisites step.* * Select the Application: From the application list, click on the newly created application name (e.g., "Finance Analysis"). * Access Configuration: Click on the "Configuration" tab located in the top menu. * Fill Service Principal Details: * Client ID: Enter the unique identifier for the application. * Client Secret Value: Enter the secret key associated with the application. * Application Scope: Define the scope required for the application's access. * Token Endpoint: Enter the URL endpoint used to retrieve authentication tokens. *** ### Finalize Registration * Save Configuration: Click "Save" at the bottom of the Configuration page to store the service principal details. * Confirmation: Ensure the "Application created successfully" notification appears. Note: Only applications with an "Active" status can be targeted by new Access Policies. Ensure the toggle for "Application Status" is enabled during configuration. \ \
# Resources ## Discoverable Resources TrustLogix Application can only define access on application resources by mapping the actual resources mapped into TrustLogix. TrustLogix doesn't currently support discovery/import for a desired resource, they can be manually configured in the console. {% hint style="warning" %} Currently, TrustLogix only supports automatic discovery of database objects in registered data accounts and data products across all data domains. \ \ Additionally, we offer 4 resource types out of the box (File, Folder, API, Data Product) that can be used to manually configure resources. {% endhint %} ## Custom Resource Creation * Custom resource types can be defined in the **Resources Type** tab. Resource types consist of name, description, attributes, and actions. * Once the resource type is created, it can be selected during the manual resource creation in the **Resource** tab. * Along with any custom resources created here, resources that TrustLogix discovers will be automatically selectable during policy creation in the **Access Policies** tab. # Attributes To define effective access policies in TrustLogix, you must first establish the necessary Attributes and Resources. The following documentation outlines the process for managing and adding attributes, specifically focusing on those sourced from Entra ID. *** ### Prerequisites * Attribute Source Integration: Before adding attributes, you must have an established source configuration (e.g., Azure AD) created via the Attribute Source Integration screen. This step ensures that TrustLogix can communicate with your external identity provider to fetch attribute data. *** ### Access Attribute Management Navigate to the Attribute Management section within your specific application to begin the configuration. * Path: Applications > \[Your Application Name] > Resource Policies > Attribute Management. * Click the "Add Attribute" button to open the configuration dialog. *** ### Configure Attribute Source In the Source Configuration section, specify where the attribute data will originate. * Source Type: Click the drop-down menu and select your integrated source, such as "Azure AD attribute source". *** ### Map Attributes Once the source is selected, use the Attribute Mapping section to link external data fields to TrustLogix attributes. * Source Column: Select the specific field from your source (e.g., "ageGroup" or "city"). * Display Name: Enter the name as it should appear within TrustLogix policies (e.g., "city"). * Type: Select the data format, such as "STRING". * Additional Options: * Use this as user identifier: Check this if the attribute uniquely identifies the user. * Multiple Values: Check this if the attribute can contain more than one value. *** ### Save and Verify * Click "Save" to add the attribute to your management list. Review: Verify the attribute appears in the table with its corresponding Display Name, Description, Type, and Source (e.g., Azure AD). # Access Policies Steps to create a new Resource Access Policy in TrustLogix. This specific policy targets the "Finance" module and returns detailed response context (User city, Department, and Sub-module information) when the action View is performed, provided the resource's department is set to Finance. *** ### Initiate Policy Creation Navigate to the Access Policies management section within your application to begin the registration. * Navigate to: Application Module * Click the "Create policy" button. ### Define Policy Details Provide the basic identification details for your new policy. * Name: Enter a unique name (e.g., "FinanceModule"). * Description: Provide a summary of the policy's purpose. * Click "Next" to proceed to resource selection. ### Resource Selection and Actions Specify which resources this policy protects and what operations are governed. * Resource Source: Select RESOURCE from the dropdown. * Resources: Select the specific resource (e.g., Finance). * Actions allowed: Select View from the available operations. * Click "Next" to define conditions. ### Set Policy Conditions Configure the logic that determines when this policy is applied. * Select Attribute Type: Choose Resource Attributes. * Select Attribute: Select Department. * Operator: Choose Equals. * Value: Enter Finance. ***Note: Policies condition can contain user attribute (created under Attribute Management section) or Request Attributes (which can be send in authorization request payload)*** ### Configure Response Context Define the additional information that will be returned in the policy evaluation response. * User Attributes: Select city to include the user's city of residence in the response. * Resource Attributes: Select Department to echo the resource's department. * Custom Attributes: Add a new custom field: * Name: Enter Sub Module. * Value: Enter Plan, Budget. ### Deploy the policy Complete the policy creation and push it to the authentication service. * Save: Click the "Save" button to store the configuration. Deploy: Click "Deploy" in the "Generating Policy" dialog to move the policy into the Auth Service. # Tag Management TrustLogix Tag Management feature help users to classify and organize data sources effectively. Users can create, edit, and manage tags to control access and apply policies efficiently. 1. Add new tags 2. Edit existing tags 3. Manage tag associations 4. Delete tags > TrustLogix user with Super User, Data Administrator and Policy Administrator role can only access the Tag Management tab and manage the tags. > Databricks doesn't have Tag Management tab. Both tag management and tag association will be managed through Tag association tab itself. > > Deletion of tags are not supported in Databricks. ### Adding a New Tag #### Steps: * Navigate to the **TrustLogix Application**. * Click on **Data Sources** from the main menu. * Select the **Data Source** where tags need to be managed. * Click on **Tag Management**. * Click on **Add Tag**. #### Configuring the New Tag: * The **Add Tag** modal will appear. * By default, tags are mapped to **TLX\_POLICY\_DB** and **TLX\_SCHEMA**. * Enter the **Tag Name** (e.g., `Sales_Info`). * Click on **Tag Value** and enter a value (e.g., `SENSITIVE`). * Click **Save**. > Edit database and schema option needs to be selected to get the tag information from other databases than default which is **TLX\_POLICY\_DB** and schema **TLX\_SCHEMA** #### Notes: * Users need proper permissions to create tags under the selected database/schema. * Newly created tags may take up to **2 hours** to reflect in Snowflake but can be used immediately. ### Editing Existing Tags #### Steps: * Navigate to **Tag Management**. * Click on the **row-level menu** next to the tag and select **Edit**. * Modify tag values by adding or removing entries. * Click **Update** to save changes. #### Notes: * Users require the necessary permissions to edit tags. * Updated tags apply instantly if permissions are granted. ### Deleting Tags #### Steps: * Navigate to **Tag Management**. * Click on the **row-level menu** next to the tag and select **Delete**. #### Notes: * Tags with existing **access policies** cannot be deleted. * If no policies are associated, the tag will be removed, and all objects will be dissociated. ### Tag Association Tag association management in TrustLogix allows users to link data assets with specific tags to enforce access controls, classify data, and enhance governance. This document provides a detailed guide on how to associate, modify, and manage tag associations effectively. ### Associating Objects with Tags #### Steps: * Log in to **TrustLogix Application**. * Click on **Data Sources** from the main menu. * Select the **Data Source** where the tags are defined. * Click on **Tag Management**. * Navigate to the **Tag Association** tab. * In the **Tag Association** tab, select the objects that need to be associated with a tag. * Click on **Add Tag Association** button. * Choose the appropriate **Tag Name** from the dropdown list. * Select the **Tag Value** that aligns with the data classification requirements. * Select the object type and choose the fields based on the object type selected. * Click **Save** to confirm the association. #### Notes: * Users must have **proper permissions** to associate tags with objects. * Tag associations enable access control based on predefined **policy rules**. * Changes apply instantly for governance and access enforcement. ### Removing Tag Associations #### Steps: * Navigate to **Tag Association**. * Identify the object whose tag association needs to be removed. * Click on **Delete** * Confirm the removal in the prompt. #### Notes: * If an access policy is dependent on the tag, a **warning message** will appear. * Users must ensure that removing a tag does not violate existing security policies. > Modifying of tag association is not available. To modify any tag association, delete the association and create a new association. > > For Snowflake database this removal and creation of association will take 2 hours to reflect in UI due the latency of metadata refresh from Snowflake side. ### Best Practices for Tag Association * Always align tag associations with **data governance policies**. * Use **consistent naming conventions** for tags and values. * Regularly audit tag associations to ensure compliance with **security frameworks**. * Ensure that only authorized users manage tag associations to maintain **data integrity**. # Attribute Management # Attribute Management ### Overview This document outlines the step-by-step process to add and manage user attributes in **TrustLogix**, including attribute creation, configuration, and provisioning. *** ### Steps to Add a New User Attribute #### 1. Navigate to the Attribute Management from Main Menu > User with Super user, Data Source Administrator,User Attribute administrator and Value management roles can access this page. #### 2. Start Creating an Attribute * Click on the section to manage **User Attributes**. * Click **Add Attribute**. #### 3. Select Target Data Source and Product * Choose the appropriate **Data Source** (e.g., `Select exisiting data source`) from the drop down * Select the **Data Product** (e.g., `ClinicalTrial`) from the drop down. Choosing this option will create the attribute for a specific data product. #### 4. Enter Attribute Details * **Name & Description**: Enter attribute name and description (e.g., "Territory Value" with description "Attribute value for territory"). * **Data Type**: Select from dropdown (e.g., `String`). #### 5. Group and Value Configuration * **Select Group**: Choose the appropriate user group (e.g., `Default`, `hr`). Attribute group will group the values in UI so that all group related attribute can be managed under one section. * **Multiple Values**: Enable if users can have more than one value. #### 6. Save and Provision the Attribute * Click **Save** to store the configuration. * Click **Provision** to push the attribute configuration to the selected data source. *** ### Editing an Existing Attribute * Navigate back to the **User Attributes** tab. * Click the **edit icon** beside the attribute. * Modify name, description, type, or groups as required. * Click **Save** to confirm changes. *** ### Notes * Always ensure the selected **data source and data product** are correctly mapped before provisioning. * Provisioning is essential for the attribute to become active and usable in policies. * Use meaningful names and descriptions to make attribute purpose easily identifiable. *** ### Conclusion TrustLogix allows seamless creation and management of user attributes for entitlement and access control. Following this workflow ensures consistent, secure, and compliant attribute management across your data environment. # Attribute Value Management ### **Prerequisites** Before you begin, ensure the following: * You have appropriate access and permissions in **TrustLogix** to manage attributes and their values. * The attribute to which you intend to add values has already been created. #### **Creating Attribute Values** Follow these steps to add attribute values in TrustLogix: 1. **Navigate to Attribute Management**\ Log in to the TrustLogix platform and access the **Attribute Management** section. 2. **Go to the Attribute Value Page**\ Open the **Attribute Value** tab to manage and input values for attributes. 3. **Select Data Source and Data Product**\ Choose the relevant **Data Source** and **Data Product** from the dropdown menus. > *Note: The Add Value page displays all attributes linked to the selected data product, as well as those associated with the universal `All` data product.* 4. **Enter Identifier Value**\ Provide the value for the **Identifier Attribute** associated with the selected data product. This is a mandatory step for record association. 5. **Enter Values for Additional Attributes** * For each non-identifier attribute, input the corresponding value. * If the attribute is configured with a source, the TrustLogix UI will render relevant data dynamically: * Values may appear as **single-select** or **multi-select dropdowns**, or **hierarchical selectors**, depending on the source configuration and the nature of the dimension table. 6. **Click Save**\ Once all required values are entered, click the **Save** button. 7. **Value Synchronisation**\ Upon successful saving, the attribute values are automatically synchronized with the corresponding **Data Source**. # Attributes based on Source Attribute Management in TrustLogix allows organizations to configure user attributes for data access control. Entitlement Attribute Management in TrustLogix ensures flexible and scalable attribute creation and mapping. Whether using direct, derived, hierarchical, or recursive hierarchical types, organizations can manage access efficiently. 1. Attribute Source Configuration 2. Creating Attributes with Source Configuration: * Direct Mapping Attribute * Derived Attribute * Hierarchical Attribute * Recursive Hierarchical Attribute 3. Creating Attributes Without Source Configuration > TrustLogix supports separation of duties for attribute management feature. > > **User Attribute Administrator** is responsible for **Attribute Source Configuration, Attribute Creation** and **also Attribute Value population** > > **Value Manager i**s responsible for **Attribute Value Population** > > Ensure the right user is logged in and performing respective activity. The users can be confined to a particular data source by assigning the data source in user administration screen. ### Attribute Source Configuration #### Attribute Source Configuration is a one-time activity required to define a source for attributes. Any registered TrustLogix account can configure a source from a dimension table (or master table). #### Steps to Configure a Source: * Enter the **name** of the connection. * Select the **data source** from the dropdown list. * Click **Create Configuration**. * On the next screen, attributes can be created using this source. ### Creating an Attribute with Source Configuration #### Steps: * Select **Target Datasource** and **Data Product**. * Choose **Attribute Type**. * Enter **Display Name** and **Description**. * Select the **Multi-Value** checkbox if applicable. * Click **Import** to create the attribute. * Go to **User Attributes** tab to verify the newly created attributes. #### Direct Mapping Attribute * Used when the attribute value is **directly mapped** to a column. * Example: Department Name mapped from a Department Dimension Table. ```sql CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.DEPARTMENT ( DEPARTMENT_ID NUMBER(38,0) NOT NULL, DEPARTMENT_NAME VARCHAR(100) NOT NULL, PRIMARY KEY (DEPARTMENT_ID) ); ``` * The **Department Name** attribute will be stored as a dropdown list. * Ensure **TrustLogix users have SELECT access** to the department dimension table. #### Derived Attribute Type * Used when an attribute value is obtained by **joining a source column** with a value column in a dimension table. * Example: Assigning a **Department Name** while storing **Department ID** in a fact table. ```sql CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.DEPARTMENT ( DEPARTMENT_ID NUMBER(38,0) NOT NULL, DEPARTMENT_NAME VARCHAR(100) NOT NULL, PRIMARY KEY (DEPARTMENT_ID) ); ``` * The **Department ID** is stored in the fact table but resolved to **Department Name** via a join. #### Hierarchical Attribute Type * Used when an attribute value is derived from **hierarchical columns** in a dimension table. * Example: Assigning country access within a geographical hierarchy. ```sql CREATE OR REPLACE TABLE DPM_POC.MASTER_DATA.GEO_HIERARCHY ( GLOBAL_ZONE VARCHAR(255), CONTINENT VARCHAR(16777216), REGION VARCHAR(16777216), SUB_REGION VARCHAR(16777216), COUNTRY_NAME VARCHAR(16777216), COUNTRY_CODE VARCHAR(16777216) ); ``` * The hierarchy is displayed as a **tree structure**, allowing multiple selections. #### Recursive Hierarchical Attribute Type * Used when an attribute value is derived from a **recursive hierarchy**. * Example: Employee reporting structure. ```sql CREATE OR REPLACE TABLE DPM_POC.HR_DATA.EMPLOYEE ( EMP_ID NUMBER(38,0) NOT NULL, EMP_EMAIL VARCHAR(100) NOT NULL, MANAGER_ID NUMBER(38,0), MANAGER_EMAIL VARCHAR(100) NOT NULL, PRIMARY KEY (EMP_ID), FOREIGN KEY (MANAGER_ID) REFERENCES DPM_POC.HR_DATA.EMPLOYEE(EMP_ID) ); ``` * Select **MANAGER\_EMAIL** as **Parent Column** and **EMP\_EMAIL** as **Child Column**. * This allows an attribute value to be displayed in a **hierarchical tree**. ### Creating an Attribute Without Source Configuration * Attributes can be created **without a source configuration**. * The **value screen** will show an input text box for free-form text entry. #### Steps: * Click **Add Attribute**. * Select **Target Datasource** and **Data Product**. * Enter **Display Name**, **Description**, **Type** and **Group**. * Select **Multiple Values** checkbox if needed. * Click **Save**. * Click **Provision** to push the attribute to the target datasource. ### Associating Attributes with Data Products When creating an attribute in the TrustLogix platform, it is mandatory to **associate it with a Data Product**. Attributes associated with **"All"** are shared globally across all Data Products. Each Data Product can maintain its own **distinct set of attributes and a designated Identifier**. These attributes are critical for defining **data access policies** tailored to individual Data Products. > **Note:** An attribute can be associated with **one or multiple Data Products** based on the access control requirements. When adding attribute values, the platform uses the selected **attribute and its associated Identifier** to populate the values correctly. This ensures precise mapping and enforcement of policies across different Data Products. For more information on attribute value population, see [Attribute Value](/attribute-management/attribute-value-management) ### Configuring Identifier attribute To add attribute values in the TrustLogix App, **one of the attributes must be designated as the Identifier**. This Identifier uniquely distinguishes each entity (e.g., a user, role, or group) and serves as the primary reference point for additional attributes. Attributes such as **User Name**, **Role Name**, or **Group Name** are commonly used as Identifiers due to their unique and descriptive nature. All other attributes will be treated as supplementary characteristics associated with the Identifier. To configure an attribute as an Identifier: * Select the **"Use this as user identifier"** checkbox for the relevant attribute. * This configuration can be applied during the initial creation of the attribute or updated later by editing an existing attribute. Designating the correct Identifier is essential for accurate data representation and effective policy enforcement within the TrustLogix platform. ### Overriding Identifier attribute for a data product In TrustLogix, you can assign different **Identifier attributes** for each **Data Product** to enable precise and context-aware access control. An Identifier uniquely distinguishes a user or entity within the context of a Data Product and plays a critical role in policy definition. If no specific Identifier is configured for a Data Product, the attribute **"User Name"** (associated with the **"All"** Data Product) will be used as the default Identifier across all Data Products. #### Example Let’s consider three Data Products: **HR**, **Finance**, and **Health Care**. If you do not configure an Identifier for any specific Data Product, the attribute **"User Name"** will be used as the default Identifier across **HR**, **Finance**, and **Health Care**. However, for the **HR** Data Product, you may want to override this and use **"Employee ID"** as the Identifier since it more accurately reflects the internal HR systems. To override the default: > ✅ **Select** the checkbox **“Use this as user identifier”** for the attribute **Employee ID** when creating or editing the attribute. This approach ensures that each Data Product uses the most appropriate Identifier, enhancing the accuracy and granularity of your data access policies. > **Note:** Only one attribute can serve as the Identifier per Data Product, and it must be marked accordingly using the **"Use this as user identifier"** option during creation or by editing the attribute. ### Organizing Attributes Using Groups Attributes in TrustLogix can be assigned to a **Group** during creation or later through updates. Grouping related attributes together provides better organization, especially when managing attributes across multiple data products or use cases. Grouping attributes based on their function or context enhances usability and consistency. All attributes belonging to the same group are displayed together on the **Attribute Value** page, making it easier for users to populate values efficiently and accurately. This approach supports streamlined configuration and improved clarity when working with complex attribute sets across different business domains. # Importing User Attributes and Group Membership from Microsoft Entra ID (Azure AD) TrustLogix enables you to import user attributes and group memberships from Microsoft Entra ID into TrustLogix entitlement tables. These attributes and group memberships can then be used to create and enforce data access policies. ### Steps to Import User Attributes and Group Membership #### 1. Configure Integration with Azure Set up the Azure integration by following the steps described in [Configure Azure AD/Entra as an Attribute Source Connection](/integrations/attribute-source-connection/azure-ad-or-ms-entra-graph-endpoint) #### 2. Configure Attribute Source Follow the below steps to configure the integration as attribute source * Go to **Attribute Management** * Click on **Source Configurations** Tab * Click on **Add Configuration** * Enter the source **Configuration Name** * Select the integration created in step#1 as Data Source Click on **Next** to create attribute definition Alternatively, go to the **Attributes** tab and click **Add Attribute** to create attribute definition(explained in the next step) #### 3. Define User attributes Follow the steps mentioned to [Create Attribute with Source Configuration](/attribute-management/attributes-based-on-source#creating-an-attribute-with-source-configuration) In order to create Azure AD attribute definition * Enable **“Map Attribute Value Source”** * Select the Azure attribute source created in Step 2 as the **Source Configuration** * Select **Attribute Type** as **Direct** * Choose the required Azure AD attribute from the **Source Column** * To import user group memberships, select **group** * Review and update additional fields as needed: * Display Name * Description * Group Name * **Save** the attribute * **Provision** the attribute > Please note that **group** is not a standard user attribute in Azure AD. It is a special attribute specifically designed to capture and import group memberships for users. > > All user attribute values, including group memberships, are stored directly in the data source. TrustLogix maintains only the metadata; the actual values are not stored within TrustLogix. #### 4. Import/sync Azure AD attribute values Once the attribute is defined: * The attribute sync service imports attribute values from Azure into the entitlement tables * Changes in Azure AD (including group memberships) are automatically synchronized * Synchronization occurs based on the configured frequency * The imported attribute values are stored directly in the entitlement tables of the corresponding data sources and are not persisted within TrustLogix. # Data Domains ### Overview Domain Management is a preview feature in TrustLogix that enables organizations to manage access control at a business-oriented level. By defining Domains, associating Data Products, and assigning Policy Administrators, enterprises can create a scalable, structured model for governing access across data assets. ### Key Concepts * Domain: A logical grouping of data products and their underlying assets (e.g., databases, schemas, tables). * Data Product: A set of related data assets that serve a business purpose. * Policy Administrator: A user assigned to manage access policies for a specific domain. * Access Policies: Policies like RBAC, ABAC (Row Access, Masking), and template-based policies scoped to domain assets. *** ### Feature Capabilities #### 1. Domain & Product Definition * Domains can only be created by Super Users or Data Source Administrators. * Within a domain, you can define one or more Data Products, each of which can contain multiple data assets. * Each data product must be mapped to a data source (e.g., Snowflake).\\ #### 2. Domain Asset Mapping Data assets mapped to a domain can include: * Database * Schema * Table/View * These mappings define the scope of enforcement for all access policies under that domain. #### 3. Data Product Asset Mapping Data assets mapped to a domain can include: * Table/View #### 4. Domain-Scoped Access Policy Management * Once domains and products are defined, Policy Administrators can be assigned to specific domains.\ Assigned Policy Administrators can: * Create RBAC and ABAC policies on data assets belonging to their domain. * Apply template-based policies, but only those templates defined at the domain level. * View and manage data products, but not the domain itself (only Super Users or Admins can manage domains). #### 5. Policy Enforcement Scope * RBAC Policies: Roles can be assigned access to domain-scoped data assets. * Template Policies: Domain-level templates only; system-level templates are not accessible to Policy Administrators. * ABAC Policies: * Row Access Policies based on user entitlements or data attributes. * Masking Policies for sensitive data, enforceable per product and user role.
*** ### Step-by-Step Guide #### A. Creating a Domain 1. Go to the TrustLogix Dashboard. 2. Navigate to the Domain Management section and click "Add Domain". 3. Enter the domain name (e.g., FinanceDetails) and a description. 4. Click Save. #### B. Adding a Data Product to the Domain 1. Click on the domain (e.g., FinanceDetails) → Data Products → Add Product. 2. Provide product name (e.g., DetailsOne) and datasource (e.g., Snowflake). 3. Select a linked data source (e.g., Snowflake Manual Testing Account). 4. Save the data product. **C. Linking Data Assets to the Product** 1. Go to the relevant data product (e.g., DetailsOne) → Data Assets → Add Data Asset. 2. Select asset type (Database, Schema, or Table) and link it to the Snowflake source. 3. Save the configuration. D. **Assigning a Policy Administrator** 1. In the User Management section, click "New User". 2. Enter user details (name, email, description). 3. Assign the user role: Policy Administrator. 4. Under Domain Access, select the relevant domain(s) (e.g., FinanceDetails). 5. Save the user profile.
*** ### Best Practices * Use business-friendly domain names that align with organizational units or data ownership (e.g., "Finance", "Marketing", "HR"). * Limit policy scope by assigning administrators to only the domains they govern.
Keep template libraries curated at the domain level to ensure consistent policy application.
# Data Products ### Overview **Data products** are curated, reusable, and value-focused datasets that are designed, developed, and maintained like software products to serve specific business or analytical needs. Data products are typically created **within and owned by** data domains. Each domain is responsible for the quality, relevance, and governance of its data products. Example: The "Customer Profile" data product would belong to the **Customer** domain. ### Policy Administrator Feature Capabilities As discussed under the concept of **data domains**, once **domains** and their corresponding **data products** are created and datasets are assigned. A **Super User** (or central data governance authority) can **delegate governance responsibilities** by assigning a **Domain Policy Administrator** for each domain. This delegation of responsibility enables **domain-driven data governance** at scale, with the following capabilities granted to the **Policy Administrator**: #### **Capabilities of a Domain Policy Administrator** 1. **Manage Data Products within Assigned Domains** * Create, update, or retire data products owned by their domain. * Maintain metadata, documentation, and classification of data products. 2. **Define and Manage ABAC/RBAC Policies** * Create fine-grained access control policies using **Attribute-Based Access Control (ABAC)** and **Role-Based Access Control (RBAC)** for data products in their domain. * Apply policies to views, tables. 3. **Attribute-Based Policy Enforcement** * ABAC policies are further refined using **data product-specific user attributes** (e.g., region, business unit, sensitivity level). * Enables dynamic, context-aware access control that adapts based on the user and product characteristics. ### User Attribute Administrator Feature Capabilities To scale and decentralize **Attribute Management**, the Super User can **delegate the responsibility** of managing user-specific attributes to a **Domain User Attribute Administrator** for each domain. This enables **domain-aligned**, **context-aware**, and **fine-grained attribute-based access control (ABAC)** policies by allowing attribute creation and management closer to the source of domain knowledge. **Capabilities of Domain User Attribute Administrator:** 1. **Data Product specific Attribute Definition & Management** * Define domain-product relevant user attributes (e.g., `region`, `business_unit`, `market_segment`) that are needed to enforce ABAC policies for data products in the domain. * Assign and update values for users belonging to their domain based on business roles or responsibilities. ### Step-by-Step Guide **A. Super User assigning a Policy Administrator** 1. Go to the TrustLogix Dashboard. 2. In the User Management section, click "New User". 3. Enter user details (name, email, description). 4. Assign the user role: Policy Administrator. 5. Under Domain Access, select the relevant domain(s) (e.g., FinanceDetails). 6. Save the user profile. B. **Super User assigning a User Attribute Administrator** 1. Go to the TrustLogix Dashboard. 2. In the User Management section, click "New User". 3. Enter user details (name, email, description). 4. Assign the user role: User Attribute Administrator. 5. Under Domain Access, select the relevant domain(s) (e.g., FinanceDetails). 6. Save the user profile. **C. Policy Administrator Creating ABAC policies** 1. Go to the TrustLogix Dashboard. 2. In the Data sources section, Access Policy -> Click Create Policy 3. Select **Row Access** Option 4. Provide Policy Name, Description 5. Select **Classified As** under Objects 6. Choose Data Products 7. Configure the conditions in the condition builder section 1. These also have Data Product based User Attributes 8. Click Save & Deploy policy. **D. User Attribute Administrator Creating product specific attributes** 1. Go to the TrustLogix Dashboard. 2. Navigate to **Attribute Management** from Menu. 3. Under the **Attributes** section click on **Add Attribute** 4. Select the registered **Snowflake** data source name. 5. Choose the specific **Data Product** (e.g. Accounting\_Finance) associated with this user attribute from Data Product dropdown. * Select **ALL** option for using it as common user attribute. 6. Enter the attribute **Display Name, Description**. 7. Choose the attribute **DataType**. 8. Choose the attribute **Group** (Optional). 9. Click **Save**. 10. Once Attribute is Saved, Click **Provision** to push attribute to Snowflake data source. # Attribute Management ### Overview Attribute Management refers to the process of defining, organizing, and maintaining **user attributes** that are used to make **attribute-based access control (ABAC)** decisions. It is a core capability enabling **Attribute-Based Access Control (ABAC)** policies to be created and enforced in a **domain-driven data governance** model. It defines how **user attributes** are structured, governed, and scoped for **policy authoring** and **policy deployment** across registered data sources like **Snowflake**. It can be used in following types of ABAC policies. 1. Masking policy 2. Row Filter policy ### Feature Capabilities Attributes in the ABAC system can be broadly classified as: * **Common User Attributes:** * Global attributes applicable across all domain products. * generally known as **ALL** under data products. * Example: `user.role`, `user.region` * **Domain Product-Specific User Attributes:** * Custom attributes tied to a specific **domain data product**. * Example: For `Finance` domain: `user.gl_access_scope`, for `Sales` domain: `user.territory_id` * The admin can specify a **Unique Identifier** for each data product to store and reference user attribute values. This ensures that attribute values are mapped accurately within the context of the data product and enables precise policy evaluation during ABAC enforcement These attributes are pre-defined centrally. * **Attribute Based Access Policies:** * ABAC policies are created based on assigned data products. * During policy creation, all applicable **User Attributes**—either **Common** or specific to the assigned **Data Product**—are automatically populated and made available for use in defining access rules. * These attributes are used to enforce fine-grained access control over the underlying data assets. ### Step-by-Step Guide **A. Create Domain Product User Attribute** 1. Go to the TrustLogix Dashboard. 2. Navigate to **Attribute Management** from Menu. 3. Under the **Attributes** section click on **Add Attribute** 4. Select the registered **Snowflake** data source name. 5. Choose the specific **Data Product** (e.g. Accounting\_Finance) associated with this user attribute from Data Product dropdown. * Select **ALL** option for using it as **Common** user attribute. 6. Enter the attribute **Display Name, Description**. 7. Choose the attribute **DataType**. 8. Choose the attribute **Group** (Optional). 9. Click **Save**. 10. Once Attribute is Saved, Click **Provision** to push attribute to Snowflake data source. ### Best Practices * Ensure that each attribute is clearly **scoped to a domain and specific data product**. * Prevent attributes from being reused across domains unless explicitly marked as **ALL (common/shared)**. * This supports **least privilege access** and ensures **policy isolation**. # Template Policies ### Overview **TrustLogix** introduces the concept of **Privilege Templates**, which serve as blueprints for defining access controls across a set of data source objects (e.g., tables, views, columns) and associated **privileges** (e.g., SELECT, USAGE, MODIFY).. **TrustLogix** categorizes privilege templates into below two types—**Database Level Templates**, **System Templates** and **Domain Templates**—to support both centralized and federated access control models. Each serves a distinct administrative purpose and governs a specific scope of data source objects. #### **1. System Templates** System Templates are designed for **platform administrators** (e.g., Snowflake Admins, Databricks Admins) who manage **infrastructure-level access controls** across the entire data environment. System Templates typically govern **global or system-level objects**, such as: * Data source **accounts** or tenants * **Applications** and integration services * **Warehouses** or compute engines * **Object-level roles** with admin-level privileges **etc.** Generally, Domain templates are designed for below personas in the organization: * **Super Users** * **Platform Governance Administrators \[Data Soure Administrators]** #### **2. Domain Templates** Domain Templates are designed for **Domain Policy Administrators** who manage access to data assets **within a specific domain,** such as Finance, HR, Sales, or Risk. These templates focus on **data-level access controls**, typically involving: * **Databases** * **Schemas** * **Tables & Views** * **Columns (for column-level security) etc.** Generally, Domain templates are designed for below personas in the organization: * **Domain Policy Administrators** * **Data Stewards** ### Super User Feature Capabilities 1. Super Users can create and manage both: * **System-Level Templates**: Designed to control access to global/system objects such as accounts, applications, compute warehouses, and integration services. * **Domain-Level Templates**: Targeted at domain-specific objects like databases, schemas, tables, views, and columns. #### **Access-Based Visibility Control** Templates created by Super Users are **automatically scoped and visible to personas** based on their access role and responsibility: | Persona | Access Scope | Template Visibility | | ------------------------------- | --------------------------- | --------------------------------------- | | **Domain Policy Administrator** | Domain-specific data assets | Can view and apply **Domain Templates** | | **Database Administrator** | System-level configurations | Can view and apply **System Templates** | ### Domain Policy Administrator Feature Capabilities 1. The Domain Policy Administrator can: * **View assigned template policies** created by Super Admins or Governance Teams. * **Apply templates to domain-specific assets**, such as schemas, tables, or views , by creating the RBAC-> Privilege template policy. 🔹 Example: A "Finance Analyst Access Template" might grant SELECT on financial reports and views for the `ANALYST` role. ### Step-by-Step Guide **A. Super User creating custom domain templates** 1. Go to the TrustLogix Dashboard. 2. In the Configurations section, Click **Privilege Template Management** 3. Click **Add Privilege Template** 4. Provide Template Name, Description 5. Select which data source it will apply to \[Snowflake, Databricks] 6. Select **Classified As** under Objects 7. Select Is Domain Template flag if template is created for domain policy administrators. 8. Select Object Type & Privileges 9. Click Save. **B. Super User assigning a Domain to Policy Administrator** 1. Go to the TrustLogix Dashboard. 2. In the User Management section, click "New User". 3. Enter user details (name, email, description). 4. Assign the user role: Policy Administrator. 5. Under Domain Access, select the relevant domain(s) (e.g., FinanceDetails). 6. Save the user profile. **C. Domain Policy Administrator creating template policies** 1. Go to the TrustLogix Dashboard. 2. In the Data sources section, Access Policy -> Click Create Policy 3. Select **Object Access** Option 4. Provide Policy Name, Description 5. Select **Policy Type as Privilege Template** 6. Select the domain privilege template - created by Super User. 7. Select the domain assets - database, & schema, 8. Click on Next 9. Select the Principal \[Snowflake role, Snowflake DB Role] 10. Click Save & Deploy policy. # Administration # Users #### Creating a New User in TrustLogix Follow the steps below to create a new user in TrustLogix: **1. Navigate to the User Management Section** * Log in to the TrustLogix application with the appropriate credentials. * Navigate to the **Users** section from the main menu. **2. Open the Create New User Form** * Click the **Create New User** button to open the user creation form. **3. Fill in the User Details** * **Full Name**: Enter the full name of the user. * **User Description**: Provide a brief description of the user or their role. * **Email Address**: Enter the user’s email address. * Ensure the email is valid, as a password will be sent to this address for the user to log in. **4. Assign Roles to the User** Toggle the roles you want to assign to the user. The available roles are: 1. **Super User** * Grants unrestricted access to all data sources and their configuration. 2. **Data Source Administrator** * Provides full access to specific data sources and their configurations. 3. **Compliance Manager** * Allows access to create and modify monitoring policies and visualize risk alerts. 4. **Policy Administrator** * Grants the ability to create and modify access policies. 5. **Data Access Policy Reader** * Read-only access to view data access policies. 6. **User Attribute Administrator** * Grants access to create and manage access policy user attributes. **5. Save the User** * Once all the required information is filled in and roles are assigned: * Click the **Create User** button to save the new user. * The system will send an email with the login credentials to the specified email address. **6. Confirm User Creation** * After saving, verify that the user has been added to the **User Management** list. * Test the credentials by logging in, if necessary. *** By following these steps, you can successfully create and configure a new user in TrustLogix. # Delegated Administration TrustLogix offers a role-based delegation model for administering data security and governance operations across data sources, domains, and compliance features. The roles are designed to support operational separation of duties and ease of administration. #### Super User * Scope: Global and full access across all TrustLogix functionalities. * Responsibilities: * Manage all data sources and configurations. * Create and manage users and assign roles.\ Access to all modules, including DSPM, access governance, tagging, data risks, monitoring, and reporting. * Can create domain and products also assign the data assets to them * UI Access: Full UI access. #### Data Source Administrator * Scope: Admin rights restricted to specific data sources. * Responsibilities: * Manage configurations for the assigned data source(s). * Assign policy administrators and manage related policies. * Perform data classification, sensitive data tagging, access tracking, and alert configuration for the assigned data sources. * They can manage the users, like updating domains or database assignment of the users assigned to a data source * Can create domain and products also assign the data assets to them * UI Access: Full access is limited to their assigned data sources. #### Compliance Manager * Scope: DSPM (Data Security Posture Management) functionalities across the environment. * Responsibilities: * View and analyze data sprawl reports, access patterns, and sensitive data movement. * Monitor alerts and policy violations. * Generate compliance and risk reports. * UI Access: Read/write access to DSPM dashboards and reports. #### Policy Administrator * Scope: Limited by Data Source or Domain assignment. * Responsibilities: * Create and manage access control policies (RBAC, ABAC, masking). * When assigned: * Data Source Level: Policies can be created and applied only to that data source using database-level templates. * Domain Level: Can manage policies using domain-level templates, and only for assets defined within that domain. * Can manage products and their assets * Restrictions: * Cannot use system-wide templates. * UI visibility and functionality are limited to their scope. * Policy administrators with domain assignments will: * Only see policies mapped to their domain. * Only use domain-specific templates. * Policy administrators with database assignments will: * Only see policies mapped to their assigned databases. * Only use database-specific templates. * UI Access: Yes, based on assigned scope. #### User Attribute Administrator * Scope: User Attribute Configuration to the assigned data sources. * Responsibilities: * Define and manage user attributes for the assigned data sources used in ABAC policies. * Maintain allowed values and hierarchical mappings for user entitlements. * UI Access: Yes, limited to attribute management panels. #### Attribute Value Manager * Scope: User Attribute Value Configuration to the assigned data sources. * Responsibilities: * Maintain allowed values and hierarchical mappings for user entitlements for the assigned data source. * UI Access: Yes, limited to attribute value management panels. #### Policy Reader * Scope: Read-only access to the assigned data sources * Responsibilities: * View configurations, policies, reports, and dashboards. * No create, edit, or delete permissions. * UI Access: Read-only access. #### Policy Promoter * Scope: Integration-focused automation. * Responsibilities: * Promote and push policies using TrustLogix APIs. * Does not interact with the UI. * Commonly used in CI/CD pipelines or external integrations. UI Access: No UI access. ### Permissions Matrix
RoleCreate DomainManage ProductsDefine PoliciesUse TemplatesManage AttributesManage DSPM
RoleCreate DomainManage ProductsDefine PoliciesUse TemplatesManage AttributesManage DSPM
Super UserYesYesYes Yes (All templates)Yes (All attributes)Yes
Data Source AdministratorYesYesYesYes (All templates)Yes (All attributes)Yes
Policy Administrator(Domain Level)NoYes (Assigned Domain only)Yes (On Data Products from Assigned Domains only)Yes (Domain-level Templates only)NoNo
Policy Administrator(Database Level)NoNoYes(On Assets which are under assigned databases only)Yes(Database level templates only)NoNo
User Attribute Manager(Domain Level)NoNoNoNoYes (ALL or On Data Products from Assigned Domains only)No
User Attribute Manager(Database Level)NoNoNoNoYes (Restricted to Non Data Products attributes)No
Policy Reader(Domain Level)No(Read only access)No(Read only access)No(Read only access)NoNo(Read only access)No
Policy Reader(Database Level)NoNoNo(Read only access)NoNo(Read only access)No
Compliance ManagerNoNoNoNoNoYes
# Configurations # Tenant Settings Tenant settings are organization level settings that deal with cloud resource creation as well as data encryption. The following settings deal with cloud resource creation and they can be turned on or off using the toggle button. 1. Deploy Access Analyzer Resources 2. Deploy Access Governance Resources 3. Deploy Monitoring Resources 4. Deploy Real-Time Monitoring The following setting deals with data encryption at REST and it can be turned on using the toggle button and by providing the cloud provider specific encryption key 1. Encryption Key NOTE : The Encryption Key toggle button cannot be turned off from the TrustLogix console. # Templates Privilege Template access policies are a key feature in TrustLogix that enable customers to create object access policies based on personas defined within an organization. Privilege templates group object types and privileges on a data source, allowing for combined grant assignments using a single policy.
### Managing Privilege Policy Templates **Navigating to Privilege Templates** * Log in to TrustLogix. * Click on the **Menu** icon. * Navigate to **Configurations**. * Click on **Privilege Template** card. **Viewing and Selecting a Template** * A list of available templates will be displayed. * TrustLogix provides some pre-seeded templates based on industry standards. * Customers can customize existing templates or create new ones. * Select an existing template (e.g., **DB Privileges - DDL & RW**) to modify or create a new one. **Editing a Template** * Click on the **Edit** button. * Click the **+** icon to add a new object type and privilege. * Select an **Object Type** (e.g., **ACCOUNT**). * Select the required **Object Privilege**. * Click **Close** to save the selection. * Modify existing object type privileges as needed. * Click **Update** to save the template. **Deploying Updated Templates** * If there are existing policies using the template, a warning modal appears. * The user can choose to **redeploy the existing policy** or **only update the template**. * Impacted policies will be flagged on the **Access Policies List** page for redeployment. **Creating a New Policy Using the Template** * Click on **Enter a policy name**. * Select **Policy Type** and choose **Privilege Template**. * Configure additional details as required. * Save the policy. ### Notes * Privilege templates streamline policy management by grouping grants under a single entity. * Users should ensure proper redeployment of policies when updating templates. * TrustLogix provides predefined templates, but customization is fully supported. # Understanding Future Schema Grants and Permission Gaps ### Overview In Snowflake, generating future grants at the schema level is expected behavior. However, when future grants are defined at both the database and schema levels, a known limitation can lead to permission inconsistencies. This document explains the cause of the issue and how it is addressed. *** ### The Snowflake Gap: Database vs. Schema Precedence There is a known behavior in Snowflake regarding how future grants are evaluated that can disrupt access policies: > 🚧 Important Snowflake Behavior When future grants are defined at *both* the database level and the schema level, the schema-level grants take absolute precedence and the database-level grants are completely ignored. #### How the Gap Occurs 1. Database-Level Grant: You grant a privilege (e.g., `SELECT ON FUTURE TABLES`) to Role A at the Database level. The expectation is that Role A will have access to all future tables across all schemas in that database. 2. Schema-Level Grant: Later, a future grant is applied to Role B at the Schema level for a specific schema within that same database. 3. The Resulting Gap: Because the schema-level grant exists, Snowflake overrides and ignores Role A's database-level grant for that specific schema. When new tables are created in that schema, Role A will receive an "Insufficient Privilege" error, breaking expected data access workflows. *(Reference:* [*Snowflake Knowledge Base - Behavior of future grants when defined at both database and schema level*](https://community.snowflake.com/s/article/Behavior-of-future-grants-when-defined-at-both-database-and-schema-level)*)* *** ### The TrustLogix Solution TrustLogix eliminates the manual overhead of tracking these precedence conflicts and ensures that your overarching access control policies are respected automatically. #### How TrustLogix Fixes This To fix this Snowflake gap, TrustLogix automates the resolution process for privilege template policies deployed using the TrustLogix Console: * Targeted Scanning: TrustLogix exclusively scans Privilege template policies that are deployed through the TrustLogix console. * Automated Grant: If a new policy is deployed at the database level, TrustLogix checks for an existing schema-level policy on the same database. If one is found, TrustLogix automatically adds the specific schema grants to that existing policy to prevent any access gaps. * Automated Redeployment: If a policy is initially deployed using `ALL_SCHEMAS`, and subsequently a new policy is created for a selected schema within that same database, TrustLogix automatically redeploys the `ALL_SCHEMAS` policy. During this redeployment, it appends the additional schema future grants to ensure the broader database-level access intent remains fully intact. #### Key Benefits * Consistent Access: Prevents unexpected "Insufficient Privilege" errors for roles that should inherently have database-wide access. * Reduced Administrative Overhead: Eliminates the need for Snowflake administrators to manually track overlapping future grants and issue reactive, schema-by-schema permissions. * Secure Scaling: Allows security and data engineering teams to confidently define broad database policies alongside granular schema policies without breaking data pipelines. # User-Defined Function Using Functions in Access Policy Condition Builder This guide explains how to map and utilize custom or system functions within the TrustLogix platform to build dynamic data access policies. **Important Note:** TrustLogix does not create functions directly in your target data source. It simply maps existing data source functions within the TrustLogix UI so they can be referenced and applied during policy creation. #### Pre-requisites Before mapping a function in TrustLogix, ensure the following: * **Required Permissions:** Grant **USAGE** permissions on the database, schema, and the specific function to the `tlx_dp_role`. * **Function Availability:** Ensure the function is already mapped in the TrustLogix UI as a **Custom Function**. #### Mapping the Function To make a function available for policies, you must first register it in the TrustLogix dashboard: 1. **Navigate**: Go to Configurations -> User Defined Function. 2. **Tab Selection**: Select the Custom Functions tab. 3. **Initiate Mapping**: Click the + Custom Function button. 4. **Selection Steps**: 1. Select the Database from the dropdown menu. 2. Select the Schema belonging to that database. 3. Select the specific Function you want to map. 5. Error Handling (Validation): **Duplicate Check**: TrustLogix will validate if the function has already been mapped. If you attempt to add a function that already exists in the system, an error message will appear preventing the duplicate entry. #### Applying Functions in Policy Conditions Once the function is registered, it can be used in your Row Access Policies (RAP) or Masking Policies. **Steps to Implement:** 1. Navigate to your **Data Source** and select **Access Policy**. 2. Choose to **create a new policy** or **edit an existing** RAP or Masking Policy. 3. In the **Condition Builder**, locate the **System or Custom Function** option. 4. Select your mapped function from the list to define your policy logic. #### **Limitations** While the Condition Builder is flexible, the following limitation applies: * **Nesting Support:** The Condition Builder supports function nesting up to **one level only**. * ✅ Supported: `FunctionA(FunctionB(column))` * ❌ Not Supported: `FunctionA(FunctionB(FunctionC(column)))` * **Complex Expressions:** For multi-level nesting, use the *Custom Expression* field starting from the second level onward. * Example: `FunctionA(FunctionB(FunctionC(column)))` # Integrations # Attribute Source Connection #### **Attribute Source Connections in TrustLogix** Attribute Source Connection in TrustLogix allow users to configure external identity providers (such as Azure Active Directory) as sources for attribute-based access control (ABAC). This document outlines the steps required to set up an external attribute source connection. # Azure AD or MS Entra Graph Endpoint *** ### **Configure Azure AD/Entra as an Attribute Source Connection** #### **1. Access the Attribute Source Connections Page** 1. Log in to the **TrustLogix Dashboard**. 2. Navigate to **Integrations** > **Attribute Source Connections > Add** *** #### **2. Configure the Connection Details** > Create a separate application to integrate the graph endpoint as source in TrustLogix. Please follow [prerequisites](#id-3.-follow-the-prerequisite-steps) step to get the required details to complete the integration. 1. **Select Connection Type** * Choose the external source (e.g., **Azure Active Directory (Azure AD)**). 2. **Enter Connection Details** * **Configuration Name**: Provide a user-friendly name (e.g., "Azure AD - HR Attributes"). * **Azure Tenant ID**: Enter the unique identifier for the Azure AD tenant. * **Client ID**: Provide the application Client ID from Azure AD. * **Client Secret Value**: Enter the secret key for authentication. > * Get Application(Client) ID and Directory(Tenant) ID from Azure Application Overview page. > > Copy Secret value while creating in prerequisites step. > > * For hybrid tenants, the Azure Tenant ID, Client ID, and Client Secret are not required. These credentials are stored and managed exclusively on the customer side (e.g., Azure Key Vault or AWS SSM). 3. Enable below options 1. **Sync All Users from Microsoft Entra ID :** Enables automatic addition and synchronization of new, deleted, and disabled users from Microsoft Entra ID. When disabled, only users imported via the console are synchronized. 2. **Delete Inactive or Deleted Microsoft Entra ID Users from Entitlement Table:** When enabled, inactive Microsoft Entra ID users are permanently deleted from the entitlement table. When disabled, only a soft delete occurs. *** #### **3. Follow the Prerequisite Steps** To retrieve the necessary credentials, follow these steps: #### Steps to Register a Microsoft Graph App in Azure: Register an application 1. Go to Azure Portal:\ Visit the [Azure Portal](https://portal.azure.com/). 2. Navigate to Azure Active Directory:\ In the left-hand menu, click on Azure Active Directory. 3. Register a New Application: 4. * In the Azure Active Directory panel, select App registrations. * Click on New registration at the top.![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXeVpkOpPdcAL-ExDsoOmS23rYK1_FsdrLYRG7IkEZDnOzkBA4vdxBmspYBzmdOC3Zkt3rqD91BPBSSk_izcec4wRqhc1l_qJquEIO0r0PN5nyy8I0vTIVjYruPJg3lL6CpJ1uraGg?key=SgOgRPvsv9boI1waxuEWn1US) 5. Fill in Application Details: 6. * Name: name for your application (e.g., "Health Care Graph API"). * Supported account types: Select Accounts in this organizational directory only (Default Directory only - Single tenant) * Once you’ve filled in the necessary details, click on the Register button.![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfXQ0V_2FV7Rp6Qi8ro04LM1bYAzuzxMdxM-jVmG3DhTzB_0RNkP6fqnWpcyxljCa171fYmVznfuENexv1XnncdTvyfDZtMWfehpnXAZR_PFE80UhyNGTXpFJYITqmNzZHpNx8z?key=SgOgRPvsv9boI1waxuEWn1US) Configure API Permissions: 1. After registration, you will be directed to the app's Overview page.![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXe6Vj6qpsB1sLjBGNI2xhJBwmLU-5DDWdbHl1S8jtpb6c0-Nh8zuDadg3dop9M2clZDre-UjKVfEFuudpbqDk1N8gEPm-b-C7Oieu54E-Yw-PqZLtcFgowzBoKt5iyw5KXSJM6ZPg?key=SgOgRPvsv9boI1waxuEWn1US) * Select API permissions from the left-hand menu under Manage. * Click Add a permission > Microsoft Graph. * Choose the appropriate permissions: * * Application permissions (for app-only access without a user). * Select the necessary permissions for your app (User.ReadBasic.All).![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXfpzfTkeXPTGZdctWPWdP-TnoBLA2H0A5ObgYwRXm2PtCz2h8Q8ZtMDTa11tzwEiLFk9dU_eLQXncOkLIT7fAi8CgxVTfSpQy2AdrYBe0GYsXQ3aaM9lWqp_Hzm57LRMsuHJT1Vtw?key=SgOgRPvsv9boI1waxuEWn1US) * Set Admin consent by clicking on Grant admin consent to Default Directory![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXe2RDwspa4STWl2oXfT8mzc3LmBSrWOT-cAWfd45PJGi4TZzWSv1r7xDGunGezTeH9_XQ9GXYSE1bWRaoOJG9rGIHbPztCgC9JNUP8YhVil-W5M49uVN46mgIKXao70eW2c0xt3?key=SgOgRPvsv9boI1waxuEWn1US) > Not[^1]e: > > The `User.ReadBasic.All` permission allows reading only a basic set of profile properties, including display name, first name, last name, email address, open extensions, and photo. To access any other user properties, the `User.Read.All` permission is required, and to access/import user's group and group membership information, the `GroupMember.Read.All` permission is required. Create a Client Secret: 1. * If your app needs to authenticate without user interaction, create a client secret (application password). * Go to Certificates & secrets > New client secret. * Provide a description and set an expiration period, then click Add. * Note: Be sure to copy the secret value immediately, as you won't be able to see it again.![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcJVqFBP9WmVNKqfOXtl0tPL1Kld5RxF5MrYvahH10bAufeay-8dEYfBOHSO5WmjsLp2DJ0KkuEUw5mikIsB7SQv59yT6N-dFfPVE2UeyQnr9MFy9e-oUEZpYIvIg6hL6GC31XIjg?key=SgOgRPvsv9boI1waxuEWn1US)
*** #### **4. Save the Integration Details** 1. Click on **Save** to save the Integration details. 2. If there are errors, check the credentials entered are valid. [^1]: # Single Sign On TrustLogix supports Single Sign-On (SSO) integration with multiple Identity Providers (IdPs) to enhance security and simplify authentication for enterprise users. The integration allows users to log in to TrustLogix using their organization's authentication system, ensuring seamless and secure access management. *** ### **Supported Identity Providers (IdPs)** TrustLogix supports integration with the following IdPs: * **Azure AD** * **Okta** * Other IdPs supporting **SAML 2.0** authentication Each IdP has a similar integration process, which involves configuring SAML-based authentication, exchanging metadata, and setting up user provisioning where applicable. *** ### **General Steps for SSO Integration** #### **1. Configure Enterprise Application in IdP** * Log in to the IdP's admin console. * Create a new **Enterprise Application** for TrustLogix. * Select **SAML-based authentication**. * Provide required TrustLogix SAML attributes, such as: * **ACS (Assertion Consumer Service) URL**: `https://trustlogixhostname/api/federation/{tenant_id}/sso` * **Entity ID**: `https://trustlogixhostname/api/federation/{tenant_id}/metadata` * Download the **Federation Metadata XML** from the IdP. > Replace trustlogixhostname with hostname shared for front end use. #### **2. Configure SSO in TrustLogix** * Log in to TrustLogix with **Super Admin** privileges. * Navigate to **Integrations → SSO**. * Create an SSO integration by providing: * **Integration Name** (e.g., "Azure AD SSO") * **Metadata XML** downloaded from IdP * **Redirect URL** (User Access URL from IdP) * Save and enable the integration. # Azure Active Directory (MS Entra) ## Integration of SSO with Azure AD and TrustLogix ### Create Azure AD SSO Application Follow these steps to create an Azure AD SSO application for TrustLogix: #### Step 1: Create an Enterprise Application 1. Navigate to **Microsoft Entra ID** → **Enterprise Applications**. 2. Click on **New Application**. 3. Select **Create your own application**, provide a name, and create the application. #### Step 2: Configure Single Sign-On (SSO) 1. Go to **Single Sign-On** and select **SAML**. 2. Add the **Entity ID** and **ACS URL**: * **Entity ID**: `https://{trustlogixhostname}/api/federation/{tlx_tenant_id}/metadata` * **ACS URL**: `https://{trustlogixhostname}/api/federation/{tlx_tenant_id}/sso` * NOTE : Replace **trustlogixhostname** with hostname shared for front end use e.g. : dp.trustlogix.io and **tlx\_tenant\_id** with the alphanumeric value e.g. : 8a48834e95ea0b540195ea56a5ae00d3 3. Download the **Federation Metadata XML**. 4. Navigate to **Properties** and retrieve the **User Access URL** (Redirection URL), for example: [https://launcher.myapps.microsoft.com/api/signin/\?tenantId=\](https://launcher.myapps.microsoft.com/api/signin/87957f06-9692-4a1f-8c98-a3329cf5b39a?tenantId=64ddf09f-4f98-4b98-a806-f947d4d7a672) *** ### Enable SSO in TrustLogix Once the Azure AD SSO application is created, follow these steps to configure SSO in TrustLogix: #### Step 1: Configure SSO in TrustLogix 1. Log in to **TrustLogix** using a **Tenant Root Admin** user with Super User role. 2. Navigate to the **Integrations** page. 3. Click on **Create SSO Integration**. 4. Fill in the required details: * **Integration Name** * **Metadata XML** (downloaded from the Azure AD application) * **Redirect URL** (from Azure AD application) 5. Save the integration. #### Step 2: Test SSO Login 1. Assign a user to the Azure AD application. 2. Create a user with the same email address in TrustLogix. 3. Log in using SSO to verify successful authentication. *** By following these steps, TrustLogix will be successfully integrated with Azure AD for SSO. To enable user provisioning from Azure AD refer User Provisioning section. # User Provisioning from Azure AD ### Enable User Provisioning To enable automatic user provisioning from Azure AD to TrustLogix, follow these steps: #### Step 1: Enable Auto Provisioning in TrustLogix 1. Navigate to existing Azure AD SSO Integration item. 2. Click the **Enable Auto Provisioning** button in TrustLogix. 3. TrustLogix will generate a **SCIM URL** and a **Bearer Token**. 4. Copy the **SCIM URL** and **Bearer Token** for use in Azure AD. #### Step 2: Configure Provisioning in Azure AD 1. Navigate to **Provisioning** under **Manage** in the Azure AD application (This could be the same SSO application created in Azure AD for TrustLogix Integration). 2. Click on "New Configuration" button . 3. Configure the connection using the details from TrustLogix Console: * **Tenant URL (SCIM URL)** * **Secret token (SCIM Token)** (prefix with `Bearer` , e.g., `Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdW***`) * Disable the Groups Provision check box under the Mappings 4. Test the connection. 5. After a successful connection, create the provisioning setup. 6. Navigate to **Users and Groups** and assign the users or groups to TrustLogix SSO Application. #### Step 3: Start Provisioning 1. Go to **Overview (Preview)** in Azure AD. 2. Click **Start Provisioning**. 3. User provisioning occurs every **40 minutes** for newly assigned users. *** ### Notes * If **Auto User Provisioning is disabled**, customers must manually create users in TrustLogix with their Azure AD email ID and assign roles. * If **Auto User Provisioning is enabled**, new users or groups assigned in Azure AD will be automatically created in TrustLogix **without roles**. * A **Super Admin** must manually assign TrustLogix roles to newly provisioned users. By following these steps, TrustLogix will be successfully integrated with Azure AD for SSO and automatic user provisioning. ### References * Regenerate SCIM token on expiration: # User Deprovisioning from Azure AD ### Enable User Deprovisioning To enable automatic user deprovisioning from Azure AD to TrustLogix, follow these steps: #### Step 1: Enable Auto Deprovisioning in TrustLogix 1. Navigate to existing Azure AD SSO Integration item. 2. Click the **Enable Auto Deprovisioning** button in TrustLogix. 3. There are three fields that you need to populate in the TrustLogix UI 1. Azure Tenant ID 2. Client ID 3. Client Secret Value 4. To retrieve these values, go to Azure and search for "App registrations" and then search for the SSO application that has been created under the "All applications" 5. Click on the SSO application and on the main page you will find the following values 1. Directory (tenant) ID 2. Application (client) ID 6. You will have to generate a new client secret by going to the "Certifications & secrets" option under "Manage" option 1. Click on to generate a new client secret. 7. Now populate the values in the TrustLogix UI with the tenant ID, client ID and client secret Azure values and save them. 8. For the User Deprovisioning to happen in TrustLogix, the SSO application should be provided with the Microsoft Graph service Read API permissions. 1. Go to "API permissions" option under "Manage" option. 2. Click on button and select "Microsoft Graph" service. 3. Then click on the "Application permissions" button and search for "DelegatedPermissionGrant" as well as "User" permissions to select the Read permission e.g. and click on the "Add permissions" button. 4. Click on "Grant admin consent for Default Directory" button to provide the above Read permissions *** ### Notes * If **Auto User Deprovisioning is disabled**, customers must manually remove users in the TrustLogix application. * If **Auto User Deprovisioning is enabled**, users removed in Azure AD will be automatically be removed from the TrustLogix application. By following these steps, TrustLogix will be successfully integrated with Azure AD for automatic user deprovisioning. # Okta ## Integration of SSO with Okta and TrustLogix ### Create okta SSO Application Follow these steps to create an Okta SSO application for TrustLogix: #### Step 1: Create Okta Application 1. Navigate to **Okta** → **Applications**. 2. Click on **Create App Integration**. 3. Select **SAML 2.0 option for SSO**. 4. provide **App Name** & optional logo. 5. Click Next for SAML configuration. 6. Provide **Single Sign On URL** on below format. 1. `https://{trustlogixhostname}/api/federation/{tlx_tenant_id}/sso` 7. Provide **Audience URI (SP Entity ID)** as below format. 1. `https://{trustlogixhostname}/api/federation/{tlx_tenant_id}/metadata` 8. Provide **Name ID Format** as **Unspecified &** Click on **Next.** 9. Click **App type** as **This is an internal app that we have created.** 10. Click on **Finish.** #### Step 2: Capture Metadata XML 1. Under your registered Application, Goto **Sign On** tab. 2. Under Sign On Tab, right side, there is information about **SAML2.0,** Scroll down to bottom of the page & click on **View SAML setup instructions.** 3. It will open up the SAML information on new tab. 4. Scroll to end of the Page, There is an **Optional** section. 5. Under the **Provide the following IDP metadata to your SP provider**. 1. Copy the XML and save it as XML file. 2. This file will be uploaded on TrustLogix under Integrations page. ### Enable SSO in TrustLogix Once the Okta SSO application is created, follow these steps to configure SSO in TrustLogix: #### Step 1: Configure SSO in TrustLogix 1. Log in to **TrustLogix** using a **Tenant Root Admin** user with Super User role. 2. Navigate to the **Integrations** page. 3. Click on **Create SSO Integration**. 4. Under the **Okta** option, Click on **Integrate**. 5. Fill in the required details: * **Integration Name** * **Metadata XML** (downloaded from the Okta) * **Redirect URL** (from Okta application) * This must be Okta Application embedded URL. * Go to **General** tab under registered Okta Application. * under **App Embed Link** option , there is application URL under the **Embed Link** , provide this URL as redirect URL on TrustLogix. 6. Save the integration. #### Step 2: Test SSO Login 1. Assign a user to the Okta application. 2. Create a user with the same email address in TrustLogix. 3. Log in using SSO to verify successful authentication. *** By following these steps, TrustLogix will be successfully integrated with Okta for SSO. To enable user provisioning from Okta refer User Provisioning section. # User Provisioning from Okta ### Enable User Provisioning To enable automatic user provisioning from Okta to TrustLogix, follow these steps: #### Step 1: Enable Auto Provisioning in TrustLogix 1. Navigate to existing Okta SSO Integration option. 2. Click the **Enable Auto Provisioning** button in TrustLogix. 3. TrustLogix will generate a **SCIM URL** and a **Bearer Token**. 4. Copy the **SCIM URL** and **Bearer Token** for use in Okta. #### Step 2: Configure Provisioning in Okta 1. Open the Application created for SSO in Okta 2. Go to General tab, & click on Edit 3. Under **Provisioning** option, Select **SCIM,** Click **Save.** This will enable **Provisioning tab.** 4. Go to the **Provisioning** tab, under integration option, click on **Edit** 1. Provide the **SCIM connector base URL** as **the TrustLogix-generated SCIM URL** from **Step-1** 2. Provide the **Unique identifier field for users** as userName 3. under Supported provisioning actions 1. Select Import New Users and Profile Updates 2. Select Push New Users 3. Select Push Profile Updates 4. Under Authentication Mode, Select **Http Header** option 5. Under HTTP Header -> Authorization -> Bearer, provide the **TrustLogix-generated token**. 6. Click on **Test Connector Configuration** 7. Once testing is successful, click on **Save**. ### References * Regenerate SCIM token on expiration: # User Deprovisioning from Okta ### Enable User Deprovisioning To enable automatic user deprovisioning from Okta to TrustLogix, follow these steps: #### Step 1: Enable Auto Deprovisioning in Okta 1. Login to Okta, go to the registered Application, 2. Go to the **Provisioning** tab. 3. Under **To App** option, **Provisioning to App** , click on **Edit** 1. **Enable Create Users** 2. **Enable Deactivate Users** 3. Click **Save.** ### Notes * If **Auto User Deprovisioning is disabled**, customers must manually remove users in the TrustLogix application. * If **Auto User Deprovisioning is enabled**, users removed from Okta Application will be automatically be removed from the TrustLogix application. By following these steps, TrustLogix will be successfully integrated with Okta for automatic user deprovisioning. # Generate SCIM token This document explains how to regenerate an existing SCIM token, validate it in the user provisioning application, and update it in both the external application and the TrustLogix console. ### Important Note * **SCIM token regeneration is supported only if user provisioning is already enabled** for the SSO integration. ### Prerequisites Before you begin, ensure the following: * An existing SSO integration is already configured * User provisioning is enabled for the SSO integration * Access to the external user provisioning application * Log in to the TrustLogix console as **Tenant Root user.** ### Steps to Regenerate the SCIM Token #### Step 1: Navigate to the Existing SSO Integration 1. Log in to the **TrustLogix Console** 2. Go to **Integrations** using left corner hamburger menu 3. Open the existing SSO integration for which SCIM provisioning is enabled #### Step 2: Regenerate the SCIM Token 1. Click on **Regenerate SCIM Token** 2. A new SCIM token will be generated #### Step 3: Copy and Test the Token 1. Copy the newly generated SCIM token 2. Navigate to the **User Provisioning** section in your external application 3. Paste the token and test the SCIM connection using the provisioning test option #### Step 4: Update the Token in the External Application Once the connection test is successful: 1. Save the regenerated SCIM token in the external user provisioning application 2. Ensure the updated token is active and applied #### Step 5: Update the Token in the TrustLogix Console 1. Return to the **TrustLogix Console** 2. Update the SCIM token for the corresponding SSO integration 3. Click **Update** to complete the configuration # Collaboration Tool TrustLogix supports integration with multiple collaboration tools to enhance communication of security activities for enterprise users. These integrations allow all relevant stakeholders to be informed of potential security risks in a timely manner, leading to quicker decision-making and proactive risk mitigation. ### **Supported Collaboration Tools** TrustLogix supports integration with the following tools: * **Email** * **Slack** Each collaboration tools integration process is defined in the below child pages. # Email ## Integration of Email with TrustLogix #### Prerequisite 1. Create a distribution list email where multiple users are subscribed to it. This email will receive all the TrustLogix security risk alerts. #### Setup 1. Enter the distribution list email created in the prerequisite step 2. Choose the severity of the security risk alerts. If you only want the Critical and High severity alerts to be sent to the distribution list email then select them in the drop down list. #### Post Setup 1. An email from AWS with the following subject will appear in the inbox tied to the distribution list email 1. **Amazon Web Services – Email Address Verification Request in region US East** 2. Click on the URL mentioned in the email to verify the request. 3. Once the email has been verified, the distribution email will start receiving the TrustLogix security risk alerts in this manner | Monitoring policy name | Monitor for block list IP addresses | | ---------------------- | ----------------------------------- | | Description | Alert block list IP's | | Account | Snowflake Dev | | Account type | Snowflake | | Category | Shadow IT | | Severity | High | # Slack #### Prerequisite 1. Create a Webhook URL using this [link](https://api.slack.com/messaging/webhooks). TrustLogix will send all the security risk alerts to the Slack channel tied to this Webhook Slack App. #### Setup 1. Enter the Slack Web Hook URL created in the prerequisite step 2. Choose the severity of the security risk alerts. If you only want the Critical and High severity alerts to be sent to the distribution list email then select them in the drop down list. #### Post Setup 1. TrustLogix security risk alerts will be sent to the Slack App in this manner
# Release Notes TrustLogix releases new versions bi-weekly. These releases include both the feature additions as well as the product bug fixes. # 2026 Q3 Releases # Aug 2026 This release strengthens AI agent security and risk visibility. Guardian Agent now automates EU AI Act compliance reporting and expands real-time Snowflake risk detection, while a new interceptor enforcement mode gives security teams deeper control over MCP traffic. **Feature List** * MCP Interceptor Enforcement Mode * Automated EU AI Act Compliance Reporting * Expanded Real-Time Snowflake Risk Detection *** #### New Features & Enhancements Kong AI Gateway TrustLogix Plugin: Interceptor Enforcement Mode Advanced Traffic Interception: Kong AI Gateway integration is now available as a new "Interceptor" enforcement mode, giving security teams deeper inspection and control over AI agent traffic passing through the gateway. *** **Guardian Agent Compliance & Risk** Automated EU AI Act Reporting: Guardian Agent can now generate compliance reports for the EU AI Act automatically, reducing the manual effort required to demonstrate regulatory alignment. A new Compliance Report view brings these reports directly into the Guardian Agent interface. Expanded Snowflake Risk Detection: Real-time risk detection for Snowflake now covers a broader range of privileged events, giving security teams even faster visibility into risky access as it happens. *** #### Improvements * Data Source Favorites: You can now mark data sources as favorites for quicker access and easier navigation. * Modernized Dialogs: The "Import Users" dialog has been redesigned for a cleaner, more consistent experience. * UI Standardization: Buttons, tables, and tabs have been standardized across the product for a more consistent look and feel. * Clearer Sync Notifications: Policy synchronization notification emails now provide clearer, more actionable content. * Clearer Attribute Categories: "Identity Type" has been renamed to "Attributes Category" to better reflect the addition of asset-level attributes. * Streamlined Dremio Registration: Dremio registration now supports single-project selection for simpler setup. * Multi-Server MCP Management: The UI now supports viewing and managing multiple MCP servers at once. * Clearer "No Data Found" Messaging: Search results now include clearer reasoning and next-step guidance when no data is found. * Sharper Databricks Risk Detection: Improved risk detection accuracy for Databricks environments. * Real-Time Guardian Agent Prompts: Guardian Agent now supports real-time, event-driven prompts. * Expanded Data Product Management: Added support for reference attributes in Data Product Management (DPM). * Snowflake RBAC Alignment: Updated Snowflake RBAC enforcement to align with Snowflake's latest security requirements and deprecations. * Improved Dremio Connectivity: Enhanced Dremio JDBC connectivity with project-level selection support. *** #### Bug Fixes * Resolved duplicate API calls and incorrect labeling in the TrustAI interface. * Improved reliability for Azure-hosted deployments, including Key Vault integration. * Fixed an attribute synchronization job failure. * Fixed missing Databricks workspace alerts caused by duplicate policies. * Resolved high-severity UI issues, including SSO tenant handling and refresh behavior. * Fixed a scheduler error in the policy synchronization service. * Fixed a stability issue affecting users who belong to multiple tenants. # July 2026 This release delivers full lifecycle support for Unified Lakehouse Policy across Snowflake and Dremio, extends TrustAI with Databricks Genie and introduces MCP Gateway Passthrough Option — along with a redesigned policy creation experience and dozens of reliability improvements. **Feature List** * Unified Lakehouse Policy (ULP): Full RBAC + ABAC Row-Level Security Lifecycle * New Access Policy Creation Wizard * MCP Gateway Passthrough Option * Intent-Based Access Control (IBAC) for AI Agents * TrustAI: Databricks Genie Support and Faster Prompt Response Times * Microsoft SharePoint & Work IQ MCP Integration * Compliance Framework Tagging in Guardian Agent Risk Findings * Relationship-Based Access Control Enhancements *** #### New Features & Enhancements **Unified Lakehouse Policy (ULP)** **Full Policy Lifecycle Across Snowflake and Dremio:** Unified Lakehouse Policy now supports the complete policy lifecycle — create, review, publish, deploy, enable, disable, and re-deploy — from a single UI and API, with policies enforced simultaneously across both Snowflake and Dremio for Iceberg-based data lakehouses. **Attribute-Based Row-Level Security:** Building on ULP's RBAC foundation, you can now also create and enforce attribute-based (ABAC) row-level security policies, using a dynamic condition builder in place of manual role assignment. A dedicated User Attributes tab makes managing attribute mappings straightforward, and user attributes are now resolved dynamically at policy evaluation time for more accurate enforcement. **Unified Catalogs Across Platforms:** New Unified Catalog and Unified Policy views let you browse data objects and policies across lakehouse platforms in one place, with objects and roles automatically mapped across Snowflake and Dremio so you can manage them under one consistent name. Schema-level privilege assignment is now supported for multi-object RBAC policies. **Automatic Sync and Drift Detection:** Access policies now sync automatically to Dremio and Snowflake data sources, and policy drift detection flags newly registered data sources that match an existing unified policy so they can be brought into sync. *** **Access Policy Creation** **Redesigned Policy Creation Wizard:** A completely redesigned, multi-step wizard now guides you through creating and managing access policies — with guided configuration, role management, a review step, and clear deployment status visibility throughout. *** **TrustAI** **Databricks Genie Support (Now Generally Available):** Guardian Agent fully understands Databricks entities — users, groups, catalogs, tables, and clusters — for rich, contextual security analysis. Genie (Databricks' AI assistant) activity is now ingested for security analysis, with natural-language understanding tuned specifically for Databricks terminology. Databricks support is now available to all customers. **Faster Guardian Agent Responses:** Guardian Agent now responds significantly faster on Snowflake environments, by integrating directly with Snowflake official MCP servers, giving more accurate answers. **Deeper Investigation:** You can now ask follow-up questions directly from Guardian Agent risk findings to investigate further without starting a new query. **Compliance Framework Tagging:** Guardian Agent responses now include inline compliance framework tags — including NIST AI RMF, ISO 42001, and the EU AI Act — directly within risk summaries and findings. *** **Intent-Based Access Control (IBAC)** **IBAC Enforcement:** Agents can now be assigned a declared purpose at registration, and that intent is evaluated before any tool call is allowed — with configurable off/monitor/enforce modes and Kill Switch behavior by default. IBAC now also extends to Microsoft Work IQ MCPs, including SharePoint. *** **MCP Gateway Passthrough Option** **Passthrough Option:** Register MCP servers — using passthrough authentication, where the agent's own credentials are validated and used directly against the downstream service. Each server receives its own unique gateway URL and authentication handshake, matching the downstream identity provider. *** **Microsoft Ecosystem Integration** **SharePoint/OneDrive/Teams & Foundry Support:** TrustAI's policy fabric now supports Microsoft 365 MCP servers, with server- and tool-level policy enforcement on SharePoint access by Foundry agents. *** **Relational Based Access Controls** **Filter by Employee/Manager:** ABAC now supports filtering by employee name and manager for easier navigation. **Required Attributes:** Administrators can mark attributes as required and manage them through an improved slide-panel dialog.\ \ **Expanded Governance Capabilities:** Extended entitlements transparency, Guardian Agent-driven auditability. # 2026 Q2 Releases # June 2026 A special thank you to everyone who joined us at [**Snowflake Summit 2026**](https://info.trustlogix.io/e3t/Ctc/5F+113/d2v55G04/VW2f_H6cdCYQW5TZ2Fs5CFjTSW6fpr4J5QN6SrN1MKF-g5kvg8W6N1X8z6lZ3mhW48WrkL3tLQ00W2-rxdY1dBvjzW5hjPBJ7Mtw_3W2Pd8C31ZhmTXW8zqK5t3drV5PW4kQ7yM25z6lCN1xjjWfVFMvSW4fPV0D75bp24W1QlzPp5Gz_BlW3LXB_n6gw2m5N3lD7dTl_PBrW6y8vMF56ns_tW58HDKf5tLdM4W3ghzM48mLWmCW3P2Dpn3syY2TW22MqG255cmxrW4rp4BV4s7XBMN8Tcg4FdhXThW8_TnK68sr87hVF-SBY83rYmFV5TdWz1rXGKgW8CtT8C3SjXBmN5v_JtHhl9k7W6xZD496Vv757W7lF-WD8H_7cSW5P4w3k2vbbh2N2FHzqvpRtZ-W2jq7Ry2xxzfwW5DzDsX4l7Xg0W4G_Kr7730jzGW97ZvCH8m31fGW8w0P6M31YDfhW75zR8359D9VDW1btB0T7-1jxLN6zS94gt45j6W3Y-nvP96FVl8W3ht5wQ98Dvq0W6dY0HV2C30jTf6P6rdd04).and [**Databricks Data + AI Summit**](https://info.trustlogix.io/e3t/Ctc/5F+113/d2v55G04/VW2f_H6cdCYQW5TZ2Fs5CFjTSW6fpr4J5QN6SrN1MKFZ-5nR3bW69t95C6lZ3kqW5-XNmV5lkmYpW24Nf3S65kGhPW5YYMJk8p4z6ZW2Z_pDD5L9gK7Mvy3ND2qlVJW43y3Yh1N-P2TW2jndl53LsRPtMjLcsgPbpbKMQrSk_X1-z9W2BBQfS8DSj-3F5BPH3MgnP8W8kBsm84xT_DLW3pF2Rx1qss0bW8Gtqm13F3pZ0W4r3Dlc5cnyjQW7hkmGt2BXjxcW34hVs_5v9RdqW3XcXT37B-9hTVfhk207210ZdW47mK848Qc-6sW2ssRk62_-J_nW2Pdv0X3bgwM4W3l9Hhv17RHrhW2KZVFN6S4WGDVg_tqN7S6W5xW41c2y13JHKwCW1d39Bm6RsyjFW4RKmpK90YyGnV4v90V83kT9yW6QgHdz5Yv59GW7h99Mm1Hv5ZxW1HFhXC4RrRl7W8DHwQG3B-BF_W56yqX04_Dm2VW8JP9Wy4LBK4WW50SMzN4Lkpsnf68BXyq04). We appreciated the opportunity to connect, exchange ideas, and have meaningful conversations about the future of AI data security and governance. We are thrilled to announce the enhancements to the current **Guardian Agent**, our next-generation security agent and a conversational security expert designed to revolutionize how you manage security, compliance, and data governance. With the June release we announce Dremio as a first-class supported data source system. #### Feature List * Guardian Agent Overview and Enhancements * RBAC and ABAC support for Dremio * Privilege Reduction * Data Bricks Workspace Management * RBAC Support for Databricks AI Apps * Risk Detection
### New Features & Enhancements #### **Guardian Agent** **TrustAI Guardian** is an autonomous security layer offering a **natural-language interface to identify, prioritize, and remediate data risks** for users, service accounts, and AI agents. In this release we have significantly improved the features and performance of the Guardian Agent. TrustAI Guardian Agent is now built as a **multi-agent system**, not a single copilot or rules engine and provides the following benefits to CISO: * **Continuous reasoning:** Agents can correlate identity, data sensitivity, behavior, and policy over time. * **Autonomy with guardrails:** Move from alerts to recommendations to controlled remediation. * **Scalability:** Match the velocity of AI agents and automated access. * **Explainability:** Convert low-level telemetry into human-understandable narratives. * **Automated Compliance:** Stay ahead of evolving regulations with built-in governance mappings, from traditional standards (**GDPR, SOC2, NIST CSF**) to cutting-edge AI frameworks (**ISO 42001** and the **EU AI Act**). {% embed url="" %}
### New Features & Enhancements #### Dremio Support * **RBAC and ABAC Support for Dremio:** We are proud to introduce Dremio as a fully supported, first-class data source. We now deliver the same granular security and policy management you use for Snowflake and Databricks directly to Dremio. Easily build and enforce role-based (RBAC) and attribute-based access controls (ABAC) across your entire data ecosystem without changing your workflow. {% embed url="" %} * **Privilege Reduction:** Enhanced our security posture by minimizing the required permissions for service principals. Specifically, we have eliminated the 'account admin' requirement for Databricks service principals and the 'manage grant' requirement for Snowflake roles, allowing policies to be enabled at the workspace level. * **Databricks Workspace Management**: Introduced data source-level workspace selection indicating what metrics are shown across all workspaces.
* **RBAC Support for Databricks AI Apps**: Added role-based access control policies for Databricks Apps, enabling differentiated access for administrators, developers, and end users through group-based permissions integrated with Okta and managed through enhanced backend APIs, Trustlets, and policy management workflows. {% embed url="" %} **Risk Detection**: Four new out-of-the-box risk detector rules identify agents inheriting excessive permissions from users, such as running with account admin roles: > * **Sensitive Data Exposure:** Are agents accessing any PII or sensitive data? > * **Excessive Permissions:** What over-privileged permissions are agents deriving from a user’s historical usage? > * **Data Exfiltration:** Are agents performing unauthorized data movement or exfiltration activities? > * **Compliance Violations:** Are any agents breaching jurisdictional data residency regulations?
#### **June Edition:** [Adaptive Governance: Keeping Data Access in Sync with Your Evolving Organizational Hierarchy.](https://www.trustlogix.ai/blog/adaptive-governance-keeping-data-access-in-sync-with-your-evolving-organizational-hierarchy?utm_source=hs_email\&utm_medium=email&_hsenc=p2ANqtz-8jKT7ZqBD01gBN_8Mgkl6SYH67PheZq9dmOT7M3c-0PGsCxWw2U9QoormZ3CrmQnV2SGZz) Each month, we select one critical piece of research or news to help you stay ahead of the curve. # May 2026 |

In May 2026 release notes:

  • Attribute Sync
  • New Privilege Template for Shared Objects in Snowflake
  • Policy Naming Consistency
  • Partial Policy Deployment Visibility (Snowflake)
  • Enhanced Risk Summary Reporting
  • Multi-Format Report Downloads
  • Enhanced Security Intelligence for On-Prem SQL Server & Oracle
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|

TrustAccess Features & Enhancements

  • Attribute Sync: Improved reliability and performance of attribute synchronization for more consistent policy evaluation.
  • New Privilege Template for Shared Objects in Snowflake: Introduced support for creating privilege templates for shared databases using a new SHARED\_DATABASE object type, enabling policies to be scoped specifically to shared database resources.
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | {% embed url="" %} |

UI Enhancements

  • Policy Naming Consistency: Standardized naming validation across UI and API to reduce confusion.
| | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
|

Bug Fixes

  • Partial Policy Deployment Visibility (Snowflake): Helps teams quickly identify and fix missing grants during policy deployment, avoiding confusion and manual debugging. Technically, updates the UI and API to mark partial deployments and display skipped grants for accurate remediation.
| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|

TrustDSPM Features & Enhancements

  • Enhanced Risk Summary Reporting: Adds risk summary dimensions such as risk counts by connection, closed items over time, average risk age, and time-based trends, with reports available for download 5 minutes after generation.
  • Multi-Format Report Downloads: Supports ZIP download with both PDF and XLSX formats for risk reports.
| | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | {% embed url="" %}
|

TrustAI Features & Enhancements

Guardian Agent

  • Enhanced Security Intelligence for On-Prem SQL Server & Oracle: Guardian Agent delivers more precise and actionable security insights for SQL Server and Oracle environments, enabling security teams to quickly identify risks such as over-privileged access and take action with confidence.
| | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|

May Edition: In the MCP era, security and governance must move at the speed of the model by securing every prompt, every retrieval, and every insight.

Each month, we select one critical piece of research or news to help you stay ahead of the curve.

| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | # April 2026

TrustAccess

|

New Feature and Enhancements

  • Risk-Based Adaptive Authorization: Inline with the trends in the security industry, we are excited to introduce a dynamic approach to access control that replaces "all-or-nothing" in policy conditions. TrustLogix is evolving from static access rules to Adaptive Authorization. By continuously evaluating identity risk, the platform now automatically adjusts data access permissions in real-time based on risk threshold and risk score.
| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Copy of Copilot (3)
|
  • Seamless Entitlement Integration: We have enhanced the attribute-based access control (ABAC) policy to pull "group membership" in real-time from Microsoft EntraID and use it for dynamic enforcement.
| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Copy of Copilot (4)

TrustDSPM

|

New Feature and Enhancements

  • Suppress Data Risks: With this release, we have enabled suppression of repetitive data risks and related alerts while keeping the associated monitoring policy active. Repetitive Data Risks that need to be ignored for a certain time period can now be suppressed. To enable this feature, please contact customer success team.
  • Extended DSPM to On-Prem databases: TrustLogix DSPM supports SQL Server, Oracle, and MySQL. These on-prem integrations now include advanced exclusion criteria, enabling you to fine-tune your data risk monitoring by filtering out non-essential assets.

Bug Fixes

  • Alert Deduplication: Resolved an issue where multiple alerts were being generated for a single Snowflake login event due to multiple concurrent sessions. The system now consolidates all concurrent sessions from a single login into a single and comprehensive alert.
| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

UI Enhancements

|

New Feature and Enhancements

  • Enhanced User Experience: We’ve redesigned the UI to be more intuitive. A new collapsible left-hand menu organizes features by product, while a collapsible right-hand panel keeps your recent activity and completed tasks visible but out of the way. We’d love to hear your feedback on these usability improvements.
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Copy of Copilot (1)

Security Spotlight - April Edition

|

This Month's Hand-Picked Insight by TrustLogix: After the Claude Code Leak—Why a "Kill Switch" for AI agent data access is now an enterprise essential.

Each month, we hand-select one critical piece of research or news to help you stay ahead of the curve.

| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | # 2026 Q1 Releases # Mar 2026 |

Data Access Governance & Policy Management

New Feature and Enhancements

  • Ease of Attribute Assignment for Policies: Added a powerful feature for the business users to copy attribute values from a specific user to multiple users.
| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Copy Attribute Values
|
  • Hierarchical Attribute Support: ABAC access policies now support conditional evaluation to match values dynamically at the Same node, Parent, Child, or Parent + Child.
  • Additional Operators for Policy Building: Enhanced the ABAC policy builder by adding IN and NOT IN to the existing operators for Snowflake and Databricks.
  • UI Guidance: Added Info icons within the ABAC policy builder to describe dimension attribute filters.
  • Deployment Resilience: RBAC template policies now support handling failed grants during delta deployments.
  • Enhancement to Setting up Privilege Template: Any new object types and new privileges launched by Snowflake or Databricks are automatically shown at the time of setting up the privilege template

  • Power BI Integration: Enhanced Power BI support to handle invalid semantic models gracefully.

Bug Fixes

  • UI Consistency: Revamped the RBAC access policy governance interface to align with the ABAC UI for a unified user experience.
| | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Data Security Posture Management (DSPM)

New Feature and Enhancements

  • Geo-Based Monitoring: Added support for location-based monitoring policies across Oracle, SQL Server, and MySQL platforms.
| | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Geo based Monitoring Policies
|
  • Automated Maintenance: New scripts to automate updates for on-prem host AWS cloud parameters.
  • Ingestion Optimization: Enhanced Oracle and SQL Server performance to handle millions of audit events efficiently.
  • Near Real-Time Monitoring: Enabled near real-time monitoring policies for Oracle and MySQL.
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
Near Real Time Monitoring
|

Guardian Agent (Preview)

  • Enhanced Reporting and Auditability: Trust AI Guardian now allows customers to use AI security prompts and download results providing clear audit trails and actionable reports.
  • Cloud Deployment: Support for Trustlet cloud-based Guardian Agent deployment.
  • Snowflake Cortex Integration: Guardian Agent now supports answering prompts for Snowflake Cortex agent activities.
| | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | # Feb 2026 **Data Access Governance & Policy Management** * **Power BI Access Policy Improvements**: Our latest enhancements for Power BI integration streamline data access governance and policy deployment. The introduction of Virtual Attributes allows for including third-party dimension columns in policy creation without storing the values in entitlement tables. Furthermore, Power BI Multi-Object Selection boosts efficiency, enabling policy administrators to deploy a single data access policy across multiple objects within the same semantic model, ensuring consistent and rapid policy enforcement. * **Snowflake DBT and Intelligence Access Template:** Custom data access policy templates can be created on Snowflake DBT projects as well as on Snowflake Intelligence Objects. * **Multi-Environment Data Source Management**: Simplify policy administration across your development lifecycle. This new feature enables the creation of multiple Snowflake and Databricks data sources from a single cloud connection, supporting separate, environment-based databases (e.g., Dev, QA, and Prod). This ensures consistent, environment-specific policy enforcement and streamlined governance **AI Security (Preview)** The introduction of TrustLogix AI Guardian (Preview) marks a shift toward AI-assisted data security, allowing your team to query complex risks using natural language * **Enhanced Reporting and Auditability:** **Trust AI Guardian** now allows customers to download security prompt results as a report, providing clear audit trails and simplifying compliance efforts for AI-driven interactions. * **Broader Platform Coverage:** **Trust AI Guardian** has extended its support to critical data platforms, including **SQL Server**, offering a comprehensive set of security prompts to protect sensitive data within these environments. ### Trust Application (Preview) * **Auditability and Flexibility:** We’ve introduced an Audit Report for Application Access that logs all 'allow' and 'deny' decisions, enhancing monitoring and compliance. Application Access Governance now includes visible REGO policy definitions for greater transparency. * **Expanded Attribute Sourcing:** Multi PIP Source Support Azure as the Policy Information Point capabilities beyond the Snowflake table to be configured as an attribute source, which enables the policy evaluation to fetch the real-time values which providing greater flexibility and dynamic evaluation of policy conditions. **Data Security Posture Management (DSPM)** We have enhanced our reporting suite to provide executives and auditors with clearer evidence of a "Zero Trust" data posture. * **Improved Monitoring and Access Visibility:** The Data Risks page now features **User Type Filter Support** (Human vs. Service Type) for more targeted risk analysis. **Access Analyzer** has been enhanced with search functionality to efficiently manage very large user sets. * We've also added **SQL Server Separation of Duties Monitoring**, enabling the monitoring and blocking of SQL Server user logins based on a defined allow list. * **Enhanced Reporting and Alert Customization:** **On-Demand Report Execution** is now available, providing ad hoc report triggering for various audit and compliance reports (e.g., Entitlement and Secured Objects reports). * We have also updated the alert delivery workflow to support **Custom Email Alert Timing**, allowing you to receive security notifications at your preferred time **Platform & UI Improvements** * **Enhanced Data Domain User Mapping:** We've improved the domain list to clearly show all TrustLogix users associated with each domain and introduced new filtering options for simpler, more accurate user-domain determination. * **SCIM Token Administration:** You can now easily regenerate Azure AD and Okta Single Sign-On (SSO) tokens directly from the Single Sign On page, streamlining your security administration tasks. # Jan 2026 **Data Access Policy Enhancements** * **Object Sync Enhancement** – All the informational messages related to Object Sync are now displayed in the notifications feature. Reference image : * **Object Sync Impacted Objects List** – Object Sync button displays the list of all impacted objects within the data source as part of the sync process. * **Databricks Registration Enhancement** – Support for registering multiple Databricks workspaces is now supported within the same notebook script. * **Policy Admin Reports** – Policy admins can now download various audit and compliance reports based on the databases that are accessible to them within the data source. * **Snowflake OAuth Support for Object Sync Service** – Object sync service now supports OAuth for the Snowflake data source. * **Incremental Grant Support in Access Policies** – Redeployment of ABAC policies will generate GRANT/ALTER statements only for the delta objects going forward. * **Tag Migration and Policy Promotion Scripts Enhancements** – Tag migration now extracts the object-level and column-level tags used in a particular policy, validates or creates the required tags and allowed values on the target data source. * **SCIM Token Regeneration** – Regeneration of Azure AD and Okta SSO token is now available within the Single Sign On page. ![](/files/UFDh34drlNTwXnCCwawc) **Data Security Posture Management Enhancements** * **Copilot** **LiteLLM Support** – Copilot Agents supports communication with different LLM models using [LiteLLM](https://docs.litellm.ai/docs/simple_proxy) Proxy. * **Copilot Databricks and SQL Server Support** – TrustLogix Copilot (*Preview*) now supports various security prompts for Databricks and SQL Server. * **Access Analyzer Enhancement** – Search for a particular user in a very large user set is now provided within Access Analyzer. * **User Type Filter Support** – Human vs Service Type user filter is now displayed in the Data Risks page. This will let the user filter for data risks pertaining to Human or Service Type users as defined in the monitoring policies. # 2025 Q4 Releases # Dec 2025 **Data Access Policy Enhancements** * **SailPoint Integration** – TrustLogix now supports SailPoint as an Attribute Source. * **Tag Migration Utility Scripts** – Snowflake and Databricks tag migration utility scripts are now available under the utility scripts configuration. * **Okta Integration** – Automatic user provision and deprovision through Okta application is now supported. Reference : * **Object Sync Feature** – On demand button added to support ad hoc sync of Snowflake objects with respect to data access policies. Reference image : * **Power BI Access Governance** – Azure Entra groups are now supported in the Power BI access policies. * **Azure Attribute Sync** – Additional Azure attributes like "onPremisesSamAccountName" and "onPremisesLastSyncDateTime" are now supported in the attribute sync service. * **Access Policy Secured Objects Report** – Report to display all the objects that have been secured is now available under the reports section. Reference image : * **Snowflake Key Pair Authentication Alert** – Alert for rotating the Snowflake RSA keys that are older than 90 days and used for authentication is now visible in the notifications feature. * **Release Information** – TrustLogix component releases are now shown in the UI under the notifications feature. Reference image : **Data Security Posture Management Enhancements** * **Copilot** – Copilot feature is available in preview mode to generate various security risk insights based on user prompts. * **Monitoring Policies** – Additional monitoring policies to discover any alter or modifications to TrustLogix access policies are now available. * **Snowflake Cortex Agent Activity Policies** – TrustLogix now supports Cortex Agent activity based monitoring policies. * **Databricks Access Analyzer** – Access Analyzer feature is now available for Databricks. This feature will show both the Databricks user and group based grants and relationships. * **Oracle and SQLServer Audit Optimization** – Additional audit optimizations to support auditing for sensitive databases and tables is now supported. # Nov 2025 **Data Access Policy Enhancements** * **Agent Access Governance** – TrustAI feature in preview to implement AI Agent-specific resource access policies to control the data access for end users via AI Agents. * **Application Access Governance** – TrustApp feature in preview to try out resource-specific access management by applications. * **MCP Service** – TrustLogix MCP server preview for consumption with OAuth based authentication. **Data Security Posture Management Enhancements** * **Activity Reporting** – Entitlement Report fixes to handle multiple user selections across databases, schemas etc. * **Monitoring Policies** – Addition of “Mute policy” feature to the monitoring policies across all the data sources which will pause the execution of a certain monitoring policy. * **Monitoring Policies** – Improved data monitoring policy UI layout to maintain consistency with the access governance UI. # Oct 2025 **Data Access Policy Enhancements** * **Power BI Governance** – Rolled out "Delegation Admin" capabilities for granular administrative control. This includes policy administration by workspace. * **Access Governance Object Sync** – On-Demand sync services and APIs for common sync services to streamline policy enforcement. * **Entitlement Expansion** – Entitlement data APIs to fetch roles and privileges based on database/schema/object access. * **Attribute Migration Feature** – Download of migration scripts directly from the console and performing attribute migration from one environment to another. **Data Security Posture Management Enhancements** * **Activity Reporting** – Enhanced User Activity Reports with advanced filtering capabilities and a new option to generate reports directly from the access policies page. * **Monitoring Policies** – Addition of new policies to detect for "User Enumeration" attacks and detection of table tagged as sensitive in the backed up table list. # 2025 Q3 Releases # Sept 2025 **Data Access Policy Enhancements** * **Tag Management Expansion** – Oracle and MySQL now support tag-based management. * **Policy DB Flexibility** – Support for multiple TrustLogix policy databases across different Databricks workspaces. * **ABAC Policy Enhancements** * Import conditions directly into ABAC policies * Hierarchical attribute support in condition builder * Automatic rollback to the previous state if redeploy fails * RBAC/ABAC Policy-Object synchronization support for object lifecycle * **RBAC/Privilege Enhancements** – Grant options are now available in access policy privilege templates. * **UDF Functions** – UDF Functions can be mapped and used in the condition builder for policy definition. **Data Security Posture Management Enhancements** * **Unusual Login Detection** – Monitoring policies now detect suspicious logins, including failed attempts by disabled users and logins outside business hours. * **Snowflake Sensitive Data Protection** – Query text ingestion now supports redaction of sensitive data, ensuring compliance and privacy. * **On-Prem MySQL Audit Support** – Extended audit capabilities to on-prem MySQL databases. * **Expanded Entitlement Reports** – Support for "All Users" selection, plus Azure-based entitlement reporting for hybrid cloud customers. * **User/Group/Role Enhancements** – Improved entitlement visibility across databases and hybrid environments. # Aug 2025 **Data Access Policy Enhancements** * **Snowflake & Databricks Access Policy Enhancements**\ Improved support for domain and product features, making policy management more domain owner-driven and consistent access policies across platforms. * **Role and Attribute based Access Control Policy Alignment**\ Role based access grants are now automatically revoked when an attribute access policy is deleted or deactivated which reduces access risk and admin time. * **Multi-Database Support for Databricks**\ Customers can now manage multiple Databricks catalog access using a single policy for their Databricks accounts. * **Policy Condition Builder Enhancements**\ A more intuitive condition builder makes policy authoring faster and less error-prone. Includes converting regular conditions into nested conditions, creating a duplicate of conditions for faster implementation. * **Power BI Access Policy Enhancements**\ Improvement in the policy condition building to support multiple data and user attribute criteria and also to support nested conditions. **Data Security Posture Management Enhancements** * **Improvement in Integrations UI**\ Create and manage Slack and Email tools using integration user interface. * **SQL Server & Oracle Audit Enhancements**\ Expanded audit coverage and SoD(Separation of duties) updates provide stronger compliance and monitoring capabilities. # July 2025 **Data Access Policy Enhancements** * **Attribute Management Embedded in Data Source Page**\ User attribute management is now available directly within each data source’s page, streamlining configuration workflows. * **Hierarchical Attributes – Leaf Node Identification**\ Attribute Management now clearly indicates leaf nodes in hierarchical user attributes, improving clarity in attribute-driven policy evaluation. * **GitHub Integration for Policy CI/CD**\ Support for Azure CI/CD pipelines through GitHub enables automated policy promotion and DevSecOps integration. * **AI/ML Policy Templates**\ Out-of-the-box policy templates are now available for AI/ML datasets, helping accelerate secure access control in data science environments. * **Improvements to Azure AD Integration for User Provisioning**\ You can now automatically sync users from Azure Active Directory into TrustLogix roles using Graph APIs, simplifying identity management. **Data Security Posture Management Enhancements** * **SQL Server Separation of Duties (SOD) Allowlist Enhancements**\ New updates to the SOD feature allow administrators to fine-tune allowlist configurations in SQL Server environments. * **DSPM Enhancements for SQL Server and Oracle**\ Watermark-based tracking has been refined to improve data sensitivity monitoring for SQL Server and Oracle environments. * **Configurable Access Analyzer Execution Frequency**\ Admins can now easily configure how often the Access Analyzer runs, offering better control over monitoring schedules. # 2025 Q2 Releases --- [Next Page](/llms-full.txt/1)