GraphRAG security — new risks in knowledge-graph-augmented retrieval

It is worth being explicit about what still applies. A GraphRAG pipeline still ingests documents, and every ingestion-time poisoning vector already covered for vector RAG — direct upload, crawled content, API-fed documents, shared-knowledge-base updates — still reaches a GraphRAG corpus the same way. Document-level, field-level and output-level access control still matter for whatever vector-similarity retrieval the pipeline keeps alongside graph traversal.

What this piece adds is the layer sitting on top of that: the graph itself, built from the corpus rather than being the corpus, queried by a mechanism (traversal) that behaves differently from similarity search in a way that matters specifically for security review. A reviewer who has fully verified the ingestion and access-control checklist for the underlying documents has not yet reviewed GraphRAG's specific risk — they have reviewed the RAG system GraphRAG happens to be built on top of.

Architecturally, a GraphRAG pipeline adds three things to a standard RAG pipeline: an extraction step that pulls entities and relationships out of each ingested document (typically via an LLM extraction pass, sometimes supplemented by rule-based extraction), a graph store that holds those entities and relationships as structured data, and a retrieval step that traverses the graph — following edges outward from entities matched to the query — in addition to, or instead of, similarity search against a vector index.

Many implementations add a fourth element: pre-computed summaries at multiple levels of the graph, generated by clustering related entities into communities and asking the model to summarize each community once, ahead of query time, so that a broad query (“what are the main themes in this corpus about X”) can be answered from a small number of pre-computed summaries rather than traversing the full graph live for every request.

Each of these four elements — extraction, storage, traversal, and pre-computed summarization — introduces its own security-relevant question, and the three threats below map onto three of them directly.

This is the threat that most directly breaks an access-control model inherited from vector RAG, and it is worth spelling out concretely. Suppose document-level access control is enforced correctly: a user's retrieval query is filtered to only the documents that user is permitted to see, and that filter works exactly as designed for the vector-similarity retrieval path. The same user now asks a question that graph traversal answers by starting from an entity mentioned in a document they are permitted to see, and following an edge — “works with,” “reports to,” “is a vendor for” — to a related entity that was extracted from a different document entirely, one the user does not have permission to see.

The access-control check that scoped the user's query to permitted documents ran once, at the entry point, against the starting entity. It did not run again at each hop of the traversal, because the traversal engine has no reason to think of a graph edge as crossing a document boundary — from the graph's perspective, it is just an edge. The user's final answer can therefore surface information that was extracted from a document they were never permitted to retrieve, without the retrieval pipeline ever returning that document to them directly. The access-control violation is real; it just never shows up in the document-level audit log, because no restricted document was retrieved — only a fact that happened to be extracted from one.

A worked example: an internal knowledge graph built from HR records and project documentation extracts a “reports to” relationship from a restricted compensation-review document and a “works on” relationship from a public project wiki page. A user permitted only to see the public wiki page asks “who does the lead on Project X report to, and what is that person's role on other confidential initiatives?” Traversal starts from the public entity (Project X), crosses the “reports to” edge that was extracted from the restricted document, and can surface a chain of connected facts the document-level permission check never evaluated, because the check ran against the starting document, not against every document any edge in the resulting path was extracted from.

Standard RAG data poisoning works by getting an adversarial document into the corpus so it is retrieved and treated as evidence for a query about the document's own content. Relationship injection is a more indirect variant specific to GraphRAG: an attacker-controlled document does not need to be retrieved at all to cause harm. It only needs to be ingested, so that the extraction step pulls a false relationship out of it and writes that relationship into the graph as structured data.

Once written, the false relationship is treated identically to a true one during traversal — the graph store generally has no field for “confidence this edge is real” that traversal actually checks, and even where extraction confidence scores exist, they reflect the model's confidence in having extracted the assertion correctly from the source text, not whether the source text was telling the truth. A single low-privilege document asserting “Entity A is affiliated with Entity B” — a document the attacker was permitted to submit, perhaps to an otherwise legitimate, lightly reviewed contribution channel — can influence every future answer the system gives about Entity B's associations, for any user who queries about Entity B, regardless of whether that user ever sees the original poisoned document.

This is more insidious than direct document poisoning for two reasons. The injected content never has to compete for retrieval ranking against legitimate documents — it only has to survive one extraction pass. And the resulting exposure is indirect: an audit of “what documents were retrieved for this answer” will not show the poisoned document at all, because the poisoned document's only contribution was a single edge in the graph, extracted once, reused indefinitely.

Pipelines that pre-compute community-level summaries — a single narrative summary generated once for a cluster of related entities, used to answer broad queries efficiently without live traversal — introduce a third failure mode: a single poisoned document that ends up clustered into a community can corrupt the summary generated for that whole community, and that one corrupted summary is then reused as the answer basis for every future query that draws on it, until the summary is regenerated.

The amplification here is structural, not incidental. A single restricted or low-privilege document poisoning one relationship affects queries that touch that specific relationship. The same document, if it happens to land in a community whose summary many unrelated queries draw on for broad, high-level questions, has its influence multiplied across every one of those queries — none of which retrieved the poisoned document, or even the specific entity it poisoned, directly. And because the summary is pre-computed, the corruption is silent between regeneration cycles: nothing about a stale, poisoned summary look different from a stale, accurate one at query time.

This is where GraphRAG's efficiency optimization and its security exposure are the same design decision. Pre-computing summaries is what makes broad queries fast; it is also what turns a single poisoned source document into a standing, reused artefact rather than a one-time retrieval risk.

The pattern common to all three threats above is that they operate at a layer the standard RAG access-control and poisoning checklist was never designed to reach — traversal, extraction, and pre-computed summarization each sit between the document-level control point and the answer the user actually receives. Closing the gap means extending, not replacing, the existing controls.

Concretely: access control has to be re-evaluated at each traversal hop against the permission of the document each edge was extracted from, not just at the query's starting point. Relationship extraction from any document below a defined trust tier needs a validation or review step before the extracted edge is written into the graph as usable fact, the same way a trust-tier model already governs direct document poisoning in vector RAG. And any pre-computed summary needs an explicit staleness and regeneration policy tied to changes in its source documents — a summary that never gets regenerated is a summary that can carry a poisoning event indefinitely.

For a GraphRAG deployment, a review is complete on the graph-specific surface when it can answer each of these with a configuration artefact or a test result, not a description of the vector-RAG controls alone:

• Does access control operate at the graph-traversal layer — re-evaluated at each hop against the source document's permission — or only at the ingestion/document layer?
• Is there a limit on traversal depth or hop count from a permitted starting node, bounding how far a query can travel before the traversal engine has to re-check scope?
• How are relationship extractions from untrusted or low-privilege documents validated before being written into the graph as usable fact?
• Are pre-computed community summaries regenerated when their source documents change, or can a summary go stale — and silently carry a poisoning event — indefinitely?
• Can an audit reconstruct, for any answer, every document whose extracted content (not just whose retrieved text) contributed to that answer — including edges and summaries several steps removed from the query's starting entity?

A GraphRAG deployment that answers the vector-RAG checklist well and cannot answer these has not closed its access-control boundary — it has moved part of that boundary into a structure the existing review never looked at.