Permission-aware GraphRAG: retrieval must respect access boundaries

Permission-aware GraphRAG is not just normal document authorization with a graph attached. The graph creates new ways for information to move. A user might be allowed to see a public service node, but not the private incident that explains why the service changed. They might be allowed to see a team name, but not the customer relationship that connects that team to a restricted support case.

The safest mental model is simple: every retrieved fact must be authorized, and every relationship used to discover that fact must be safe to reveal. If a traversal uses a private edge to find a public document, the retrieval path itself may leak sensitive knowledge even when the final document looks harmless.

flowchart LR
    Query["User query"] --> Seeds["Recognized seed entities"]
    Seeds --> SeedAcl{"Seed access allowed?"}
    SeedAcl -- "No" --> Stop["Stop or ask for narrower scope"]
    SeedAcl -- "Yes" --> Traverse["Traverse graph"]
    Traverse --> EdgeAcl{"Node and edge access allowed?"}
    EdgeAcl -- "No" --> Redact["Exclude path"]
    EdgeAcl -- "Yes" --> Evidence["Candidate evidence"]
    Evidence --> DocAcl{"Source document ACL allowed?"}
    DocAcl -- "No" --> Redact
    DocAcl -- "Yes" --> Rerank["Rerank allowed context"]
    Rerank --> Answer["Model answer with audit trace"]

The graph changes the threat model

Plain RAG usually starts with source documents. If the user cannot access a document, the retrieval layer filters it out. GraphRAG adds a relationship layer above those documents: entities, aliases, ownership edges, incident links, dependencies, customer impact, decisions, and temporal history. Those graph facts may reveal sensitive information even before a source document is opened.

Example: a public node says Content Discovery AI is a microservice. A restricted edge says it is connected to a named customer escalation. If retrieval expands through that edge, the model may infer customer impact from the path or from surrounding candidates. The system did not quote the private support case, but it still used private structure.

Permission layers in a ContextGraph

A production graph usually needs more than one access-control layer. User-level permissions describe who the person is. Tenant boundaries describe which workspace or customer data they belong to. Document ACLs describe source visibility. Node permissions describe whether an entity should be visible. Edge permissions describe whether a relationship can be used or explained.

These layers can disagree. A user may have access to a public service node and a public architecture note, but not the restricted edge connecting the service to an unreleased acquisition. A clean system treats the edge as blocked, even if both ends are individually visible.

Pre-filtering versus post-filtering

Post-filtering is tempting because it is easy to bolt onto an existing retrieval pipeline: retrieve candidates, remove unauthorized documents, answer with what remains. That is not enough for GraphRAG. If unauthorized nodes or edges influenced candidate selection, then private graph structure has already affected the answer.

Pre-filtering is safer: check access before a graph expansion is allowed. The downside is engineering complexity. Permission checks become part of query planning, caching, traversal limits, and ranking. The system needs fast access decisions and a consistent model for inherited permissions.

Most production systems need both. Pre-filter traversal so restricted paths cannot shape retrieval, then post-filter the final evidence as a defensive second pass. If either layer blocks something, it should be excluded from the model context and from user-visible explanations.

The public-node, private-edge problem

Graph permissions are subtle because visibility is not only attached to nodes. An entity can be public while a relationship is private. A team can be public while its relationship to a confidential project is private. A document can be private while a sanitized concept extracted from it is public.

That means a graph needs edge-level ACLs or an equivalent policy. If the system only checks whether the source and target nodes are visible, it can leak the existence of restricted relationships. For retrieval, the edge is often the reason a candidate was discovered, so edge visibility is part of answer safety.

Inheritance and propagation

Access-control mistakes often happen during ingestion. A restricted document creates an entity mention. The entity is merged into a canonical node. An alias is added. A relationship is inferred. Which permissions should each derived object inherit?

A safe default is to keep provenance attached to every derived graph fact. If an edge exists only because a restricted document asserted it, then the edge should not become globally visible just because the two endpoint nodes are public. Derived facts should carry the access constraints of their evidence unless a separate publishing process intentionally sanitizes them.

Merge decisions need the same care. If a private document teaches the system that two aliases are equivalent, that alias mapping may itself be sensitive. A user who cannot access the private evidence should not necessarily see that the two names are connected.

Auditability is part of permission design

When a GraphRAG answer is challenged, the system should show the retrieval trace: seed entities, traversed edges, candidate documents, permission decisions, filters, reranking results, and final context. For blocked evidence, the audit log can record that something was excluded without revealing the sensitive content to the user.

This is useful for both safety and debugging. If users complain that an answer is incomplete, engineers can see whether the missing context was unavailable because of permissions, poor retrieval, bad taxonomy, stale ingestion, or a ranking mistake.

What the model should never see

The model should not receive unauthorized chunks, unauthorized graph facts, unauthorized path explanations, or sanitized summaries generated from private evidence unless the user has permission to see that derived summary. The model context is the final access boundary. Anything placed there can influence the answer.

Redaction should happen before model assembly, not after generation. Asking the model to "ignore private details" is not an access-control system. Permission enforcement belongs in retrieval, graph traversal, context assembly, and auditing.