Graph access control is the policy discipline that determines which principals may discover, traverse, read, infer from, modify, or act on nodes, properties, relationships, paths, and situations in a graph, for a declared purpose and time.
Why rows and columns are not enough #
Traditional access control starts with a resource such as a table row, file, or API object. A context graph adds relationships and multi-hop paths. A user who cannot open an investigation node may still infer that it exists because a customer node has an unusual edge count or because a summary mentions a restricted relationship.
The protected object is therefore the context returned for a decision. Authorization must determine whether each fact and relationship may participate in the assembled situation, whether its presence may be disclosed, and whether downstream reasoning or action is allowed.
Stage 1: define the graph authorization model #
Define policies at several levels: domain, entity or node, property, relationship or edge, path, purpose, operation, and time. Node controls answer whether a principal may discover or read an object. Property controls protect sensitive attributes. Edge controls protect relationship meaning. Path controls prevent traversal through restricted intermediates even when endpoints are visible.
Add decision purpose and action scope. The context needed to investigate fraud may not be appropriate for marketing. Read permission does not imply permission to export, infer, update, or trigger an action.
Stage 2: normalize source entitlements #
Source systems express access differently: groups, business units, ownership rules, case assignment, geography, consent, clearance, contractual restrictions, and row filters. Normalize these into stable policy attributes while preserving the source rule and effective time.
Do not simply copy every source ACL onto every graph object. That creates policy explosion and contradictory semantics. Instead, map source entitlements to domain policies, retain lineage, and define explicit combination rules such as intersection, union, precedence, or deny-overrides.
Stage 3: propagate permissions through relationships #
Permission propagation should be relationship-specific. Access to an account may allow access to its products and service cases but not to an employee investigation connected to the account. Ownership, membership, assignment, treatment, delegation, and legal-control edges each carry different authorization meaning.
Use explicit propagation rules with bounded depth, direction, effective dates, and stop conditions. Recompute affected permissions when relationships change, and record why a principal received access.
Stage 4: enforce at situation assembly #
The Context Harness should evaluate policy while the situation is assembled, before data reaches the consumer. It may remove properties, suppress edges, substitute an aggregated value, return a redacted object, or deny the request. The response should carry policy and lineage metadata appropriate for audit.
Controls must also apply to vector retrieval, graph algorithms, subscriptions, exports, caches, and model context. A secure graph query followed by an unrestricted generated summary is still a security failure.
Stage 5: test leakage and entitlement drift #
Test direct and indirect disclosure. Can a user infer a hidden supplier from counts? Can an agent ask repeated questions to reconstruct a restricted relationship? Can a permitted aggregate become identifying when combined with another path?
Monitor drift between source entitlements and graph decisions. Permission changes should propagate within a defined objective, subscriptions should stop immediately when access is revoked, and cached or derived context should be invalidated when policy changes.
Control framework and operating checklist #
| Access model | Best use | Main limitation | Graph requirement |
|---|---|---|---|
| Role-based access control | Stable job responsibilities | Roles become broad and numerous | Combine role with domain, purpose, and relationship |
| Attribute-based access control | Dynamic rules using identity and resource attributes | Hard to explain without policy tracing | Retain evaluated attributes and policy version |
| Relationship-based access control | Ownership, assignment, membership, delegation | Requires trustworthy and current relationships | Treat authorization edges as first-class context |
| Purpose-based control | Restrict use to declared business decisions | Purpose can be falsely asserted | Bind purpose to workflow, case, or approved tool |
| Policy-filtered situation assembly | Serve only permitted facts and paths | Requires enforcement across all query modes | Centralize in the Context Harness |
A healthcare network builds a provider and patient context graph. A clinician may see a patient’s care team and current treatment relationships, while a billing specialist may see coverage and claim context but not clinical notes. When a clinician changes facilities, relationship-based access expires on the effective date. The Context Harness filters each situation according to role, treatment relationship, purpose, and consent. An analytics service receives approved aggregates but cannot traverse back to individual patients. Every response records the policy decision and the relationships that granted access.
Common mistakes to avoid #
- Copying source permissions without defining how conflicting entitlements combine.
- Protecting nodes while allowing restricted relationships or paths to leak meaning.
- Embedding authorization in each application instead of using a common policy enforcement layer.
- Ignoring caches, embeddings, subscriptions, aggregate queries, and generated answers.
- Failing to revoke derived access when an assignment or relationship ends.
How OpenKnowra approaches this #
OpenKnowra treats this capability as part of the context operating system rather than an isolated feature. The Context Graph Engine maintains the Enterprise Digital Twin, the Context Harness applies policy and quality controls, the Decision Layer consumes governed situations, and the Execution Grid records controlled action and outcomes. The design goal is a traceable Understand-Decide-Execute loop in which context remains explainable and accountable.