Access Policies

Access policies are the building blocks of Datafi's governance model. Each policy is a declarative rule that specifies who can perform what action on which resource and under what conditions. Policies apply to datasets, agents, and other platform resources.

Policy Rule Structure

Every policy rule consists of four components:

{
  "subject": {
    "roles": ["editor"],
    "attributes": { "department": "engineering" }
  },
  "resource": {
    "type": "dataset",
    "tags": ["internal"],
    "fields": ["name", "email", "created_at"]
  },
  "action": "Read",
  "effect": "Allow",
  "conditions": {
    "time_range": { "after": "08:00", "before": "18:00" },
    "ip_range": "10.0.0.0/8"
  }
}

Subjects

The subject identifies who the policy applies to. You can target subjects by:

• Role -- match users with a specific RBAC role
• User attribute -- match users whose profile attributes meet a condition
• Group membership -- match users belonging to a specific group

Resources

Resources define what the policy governs. You can scope resources by:

Scope	Description	Example
Type	The kind of resource	dataset, agent, connection
Tag	Metadata tags on the resource	pii:sensitive, env:production
Field	Specific columns or fields	ssn, email, salary
Name	Exact resource name	customers_us_west

Actions

Actions specify the operations the policy governs.

Action	Description
Read	Query or view the resource
Write	Insert, update, or modify data
Delete	Remove records or the resource itself
Run	Execute an agent or workflow

Effects

Each rule produces one of two effects:

• Allow -- the action is permitted when all conditions are met
• Deny -- the action is explicitly forbidden, overriding any Allow rules

warning

Deny rules always take precedence. If both an Allow and a Deny rule match the same request, the request is denied.

Conditions

Conditions add contextual constraints to a policy rule. A rule only takes effect when all conditions evaluate to true.

conditions:
  time_range:
    after: "08:00"
    before: "18:00"
    timezone: "America/New_York"
  ip_range: "10.0.0.0/8"
  mfa_required: true
  device_posture: "compliant"

Supported condition types:

Condition	Description
time_range	Restrict access to specific hours
ip_range	Restrict access to a CIDR block
mfa_required	Require multi-factor authentication
device_posture	Require a compliant device
geo_location	Restrict to geographic regions

Dataset-Level Policies

Dataset-level policies govern access to entire datasets or specific fields within them. You attach policies directly to a dataset, and they are evaluated every time a user queries that dataset.

{
  "resource": {
    "type": "dataset",
    "name": "customer_records",
    "tags": ["pii:high"]
  },
  "rules": [
    {
      "subject": { "roles": ["viewer"] },
      "action": "Read",
      "effect": "Allow",
      "fields": ["name", "city", "state"]
    },
    {
      "subject": { "roles": ["viewer"] },
      "action": "Read",
      "effect": "Deny",
      "fields": ["ssn", "dob", "salary"]
    },
    {
      "subject": { "roles": ["admin"] },
      "action": "Read",
      "effect": "Allow",
      "fields": ["*"]
    }
  ]
}

In this example, viewers can read name, city, and state but are explicitly denied access to ssn, dob, and salary. Admins can read all fields.

Agent-Level Policies

Agent-level policies control who can create, run, modify, and delete AI agents. Because agents can execute queries autonomously, their policies are critical for preventing unintended data exposure.

{
  "resource": {
    "type": "agent",
    "tags": ["production"]
  },
  "rules": [
    {
      "subject": { "roles": ["editor"] },
      "action": "Run",
      "effect": "Allow"
    },
    {
      "subject": { "roles": ["viewer"] },
      "action": "Run",
      "effect": "Deny",
      "conditions": {
        "agent_capability": "write"
      }
    }
  ]
}

info

When an agent executes a query, it inherits the policies of the invoking user. The agent cannot access data that the user themselves cannot access.

Policy Evaluation Flow

Best Practices

1. Start with deny-by-default. Do not create broad Allow rules. Grant the minimum access required.
2. Use tags for scalable governance. Instead of writing per-dataset policies, tag datasets with classification labels and write policies against tags.
3. Separate read and write policies. Most users need read access far more often than write access. Keep these as distinct rules.
4. Audit regularly. Review your policy rules periodically to remove stale or overly permissive entries.
5. Test with dry-run. Use Datafi's policy simulator to test rules before applying them to production datasets.