Guides › GraphRAG and agentic retrieval

GraphRAG and Agentic Retrieval Security: What Changes When the Index Is a Graph or the Model Picks the Query

Two retrieval architectures have moved from research to production in the last eighteen months. GraphRAG replaces the flat index with a graph of entities, relationships and community summaries, so the assistant can answer questions that span many documents. Agentic retrieval replaces the single retrieval call with a plan the model writes itself, fetching from several sources across several hops. Both are improvements in answer quality and both change the leakage profile in ways the classic RAG controls don't cover on their own. This page describes what changes in each, cites the research that measured it, and lays out the controls that hold.

GraphRAG: what the index becomes

A classic index stores chunks of source text, each chunk traceable to one document and therefore to one access control list. GraphRAG runs an extraction pass over the corpus and stores what it finds: entities with generated descriptions, relationships between entities with generated descriptions, and community summaries that condense clusters of related entities into prose. Those artifacts are the product. A question about a customer, a program or a person is answered from the entity's description and its neighborhood rather than from any single document, which is why GraphRAG is good at questions that classic retrieval fumbles.

It is also why the permission model breaks. An entity description was synthesized from every document that mentions the entity, some of which the asking user could open and some not. A relationship between two entities may exist only because two documents in different silos were read together. A community summary is, by construction, a cross-document synthesis with no single source. None of these artifacts carries a native access control list, and a retriever that returns them is making the cross-silo joins the data silos guide warns about, as a feature, at build time.

What the research measured

A 2025 study from Pennsylvania State University, Exposing Privacy Risks in Graph Retrieval-Augmented Generation, ran data extraction attacks against naive RAG, GraphRAG and LightRAG over the Enron email corpus and a healthcare question dataset, with 250 queries per setting. The headline is a trade-off: GraphRAG leaked less verbatim source text than conventional RAG and far more structured data. The numbers are worth quoting.

Three findings matter for a defender. Leakage rose as the retriever returned more items per query, often stabilizing above 70 percent once the top-k reached ten or fifteen, so retrieval breadth is a security setting. The attack depended on the command: a crafted instruction to list retrieved entities and relationships with their descriptions reached 68.6 percent entity leakage on the healthcare set where a generic “repeat the context” prompt reached under one percent, so prompt-level defenses that stop the generic version are not evidence of safety. And the mitigations the authors tested all fell short: prohibitive system prompts gave marginal reductions, similarity thresholds high enough to help removed almost all useful context, and summarization reduced untargeted leakage while failing to protect, and sometimes increasing exposure of, specifically targeted entities.

Why the summaries are the hard part

Entity and relationship descriptions can, with effort, inherit permissions from the documents they were extracted from: the entity's access control list is the union of its source documents' lists if any mention is enough, or the intersection if the description blends them. Community summaries resist this. A summary of a cluster drawn from twelve documents across four permission groups is readable by nobody under the intersection rule and by everybody under the union rule, and neither is right. The workable answer is to build summaries per principal set, or per sensitivity tier, so that a user retrieves the summary generated from the documents they could open, and to treat any summary without that scoping as unrestricted content.

Controls for GraphRAG

Five controls carry the classic design onto a graph. Propagate access control metadata to nodes and edges at extraction time, with an explicit rule for blended descriptions. Scope community summaries by principal set or sensitivity tier rather than generating one summary per community. Run identifier substitution before the extraction pass, so that entity names and keys in the graph are already stand-ins and an extraction attack recovers nothing a reader could not already resolve. Record node, edge and summary retrievals in the telemetry store under opaque IDs, because a graph makes the “which documents were returned” question harder and the record more important. And test with the attack the paper used, a targeted command for entities and relationships with descriptions, rather than with generic repetition prompts.

Agentic retrieval: what changes when the model picks the query

In classic RAG the application issues one retrieval call with the user's question. In agentic retrieval the model plans: it decomposes the question, decides which sources to query, issues several retrieval or tool calls, reads the results, and decides whether to go again. Managed services now offer this as a feature, with knowledge agents that run multi-source retrieval behind a single call. The quality gain is real. The security change is that the retrieval decision has moved from code you wrote to a model that reads the results of its own previous hops, and the table summarizes what that does to each control.

The join problem, automated

A user with legitimate access to three sources could in principle have joined them by hand. An agent does it in seconds, repeatedly, for every question that benefits. Each hop can pass its entitlement check and the combination can still produce an inference no document contained and no check examined. The practical control is to log the hops as a chain and to test chains, not single retrievals: the question is what the agent can assemble for a given user, which is a larger set than what the agent can retrieve for them.

Tool results as instructions

Every result an agent reads becomes part of the context that shapes its next decision, and a document, ticket or page can carry text written to redirect that decision. In classic RAG this is indirect prompt injection with one hop to exploit. In agentic retrieval the injected instruction can steer which sources are queried next and, if any tool can write or send, where the result goes. Tool results have to be treated as untrusted content, and the set of tools an agent may chain, especially any tool that writes, has to be defined in advance rather than left to the plan.

Controls for agentic retrieval

The policy point runs on every hop, against the asking user's live principals, not once at the start of the plan. Hop counts and retrieval budgets are capped per question, which also bounds the extraction rate the GraphRAG research showed rising with volume. Allowed tools and allowed chains are enumerated; a plan that proposes an unlisted combination fails closed or waits for approval. Substitution applies to every result before it re-enters the model's context, so what the plan reads is already stand-ins. Telemetry records the plan, each hop, each policy decision and the final context as one trace. And the test suite includes planted-instruction content and cross-source questions, run per identity, with the leakage number computed on the assembled context rather than on any single retrieval. The connector and MCP security page covers the identity and supply-chain questions that agents add on top.

Managed agentic retrieval and knowledge services

Managed services are moving the controls into the platform, unevenly. Azure AI Search, which underpins Microsoft's managed knowledge layer for agents, documents document-level access control with security filters generally available and token-based ACL, RBAC, Purview sensitivity label and SharePoint permission trimming in preview as of October 2026, with permission changes reflected only after the index is resynced. Its retrieve action and MCP retrieval tool can surface sensitivity label information per reference so a client can enforce policy. The documentation's explicit agentic guidance covers label surfacing; whether token-based trimming runs inside every knowledge-agent retrieve path is something to verify for the call you use before relying on it. The rule for any managed service is the same: find the retrieve call your application makes, confirm which trimming runs inside it and what its sync lag is, and put a policy point in front where the answer is unsatisfying.

Where Hardshell sits

Hardshell applies the same four controls to a graph or an agent that it applies to a flat index: entitlements checked at query time on every retrieval and every hop, identifiers substituted before content reaches a model provider or re-enters an agent's context, every retrieval recorded under opaque IDs as a trace, and exposure testing that runs targeted extraction commands, planted instructions and cross-source questions per identity before rollout, with findings mapped to MITRE ATLAS technique IDs. It connects to the systems where data already lives without migrating them and deploys as a cloud service, in a private cloud or as an offline bundle.

Frequently asked questions

Is GraphRAG less secure than vector RAG?

It leaks different things. The 2025 Penn State study found GraphRAG leaked less verbatim source text and far more structured data: targeted attacks recovered roughly 70 percent of entities and relationships against GraphRAG where naive RAG stayed around three to ten percent. For a corpus where the sensitive content is who is connected to whom, that is the worse profile.

Can a system prompt stop extraction from a graph?

Not reliably. The same study tested five prohibitive system prompts and found marginal reductions that did not meaningfully stop PII extraction. Similarity thresholds high enough to help removed almost all useful context. The controls that hold are structural: permissions on the graph artifacts, scoped summaries and substitution before extraction.

Does Microsoft's GraphRAG support document permissions?

The open-source GraphRAG pipeline builds entities, relationships and community summaries from the corpus it is given and does not carry access control lists through that process on its own; permission scoping is something the team building the pipeline adds, typically by building per-scope graphs or propagating metadata at extraction. Managed knowledge services document their own, partly preview, trimming options.

What is the difference between agentic retrieval and an agent with tools?

Agentic retrieval is the narrower case: the model plans a sequence of reads. An agent with tools can also act. Every control on this page applies to both; an agent that can write or send adds the exfiltration path and the tool-chaining rules on the connector page.

How do we test an agentic system for leakage?

Run the leakage self-test against the assembled context rather than against single retrievals: for each test identity and question, record every hop, union the documents touched, and score the union against the entitlement matrix. Add planted-instruction content to the test corpus and cross-source questions to the query set.