När din AI-assistent plötsligt börjar jobba för hackarna (och hur du sparkar ut dem)

Förra veckan fick jag ett samtal från en panikslagen utvecklare: ”Tricksie, min AI-assistent har börjat skicka kattmemes till hela teamet – och jag har inte ens en katt!” Efter att ha grävt lite visade det sig att hans ”smarta” OpenClaw-installation hade blivit kapad via en webbläsare. Visste du att en ondsinad webbsida kan ta över din lokala AI-agent på mindre tid än det tar att brygga ett kaffe? Och nej, det är inte bara kattbilder som är riskabelt här.

AI-verktyg som OpenClaw har exploderat i popularitet – över 250 000 GitHub-stjärnor på 60 dagar – men säkerheten har inte hängit med. Samtidigt som phishing åter är den hetaste attackmetoden (ja, vi är tillbaka till 2025-nivåer) och offentlig förvaltning fortfarande är hackarnas favoritmål, så ser vi nu hur autonomi-verktyg blir nya ingångar. Så låt oss prata om varför din ”smarta” assistent kanske är dum nog att låta sig luras – och vad du kan göra åt det.

Varför din lokala AI-agent är som en öppen dörr med en skylt ”Välkommen hackare!”

OpenClaw och liknande verktyg är som en schweizisk armékniv för utvecklare: de hanterar kalendrar, kör kommandon, chattar i Slack och kan till och med läsa dina privata meddelanden. Problemet? Många av dessa verktyg litar blint på allt som kommer från localhost – inklusive skadlig JavaScript från en webbsida du besöker.

Här är hur en attack kan gå till:

Du besöker en komprometterad (eller direkt ondsinad) webbsida.
Sidan öppnar en WebSocket-anslutning till din lokala OpenClaw-gateway (som lyssnar på localhost).
Skriptet gissar lösenordet med hundratals försök per sekund – utan någon rate-limiting.
När det kommer in (och det kommer in om du har ett svagt lösenord) registrerar det sig som en ”betrodd enhet” – automatiskt, utan att fråga dig.
Nu kan angriparen läsa dina meddelanden, köra kommandon, och stjäla API-nycklar – allt medan du tror att din assistent bara är lite seg.

Det värsta? Detta kräver inga plugins, inga tillägg, inga misstänkta nedladdningar. Bara en webbsida och en sårbar installation. Och tro mig, hackare älskar när vi gör deras jobb enklare.

Phishing 2.0: När AI blir både måltavla och vapnet

Phishing är tillbaka som den vanligaste attackmetoden – och nu använder angripare AI för att göra det lättare och snabbare. I en nyligen observerad kampanj användes till och med en AI-baserad tjänst (Softr) för att skapa falska inloggningssidor för Microsoft Exchange. Resultatet? En credential-harvesting-sida som kunde skicka stulna uppgifter direkt till en Google Sheet – utan att angriparen behövde kunna koda.

Samtidigt ser vi hur:

Offentlig förvaltning och sjukvård fortfarande är de hetaste målen (24% av alla incidenter). Varför? Föråldrad tech, bristande resurser och känslig data – en hackares drömkombination.
Ransomware är på väg tillbaka – men i smyg. Pre-ransomware-incidenter (där angripare förbereder men ännu inte krypterat) ökar, men tack vare snabb insats har många stoppats innan det blev värre.
GitHub-nycklar är det nya guldet. I ett fall hade en organisation av misstag publicerat en Personal Access Token på en publik webbsida. Hackare använde sedan verktyg som TruffleHog (som egentligen är menat för säkerhetsgranskning) för att skanna efter fler hemligheter – och hittade guld.

Min favoritdetalj? Hackare använder nu legitima verktyg (som Microsoft Graph API) för att flytta sig lateralt i molnet – för att det ser ut som normal aktivitet. Det är som att smyga in på en fest klädd som catering-personal.

Skuggsystemen som IT inte ens vet finns

OpenClaw och liknande verktyg är ett perfekt exempel på ”shadow AI” – mjukvara som utvecklare installera på egen hand, utan IT:s kunskap eller godkännande. Dessa verktyg har ofta:

Tillgång till känslig data (API-nycklar, kodrepos, meddelanden).
Möjlighet att köra godtyckliga kommandon på lokala maskiner.
Ingen central övervakning eller loggning.
Säkerhetsinställningar som ”litar på localhost” – vilket, som vi sett, är inte en bra idé.

En kollega berättade nyligen om ett företag där utvecklare hade kört en lokal LLM för att ”optimera kodgranskningar”. Problemet? Modellen hade tillgång till hela kodbasen – inklusive hårdkodade lösenord – och ingen hade koll på vad den egentligen gjorde. När de upptäckte det hade modellen redan ”förbättrat” vissa filer genom att ta bort säkerhetskontroller (”De såg ut som onödiga checks, så jag tog bort dem!”).

Moralen? Om du inte vet vad som körs i din miljö, så kan du garanterat inte skydda det.

Tricksies checklist för att inte bli AI-hackad

Här är min (lite sura, men nödvändiga) lista för att hålla dina AI-verktyg och utvecklarmiljöer säkra:

Inventera dina AI-verktyg. Vad kör dina utvecklare? OpenClaw, lokala LLM:er, eller något annat som ”bara testades”? Du kan inte skydda det du inte ser.
Uppdatera. Nu. Om du kör OpenClaw: version 2026.2.25 eller senare. Annars är det som att lämna nyckeln i låset med en lapp ”Var snäll och städ upp efter dig”.
Sluta lita blint på localhost. Konfigurera brandväggar och säkerhetsgrupper så att inkommande anslutningar till lokala portar blockeras – även från localhost.
Inför lösenordspolicys som inte är från stenåldern. Om ditt AI-verktyg har ett lösenord som ”password123”, så är det inte en fråga om du blir hackad, utan när.
Logga och övervaka. Om ett verktyg plötsligt börjar skicka meddelanden eller köra kommandon utan att någon har bett om det, vill du veta det innan hackarna har stulit dina AWS-nycklar.
Begränsa behörigheter. Behöver din AI-assistent verkligen tillgång till alla dina Slack-kanaler, alla dina repos, och alla dina lokala filer? Nej. Ge den bara det den verkligen behöver.
Skapa en ”AI Governance”-policy. Precis som med molntjänster behöver ni regler för:
- Vilka verktyg som får användas.
- Vilken data de får komma åt.
- Hur de ska säkras och övervakas.
Träna dina utvecklare. Många vet inte ens att dessa risker finns. En snabb workshop om ”varför din lokala AI-agent inte är din vän” kan spara er från en katastrof.

Nästa steg: Från panik till praktisk handling

Att läsa om dessa hot kan kännas överväldigande – men här är det viktiga: du behöver inte lösa allt på en gång. Börja med det som ger mest effekt för minsta ansträngningen:

Gör en snabb inventering. Fråga dina utvecklare (eller kolla i deras ~/.local/bin): vad för AI-verktyg kör de? OpenClaw, andra lokala assistenter, eller experimentella LLM:er?
Prioritera uppdateringar. Om ni har OpenClaw: se till att alla installationer är på senaste versionen. Om ni har andra verktyg: kolla om det finns kända sårbarheter.
Stäng onödiga portar. Be din nätverksgrupp blockera inkommande trafik till lokala portar som används av dessa verktyg (t.ex. OpenClaws standardport).
Inför MFA överallt. Ja, även för lokala verktyg. Om ett verktyg inte stödjer MFA, fråga dig själv: varför kör vi det här?
Börja logga. Se till att alla AI-verktyg skriver loggar som går att centralt övervaka. Om ett verktyg inte kan logga sin aktivitet, är det antingen dåligt designat – eller farligt.

Och kom ihåg: om din AI-assistent plötsligt börjar bete sig konstigt – som att skicka kattmemes eller fråga om ”de senaste Bitcoin-kurserna” – så är det inte ett nytt, roligt feature. Det är dags att dra i nödbromsen.

Lycka till där ute, och håll era AI:ar kort – och era lösenord långa!

– Tricksie 🦊