> For the complete documentation index, see [llms.txt](https://docs.trustlogix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trustlogix.io/trust-access/data-access-governance/attribute-based-access-policies.md).

# 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**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.trustlogix.io/trust-access/data-access-governance/attribute-based-access-policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.