ReBAC in Gateco: Relationship-Based Access for Vector Retrieval

Role-based access control answers "does this user have the right role?" Attribute-based access control answers "does this resource have the right attributes?" Both are useful, but neither expresses the question "is this specific user the owner of this specific document?" That is a relationship question — and it is now a first-class concept in Gateco's policy engine.

How relationships work

A Relationship in Gateco is a named link between a principal and a gated resource. Three fields: subject_id (the principal), relation_name (a string you define, e.g., "owner_of", "assigned_to", "member_of"), and object_id (the resource). You create them via the API or SDK. In a policy condition, you reference the relationship with the relation.<name> field prefix: {"field": "relation.owner_of", "operator": "eq", "value": true}. This condition evaluates to true only when the requesting principal has an active relationship of type "owner_of" to the specific resource being evaluated. No relationship means the condition is false — the policy does not match — and the retrieval is denied unless another policy grants access.

The retrieval path: async evaluation and caching

Relationship conditions use the async policy evaluator rather than the synchronous path used for standard RBAC and ABAC conditions. This is because resolving a relationship requires a database lookup rather than pure attribute comparison. The lookup result is cached for 60 seconds per (org_id, principal_id, relation_name, resource_id) tuple. Any Relationship mutation — create or delete — invalidates the cache for that organization immediately, so access changes take effect on the next request rather than waiting for cache expiry.

In the ingestion context, relation.* conditions always return false. There is no resource context during document ingestion, so relationship conditions cannot be evaluated at that stage. This is documented behavior, not a bug.

Three use cases

Document ownership. A principal who created a document gets an owner_of relationship to it. Policy rule: allow when relation.owner_of is true. This works alongside classification policies — the owner can access their own document regardless of classification ceiling, while other principals are subject to the normal ABAC rules.

Assignment-based access. A support system where agents can only retrieve information relevant to their assigned tickets. When a ticket is assigned, create an assigned_to relationship between the agent and the corresponding resources. When the ticket is reassigned, delete the old relationship and create a new one — cache invalidation fires automatically.

Project scoping. A project management tool where only project members can retrieve project documentation. Create member_of relationships when someone joins a project. Policy: allow group "project_leads" OR allow when relation.member_of is true. Combine relationship conditions with role or attribute conditions in a single rule.

When to use ReBAC vs RBAC vs ABAC

Use RBAC (principal.roles contains "role_name") when access is categorical: all engineers can see internal documentation. Use ABAC (resource.classification lte "confidential") when access depends on resource properties: confidential and below is accessible to senior staff. Use ReBAC (relation.owner_of eq true) when access depends on the specific relationship between a principal and a specific resource — something you cannot express with role membership or resource attributes alone. The three models compose naturally. A single policy rule can combine role membership, resource attributes, and relationship conditions. The policy engine evaluates all conditions and produces a single allow/deny decision with the full trace logged to the audit trail.

Getting started

Create relationships via the API or SDK. Define policies using the relation.<name> condition prefix. Test them in the Access Simulator before activating — the simulator shows the full evaluation trace including which relationship lookups succeeded or failed. Relationship CRUD is available on all plans; the relation.* policy conditions require Team and above.