Retrieval-augmented generation, embeddings and vector stores, and watermarking what a model produces

Why this matters

Most organisations do not train models. They connect an existing model to their own documents, and the usual way to do that is retrieval-augmented generation. That makes RAG the architecture a security team is most likely to be asked to review, and its weak points are not where people expect. The model is rarely the problem. The problem is the new copy of the organisation's documents sitting in a vector store, usually without the permissions those documents had at source, behind an assistant that will cheerfully summarise whatever it retrieves for whoever asks.

Embeddings sit underneath that copy, and they are widely misunderstood as an anonymised or one-way form of the data. They are neither, and treating them as safe to share is how sensitive content leaves through a side door.

Watermarking belongs here because it is the other half of data security for generative AI: not keeping data in, but being able to recognise model output, or your own data, when it turns up elsewhere. It is also oversold, and knowing its limits is what scenario questions test.

The lesson

Embeddings: turning text into vectors, and what can be recovered from a vector

An embedding is a list of numbers, a vector usually with hundreds or thousands of dimensions, produced by an embedding model from a piece of text, an image or other content. The model is trained so that content with similar meaning produces vectors that lie close together. "How do I reset my password?" and "I'm locked out of my account" end up near each other even though they share almost no words. Closeness is measured mathematically, commonly with cosine similarity.

That property powers semantic search, clustering, duplicate detection, classification and the retrieval step in RAG.

The security point is that an embedding is derived from its source and keeps much of its meaning. It is not encryption and it is not anonymisation. Research has shown that text can be substantially reconstructed from its embeddings, and that attributes of the source, such as the topic, a medical condition or a named person, can be inferred from vectors even when the text cannot be recovered in full. So:

• Classify embeddings at the level of their source. Vectors of HR case notes are HR case notes for handling purposes.
• Do not share them as a safe substitute for the data with a partner or a vendor.
• Expect retrieval to be manipulable. A document written to sit close to many likely questions will be retrieved often, which is a way to push content into answers. OWASP lists this family of risk as Vector and Embedding Weaknesses (LLM08).

Embeddings are specific to the model that made them. Changing the embedding model means re-embedding everything, which is worth knowing when a scenario asks about replacing a compromised or deprecated model.

Vector storage, and why a vector database is a data store with access-control needs of its own

A vector store (or vector database) holds embeddings and finds the nearest ones to a query quickly. Some are dedicated products; others are extensions to existing databases or search engines. What matters for security is what each record contains: the vector, the original chunk of text it was made from, and metadata such as the source document, its owner and its date.

The chunk text is usually stored in clear alongside the vector, because the application needs it to build the prompt. A vector store is therefore not an index pointing at your documents; it is another copy of them, and it needs everything any data store needs:

• Authentication and authorisation on the store itself. Development instances are often deployed with no authentication and then promoted. An open vector endpoint is a document leak, not a curiosity.
• Query-time access control. Each chunk should carry the permissions of its source, and the retrieval layer should filter results by the requesting user's identity on the server, before anything reaches the model. Lesson 11 covers data access in detail.
• Tenant separation. In a multi-customer service, a separate index or namespace per tenant is stronger than one shared index relying on a metadata filter, because a single missing filter exposes everyone.
• Write control. Whoever can add or change records can poison what the assistant says. Ingestion should run under its own identity, from approved sources only.
• Synchronisation. When a source document is deleted or its permissions change, the store must follow, or it keeps serving what the source has withdrawn.
• Encryption, backups, retention and logging, as for any store of that classification.

Retrieval-augmented generation as an architecture, and the documents it can expose

Retrieval-augmented generation (RAG) gives a model relevant information at the moment it answers, instead of relying only on what it learned in training. It has two flows.

Ingestion: load documents, split them into chunks, embed each chunk, and store the vectors with their text and metadata.

Query: embed the user's question, retrieve the closest chunks, place them in the prompt with instructions to answer from them, and generate an answer, ideally citing which chunks it used.

The benefits are real. Answers reflect current documents without retraining, citations let users check them, and grounding reduces, though never removes, hallucination. Lesson 2 builds a small RAG app so you can watch each step.

Consider an HR assistant built over the HR department's file share. What can it expose?

• Documents the user should not see. If ingestion took the whole share and retrieval ignores permissions, any employee asking about pay can be handed a chunk of the salary review spreadsheet. The model did nothing wrong; it answered from what it was given.
• More than was meant to be ingested. Shares contain drafts, exports and personal folders. Ingest the minimum, from named sources, deliberately.
• Instructions inside documents. Retrieved text enters the model's context as tokens like any other, so a document containing instructions can steer the answer. This is indirect prompt injection, covered in lesson 17.
• Verbatim sensitive text, quoted straight into an answer, and copied again into the prompt and response logs.
• Stale or withdrawn content that the store still holds.

The controls follow the same order: minimise what is ingested, carry source permissions into metadata, filter by identity before retrieval, mark retrieved text as untrusted data in the prompt template, limit how many chunks are returned, and log retrievals so you can see what was served to whom.

Watermarking model output and training data, and what it can and cannot prove

Watermarking embeds a signal in content that a detector can later find.

Output watermarking marks what a model produces. For text, one approach nudges the model's choice of tokens in a pattern that is invisible to a reader but statistically detectable by someone holding the key. For images, audio and video, the signal is hidden in the media itself. A related technique attaches signed provenance metadata to a file, recording what created or edited it; industry standards exist for this, but metadata is easy to strip, so it complements a watermark rather than replacing it.

Training data watermarking marks a dataset, for example by including unique, deliberately planted records, so that a model trained on it can later be shown to have learned from it. It is a way to detect that your data was used without permission. A related idea marks a model's weights or behaviour so that a stolen copy can be identified, which links to model theft in lesson 19.

What a watermark can support: a strong detection is good evidence that the content came from a system using that watermark, or that a model saw the marked data.

What it cannot prove:

• Absence proves nothing. Many models do not watermark at all, so unmarked content may still be generated.
• It can be removed. Paraphrasing, editing, translating, cropping or re-encoding can weaken or destroy a watermark.
• Short content gives a weak signal. A sentence carries too little text for a confident statistical test.
• Detection depends on the key holder. Usually only the provider can check its own watermark.
• It says nothing about truth or intent. A watermark identifies a source system, not who prompted it or whether the content is accurate.
• False positives exist. Detection is a probability, not a certainty.

The exam framing is that watermarking is one piece of evidence within a provenance process, never proof on its own.

Choosing between fine-tuning and retrieval when the data is sensitive

Both put organisational knowledge into an assistant's answers. They do it in opposite places, and that decides the security outcome.

Fine-tuning puts the data into the weights. That means:

• no per-user permissions: the model knows the same things for everyone;
• no clean deletion: removing a person's data generally means retraining;
• memorisation risk: the model may repeat training records verbatim;
• the weights become as sensitive as the data.

Retrieval keeps the data in a store and fetches it per request. That means:

• per-user access control at query time;
• deletion that takes effect when the record leaves the index;
• citations that let answers be checked;
• but a new copy of the data to secure, documents travelling into prompts (to a provider, if the model is hosted), and exposure to indirect injection.

The working rule is to fine-tune for behaviour and retrieve for facts. Use fine-tuning to teach a format, a tone or a narrow skill from data that is not sensitive; use retrieval for knowledge that is sensitive, permissioned or changing. The two combine well.

In a scenario, three requirements settle the choice. Different users must see different documents: retrieval with permission filtering. Individuals' data must be deletable on request: retrieval. The data must never leave the organisation at all: either approach can satisfy it, but only with a locally hosted model, which is a hosting decision rather than an architecture one.

What the exam is really asking

RAG scenarios usually describe a leak and ask where the control was missing. Work along the pipeline. If a user received content from a document they could not open at source, the failure is query-time access control in the retrieval layer, not the model and not the system prompt. If the vector store was reachable without credentials, it is the store's own authentication. If the assistant repeated an instruction that came from a document, it is indirect prompt injection, contained by treating retrieved text as data and limiting what the assistant can do. If somebody claims embeddings are safe to hand to a vendor because they are "just numbers", that is the misconception being tested. And if a question asks whether a watermark proves a piece of text was written by a person, the answer is that a missing watermark proves nothing at all.