Knowledge Graph LLM Security Starts at Context Assembly

Microsoft GraphRAG local search starts with a user query, identifies related entities, follows relationships, retrieves associated text units and community reports, then filters that material into one context window. Security decisions made only at document retrieval miss the object that the model actually receives. I want to focus on that final assembly boundary: the point where graph facts, source text, conversation history and instructions become one HTTP request to an LLM.

TL;DR

• Carry source and authorization metadata through every graph transformation, then create a manifest for the completed context.
• Recheck the caller, purpose, data classes and model destination after assembly because the combination can be more sensitive than any single node.
• Inspect the completed HTTP request before model delivery and retain the manifest hash, policy version and outcome.
• Keep graph construction and source permissions with their owners. An AI gateway governs only traffic deliberately routed through it.

GraphRAG changes the object under review

The Microsoft GraphRAG indexing documentation describes a pipeline that extracts entities, relationships and claims from raw text. It detects communities, generates summaries and reports at several levels, and embeds text into a vector space. The default outputs include Parquet tables and configured vector-store entries.

The security object changes during that pipeline. A source paragraph may begin with a document ID, access list and retention rule. Entity extraction turns the paragraph into graph objects. Community detection groups those objects, and report generation writes new text about the group. That generated report is derived material with its own sensitivity, even when every source paragraph was handled correctly.

Graph construction needs provenance and authorization metadata that survive each transformation. At minimum, each entity, relationship, claim, text unit and community report should retain source references, source access scope, data classification, transformation version and last validation time. A graph row without provenance is a loose fact. It may still be useful, but a security decision lacks the basis to explain where it came from or which source rule should constrain it.

This article addresses customer-controlled GraphRAG applications. The existing Glean DLP analysis covers a hosted enterprise-search product and its derived knowledge graph. Here, the engineering artifact is a context manifest produced by an application you control.

Authorization labels have to survive graph transformations

Document authorization rarely maps cleanly onto a graph. One relationship can combine facts from a project plan and a meeting transcript. A community report may summarize dozens of entities. A local-search result can include a relationship that was inferred by the indexing model rather than written by a person.

I would use conservative label propagation for security-sensitive fields. A derived object should record every contributing source and inherit the most restrictive applicable access condition until an explicit policy says otherwise. The system also needs a rule for conflicting residency, purpose and retention labels. Quietly dropping a label during entity extraction is a security defect, not a data-quality inconvenience.

The graph store still has to enforce its own read controls. The graph owner must repair a query engine that returned an unauthorized node. Test the graph with two identities: one entitled to a restricted source and one excluded from it. Preserve the selected entity and relationship IDs for both runs. A failing test belongs with the graph owner before any prompt leaves the application.

Label propagation also needs revalidation. Source access can change after indexing, while a generated community report remains in a cache. Set an expiry or change event for derived objects whose source permissions are mutable. The AI data classification guide provides the classification layer; the graph adds lineage and combination rules around it.

Context assembly is a separate policy decision

Microsoft's local-search methodology combines structured graph data with unstructured source text at query time. Its documented flow can include entities, relationships, covariates, community reports, text units and conversation history. Candidate material is ranked and filtered to fit the configured context window.

That completed context deserves a second authorization decision. Retrieval asks which objects the caller may receive from the graph. Context authorization asks whether this combination may be sent to this model for this purpose. The two decisions use different facts.

A useful context policy evaluates:

• the authenticated human or agent and its role
• the approved use case and application route
• all source scopes and classifications represented in the context
• derived claims and reports, including their provenance state
• the requested model provider, model family and region
• conversation history and system instructions added after retrieval
• tool or action authority attached to the model call

Aggregation can raise sensitivity. A budget line, hiring plan and project codename may each be available to the caller. Their combined context can disclose an acquisition plan that no source states directly. The policy engine needs the assembled prompt because upstream components see fragments.

My opinion is blunt: a graph query that returns 14 authorized objects still needs a context decision. Fourteen green retrieval checks on a whiteboard leave the safety of the resulting external prompt unproven.

The context manifest makes the decision reviewable

Create a machine-readable manifest immediately before serialization of the model request. Give it a stable ID and hash the exact context bytes. The manifest should list the authenticated caller, use-case ID, graph index version, query method and model destination. It should also identify every included entity, relationship, report and text unit, with source references and effective classifications.

The record can stay compact by storing stable object IDs and hashes rather than duplicating full source text. An investigator still needs a controlled way to resolve those IDs against the graph version that existed at decision time. If graph compaction or re-indexing destroys old identifiers, the audit trail becomes a bag of dead pointers.

Record these fields for each outbound call:

• context_manifest_id and hash of the assembled context
• authenticated identity, role and delegated authority
• application route, use-case ID and purpose
• graph index, extractor and prompt-template versions
• included object counts by type and highest effective classification
• source systems, access scopes and unresolved provenance flags
• model destination, region and route policy
• decision, reason code, policy version and timestamp

The LLM audit log retention guide covers storage and retrieval after the event exists. For a knowledge graph, retention planning also has to preserve the identifier map needed to reconstruct the manifest.

Picture the review at 11:42 on a Tuesday. An analyst opens decision kg-7f31, sees nine entities, four relationships, two community reports and six text units, then resolves the one report that raised the classification. That is usable evidence. A log line saying GraphRAG request allowed is useless by itself.

Tests should cross the graph and model boundary

Use fixed fixtures with visible markers. Place one marker in a broadly available source and another in a restricted source. Build the graph, run the same query under two identities, and record which objects enter each candidate set. Then inspect the final context manifest and outbound HTTP decision.

A minimum test pack should cover an entitled user, an excluded user, a stale source permission and a community report derived from mixed scopes. Add a destination change from an approved private model route to an unapproved external route. Test a missing identity and an expired manifest. Trigger policy-service failure in a controlled environment and confirm that the route fails closed.

Keep expected results precise. The excluded identity should never receive the restricted graph object. Mixed-scope derived material should receive the configured restrictive label. A disallowed destination should be denied before model delivery. The record should name the reason and active policy version.

Graph poisoning and extractor quality need separate tests. A gateway can classify and authorize the assembled request. Extraction correctness remains outside that gateway evidence. Data and model teams own source validation, extraction evaluation and graph integrity. HTTP request controls begin after the application has assembled model traffic.

DeepInspect

DeepInspect can enforce the final routed decision for customer-controlled GraphRAG applications. The application supplies authenticated identity and approved use context, then sends the assembled HTTP request through DeepInspect before it reaches the LLM endpoint. DeepInspect can classify the prompt, evaluate identity and role plus model destination, and permit, redact or deny the request under versioned policy.

The resulting per-decision record can reference the application's context-manifest ID and hash alongside the caller, route, classification, policy version, outcome and timestamp. Graph ingestion, extraction quality, source ACLs and label propagation stay with the graph platform. Vendor-hosted graph traffic that bypasses the proxy stays outside this enforcement boundary. Book a technical deep dive at deepinspect.ai.