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.
Why This Matters for Security Teams
RAG supply chains are risky because the attack surface is not just the model. It includes the retriever, chunking logic, orchestration layer, connectors, embedding service, vector store, and the secrets that let each piece talk to the next. If any of those components can write, read, or move data, they can also leak it, tamper with it, or redirect outputs. That is why NHI governance has to extend beyond the application perimeter and into build pipelines, service accounts, and third-party dependencies. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward inventory, access control, and continuous monitoring as baseline controls, not optional extras. NHIMG research shows why this matters in practice: the CI/CD pipeline exploitation case study demonstrates how quickly production trust can collapse when pipeline credentials are exposed. In practice, many security teams encounter RAG risk only after a connector, package, or runner has already been used to move sensitive data out of scope, rather than through intentional supply chain review.
How It Works in Practice
Reducing supply chain risk in RAG pipelines starts with treating every dependency as a governed identity-bearing component. That means mapping who or what can access the retriever, where embeddings are generated, which indexes can be updated, and which services can export prompts or documents. Security teams should classify each component by blast radius: can it read source data, alter embeddings, inject retrieved context, or exfiltrate outputs? If yes, it needs an owner, logging, and a control path for revocation.
Practical controls usually include:
- Inventorying all orchestration frameworks, plugins, connectors, vector databases, and model gateways.
- Using short-lived secrets and workload identity instead of shared long-lived API keys.
- Scanning dependencies, container images, and pipeline runners for hardcoded secrets before release.
- Separating ingestion, indexing, retrieval, and generation permissions so one compromise does not become full pipeline compromise.
- Recording prompts, retrieval events, and index mutations for forensic review.
That approach is reinforced by NHIMG incident research such as the Reviewdog GitHub Action supply chain attack, where a trusted automation path became a secrets exposure path, and by the Guide to the Secret Sprawl Challenge, which shows how fragmented secret handling undermines central control. In secrets-heavy environments, this is not theoretical: NHIMG research in The State of Secrets Sprawl 2026 found 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. These controls tend to break down when the RAG stack depends on many ephemeral connectors and developer-managed secrets because ownership becomes unclear and revocation lags behind deployment.
Common Variations and Edge Cases
Tighter supply chain control often increases delivery overhead, requiring organisations to balance faster experimentation against stronger release governance. That tradeoff is especially visible in RAG pilots, where teams want to add new sources quickly but may not have a stable approval process for connectors, embedding providers, or managed vector stores. Best practice is evolving, but current guidance suggests that any component capable of reading proprietary content or influencing retrieval should be treated like a sensitive production dependency, even if it is “just a plugin.”
Two edge cases matter. First, private repositories are not automatically safer than public ones. Internal code often contains the most useful secrets, so the review standard should be the same across environments. Second, out-of-band sources such as ticketing systems, chat, and documentation platforms can be as dangerous as code because prompts and credentials often live there during troubleshooting. That is why many organisations pair code scanning with secrets governance across collaboration tools and CI systems.
For alignment, 52 NHI breaches Analysis is a useful reminder that non-human identities are frequently the real failure point, not the model itself. When the pipeline spans external vendors, temporary runners, and multiple trust domains, the right answer is not more trust in the stack. It is narrower permissions, faster revocation, and explicit accountability at every hop.
Related resources from NHI Mgmt Group
- How can organisations reduce the risk of webhook-driven SaaS supply chain attacks?
- How should security teams reduce supply chain risk in GitHub-based development pipelines?
- How can organisations reduce NHI risk without breaking production?
- When should organisations treat an NHI as a high-priority risk?
