Policies that know who owns what.

The problem RBAC and ABAC cannot solve

RBAC answers "does this user have the right role?" ABAC answers "does this resource have the right attributes?" Both are categorical — they apply the same logic to every principal-resource pair that matches the condition. Neither expresses "is this specific user the owner of this specific document?"

Without ReBAC, teams work around this with role proliferation (a "doc_owner_123" role per document) or custom metadata (storing principal IDs in resource attributes and writing ABAC conditions against them). Both approaches break at scale.

How relationships work in Gateco

A Relationship is a named link between a principal (subject_id) and a gated resource (object_id), identified by a relation_name string you define. Create them via the API or SDK: client.relationships.create(subject_id=principal_id, relation_name="owner_of", object_id=resource_id).

In a policy condition, use the relation.<name> field prefix: {"field": "relation.owner_of", "operator": "eq", "value": true}. The policy engine performs a 1-hop lookup: does the requesting principal have a relationship of this name to this specific resource? No relationship means the condition is false.

Relationship lookup results are cached for 60 seconds per (org_id, principal_id, relation_name, resource_id) tuple. Any Relationship mutation — create or delete — immediately invalidates the cache for that organization, so access changes take effect on the next request.

# Python SDK — create and use a relationship
client.relationships.create(
  subject_id="user_alice",
  relation_name="owner_of",
  object_id="doc_quarterly_report",
)
# Policy condition in Policy Studio:
# {"field": "relation.owner_of", "operator": "eq", "value": true}

Composing with RBAC and ABAC

ReBAC conditions compose naturally with role and attribute conditions in the same policy rule. Example: allow when (principal.roles contains "manager") OR (relation.assigned_to eq true). The policy engine evaluates all conditions and produces a single allow/deny decision with the full evaluation trace in the audit log.

ReBAC is not a replacement for RBAC or ABAC — it fills the gap when you need per-resource principal binding. Use RBAC for categorical access (all engineers), ABAC for attribute-based ceilings (classification levels), and ReBAC for specific ownership or assignment relationships.