MAI-Cyber-1-Flash er Microsofts specialiserede AI-model til at analysere kode for sårbarheder i MDASH-systemet. Modellen løser de fleste opgaver i et fleragentforløb, mens større modeller håndterer de sværeste tilfælde. Resultaterne viser potentiale for mere effektiv sikkerhedstest, men dokumenterer ikke automatisk fund af ukendte fejl i enhver kodebase.
MAI-Cyber-1-Flash er en specialiseret Microsoft-model, der arbejder i et fleragent-system til at finde og validere sårbarheder i software. Løsningen viser, hvordan mindre og større modeller kan fordeles efter opgavens sværhedsgrad, men adgang, benchmarkgrænser, menneskelig kontrol og behandling af følsom kildekode afgør den praktiske værdi.
Hvad har Microsoft lanceret?
Microsoft præsenterede MAI-Cyber-1-Flash den 27. juli 2026. Det er selskabets første model, som specifikt er udviklet til cybersikkerhed, og den er integreret i MDASH, et system til at finde, validere og hjælpe med at rette sårbarheder i software.
Lanceringen handler derfor om mere end en ny sprogmodel. Den centrale enhed er kombinationen af en specialmodel, andre AI-modeller, sikkerhedsdata og et fleragent-system. Microsoft oplyser, at MAI-Cyber-1-Flash er en kompakt, kodetung model baseret på samme udviklingslinje som ræsonneringsmodellen MAI-Thinking-1.
Microsofts juliudmelding beskriver ikke almindelig selvbetjent adgang, en offentlig pris eller særskilt tilgængelighed i bestemte lande. En tidligere beskrivelse af MDASH placerede systemet i en begrænset privat prøveperiode. Nyheden skal derfor læses som en produkt- og kapabilitetslancering, ikke som dokumentation for, at enhver udvikler allerede kan tage modellen i brug.
Hvad er MAI-Cyber-1-Flash?
MAI-Cyber-1-Flash er en specialiseret model til at undersøge komplekse kodebaser. Hvor en generel model skal kunne løse mange typer opgaver, er denne model indrettet til sikkerhedsarbejde med programkode, herunder analyse af mulige fejl og vurdering af, om en fejl kan udnyttes.
Specialiseringen gør ikke modellen til et selvstændigt sikkerhedsværktøj. Microsoft beskriver den som ét lag i MDASH. Det svarer til forskellen mellem en motor og hele det køretøj, der styrer retning, bremser, målinger og sikkerhed. I et AI-workflow afhænger resultatet både af modellen og af de trin, kontroller og værktøjer, som omgiver den.
Microsoft oplyser, at modellen er vurderet af selskabets eget AI Red Team, testet med automatiske og ekspertledede angreb og vurderet af en ekstern tredjepart. Kilden offentliggør ikke den fulde tredjepartsrapport, så oplysningerne dokumenterer en testproces, men ikke en uafhængigt efterprøvbar sikkerhedsgaranti.
Hvordan fungerer MDASH omkring modellen?
MDASH er en såkaldt harness: et styresystem omkring modeller og agenter. Det opdeler sikkerhedsanalysen i flere roller og faser i stedet for at bede én model om at gennemgå hele kodebasen i ét svar. Microsoft beskriver mere end 100 agenter, der kan arbejde med forskellige modeller.
| Lag | Funktion | Kontrolpunkt |
|---|---|---|
| MAI-Cyber-1-Flash | Analyserer kode og løser sikkerhedsopgaver | Modellens forslag kan være forkerte eller ufuldstændige |
| Specialiserede agenter | Søger, sammenligner, diskuterer og prøver fund | Roller og adgang skal begrænses til opgaven |
| MDASH | Orkestrerer modeller, værktøjer, dubletkontrol og beviser | Et fund bør først gå videre, når det kan reproduceres |
| Menneskelig sikkerhedsproces | Prioriterer, retter, tester og koordinerer offentliggørelse | En foreslået rettelse må ikke sættes i drift uden kontrol |
Den tidligere MDASH-beskrivelse fremhæver faser som målretning, validering, fjernelse af dubletter og praktisk bevis. Den arkitektur er relevant, fordi automatiske scannere ofte producerer lange lister over mulige problemer. Et reproducerbart bevis kan skelne en reel sårbarhed fra et fund, som kun ser mistænkeligt ud.
Hvorfor fordeles arbejdet mellem flere modeller?
MAI-Cyber-1-Flash er ifølge Microsoft designet til at håndtere op til 90 procent af opgaverne i systemet. De cirka 10 procent, som vurderes som særligt vanskelige, kan sendes til en større model, i den beskrevne opsætning GPT-5.4. Formuleringen beskriver en planlagt arbejdsdeling og er ikke et løfte om præcis samme fordeling i alle projekter.
Princippet er modelrouting: systemet vælger model efter opgavens sværhedsgrad, pris og krav. En mindre specialmodel kan behandle mange gentagne analyser, mens en dyrere model reserveres til problemer, der kræver mere omfattende ræsonnement. Det minder om fleragent-systemer, men rollerne behøver ikke bruge samme model.
Microsoft oplyser en omkostningsreduktion på 50 procent sammenlignet med selskabets hidtil bedste MDASH-opsætning med GPT-5.4, GPT-5.4 mini og GPT-5.3 Codex. Tallet er en intern sammenligning mellem to konkrete konfigurationer. Det viser ikke, at sikkerhedsarbejde generelt bliver halvt så dyrt, fordi licenser, beregning, tilpasning, menneskelig gennemgang og efterfølgende rettelser også påvirker den samlede omkostning.
Hvad viser CyberGym-resultatet?
Microsoft rapporterer en succesrate på 95,95 procent, afrundet til 96 procent, for kombinationen af MDASH, MAI-Cyber-1-Flash og GPT-5.4 på CyberGym. Det er ifølge selskabet omkring 12 procentpoint over Mythos i den samme sammenligning.
CyberGym er en offentlig ramme til at måle AI-agenters arbejde med virkelige, tidligere kendte sårbarheder. Den anvendte del omfatter 1.507 opgaver fra 188 open source-projekter. På niveau 1 får systemet den sårbare kode og en overordnet beskrivelse af sårbarheden og skal fremstille et input, som reproducerer fejlen.
Resultatet siger derfor noget konkret om evnen til at arbejde fra en kendt fejlbeskrivelse frem mod et fungerende bevis. Det er en mere afgrænset opgave end at finde en hidtil ukendt sårbarhed uden spor. Sammenligningen er desuden offentliggjort af Microsoft og er ikke i sig selv en uafhængig gentagelse af hele forsøget.
Hvad viser benchmarken ikke?
En høj score på CyberGym dokumenterer ikke, at systemet kan finde 96 procent af alle fejl i en vilkårlig kodebase. Kodesprog, arkitektur, dokumentation, adgang til bygge- og testmiljøer samt kvaliteten af fejlbeskrivelsen kan ændre resultatet.
- Benchmarken måler reproduktion af kendte sårbarheder under fastlagte betingelser.
- Den måler ikke hele processen fra ukendt fejl til sikker rettelse i produktion.
- Den viser ikke antallet af falske positive fund i alle typer kode.
- Den dokumenterer ikke, at en foreslået programrettelse bevarer funktion, ydeevne og kompatibilitet.
Microsofts tidligere MDASH-arbejde giver et bredere signal, fordi systemet ifølge selskabet bidrog til fund, som indgik i sikkerhedsrettelser til Windows. Også her afhænger resultaterne af interne værktøjer, eksperter og Microsofts adgang til egen kildekode. De kan ikke uden videre overføres til en mindre organisation med andre systemer og færre sikkerhedsdata.
Hvordan adskiller metoden sig fra almindelig kodescanning?
Traditionel statisk analyse leder typisk efter kendte mønstre, usikre funktioner eller brud på koderegler. AI-baseret analyse kan i stedet forsøge at forbinde adfærd på tværs af filer, følge ejerskab af hukommelse eller foreslå en sekvens, som udløser fejlen. De to metoder erstatter ikke nødvendigvis hinanden.
Microsofts system kombinerer modelbaseret ræsonnement med værktøjer, projektspecifikke plugins og praktisk afprøvning. Det centrale fremskridt ligger dermed i processen omkring modellen: flere hypoteser kan undersøges, fund kan udfordres af andre agenter, og et bevis kan køres i et isoleret miljø.
Samme skel findes i andre forsøg med AI-assisteret sårbarhedsanalyse. En model kan pege på et problem, men sikkerhedsarbejdet er først færdigt, når problemet er reproduceret, prioriteret, rettet og testet. Automatisering flytter arbejde mellem faserne; den fjerner ikke behovet for en ansvarlig proces.
Hvilke opgaver kan systemet understøtte?
Den dokumenterede kerne er analyse af programkode for sårbarheder. I et kontrolleret udviklingsmiljø kan en sådan arbejdsgang bruges til at supplere eksisterende kodegennemgang, prioritere mistænkelige fund og konstruere test, der viser, om en fejl faktisk kan udløses.
- Gennemgang af komplekse kodeforløb på tværs af flere filer.
- Sammenligning af forskellige steder, hvor samme type objekt eller data behandles.
- Validering og deduplikering af mulige sårbarheder.
- Fremstilling af reproducerbare test i et isoleret miljø.
- Forslag til rettelser, som derefter gennemgår almindelige softwaretest.
Disse opgaver kræver adgang til kode, byggeværktøjer og i nogle tilfælde information om konkrete systemer. Et system, der må afprøve udnyttelse, bør ikke have ukontrolleret adgang til produktionsmiljøer eller internettet. Microsoft oplyser, at MDASH anvender rollebaseret adgang, tenant-adskillelse, kryptering, logning og sandkasser uden internetadgang. Den konkrete konfiguration skal stadig kontrolleres i den enkelte installation.
Hvilke kontroller kræver brug i praksis?
AI-genererede sikkerhedsfund kan både overse reelle fejl og markere ufarlig kode. En praktisk proces bør derfor adskille analyse, bevis, rettelse og godkendelse. Den samme person eller agent bør ikke ukontrolleret kunne finde et problem, ændre produktionskode og frigive ændringen.
- Afgræns de kodebaser og systemer, som må analyseres.
- Kør reproduktion og eventuel udnyttelse i et isoleret testmiljø.
- Lad en sikkerhedsfaglig person kontrollere alvor, rækkevidde og bevis.
- Test rettelsen for funktionelle fejl og nye sikkerhedsproblemer.
- Dokumentér godkendelse, logning og eventuel koordineret sårbarhedsrapportering.
Kontrollerne følger samme grundidé som arbejdet med kontrol af avancerede AI-agenter: adgang og konsekvens bør begrænses, mens handlinger kan spores og stoppes. Et højt benchmarkresultat ændrer ikke på, at fejlrettelser kan få driftsmæssige konsekvenser.
Hvad betyder udviklingen for organisationer i Danmark?
For virksomheder og offentlige arbejdspladser i Danmark er den nærmeste betydning en mulig ændring i, hvordan sikkerhedsteams fordeler deres tid. Mere af den indledende analyse og reproduktion kan automatiseres, mens medarbejdere koncentrerer sig om alvor, systemkontekst, rettelser og ansvarlig offentliggørelse. Effekten afhænger dog af adgang, pris og dokumenteret kvalitet på organisationens egne kodebaser.
Kildekode kan indeholde forretningshemmeligheder, adgangsoplysninger, loguddrag og i visse tilfælde personoplysninger. Hvis personoplysninger behandles, gælder GDPR-principper som formålsbegrænsning, dataminimering, integritet og fortrolighed. Før ekstern behandling bør organisationen kende dataplacering, opbevaring, underdatabehandlere, adgangsstyring og muligheder for sletning.
Microsofts generelle oplysning om kryptering og tenant-adskillelse kan indgå i vurderingen, men den afgør ikke alene, om en konkret anvendelse er lovlig eller sikker. En indkøbs- eller prøveproces bør også afklare, om kode forlader organisationens miljø, om data bruges til modeludvikling, og hvordan hændelseslogning kan revideres. Den officielle kilde dokumenterer ikke særlige vilkår for Danmark.
Hvad kan ændre sig efter lanceringen?
Microsoft skriver, at agentplatformen Perception senere skal bruge MAI-Cyber-1-Flash til flere sikkerhedsopgaver end sårbarhedsanalyse af software. Det er en planlagt udvidelse, og kilden angiver ikke en fast dato eller en fuld liste over funktioner.
Den vigtigste udvikling at følge er derfor ikke kun en højere benchmarkscore. Bred adgang, dokumenterede testbetingelser, uafhængige evalueringer, pris, datavilkår og resultater på andre kodebaser vil afgøre, hvor stor praktisk betydning modellen får. Det samme gælder, om systemet kan reducere både oversete fejl og unødvendige alarmer uden at skabe en ny flaskehals i den menneskelige gennemgang.
Hvilke kilder ligger til grund?
Artiklen bygger på Microsofts lancering af MAI-Cyber-1-Flash og den tekniske beskrivelse af MDASH-systemets arbejdsproces. Benchmarkens omfang er kontrolleret mod CyberGym-observatoriet, mens den lokale databeskyttelsesvinkel følger Datatilsynets oversigt over GDPR-principperne.