subgraph-access-control

Subgraph Access Control

Overview

An agent with unrestricted access to your knowledge graph is a liability. The dense relationships that make agentic reasoning powerful also mean a single unscoped query can traverse from a public product catalog to internal cost data to employee records. In a graph, everything is reachable from everything else.

Graph databases have mature access-control primitives. Neo4j Enterprise supports privileges at the node-label, relationship-type, and property level: you GRANT traverse rights on specific labels, DENY read access to specific properties, and combine them into role-based policies. A critical design feature is security transparency — when a role lacks permission to see a node, the node is invisible, not access-denied. The agent cannot distinguish data that does not exist from data it is not allowed to see, which blocks an autonomous agent from probing access boundaries as part of its reasoning.

This skill covers the three governance concerns from the chapter: subgraph-level access control (a role per persona, bound at connection time), PII and retention (Rehmer's Privacy-by-Architecture UUID separation with GDPR soft/hard erasure), and the execution graph as a compliance artifact (KG.GOV governance metadata that answers auditor questions as a graph query).

When to Use

• A graph-backed agent serves multiple personas (SRE, finance) who need different views of the same graph.
• You must prove which role accessed which data for a compliance review.
• The graph holds PII and you need GDPR Article 17 erasure that does not cascade across densely connected relationships.
• You are testing that an access policy does not accidentally starve the agent's reasoning (the "governance blocks the agent" pitfall).

Phrases that should invoke this skill: "who can see what in the graph", "subgraph access control", "role-based graph permissions", "GDPR delete from the graph", "PII in the knowledge graph", "compliance audit of agent decisions".