Role-based (RBAC)
Good for coarse gates (“finance team”, “admin”). Weak when two people share a role but should see different customers, departments, or patients.
Decide who may see which rows by how they connect in the graph—not only by job title or a single “can read everything” flag. AnythingGraph encodes those rules in playbooks and enforces them when people and AI query your data.
ReBAC stands for relationship-based access control. Instead of asking only “Does this user have the HR role?”, you ask “Is this user related to this row in a way the business allows?”—for example, manages that department, owns that account, or is the attending clinician for that patient.
Permissions follow paths in your data: employee → department → manager, opportunity → account → sales rep, clinical note → patient → care team. If the path from a row to the requesting person matches a rule, the row is visible; otherwise it stays hidden.
Good for coarse gates (“finance team”, “admin”). Weak when two people share a role but should see different customers, departments, or patients.
Matches how organizations actually work: territory, reporting line, clinic panel, account ownership. Same role, different slice of data—ideal for governed dashboards and AI assistants.
ReBAC is declared in an ontology playbook (one JSON pack), enforced at query time on a data capsule (a synced graph snapshot per playbook), and applied whenever a caller supplies a subject—the person or agent identity asking the question.
relationship_access_rules, you describe who the subject is (e.g. an HR user or care
provider), default deny, and allow rules using graph paths, field matches, or “only if you already see
the linked record.”
subject_id (e.g. alice.mgr,
dr.chen). The engine walks instance relationships and filters results to allowed rows
only.
run_sparql, ask_graph, and
list_allowed_rows all respect the same rules, so agents do not bypass policy with a
broader prompt.
Playbook authors combine a few patterns. You do not need to implement these in application code—they live in JSON.
Walk links from the row to the subject (e.g. employee → department → manager).
Engineering manager sees employees in departments they manage.
Compare a field on the row to the subject without a hop (e.g. same email).
Employee sees their own profile when emails match.
Allow a sensitive row only if the subject may already see a linked record.
Compensation or clinical notes only when the linked person is already on the user’s panel.
Limit which subjects a rule applies to (e.g. only HR Business Partner, not every manager).
Nurses see patients in clinic; note access limited to physicians and coordinators.
Install from Playbooks, sync the data capsule, then try Graph
View or MCP with different subject_id values to see different slices.
Managers see their department; HR partners see supported departments; compensation only when the employee is already visible—Alice sees Engineering, not Sales.
Reps see owned accounts; territory managers see their region; opportunities only with prior access to the account—pipeline data stays in the right hands.
Clinicians see patients in their clinic panel; clinical notes gated by role—coordinators and attendings see notes, nurses may see patients without every note.
Author or extend rules in the playbook JSON. After changes, restart rdf-cache so rule files reload. For step-by-step authoring (paths, direction, examples), use the Playbook Cookbook.
Operational setup—install, data capsules, MCP—is in Documentation.
?row in SPARQL) so filtering can apply correctly.