Notifications
Clear all
Topic starter
06/06/2026 2:21 am
TL;DR: RAG connects models to live internal knowledge, but that architecture creates security risks around poisoned documents, over-permissioned retrieval, data leakage, embeddings, and third-party components that legacy tools were not built to govern, according to WitnessAI. The governance problem is structural: access, trust, and output controls must be designed for the retrieval pipeline, not assumed from traditional IAM or DLP.
NHIMG editorial — based on content published by WitnessAI: RAG security risks and how enterprises can address them
Questions worth separating out
Q: How should security teams govern access in RAG systems?
A: Security teams should govern RAG access at the retrieval layer, not only at authentication.
Q: Why do RAG deployments create more data exposure risk than standard chat systems?
A: RAG deployments connect the model to live enterprise content, so the model can surface data that was never meant to be public within that workflow.
Q: What breaks when retrieval permissions are too broad in RAG?
A: Broad retrieval permissions collapse data separation.
Practitioner guidance
- Tighten retrieval entitlements by collection Map each RAG use case to the minimum set of collections it needs, then bind those collections to user and service account entitlements.
- Treat ingestion as a privileged write path Require provenance checks, signed source attestation, and approval for any process that writes into the knowledge base or vector store.
- Apply response-layer filtering before output leaves the model Use tokenization, redaction, and authorization checks on generated responses before they reach end users or downstream systems.
What's in the full article
WitnessAI's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step controls for securing the ingestion path, including provenance validation and restricted write access.
- Implementation detail on runtime data tokenization, response authorization, and bidirectional scanning.
- Practical guidance on handling vector database poisoning and anomaly signals across retrieval patterns.
- Coverage of supply chain exposure across orchestration frameworks, embedding providers, connectors, and MCP servers.
👉 Read WitnessAI's full analysis of RAG security risks and controls →
RAG security gaps: what IAM teams need to govern now?
Explore further
06/06/2026 3:59 am
RAG security is an identity governance problem before it is a model-safety problem. The article shows that the decisive control points sit in retrieval permissions, ingestion provenance, and runtime output handling. That is exactly where identity, access, and data governance intersect, so the operating model must be built as a control plane for access to knowledge rather than a model-only safeguard. Practitioners should treat retrieval scopes as enforceable entitlements, not implementation details.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- That confidence gap persists alongside a separate finding that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which keeps retrieval and delegation risks hidden.
A question worth separating out:
Q: How do organisations reduce supply chain risk in RAG pipelines?
A: Organisations should review every component that can shape retrieval, indexing, or output, including orchestration frameworks, connectors, vector databases, and embedding providers. The practical test is whether the component can write, read, or move sensitive data. If it can, it needs inventory, logging, and governance alongside the rest of the production stack.
👉 Read our full editorial: RAG security gaps show why legacy IAM controls are not enough
