
Redacting Sensitive Relationships: The Stealth Graph
Hide the bridge without breaking the path. Learn how to implement 'Abstracted' relationships that allow AI agents to reason over connections without seeing the sensitive details of the link.
Redacting Sensitive Relationships: The Stealth Graph
Sometimes, the fact that a relationship exists is fine, but the Details of that relationship are secret.
- Public Fact: Sudeep is connected to Project Alpha.
- Secret Detail: Sudeep is connected to Project Alpha because he is a Board Representative for a Hostile Competitor.
If you just delete the relationship, the AI doesn't know they are connected at all. If you keep it as-is, you leak the secret. The solution is Relationship Redaction.
In this lesson, we will look at how to build a "Multi-Resolution" Graph. We will learn how to use Relationship Aliasing and Property Masking to give the AI enough "Breadcrumbs" to reason, without giving it the "Crown Jewels."
1. The Relationship Alias Pattern
Instead of one relationship, we store two:
[:PARTICIPATES_IN {detail: "Board Member"}]-> Hidden from most.[:CONNECTED_TO]-> Visible to everyone.
The Workflow:
During retrieval, the system checks the user's role. If they are Low-Clearance, the Cypher generator is strictly forbidden from using the [:PARTICIPATES_IN] type and must use the [:CONNECTED_TO] type instead. The AI still knows Sudeep is a "Key Player," but it doesn't know his specific role.
2. Property Masking (Dynamic Redaction)
If the data is on a property (e.g., (Transaction {amount: 50000})), we can mask it during the retrieval step.
The Cypher Logic:
MATCH (t:Transaction)
RETURN CASE WHEN $user_role = 'Admin' THEN t.amount ELSE '***' END as amount
By moving the logic into the Database Layer, you ensure that even if the LLM is "clever," it cannot bypass the redaction. The text it receives as context will literally contain stars instead of numbers.
3. The "Shadow Node" Strategy
For extremely sensitive data (e.g., medical IDs), we use a Shadow Node.
- Real Node:
(Patient {name: 'Jane Doe', disease: 'X'}) - Shadow Node:
(Subject_9921 {risk_score: 0.9})
The RAG system performs all its "Reasoning" on the Shadow Nodes. Only in the final millisecond, if the user is a Doctor, is the Shadow Node linked back to the Real Node to provide the name.
graph LR
Sudeep ---|Hidden: Board Rep| Alpha
Sudeep ---|Public: Connected| Alpha
style Sudeep fill:#4285F4,color:#fff
style Alpha fill:#34A853,color:#fff
note[Junior AI sees the 'Connected' link]
note[Admin AI sees the 'Board' link]
4. Implementation: A Redacting Cypher Query
MATCH (p:Person)-[r]->(dept:Department)
RETURN p.name,
// REDACTION LOGIC
CASE
WHEN type(r) = 'SALARY_MANAGER' THEN 'Management Role'
ELSE type(r)
END as relationship_type
5. Summary and Exercises
Redaction is about Abstracting Complexity to preserve privacy.
- Relationship Aliasing provides a "safe" version of a sensitive bridge.
- Property Masking ensures that sensitive numbers and names never leave the database.
- Shadow Nodes allow for "Anonymous Reasoning."
- The Principle of Least Privilege: Give the AI only the granularity it needs to answer the question.
Exercises
- Redaction Task: You have a relationship
[:BOUGHT_WITH_STOLEN_CREDIT_CARD]. What would be a good "Public Alias" for this relationship? (e.g.,[:ASSOCIATED_WITH]). - The "Inference" Risk: If you redact a name but leave a unique "Employee ID," can the AI find the name in a different (public) document? How do you prevent this?
- Visualization: Draw two nodes with two different relationships between them. Label one "High-Res" and one "Low-Res."
In the next lesson, we will look at legal frameworks: PII and the Graph: Privacy-Preserving RAG.