Security and Access Control: Protecting the Graph

A Knowledge Graph often contains the "Nuclear Secrets" of a company: salaries, internal strategy, customer PII. If you build a Graph RAG system and an Intern asks: "Show me the path between the CEO and the secret budget," the AI might happily answer if you don't have Access Control.

In this lesson, we will look at Graph Security. We will learn how to implement Role-Based Access Control (RBAC) at the node and relationship level. We will explore Query Filtering (injecting security constraints into Cypher) and how to ensure that your LLM only "Sees" the part of the graph the specific user is authorized to access.

1. The Security Challenge: Reasoning over Secret Paths

In a vector database, security is "Document Level" (Either you can see the file or you can't). In a graph, security is Traversal Level.

A user might be allowed to see Node A and Node C, but NOT the relationship Node B that connects them.

If the AI "Walks" through Node B to answer a question, you have a Data Leak, even if the final answer doesn't mention Node B directly!

2. Strategy 1: Database-Native RBAC

Enterprise graph databases (Neo4j Enterprise, Neptune) allow you to define roles.

ROLE: FINANCE_DEPT can MATCH (n:Salary)
ROLE: MARKETING is denied all access to (n:Salary)

The Workflow: When your Python API connects to the Graph, it should connect using a User-Specific Token or a "Service Account" with the same permissions as the user. This way, the database itself will throw an error if the AI agent tries to walk into a forbidden area.

3. Strategy 2: Property-Based Filtering

If you can't use node-level security, you can use Query Anchors. Every node has an allowed_groups list.

The Filter: MATCH (p:Person)-[r]-(m) WHERE 'Sales' IN p.allowed_groups AND 'Sales' IN m.allowed_groups RETURN p, r, m

This ensures that the AI's "Context Window" is only filled with facts the user is allowed to see.

4. Encryption and Networking

Encryption at Rest: Your graph data must be encrypted on the disk.
TLS (Transport Layer Security): All communication between your LangChain code and the DB must use encrypted Bolt/HTTP connections (e.g., bolt+s://).
Private Link: Your Graph DB should Never be available on the open internet. It should sit in a Private Subnet (VPC) accessible only by your API servers.

graph TD
    User((User: Bob)) -->|Query| API[RAG API]
    API -->|Identify| Role[Role: Marketing]
    Role -->|Authorized Cypher| DB[(Graph DB)]
    DB -->|Filters by Role| Context[Filtered Context]
    Context --> LLM[LLM Synth]
    LLM -->|Answer| User
    
    style DB fill:#4285F4,color:#fff
    style Role fill:#f44336,color:#fff

5. Summary and Exercises

Security is the difference between a "Toy" and an "Enterprise Tool."

RBAC prevents the AI from becoming an "Internal Spy."
Security Anchors filter the graph walk by user group.
Private Networking ensures the graph is invisible to hackers.
Deny-by-Default is the only safe strategy for sensitive Knowledge Graphs.

Exercises

Security Audit: A user asks: "What is my manager's home address?". Even if the graph has the address, should the Cypher generator be allowed to query it? Where should the "Block" happen—the Prompt or the Database?
The "Bridge" Leak: Why is the shortestPath query particularly dangerous for security? (Hint: It might bridge two allowed nodes via a "Secret" node).
Visualization: Draw a graph with 5 nodes. Label 2 as "Public" and 3 as "Restricted." Draw a path from Public A to Public B that goes through Restricted C. How do you stop a "Public" user from finding this path?

In the final lesson of this module, we will look at the budget: Cost Management for LLMs and Graph Storage.