Experimenterandet med AI-agenter fortsätter. Och i takt med att jag lär mig mer vill jag också använda dem till mer. I andra vågskålen ligger riskerna för att de gör fel eller faktiskt orsakar skada. Här är tre principer jag använder mig av nu för att försöka minimera riskerna till en nivå som fortfarande låter mig testa.
För mig handlar användningen av AI-agenter om att hitta tillit till dem på tre olika nivåer:
- Agenten i sig själv.
- Vad agenten tar sig för i min dator.
- Vad agenten lämnar ifrån sig när den är klar.
Agenten i sig #
Det enklaste steget – eller åtminstone det som jag känner igen sedan tidigare – handlar om tillit till programmet i sig självt: Gör det vad det utger sig för att göra och inget annat? Är det bara en AI-agent eller är det i själva verket en trojansk häst som kommer att kryptera min hårddisk i en ransomware-attack eller göra den till en del av ett botnät?
Det här hanteras genom en mix av källkritik och verktyg. Jag installerar bara program från företag eller personer jag litar på och ser till att jag laddar ner mjukvaran från rätt ställe.
Och när jag kör dem direkt i min dator, där de får tillgång till stora delar av det som finns på hårddisken, är Little Snitch med och övervakar vad de hittar på på nätet. Little Snitch är en utmärkt brandvägg för MacOS som jag använt i många år. Den håller koll på vilka servrar programmen i datorn försöker komma åt, visar tydliga varningsrutor när ett program försöker sig på något nytt och låter mig bestämma om det är okej eller inte.
Det agenten tar sig för i din dator #
Men AI-agenterna kör jag just nu inte direkt i MacOS. Det som skiljer dem från traditionell mjukvara är att de inte bara kommer att följa utvecklarnas instruktioner. Hela anledningen till hypen kring AI-agenter är ju att de får en språkmodell som “hjärna” som fattar beslut utifrån de instruktioner som användaren skriver i sina prompter.
Det innebär att den kan hitta på dumma saker även om det inte varit utvecklarnas intentioner. Den kan till exempel få för sig att skriva ett kommando som raderar hårddisken eller bli lurad av en prompt injection i en text den läser på nätet och försöka skicka mina lösenord till en server någonstans på nätet. (Bruce Schneier skrev bra om just den utmaningen i höstas, Agentic AI’s OODA Loop Problem.)
Så hur hantera det här? Just nu gör jag ett par saker:
- Agenterna, för tillfället Pi och Claude Code, installeras inte direkt i min dators operativsystem. Istället använder jag VMWare Fusion för att skapa virtuella Linux-datorer i min Mac. Den virtuella datorn är separerad från min fysiska, och kan varken läsa eller skriva till Macens operativsystem. Det innebär att risken för exempelvis en omformattering av hårddisken är begränsad till den virtuella datorn och inte den fysiska. Och inte ens då behöver det vara ett stort problem. VMware Fusion har, precis som de flesta mjukvarorna för virtualisering, en funktion som kallas för snapshots. Men den skapar jag med jämna mellanrum, och framför allt precis innan jag ska testa något som jag tror kan gå snett, det som kallas för återställningspunkter. Det tar några sekunder, och sedan kan jag resa tillbaka i tiden om något faktiskt går fel.
- Med hjälp av brandväggsregler både i den virtuella datorn och i hemmanätets router begränsar jag vad agenten kan komma åt på det lokala nätverket, för att minska risken för att den trots virtualiseringen hittar på saker med övriga datorer och prylar här hemma.
- Risken för att agenten skickar access tokens för API:er och liknande går inte riktigt att skydda sig mot. Istället handlar det om att minska konsekvenserna om/när det sker. Ett sätt är att ge agenten egna identiteter. Den har fått en egen mailadress, egna API-nyckar till de språkmodeller jag använder, eget konto på Git med access tokens som bara är giltiga i tre månader och så vidare.
Och självklart kan virtualisering användas även för att hantera den första nivån, tillit till programvaran i sig själv: Är du osäker, kör den i en simulerad dator istället för din riktiga.
En sak som jag inte testat än, men som nog är ett kommande steg, är en hybrid mellan att köra agenten direkt i MacOS och i en virtualiserad maskin. Jag har sett lösningar som ser till att agentens kommandon körs i en så kallad sandlåda, medan agenten själv finns i datorns faktiska operativsystem. Det blir ett sätt att i realtid begränsa vad agenten kan göra, men samtidigt ge den tillgång till information som bara finns på “värddatorns” hårddisk. På det här sättet kan man exempelvis ge agenten access att läsa dokument, men inte ändra i dem eller skapa nya.
Det agenten lämnar ifrån sig #
I sista steget finns tilliten till det agenten lämnar ifrån sig. För vissa av uppgifterna de får hjälpa mig med – som feedback på texterna jag skriver – handlar det om samma förhållningssätt som när jag jobbar direkt med ChatGPT, Claude eller Gemini: Att vara vaksam på hallucinationer och faktafel i det jag får tillbaka.
Det som är lurigare, särskilt för en icke-utvecklare som jag, är motsvarande hallucinationsrisk när agenten och jag jobbar med programkod. De kod-projekt som Pi och Claude Code hjälper mig med är mycket mer avancerade än att jag själv fullt ut förstår hur koden fungerar. Finns det allvarliga buggar som kommer få min dator att krascha? Har agenten valt att använda tredjeparts-bibliotek som innehåller malware eller öppnar min kod för intrång?
Bug-problematiken går än så länge, med de lite mindre projekt jag har igång, bra att hantera med hjälp av språkmodellerna själva. Den största delen av koden låter jag lite enklare modeller skriva, och sen får de mest kraftfulla, som Anthropics Opus, då och då titta igenom koden, förklara för mig hur den fungerar och komma med förslag på förbättringar. Sen blir det en ny vända med de enklare modellerna som får ta sig an förslagen innan en ny vända kod-koll. Och så vidare.
Risken för sårbarheter i tredjeparts-bibliotek hanteras delvis på samma sätt, med att jag ber Opus kolla om de bibliotek som används är okej. Men Opus och Gemini har också skrivit några kortare script som bland annat jämför de bibliotek som används i den genererade koden med kända sårbarheter i OSV.dev. I Pi har jag en skill (en “specialprompt”) som triggas automatiskt varje gång agenten vill lägga till ett nytt bibliotek och som gör säkerhetskollen innan det läggs till i min kod.
Hur gör ni andra? #
Det här är det mindset och de förhållningssätt jag landat i för tillfället. Men AI-agenterna är nya, både för mig och för alla andra. Principerna ovan ska dessutom omsättas i praktiken. Och här verkar vad som är best practices förändras i snabb takt, med nya verktyg och metoder på löpande band.
Så jag är nyfiken. Vilka luckor finns i mitt förhållningssätt på en generell nivå? Och vilka praktiska lösningar använder du?