AI-agenter behöver säkerhetsbälte: fem kontroller innan de får använda riktiga konton

När en AI-agent kan läsa webbsidor, köra kod, klicka i ett affärssystem och använda redan inloggade konton är frågan inte längre “kan den göra jobbet?”. Frågan är: vad hindrar den från att göra fel jobb med rätt behörighet?

Den senaste veckans signaler från Perplexity, OpenAI, Claude, Manus och Google pekar åt samma håll. Seriösa AI-verktyg byggs nu med säkerhetsbälten: isolerade miljöer, kortlivade behörigheter, skydd mot promptinjektion, godkännandesteg och loggar. Det är inte bara teknik för stora IT-avdelningar. Det är en praktisk inköps- och införandefråga för alla organisationer som låter AI arbeta nära riktiga konton.

Fem säkerhetsbegrepp som beslutsfattare behöver kunna

Du behöver inte bli säkerhetsarkitekt. Men du behöver kunna ställa bättre frågor än “är verktyget säkert?”. Börja här:

• Sandbox: en avgränsad körmiljö där agenten får arbeta utan att automatiskt få samma frihet som användarens vanliga dator eller konto.
• Kopplingskontroll: regler för vilka tjänster agenten får ansluta till, vilken data den får läsa och vem som får slå på kopplingen.
• Tillfälliga behörigheter: åtkomst som gäller för just den uppgiften och försvinner när arbetet är klart, i stället för eviga API-nycklar eller delade lösenord.
• Promptinjektionsskydd: filter och rutiner som stoppar externa webbsidor, dokument eller mejl från att lura agenten att ignorera instruktioner.
• Spårbar logg: en lista över vad agenten försökte göra, vilka system den rörde och var en människa godkände eller stoppade åtgärden.

Det här är skillnaden mellan en demo och ett arbetsflöde som tål vardagen.

Vad Perplexity och OpenAI visar med sina isolerade miljöer

Perplexity beskriver hur Computer kör varje uppgift i en Firecracker microVM, med egen Linux-kärna, isolerat filsystem, separat nätverk, kortlivade proxy-tokens och säkert stopp när misstänkt innehåll upptäcks. Det viktiga för en icke-specialist är inte namnet Firecracker. Det viktiga är principen: agenten ska inte arbeta direkt i “hela företaget”, utan i en begränsad miljö där åtkomst kan stängas av.

Källa: Perplexity — How We Built Security Into Computer

OpenAI:s Windows-genomgång för Codex visar samma sak från ett annat håll. Codex behövde en särskild isolerad Windows-miljö eftersom agenten annars kör kommandon med användarens egna rättigheter. OpenAI beskriver separata Windows-användare, filsystemsregler, brandväggsregler och ett tydligt val mellan bekvämlighet och risk.

Källa: OpenAI — Building a safe, effective sandbox to enable Codex on Windows

Översatt till vardagen: om en agent ska hjälpa till med filer, kod, ekonomiexporter eller kunddata räcker det inte att den “verkar försiktig”. Den behöver tekniska räcken och en mänsklig process runt dem.

Webbläsaragenter gör konto- och sessionsfrågan akut

Manus Preferred Browser visar varför webbläsarautomation snabbt blir känslig. Poängen med funktionen är att agenten kan använda en redan auktoriserad Chrome-miljö med rätt inloggningar, tillägg, nätverksåtkomst och interna portaler. Det gör arbetet smidigare, men det gör också browsern till en del av säkerhetsarkitekturen.

Källa: Manus — Introducing Preferred Browser

Google beskriver samtidigt Gemini i Chrome och Auto Browse på Android, där agenten kan hjälpa till med uppgifter som bokningar och vardagsärenden men ska be om bekräftelse före känsliga åtgärder som köp eller publicering. Den detaljen är central: AI kan förbereda handlingen, men konsekvensen ska godkännas.

Källa: Google — Gemini in Chrome with auto browse comes to Android

Claude-publiceringen om dator- och webbläsaranvändning visar en mer teknisk men nyttig påminnelse: även något så konkret som skärmbildsupplösning och koordinatskalning påverkar om agenten klickar rätt. När agenten får ett gränssnitt att använda blir “den förstod nog” inte en säkerhetsstrategi.

Källa: Claude — Best practices for computer and browser use with Claude

En praktisk checklista innan agenten får riktiga konton

Använd frågorna nedan innan ni kopplar en AI-agent till e-post, ekonomisystem, CRM, elevplattform, webbläsare eller interna filer.

1. Vilket konto använder agenten?

Undvik privata huvudkonton, delade lösenord och “bara låna min inloggning”. Skapa hellre ett avgränsat konto eller en tydlig auktoriserad session med minsta möjliga behörighet.

Bra första test: låt agenten läsa testdata eller en kopia innan den får åtkomst till ett produktionskonto.

2. Vilken data får agenten läsa?

Skriv ned datakällorna: mappar, projekt, kundlistor, elevinformation, offerter, fakturor, supportärenden. Om listan känns för känslig för att skriva ned är den för känslig för att koppla på slentrian.

Bra första test: börja med en källa, inte “hela Google Drive”.

3. Vad får agenten ändra?

Dela upp åtgärder i tre nivåer:

• Förbereda: skapa utkast, sammanfatta, föreslå nästa steg.
• Ändra internt: uppdatera status, skapa en intern notis, lägga till en tagg.
• Påverka externt: skicka mejl, göra köp, publicera, ändra kund- eller ekonomidata.

Agenten kan ofta få göra nivå ett tidigt. Nivå två kräver tydlig logg. Nivå tre bör ha mänskligt godkännande tills ni har mätt felrisk och återställning.

4. Var stoppas promptinjektion?

Om agenten läser webbsidor, PDF:er, mejl eller kundtext kan den möta instruktioner som försöker styra den. Fråga leverantören hur sådant upptäcks och vad som händer när något ser misstänkt ut.

Bra första test: kör ett scenario där en webbsida innehåller tydliga “ignorera tidigare instruktioner”-fraser och se om agenten stannar, varnar eller fortsätter.

5. Var finns loggen och rollback-planen?

Ni behöver kunna svara på tre frågor efteråt:

• Vad försökte agenten göra?
• Vilken människa godkände åtgärden?
• Hur återställer vi om resultatet blev fel?

Om svaret är “vi får leta i chatthistoriken” är arbetsflödet inte redo för känsliga uppgifter.

Börja med ett arbetsflöde där risken syns

Välj inte den mest imponerande användningen först. Välj ett återkommande arbetsflöde där det är tydligt vad agenten läser, vad den föreslår och vem som godkänner resultatet.

Bra startpunkter:

• Ett utkast till fakturapåminnelse som ekonomiansvarig godkänner
• En sammanfattning av supportärenden där ingen kund får svar automatiskt
• En lista över saknade dokument inför en introduktion
• En intern uppdatering från en projektmapp till ett veckomöte
• En webbläsarbaserad kontroll som bara markerar avvikelser, inte ändrar data

Det här passar i Tankesmide eller Verktygssmide: kartlägg konton, datakällor, godkännanden och loggning innan automationen får mer frihet. Om det låter som ert nästa steg kan Hammer hjälpa till att bygga en enkel agentpolicy och ett första säkert pilotflöde.