Adding Gateco to a LangChain or LlamaIndex RAG Pipeline

Gateco is not a RAG framework and does not want to be one. If you already build with LangChain or LlamaIndex, you keep them. Gateco is the authorization layer you insert at a single point in that pipeline, the retrieval step, so the chunks that reach your model are already filtered to what the end user is allowed to see. No new integration, no rewrite, one call in the place you already fetch context.

The one change: gate the retriever

Both frameworks share the same shape: embed the query, retrieve the closest chunks from a vector store, assemble them into context, and call the model. The only step that needs to change is the second one. Instead of querying the vector store directly, you call Gateco's retrieval, bound to the principal the agent is acting for. Everything downstream, context assembly, prompting, synthesis, stays exactly as it was.

In LangChain

The natural seam is the retriever. Where you would call the vector store's as_retriever and hand that to your chain, you instead resolve the request's user to a principal and call the Gateco SDK's retrieve for that principal, then pass the returned chunks into the same chain. The chain neither knows nor cares that the candidate set was filtered by policy first; it just receives fewer, authorized chunks.

In LlamaIndex

The seam is the same, one layer in: the query engine's retriever. Resolve the principal, call Gateco for the allowed nodes, and pass those to the response synthesizer. Because the substitution happens at the retriever and not at synthesis, all of LlamaIndex's response modes and post-processors keep working unchanged.

Resolving the principal is the part that matters

The whole model depends on knowing who the agent is acting for. Resolve the end user to a principal by email or identity-provider subject, then pass that principal on every retrieval. The pattern to avoid is the common one: an agent that queries the store with a single shared service account and no per-user identity, which makes per-user authorization impossible no matter what comes after.

Why the retrieval step and not the prompt

It is tempting to filter the model's output instead, or to ask the model nicely not to use certain context. Both are too late: once denied content is in the context window, it can surface in the answer, in a citation, or in a follow-up. Gate before the context is assembled, not after. We make that argument in full in pre-retrieval vs post-retrieval authorization.

The result is one authorization layer across LangChain, LlamaIndex, and direct SDK use, with the same policies and the same audit trail behind all three. The Python and TypeScript SDKs and the exact retrieval call are documented in the docs.