AGENTISKA WEBBLÄSARE PÅ JOBBET: STYRNING, BEHÖRIGHET OCH ANSVAR NÄR AI:N KLICKAR SIG FRAM
OpenAI Atlas, Microsoft Copilot Actions i Edge och Perplexity Comet kan logga in på webbplatser och klicka, fylla i och skicka formulär åt en medarbetare — med medarbetarens eget konto. Det är ett annat styrningsproblem än en internbyggd AI-agent med en admin-godkänd koppling: ingen i IT har beslutat exakt vilka sajter verktyget får besöka, för det är hela den öppna webben medarbetaren redan har tillgång till. Den här artikeln ger en praktisk checklista för behörighet, spårbarhet, godkännandegrindar och de första stegen när verktyget klickar eller skickar fel.
Vad den här artikeln är till för
Artikeln är skriven för chefer, IT-ansvariga och andra med ett styrningsansvar på en svensk arbetsplats där medarbetare använder eller överväger ett färdigt agentiskt webbläsarverktyg — inte ett internbyggt system, utan en produkt som OpenAI Atlas, Microsoft Copilot Actions i Edge eller Perplexity Comet. Texten bygger på leverantörernas egen produktdokumentation, kontrollerad 2026-08-17, samt gällande svensk och europeisk rätt. Produktfunktioner ändras snabbt: kontrollera alltid den aktuella inställningen i er egen tjänst innan ni fattar beslut.
Skillnaden mot en agent ni redan har styrning kring
Vår genomgång av AI-agentens behörigheter handlar om en agent som ansluts till namngivna system — mejl, filer, en kanal — genom en koppling en administratör har godkänt och kan begränsa till en mapp, ett konto eller en åtgärd. En agentisk webbläsare fungerar tvärtom: den öppnar sajter på den öppna webben och kan där logga in med de konton medarbetaren redan har, fylla i formulär och klicka på knappar, ungefär som medarbetaren själv skulle gjort. Vilka system den når bestäms alltså inte av en administratörs koppling, utan av vilka tjänster medarbetaren råkar vara inloggad på i webbläsaren den dagen — leverantörssystem, kundportaler, myndighetstjänster, bankkonton.
Det gör frågan om behörighet, spårbarhet och godkännande till ett delvis nytt problem, även om er organisation redan har en policy för internbyggda agenter. En policy skriven för "vår agent som läser SharePoint" täcker sällan "medarbetarens webbläsare som nu kan handla åt henne på leverantörens webbplats".
Produkterna lånar inte inloggningen på samma sätt
Det är lätt att anta att "en agentisk webbläsare" är en enhetlig kategori med samma riskprofil. Så är det inte. Utifrån leverantörernas egen dokumentation, kontrollerad 2026-08-17:
- OpenAI Atlas (agentläge) uppges inte kunna köra kod i webbläsaren, ladda ner filer, installera tillägg eller nå andra appar och filsystemet, och sägs pausa på vissa känsliga sajter som finansiella institutioner samt sakna åtkomst till sparade lösenord och autofyll. Agentläget arbetar ändå inom samma allmänna webbläsarkontext som medarbetaren normalt använder.
- Microsoft Copilot Actions i Edge for Business (begränsad förhandsvisning från 20 maj 2026) arbetar i stället i en isolerad flik utan åtkomst till medarbetarens personliga kakor, bokmärken eller sparade lösenord, och är enligt Microsoft begränsad till sajter IT uttryckligen godkänt i förväg. Den pausar för lösenord och kortnummer, och Purviews dataskyddspolicyer sägs fortsätta gälla under körningen.
- Perplexity Comet, i sin Enterprise-variant, har enligt ett partnerskap med CrowdStrike (2026) lagt till ett policylager där admin kan konfigurera vilka åtgärder agenten får utföra och få realtidsdetektion av vissa dataflöden.
Slutsatsen är inte att en produkt är "säkrast". Slutsatsen är att ni måste fråga varje leverantör konkret om agenten återanvänder medarbetarens befintliga inloggade sessioner eller arbetar i en isolerad, allowlist-styrd kontext — och verifiera svaret i produktens egen adminkonsol, inte bara i marknadsmaterialet.
Bestäm vilket konto agenten faktiskt agerar som
Innan en agentisk webbläsare släpps in i en verklig arbetsuppgift, avgör konkret: agerar den under medarbetarens vanliga, privilegierade konto — med samma åtkomst medarbetaren byggt upp under flera år — eller under en avgränsad identitet skapad för uppgiften? Ett exempel: en agent ombeds beställa kontorsmaterial hos en leverantör. Om agenten återanvänder medarbetarens vanliga inloggning kan den, beroende på produkt, hamna på fel leverantörssida, logga in med samma konto som används för större inköp, och skicka en beställning ingen hunnit se. Om produkten i stället kräver en separat, avgränsad inloggning för agentuppgifter blir felet lättare att begränsa och lättare att stänga av.
Prov ni kan göra: be IT eller leverantören visa exakt var i adminkonsolen ni ser och begränsar vilka sajter eller kontotyper agenten får arbeta mot. Finns ingen sådan begränsning, eller finns bara en allmän på/av-knapp för hela verktyget, är det ett observandum värt att skriva ner innan piloten går vidare — inte ett skäl att avbryta automatiskt, men ett skäl att sätta en snävare uppgift och en kortare pilotperiod.
Anta inte att er befintliga loggning redan täcker verktyget
Det vanligaste antagandet är att en agentisk webbläsare, precis som andra företagsverktyg, automatiskt syns i organisationens vanliga efterlevnadsloggar — Compliance API, SIEM, eDiscovery. Enligt OpenAIs egen dokumentation för ChatGPT Atlas i företagsmiljö stämmer det inte generellt: Atlas uppges inte skicka loggar till Compliance API och saknar SIEM- och eDiscovery-integration, och vissa datatyper — webbläsardata, minnen från sessioner, agentaktivitet — omfattas enligt samma dokumentation eventuellt inte av kontots vanliga regler för lagring och radering. Det är precis den typ av lucka som inte upptäcks förrän någon faktiskt behöver loggen, det vill säga under en utredning.
Prov ni kan göra redan idag: be IT hämta en enda loggpost för en agentisk webbläsaråtgärd som utfördes igår — vilken sajt, vilket klockslag, vilken åtgärd — och kontrollera om den syns i organisationens ordinarie säkerhetsloggning. Går det inte att hitta posten har ni ett spårbarhetsglapp nu, medan det går att åtgärda, i stället för mitt i en incident. Jämför sedan med vad just er produkt faktiskt uppger sig logga — Microsofts beskrivning av Copilot Actions nämner en administratörslogg för agentkörningar i Edge for Business, men kontrollera det direkt i er egen tenant snarare än att lita på det generella produktbeskrivningen, eftersom funktionen fortfarande är i begränsad förhandsvisning och kan ändras.
Leverantörens paus är inte er organisations definition av känsligt
Flera av produkterna har inbyggda pauser: OpenAI uppger att Atlas stannar upp på vissa finansiella sajter, Microsoft att Copilot Actions pausar vid lösenord och kortnummer. Det är bra som grundskydd, men det är leverantörens definition av känsligt — inte er organisations. En agent som får i uppdrag att "svara på kundens reklamation" eller "acceptera leverantörens nya villkor" utlöser normalt ingen av de inbyggda pauserna, även om båda kan vara konsekvenser ni vill att en människa ser innan de sker.
Definiera därför själva, innan piloten startar, en kort lista över åtgärder som alltid ska kräva ett uttryckligt mänskligt godkännandeklick oavsett vad produkten själv pausar för: att skicka något till en kund eller motpart, att acceptera villkor eller ett avtal, att göra en betalning eller beställning över ett belopp ni bestämmer, och att ändra behörigheter eller kontouppgifter. Provet: ge agenten en avsiktligt tvetydig instruktion, till exempel just "svara på kundens reklamation", och observera om den stannar för godkännande eller skickar direkt. Gör det innan en verklig kund är inblandad, inte första gången det händer på riktigt.
När webbläsaren klickade eller skickade fel
Vår generella första-timmen-checklista för AI-incidenter gäller även här: stoppa, dokumentera fakta i stället för antagen orsak, och bedöm om det är en personuppgiftsincident. En agentisk webbläsare har två egenheter som gör att den generella listan behöver kompletteras:
- Stäng agentsessionen direkt — logga ut den isolerade agentfliken eller stäng av agentläget för medarbetaren i adminkonsolen, inte bara kontot i allmänhet. Kontrollera samtidigt om det inloggade sessionstoken eller lösenordet som användes bör återkallas, särskilt om felet kan bero på att en manipulerad webbsida försökt styra agenten (promptinjektion) — en känd risk för den här typen av verktyg som leverantörerna själva beskriver som svår att helt eliminera.
- Räkna med att motparten är extern. Till skillnad från en agent som bara arbetar i era egna system kan en agentisk webbläsares fel synas hos en tredje part — en leverantörs orderformulär, en kundportal, en myndighetstjänst. Första timmen behöver därför inkludera bedömningen om ni behöver kontakta den externa parten, inte bara frysa era interna flöden.
Hämta därefter agentens egen körlogg om den finns (se föregående avsnitt), dokumentera i er AI-beslutslogg vad som hände och vem som fattade nästa beslut, och följ 72-timmarsbedömningen för personuppgiftsincidenter enligt IMY:s vägledning om ärendet gäller personuppgifter.
Samma ansvarsprincip som för andra AI-agenter — inte en ny lag
AI-förordningen skiljer på leverantör och tillämpare; en arbetsgivare som sätter en agentisk webbläsare i arbete är normalt tillämpare av verktyget. Tillämparens särskilda skyldigheter enligt artikel 26 — bland annat mänsklig tillsyn och sexmånaders loggbevarande — gäller uttryckligen AI-system som är klassade som högrisk, och ingen av produkterna i den här artikeln är generellt klassad som ett högriskssystem enligt AI-förordningen; en konkret klassificering beror på det faktiska användningsfallet och är inte gjord här. Skickar eller beställer verktyget något som orsakar en skada gäller samma civilrättsliga huvudregel som för andra misstag en anställd gör i tjänsten: enligt 3 kap. 1 § skadeståndslagen svarar normalt arbetsgivaren, inte den enskilda medarbetaren. Se Vem bär ansvaret när AI-agenten gör fel på jobbet? för hela genomgången av de två lagren.
En sista punkt: varken IMY eller PTS hade per 2026-08-17 publicerat någon vägledning specifikt om transparens för agentiska AI-verktyg. Det ska inte tolkas som att ingen reglering gäller — AI-förordningens generella regler och GDPR gäller redan — utan bara att det inte finns någon särskild, riktad agent-vägledning att luta sig mot ännu. Kontrollera imy.se och pts.se på nytt inför ett större beslut.
Checklista att gå igenom före en pilot
Vanliga frågor om agentiska webbläsare på jobbet
Är en agentisk webbläsare samma sak som en intern AI-agent?
Nej. En internbyggd agent kopplas normalt till namngivna system genom admin-styrda integrationer med avgränsade rättigheter. En agentisk webbläsare arbetar i stället i medarbetarens vanliga webbläsare och kan agera på hela den öppna webben under de konton medarbetaren råkar vara inloggad på, om produkten inte uttryckligen är begränsad till en godkänd lista av sajter.
Loggar alla agentiska webbläsare vad de gjort?
Nej, inte lika. Produkterna skiljer sig åt i om agentaktivitet skickas till organisationens vanliga efterlevnadsloggar (till exempel Compliance API, SIEM eller eDiscovery). Kontrollera varje produkts egen dokumentation i stället för att anta att befintlig loggning täcker den nya funktionen.
Räcker vendor-produktens inbyggda godkännandepaus?
Inte automatiskt. Leverantörernas inbyggda pauser (till exempel vid lösenord eller kortnummer) speglar leverantörens definition av känsligt, inte nödvändigtvis er organisations. Definiera egna åtgärder som alltid kräver mänskligt godkännande innan piloten startar.
Vem bär ansvaret om den agentiska webbläsaren skickar eller beställer fel?
Samma princip som för andra AI-agenter en anställd använder i tjänsten: enligt 3 kap. 1 § skadeståndslagen svarar normalt arbetsgivaren för skada som uppstår, om handlingen skedde i tjänsten. Se vår fördjupning om ansvarsfrågan för en fullständig genomgång.
Källor och vidare läsning
- OpenAI: Introducing ChatGPT Atlas (öppnas i ny flik)
- OpenAI: Continuously hardening ChatGPT Atlas against prompt injection attacks (öppnas i ny flik)
- OpenAI Help Center: ChatGPT Atlas for Enterprise (öppnas i ny flik)
- Microsoft Edge Blog: New in Edge for Business — AI for work, safe from day one, 20 maj 2026 (öppnas i ny flik)
- CrowdStrike: CrowdStrike and Perplexity Partner to Deliver Enhanced Security for Comet Enterprise (öppnas i ny flik)
- IMY: Nyheter (kontrollerad 2026-08-17, ingen agent-transparensvägledning funnen) (öppnas i ny flik)
- PTS: AI-förordningen (kontrollerad 2026-08-17) (öppnas i ny flik)
- Sveriges riksdag: Skadeståndslag (1972:207), 3 kap. och 4 kap. (öppnas i ny flik)
- AI-agentens behörigheter: skydda mejl och filer
- Vem bär ansvaret när AI-agenten gör fel på jobbet?
- AI-incident: första timmens checklista på jobbet