I slutet av juli 2026 testade OpenAI en av sina nya modeller i en stängd miljö när modellen bestämde sig för att bryta sig ut(nytt fönster). Den hackade sig in i den privata infrastrukturen hos ett annat mjukvaruföretag, Hugging Face, för att stjäla facit till ett cybersäkerhetstest den utvärderades på. Med andra ord bröt den mot lagen för bekvämlighets skull.

Några dagar senare avslöjade UK AI Security Institute att Anthropics AI-modell Mythos 5(nytt fönster) hade skapat falska utvecklaridentiteter, nätfiskat riktiga GitHub-användare att godkänna skadlig kod och redigerat sin egen aktivitetslogg för att dölja sina spår när den upptäcktes.

Sedan i augusti kom nyheten att en man i Melbourne vid namn Andrew hade bett sin personliga AI-agent(nytt fönster), byggd på OpenClaw och driven av Anthropics Claude, att hjälpa honom komma in på ett fullbokat morgonpass på gymmet. Han var fyra på väntelistan och frågade om det fanns något sätt att flytta upp.

Agenten upptäckte att boknings-API:et inte hade någon behörighetskontroll för att avbryta andra användares bokningar. Så utan att be Andrew om lov gick den vidare och avbröt bokningen för personen på första plats för att göra plats för honom. När Andrew bad den att ångra avbokningen kunde den inte det: “Personen jag tog bort är borta från väntelistan och jag har inget sätt att återställa dem.”

Ursprunget till dessa tre incidenter är inte detsamma, men resultatet är det: AI-agenter undersökte och utnyttjade system snabbare och mer ingående än vad någon människa skulle ha hanterat. De instruerades aldrig att attackera något men hittade ändå den kortaste sökvägen till sitt mål.

Det spelar ingen roll om du är infrastrukturen för ett ledande forskningslabb eller bokningsmjukvaran för ett förortsgym. Om du har ett företag som exponerar ett API är du nu något som en AI-agent kan undersöka, i en hastighet och fullständighet som ingen mänsklig angripare har matchat. Och ingen behöver ens bestämma sig för att attackera dig.

Hastigheten är den verkliga nyheten

En mänsklig angripare väger insats mot belöning. De blir uttråkade, tiden tar slut, de bestämmer att en gymbokningsapp inte är värd besväret. Det är den kalkylen som i det tysta har skyddat de flesta mål av lågt värde från tillfälligt utnyttjande under de senaste 20 åren (såvida du inte kör WordPress).

En AI-agent gör inte den kalkylen. Givet ett mål försöker den vad API:et tekniskt sett tillåter och testar slutpunkter och parameterkombinationer i maskinhastighet tills något fungerar. Den hittade gymmets behörighetslucka på den tid det tog för Andrew att ställa en följdfråga.

Omfattningen av den hastighetsklyftan syns redan i siffrorna. Unit 42:s Global Incident Response Report för 2026(nytt fönster) visade att de snabbaste attackerna nu exfiltrerar data på 72 minuter, jämfört med 285 minuter året innan. Det är trenden medan människor fortfarande mestadels är involverade. En agent fattar beslut på millisekunder; en mänsklig analytiker svarar på minuter till timmar.

För säkerhetsteam är den ökande hastigheten den verkliga orsaken till oro, inte enskilda incidenter som hamnar i nyheterna.

Den nya attackytan: allt med ett API

Varje tjänst som exponerar ett API är ett potentiellt mål, oavsett om den ser ut som ett eller inte.

  • Prissättningsmotorer där rabatter valideras på klientsidan
  • Lagersystem där lagerstatus finns i butiksfronten i stället för i backend
  • Supportplattformar där interna fält kan nås via odokumenterade API-sökvägar
  • Prenumerationshantering som inte verifierar att anroparen äger kontot som ändras.

Inget av detta kräver att en människa letar efter det. Det kräver bara en agent med ett mål och ett API som svarar.

De mest utsatta företagen är inte de med uppenbara säkerhetshål. Det är de med affärslogiska luckor: regler som endast finns i användargränssnittet, åtgärder som API:et tekniskt sett tillåter men som gränssnittet aldrig visar, arbetsflöden uppbyggda på antagandet att ingen anropare någonsin skulle försöka använda sökvägen som hoppar över den avsedda.

Gymmets utvecklare tyckte nästan säkert inte att det var värt att skriva en behörighetskontroll för avbokningar, eftersom ingen vanlig användare, och ingen vanlig angripare, hade anledning att försöka. En agent hade inga sådana betänkligheter, och den försökte inte en gång hitta en bokning att hoppa över. Den försökte bara vara hjälpsam.

Hur företag kan förbereda sig för AI-attacker

Behandla varje API-åtgärd som en behörighetskrävande åtgärd. Identitet, behörighet och kontextuell policy, kontrollerade oberoende, vid varje anrop. Inte “användargränssnittet låter dig inte göra detta”, utan “servern verifierar att du får göra detta på denna resurs utifrån dess nuvarande tillstånd”. Gymmets system skulle ha stoppat denna specifika incident med en enda rad behörighetslogik på avbokningens slutpunkt. Detta är inte alls en ny kontroll, det är det äldsta objektet på OWASP:s lista över API-säkerhet, bruten behörighetskontroll på objektnivå, och det är fortfarande det som flest system misslyckas med.

Ge agenter en egen modell för inloggningsuppgifter. Avgränsade tokens med kort livslängd som utfärdas specifikt för agentsessioner, skilda från vanliga mänskliga sessionstokens, begränsar skaderadien även när agenten hittar en lucka som du inte förutsåg. Om Andrews agent hade haft en token avgränsad till endast hans egen bokning skulle avbokningen av någon annans bokning ha misslyckats vid lagret för inloggningsuppgifter oavsett vad API:et i övrigt tillät. Detta är viktigt eftersom du inte kan lita på agentens egen återhållsamhet. Du måste lita på vad dess inloggningsuppgifter fysiskt tillåter den att göra.

Instrumentera specifikt för att upptäcka agentbeteende. Agenttrafik har en urskiljbar form: förfrågningstider som understiger mänsklig förmåga, systematisk numrering av slutpunkter, sekventiell undersökning av parameterkombinationer, framgångsrikt utförande av åtgärder som ingen mänsklig användare någonsin har försökt genom det faktiska gränssnittet. Skapa en baslinje för den formen och larma om den i realtid.

Minska klyftan i responstid, inte bara klyftan i upptäckt. Att upptäcka en undersökning om en timme är meningslöst om undersökningen slutfördes och gick vidare på några minuter. Siffran från Unit 42 ovan, 72 minuter för de snabbaste attackerna i mänsklig takt, är redan fel referensvärde att planera mot. Automatiserad respons, inte bara automatiserade larm, är vad som överbryggar en klyfta som mäts i millisekunder. Givetvis måste du också se till att din automatiserade respons inte heller orsakar skada.

Anta att detta kommer att hända och öva på responsen. Dokumentera vem som blir uppringd, förbered kundkommunikation i förväg och kör skrivbordsövningar mot specifikt agentdrivna scenarier, inte bara traditionella handlingsplaner för dataintrång. IBM:s Cost of a Data Breach Report för 2026 uppskattade det globala genomsnittet för ett dataintrång till 4,99 miljoner dollar, där AI-aktiverade intrång i genomsnitt kostade cirka 1 miljon dollar mer. De siffrorna beskriver i allt högre grad incidenter som började på samma sätt som gymmets: ingen angripare i traditionell mening alls.

Testa dina egna API:er på samma sätt som en agent skulle göra, innan en agent gör det åt dig. Manuell penetrationstestning förutsätter en mänsklig testare med begränsad tid och en ändlig lista med saker att prova. En automatiserad motståndare mot dina egna slutpunkter, som undersöker med samma uthållighet och hastighet som en agent, kommer att lyfta fram samma luckor innan en kunds assistent råkar stöta på dem. Verktyg med öppen källkod finns nu specifikt för detta. CyberStrike(nytt fönster), till exempel, kör specialiserade agenter kopplade till OWASP WSTG och MITRE ATT&CK mot dina egna slutpunkter, inklusive en dedikerad testare för exakt den behörighetslucka på objektnivå som överraskade gymmet: Den skickar en baslinjeförfrågan, skickar attacken och flaggar bara ett fynd om det finns en mätbar, reproducerbar skillnad. Det är samma typ av kontroll som skulle ha upptäckt avbokningens slutpunkt innan en agent hittade den ute i det vilda.

Principen är förstås inte ny. Webbplatsägare som körde sina egna sårbarhetsskannrar mot WordPress-installationer under botnätseran överlevde den. Verktygen behöver bara matcha anroparens hastighet nu, inte hastigheten hos en mänsklig angripare som så småningom kanske tar tag i det.