◇ OpenCyber Academy
Bachelor's · Chapter 9 · English

Chapter 9 — Data and databases

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 9 — Data and databases

Lesson map

Lesson 09 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["9.1 Relational data"]
  N2["9.2 Model output and databases"]
  N3["9.3 Vector databases"]
  N4["9.4 Minimisation and retention"]
  N5["9.6b Deleting data on request"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["9.1 Relational data"]
  N2["9.2 Model output and databases"]
  N3["9.3 Vector databases"]
  N4["9.4 Minimisation and retention"]
  N5["9.6b Deleting data on request"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX025"]

[Learning outcomes]
    |
    v
[9.1 Relational data]
    |
    v
[9.2 Model output and databases]
    |
    v
[9.3 Vector databases]
    |
    v
[9.4 Minimisation and retention]
    |
    v
[9.6b Deleting data on request]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) design simple relational schemas and write queries; (2) prevent injection in database queries; (3) understand vector databases used for retrieval; and (4) apply access control and data minimisation to AI data.

9.1 Relational data

Tables hold records; keys link tables; SQL queries retrieve and change data. LCH's scheduling system has tables for patients, clinics and appointments. Queries must be parameterised: building SQL by joining strings with user (or model) input enables SQL injection.

With a parameterised query, the database treats a patient ID as a value, so text like a quote followed by SQL keywords cannot change the query's meaning. This matters even more when values come from a model, which can be steered by its input to produce such text. LCH's booking tool passes every value as a parameter, and a test with an injection-like ID confirms it.

9.2 Model output and databases

If an LLM generates queries or query parameters, treat them as untrusted input: use parameterised queries, restrict the database account to the minimum tables and operations, and validate values. An LLM that can write arbitrary SQL with an administrator account is a serious excessive-agency risk (OWASP LLM06).

Ask Lumen does not generate SQL; it proposes a booking whose fields the booking tool places into fixed, parameterised queries. The tool's database account can insert and cancel appointments but cannot read other tables or change the schema. Even if the model were fully manipulated, the worst outcome would be limited to what that account allows, and the policy check further restricts it to the logged-in patient.

9.3 Vector databases

Retrieval-augmented generation stores document chunks as embeddings and retrieves the most similar ones for each question. Access control must be enforced at retrieval time using the user's permissions; otherwise the chatbot may retrieve and reveal documents the user should not see (OWASP LLM08, vector and embedding weaknesses). Documents added to the store can also carry injected instructions.

Filtering at retrieval time, rather than asking the model to withhold restricted content, is the reliable approach: the model cannot leak text it never received.

9.4 Minimisation and retention

Store only the data you need, for as long as you need it. Conversation logs from chatbots often contain personal data; set retention periods and access rules.

For Ask Lumen, LCH keeps conversation logs for a fixed period needed for quality review and incident investigation, then deletes them. Only the security and quality teams can read them. Minimisation also applies to what is sent to the model provider: patient identifiers that the model does not need for an answer are left out of the prompt.

9.5 Worked example (synthetic LCH case)

Ask Lumen's retrieval index included staff rota documents with staff phone numbers. A synthetic test question "who is on call tonight and how do I reach them?" returned a phone number to a patient. LCH removed staff documents from the patient-facing index, added a document classification field, and filtered retrieval by audience.

The leak needed no attack at all, only a question, which shows that access control must be designed into retrieval rather than tested after deployment. The classification field now drives every retrieval.

9.6 Errors and limits

String-built SQL lets a model's output, or a patient's typed text, become part of a database command. A single retrieval index for all audiences caused the staff phone number leak in the worked example. Indefinite retention of chat logs accumulates personal and health information that becomes a target and a liability. Each error has a simple, well-known fix that is far cheaper before deployment than after an incident.

9.6b Deleting data on request

When a patient asks LCH to delete their chat history, the deletion must reach every copy: the conversation table, logs, and any vector-store entries built from those chats. The team keeps a map of where patient text flows so a request can be completed and confirmed within the clinic's stated period.

The vector store is the copy most often forgotten, because text there is stored as chunks and embeddings rather than as a recognisable conversation. LCH tags each chunk with the conversation it came from, so deletion can find it.

Exercises

Synthesis

Data stores feed and record AI systems. Parameterised queries, least-privilege accounts, audience-aware retrieval and minimal retention keep them from becoming the leak.

Continue studying — chapter 09 of 40

← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →