Så använder ni AI med öppen källkod på ett säkert sätt
Öppna modeller och agenter med öppen källkod går att granska, köra i egen miljö och anpassa efter verksamheten. Med den friheten följer ett ansvar. Det är organisationen själv som avgör vad som laddas ner och som märker när något följer med som inte borde.
iSearch
Innehåll
Fördelarna med öppen källkod gäller även för AI. En öppen modell kan köras i en egen miljö. Koden går att granska och anpassa. Det arbete som en leverantör annars gör hamnar i stället hos er: att välja version, kontrollera ursprunget och följa upp när något ändras.
Agenter och tillägg från okända utvecklare
Personliga AI-agenter som körs på den egna datorn kan läsa och skriva filer, styra webbläsaren, skicka e-post och köra kommandon. När en medarbetare installerar en sådan agent på egen hand kan den få tillgång till allt som personen själv når. Franska CERT-FR slog i april 2026 fast att den typen av agenter inte bör användas på arbetsdatorer och mobiler förrän produkterna är stabila och prövade ur säkerhetssynpunkt. Fram till dess rekommenderar myndigheten isolerade testmiljöer utan känsliga uppgifter, att IT och säkerhet godkänner användningen i förväg och att systemkommandon alltid kräver mänskligt godkännande.
Agenterna blir mer användbara med tillägg, som kopplingar via MCP eller färdiga färdigheter från en marknadsplats. Beroende på hur agenten är byggd kan ett tillägg köras som betrodd kod med samma behörigheter som agenten själv. I början av 2026 gick säkerhetsforskare igenom marknadsplatsen för en populär agent med öppen källkod och hittade hundratals skadliga färdigheter. Flera hade namn som bara skilde sig med en bokstav eller två från marknadsplatsens officiella verktyg.
Felstavade namn är ett gammalt knep i öppna paketregister, och AI har gett det en ny variant. När forskare lät kodmodeller skriva programkod föreslog modellerna ibland paket som inte fanns, och samma påhittade namn återkom ofta. Den som registrerar ett sådant namn kan sedan vänta på att någon installerar det. En agent som själv installerar det modellen föreslår kan göra den risken större. Hur en agent dessutom kan luras av dolda instruktioner beskrivs i riskerna med AI-agenter.
Uppdateringar som ingen har granskat
En komponent som var säker i går kan vara skadlig i dag. I augusti 2025 publicerades skadliga versioner av ett välkänt byggverktyg i ett öppet paketregister. Versionerna låg ute i några timmar. De sökte igenom utvecklarnas datorer efter känsliga uppgifter, försökte få AI-verktyg som redan var installerade att hjälpa till och laddade upp det de hittade till offentliga kodförråd.
Samma sommar hamnade skadlig kod i en officiell version av ett tillägg för kodassistans, sedan en åtkomstnyckel i byggkedjan varit för brett avgränsad. Koden innehöll ett fel och kunde inte köras, och versionen drogs tillbaka. Båda fallen visar varför nya versioner bör granskas innan de släpps in, varför versioner låses och varför automatiska uppdateringar inte bör gå direkt till datorer med känsliga uppgifter.
Modellfiler och deras ursprung
Formatet pickle är standard för modellvikter i ett av de vanligaste ramverken för maskininlärning, och en picklefil kan köra programkod i samma ögonblick som den läses in. Under 2024 hittade forskare ett hundratal modeller med skadlig kod på en stor modellplattform. I början av 2025 upptäcktes modeller med skadlig kod som plattformens skanning inte hade flaggat. De togs bort inom ett dygn, och skanningen förbättrades. Format som bara innehåller modellens vikter, som safetensors, minskar risken.
OWASP konstaterar att publicerade modeller saknar starka garantier för var de kommer ifrån, och att en modellbeskrivning ger information men inget bevis. Ett konto kan kapas eller ett förväxlingsbart konto skapas. En modell kan också ha justerats för att bete sig annorlunda i vissa lägen, utan att det syns i vanliga tester. Samma sak gäller de mindre tilläggsfiler som anpassar en modell till en viss uppgift.
Krav på det som laddas ner
Enligt riktlinjer från 2023, som NCSC tog fram tillsammans med CISA, bör leverantörer av AI-komponenter följa samma säkerhetskrav som organisationen ställer på annan programvara. I praktiken kan det innebära en lista över godkända öppna modeller, paket och tillägg, att nya versioner granskas innan de används och att det som inte är granskat körs avskilt i en sandlåda.
En förteckning över alla komponenter, en SBOM, gör det möjligt att snabbt se var en sårbar version finns. För AI omfattar den också modeller, dataset och deras ursprung. G7:s arbetsgrupp för cybersäkerhet publicerade i maj 2026 en vägledning om vad en sådan förteckning för AI minst bör innehålla. Kontrollsummor och signaturer visar att filen är oförändrad och vem som har publicerat den. Om innehållet är säkert avgörs av granskningen. Varje komponent behöver också en ägare som följer upp den, så att någon märker när ett paket byter förvaltare eller en leveranskedjeattack blir känd.
Så fungerar det i iSearch
iSearch levereras med låsta beroenden och en SBOM, en förteckning över alla komponenter. Uppdateringarna är signerade, även för helt avskilda miljöer. Språkmodellen kan köras i er egen miljö, tillsammans med resten av kedjan. Varje kund får en egen, separat installation, och era frågor och dokument används aldrig för att träna modeller.
Läs mer om säkerheten i iSearch och om egen installation eller molntjänst, eller boka en genomgång.
Källor: OWASP, LLM03 Supply Chain (2025)CERT-FR om autonoma AI-assistenter (2026)NCSC och CISA, riktlinjer för säker AI-utveckling (2023)G7, SBOM for AI Minimum Elements (2026)Studie om påhittade paketnamn i AI-genererad kod (2024)Hugging Face om pickle och säkerhet