Securing LlamaIndex applications

The most useful thing to know about securing a LlamaIndex application is a distinction the framework's own documentation makes clearly and most integration pages blur: its instrumentation module is built to observe the pipeline, not to intercept it. That single fact decides where enforcement can and cannot go, and it is why a monitoring integration and a security control are not the same project.

We publish no tested-compatibility claim for LlamaIndex. What follows is the framework's documented extension surface and what a control attached to it can enforce. Our own tested support belongs in the supported models and frameworks matrix, which is not filled in yet.

What the instrumentation module gives you

LlamaIndex documents an instrumentation module built from four pieces:

• Events — "a single moment in time that a certain occurrence took place within the execution of the application's code", carrying attributes such as id_, timestamp and span_id.
• EventHandlers — objects that "listen to the occurrences of Events and execute code logic at these moments in time". You subclass BaseEventHandler and implement class_name() and handle(event, **kwargs).
• Spans — "the execution flow of a particular part in the application's code", containing events.
• SpanHandlers — responsible for entering, exiting and dropping spans, via new_span(), prepare_to_exit_span() and prepare_to_drop_span().
• Dispatcher — emits events and span signals to the registered handlers. You obtain one with instrument.get_dispatcher(__name__) and register a handler with dispatcher.add_event_handler(my_event_handler).

Source: LlamaIndex instrumentation documentation, read 13 August 2026.

Why that is monitoring rather than enforcement

Read the shape of the interface. A handler's handle() is called when something has occurred. That is exactly the right design for tracing, metrics, audit and evaluation — and it is the wrong shape for a control that has to stop something from happening, because by the time the handler runs, the thing it was told about has already happened.

The practical consequence for a security programme:

• You can build excellent visibility on this interface. Every query, every retrieval, every model call, correlated by span, with timestamps. That is a real security asset: it is what turns "we think we had an incident" into an answerable question, and it is genuinely hard to add later.
• You cannot enforce on it. A blocking decision needs to sit in the request path with the ability to refuse. Attaching a "guardrail" as an event handler produces a system that reliably records the disclosure it did not prevent.

Neither point is a criticism of LlamaIndex. Observability and enforcement are different jobs, and a framework that says which one it is doing is being straight with you. Take the same care with the labels in your own architecture diagram.

Where enforcement actually goes in a RAG pipeline

A LlamaIndex application is usually a retrieval pipeline, which means it has three distinct enforcement points and only one of them is about model traffic.

1. At the retriever, for authorisation. This is the one that matters most and the one an inline layer cannot do for you. If a retriever can return a document the requesting user is not entitled to read, the disclosure has already occurred when the chunk enters the context window — a downstream check can only decide whether to repeat it. Filter at query time by the user's own entitlements, in the vector store, not in a post-hoc check. RAG security works through why permission-aware retrieval is the control and everything else is mitigation.

2. In the request path to the model, for content decisions. Prompt-injection detection over the assembled context — which in a RAG application means over the retrieved chunks, because that is where indirect injection arrives — plus output-side handling of what the model returns. The reliable way to attach here is outside the framework: point the model client at a layer you run, so every call reaches it regardless of which code path built the request. The base-URL pattern is described on the Anthropic API and Vertex AI pages.

3. In the ingestion pipeline, before anything is indexed. Documents entering the index are the durable version of your prompt content: a poisoned or over-permissioned document indexed today is retrieved for every user for as long as it stays there. Data poisoning and PII redaction both apply at this stage, and this is the cheapest place in the whole system to apply them.

Use the instrumentation module for what it is good at

Having said what it cannot do, it would be a mistake to skip it. Register an event handler that records, for every query: which documents were retrieved, which model was called, how long each span took, and the identity the request was made under. Then:

• you can answer "which users could have seen this document" after the fact, which is the first question in any retrieval incident;
• you have the corpus you need to measure a guardrail on your own traffic instead of on a vendor's benchmark — see detection accuracy and false positives;
• you can tell whether a spike in blocks is a threshold problem or one bad document, which is the difference between a tuning afternoon and a week.

Be deliberate about what those records contain. A trace that captures full prompt text is a second copy of your most sensitive data, in a system that is usually less well protected than the one it is observing. Decide the retention for it at the same time you decide the retention for everything else — see data handling.

What to ask us before you build against this

• Which attachment point do you support for a LlamaIndex pipeline today?
• Does anything you offer act at retrieval time, or only on model traffic?
• If you ingest traces, what is retained, for how long, and where?
• What happens to a query when the layer cannot reach a decision?

Evaluation and security review has the full list to take into a first call.

Related

• Securing LangChain applications
• RAG security
• Amazon Bedrock