Google Mantis lar kodeagenter bevise sårbarheter før de lapper dem

Google Mantis gir kodeagenter en hel arbeidsflyt for å finne, bevise og reparere sårbarheter – ikke bare en ny måte å produsere alarmer på. En mistenkt feil skal gjennom flere porter: duplikater fjernes, falske positiver filtreres bort, feilen forsøkes reprodusert i en isolert sandbox, lappen testes og den ferdige rettelsen angripes på nytt.

Hvis du utvikler programvare med AI-agenter, er dette en viktig forskjell. Det er ganske enkelt å få en språkmodell til å peke på kode som ser farlig ut. Det vanskelige er å avgjøre om feilen faktisk kan oppstå, om den betyr noe i produksjon, og om rettelsen virkelig stenger angrepsveien.

Mantis angriper akkurat dette problemet med en modulær samling skills som kan brukes av forskjellige kodeagenter og tilpasses forskjellige teknologistakker. Arkitekturen er lovende. Samtidig er Googles egen advarsel tydelig: Prosjektet er laget for demonstrasjon, er ikke et offisielt støttet Google-produkt og skal ikke behandles som produksjonsklar sikkerhetsautomatisering.

Hva er Google Mantis?

Google Mantis er et åpent sett med sekvensielle sikkerhets-skills for AI-kodeagenter. Ifølge prosjektets README på GitHub er målet å gi utviklere et utgangspunkt for en komplett sikkerhetsgjennomgang som kan tilpasses egen kodebase, trusselmodell, byggesystem og risikotoleranse.

Det er altså ikke en ferdig skanner med en knapp og et dashboard. Hver skill har en avgrenset oppgave og utveksler strukturert tilstand med neste steg. Mantis kan blant annet lese historikken i repositoriet, bygge en kunnskapsbase over arkitekturen, lage en trusselmodell, planlegge gjennomgangen, lete etter feil og samle funn som beskriver samme underliggende sårbarhet.

Google beskriver verktøyet som plattformuavhengig. Selskapet har brukt det med Gemini CLI og Antigravity CLI, og dokumentasjonen sier at andre rammeverk for kodeagenter også skal kunne fungere. Skillsene kan dessuten tilpasses spesialområder som maskinvare, Infrastructure as Code, maskinlæringspipelines og firmware.

Lisensen er Apache 2.0. Det gjør det mulig å bruke, endre og bygge videre på materialet, også i kommersielle sammenhenger, så lenge lisensvilkårene følges. Den åpne lisensen gjør imidlertid ikke prosjektet produksjonsklart av seg selv. Kode som kan utløse sårbarheter, er fortsatt kode du bør ha stor respekt for.

Hvorfor er reproduksjon viktigere enn modellens selvtillit?

En sikkerhetsrapport blir langt mer nyttig når påstanden kan underbygges av en faktisk reproduksjon. Google skriver at slurvete AI-skanning ofte gir en andel reelle funn på under 7 prosent. Mantis bruker derfor egne review- og critic-steg, før en reproducer lager et konkret testtilfelle og kjører det i et isolert miljø.

Dette er den mest interessante delen av hele prosjektet. En språkmodell kan formulere en svært overbevisende forklaring på en sårbarhet som ikke finnes. Når funnet må overleve negative filtre, en vurdering av om feilen kan nås i produksjon og en proof of concept som faktisk utløser problemet, blir beviset viktigere enn hvor sikker modellen høres ut.

Mantis stopper heller ikke ved reproduksjonen. Patcher-steget lager en minst mulig rettelse, kontrollerer den i sandboxen og prøver deretter en variant av angrepet. Først etter dette beregnes en Mantis Risk Score fra 1 til 10 basert på konsekvens, bevis og praktisk gjennomførbarhet. Et menneske får dermed et bedre grunnlag for prioritering enn «modellen tror dette er kritisk».

Hvordan er sikkerhetsløpet bygget opp?

Den manuelle arbeidsflyten i dagens dokumentasjon viser 16 slash-kommandoer når det valgfrie structural-index-steget telles med, før én avsluttende menneskelig vurdering. Noen av de første stegene er valgfrie, men kjernen går fra kartlegging og trusselmodell til søk, validering, reproduksjon, patching og rapport. Hele poenget er at agenten ikke skal hoppe rett fra mistanke til kodeendring.

1. Forstå kodebasen: Historikk, katalogstruktur og arkitektur samles i en kunnskapsbase. Deretter bygges en levende trusselmodell og en plan over angrepsflaten.
2. Finn og rydd: Researcher-steget leter etter mulige svakheter. Dedupe slår sammen overlappende funn, mens review og critic fjerner falske positiver og problemer som ikke er praktisk gjennomførbare i produksjon.
3. Bevis: Reproducer lager et testtilfelle eller en rå payload og kjører den i en sandbox uten nettverk. Bekreftede enkeltfunn kan også settes sammen til mulige angrepskjeder.
4. Reparer og kontroller: Patcher lager en liten rettelse og angriper den på nytt. Deretter risikovurderes funnet, erfaringene fra kjøringen lagres og en lesbar rapport bygges.

De enkelte stegene skriver maskinlesbare funn til JSON-filer. Google publiserer også kontraktene mellom stegene og anbefaler en deterministisk orkestrator for mer seriøs bruk. Det er et godt arkitekturvalg: En vanlig agent kan glemme å kalle en kritiker eller å slå av nettverket. En fast pipeline kan håndheve dette uansett hva modellen finner på.

For store kodebaser kan Mantis bygge et hierarkisk sammendrag fra enkeltfiler til kataloger og rot. Google Cloud oppgir at dette reduserte tokenbruken med over 85 prosent, samtidig som vesentlig strukturell kontekst ble bevart. Det er viktig når agenten ellers ville brukt store deler av kontekstvinduet bare på å finne fram.

Hva må du gjøre for å kjøre Mantis trygt?

Start interaktivt og bruk et dedikert, isolert miljø. Google anbefaler at de enkelte slash-kommandoene kjøres én etter én, med menneskelig godkjenning før agenten får skrive filer eller kjøre kode. Ikke slå på automatisk godkjenning med --yolo eller --dangerously-skip-permissions på en vanlig utviklingsmaskin.

Prosjektet foreslår Docker for testcontainere og gVisor som et sterkere isolasjonslag. Reproducer- og patcher-stegene er instruert til å kjøre genererte payloads med nettverket avslått, for eksempel med --network none. Men dette er instruksjoner til en ikke-deterministisk agent, ikke en fysisk sikkerhetsgrense. Google anbefaler derfor en dedikert, isolert VM som agenten ikke kan hoppe ut av ved bare å «glemme» riktig flagg.

Det rådet bør tas bokstavelig. Ikke kjør Mantis på en maskin som har tilgang til produksjonssystemer, interne nettverk, kundedata, SSH-nøkler eller andre hemmeligheter. En reproducer er laget for å utløse en feil. Hvis agenten tar feil av katalog, container eller vertsmaskin, er ikke «den mente det godt» en særlig nyttig gjenopprettingsplan.

Installasjonen kan gjøres med npx skills add google/mantis, men det første fornuftige steget er et smalt utsnitt av kodebasen. Dokumentasjonen anbefaler å justere de negative filtrene etter prosjektet før du slipper løs en gjennomgang av hele repositoriet. Gi også agenten menneskeskrevet kontekst om arkitektur, byggeregler og hvilke typer feil som faktisk skal prioriteres.

Kan Mantis brukes i en automatisert pipeline?

Ja, arkitekturen er laget slik at skillsene kan pakkes inn i en deterministisk pipeline. Googles agentguide anbefaler dette for mer pålitelig orkestrering, strengere sandboxing, CI/CD-integrasjon og reproducerbare rapporter. Hvert steg kan behandles som en avgrenset tjeneste som leser og oppdaterer strukturert tilstand.

Det er også her Mantis går fra spennende demo til et mulig byggegrunnlag. En orkestrator kan låse et bestemt snapshot av kodebasen, håndheve at ukjent kode bare kjøres i riktig VM, kreve at critic-steget alltid fullføres og nekte patching dersom reproduksjonen mangler. Da ligger de viktigste garantiene i programmet rundt modellen, ikke i håpet om at en lang prompt blir fulgt perfekt.

Men automatisk betyr ikke ubemannet. Dokumentasjonen sier uttrykkelig at alle funn skal kontrolleres manuelt av en sikkerhetsekspert før de rapporteres. Utviklere skal heller ikke masseinnrapportere ubekreftede AI-funn til open source-prosjekter. En vellykket reproduksjon beviser ikke automatisk at feilen kan utnyttes i alle miljøer, og en mislykket reproduksjon beviser ikke at funnet er falskt.

Angrepskjeder har dessuten en viktig begrensning: Mantis kan kombinere flere bekreftede enkeltfunn til en kjede, men kjører ikke hele kjeden fra ende til ende. Den regnes som statisk bekreftet når delene er bekreftet hver for seg. Den samlede utnyttelsen må fortsatt vurderes manuelt eller håndteres av en egen, tilpasset orkestrator.

Hvem får mest nytte av Mantis?

Mantis passer best for utviklere og sikkerhetsteam som allerede bruker kodeagenter og som kan bygge et forsvarlig testmiljø rundt dem. Små bedrifter kan få verdi av den åpne arbeidsflyten, særlig hvis alternativet er tilfeldig sikkerhetsgjennomgang eller ingen gjennomgang i det hele tatt. Men teamet må eie sandboxen, akseptansekriteriene og den menneskelige kontrollen.

Det er ikke et verktøy jeg ville pekt på til en nybegynner og sagt «installer dette på laptopen og trykk start». Mantis gir agenten oppgaver som innebærer å lage og kjøre potensielt farlig kode. Uten isolasjon, begrensede rettigheter og kontroll på hemmeligheter kan sikkerhetsverktøyet bli den farligste prosessen på maskinen.

Likevel er retningen riktig. AI-sikkerhet blir ikke troverdig av flere selvsikre tekstbokser. Den blir bedre når funn må gjennom dokumenterte porter, når testene kan gjentas og når en patch må tåle et nytt angrep før den får grønt lys. Mantis gjør denne tankegangen tilgjengelig som open source i stedet for å gjemme den i et internt Google-system.

Min dom er derfor ganske enkel: Mantis er et nyttig og gjennomtenkt utgangspunkt for agentdrevet sikkerhetsarbeid, men ikke en ferdig sikkerhetsavdeling på autopilot. Bruk arbeidsflyten. Bygg harde grenser rundt agenten. Og la et menneske med sikkerhetskompetanse ta den siste avgjørelsen.

Ofte stilte spørsmål