graphrag

private-rag has three previously-shipped vertical slices — CAPRISE embedder, CAPRISE storage, GELO reranker — that together cover flat-vector RAG: documents go in as encrypted embeddings, queries come back as encrypted top-k. That vertical assumes the corpus is a flat list of chunks. This page is the graph-augmented slice. LightRAG (Guo et al. EMNLP 2025) replaces the flat list with a knowledge graph of entities + relations + chunk pointers; retrieval becomes three parallel ANN searches plus a 1-hop graph expansion plus a chunk fan-out. Done naïvely, each of those steps is a distinct side channel the storage operator can read.

The job of this slice is to compose LightRAG retrieval semantics over the Compass encrypted-ANN protocol (OSDI 2025) so the full kg_query surface — including the graph expansion and chunk fan-out — runs as oblivious primitives over an untrusted blob store. Three Compass-encrypted HNSW indexes hide which entity / relation / chunk got looked up; two XorMM volume-hiding multi-maps hide adjacency-list lengths and source-chunk fan-out widths; AES-GCM hides chunk text. Every primitive is driven from inside a SEV-SNP CVM, attestation-anchored to the same scheme_identity that already pins the embedder and storage slices.

What this unlocks in the product: a tenant can ship a structured KG (entities, relations, chunks) to the CVM over RATLS, and subsequent queries return graph-grounded context — the kind LightRAG's headline benchmarks show beats flat retrieval on multi-hop and discovery tasks — without exposing the KG topology, the lookup pattern, or the result identities to the storage operator. The retrieval primitives are general; LightRAG is the first consumer.

What this slice is not. It is not the ingest LLM (entities/relations are extracted on the client today; an in-TEE extractor is a roadmap item). It is not the generation-layer defence against AGEA-class extraction over many legitimate API calls (that is PrivGemo / DP-RAG territory, separate from the retrieval crypto here). It is not a portability story for thin browsers: 50–325 MB of in-CVM client state per tenant means we ship as a server-resident multi-tenant CVM, not as on-device code.

Same trust geometry as the CAPRISE path (storage page): the CVM is trusted, the storage server and network operator are not, the client endpoint is trusted for the duration of an RATLS session. GraphRAG introduces structural attack surfaces the flat vector path does not have — every entity, every relation, every per-node degree, every adjacency list is now a distinct side channel. The TEE-anchored deployment neutralises those by routing every server-visible operation through one of three primitives: Ring-ORAM (over an encrypted HNSW or KV blob), XorMM volume-hiding multi-map (over adjacency & source-id lists), AES-GCM blob fetch (over chunk bodies).

Departure from the Compass paper. Compass's paper places its protocol "client" — the party holding the position map, stash, treetop cache, and ORAM key — on the user's own device (laptop / phone / browser), explicitly avoiding TEEs because enclave side channels weaken the story. This design shifts that client role into the SEV-SNP CVM. The Compass protocol is unchanged; the trust anchor moves from "user owns the hardware" to "SEV-SNP attestation + AMD vendor." Opal (Kaviani et al. 2026) already does this composition and formally imports Compass's batched-access lemma into its G_att-hybrid proof — the security property holds because it's a property of the protocol, not of which silicon hosts the client. The thin-client / multi-tenant SaaS shape this prototype targets cannot put 5–500 MB of ORAM state on every user's browser, and SEV-SNP attestation is the trust anchor this codebase already relies on for CAPRISE-at-rest. Deployments that cannot accept SEV-SNP trust should use the on-device deployment from the design doc instead — paper-faithful Compass on the user's device. The two are parallel deployments of the same protocol with different trust anchors, not primary and fallback.

Inherited weakness. CAPRISE remains distance-preserving inside the Compass block payload — defence in depth, not a substitute. The ORAM hides which block is read; CAPRISE keeps the block contents useless if the AES-GCM key is later broken. A key-holder still recovers plaintext (Vec2Text).

Each card pairs [method ↦ source ↦ what it secures ↦ threat ↦ overhead]. Crates tagged SHIPPED are end-to-end functional behind release-tested integration suites; deferred sub-features are called out in the card body and tracked in §07 Status & gaps.

What the storage server sees, end-to-end. A stream of Ring-ORAM read_path + write_path RPCs against three trees plus two KV trees, plus XorMM bucket reads against two static EMMs, plus AES-GCM blob fetches. Path IDs are uniform-random by construction. Bucket sizes are uniform per-tree. XorMM response sizes are uniform per-EMM. Request rate is constant per RATLS session. Across two distinct queries by the same tenant, the server's view is computationally indistinguishable.

Today's simplification: step ③ "Embed (GELO)" runs on the client, not in the TEE. The current wire format (/lightrag/ingest, /lightrag/query) accepts pre-computed embeddings for every chunk / entity / relation / query — the client owns the GELO + mask + GPU offload pipeline. The diagram preserves the target shape where the TEE re-runs the embedder under attestation, but the present ship trusts the client (same machine as the keyword-extraction LLM) to do this honestly. Moving embedding back into the TEE is the same plumbing as the embedder slice (embedding page) — no new crypto, just a request-path branch.

Note: ingest path. Same trust geometry, opposite direction — client streams documents + extracted KG over RATLS; TEE embeds, builds a plain hnsw_rs::Hnsw in encrypted CVM RAM, runs CompassIndex::from_plaintext_hnsw, pushes the encrypted ORAM tree to storage, builds and pushes the XorMM EMMs, writes the AES-GCM chunk blobs, then zeroizes the plaintext working set. Heavier than query — expect minutes per 100K docs — but a batch operation, not on any user-perceived path.

Inset · Step ④ per-session search perturbation

Why this step exists: Compass + Ring-ORAM randomises the storage-side path IDs, but two sessions of the same tenant issuing the same query still produce identical execution fingerprints (timing · round count · batch sizes · SEV-SNP-leaky perf counters). The perturbation randomises the HNSW start vertex per session, breaking cross-session linkability.

The Compass paper acknowledges a coarse version of this leak — "different query types use different ef, so an adversary can still distinguish the operation type" — and explicitly puts it out of scope. Concretely: Compass's batched ORAM rounds-per-query are n = ⌈ef / ef_spec⌉, so a search at ef=64 takes 4 round-trips while an insert at ef=200 takes 13. The count of round-trips is itself a fingerprint visible to any passive observer, with no decryption required. Compass openly does not try to hide it. Our HMAC perturbation closes the finer-grained content-level version of the same class of leak: same operation, same mode, but two sessions issuing the same query produce different content-adaptive execution patterns (directional-filter prune rate, speculative-prefetch hit rate, hops-to-convergence) — without the perturbation, those signatures are stable enough to link sessions to each other.

Numbers below are from the compass-rag-bench binary (crates/graphrag-bench) — release build, single-threaded, in-memory backends (no network), 50 queries per (size, mode) after 5 warmup queries dropped. The bench replicates the kg_query orchestration with Instant::now() boundaries between each stage so latency can be attributed end-to-end. The next bench tiers will swap InMemoryBlockBackend for compass-rest-backend on loopback (REST overhead) and then POST through /lightrag/query (full user-perceived latency).

Query latency · Local mode

Query latency · Hybrid mode

Where the time goes. CompassIndex search owns the budget: 99.4 % of Local at every size, ~71 % of Hybrid (split between the entities and relations searches, in proportion to corpus size — relations is N·0.33). EMM lookups + AES chunk decrypt + search_perturb combined stay under 0.5 % of total at every scale. This is the batched-ORAM-reads + Speculative-Neighbor-Prefetch optimization budget: at N=2000 each query does 212 sequential ORAM round-trips that in principle could be unioned into a small number of batched paths.

Sub-linear scaling. Wall time grows 10 → 19 → 34 ms for a 20× corpus (~3.4× growth) — HNSW O(log N) traversal cost is the headline, but layer-0 ORAM read count grows even more gently (117 → 174 → 212, only 1.8×). The wall-time gap is the second-order effect: n_leaves scales with corpus (256 → 1024 → 4096), Ring-ORAM tree levels go 8 → 10 → 12, and per-path-read bytes grow accordingly. Ingest cost is dominated by the HNSW build pass (O(N · ef_construction · M) distance ops); the ORAM admit phase is small.

Correctness — recall + security tests

Test totals. ring-oram 34 · xormm-emm 13 · compass-index 13 lib + 3 recall · compass-rest-backend 5 lib + 3 integration · light-kg-store 7 lib + 1 acceptance · lightrag-private 7 lib + 2 integration · gelo-snp-runner (mock mode) 3 lightrag routes. All release-mode where needed (compass-index recall, light-kg-store acceptance, graphrag-bench); see memory/feedback_compass_recall_release.md for the rationale.

The vertical end-to-end (client → /lightrag/ingest → encrypted store → /lightrag/query → context string) is shipped, including Local and Hybrid kg_query modes and the unknown-tenant loud-failure contract. Below: feature-by-feature status with deferrals called out, then the residual gaps grouped by axis.

Residual gaps grouped by axis.