Open versus gesloten modellen: beveiligingsafwegingen

Beveiligingsimplicaties van open-weight versus closed-source AI-modellen — toegang tot gewichten, verantwoorde deployment, fine-tuning-risico's en de impact op je red team-strategie.

Het spectrum van modelbeschikbaarheid

Het onderscheid tussen "open" en "gesloten" AI-modellen is niet binair — het is een spectrum. Begrijpen waar een model op dit spectrum valt, bepaalt rechtstreeks welke aanvallen mogelijk zijn en welke verdedigingen beschikbaar zijn.

Het beschikbaarheidsspectrum

Beveiligingsprofiel: gesloten modellen

Gesloten modellen zijn alleen toegankelijk via de API's van de aanbieder. De modelgewichten, architectuurdetails en trainingsdata zijn propriëtair.

Beveiligingsvoordelen

• Bescherming van gewichten: De modelgewichten zijn niet direct toegankelijk, wat aanvallen op basis van gewichten voorkomt (aanpassing, extractie, directe analyse)
• Gecentraliseerde guardrails: De aanbieder beheert alle veiligheidsmaatregelen en kan ze bijwerken zonder actie van de gebruiker
• Monitoring en misbruikdetectie: De aanbieder kan al het gebruik monitoren op misbruikpatronen
• Rate limiting: Server-side rate limits beperken geautomatiseerde aanvallen
• Snel patchen: De aanbieder kan veiligheidspatches uitrollen die direct voor alle gebruikers van kracht worden

Beveiligingsnadelen

• Ondoorzichtigheid: Verdedigers kunnen de binnenkant van het model niet inspecteren om het kwetsbaarheidsprofiel te begrijpen
• Afhankelijkheid: De beveiliging hangt volledig af van de praktijken van de aanbieder, die niet te auditen zijn
• Alleen black-box-aanvallen: Redteamers zijn beperkt tot prompt-gebaseerde aanvallen, die mogelijk niet alle kwetsbaarheden onthullen
• Geen aanpassing: Organisaties kunnen geen eigen veiligheids-fine-tuning toevoegen of het gedrag van het model op gewichtsniveau aanpassen
• Datablootstelling: Alle prompts en data worden naar de infrastructuur van de aanbieder gestuurd

Implicaties voor het red team

Het testen van gesloten modellen vereist uitsluitend black-box-technieken. Je kunt de gewichten, attention-patronen of interne representaties van het model niet onderzoeken. Aanvallen blijven beperkt tot prompt-gebaseerde aanpakken (injectie, jailbreaken, extractie), aanvallen op API-niveau en gedragsanalyse. Dit beperkt de aanvalsruimte, maar betekent ook dat veel geavanceerde aanvallen (gradient-gebaseerde optimalisatie, gewichtsanalyse) niet beschikbaar zijn.

Beveiligingsprofiel: open-weight modellen

Open-weight modellen leveren de getrainde parameters om te downloaden. Iedereen kan inference draaien, fine-tunen of het model aanpassen.

Beveiligingsvoordelen

• Transparantie: Beveiligingsonderzoekers kunnen de gewichten, architectuur en het gedrag van het model gedetailleerd onderzoeken
• Auditing door de community: Een grote community kan kwetsbaarheden vinden die een enkele aanbieder zou kunnen missen
• Aanpasbare veiligheid: Organisaties kunnen eigen veiligheids-fine-tuning toevoegen, toegespitst op hun use case
• Datasoevereiniteit: Modellen kunnen volledig op lokale infrastructuur draaien, waardoor data privé blijft
• Reproduceerbaar onderzoek: Beveiligingsonderzoek op open modellen is reproduceerbaar en verifieerbaar

Beveiligingsnadelen

• Verwijderen van veiligheid: Iedereen kan met relatief weinig moeite en rekenkracht de veiligheidstraining weg-fine-tunen
• Onbeperkte deployment: Geen gecentraliseerde controle over hoe of waar het model wordt gedeployd
• Geen monitoring: De modelaanbieder heeft geen zicht op hoe het model wordt gebruikt
• Afgeleide modellen: Fine-tuned varianten verspreiden zich zonder veiligheidsevaluatie
• Aanvallen op basis van gewichten: Directe toegang tot gewichten maakt geavanceerde aanvallen mogelijk (activatieanalyse, gewichtsaanpassing, gerichte fine-tuning)

Implicaties voor het red team

Open-weight modellen zijn zowel makkelijker aan te vallen als makkelijker defensief te bestuderen. White-box-aanvallen worden mogelijk: gradient-gebaseerde generatie van adversarial invoer (GCG), activatieanalyse om veiligheidsmechanismen te begrijpen, gewichtsaanpassing om backdoors te maken, en gedetailleerde analyse van hoe veiligheidstraining op parameterniveau is geïmplementeerd.

Het beveiligingsprobleem van fine-tuning

Fine-tuning is waar de beveiligingsspanning tussen open en gesloten modellen het scherpst wordt. Onderzoek laat consistent zien dat zelfs onschadelijke fine-tuning de veiligheids-alignment van een model aanzienlijk kan verzwakken.

Hoe fine-tuning de veiligheid verzwakt

Reacties van aanbieders op het fine-tuning-probleem

Verschillende aanbieders kiezen verschillende aanpakken:

• OpenAI: Biedt fine-tuning via hun API met geautomatiseerde veiligheidsevaluaties van fine-tuned modellen; kan fine-tuned modellen die het beleid schenden weigeren of intrekken
• Anthropic: Beperkte toegang tot fine-tuning; richt zich op constitutional AI-aanpakken die robuuster zijn tegen fine-tuning
• Meta (Llama): Levert een Acceptable Use Policy en licentiebeperkingen, maar kan het verwijderen van veiligheid uit gedownloade gewichten technisch niet voorkomen
• Mistral: Levert gewichten met een permissieve licentie; het afdwingen van veiligheid wordt overgelaten aan de deployers

Verantwoorde deployment van open modellen

Organisaties die open-weight modellen deployen, nemen de beveiligingsverantwoordelijkheden op zich die aanbieders voor gesloten modellen afhandelen. Dit omvat:

Minimale beveiligingseisen

1. 1

   Veiligheidsevaluatie vóór deployment

   Draai uitgebreide veiligheidsbenchmarks op de specifieke modelversie (inclusief eventuele fine-tuned versies) vóór deployment. Tools als de Eleuther AI LM Evaluation Harness bieden standaard veiligheidsbenchmarks.

2. 2

   Server-side guardrails

   Implementeer input- en outputfiltering, aangezien de ingebouwde veiligheid van het model zwakker kan zijn dan die van gesloten alternatieven. Zie Guardrails-architectuur.

3. 3

   Monitoring en logging

   Bouw monitoring voor misbruikpatronen, aangezien geen externe aanbieder meekijkt. Log prompts en responses (met inachtneming van privacy-eisen) voor incidentonderzoek.

4. 4

   Rate limiting en toegangscontrole

   Implementeer rate limiting en authenticatie op applicatieniveau, aangezien er geen controles op aanbiedersniveau bestaan.

5. 5

   Updateprocedures

   Stel procedures op voor het bijwerken naar nieuwe modelversies wanneer de modelaanbieder veiligheidsrelevante updates uitbrengt.

Het afwegingskader voor deployment

Impact op je red team-strategie

Het onderscheid open/gesloten verandert fundamenteel hoe je een red team-opdracht aanpakt:

Teststrategie voor gesloten modellen

1. Focus op gedragstesten: Prompt injection, jailbreaken, extractie van de system prompt — allemaal via de API
2. Enumereer het API-oppervlak: Zoek naar ongedocumenteerde endpoints, header-injectie, authenticatiefouten
3. Test guardrails systematisch: De guardrails van de aanbieder zijn de primaire verdediging; breng hun dekking in kaart
4. Meet de reproduceerbaarheid: Documenteer slagingspercentages over meerdere runs, temperaturen en modelversies
5. Ketenen van aanvallen: Combineer prompt injection met tool use of RAG om aanvallen in meerdere stappen uit te voeren

Teststrategie voor open-weight modellen

1. Alles van het bovenstaande, plus:
2. Analyseer de gewichten direct: Onderzoek attention-patronen, activatieverdelingen en veiligheidsgerelateerde neuronen
3. Genereer adversarial invoer: Gebruik gradient-gebaseerde optimalisatie (GCG, AutoDAN) om optimale aanvalsstrings te maken
4. Test de bestendigheid tegen fine-tuning: Evalueer hoe snel de veiligheid verzwakt onder onschadelijke en adversarial fine-tuning
5. Onderzoek de veiligheidsmechanismen: Reverse-engineer hoe het model weigering en veiligheidsgedrag implementeert
6. Test de veiligheid onder quantisatie: Evalueer of gequantiseerde versies (GGUF, GPTQ, AWQ) hun veiligheidseigenschappen behouden

Gerelateerde onderwerpen

• Het AI-landschap — de bredere ecosysteemcontext
• Modeltypes en aanvalsoppervlakken — hoe de modelarchitectuur de kwetsbaarheid beïnvloedt
• Deploymentpatronen — hoe deployment samenhangt met modelbeschikbaarheid
• Adversarial ML: kernconcepten — de adversarial technieken die toegang tot gewichten mogelijk maakt

Bronnen

• "On the Risks of Open-Weight Large Language Models" - Soice et al. (2024) - Analyse van de beveiligingsrisico's die ontstaan door modelgewichten publiek beschikbaar te maken
• "Fine-Tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To" - Qi et al. (2023) - Onderzoek dat aantoont dat onschadelijke fine-tuning de veiligheids-alignment verzwakt
• "Shadow Alignment: The Ease of Subverting Safely-Aligned Language Models" - Yang et al. (2023) - Demonstreert hoe weinig voorbeelden nodig zijn om veiligheids-fine-tuning uit open-weight modellen te verwijderen
• "The Model Openness Framework" - Open Source Initiative (2024) - Een kader om de mate van openheid in AI-modellen te classificeren voorbij een simpel binair onderscheid open/gesloten