Retrieval-Augmented Generation Vendor Risk: Data Leakage, Access, And Provenance

Retrieval-augmented generation vendor risk is the risk created when an AI service retrieves enterprise information from documents, databases, vector stores, or connected systems and uses that material to generate an answer. RAG can improve relevance and provide citations, but it also creates new paths for unauthorized retrieval, cross-tenant leakage, poisoned content, stale permissions, weak provenance, and sensitive output.

A TPRM review must evaluate the full retrieval pipeline, not only the foundation model. This guide explains what to ask about ingestion, embeddings, vector storage, access enforcement, source integrity, deletion, logging, citations, output controls, and downstream actions.

What changes when a vendor uses RAG

A conventional AI service receives a prompt and sends context to a model. A RAG service adds a knowledge pipeline: content is collected, parsed, chunked, embedded, indexed, retrieved, inserted into the model context, and transformed into output. Each step has its own owner, data copy, permission decision, retention period, and failure mode.

The OWASP RAG Security Cheat Sheet describes this as a distinct attack surface across ingestion, embeddings, vector storage, retrieval, generation, and output. For TPRM, the practical conclusion is simple: “the vendor uses our permissions” is not enough. The review needs evidence showing where and how those permissions are enforced.

Map the complete RAG architecture

Ask the vendor for a data-flow and trust-boundary diagram covering:

Source repositories, connectors, uploads, crawlers, APIs, and synchronization jobs.
Parsing, optical character recognition, chunking, metadata extraction, classification, and malware scanning.
Embedding models, vector databases, indexes, caches, and backup locations.
Identity, authorization, tenant isolation, retrieval filters, and administrative access.
Foundation-model providers, hosting, gateways, prompts, logs, and subprocessors.
Response generation, citations, policy filters, exports, agents, plugins, and tools.

For every component, record legal entity, region, data categories, retention, encryption, keys, access, incident responsibility, and exit method. A SaaS vendor may operate the application while separate providers supply the embeddings, model, vector database, cloud, observability, and content connectors.

Control ingestion before content becomes trusted context

RAG systems can ingest malicious, obsolete, misclassified, or unauthorized documents. A poisoned document may contain hidden instructions intended to influence later answers. A legitimate file may be risky because it contains credentials, privileged legal advice, personal data, or information the uploader was not authorized to share.

Review source approval, uploader identity, malware scanning, file-type controls, sensitive-data discovery, duplicate handling, document classification, versioning, and quarantine. The vendor should distinguish trusted enterprise sources from user uploads and external content. Automated ingestion should not turn every connected file into authoritative evidence.

Record provenance at ingestion: source system, original location, owner, uploader or connector, timestamp, version, classification, permissions, approval, and a durable content identifier or hash. This metadata is essential for investigation and citation later.

Require permission inheritance at chunk level

Document permissions can be lost when a file is split into chunks and converted into embeddings. A shared vector store may then retrieve a restricted chunk for a user who could not open the source document. Permission checks performed only when content is ingested also become stale after a user changes role or a document is restricted.

Ask whether every chunk carries tenant, owner, classification, role, group, and source-permission metadata. Authorization should be checked at retrieval time using the current identity and policy. Test negative cases: a user without source access, a removed user, a document whose permissions changed, two tenants with similar content, and an administrator with limited business need.

Do not rely on the language model to hide information it has already received. Access control must prevent unauthorized content from entering the model context.

Assess tenant and index isolation

Determine whether customers, departments, confidentiality levels, or regions share indexes, caches, encryption keys, and administrative planes. Logical separation can be appropriate when it is designed, tested, monitored, and supported by tenant-aware authorization. High-impact use cases may require dedicated indexes, storage, or keys.

Evidence can include architecture, configuration extracts, tenant identifiers in retrieval queries, authorization tests, penetration-test scope, logging examples, and incident procedures for cross-boundary retrieval. Ask how backup restoration preserves isolation and how support personnel troubleshoot without viewing sensitive content.

Review embeddings and vector data as sensitive assets

Embeddings are derived data, not harmless metadata. They can encode characteristics of source content and remain useful after the original file changes. Treat vector stores, indexes, cached passages, query logs, and generated answers according to the sensitivity of the source data.

Review encryption, key ownership, privileged access, backup, export, retention, deletion, integrity, monitoring, and environment separation. Ask whether the embedding provider receives customer content and whether inputs or outputs are retained or used for training, evaluation, or product improvement.

A practical RAG vendor review workflow

1. Define the use case and impact

Identify users, decisions, data, sources, output recipients, integrations, regulatory context, and business consequence of an incorrect or leaked answer. A public knowledge assistant and a legal research tool need different assurance.

2. Map the pipeline and suppliers

Document ingestion through output, including model, embedding, vector, hosting, observability, and connector providers. Confirm data regions and fourth-party responsibilities.

3. Test content governance

Sample approved and prohibited sources. Review upload authority, validation, classification, versioning, poisoning defenses, and provenance. Confirm that untrusted content is treated as data rather than executable instruction.

4. Test authorization boundaries

Use positive and negative test identities across roles, tenants, revoked access, changed permissions, and restricted sources. Validate authorization before retrieval and before any downstream action.

5. Validate answer traceability

Check whether answers identify retrieved sources and the exact passages used. Confirm that citations resolve to content the user may access, refer to current versions, and cannot be altered without detection.

6. Test retention and deletion

Delete or de-permission a source and verify removal from chunks, embeddings, indexes, caches, generated-answer stores, and future retrieval. Record backup treatment and expected propagation time.

7. Review output and action controls

Test sensitive-data filters, unsupported-answer handling, structured-output validation, human review, rate limits, and tool authorization. A cited answer can still be misleading or unsafe.

8. Make and monitor the decision

Document residual risk, restrictions, conditions, owners, monitoring, incident triggers, model or provider change triggers, review dates, and exit requirements.

Demand useful provenance and citations

A citation should identify the source, version, location, retrieved passage, and access scope. It should allow an authorized reviewer to verify that the answer is grounded in the cited material. A link to a large repository or a filename without version context is weak provenance.

Ask how the vendor detects stale, conflicting, superseded, or deleted sources. If multiple documents disagree, the system should not quietly select one without exposing uncertainty. For decision-support use cases, retain the query, user, retrieved chunks, source versions, model and configuration, output, and human disposition.

Prevent retrieved content from becoming commands

Documents may contain text that looks like instructions to the model. The application should isolate retrieved data from system instructions and apply controls outside the model. This matters most when RAG output can trigger tools, send messages, update records, approve transactions, or retrieve more data.

Require deterministic authorization for each action, allowlisted tools and parameters, schema validation, least-privilege service identities, rate limits, monitoring, and human approval for material actions. The user being allowed to read a document does not automatically authorize the model to act on every instruction in it.

Plan cascading deletion and permission changes

Removing a source file should trigger removal or invalidation of derived chunks, embeddings, index entries, caches, and generated outputs where required. Permission changes should propagate to retrieval quickly enough for the risk. Test what happens during synchronization failures and how orphaned chunks are detected.

Contracts should address data return, deletion, retained logs, backups, subprocessors, derived data, embeddings, model improvement, and deletion evidence. Exit planning should cover usable exports of sources, metadata, configurations, audit history, and any customer-owned indexes.

Monitor the controls that can drift

Track failed authorization checks, cross-tenant test results, anomalous retrieval volume, poisoned-source detections, orphaned chunks, stale indexes, deletion failures, sensitive-output alerts, citation errors, model or embedding changes, subprocessor changes, and security incidents. Reassess when new repositories, users, regions, tools, or automated actions are added.

Evidence for a defensible decision

Retain architecture and data flows, supplier lists, source governance, access-control design, tenant isolation evidence, test cases and results, penetration-test scope, retention and deletion tests, output-filter tests, incident procedures, contract clauses, findings, approval conditions, and monitoring plans. Record limitations honestly when vendor evidence does not cover the exact service or configuration.

Common mistakes

Reviewing the foundation model but not the retrieval pipeline.
Assuming source-document permissions automatically apply to chunks.
Sharing vector stores or caches without effective tenant boundaries.
Allowing any connected content to become trusted context.
Treating embeddings as non-sensitive technical metadata.
Deleting the source while leaving chunks and cached answers searchable.
Showing citations that do not prove which passages influenced the answer.
Letting the model enforce authorization or approve tool actions.

Analyst takeaway

A RAG vendor is a data-processing and authorization system wrapped around an AI model. Review who can add knowledge, how permissions survive chunking, where derived data lives, how retrieval is isolated, whether sources can be verified, and how deletion propagates. Strong controls prevent unauthorized information from reaching the model and keep generated output from bypassing business rules.

Frequently asked questions

What is retrieval-augmented generation vendor risk?

It is the third-party risk created by collecting, transforming, storing, retrieving, and generating answers from enterprise knowledge through an external AI service and its supporting providers.

Can document permissions be lost in a RAG system?

Yes. Chunking and embedding can separate content from source permissions. Effective systems carry authorization metadata to each chunk and enforce current permissions at retrieval time.

Are embeddings considered sensitive data?

They are derived from source content and should be protected according to source sensitivity and applicable obligations. Reviews should cover access, isolation, encryption, retention, deletion, and provider use.

How should a TPRM team test RAG deletion?

Delete or de-permission a source and verify that its chunks, embeddings, index entries, caches, and future retrieval are removed or blocked within the approved period, including documented backup treatment.

Do citations make a RAG answer trustworthy?

No. Citations improve traceability only when they identify the actual source and passage, respect user access, reflect the correct version, and support the answer. Output still requires validation proportionate to its use.