Wat is LLM-beveiliging? Zo beperk je de veiligheidsrisico's uit de OWASP Top 10

Een aanval die een AI zo misleidt dat die de instructies van een aanvaller als opdrachten behandelt—promptinjectie—staat sinds 2023 in elke editie op nr. 1 in de OWASP Top 10 for LLM Applications.

Dichter bij consensus dan deze lijst komt AI-beveiliging nauwelijks. Het project begon als een kleine groep beveiligingsprofessionals en steunt inmiddels op meer dan 600 bijdragende experts in meer dan 18 landen.

We zijn een AI-bedrijf dat een gids publiceert over hoe AI zich dingen laat aanpraten, dus we gaan niet doen alsof dit probleem is opgelost. Wilson, medeleider van het OWASP-project, was vrij duidelijk over de huidige verdedigingsmaatregelen: "...eerlijk gezegd denk ik niet dat we op 99% zitten."

De editie van 2026 opent in dezelfde geest. De projectleider roept ons op om "te stoppen met proberen een model te bouwen dat niet om de tuin kan worden geleid" en het omliggende systeem zo te ontwerpen dat een misleid model niets belangrijks kan breken.

Vanuit dat standpunt bespreken we alle 10 risico’s op de OWASP-lijst van 2026.

Wat betekent LLM-beveiliging?

LLM-beveiliging betekent het beschermen van AI-modellen en de applicaties die ze gebruiken tegen aanvallen en misbruik. Het risico groeit met alles waarmee het model verbonden is: de bestanden en gegevens die het kan lezen, en de tools die het kan gebruiken, zoals e-mail, zoekfuncties of een bedrijfsdatabase.

In goed beveiligde software is er een harde grens tussen de instructies die een programma volgt en de informatie die het verwerkt. Maar LLM's hebben die grens niet.

Alles wat het model leest, komt binnen als één lange stroom tekst: de instructies van de ontwikkelaar, je vraag, een webpagina die het heeft opgezocht. AI-modellen horen bij te houden wie er aan het woord is, of dat nu de ontwikkelaar is, de gebruiker of het model zelf dat over een probleem nadenkt.

Maar onderzoekers Jasmine Cui en Charles Ye ontdekten dat modellen vooral raden wie er aan het woord is op basis van hoe de tekst klinkt. Als een aanvaller dus iets schrijft dat klinkt als de eigen redenering van het model, kan het model denken dat het zelf op het idee is gekomen. Dat is een probleem voor elke beveiligingsopzet die ervan afhangt dat het model weet wie de baas is.

We zijn hetzelfde probleem tegengekomen bij onze eigen AI-agents. Onze CISO, Kyle Polley, vertelde ISMG dat agents "beleidsregels mogelijk niet volgen, zelfs als je ze aan de systeemprompt toevoegt." Daarom hebben we Numbat gebouwd, een opensourcetool die controleert wat een agent op het punt staat te doen en de actie kan blokkeren als die een ingestelde beveiligingsregel schendt.

LLM-beveiliging betekent accepteren dat het model soms orders aanneemt van de verkeerde persoon, en er AI-guardrails omheen bouwen die ook dan standhouden.

Wat zijn de best practices voor LLM-beveiliging?

We lopen de OWASP Top 10 for LLM Applications 2026 op volgorde door, van nr. 1 tot en met nr. 10.

Voor elk risico krijg je in gewone taal uitgelegd hoe het misgaat, plus een voorbeeld uit de praktijk. Daarna bespreken we de werkwijzen die kunnen helpen het te voorkomen, of op zijn minst de schade te beperken.

1. Houd promptinjectie in toom

Bij promptinjectie laat een aanvaller een AI instructies volgen die niet gevolgd zouden mogen worden. Die instructies kunnen rechtstreeks in een chat worden gegeven of verstopt zitten in een e-mail, webpagina of document.

Het tweede type staat bekend als indirecte promptinjectie. Je vraagt je assistent om een document samen te vatten. Daarin hebben ze de assistent opgedragen om je privébestanden naar hen te sturen. Als de assistent die instructies opvolgt, heeft degene die het document schreef in feite jouw toegang geleend.

PCMag vergelijkt promptbeveiliging met het dichten van gaten in poreuze steen. Je dicht de ene opening, en het water vindt een andere. “Een aanval vindt zijn weg naar binnen; die wordt verholpen, maar talloze andere aanvalsroutes moeten nog worden ontdekt, simpelweg omdat systemen als LLM’s zo dynamisch zijn.”

Voorbeeld: In juni 2025 ontdekten onderzoekers van Aim Security EchoLeak, een kwetsbaarheid waarmee Microsoft 365 Copilot zo werd misleid dat het vertrouwelijke bedrijfsinformatie lekte. Wanneer een medewerker een routinematige werkvraag stelde, kon Copilot de e-mail ophalen, de daarin verborgen instructies opvolgen en gevoelige informatie naar de aanvaller sturen. De aanval omzeilde de controles die bedoeld waren om kwaadaardige instructies te onderscheppen en verdachte links te verwijderen.

Wat je kunt doen:

• Volg Meta’s “Rule of Two”: EchoLeak had een AI nodig die bedrijfsdata kon lezen, externe e-mail kon lezen en informatie naar buiten kon sturen—en die AI kon alle drie. Door de AI te beperken tot twee van die mogelijkheden voorkom je dat een promptinjectie te veel controle krijgt. Vereist de taak alle drie, laat dan elke actie eerst door een mens goedkeuren.
• Test tegen aanvallers die je verdediging kennen: Geef je beveiligingstesters de regels en filters die je hebt ingesteld en laat ze die vervolgens omzeilen. In één onderzoek slaagden aanvallers die zich aanpasten aan de verdediging in meer dan 90% van de gevallen tegen de meeste van de 12 geteste verdedigingsmechanismen.

2. Voorkom dat gevoelige informatie uitlekt

Wanneer AI-systemen privégegevens verstrekken aan mensen die ze niet zouden mogen zien, heet dat openbaarmaking van gevoelige informatie. Denk aan het onthullen van de betaalgegevens van een klant of aan privégesprekken die in een gedeelde database blijven staan.

Veel lekken beginnen met “oversharing”. Stel dat een bedrijf zijn AI koppelt aan schijven en kennisbanken met ruime machtigingen. De AI haalt alles op waar die bij kan, precies zoals bedoeld. Niemand hoeft in te breken, maar je kunt de LLM net zo goed als gekraakt beschouwen.

Voorbeeld: In januari 2025 ontdekten onderzoekers van Wiz een DeepSeek-database die openstond voor het internet, met meer dan een miljoen logregels, waaronder chatgeschiedenis en API-sleutels, waarmee software toegang krijgt tot andere diensten. De onderzoekers hoefden het model nergens toe over te halen.

Wat je kunt doen:

• Controleer de toegang voordat de AI de data leest: Je applicatie moet controleren welke documenten de persoon die de vraag stelt mag inzien, voordat ze aan het model worden doorgegeven.
• Bescherm de sporen die je AI achterlaat: Verwijder privégegevens en geheime sleutels voordat je activiteitenlogboeken opslaat, maak inloggen verplicht en beperk de toegang tot de mensen die ze nodig hebben. Stel een bewaartermijn in zodat die gegevens zich niet eindeloos opstapelen.

3. Beteugel overmatige autonomie

AI’s met overmatige autonomie hebben meer macht dan hun werk vereist: tools die ze niet nodig hebben, machtigingen die verder gaan dan hun taak, of de vrijheid om zonder controle te handelen. De oorzaak doet hier niet ter zake.

Een geïnjecteerde prompt, een bug of een model dat het gewoon verkeerd heeft: ze leiden allemaal tot hetzelfde resultaat. De AI zal uiteindelijk iets destructiefs doen als die daartoe de mogelijkheid heeft.

Voorbeeld: In juli 2025 meldde SaaStr-oprichter Jason Lemkin dat de codeeragent van Replit zijn database met 1.206 records van leidinggevenden had verwijderd, ondanks instructies om geen wijzigingen aan te brengen. De agent zei eerst dat de gegevens niet konden worden hersteld, hoewel herstel later toch mogelijk bleek. Jason ontdekte dat de opdracht om de database met rust te laten de agent niet de mogelijkheid had ontnomen om die te verwijderen.

Vergroten

Bron: X

Wat je kunt doen:

• Verwijder mogelijkheden die de taak niet nodig heeft: Beperk zowel de tools die een agent krijgt als wat die tools kunnen doen. Een assistent die e-mails samenvat, heeft toestemming nodig om ze te lezen, niet om ze te versturen of te verwijderen.
• Plaats toestemmingscontroles buiten de AI: Toets elke aangevraagde actie aan je beveiligingsregels en vereis goedkeuring door een mens.

4. Controleer wat je AI-toeleveringsketen binnenkomt

Weinig bedrijven bouwen AI vanaf nul, en elk jaar worden het er minder. Volgens het onderzoek The State of Generative AI in the Enterprise 2025 van Menlo Ventures kocht 53% in 2024 AI-modellen in, een aandeel dat in 2025 steeg tot 76%.

Meestal downloaden bedrijven modellen van hubs zoals Hugging Face, trainen ze die verder op datasets die anderen hebben verzameld en voegen ze add-ons en codepakketten toe die door onbekenden zijn geschreven.

Elk van die onderdelen is een toegangspunt. Als er met één ervan is geknoeid, wordt het probleem met je product meegeleverd.

Voorbeeld: Het aantal openbare modelrepository’s van Hugging Face groeide tussen januari 2026 en augustus 2026 van 2,43 miljoen naar 2,96 miljoen. In juli 2026 wisten modellen van OpenAI echter tijdens interne beveiligingstests de controles te omzeilen die hen van het internet moesten weghouden, en drongen ze delen van de systemen van Hugging Face binnen. Eén agent bemachtigde zelfs 14 openbaar blootgestelde toegangsgegevens, controleerde of ze werkten en deelde ze met andere agents. Vervolgens buitten de agents kwetsbaarheden uit waarmee ze code konden uitvoeren op de servers van Hugging Face.

“We stellen strengere eisen aan alignment gedurende de hele levenscyclus van een model, creëren meer geïsoleerde sandboxes, beperken de internettoegang en controleren de toegang tot modelgewichten nog strenger”, aldus het rapport van OpenAI.

Wat je kunt doen:

• Zet modellen vast op een exacte versie en verifieer ze: Zet elk model vast op een gecontroleerde versie en controleer de vingerafdruk van het bestand voordat je het laadt, zodat een verwisseld bestand niet onder hetzelfde label naar binnen kan glippen. OWASP raadt ook digitale handtekeningen aan, met een kanttekening—een handtekening bewijst waar een model vandaan komt, niet dat het veilig is.
• Controleer elk pakket dat je AI voorstelt: Controleer bij een codepakket dat een AI-assistent heeft aanbevolen vóór de installatie of het bestaat, of het om het pakket gaat dat je bedoelde en of het afkomstig is van de uitgever die je verwacht.

5. Bescherm je tegen data- en modelvergiftiging

Een vergiftigde AI leert van gecorrumpeerde data. Het kan gaan om de voorbeelden waarmee het model is gefinetuned, of om een kennisbank die het doorzoekt om antwoorden te vinden. Het model lijkt nog steeds te werken; het leert alleen de verkeerde lessen, en soms leert het zich pas te misdragen wanneer het een specifieke triggerzin ziet.

Het model doorstaat elke test die je het voorlegt, totdat iemand die zin gebruikt.

Vergroten

Bovendien is het erg moeilijk terug te draaien. Vergiftiging is geen bug die je kunt patchen. Als je data niet klopt, moet je die misschien opnieuw controleren, het model opnieuw trainen of het volledig vervangen.

Voorbeeld: In oktober 2025 toonden onderzoekers van Anthropic, het UK AI Security Institute en het Alan Turing Institute aan dat 250 vergiftigde documenten een model konden leren onzin te produceren zodra het een bepaalde trigger tegenkwam. Hetzelfde aantal werkte bij alle vier geteste modelgroottes, ook al werd het grootste model getraind op meer dan 20 keer zoveel schone data.

Wat je kunt doen:

• Houd bij waar je data vandaan komt: Houd een overzicht bij van elke dataset en elk model dat je gebruikt, waar ze vandaan komen en wat er tussen versies is veranderd. We raden versiebeheer voor datasets aan, zodat je, als er vergiftiging opduikt, kunt terugkeren naar een schone versie en kunt achterhalen hoe die erin is gekomen.
• Test op achterdeuren: Een “achterdeur” is verborgen gedrag dat een aanvaller in een model inbouwt en dat wacht op een bepaalde zin of andere trigger om te worden geactiveerd. Test hierop met invoer die is ontworpen om het model zijn gebruikelijke regels te laten overtreden.

6. Beperk onbegrensd verbruik

Wanneer er geen grenzen zijn aan hoeveel werk AI's mogen doen of hoeveel ze mogen kosten, wordt hun verbruik als “onbegrensd” beschouwd. De meeste AI-diensten rekenen per gebruik af, dus een aanvaller kan je rekening flink laten oplopen of een kopie van je model bouwen.

OWASP noemt het kernprobleem “kostenasymmetrie”. Een kort, goedkoop verzoek kan aan jouw kant dure berekeningen in gang zetten.

Voorbeeld: In mei 2024 ontdekte het Threat Research Team van Sysdig een nieuwe aanval, “LLMjacking” genaamd. Een groep aanvallers richtte zich met gestolen inloggegevens op 10 in de cloud gehoste LLM-diensten. Ze kwamen binnen via een kwetsbare versie van Laravel en zochten vervolgens uit wat ze met de inloggegevens konden doen en welke quota er golden, met het duidelijke doel de toegang te verkopen. Ook werden veel logboekinstellingen opgevraagd, waarschijnlijk om detectie te voorkomen. Volgens Sysdig zou het slachtoffer in het ergste geval meer dan 46.000 dollar per dag kwijt kunnen zijn.

Wat je kunt doen:

• Stel budgetten in die de uitgaven stoppen: Hanteer harde uitgavenlimieten voor individuele gebruikers, API-sleutels, teams en het account als geheel. Dwing ze af op elke plek waar verzoeken binnen kunnen komen.
• Geef elke taak een eindpunt: Beperk hoe lang een taak mag duren, hoeveel tekst die mag verwerken en genereren en hoeveel toolaanroepen die mag doen. Voeg automatische afbreekpunten toe voor agents die zichzelf herhalen of hun toegewezen limiet overschrijden.

7. Onderschep misinformatie voordat er actie wordt ondernomen

Wanneer een AI iets onjuists produceert dat juist klinkt, en iemand of iets daarop handelt, heet dat misinformatie. Het kernrisico zit niet zozeer in het verkeerde antwoord zelf, maar in het feit dat dat verkeerde antwoord wordt vertrouwd en gebruikt.

Uit de incidentgeschiedenis blijkt dat professionals zich minder zorgen maakten over misinformatie dan nodig was. Volgens de openingsbrief van de editie van 2026 plaatsten de stemmers het bijna onderaan, terwijl het op basis van incidenten in de praktijk juist bijna bovenaan hoort.

Voorbeeld: In 2025 leverde Deloitte Australia een evaluatie op van IT-systemen voor sociale zekerheid, in het kader van een overheidscontract van 440.000 Australische dollar. Chris Rudge, onderzoeker aan de University of Sydney, vond verwijzingen naar niet-bestaand onderzoek en een verzonnen citaat uit een uitspraak van een federale rechtbank. In het herziene rapport werd vermeld dat Deloitte Azure OpenAI GPT-4o in zijn methodologie had gebruikt, en het bedrijf stemde ermee in de laatste termijn terug te betalen. Het ging hier helaas uitgerekend om een assurance-onderzoek.

Wat je kunt doen:

• Controleer of het bewijs het antwoord ondersteunt: Onderbouw beweringen met actuele, gezaghebbende bronnen. Haal voor een antwoord over beleid het goedgekeurde beleid op en controleer of dat de conclusie ondersteunt, inclusief eventuele uitzonderingen.
• Verifieer voordat het systeem handelt: Als een agent zegt dat een klant een identiteitscontrole heeft doorstaan, bevestig dat dan via het verificatiesysteem voordat je een betaling vrijgeeft. Vereis menselijke goedkeuring voor ingrijpende beslissingen, waarbij het onderbouwende bewijs beschikbaar is voor de beoordelaar.

8. Beperk de schade door blootstelling van verborgen context

AI-applicaties geven het model instructies en achtergrondinformatie die gebruikers normaal gesproken niet zien. Denk aan de systeemprompt, interne beleidsregels, beschrijvingen van beschikbare tools en regels over wie die mag gebruiken. Van blootstelling van verborgen context is sprake wanneer het model die informatie aan iemand onthult.

In 2026 heeft OWASP deze categorie verbreed van “system prompt leakage”, omdat de systeemprompt maar een deel is van wat er kan uitlekken. Het gevaar hangt af van wat je erin hebt gezet. Een uitgelekte tone-of-voice-gids is licht gênant, maar een uitgelekte API-sleutel geeft iemand toegang tot je vertrouwelijke database.

Voorbeeld: In februari 2023 kregen gebruikers Bing Chat van Microsoft zover dat het zijn interne instructies prijsgaf. Eén geslaagde poging kwam van Marvin von Hagen, die beweerde een ontwikkelaar van OpenAI te zijn en om de instructies vroeg zodat hij het model kon configureren. Bing onthulde regels voor zijn zoekopdrachten, antwoorden en veiligheidsgedrag, en daarnaast zijn interne naam: Sydney. Een van de onthulde instructies droeg Bing op om die instructies vertrouwelijk te houden.

Wat je kunt doen:

• Houd geheimen buiten de context van het model: Ga ervan uit dat alles wat het model kan lezen, zichtbaar kan worden voor gebruikers. Bewaar wachtwoorden, API-sleutels en toegangstokens daarom in een apart systeem voor geheimenbeheer.
• Zorg dat rechten blijven gelden, ook als de regels uitlekken: Dwing toegangscontroles af in je applicatiecode. Als een tool alleen voor beheerders bedoeld is, controleer dan de accountrechten van de gebruiker voordat je de tool uitvoert.

9. Beveilig je vectoren en embeddings

Wanneer een AI met vectorzoeken antwoorden zoekt in de documenten van je bedrijf, doorzoekt die de tekst niet rechtstreeks. De documenten worden omgezet in “embeddings” – lange reeksen getallen die vastleggen wat elke passage betekent – en opgeslagen in een vectordatabase. Een vraag wordt op dezelfde manier omgezet, waarna het systeem de passages ophaalt waarvan de getallen er het dichtst bij liggen.

OWASP vat de vier manieren samen waarop het misgaat: vergiftiging zorgt dat het systeem fouten maakt, inversie dat het lekt, jamming dat het zwijgt en gebrekkige toegangscontrole dat het alles aan iedereen geeft.

De getallen zijn niet de veilige abstractie die ze lijken. Opgeslagen embeddings kunnen weer worden omgezet in tekst, en één methode reconstrueerde in tests 92% van de korte passages van 32 tokens exact. Een uitgelekte back-up met “alleen embeddings” kan dus ook de inhoud van de documenten blootleggen.

Voorbeeld: In onderzoek dat werd gepresenteerd op USENIX Security 2025 lieten onderzoekers zien dat één zorgvuldig opgesteld document een AI kon verhinderen een bepaalde vraag te beantwoorden. Ze voegden het toe aan de verzameling die de AI doorzocht. Wanneer de AI het document vond, kon die zeggen dat die niet genoeg informatie had of dat het onveilig zou zijn om te antwoorden. Het document hoefde de AI niet eens op te dragen de eigen regels te negeren. Dit wordt “retrieval jamming” genoemd.

Wat je kunt doen:

• Gebruik aparte indexen voor openbare en privégegevens: Meng gescrapete webcontent niet met partnergegevens of vertrouwelijke interne documenten. Scheid gegevens fysiek op basis van vertrouwensniveau in plaats van content binnen één index te taggen. Zo sluit je een hele categorie configuratiefouten uit, en kan content die van internet is gescrapet nooit naast je bestuursstukken terechtkomen.
• Behandel embeddings als de documenten waaruit ze afkomstig zijn: Versleutel ze, beveilig back-ups van de vectordatabase net zo goed als de bronbestanden en verwijder embeddings wanneer je het origineel verwijdert. Houd API-sleutels voor je embeddingservice geheim.

10. Controleer AI-uitvoer voordat je die doorgeeft

Wanneer een applicatie AI-uitvoer doorgeeft aan een ander systeem zonder te controleren of die daar veilig kan worden gebruikt, is er sprake van onjuiste verwerking van LLM-uitvoer.

Deze categorie omvat ook de onveilige code die AI-programmeerassistenten op grote schaal genereren. Elke regel die een assistent schrijft, is dus ook uitvoer.

Voorbeeld: In 2025 liet onderzoeker Johann Rehberger zien hoe de programmeerassistent Amp van Sourcegraph chatinhoud kon lekken door simpelweg een afbeelding weer te geven. Met promptinjectie liet hij Amp privégegevens opnemen in het webadres van een afbeelding. De applicatie haalde die afbeelding vervolgens automatisch op, waardoor de gegevens naar zijn server werden verzonden. De fout in de verwerking van de uitvoer zat in dat automatische verzoek: de tekst die het model genereerde, veranderde in een verbinding met een externe server en nam daarbij privégegevens mee.

Wat je kunt doen:

• Maak de uitvoer veilig voor de bestemming: Controleer en verwerk antwoorden op basis van waar ze naartoe gaan. Voorkom bij een webpagina dat gegenereerde tekst uitvoerbare code wordt. Gebruik bij een database geparametriseerde query's die aangeleverde waarden gescheiden houden van opdrachten.
• Voorkom dat antwoorden automatisch externe verbindingen maken: Schakel het automatisch laden van afbeeldingen, linkvoorbeelden en ingesloten pagina's in modelantwoorden standaard uit. Beperk noodzakelijke verbindingen tot expliciet goedgekeurde bestemmingen.

Hoe beveiligt Perplexity LLM's?

We gaan ervan uit dat elk van de bovenstaande risico's vroeg of laat werkelijkheid wordt, en we ontwerpen onze systemen zo dat de schade dan beperkt blijft. Onze CISO, Kyle Polley, legde in een recente workshop uit hoe we dat doen.

• De agent krijgt een eigen computer, en die is in eerste instantie leeg: Agenttools die op je laptop zijn geïnstalleerd, kunnen toegang krijgen tot de bestanden, apps en opgeslagen inloggegevens op die laptop. Perplexity Computer werkt andersom. Elke taak draait in een eigen geïsoleerde sandbox, en zoals Polley het zegt: “standaard heeft die nergens toegang toe.”
• De agent ziet de wachtwoorden nooit: De inloggegevens voor gekoppelde services worden buiten de sandbox opgeslagen. Wanneer de agent een service zoals GitHub moet bereiken, verstuurt die een verzoek zonder inloggegevens. Een gateway controleert of de bestemming en het verzoek overeenkomen met wat wordt verwacht, en voegt de inloggegevens toe wanneer het verzoek naar buiten gaat. Zo kan de agent de verbinding gebruiken zonder de sleutels in handen te krijgen.
• Je rechten worden overgenomen, en je kunt ze verder aanscherpen: Verbindingen die via OAuth worden gemaakt, behouden je toegangsrechten in de gekoppelde service. Wat jij niet kunt zien, kan je agent ook niet zien.
• Elke webpagina wordt als een vreemde behandeld: We hebben BrowseSafe gebouwd voor Comet, onze agentische browser, omdat de tools die we testten in de praktijk niet aan onze eisen voldeden. De browser scant webpagina's en andere externe content, waaronder e-mails, op promptinjectie. We hebben zowel het model als de dataset open source gemaakt.
• We houden de agent en de machines waarop die draait in de gaten: Numbat zit tussen het moment waarop een agent besluit iets te doen en het moment waarop de tool daadwerkelijk wordt uitgevoerd. Numbat registreert de activiteit van ondersteunde codeeragents en kan acties die in strijd zijn met geconfigureerd beleid blokkeren voordat ze worden uitgevoerd. Bumblebee inventariseert softwarepakketten op laptops, servers en build-pipelines, en markeert pakketten waarvan bekend is dat ze kwaadaardig zijn. Beide zijn open source.
• De modelproviders bewaren je gegevens niet: We hebben met onze externe LLM-providers afgesproken dat er geen gegevens worden bewaard (zero data retention). Enterprise-beheerders kunnen daarnaast de bewaartermijn van Perplexity zelf instellen op slechts 24 uur.

We hebben Numbat proactief gebouwd, om een reden die Polley in één zin samenvat: “Hoe meer autonomie je een agent geeft, hoe groter het risico.”

Veelgestelde vragen over LLM-beveiliging

Wat is de veiligste LLM?

Geen enkele LLM maakt een applicatie op zichzelf veilig: modellen kunnen content die ze alleen moeten lezen nog steeds aanzien voor instructies die ze moeten opvolgen. Verdedigingen die in standaardtests sterk lijken, kunnen onder druk bovendien bezwijken.

Een betere vraag is welke opzet het veiligst is voor jouw toepassing. Denk aan beperkte rechten, inloggegevens die buiten bereik van het model blijven, menselijke goedkeuring voor risicovolle acties en tests door mensen die je verdedigingsmechanismen kennen.

Wat zijn LLM-kwetsbaarheden?

LLM-kwetsbaarheden zijn zwakke plekken waardoor een AI-systeem kan worden misleid, gegevens kan lekken of schade kan aanrichten, door toedoen van een aanvaller of door eigen fouten.

De tien grootste risico's zijn promptinjectie, openbaarmaking van gevoelige informatie, buitensporige autonomie, de toeleveringsketen, vergiftiging van gegevens en modellen, onbegrensd verbruik, desinformatie, blootstelling van verborgen context, zwakke plekken in vectoren en embeddings, en onjuiste verwerking van uitvoer.

Is een privé-LLM veilig?

Voor sommige toepassingen is het een veiligere optie, maar niet vanzelf. Als je een model op je eigen infrastructuur of in een cloudomgeving draait, heb je meer controle over de verwerking van gegevens. Er is echter geen automatische manier om promptinjectie, buitensporige autonomie, vergiftiging of desinformatie te voorkomen.

Bij zelfhosting ben je ook verantwoordelijk voor het model dat je downloadt, inclusief de risico's in de toeleveringsketen en de infrastructuur die het model nodig heeft.