Skip to main content

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.

RoleDatasetsAgentsAdmin
ViewerReadRunNone
EditorRead, WriteRun, CreateNone
AdminFullFullFull

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:

  1. A user with the Editor role submits a query against a customer dataset.
  2. RBAC confirms that Editors have Read access to datasets.
  3. ABAC evaluates the dataset's pii:sensitive tag against the user's clearance:standard attribute and permits read-only access.
  4. Query-Level Security parses the SQL, confirming the user may query the customers table but not the ssn column. The query is rewritten or rejected accordingly.
  5. 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
tip

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.