AI Security
Advanced 13 min read AI Security

Data Leakage

Containing every copy

Leakage means model-visible data escaping the system: via responses, logs, embeddings, memory, or evals/training. Containment is about every copy — because models amplify whatever they can reach.

data leakageexfiltrationembeddingslogsmemorytenant isolation
Prerequisites: PII Handling
Before we start

What you will learn

  • Map where data copies live
  • Test for cross-tenant leakage
  • Scrub logs and embeddings
Introduction

What is this?

Data leakage is confidential material appearing where it shouldn't: in another tenant's response, in logs, in embedding stores, in memory, or in training/eval data. Prevention is copy control: tenant isolation at every store, PII scrubbers on outputs and logs, and minimal-data principles.

Motivation

Why do you need it?

  • LLM pipelines copy data into many new places (caches, vectors, memory).
  • Cross-tenant leakage is the highest-severity failure class.
  • Embeddings retain retrievable secrets — hidden exfiltration channel.
  • Once data lands in logs/training, recall is nearly impossible.
Think about it

Mental model

Imagine

Shredding vs. storing in one shared bin

Think of

Leakage

A hospital that keeps patient charts in a single shared drawer is leaking by architecture. Proper practice: separate lockers per tenant (isolation), destroy copies on release (scrubbers), and know where every copy lives (inventory). Leakage rarely 'happens'; it's designed in.

Mechanics

How it works

  • Inventory wherever data copies land: context, vectors, memory, logs, caches.
  • Enforce tenant isolation per store (scoped keys).
  • Scrub PII from outputs, logs, and eval sets.
  • Restrict what embeds/memory retain (minimal + ttl).
  • Test leakage: cross-tenant probes in CI.

Copy inventory.

Source
Context
Stores
Outputs
Scrub
Real world

In production

  • Multi-tenant chat enforces scoped vector/memory namespaces.
  • Log pipelines strip messages before retention.
  • Embedding stores exclude confidential fields; ttl applied.
Guidelines

Best practices

  • Tenant isolation: scope keys in every store, test it.
  • Minimal data: send only what the task requires.
  • PII scrub on every output AND every log line.
  • Inventorize data copies; new store = new entry + test.
Watch out

Common mistakes

  • One shared vector index for all tenants (blend on retrieval).
  • Logging full prompts 'for debugging' with no scrub.
  • Cold eval sets seeded with live confidential conversations.
Root cause analysis

Common issues

Error
Tenant A sees Tenant B data
Root cause

Unscoped retrieval

Fix

Scope every query + index by tenant; add negative CI tests.

Error
Data in training artifacts
Root cause

Live data harvested at eval

Fix

Re-identify + scrub before dataset publish; block known fields.

When things break

Debugging tips

  • Cross-tenant hit → shared store missing scope; add tenant key + test.
  • PII in logs to find → centralized scrub gate on log pipeline.
  • Embedding recall leaks → exclude confidential fields from embedding input.
Interviews

Interview checkpoint

Practice

Hands-on lab

Redact Before Logging
25 min · intermediate
In progress
Objectives
  • Model a request payload with secrets
  • Mask sensitive keys before logging
  • Verify raw secrets never reach log lines

Redact Before Logging

25 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

A hidden exfiltration channel is…

2

Per-tenant isolation in vector stores prevents blends.

Go deeper

Official documentation

OWASP LLM10: Sensitive info disclosure
docs