Skip to main content

​
Overview

Data Access Governance (DAG) controls access using attributes assigned to users and resources. While RBAC uses fixed roles to set the boundary of what a user can do, DAG evaluates attribute-based policies to further restrict access within that boundary. DAG enables fine-grained policies based on attributes such as:
  • Department or team membership
  • Project involvement
  • Security clearance level
DAG does not replace RBAC. RBAC sets the maximum permissions a user can have; DAG can only further restrict access within that boundary. A DAG policy cannot grant permissions that the user’s RBAC role forbids.

​
User attributes

User attributes are key-value pairs that describe who a user is. You can assign attributes directly in Sift or sync them from an Identity Provider (IdP). Examples: job role, department, employment status (employee or contractor), clearance level.

​
Resource attributes

Resource attributes are key-value pairs that describe Sift resources. DAG uses them alongside user attributes to evaluate policies. Examples: project classification, sensitivity level, compliance requirements.

​
Supported resource types

You can assign attributes to the following primary resource types:
  • Assets
  • Channels
  • Runs
Policies applied to these resources follow inheritance rules described below.

​
Access inheritance

DAG enforces access inheritance between related resources. A policy on a parent resource can affect access to its children, even if no policy targets the child directly. Channels inherit from their parent asset. If a user is denied an action on an asset, the same action is denied on all of that asset’s channels even if a separate policy allows it on the channel. The asset-level decision always wins.
Example: A deny policy blocks viewData on Asset A. Even if no policy targets Channel X (which belongs to Asset A), the user cannot viewData on Channel X.
Runs check asset access only for viewData. To view telemetry data on a run, the user must have viewData access to at least one of the run’s associated assets. If all associated assets deny viewData, the run is denied too. Other actions on runs (such as editDetails or archive) are evaluated on the run alone.

​
Attribute data types

Use Enum instead of Boolean for statuses like employment type. It is easier to add a third value (for example, “Part-Time”) to an Enum than to restructure Boolean logic later.

​
Attribute key uniqueness

Attribute key names must be unique across your organization. You cannot create two attributes with the same name, even if they have different data types.

​
Policies

Policies define the logic that governs access. Each policy specifies the user attributes, resource attributes, and actions that determine whether access is permitted or denied.

​
Evaluation model

Sift evaluates access in two layers: DAG uses a default-deny model. For a user to access a DAG-controlled resource, there must be at least one allow policy that matches. If no policy matches, access is denied.
When DAG is first enabled for an organization, a blanket allow policy is typically configured so that existing access is preserved. Specific deny policies are then added to restrict sensitive resources. Without a blanket allow, all non-admin users lose access to DAG-controlled resources.

​
Precedence

When multiple policies match, Sift resolves them using strict precedence: Example scenarios (assuming a blanket allow policy is in place):

​
Actions

Every policy must define which actions are allowed or denied. The viewDetails action serves as a prerequisite for all other operations. If a user cannot viewDetails on a resource, all other actions on that resource are automatically denied. This allows a user to be granted viewDetails (to see a resource in listings) while being denied viewData (to prevent access to the underlying telemetry).

​
Admin bypass

By default, users with the Admin RBAC role bypass DAG policy evaluation entirely. Admin access is governed solely by RBAC.

​
FAQs

​
What happens if I don’t assign attributes to a resource?

If no DAG policies target a resource, access depends on your policy configuration. With a blanket allow policy in place, the resource is accessible to anyone whose RBAC role allows it. Without a blanket allow, unmatched resources are denied by default.

​
Can I restrict access to specific Channels?

Yes. You can assign resource attributes to individual Channels and Runs, not just Assets. For example, you can allow a user to see an Asset but deny access to a specific sensitive Channel within that Asset. Note that the reverse also applies: if access to an Asset is denied, all Channels belonging to that Asset are also denied.

​
What happens if a user matches multiple policies?

Sift prioritizes security: if any matching deny policy denies access, access is denied immediately, regardless of any allow policies. Access is only granted when at least one allow matches and no deny applies.

​
Best practices

​
Step 1: plan your policy

Define the scope before configuring anything.
  • Subject: Who is affected (internal staff, contractors, systems)?
  • Object: Which resources are being protected?
  • Action: Should the policy allow or deny access?

​
Step 2: organize with groups

Apply policies to user groups, not individual accounts. Create dedicated groups for specific needs (for example, a Vendor-Access-Group). This simplifies auditing because you can remove a user from the group instead of updating multiple policies.

​
Step 3: choose the right attribute type

​
Step 4: use dual-match conditions

Require matching attributes on both the user and the resource. Example: To restrict access to Artemis Mission assets, create an intersect policy with two conditions:
  1. User has Mission = Artemis
  2. Resource has Mission = Artemis
Access is granted only when both conditions are satisfied.

​
Naming convention examples

  • PascalCase: EmploymentStatus, ClearanceLevel
  • Subject-property pattern: UserDepartment, ResourceProject
  • Boolean prefixes: IsActive, HasMFA
  • Avoid redundancy: Use ClearanceLevel, not ClearanceLevelInteger