Generic baselines collapse retrieval into ordinary data access and hide the differences between writing to the index, querying it, and assembling context. RAG security only becomes actionable when each stage has its own expected pattern. Otherwise, alerting either becomes noisy or misses the deviation that actually matters.
Why RAG baselines have to be stage-specific
RAG is not one security behaviour, it is three different ones: indexing or writing content into the retrieval layer, querying that layer, and assembling context for the model. A useful baseline has to separate those stages because each has different normal volume, permissions, and error patterns. Permission-Aware RAG Guide shows why retrieval without permission-aware handling can turn routine indexing and search into over-sharing.
That separation matters operationally because one stage can drift while the others remain normal. For example, a noisy retrieval burst may be benign at query time but suspicious if it is happening during index writes, or an unusual context assembly pattern may indicate prompt shaping, data over-collection, or a broken guardrail even when the raw search traffic looks normal. CIS Benchmarks are useful here as a reminder that effective baselining works best when it is scoped to a specific control surface rather than treated as one generic security posture.
Stage-specific baselines also let teams ask different questions at each boundary. Indexing is about what enters the retrieval store, querying is about who can retrieve what, and context assembly is about what the application exposes to the model or downstream tool chain. If you collapse those into one alert profile, the signal becomes too broad to tell whether the issue is access, content quality, or orchestration.
What generic AI alerts miss in a RAG pipeline
Generic AI alerts tend to fire on broad anomalies such as unusual token counts, prompt length, or model usage spikes. Those signals can be useful, but they are too coarse to identify whether the real problem is excess write access to the index, inappropriate retrieval scope, or context that contains material the user should never see. In RAG, the security question is not just “was the system used unusually?” but “which stage behaved differently, and why?”
That is why RAG needs behavioural baselines tied to the actual workflow. A normal retrieval pattern can still hide a dangerous permission failure, while a model-side anomaly can be a downstream symptom of a retrieval problem rather than the root cause. AI Agent Observability, Audit and Incident Response Guide is relevant because the same logic applies when teams need attribution, alert quality, and a tested response path for autonomous or semi-autonomous behaviour.
Generic alerts also create tuning debt. If the detector is built around “AI activity” in the abstract, responders end up chasing harmless variance and missing the smaller deviations that matter, such as a retrieval job expanding its scope, a vector store receiving unexpected write patterns, or context assembly suddenly including out-of-policy sources. In practice, the most useful alert is usually the one that names the stage and the expected behaviour that has changed.
How to make RAG alerts actionable
Good RAG baselines start with the control point, not the model. The most practical split is to baseline index/write activity, retrieval activity, and context construction separately, then define what normal looks like for each. That usually means separate thresholds, separate ownership, and separate investigation paths, because the right responder for a retrieval permission issue may not be the same person who owns model prompting or data ingestion.
Behavioural baselines should also be permission-aware. If a user or service can query only a subset of the corpus, the baseline should reflect that expected retrieval envelope, not just average traffic. Otherwise, a malicious or broken change can stay hidden inside “normal” volume while quietly widening exposure. For that reason, RAG teams often pair behavioural alerting with access-control review and source-of-truth checks. NIST Cybersecurity Framework 2.0 aligns well with this approach because it encourages teams to govern, protect, detect, and respond around the actual asset and workflow.
When the pipeline includes external content, third-party tools, or shared indexes, the baseline should capture provenance and cross-boundary behaviour as well. If a retrieval pattern suddenly starts pulling from a new corpus, or a context builder begins including sources with different trust levels, that is not just a usage change, it is a governance change. SLSA is useful as a parallel for thinking about integrity and provenance, even though RAG is not a software build system.
Risk and Threat Considerations
RAG pipelines create a risk of silent overexposure when telemetry treats all AI activity as one bucket. Attackers and insider threats can exploit that by abusing write paths, broadening retrieval scope, or shaping context so sensitive material is surfaced without triggering an obvious generic AI alert.
Failure mechanism: The detector learns aggregate “normal AI behaviour” and loses visibility into stage-specific deviations, so permission failures, corpus drift, and abnormal context assembly blend into expected usage.
Impact: Sensitive documents can be indexed, retrieved, or passed into prompts outside their intended audience, creating disclosure risk, weak attribution, and delayed incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | RAG stages need stage-specific monitoring to spot abnormal retrieval and assembly behavior. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Permission-aware retrieval depends on enforcing access boundaries before content is surfaced. | |
| DE.AE-01 — Anomalies and Events Are Detected | Behavioral baselines exist to distinguish meaningful stage anomalies from ordinary AI usage. | |
| Recommendation — Monitor each RAG stage separately and alert on deviations from its own baseline. Enforce retrieval-time access checks so baselines reflect actual authorization scope. Define stage-specific expected behavior and detect deviations from it. | ||
| CIS Controls v8 | CIS-5 — Account Management | RAG alerting must align with who can write, query, and assemble context in the pipeline. |
| CIS-8 — Audit Log Management | Stage-specific baselines rely on logs that preserve query, write, and context events distinctly. | |
| Recommendation — Review account and service permissions for each RAG stage separately. Log RAG stage actions separately so alerts can be investigated by behavior type. | ||
Practitioner Guidance
What to prioritise: Baseline the three RAG stages separately before tuning any global anomaly detector. If you cannot tell whether the alert came from write, query, or context assembly behaviour, the alert is not yet operationally useful.
What to verify: Confirm that each stage has its own expected volume, permission boundary, and escalation path, and that the retrieval baseline reflects actual authorization scope rather than an average corpus pattern. If those three things are not distinct, the alerting model will overfit noise.
Common mistake: Treating token spikes or “AI usage anomalies” as sufficient evidence of a retrieval security problem. For RAG, the first question should be which stage changed, because that determines whether the fix belongs in access control, index hygiene, or context construction.
Practitioner takeaway: RAG alerting becomes useful only when it can explain the stage of failure, not just the presence of unusual AI activity; otherwise detection is broad enough to be comforting, but not precise enough to be actionable.
Related resources from NHI Mgmt Group
- Why do agentic AI systems need behavioural baselines instead of prompt filters?
- Why do behavioural baselines matter more when attackers use AI?
- What breaks when DLP relies on alerts instead of access control for AI agents?
- Why do AI SOC agents need environment-specific training instead of generic integrations?