ABAC Conditions

ABAC (Attribute-Based Access Control) conditions let you add fine-grained rules to any policy. A condition compares attributes from the subject, resource, or request context at evaluation time.

A policy with conditions only grants access when all active conditions pass. If any condition fails, the policy does not match — even if the subject, action, and resource match.

Conditions shape

All conditions are stored as a single flat JSON object on the conditions field of a policy. Each key in the object is an active guardrail or attribute check:

{
  "conditions": {
    "subject_attrs": [
      { "attr": "department", "op": "==", "value": "engineering" }
    ],
    "resource_attrs": [
      { "attr": "classification", "op": "==", "value": "internal" }
    ],
    "time_window": {
      "start": "09:00",
      "end": "18:00",
      "days": ["mon", "tue", "wed", "thu", "fri"],
      "tz": "UTC"
    },
    "ip_allowlist": {
      "cidrs": ["10.0.0.0/8", "172.16.0.0/12"]
    }
  }
}

Any key you omit is not evaluated. You can mix attribute checks and guardrails in the same conditions object — all present keys must pass.

Attribute conditions

Attribute checks compare a stored or request-time attribute on the subject, resource, or request context.

subject_attrs

Checks attributes on the subject (user, service, agent).

{
  "conditions": {
    "subject_attrs": [
      { "attr": "department", "op": "==", "value": "engineering" },
      { "attr": "clearance", "op": ">=", "value": 3 }
    ]
  }
}

Each row: { "attr": "<key>", "op": "<operator>", "value": <rhs> }. All rows are ANDed.

Dot-path support: attr can traverse nested objects using dot notation. "attr": "manager.region" reads subject.attributes.manager.region. Up to four levels of nesting are supported.

resource_attrs

Checks attributes on the resource being accessed.

{
  "conditions": {
    "resource_attrs": [
      { "attr": "status", "op": "==", "value": "published" },
      { "attr": "region", "op": "in", "value": ["us-east-1", "us-west-2"] }
    ]
  }
}

context_attrs

Checks keys passed in context at evaluation time.

{
  "conditions": {
    "context_attrs": [{ "key": "env", "op": "==", "value": "prod" }]
  }
}

Note the field name is key (not attr) for context rows.

Operators

Operator	Meaning
==	Equal
!=	Not equal
>=	Greater than or equal
<=	Less than or equal
>	Greater than
<	Less than
in	Value is contained in the given array (value must be an array)
not_in	Value is NOT in the given array (value must be an array)

Type coercion: if the stored or request attribute is a number or boolean but the policy stores the value as a string (which the dashboard does), Vengtoo coerces automatically — 5 >= "3" and true == "true" both work as expected.

Missing attributes fail closed: if the attribute is absent from the request, the condition fails and access is denied. Pass the relevant values in subject.attributes / resource.attributes in your evaluation call.

Guardrails

Guardrails are additional gates configured via the dashboard's Active policy rules panel. They live in the same conditions object alongside attribute checks.

Key	Controls
time_window	Policy only matches within a configured time range
ip_allowlist	Policy only matches when context.ip is in an allowed CIDR
geo_restriction	Policy only matches when context.geo is an allowed country code
mfa_required	Policy only matches when a specified claim is truthy on the subject or context
trust_level	Policy only matches when the subject meets a minimum trust tier
rate_limit	Policy only matches when the subject hasn't exceeded a request rate
requires_human_approval	Policy triggers an approval workflow before granting access

See the guardrails section of Policies for the shape of each key.

Examples

Department-scoped access

Allow users to read documents only when their department attribute matches:

{
  "conditions": {
    "subject_attrs": [
      { "attr": "department", "op": "==", "value": "engineering" }
    ],
    "resource_attrs": [
      { "attr": "department", "op": "==", "value": "engineering" }
    ]
  }
}

Both checks must pass.

Clearance-level gating

Only allow access when the subject's clearance level meets the threshold:

{
  "conditions": {
    "subject_attrs": [{ "attr": "clearance_level", "op": ">=", "value": 3 }]
  }
}

Multiple attribute checks (all must pass)

Allow admin access only for senior engineers in the platform team:

{
  "conditions": {
    "subject_attrs": [
      { "attr": "level", "op": ">=", "value": 5 },
      { "attr": "team", "op": "==", "value": "platform" }
    ]
  }
}

Nested attribute

Check a nested subject attribute (e.g., subject.attributes.manager.region):

{
  "conditions": {
    "subject_attrs": [
      { "attr": "manager.region", "op": "==", "value": "us-east" }
    ]
  }
}

Attribute check + guardrail combined

Only allow reads by engineering subjects during business hours:

{
  "conditions": {
    "subject_attrs": [
      { "attr": "department", "op": "==", "value": "engineering" }
    ],
    "time_window": {
      "start": "09:00",
      "end": "18:00",
      "days": ["mon", "tue", "wed", "thu", "fri"],
      "tz": "UTC"
    }
  }
}

In the evaluate request

Pass the relevant values in subject.attributes and resource.attributes. Conditions read these fields directly — use attributes, not properties, for conditions to match:

{
  "subject": {
    "external_id": "alice-uuid-from-your-db",
    "type": "user",
    "attributes": {
      "department": "engineering",
      "level": 5,
      "team": "platform"
    }
  },
  "resource": {
    "external_id": "wiki-uuid-from-your-db",
    "type": "document",
    "attributes": {
      "department": "engineering",
      "classification": "internal"
    }
  },
  "action": { "name": "read" }
}

Stored subject attributes (set via the Management API) are also available to conditions — see Context Trust Model for how request and stored values interact.

Where attributes come from

Resources — attribute definitions are declared on the resource type (e.g., classification: string, department: string). When you create a resource of that type, those fields appear as fillable attributes. Stored values are included in the policy bundle and available to resource_attrs conditions automatically.

Subjects — there is no owning type that enforces a schema. Subject attribute definitions are declared globally (under Schema → Subject Attributes in the dashboard), and each subject gets a freeform attributes section. Stored values are included in the bundle and available to subject_attrs conditions automatically.

Passing attributes inline — you can also pass subject.attributes and resource.attributes directly in the evaluation request. This is useful for attributes that aren't stored in Vengtoo (e.g., a session-computed risk score). Request-time values are merged with stored values, but stored values win on conflict — a caller cannot override an attribute that is already set in the Vengtoo control plane.

Related

• Policies — Policy structure, assignment, and guardrails.
• Context Trust Model — How Vengtoo decides which attributes to trust.
• Authorize Access — The /access/v1/evaluation request shape.