Filter

Blog

AI-sårbarhedsstormen er på vej

Den stigende anvendelse af security‑capable AI i sårbarhedsresearch og exploit‑udvikling forandrer trusselsbilledet fundamentalt. Time‑to‑exploit kollapser, og patching bevæger sig mod realtid, hvor patches samtidig kan fungere som blueprint for nye angreb. Læs hvad det betyder, og hvordan I bør reagere.

Læsetid: 14 minutter

Fadi Dasus

Cloud Security Architect, Conscia DK

AI-sårbarhedsstormen er på vej – featured image

AI har flyttet sikkerhed fra planlagte cyklusser til et kapløb mod tid. I praksis betyder det, at vinduet mellem sårbarhed og exploitation er skrumpet dramatisk, samtidig med at traditionelle patch‑processer og sikkerhedsantagelser er sat under pres.

Denne blog gennemgår, hvad der driver udviklingen, fra security‑capable AI til accelereret patching, og hvilke konsekvenser det har for sikkerhedsarkitektur og governance. Samtidig skitseres de konkrete tiltag, organisationer bør prioritere nu for at reducere eksponeringen.

Security-capable AI er her, og ændrer spillereglerne lige nu

I april 2026 lancerede Anthropic Claude Mythos Preview, en intern model der autonomt opdagede zero-days på tværs af alle større operativsystemer og browsere, opnåede en exploit success rate på 72,4 % mod Firefox og identificerede en 27 år gammel sårbarhed i OpenBSD (2).

Om Mythos præcis er, hvad virksomheden hævder – og de tal, uafhængige partnere rapporterer, tyder på, at det i høj grad er – eller om det viser sig at være den mest effektive marketingkampagne i teknologiens historie, er mindre vigtigt.

Retningen er ikke længere til diskussion. En security-capable model i denne klasse er enten allerede her eller meget tæt på. Den asymmetri, den skaber, er strukturel – ikke midlertidig. En måned efter Mythos offentliggjorde Microsoft MDASH, et system bestående af mere end 100 specialiserede AI-agenter, som toppede en førende branchebenchmark (9). Hvis det først er blevet synligt ved offentliggørelsen, er de kapabiliteter, vi kender til, næsten med sikkerhed ikke hele billedet.

Exploit-hastigheden er kollapset

Overvej hvad det betyder i praksis. Den gennemsnitlige tid fra offentliggørelse af en sårbarhed til bekræftet exploitation er faldet fra næsten et år i 2021 til lidt over en dag i 2026, med en forventet udvikling mod én time og derefter ét minut. Andelen af sårbarheder, der allerede blev udnyttet på tidspunktet for offentliggørelse, er steget fra 31 % for fem år siden til 73,2 % i dag, og antallet af offentliggjorte sårbarheder, der forbliver uudnyttede efter seks uger, er i praksis nul (1). 

Dette kollaps skyldes ikke, at angribere generelt er blevet “klogere”. Det skyldes, at AI er blevet rettet mod sårbarhedsresearch, og kurven er blevet markant stejlere det seneste år. 

AI sænker omkostningen og kompetencetærsklen for at finde den første exploit path langt hurtigere, end nogen organisation kan lukke resten. I en formel benchmark mod Firefox-sårbarheder genererede Claude Mythos Preview 181 fungerende exploits, hvor den tidligere generation kun fandt to (3). Det er ikke en inkrementel forbedring – det er et kvantespring i autonomi og pålidelighed, og det bliver ikke det sidste.  
 

De fleste sikkerhedsprogrammer er bygget til en verden, der er væk

Budskabet er ubehageligt, men vigtigt: De antagelser, der ligger til grund for de fleste sikkerhedsprogrammer i dag; patch cycles målt i uger, kvartalsvise penetration tests, human-speed incident response og CVE-drevet threat intelligence, er bygget til en verden, der ikke længere eksisterer. En angriber behøver én fungerende exploit path. En forsvarer skal lukke dem alle.

Patch-bølgen er startet, men skalerer ikke

Anthropics svar, Project Glasswing, gav omkring 50 kritiske infrastrukturleverandører og open source-maintainere tidlig adgang til at patche deres produkter før offentliggørelse. I den første måned identificerede partnerne mere end 10.000 high- og critical-severity sårbarheder (4). Det er den største multi-party vulnerability coordination-indsats i historien – og samtidig per definition utilstrækkelig. De fleste organisationer vil aldrig være en del af et kurateret partnerprogram som dette. Den defensive fordel ved early access er desuden tidsbegrænset. Sammenlignelige offensive kapabiliteter forventes i andre frontier-modeller inden for måneder – og i open-weight modeller tilgængelige for alle inden for seks til tolv.

Der er også en andenordenseffekt: Hver patch er i praksis en exploit blueprint. AI accelererer patch-diffing og reverse engineering af fixes, hvilket betyder, at kapløbet ikke længere starter ved disclosure – det starter ved commit’et.

Hvad betyder det for din organisation?

I de kommende uger og måneder vil partnerne i Glasswing, og resten af økosystemet bagefter, frigive en mængde kritiske patches, som branchen ikke har set før. Palo Alto Networks har allerede frigivet mere end fem gange så mange patches som normalt i én cyklus, og Microsoft har indikeret, at volumen vil fortsætte med at stige (5).

Hvis jeres patching-program allerede er presset, hvis teamet er underbemandet, eller hvis jeres change management foregår i uger frem for dage, vil bølgen ramme hurtigere, end jeres nuværende processer kan absorbere. Vinduet til at forberede sig er nu – før disclosures rammer. Triage capacity, deployment automation, change approval paths og rollback-procedurer skal kunne operere i et højere tempo end nogensinde før.

Organisationer, der har gjort dette forarbejde og arbejder ud fra en Zero Trust-tilgang med et assume-breach mindset, vil kunne følge med bølgen. Dem, der ikke har, vil falde bagud, og i dette miljø er det sådan, eksponering ser ud.

Når patchen ikke kommer frem i tide

Hvis vinduet til patching er reduceret til timer, er spørgsmålet ikke længere “hvor hurtigt kan vi implementere fixet”, men “hvad sker der, når vi ikke kan?”

Svaret ligger i arkitekturen: De kontroller, der begrænser blast radius uanset hvilken sårbarhed der udnyttes. Det er grundtanken bag zero trust. At behandle ethvert miljø som potentielt kompromitteret, enhver identitet som uverificeret, og enhver succesfuld adgang som et delvist brud snarere end et fuldbyrdet.

Her bliver principper, branchen har diskuteret i årevis, pludselig load-bearing:
  • Segmentation afgør om én exploit bliver til én hændelse eller en fuld forretningsforstyrrelse
  • Egress filtering afgør om en kompromitteret host kan nå sin command-and-control infrastruktur
  • Phishing-resistant MFA på privilegerede konti afgør om et stjålet credential kan udnyttes eller stoppes 
  • Identity-aware access, microsegmentation og least privilege er afgørende for, hvor langt en angriber kan bevæge sig, når de først er indeUdarbejd en AI-politik, der er enkel at forstå og efterleve.

Deception bør også indgå på denne liste. Canaries, honey tokens og decoy‑assets er uafhængige af både attack tools og sårbarheder. De identificerer angribere baseret på adfærd frem for signaturer, hvilket gør dem robuste over for AI‑opdagede zero-days, som ingen detektionsregler tidligere har set. I et miljø, hvor threat intelligence strukturelt halter bagefter nye opdagelser, er adfærdsbaserede fælder en af de få kontroller, der skalerer. 
 

Intet af dette er ny rådgivning. Det, der har ændret sig, er omkostningen ved ikke at have det på plads. I en verden, hvor time-to-exploit måles i minutter, og hvor threat intelligence strukturelt er forsinket, er de arkitektoniske kontroller, der begrænser skade, ikke længere et modenhedsmål på næste års roadmap. De er forskellen på en hændelse og en krise. 

IT-forsvaret bør tage AI i brug nu – også uperfekt AI

Der er et paradoks i centrum af den nuværende situation. Offensive AI-kapabiliteter er modne, dokumenterede og bliver hurtigt bredt tilgængelige. Defensive AI-produkter, der er designet til at opdage AI-genererede angreb eller køre autonom respons, halter bagefter. De er langsommere til at modnes og er ofte bundet til enkelte leverandørers økosystemer.

De kapabiliteter, der betyder mest lige nu, ligger i at bruge de samme coding agents og large language models (LLM’er), som angriberne allerede anvender, men rettet indad.

Brug værktøjerne rigtigt og få en fordel

Det første skridt i IT-forsvaret er det simpleste. Enhver organisation kan i dag bede en agent om at gennemgå sin egen kode for sårbarheder, og enhver organisation kan integrere LLM-drevet security review i sin CI/CD pipeline, så både menneskeskrevet og AI-genereret kode gennemgår en konsistent kontrol, før den når produktion. Dette er ikke længere eksperimentelt. Det er det billigste enkelte tiltag, der lukker gap’et mellem hvor hurtigt kode deployes, og hvor hurtigt den bliver gennemgået.

Det andet skridt er at give LLM’en kontekst. En coding agent, der intet ved om jeres forretning, er et generisk værktøj. En coding agent, der ved hvilke leverandør I er afhængige af, hvilke versioner I kører, hvilke services der afhænger af hvilke biblioteker, og hvilke systemer der er forretningskritiske, bliver en kontinuerlig asymmetrisk fordel. Overvej hvad der bliver muligt. Agenten overvåger offentlige commits og security advisories fra de leverandører, der indgår i jeres stack, og flager relevante ændringer i det øjeblik, de opstår – ikke uger senere, når en CVE bliver tildelt. Den kortlægger upstream- og downstream-afhængigheder af en foreslået patch op imod jeres faktiske miljø, så I allerede ved, hvad den påvirker, hvad den potentielt bryder, og hvad den beskytter, inden patchen når jeres change advisory board. Den kører kontinuerlig, proaktiv gennemgang af jeres egen kodebase med de samme teknikker, som angribere vil bruge imod den, så de sårbarheder I deployer, er dem I selv fandt først.

Det tredje skridt er operationelt. Coding agents kan allerede accelerere det arbejde, blue teams udfører hver dag. De kan triagere og validere indkommende patches hurtigere, end en menneskelig kø kan absorbere. De kan køre red team-øvelser mod jeres eget miljø løbende – ikke på kvartalsbasis. De kan automatisere indsamling af audit-data og evidens. De kan omsætte alert-støj til prioriterede, kontekstualiserede incidents. Intet af dette kræver en ny produktkategori. Det kræver de samme agents, som allerede er i udbredt brug – med den rette adgang, de rette instruktioner og de rette guardrails.

På længere sigt peger retningen mod det, industrien begynder at kalde VulnOps. En permanent funktion, bemandet og automatiseret på samme måde som DevOps, med ansvar for kontinuerlig, AI-drevet discovery og remediation af sårbarheder på tværs af hele softwarelandskabet. At etablere den er et 12-måneders projekt for de fleste organisationer. At begynde at opbygge musklen er et projekt, der kan starte denne uge.

Under værktøjerne ligger et kulturelt skift, der er lige så vigtigt som værktøjerne selv. Enhver sikkerhedsrolle bliver i stigende grad også en AI-bygge-rolle. Barrieren for at komme i gang er lavere, end de fleste tror. Teams, der læner sig ind i dette tidligt, vil operere med maskinhastighed dér, hvor det gælder. Teams, der venter, vil fortsætte med manuel triage, mens deres modstandere ikke gør.

Kapacitets- og governance-gap’et

Over det næste år vil to mindre synlige skift adskille de organisationer, der tilpasser sig, fra dem der får det svært. Ingen af dem er tekniske.

Det første er kapacitet. Industrien investerer massivt i AI-kapabiliteter fx. i frontier models, agent-infrastruktur og developer tooling. Den parallelle investering i den menneskelige kapacitet til at forsvare sig mod det nye trusselsbillede følger ikke med. Sikkerheds teams absorberer eksponentielle stigninger i workload: mere kode, der deployes hurtigere, flere sårbarheder, flere incidents, flere værktøjer. Typisk uden tilsvarende vækst i headcount, budget eller trivsel. AI-drevne produktivitetsgevinster på den offensive side akkumulerer for angribere.

På den defensive side bliver de ofte blot til ekstra belastning for de samme mennesker. Burnout og tab af ekspertise er ikke et HR-problem. Det er en direkte operationel risiko, fordi den ekspertise, der kræves for at navigere i denne transition, tager år at opbygge og ikke kan skaffes på kort sigt. Et security-team uden plads til at opkvalificere sig, som konstant reagerer på det, resten af forretningen allerede har deployet, bliver en forpligtelse i det øjeblik trusselsbilledet ændrer sig. Det øjeblik er nu.

Governance skifter fra compliance til ansvar

Det andet skift er governance, som nu har en regulatorisk dimension. EU AI Act introducerer en risikobaseret model med fire kategorier: uacceptabel risiko, høj risiko, begrænset risiko og minimal risiko. Den kategori, der er mest relevant for de fleste enterprise deployments, er høj risiko (6). Under Artikel 6 og Annex III falder AI-systemer anvendt i områder som kritisk infrastruktur, beskæftigelse, adgang til essentielle services, retshåndhævelse og biometriske/sikkerhedskritiske komponenter i denne kategori, og udløser krav til risikohåndtering, datastyring, menneskeligt tilsyn, teknisk dokumentation, præcision, robusthed og cybersikkerhed.

For IT-sikkerhedsledere er det her ikke et fremtidigt problem. Når AI-drevet scanning bliver bredt tilgængelig, flytter standarden for “rettidig omhu” sig med den, og bestyrelser vil i stigende grad blive mødt med spørgsmålet: Er det uagtsomt ikke at bruge de AI-værktøjer, der er tilgængelige?

Det praktiske udgangspunkt for compliance med Annex III: Kortlæg de AI-systemer, I allerede bruger, klassificér dem efter Act’ens risikoniveauer, og identificér hvilke der falder i højrisiko kategorien. Vurderingen bør påbegyndes nu, da kravene til selvstændige højrisiko AI-systemer under Annex III træder i kraft den 2. august 2026, sammen med særskilte forpligtelser for både udbydere og brugere (7).

Bemærk: EU har opnået politisk enighed om at udskyde denne dato til slutningen af 2027 som en del af Digital Omnibus (8), men indtil ændringen er formelt vedtaget, er 2. august 2026 den gældende dato.

Begge skift peger i samme retning. At overleve AI-sårbarhedsstormen handler ikke kun om bedre værktøjer og strammere arkitektur. Det handler om at finansiere de mennesker, der driver dem, og fjerne governance-barrierer, så der kan handles i det tempo, trusselsbilledet kræver.

Konklusion: Vi har gjort det før 

Sikkerhedsindustrien har tidligere håndteret systemiske, deadline-drevne udfordringer. Y2K var en strukturel trussel med en fast deadline, og den blev håndteret gennem koordineret indsats, disciplineret engineering og fokuseret arbejde på tværs af tusindvis af organisationer. Mønstret er det samme nu, men med to forskelle: Deadline er kortere, og værktøjerne er stærkere.

At være klar til det, der kommer efter Mythos, handler mindre om at reagere på én model eller én announcement og mere om permanent at lukke gap’et mellem, hvor hurtigt sårbarheder opdages, og hvor hurtigt organisationer kan reagere. Det gap lukker ikke af sig selv. Det lukkes gennem arkitektur, der er designet til at begrænse fremfor kun at forhindre, gennem forsvar der bruger AI lige så rutinemæssigt som angribere gør, gennem investering i de mennesker, der driver programmet, og gennem governance, der kan følge tempoet i trusselsbilledet.

Intet af dette kræver, at man venter. Hver eneste handling beskrevet i denne blog kan påbegyndes denne uge. Organisationer, der opbygger kapaciteten nu, vil møde næste bølge på egne præmisser. Dem, der venter på klarhed, vil møde den på stormens præmisser.

Referencer

  1. Zero Day Clock, Sysdig. https://zerodayclock.com and https://zerodayclock.com/collapse 
  2. “Anthropic’s Claude Mythos Autonomously Discovers, Exploits Zero-Days,” SecureWorld, April 2026. https://www.secureworld.io/industry-news/anthropic-claude-mythos-finds-exploits-zero-days
  3. “Anthropic’s new AI model finds and exploits zero-days across every major OS and browser,” Help Net Security, April 2026. https://www.helpnetsecurity.com/2026/04/08/anthropic-claude-mythos-preview-identify-vulnerabilities
  4. “Anthropic: Claude Mythos identified 10,000+ software flaws,” Help Net Security, May 2026. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update
  5. “Project Glasswing: Anthropic says Claude found 10,000 critical software flaws in a month,” Interesting Engineering, May 2026. https://interestingengineering.com/ai-robotics/anthropic-project-glasswing-10000-software-vulnerabilities
  6. “Article 6: Classification rules for high-risk AI systems,” European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6
  7. “Annex III: High-risk AI systems referred to in Article 6(2),” European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
  8. “EU AI Act Implementation Timeline.” Primary source: https://artificialintelligenceact.eu/implementation-timeline/. Supporting analysis: https://labs.cloudsecurityalliance.org/research/csa-research-note-eu-ai-act-high-risk-compliance-deadline-20/
  9. Microsoft’s new multi-model agentic security system tops leading industry benchmark,” Microsoft Security Blog, May 2026. https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/
Om forfatteren

Fadi Dasus

Cloud Security Architect, Conscia DK

A passionate Cloud Security Specialist and Cloud Native Kubeastronaut, dedicated to enhancing security in modern cloud environments and advocating for a zero-trust security strategy.

Fadi Dasus

Cloud Security Architect, Conscia DK

Seneste Blog indlæg

Relateret

Resourcer