Informationssäkerhet

Vad en språkmodell gör

Du är van att granska en angreppsyta med gränser, och här ligger gränserna utanför modellen: vad som skickas in, vad som får komma ut, vad som loggas och vem som får göra vad. En egenskap som placeras i modellen har lämnat den ytan.

• Gå igenom lösningens säkerhetsegenskaper en i taget och se var varje egenskap bärs. Varje egenskap som landar på hur modellen uppträder är en egenskap du inte kan pröva och ingen kan visa upprätthålls.
• Se om lösningen skiljer mellan det ni själva har skrivit och den text den läser in. Den skillnaden finns inte i modellen, så den måste finnas i vad lösningen får göra med det den läst.
• Se vad lösningen gör när den inte kan svara. Fyller den ut har den producerat innehåll som ser hämtat ut, och det innehållet bär ingen källa att spåra tillbaka till.

Deterministiskt och generativt

Det som gör era övriga system pålitliga är att en enda kontroll räcker, och just den egenskapen faller bort här.

Varför den hittar på

Påhittet går inte att laga bort, eftersom det är samma räkning som ger de svar som blir rätt.

Hur du märker att svaret är fel

Ett felaktigt svar låter precis som ett riktigt, så det enda som avslöjar det är innehållet och aldrig tonen.

Varför svaret varierar

Samma fråga kan ge ett annat svar, och det är så systemet fungerar.

Vad modellen minns

Allt som ser ut som minne är text som sparats och skickas in på nytt.

Personuppgifter i prompten

Gränsen passeras mitt i arbetsdagen, utan att någon fattar ett beslut.

Instruktioner är inte garantier

Det mesta som beskrivs som en säkerhetsegenskap i ett AI-verktyg är en formulering och inte en mekanism, och de två redovisas i samma kolumn i den handling du får. Skillnaden syns inte så länge systemet uppför sig.

• Ta listan över det lösningen aldrig gör och se för varje post hur det är gjort. Är svaret att det står i instruktionen har posten flyttat sig från spärr till böjelse, och listan är kortare än den ser ut.
• Leta efter de fyra saker som faktiskt hindrar: en läsrätt som inte finns, ett verktyg som inte är inkopplat, en kontroll utanför modellen, en mottagare som inte tar emot. Finns ingen av dem bakom en utfäst begränsning bärs den av text.
• Se om någon prövat att bryta begränsningen med egna försök, och läs utfallet och inte metodbeskrivningen. En begränsning som aldrig prövats är beskriven och inte byggd.

Skugg-AI

Det här är den användning som inte finns i något system du kan fråga, och den sker med riktiga ärenden eftersom det är dem arbetet består av. Ett förbud utan ett dugligt alternativ flyttar den utom synhåll och gör den svårare att kartlägga.

• Titta i nätverkstrafiken och i de tjänster organisationen redan betalar för, i stället för att fråga vad medarbetarna använder. En fråga som bara kan besvaras med ett erkännande besvaras inte.
• Gå igenom de leverantörer ni redan har och se vilka som lagt in en språkmodell i en produkt ni köpt av andra skäl. Det du letar efter är om funktionen är påslagen och vart innehållet går, och det beskedet ska vara skriftligt.
• Se vilken godkänd väg som finns för den uppgift som i dag löses någon annanstans, och hur lång tid det tar att få tillgång till den. Är vägen längre än uppgiften tål beskriver förbudet vad som kommer att ske utanför den.

Promptinjektion

Här finns ingen signatur att känna igen och ingen gräns att härda, eftersom instruktionen och datan är samma text. Det som avgör följden är därför inte hur väl innehållet granskas utan vad systemet får göra utan en människas bekräftande handling.

• Se var i flödena lösningen läser text ni inte skrivit själva, alltså inkomna handlingar, e-post, webbsidor och filer i en mapp, och håll ritningen mot en verklig körning. Varje textkälla som fanns i körningen men inte i ritningen är en väg in ingen kände till.
• Gå igenom förteckningen över åtgärder systemet kan utföra och avgör för var och en om den kan utlösas av innehåll i ett dokument. Det du letar efter är de åtgärder som når utanför lösningen, alltså att skicka, att skriva och att hämta något nytt.
• Se om det finns fall där en injicerad instruktion faktiskt följdes, och läs antalet och inte om andelen var låg. En enda träff placerar frågan hos vad systemet får göra och inte hos hur väl det läser.
• Skilj ut fallet där instruktionen kom från en part i ett ärende. Att en sökande har kunnat påverka handläggningen av sitt eget ärende är något annat än ett tekniskt missöde, och det är den händelsen som ska gå att avgränsa i efterhand.

Behörigheter som följer datan

Det du granskar här är inte lösningen utan er egen behörighetsmodell, och den har hållit därför att ingen letat i den. En sökande lösning letar i allt den får läsa, och den gör det i användarens ställe.

• Se om filtreringen ligger före sökningen eller efter. Ett svar om att modellen instrueras att inte visa vissa uppgifter är ett svar om att filtret inte finns.
• Titta i det hämtade underlaget och inte i svaret. Ett svar som ser städat ut kan vila på underlag användaren inte fick se, och det är underlaget som avgör vad som röjdes.
• Gå igenom de källor som gjorts sökbara och se vilka som har en granskad åtkomst. Öppna mappar, delade kataloger och gamla utredningar ligger stilla så länge tillgång kräver att någon vet var hon ska klicka.
• Se om loggen bär vilken behörighetskontroll som gällde vid ett anrop. Utan den uppgiften går en händelse inte att avgränsa, och då är omfattningen det värsta tänkbara.

När läsrätt blir hämtning

Det du granskar här är inte en slarvig behörighetsmodell och inte ett delat tjänstekonto. Det är vad en korrekt läsrätt blir när den som har den kan fråga i stället för att öppna det hon känner till.

• Gå igenom vad en person med den bredaste läsrätten i källan kan få fram genom att ställa en öppen fråga, och skriv ner om det är acceptabelt. Där svaret är nej är källan en hämtningsyta ni inte har beslutat om.
• Se om sökningen kan begränsas till det ärende användaren arbetar i, eller om standarden är att hämta ur allt hon får läsa. Det andra är ett annat slags tillgång, också när identiteten är hennes.
• Titta på spåret efter frågan: bär det frågan, de poster som hämtades, och vilken läsrätt som gällde. Utan det går en händelse inte att pröva mot sekretessen, eftersom ingenting i den ser ut som ett intrång.
• Se om lösningen kan sammanställa uppgifter ur flera poster till ett svar som ingen av posterna visade ensam. Den sammanställningen är en ny uppgift, och läsrätten sattes inte för den.

Agentens behörigheter

En delad teknisk identitet gör att din behörighetsmodell finns kvar och gäller men aldrig prövas, eftersom det inte är användaren som ringer. Det är också skälet till att händelsen inte lämnar något du kan känna igen som ett intrång.

• Se vilken identitet källsystemet möter vid ett anrop: användarens, eller ett konto lösningen bär. Är det det andra vet ni efteråt att något hämtades men inte av vem.
• Jämför vad agenten får läsa med vad den smalaste användaren får läsa. Skillnaden är vad hon kan nå genom att formulera en fråga, och den vägen kräver inget verktyg och ingen förmåga hon inte redan har.
• Se vilka åtgärder agenten kan utföra och håll dem mot vad användaren själv får utföra. En åtgärd hon inte får göra men kan utlösa är en behörighet som flyttats utan att någon beslutat om det.

Vad MCP kräver av era system

Om ett källsystem går att koppla in avgörs av hur den som ringer styrker vem hon är, och det avgörs sent, när arkitekturen är ritad och pilotens användningsfall redan utlovade. Det som då erbjuds som lösning är det du kom för att hindra.

• Se vilka sätt att styrka identitet inkopplingen stöder, och om standardiserad delegerad inloggning finns bland dem. Stöds den inte är inkopplingen blockerad och inte fördröjd, och beskedet brukar komma i form av ett förslag om en delad nyckel.
• Se var en delad nyckel eller ett tjänstekonto redan används i det som är byggt, och vilka källor det når. Varje sådan koppling är en plats där identiteten togs bort ur anropet.
• Se hur ett bevis om vem som ringer förfaller och förnyas. Ett bevis utan tidsgräns är en nyckel med ett annat namn.

Integration mot verksamhetssystem

Det som går fel här upptäcks i ett annat system, av en annan förvaltning, och felsökningen börjar därför i fel ände. Att ta tillbaka en omgång felaktiga poster kan dessutom kräva ett ingrepp per post.

• Följ en skrivning från lösningen in i verksamhetssystemet och se vad den mottagande förvaltningens spår visar. Visar det ett konto och ingenting om vad som skrev kommer felsökningen att börja hos dem och stanna där.
• Se hur en hel omgång ändringar tas tillbaka, och läs svaret som en tid och ett antal ingrepp. Ett system byggt för en människa som skriver en post i taget har sällan en väg tillbaka för tusen.
• Se om det finns ett tak för hur många poster lösningen får skriva innan någon läser utfallet. Utan ett tak är skillnaden mellan ett fel och tusen fel bara hur länge det pågick.

När agenten ska stoppas

Svaret du oftast får är att en människa godkänner, och det svaret är svagt av mekaniska skäl och inte av slarv. Den som trycker ser agentens sammanfattning av sitt eget arbete, alltså samma parts beskrivning av det som ska prövas.

• Räkna hur många godkännanden ett vanligt uppdrag producerar. Ett stort tal betyder att godkännandet är en vana, och en vana är inte en spärr.
• Se vad den som godkänner har framför sig: det underlag åtgärden vilar på, eller agentens sammanfattning av det. Är det det andra flyttar godkännandet ansvaret till henne utan att ge henne något att bedöma med.
• Ta de åtgärder ni beskrivit som skyddade och se om rättigheten saknas i det system som utför dem. Ett konto utan publiceringsrätt kan inte publicera, och det är den sortens svar du letar efter.

Vad som måste loggas

En lösning kan visa att en anteckning är orörd utan att kunna visa vad som stod i svaret, och de två beskrivs med samma ord i den handling du får. Vilket av dem som är byggt avgörs av ett val någon gjorde av kostnadsskäl.

• Läs ett verkligt loggutdrag för ett enskilt ärende fält för fält och avgör om det räcker för att köra om svaret: personen, tidpunkten, hela inmatningen, det hämtade underlaget, versionerna av modell och instruktion, och det levererade svaret. Att loggning finns är inte det du granskar.
• Se vad som händer när skrivningen av loggposten misslyckas. Lämnas svaret ändå ut är åtgärden ospårad, och det utfallet upprepas tyst i drift eftersom ingenting annat avviker.
• Se vilka som kan ändra eller tömma loggen, och ta med leverantörens personal i den frågan. En logg som kan ändras av den som granskas är ett underlag och inte ett spår.

Spårbarhet och ansvar

Spåret visar en handling och inte en bedömning, och ett godkännande som lämnats på systemets egen sammanfattning ser i spåret ut precis som ett som lämnats efter en genomgång av akten. Det är den skillnaden din utredning kommer att behöva.

• Ta ett godkännande ur spåret och se om det går att avgöra vad personen hade framför sig när hon lämnade det. Sparas inte underlaget tillsammans med godkännandet visar spåret att någon tryckte och ingenting mer.
• Se om spåret pekar på en person eller på ett konto, och om kontot delas. Ett delat konto gör att en åtgärd finns men att ingen bär den.
• Läs hur ansvaret är beskrivet för ett namngivet användningsfall. Är det fördelat mellan verktyget och verksamheten är det ingens, eftersom ett verktyg inte kan bära ansvar.

Skuggagenter

En koppling som en medarbetare byggt bär hennes behörighet, och den gränsen var satt för vad en människa hinner på en dag. Era spår visar en läsning gjord av henne och skiljer inte ett program från en handläggare.

• Titta efter läsmönster som inte kan komma från en människa: samma anrop med jämna mellanrum, eller volymer en arbetsdag inte rymmer. Det är den signal som finns, eftersom kontot i övrigt ser ut som ett vanligt konto.
• Gå igenom var det finns personliga nycklar och tokens mot era källsystem, och vilka som skapats av någon annan än den som förvaltar systemet. Varje sådan är en koppling som saknas i er bild av vilka system som talar med varandra.
• Se vad som händer med kopplingarna den dag den som byggde dem slutar. Upphör de mitt i något andra räknat med blir beroendet synligt först då, och en förändring i ett källsystem kan bryta ett arbetsflöde ingen känner till.