Large Language Models (LLM’s), een toepassing van AI, worden gezien als een vloek en een zegen. Ze bieden mogelijkheden om sneller en slimmer te werken, maar leveren ook gevaar op voor schending van privacy en misbruik van de AI-modellen voor criminele doeleinden zoals het creëren van valse documenten voor identiteitsfraude. Wat zijn nu de grootste risico’s van LLM’s en AI in het algemeen waar je je van bewust moet zijn? En hoe kun je hier als organisatie het best mee omgaan?
Nu de AI-act van kracht is en er wettelijke regels zijn ingesteld voor het gebruik van de technologie, is het helder hoe en waarvoor LLM’s wel en niet mogen worden ingezet. Er is een duidelijk onderscheid gemaakt tussen verschillende risicoclassificaties en er zijn eisen opgesteld waar organisaties aan moeten voldoen zodat er geen onaanvaardbare risico’s ontstaan bij gebruik van AI. Dat er wetgeving is, is heel goed, maar het betekent natuurlijk niet dat we zijn gevrijwaard van risico’s. Bovendien gaan de ontwikkelingen op het gebied van AI zo snel dat deze niet zijn bij te benen met wetgeving.
Misbruiken van LLM’s door prompt injection De grootste securityzorg op het gebied van LLM’s is op dit moment ‘prompt injection’. Dit kun je zien als een cyberaanval tegen LLM’s. Hackers manipuleren de modellen met ogenschijnlijk legitieme vragen, maar zorgen ervoor dat het systeem de geldende richtlijnen negeert en gevoelige data lekt, desinformatie verspreid of instructies geeft voor kwaadaardige activiteiten. In het securitywerkveld is de heersende regel dat ‘control’ en data van elkaar gescheiden moeten worden. Hiermee kunnen immers aanvallen die misbruik maken van de combinatie van opdrachten (control) en door de gebruiker verstrekte invoer (data) worden voorkomen. LLM’s werken echter niet op deze manier.
Nu kun je wel zorgen dat je security- vangrails toevoegt aan de LLM’s die worden gebruikt. Maar zoals het recente voorbeeld van AutoDAN-Turbo waarbij deze veiligheidsfilters werden omzeild laat zien, zijn deze niet waterdicht.
Het feit dat LLM’s steeds vaker geïntegreerd worden in zakelijke systemen maken de risico’s van prompt injection nog groter. Zo kun je met Microsoft 365 Copilot in de 365-omgeving vragen stellen over jouw werk of het werk van anderen. De LLM kan voor het antwoord alle mails en documenten uit de 365-omgeving gebruiken. Door geavanceerde prompt injection toe te passen zou je hierdoor de LLM mogelijk kunnen verleiden om gevoelige data van collega’s te geven. Een volgende stap is om LLM’s te vragen acties in andere systemen uit te voeren. Hiermee wordt het risico vanzelfsprekend nog groter, zeker als je denkt aan toepassing in de publieke- of zorgsector.
Een ander belangrijk risico is dat gebruikers van LLM’s vaak niet hoe AI precies werkt en niet kritisch naar de output kijken. Men neem deze klakkeloos aan als waarheid. AI werkt op basis van ‘token prediction’. Op basis van een vraag wordt het meest waarschijnlijke woord wat erop volgt gegeven en kunnen daarbij ook zaken worden verzonnen.
De data die je invoert, wordt gebruikt om het model te trainen. Hoe specifieker de trainingsdata, hoe beter de output. Dit betekent echter ook dat AI te manipuleren is door verkeerde data aan het model te voeden zodat er ook verkeerde antwoorden uitkomen. Ook is al verschillende keren gebleken dat mensen de fout maken om
vertrouwelijke informatie in het systeem te brengen en zich niet realiseren dat alle informatie die erin gaat wordt gebruikt om het systeem te trainen. De vertrouwelijke data kan dus gebruikt worden in het antwoord dat het systeem op een vraag van iemand anders geeft. Hiermee ligt een datalek al snel op de loer. Autorisatie, beleid en training Er is helaas geen ‘silver bullet’ om deze risico’s weg te nemen. Zoals gezegd gaan de ontwikkeling en adoptie van LLM’s zodanig snel dat security-maatregelen het niet kunnen bijbenen. Maar voordat je een model ontwikkelt of introduceert in de organisatie, is het sowieso goed je te realiseren dat het ook op andere manieren gebruikt zal gaan worden dan jij had bedacht. Denk hierover na en stem daar vervolgens de autorisatie op af.
Gelukkig zie je ook dat er vanuit de technologiebranche wordt gewerkt aan meer security- en privacyvriendelijke AI. Zo introduceerde Apple met de laatste updates Apple Intelligence, waarbij alle data die in de cloud worden verwerkt via private cloud compute worden gecodeerd en direct weer worden verwijderd. Dit zorgt ervoor dat data die aan Apple Intelligence wordt verstrekt, nooit openbaar kan worden. Als je Apple Intelligence iets vraagt kan deze data dus nooit publiek worden.
Er zullen ongetwijfeld meer oplossingen komen voor de risico’s die kleven aan het gebruik van LLM’s. Tot die tijd is sowieso slim om de volgende adviezen in acht te nemen om deze risico’s te minimaliseren:
- Neem security mee als criterium bij de selectie van een LLM. Kijk hoe de aanbieder van het LLM, omgaat met de data die jij in het LLM/GPT stopt. Hiermee voorkom je dat je als organisatie jouw (gevoelige) data lekt via het LLM.
- Creëer beleid omtrent het gebruik van een LLM/GPT. Maak duidelijk welke LLM’s gebruikt mogen worden en via het bedrijf aangeboden worden.
- Stel kaders voor het type data dat wel en vooral niet in een LLM terecht mag komen. Sommige data, zoals bijzondere persoonsgegevens, wil je niet toevertrouwen aan een LLM. Uiteraard moeten collega’s hiervoor op de hoogte zijn welke dataclassificatie / niveaus van vertrouwelijkheid gehanteerd worden en ook hiernaar handelen.
- Controleer waar het LLM “bij mag”, en of gebruikers van het LLM niet meer informatie uit het LLM kunnen halen dan nodig en toegestaan is. Dit is vooral een probleem met CoPilot, omdat deze ook OneDrive als dataset gebruikt, met als gevolg dat gebruikers soms meer informatie kunnen inzien dan de bedoeling is
- Activeer two-factor authentication en monitor het gebruik van de LLM’s om zo de compliance te bewaken.
Dit is een ingezonden bijdrage van Computest Security. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.