Governance Overview
Datafi enforces data governance through a defense-in-depth strategy. Rather than relying on a single checkpoint, every query passes through multiple independent security layers before any data leaves the platform. If one layer is misconfigured, the remaining layers continue to protect your data.
Defense-in-Depth Layers
The following diagram illustrates how a request traverses each governance layer from the moment it arrives to the moment results are returned.
Layer 1: Role-Based Access Control (RBAC)
RBAC determines what resources a user can access based on their assigned role. Roles are attached to users at the tenant or workspace level and govern broad categories of access such as viewing datasets, managing agents, or administering tenant settings.
| Role | Datasets | Agents | Admin |
|---|---|---|---|
| Viewer | Read | Run | None |
| Editor | Read, Write | Run, Create | None |
| Admin | Full | Full | Full |
Layer 2: Attribute-Based Access Control (ABAC)
ABAC refines access decisions using contextual attributes such as tags, field metadata, user properties, and environmental conditions. While RBAC answers "can this role access datasets?", ABAC answers "can this user access this specific dataset given the current context?"
Attributes evaluated include:
- User attributes -- department, clearance level, geographic region
- Resource attributes -- data classification tags, sensitivity labels
- Environmental attributes -- time of day, source IP range, device posture
Layer 3: Query-Level Security
Before any SQL statement executes against your data sources, Datafi performs SQL introspection. The query is parsed and every referenced table and column is validated against the requesting user's permissions. Unauthorized queries are rejected before they reach the database.
Layer 4: Row-Level Security (RLS)
Even after a query is authorized, RLS filters control which rows the user can see in the result set. Rows that fall outside the user's permitted scope are handled according to configurable filter types -- they can be omitted, blanked, masked, or randomized.
How the Layers Work Together
Consider a practical example:
- A user with the Editor role submits a query against a customer dataset.
- RBAC confirms that Editors have Read access to datasets.
- ABAC evaluates the dataset's
pii:sensitivetag against the user'sclearance:standardattribute and permits read-only access. - Query-Level Security parses the SQL, confirming the user may query the
customerstable but not thessncolumn. The query is rewritten or rejected accordingly. - RLS filters the result set so the user only sees customers in their assigned region.
Policy Evaluation Order
Policies are evaluated in a deterministic order. An explicit Deny at any layer overrides any Allow at the same or lower layer.
RBAC Allow → ABAC Allow → Query Allow → RLS Filter → Result
↓ ↓ ↓
Deny Deny Deny → 403 Forbidden
Start with restrictive defaults and explicitly grant access. Datafi follows a deny-by-default posture -- if no policy explicitly allows an action, the request is denied.
What to Read Next
- Access Policies -- learn how to define policy rules, conditions, and effects.
- Row-Level Security -- configure RLS filter types for fine-grained row control.
- Query-Level Security -- understand SQL introspection and column-level validation.