Embedding- en vectorbeveiliging
Hoe embeddings een verborgen aanvalsoppervlak vormen in AI-systemen: beveiligingsgrenzen van vectordatabases, aanvallen op embeddingniveau en manipulatie van RAG-retrieval.
Embeddings vormen de basis voor het vermogen van moderne AI-systemen om informatie te doorzoeken, op te halen en erover te redeneren. Elke RAG-pipeline (retrieval-augmented generation), elk semantisch zoeksysteem en elke AI-gestuurde aanbevelingsengine vertrouwt op embeddings om tekst, beelden en andere data om te zetten in numerieke vectoren die je kunt vergelijken en doorzoeken. Door die alomtegenwoordigheid is de embedding- en vectorinfrastructuur een kritiek aanvalsoppervlak dat in security-assessments vaak over het hoofd wordt gezien.
Waarom embeddings een beveiligingsrisico zijn
Embeddings zien eruit als simpele numerieke vectoren — lijsten van floating-point getallen zonder duidelijke semantische inhoud. Die schijnbare ondoorzichtigheid wekt een vals gevoel van veiligheid. In werkelijkheid coderen embeddings rijke semantische informatie over de data die ze representeren, en die informatie kun je extraheren, manipuleren en misbruiken.
De informatieparadox
Embeddings zijn ontworpen om semantische betekenis vast te leggen: twee teksten met een vergelijkbare betekenis horen vergelijkbare embeddings te hebben. Door die eigenschap werkt semantisch zoeken. Maar het betekent ook dat embeddings genoeg informatie over de oorspronkelijke tekst bevatten om reconstructie-aanvallen mogelijk te maken. Onderzoek heeft aangetoond dat embeddingvectoren geïnverteerd kunnen worden om aanzienlijke delen van de oorspronkelijke invoertekst te herstellen.
Dat levert een paradox op: hoe nuttiger een embedding is voor retrieval (hoe meer semantische informatie hij vastlegt), des te meer informatie hij lekt over de oorspronkelijke inhoud. Organisaties die embeddings van gevoelige documenten opslaan, slaan in feite een gecomprimeerde maar herstelbare versie van die documenten op.
De verborgen datastroom
In een typisch RAG-systeem stroomt data door verschillende fasen:
Brondocumenten → Chunking → Embedding-model → Vectordatabase → Retrieval → LLM
↑ ↑ ↑ ↑ ↑
Gevoelige Grens- Omzetten Opslag van Selectie
data beslissingen naar vectoren vectoren & ranking
Beveiligingsmaatregelen worden doorgaans toegepast op het niveau van het brondocument (toegangscontrole) en op het niveau van de LLM-output (contentfiltering). De tussenliggende fasen — chunking, embedding, vectoropslag en retrieval — missen vaak gelijkwaardige beveiligingsmaatregelen. Door dat gat kunnen aanvallen die op embedding- en vectorniveau opereren de maatregelen aan beide uiteinden omzeilen.
De aanvalstaxonomie
In dit gedeelte delen we beveiligingsdreigingen rond embeddings en vectoren in drie categorieën in.
Beveiliging van vectordatabases
Vectordatabases (Pinecone, Weaviate, Chroma, Milvus, Qdrant) zijn de opslaglaag voor embeddings. Ze vormen een nieuw soort uitdaging op het gebied van databasebeveiliging, omdat hun querymodel — similarity search — fundamenteel verschilt van traditionele SQL- of documentqueries. Aanvallen in deze categorie richten zich op toegangscontrole, injectie en data-exfiltratie op databaseniveau.
Belangrijke aandachtspunten zijn onder meer:
- Gaten in toegangscontrole — API-keybeheer, tenantisolatie en namespacebeveiliging in vectordatabases
- Injectie-aanvallen — embedding-poisoning, metadata-injectie en manipulatie van similarity search
- Data-exfiltratie — embedding-inversie om opgeslagen documenten te reconstrueren, enumeratie-aanvallen en op similarity gebaseerde data-oogst
Voor een uitgebreide behandeling, zie het subhoofdstuk Vector Database Security.
Aanvallen op embeddingniveau
Aanvallen op embeddingniveau richten zich op de vectoren zelf in plaats van op de database die ze opslaat. Deze aanvallen misbruiken de wiskundige eigenschappen van embeddingruimtes om adversarial invoer te maken, oorspronkelijke inhoud te herstellen of membership in trainingssets af te leiden.
Belangrijke aanvalstypen zijn onder meer:
- Adversarial embeddings — invoer maken die embeddings produceert die semantisch dicht bij de doelinhoud liggen maar kwaadaardige payloads bevatten
- Inversie-aanvallen — oorspronkelijke tekst reconstrueren uit embeddingvectoren, met aanzienlijke gevolgen voor de privacy
- Membership inference — bepalen of specifieke data in de trainingsset van het embedding-model zat
Voor een uitgebreide behandeling, zie het subhoofdstuk Embedding-Level Attacks.
Beveiliging van RAG-retrieval
RAG-systemen gebruiken embeddings om relevante context op te halen voor de generatie door het taalmodel. Aanvallen op de retrievalpipeline kunnen manipuleren welke informatie het model bereikt en zo de output beïnvloeden zonder rechtstreeks prompts te injecteren.
Belangrijke aanvalstypen zijn onder meer:
- Retrieval-manipulatie — chunks vergiftigen zodat ze hoger ranken in similarity search, chunkinggrenzen misbruiken en cross-document injectie
- Citatie-aanvallen — bronnen verzinnen, citatieverwarring veroorzaken en manipuleren hoe het model informatie toeschrijft
Voor een uitgebreide behandeling, zie het subhoofdstuk RAG Retrieval Security.
Embeddings als trust boundary
Een cruciaal concept voor securityprofessionals is dat de embeddinglaag een trust boundary vormt. Data die door een embedding-model gaat, ondergaat een eenrichtingstransformatie die de meeste beveiligingsrelevante metadata wegstript:
- Toegangscontrolelabels gaan verloren. Een document dat als "vertrouwelijk" is geclassificeerd, levert een embedding op zonder toegangscontrolelabel. Of de vectordatabase wel of geen toegangscontrole op die embedding afdwingt, is maar de vraag.
- De herkomst wordt vertroebeld. Zodra een document is gechunkt en geëmbed, is er geen cryptografische link meer tussen de embedding en het brondocument. Een aanvaller die de vectordatabase vergiftigt, kan embeddings introduceren die uit legitieme bronnen lijken te komen.
- De inhoud is getransformeerd. De embedding bevat niet de oorspronkelijke tekst, waardoor je op inhoud gebaseerde beveiligingsmaatregelen (regexfilters, keywordblokkades) niet op opgeslagen embeddings kunt toepassen.
Op deze trust boundary falen veel beveiligingsmaatregelen. Een organisatie kan robuuste toegangscontrole op haar documentmanagementsysteem hebben, maar geen toegangscontrole op de vectordatabase die de embeddings van die documenten opslaat. De embeddingpipeline wordt zo een pad voor privilege-escalatie: een aanvaller met toegang tot de vectordatabase kan bij de semantische inhoud van documenten die hij niet rechtstreeks kan inzien.
Veelvoorkomende architectuurpatronen en hun risico's
Gedeelde vectordatabase
Veel organisaties gebruiken één enkele vectordatabase voor meerdere applicaties of tenants. Zonder goede namespace-isolatie kunnen queries van de ene applicatie embeddings van een andere teruggeven, wat cross-tenant datalekkage veroorzaakt.
Onversleutelde embeddingopslag
Embeddings worden zelden encrypted at rest opgeslagen, omdat versleuteling similarity search-bewerkingen zou verhinderen. Dat betekent dat iedereen met toegang tot de onderliggende opslag van de vectordatabase bij alle embeddings kan.
Embedding-model as a Service
Wanneer organisaties externe embedding-API's gebruiken (OpenAI, Cohere, Voyage AI), sturen ze hun brontekst naar een externe dienst om te laten embedden. Dat zorgt voor data-exposure die vergelijkbaar is met het versturen van data naar een taalmodel-API, maar organisaties bekijken embedding-API-calls vaak met minder kritische blik.
Embeddinggeneratie aan de clientzijde
Sommige architecturen genereren embeddings aan de clientzijde om API-calls te beperken. Dat betekent dat de gewichten van het embedding-model naar clients worden gedistribueerd, wat modeldiefstal en adversarial embeddinggeneratie mogelijk maakt.
Assessmentmethodologie
Bij het beoordelen van de embedding- en vectorbeveiliging van een AI-systeem:
- Breng de embeddingpipeline in kaart — documenteer elke stap van brondata tot vectoropslag tot retrieval
- Identificeer trust boundaries — waar wordt toegangscontrole afgedwongen, en waar valt die weg?
- Beoordeel de beveiliging van de vectordatabase — API-keys, tenantisolatie, netwerkblootstelling, back-upbeveiliging
- Test embedding-inversie — kan er betekenisvolle tekst worden hersteld uit opgeslagen embeddings?
- Test retrieval-manipulatie — kunnen vergiftigde documenten hoger gerankt worden dan legitieme?
- Evalueer de beveiliging van metadata — wordt er gevoelige informatie in vectormetadata opgeslagen zonder toegangscontrole?
- Controleer op datalekkage — kunnen cross-tenant- of cross-applicatiequeries bij embeddings uit andere contexten?
Gerelateerde onderwerpen
- Foundations: Embeddings & Vector Systems — Technische grondslagen van embeddingsystemen
- RAG, Data & Training Attacks — Het bredere aanvalsoppervlak van RAG
- Prompt Injection & Jailbreaks — Injectie-aanvallen die retrieval-manipulatie aanvullen
- Infrastructure & Supply Chain — Infrastructuurbeveiliging relevant voor de uitrol van vectordatabases