Why do RAG systems create new security and governance problems?

RAG systems combine data retrieval, model inference, and observability into one workflow, so a weakness in any layer can affect quality or expose sensitive data. They also rely on multiple machine identities, which increases the chance of stale keys, overbroad access, and trace data leakage if lifecycle controls are weak.

Why This Matters for Security Teams

RAG changes the security boundary because it blends enterprise data, retrieval infrastructure, model prompts, and logging into a single decision path. That means a compromise does not need to defeat the model itself to create harm. Attackers can target indexed content, connector permissions, prompt inputs, or the telemetry pipeline that captures prompts and outputs. Current guidance suggests treating RAG as a governed data access workflow, not just an AI feature.

This matters because security teams often assume the risk sits only in the LLM layer, when the larger exposure is usually in retrieval sources and operational controls. If a document store contains sensitive records, or if an indexer has broad read access, the system can surface data the user was never meant to see. The NIST Cybersecurity Framework 2.0 remains useful here because it forces a view across governance, protect, detect, and respond instead of treating the model as an isolated asset. In practice, many security teams encounter RAG failure only after a bad answer or data leak has already been captured in logs, rather than through intentional control testing.

How It Works in Practice

A RAG system usually pulls content from one or more repositories, ranks the most relevant passages, injects them into a prompt, and sends that composite context to the model. Each step creates a distinct control surface. Retrieval can expose over-permissioned content, the prompt can be manipulated by adversarial text, and the output layer can repackage sensitive material in a way that is hard to detect with traditional DLP alone. For that reason, governance needs to cover both the data plane and the inference plane.

Practitioners usually need controls in four areas:

• Source governance, including classification, freshness, and ownership of indexed content.
• Connector security, including scoped service accounts, key rotation, and audit logging.
• Prompt and output controls, including injection screening, redaction, and human review for high-risk use cases.
• Telemetry governance, including retention limits, access restrictions, and clear handling rules for traces and transcripts.

Frameworks such as NIST AI Risk Management Framework and MITRE ATLAS are helpful because they map this to AI-specific threat and risk management rather than generic software assurance. Where RAG is used with autonomous tool use, the boundary between retrieval and action becomes even more sensitive, and controls from OWASP guidance for LLM applications are often relevant to prompt injection and indirect prompt injection scenarios.

These controls tend to break down when the RAG stack spans multiple teams and cloud services because ownership of sources, indexes, prompts, and logs becomes fragmented.

Common Variations and Edge Cases

Tighter retrieval and logging controls often increase latency, implementation effort, and operational overhead, so organisations need to balance answer quality against governance friction. Best practice is evolving, especially where RAG is used for internal knowledge search, regulated customer support, or agentic workflows that can take actions after retrieval. There is no universal standard for this yet.

One common edge case is multi-tenant RAG, where one index serves several business units or customers. In that model, access segmentation must be enforced at retrieval time, not only at the user interface. Another is “thin” RAG, where only a small set of documents is retrieved, creating a false sense of safety while stale or poisoned source material still influences answers. A third is observability leakage: prompt traces, embeddings, and cached responses may expose secrets, personal data, or internal strategy unless they are governed as sensitive records.

Where RAG is paired with non-human identities, the identity problem becomes more visible. Service principals, API keys, and agent credentials should be treated as privileged access paths with lifecycle control, not as implementation details. In highly regulated environments, the governance answer may be to restrict RAG to approved corpora, require review for externally facing outputs, and maintain explicit lineage from source document to model response. The NIST Cybersecurity Framework 2.0 and industry security guidance on generative AI applications both point toward this kind of layered control model.

Related resources from NHI Mgmt Group

• Why do RAG systems create a new attack surface for AI governance?
• Why do non-human identities create special governance problems in agentic systems?
• Why do AI systems create NHI governance problems?
• Why do agent tool chains create new identity governance problems?