LLM-säkerhet är produktsäkerhet
Säkerhetsproblem i LLM-integrationer är inte teoretiska — de är välkända angreppsytor som aktivt utnyttjas. Så snart du kopplar en språkmodell till verktyg, databaser eller användardata har du öppnat nya vägar in, och de fungerar inte som de sårbarheter du är van vid.
Den goda nyheten: de flesta riskerna går att begränsa kraftigt med några grundläggande principer. Här är de vi alltid implementerar för svenska bolag.
Prompt injection — det nya SQL-injection
Prompt injection innebär att en angripare bäddar in instruktioner i innehåll som modellen läser — ett dokument, en webbsida, ett mejl — och får modellen att lyda dem i stället för dina. Om din LLM kan vidta åtgärder, kan en injection få den att läcka data eller utföra oönskade operationer.
Grundregeln: behandla allt modellen läser från externa källor som opålitlig data, aldrig som instruktioner. Separera systeminstruktioner från användarinnehåll tydligt, och låt aldrig modellutdata ensamt avgöra om en känslig åtgärd ska utföras. Kräv en kontrollerad bekräftelse för irreversibla operationer.
Dataläckage — vad skickar du egentligen till modellen?
Varje token du skickar till en extern LLM-leverantör lämnar din miljö. Skicka aldrig personnummer, betalkortsuppgifter, hälsodata eller hemligheter i prompts utan att veta exakt var datan tar vägen och hur länge den lagras. För svenska bolag är detta en GDPR-fråga, inte bara en hygienfråga.
Maskera eller filtrera känsliga fält innan de når modellen. Överväg en EU-baserad eller självhostad modell för data som inte får lämna unionen. Och dokumentera databehandlingen — du behöver kunna svara på vad som delas, med vem och varför.
Minsta möjliga behörighet
Den dyraste designmissen vi ser är att ge LLM-agenten breda behörigheter 'för att det är smidigt'. En modell som kan läsa hela databasen, skicka mejl och radera poster är en katastrof som väntar på rätt prompt.
Ge agenten exakt de verktyg och den åtkomst den behöver för sin uppgift, inte mer. Läsbehörighet är säkrare än skriv. Skriv är säkrare än radera. Och varje verktyg som kan göra något irreversibelt ska ha en spärr — en bekräftelse, en gräns eller en mänsklig grind.
Logga, övervaka och sätt gränser
Logga alla prompts, svar och verktygsanrop så att du kan utreda incidenter och upptäcka missbruk. Sätt hårda gränser på output-längd, antal verktygsanrop per session och kostnad per användare — annars kan en enda fientlig eller buggig loop dränera både budget och tålamod.
Säkerhet är inte ett engångsarbete. Modeller, attacker och ditt eget produktbeteende förändras. Behandla LLM-lagret som vilken annan produktionskomponent som helst: med övervakning, larm och regelbunden granskning.
Taggar