SecurityTechInsider AI-veiligheid & governance
EN/ NL
Risico

GLM-5.3 bouwde werkende exploits in tests

Anthropic en NIST stellen vast dat open-weight model GLM-5.3 werkende exploits bouwt en zwakke safeguards heeft. Wat dat betekent voor isolatie, monitoring

4 oktober 2026 3 min
Illustratie bij dit artikel: GLM-5.3 bouwde werkende exploits in tests.
Open-weight modellen die exploits kunnen schrijven vereisen isolatie en monitoring die onafhankelijk van de ingebouwde weigeringen werken. Beeld: SecurityTechInsider — originele redactionele illustratie

U moet voor elke inzet van GLM-5.3 in productie aantonen dat het model onder vijandige omstandigheden is getest, dat isolatie en monitoring onafhankelijk van de ingebouwde weigeringen werken, en dat u kunt reconstrueren welke versie, onder welke voorwaarden, door wie is goedgekeurd.

De aanleiding is een analyse van 4 oktober 2026 van werkende exploits die GLM-5.3 in gesimuleerde tests bouwde, waarin wordt vastgesteld dat eenvoudige technieken de weigeringen van het model omzeilden. Het onderzoek gebruikte als voorbeeld een reeks cybersecurity-taken waarin het model in een materieel aandeel van de pogingen complete exploits produceerde. In onze inschatting betekent dit dat u niet op de standaard-weigering van een downloadbaar model kunt vertrouwen zodra het door derden wordt aangepast, en dat beveiliging daarom in de omgeving moet zitten, niet in het model zelf.

Wat toont het onderzoek over GLM-5.3?

Anthropics Frontier Red Team onderzocht de cybercapaciteiten van GLM-5.3 en de robuustheid van de modelweigeringen. Het model produceerde in een aanzienlijk, maar minderheids-aandeel van de taken complete, werkende exploits. Daarnaast meldt Anthropic dat misleidende prompts, voorafgevulde redeneertokens en een aangepaste versie van het model de ingebouwde weigeringen in hoge mate omzeilden. Het Amerikaanse NIST concludeerde onafhankelijk dat GLM-5.3 het meest cybercapabele open-weight model tot nu toe is.

Belangrijk: deze waren gesimuleerde tests zonder directe toegang tot echte systemen. Capaciteit in een testomgeving is niet hetzelfde als een reëel incident. Maar het risico is aantoonbaar aanwezig in het laboratorium, en de stap van laboratorium naar productie wordt bepaald door hoe u het model inzet.

Waarom faalt de ingebouwde weigering na modificatie?

Bij een gehost model dwingt de aanbieder de veiligheidsmaatregelen af. Bij een open-weight model dat u downloadt, verschuift die verantwoordelijkheid naar wie het draait. De gerapporteerde omzeilingen, tot en met een geablatieerde versie waarvoor Anthropic in de simulatie een bypasspercentage van 100% rapporteerde, tonen aan dat u op een ingebouwde weigering na modificatie niet als enige beveiligingslaag kunt vertrouwen.

Dit onderscheid is cruciaal: de standaard-weigering van een model is iets anders dan een beveiliging die ook onder vijandige prompts of na aanpassing van de gewichten blijft werken. Wie het eerste aanziet voor het tweede, overschat zijn controle.

Welke beveiligingslagen werken onafhankelijk van het model?

De beveiligingsmaatregelen die blijven effectief zijn niet de weigeringslaag, maar de omgeving eromheen:

  • Isolatie van productiesystemen — het model draait in een omgeving zonder directe verbinding naar kritieke bedrijfssystemen.
  • Least-privilege toegang — het model en de processen eromheen hebben alleen de minimale rechten die nodig zijn voor hun functie.
  • Standaard geblokkeerd uitgaand netwerkverkeer — alle externe verbindingen zijn standaard geweigerd tenzij expliciet toegestaan.
  • Monitoring op exploit-achtige uitvoer — u detecteert en logt pogingen tot command injection, path traversal of andere exploit-patronen.
  • Monitoring op tool-aanroepen — u volgt welke externe functies het model aanroept en onder welke voorwaarden.

Deze controles werken onafhankelijk van wat er aan de modelgewichten is veranderd. Een ingebouwde weigering doet dat niet.

Welke controles moet u kunnen aantonen?

Vóór elke productie-inzet moet u deze stappen hebben voltooid:

  1. Documenteer modelidentiteit en herkomst — leg vast welk model, welke versie, van welke bron, met welke gewichten u inzet.
  2. Voer een model- en versiespecifieke cyberevaluatie uit — test het model onder dezelfde omstandigheden als het in productie zal draaien, inclusief aangepaste gewichten en tools.
  3. Bouw isolatie in lagen — zorg dat het model in een geïsoleerde omgeving draait met standaard-deny uitgaand verkeer en least-privilege credentials.
  4. Stel monitoring en escalatie in — leg vast hoe u exploit-gerichte uitvoer detecteert, wie wordt gewaarschuwd, en wat de stopcriterium zijn.
  5. Leg goedkeuringen vast — documenteer wie het model onder welke voorwaarden heeft goedgekeurd, zodat later te reconstrueren is onder welke aannames u het hebt ingezet.

Wat kan tooling doen en wat niet?

Automatische monitoring en isolatie kunnen exploit-achtige uitvoer detecteren en het model van kritieke systemen afschermen. Wat tooling niet kan doen, is bepalen of het risico voor uw organisatie acceptabel is. Die afweging — welke cybercapaciteit u kunt tolereren, gegeven uw bedrijfscontext en uw tegenmaatregel — blijft uw eigen professionele oordeel. Tooling geeft u de feiten; u geeft ze betekenis.

Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Anthropic, National Institute of Standards and Technology, Center for AI Standards and Innovation, Github, Z.AI Developer Documentation en The Next Web.

Tobias Lindqvist

Geschreven door

Tobias Lindqvist

Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.