Offentlig AI-chatbot vs. kundportal: Separera identitet och dataåtkomst säkert

En chatbot på en offentlig webbplats får svara på produktfrågor, förklara öppettider eller vägleda till rätt servicesida. Men så snart den ska visa orderstatus, avtal, fakturor eller supportärenden i kundportalen ändras inte bara innehållet. Det skapas en ny säkerhetsgräns. En autentiserad AI-chatbot måste skilja identitet, behörighet, session och konkret åtgärd tydligt från varandra.

Det viktigaste arkitekturbeslutet är därför inte: ”Vilken modell ska vi använda?” Det är: ”Vilken information och vilken åtgärd är tillåten i vilken förtroendezons-nivå?” De som besvarar den frågan före promptdesign minskar dataläckor, felaktiga kontokopplingar och oönskade åtgärder. Följande guide är en teknisk och organisatorisk vägledning, inte individuell juridisk rådgivning.

Varför offentlig och autentiserad är två olika driftlägen

I den offentliga chatten är personen till en början okänd. Systemet kan som mest känna till samtalskontexten, det valda språket och tekniskt nödvändiga sessionsdata. Svaren bör därför begränsas till godkända, allmänt tillgängliga källor. En angiven e-postadress, ett ordernummer eller ett påstående som ”Det här är mitt avtal” utgör ännu inget behörighetsbevis.

I kundportalen finns däremot en inloggad session. Men även där gäller: inloggning innebär inte automatiskt att varje resurs och varje åtgärd är tillåten. OWASP Authentication Cheat Sheet skiljer på autentisering, identitetsverifiering och sessionshantering. De aktuella NIST Digital Identity Guidelines, Revision 4 behandlar också identitetsverifiering, autentisering och federering som separata byggstenar. För webbplatsteam innebär detta: chatten får endast använda de förtroendesignaler som det omgivande systemet bevisligen tillhandahåller.

Tre zoner i stället för en allsmäktig chatbot

En robust lösning delar upp kunskap och verktyg i minst tre zoner:

• Offentlig zon: godkänt webbplatsinnehåll, allmän produktinformation, processer, kontaktvägar och förutsättningslös hjälp.
• Autentiserad zon: data och ärenden som är bundna till det inloggade kontot, en organisation, roll eller behörighet.
• Särskilt skyddad zon: känsliga ändringar, utbetalningar, avtalstecknande, nya leveransadresser, behörighetsändringar eller andra åtgärder som kräver ytterligare bekräftelse eller mänsklig granskning.

Dessa zoner bör inte bara finnas i systemprompten. De måste återspeglas i datakällor, API:er, roller, verktygsbehörigheter och kontrollmekanismer på serversidan. En prompt kan styra beteende, men är ingen åtkomstkontroll. Detsamma gäller för RAG: en sökning över offentliga och privata dokument i ett gemensamt, ofiltrerat index skapar en onödigt bred angreppsyta.

Autentisering är inte auktorisering

Förenklat besvarar autentisering: ”Vilken digital identitet är inloggad?” Auktorisering besvarar: ”Får denna identitet läsa exakt detta objekt eller utföra denna funktion?” Skillnaden suddas lätt ut i en chatt eftersom användare naturligt formulerar objektnummer: ”Visa mig faktura 4711” eller ”Ändra adressen för order 815”.

OWASP-rekommendationerna mot IDOR kräver en objektbaserad behörighetskontroll, även om identifierare är svåra att gissa. I praktiken innebär det: servern härleder det aktuella kontot från den skyddade sessionen och kontrollerar vid varje begäran om fakturan, ordern eller ärendet tillhör detta tillåtna dataområde. Språkmodellen får inte ta över ett fritt angivet kund- eller objekt-ID som förtroendepunkt.

Vad den offentliga webbplatschatten får svara på

För det offentliga området är en positivlista bättre än en lång förbudslista. Tillåtna kan till exempel vara returfrister, leveransregioner, produktegenskaper, instruktioner, allmän prislogik eller vägen till inloggningen. Inte tillåtna är individuella orderstatusar, avtalsdetaljer, personliga bokningar, interna anteckningar eller besked om ett visst konto ens existerar.

Även till synes harmlösa svar kan avslöja information. ”Det finns inget konto för den här e-postadressen” bekräftar ett kontrollförsök. Ett neutralt svar som ”Logga in i kundportalen för att hämta kontorelaterad information” håller gränsen stabil. För manipulationsförsök behövs dessutom skyddsåtgärder som beskrivs i artikeln Prompt Injection bei Website-Chatbots.

Vad den autentiserade AI-chatbotten behöver utöver det

Efter inloggningen får assistenten göra mer, men bara inom den kontext som bestämts på serversidan. Lämpliga indata är en intern sessionsreferens, den tillåtna organisationen eller klientorganisationen, roller samt en snävt definierad funktionalitet. Råa inloggningsuppgifter, lösenord, fullständiga sessionstoken eller onödiga personuppgiftsfält hör inte hemma i modellkontexten.

OWASP Authorization Cheat Sheet rekommenderar behörighetskontroller för varje konkret resurs och funktion. För verktygsanrop innebär det: det är inte modellen som avgör om en faktura är synlig. Den begär den tillåtna informationen från en tjänst; tjänsten kontrollerar session, roll, klient och objekt på nytt. Chatten får därefter endast de fält som behövs för svaret.

Att utforma data- och verktygsgränser i praktiken

Läsning och skrivning bör vara separata verktyg. Ett verktyg som ”hantera kundkonto” är för brett. Bättre är små funktioner som ”lista egna öppna beställningar”, ”läsa status för en tillåten beställning” eller ”förbereda supportärende”. Varje funktion får ett minimalt indataschema, en behörighetskontroll på serversidan, tydliga felscenarier och en begränsad utdata.

För RAG rekommenderas samma logik: offentliga källor i ett offentligt sökutrymme, kontorelaterade dokument i ett sökutrymme som filtreras baserat på klient och roll. Filter skapas på serversidan från sessionen, inte från fritt formulerade uppgifter i chatten. Ändringar i källor, roller och godkännanden hör hemma i ett dokumenterat förfarande; en mall finns i artikeln om Content Governance und Change Control.

Ta hänsyn till sessionstimeout, utloggning och delade enheter

Ett chattgränssnitt får inte ge intryck av att en behörighet gäller på obestämd tid. OWASP Session Management Cheat Sheet beskriver sessionen som kopplingen mellan autentisering, HTTP-trafik och åtkomstkontroll. Om sessionen löper ut måste nästa privata datahämtning misslyckas säkert. Ett gammalt svar i den synliga historiken får inte tolkas som en ny behörighet.

Team bör också testa utloggning, kontobyte, rolländringar och delade enheter. Privata samtalshistoriker får inte visas för nästa konto efter ett byte. Assistenten bör tydligt leda till ny inloggning om sessionen har löpt ut, utan att upprepa känsliga detaljer från den föregående sessionen. För loggning och utvärdering gäller dataminimering; artikeln om datensparsamer Chatbot-Analytics visar lämpliga händelse- och lagringsgränser.

Känsliga åtgärder kräver en egen bekräftelse

Inloggning i portalen räcker inte nödvändigtvis för varje åtgärd. Om chatten ändrar en leveransadress, bekräftar ett avtal eller utlöser en betalning bör systemet kräva en tydligt identifierbar, åtgärdsspecifik bekräftelse. OWASP Transaction Authorization Cheat Sheet skiljer på inloggning och transaktionsgodkännande och kräver kontroller på serversidan samt granskning av väsentliga transaktionsdata.

Ett säkert mönster är: chatten samlar in önskemålet, visar en begriplig sammanfattning, portalen kontrollerar den aktuella behörigheten och kräver vid behov återautentisering eller en andra faktor. Först därefter utför en tjänst på serversidan exakt den bekräftade åtgärden. Om mål, belopp eller andra väsentliga uppgifter ändras förfaller det tidigare godkännandet.

Exempel: Retur utan dataläcka

En anonym person frågar: ”Kan jag returnera min beställning?” Den offentliga chatten förklarar den allmänna returlogiken och länkar till portalen. Den frågar inte efter fullständig adress eller betalningsuppgifter. Efter inloggning kan portalchatten lista användarens egna returbara beställningar via ett läsverktyg. Om personen väljer en beställning kontrollerar servern objektbehörigheten och de gällande reglerna på nytt.

För den faktiska returen skapar ett separat åtgärdsverktyg en sammanfattning. Personen bekräftar artikeln och hämtningsalternativet i portalgränssnittet. Om kontrollen misslyckas anger chatten inga interna risksignaler, utan erbjuder ett säkert nästa steg. Om mänsklig klargörande krävs följer en kontrollerad Human Handoff med endast den nödvändiga, godkända kontexten.

Testmatris före skarpt läge

En testmatris bör inte bara testa framgångsrika flöden (happy paths). Använd minst två konton med liknande roller samt separerade data och testa följande fall:

• Anonym förfrågan om allmän information och om privata kontodata.
• Inloggat konto A läser ett eget objekt och försöker därefter använda identifieraren för ett objekt från konto B.
• Utgången session, utloggning, kontobyte och återkallad roll under en pågående chatt.
• Språkbyte mitt i processen, utan att dataområde eller behörighet ändras.
• Prompt injection i användarutdata och i hämtade dokument.
• Avbrott i ett läsverktyg, timeout och motstridiga backend-data.
• Skrivåtgärd utan bekräftelse, med ändrade data och med utgången bekräftelse.
• Överlämning till människa med minimal, begriplig samtalskontext.

Förväntade resultat hör hemma i testet i förväg: Vilket svar är offentligt tillåtet? Vilket HTTP-fel uppstår på serversidan? Vilken information får vara synlig i chatten? Vilken händelse loggas utan konfidentiellt innehåll? En planerad reducerad driftnivå (degraded mode) hjälper när identitets- eller backend-tjänster ligger nere; för detta finns en egen Incident Response- och Rollback-guide.

Checklista för en robust portalgräns

• Dokumentera offentlig, autentiserad och särskilt skyddad zon.
• Modellera autentisering, auktorisering och transaktionsgodkännande separat.
• Härled konto och klient från den säkra sessionen.
• Kontrollera objektbehörighet på serversidan vid varje läsning och skrivning.
• Separera och filtrera offentliga och privata RAG-källor tekniskt.
• Utforma verktygsbehörigheter minimalt; separera läsning och skrivning.
• Ta hänsyn till sessionstimeout, utloggning, kontobyte och rolländringar i chatten.
• Sammanfatta känsliga åtgärder begripligt och kräv riktad bekräftelse.
• Begränsa överlämning och loggning till nödvändiga data.
• Testa horisontella åtkomstförsök reproducerbart med minst två konton.

En autentiserad AI-chatbot blir inte säker bara för att den visas bakom en inloggning. Säkerhet uppstår när varje information och varje åtgärd har en verifierbar gräns. Börja därför med zonkartan och testmatrisen innan du ansluter privata datakällor eller skrivande verktyg. På så sätt förblir den offentliga chatten hjälpsam och portalchatten handlingskraftig, utan att båda förtroendezonerna blandas ihop.

Källor

• NIST SP 800-63, Revision 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet