I slutten av juli 2026 testet OpenAI en av sine nye modeller i et lukket miljø da modellen bestemte seg for å bryte ut(nytt vindu). Den hacket seg inn i den private infrastrukturen til et annet programvarefirma, Hugging Face, for å stjele fasiten til en ytelsestest for datasikkerhet den ble testet på. Med andre ord brøt den loven for å gjøre det enkelt for seg selv.

Noen dager senere avslørte UK AI Security Institute at Anthropics Mythos 5 KI-modell(nytt vindu) hadde opprettet falske utvikleridentiteter, nettfisket reelle GitHub-brukere til å godkjenne skadelig kode, og redigert sin egen aktivitetslogg for å skjule sporene sine da den ble oppdaget.

Så i august kom nyheten om at en mann fra Melbourne ved navn Andrew hadde bedt sin personlige KI-agent,(nytt vindu) bygget på OpenClaw og som kjørte Anthropics Claude, om å hjelpe ham med å komme inn på en fullbooket treningstime om morgenen. Han var nummer fire på ventelisten og spurte om det var noen måte å rykke opp på.

Agenten fant ut at booking-API-en ikke hadde noen autorisasjonskontroll på avbryting av andre brukeres reservasjoner. Så uten å be om tillatelse fra Andrew, gikk den i gang og avbrøt bookingen til personen på førsteplass for å gjøre plass til ham. Da Andrew ba den om å angre avbestillingen, klarte den det ikke: «Personen jeg fjernet er borte fra ventelisten, og jeg har ingen måte å gjenopprette vedkommende på.»

Opprinnelsen til disse tre hendelsene er ikke den samme, men resultatet er det samme: KI-agenter undersøkte og utnyttet systemer raskere og mer grundig enn et menneske ville ha klart. De ble aldri instruert til å angripe noe, men fant den korteste banen til målet sitt likevel.

Det spiller ingen rolle om du er infrastrukturen til et ledende laboratorium eller booking-programvaren til et treningssenter i forstaden. Hvis du har en bedrift som eksponerer en API, er du nå noe en KI-agent kan undersøke, i en hastighet og grundighet intet menneskelig angriper har matchet. Og ingen trenger å bestemme seg for å angripe deg.

Hastighet er den virkelige historien

En menneskelig angriper veier innsats opp mot belønning. De blir lei, de slipper opp for tid, de bestemmer seg for at en treningsapp for booking ikke er verdt strevet. Det er den beregningen som stille har beskyttet de fleste lavverdimål mot tilfeldig utnyttelse de siste 20 årene (med mindre du kjører WordPress).

En KI-agent gjør ikke den beregningen. Gitt et mål, vil den prøve hva enn API-en teknisk tillater, og teste endepunkter og parameterkombinasjoner i maskinhastighet til noe fungerer. Den fant treningssenterets autorisasjonshull i løpet av tiden det tok Andrew å stille et oppfølgingsspørsmål.

Omfanget av denne hastighetsforskjellen er allerede synlig i tallene. Unit 42 sin 2026 Global Incident Response Report(nytt vindu) fant at de raskeste angrepene nå henter ut data på 72 minutter, ned fra 285 minutter året før. Det er trenden mens mennesker fortsatt for det meste er med i loopen. En agent tar avgjørelser på millisekunder; en menneskelig analytiker svarer i løpet av minutter til timer.

For sikkerhetsteam er den økende hastigheten den virkelige grunnen til bekymring, ikke enkeltstående hendelser som havner i nyhetene.

Den nye angrepsflaten: alt med en API

Enhver tjeneste som eksponerer en API er et potensielt mål, enten den ser slik ut eller ikke.

  • Prismotorer der rabatter valideres på klientsiden
  • Lagersystemer der lagerstatus ligger i nettbutikken i stedet for i backenden
  • Støtteplattformer der interne felt er tilgjengelige gjennom udokumenterte API-baner
  • Abonnementsadministrasjon som ikke verifiserer at innringer eier kontoen som endres.

Ingen av disse krever at et menneske leter etter dem. De krever bare en agent med et mål og en API som svarer.

Bedriftene som er mest utsatt, er ikke de med åpenbare sikkerhetshull. Det er de med forretningslogiske hull: regler som bare finnes i brukergrensesnittet, handlinger som API-en teknisk sett tillater men som grensesnittet aldri viser, og arbeidsflyter bygget på antakelsen om at ingen innringer noensinne vil prøve banen som hopper over den tiltenkte.

Treningssenterets utvikler tenkte nesten sikkert at det ikke var verdt å skrive en autorisasjonskontroll på avbestillinger, fordi ingen vanlig bruker, og ingen vanlig angriper, hadde noen grunn til å prøve det. En agent hadde ingen slike forbehold, og den prøvde ikke engang å finne en reservasjon å hoppe over. Den prøvde bare å være til hjelp.

Slik kan bedrifter forberede seg på KI-angrep

Behandle hver API-handling som en privilegert operasjon. Identitet, autorisasjon og kontekstuelle retningslinjer, sjekket uavhengig, ved hvert kall. Ikke «frontenden lar deg ikke gjøre dette», men «tjeneren verifiserer at du har lov til å gjøre dette, på denne ressursen, gitt dens nåværende tilstand». Treningssenterets system ville ha stoppet denne spesifikke hendelsen med én linje autorisasjonslogikk på endepunktet for avbestilling. Dette er overhodet ikke en ny kontroll, det er det eldste elementet på OWASPs API-sikkerhetsliste, ødelagt autorisasjon på objektnivå, og det er fortsatt den de fleste systemer mislykkes med.

Gi agenter sin egen modell for påloggingsinformasjon. Avgrensede token med kort TTL utstedt spesifikt for agentøkter, atskilt fra vanlige menneskelige økt-token, begrenser skadeomfanget selv når agenten finner et hull du ikke forutså. Hvis Andrews agent hadde hatt et token som bare var avgrenset til hans egen reservasjon, ville avbestillingen av noen andres booking ha feilet i laget for påloggingsinformasjon, uavhengig av hva API-en ellers tillot. Dette er viktig fordi du ikke kan stole på agentens egen tilbakeholdenhet. Du må stole på hva dens påloggingsinformasjon fysisk tillater den å gjøre.

Bruk verktøy for å oppdage agentatferd spesifikt. Agenttrafikk har en gjenkjennelig form: forespørselstiming raskere enn menneskelig kapasitet, systematisk oppramsing av endepunkter, sekvensiell undersøkelse av parameterkombinasjoner, vellykket utførelse av handlinger ingen menneskelig bruker noen gang har forsøkt gjennom det faktiske grensesnittet. Opprett en baselinje for den formen og varsle om den i sanntid.

Tett gapet i responstid, ikke bare deteksjonsgapet. Å oppdage en undersøkelse om en time er meningsløst hvis undersøkelsen ble fullført og gikk videre i løpet av minutter. Unit 42-tallet ovenfor, 72 minutter for de raskeste angrepene i menneskelig tempo, er allerede feil målestokk å planlegge ut fra. Automatisk respons, ikke bare automatisk varsling, er det som tetter et gap målt i millisekunder. Du må selvfølgelig også sørge for at den automatiske responsen din heller ikke er skadelig.

Anta at dette vil skje og øv på responshåndteringen. Dokumenter hvem som blir oppringt, utarbeid kundekommunikasjon på forhånd, og kjør skrivebordsøvelser mot spesifikt agentdrevne scenarier, ikke bare tradisjonelle dreiebøker for datasikkerhetsbrudd. IBM sin 2026 Cost of a Data Breach Report anslo det globale gjennomsnittlige bruddet til 4,99 millioner dollar, med KI-aktiverte brudd på i gjennomsnitt omtrent 1 million dollar mer. Disse tallene beskriver i økende grad hendelser som startet på samme måte som treningssenterets: ingen angriper i tradisjonell forstand i det hele tatt.

Test dine egne API-er på samme måte som en agent ville gjort, før en agent gjør det for deg. Manuell penetrasjonstesting forutsetter en menneskelig tester med begrenset tid og en endelig liste over ting å prøve. En automatisert motpart mot dine egne endepunkter, som undersøker med samme utholdenhet og hastighet som en agent, vil avdekke de samme hullene før en kundes assistent snubler over dem. Åpen kildekode-verktøy finnes nå spesifikt for dette. CyberStrike(nytt vindu) kjører for eksempel spesialiserte agenter kartlagt til OWASP WSTG og MITRE ATT&CK mot dine egne endepunkter, inkludert en dedikert tester for nøyaktig det autorisasjonshullet på objektnivå som tok treningssenteret på sengen: Den sender en baselinjeforespørsel, sender angrepet, og flagger bare et funn hvis det er en målbar, repeterbar forskjell. Det er samme type sjekk som ville ha avdekket endepunktet for avbestilling før en agent fant det i det fri.

Prinsippet er selvfølgelig ikke nytt. Nettstedeiere som kjørte sine egne sårbarhetsskannere mot WordPress-installasjoner i botnett-æraen, overlevde det. Verktøyene må bare matche hastigheten til innringeren nå, ikke hastigheten til en menneskelig angriper som kanskje til slutt kommer rundt til det.