Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
If you are familiar with RAG (Retrieval-Augmented Generation), you know that it allows an LLM to answer questions using information from your documents.
If you are new to RAG, you can check out this article first.
At a high level, RAG embeds your documents, retrieves the most relevant pieces for a question, and then passes them to the model as context.
Now, with any emerging technology, there will always be a security angle.
RAG is no exception.
The model relies on the information that gets retrieved.
So one potential weak point is the knowledge base itself.
If the documents contain bad or malicious information, the model may use that information when generating its answer.
This means an attacker may be able to influence the model's output simply by modifying the documents it retrieves, without directly attacking the model through techniques like jailbreaking.
This is known as knowledge poisoning.
There are different types of attacks.
Let's look at some of them.
Here, we plant a false document that looks like a legitimate document.
When the document is retrieved, the model may treat the false information as real and use it in its answer.
Here, we hide an instruction for the model inside the data.
When that data is retrieved and included as context, the model may interpret the hidden instruction as something it should follow.
Depending on the instruction, this could cause the model to produce unintended or potentially harmful output.
Here, we add irrelevant text that is designed to be similar to the target query.
Because the retrieval system looks for similar content, the malicious text may be retrieved instead of the information that actually answers the question.
The model then receives the wrong context and may produce the wrong answer.
This one is more subtle.
Instead of making one obvious malicious change, an attacker makes small changes over time.
Each individual change may look harmless, but together they can gradually push the knowledge base toward incorrect information.
The problem is that there may be no single edit that clearly explains where things went wrong.
The incorrect information has accumulated gradually.
Let's see one of these attacks in action.
I built a small project that demonstrates knowledge poisoning in a RAG system.
There are a few different attacks in the project, but I'll demonstrate one of them here.
You can clone the project here:
https://github.com/RijulTP/rag-demo
You can set your Gemini API key in the environment and try commands such as:
make demo-attack1
When you run it, you first see the original state before poisoning, where it correctly answers the questions.
This shows the state before the knowledge base is poisoned.
Now let's demonstrate the attack.
A file called poison_pricing.md is added to the knowledge base.
The file contains modified pricing information.
As a result, when the poisoned document is retrieved, the model uses the incorrect information and gives faulty pricing data.
Now let's look at the defense.
Two defenses are put in place.
The first is trusted sources.
The second is a pattern-based check.
As you can see, poison_pricing.md is not included in the trusted sources.
So the poisoned chunk is dropped before it reaches the model.
As a result, the poisoned information no longer alters the model's answer.
So this is one demo, there are few more in the repository, you can try it out.
RAG doesn't just introduce a retrieval problem. It also introduces a new place where an attacker can try to influence the model: the knowledge base.
Understanding these attack possibilities is important when building RAG systems.
Some attacks are easy to spot, while others can be much harder to detect.
Gradual drift is especially difficult to catch because there may be no single obvious change responsible for the final incorrect answer.
Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.
I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.
Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.
Spend code review effort where business risk is highest — not spread evenly across every diff.
⭐ Star it on GitHub:
LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.
| The exact math, not a black box | Visualize blast radius at a glance | Every factor that feeds the score |
|---|
Here's the goal:
Click below to try LiveReview with your codebase: