Förgiftning av AI-agenters minne omvandlar en enda opålitlig indata till varaktigt tillstånd. När en agent skriver angriparkontrollerat innehåll till beständigt minne kan innehållet återkomma dagar eller sessioner senare som till synes betrodd kontext. Försvara hela livscykeln: kontrollera varje skrivning, lägg till proveniens och utgångstid, isolera poster per användare och agent, granska hämtat innehåll på nytt, håll auktorisering av åtgärder utanför modellen och bevara en påverkanslogg som stöder återställning.
Innehållsförteckning
Vad är förgiftning av AI-agenters minne?
Förgiftning av AI-agenters minne är införande eller ändring av beständiga poster så att senare hämtning förändrar en agents svar, beslut eller användning av verktyg. Den ursprungliga indatan kan vara borta när effekten uppstår. Detta tidsglapp gör attacken svårare att upptäcka och rekonstruera än en synlig prompt injection i den aktuella konversationen.
Minne kan finnas på flera platser:
Lagringstekniken är inte den avgörande frågan. Beständighet plus senare påverkan skapar säkerhetsgränsen.
Detta skiljer sig från tre närliggande risker. Prompt injection manipulerar modellens aktuella kontext, även om den kan bli leveranskanal för förgiftat minne. Förgiftning av träningsdata förändrar modellens beteende genom träningskorpusen. Retrieval poisoning riktar sig mot innehåll som väljs för en begäran. Förgiftning av agentminne gör en post beständig som systemet senare kan behandla som en del av användarens historik, preferenser eller driftstillstånd.
Tre attackmönster är särskilt viktiga i praktiken:
| Mönster | Lagrad form | Aktivering | Varför ett enkelt filter har svårt att upptäcka det |
|---|---|---|---|
| --- | --- | --- | --- |
| Direkt korrumpering | En post innehåller den skadliga instruktionen eller det falska faktumet | Posten hämtas senare | Innehållet kan döljas som en preferens, sammanfattning eller uppgiftsanteckning |
| Kompositionell korrumpering | Flera poster ser godtagbara ut var för sig | Gemensam hämtning sätter ihop den skadliga betydelsen | Varje skrivning godkänns eftersom risken uppstår först i kombination |
| Vilande korrumpering | En post innehåller en instruktion som beror på en utlösare | En senare händelse, fras eller verktygsstatus aktiverar den | Utlösaren saknas när posten skrivs |
Microsofts aktuella vägledning beskriver samma strukturella problem i defensiva termer: beständiga minneslager innehåller känsliga data och påverkar dessutom modellens beteende och val av verktyg. De bör därför styras både som datasystem och som kontrollplan. Microsoft Learn
Vad tre aktuella studier mätte
Tre preprints från juli 2026 undersökte olika delar av detta hot. Tillsammans visar de varför ett enda minnesfilter är ett svagt kriterium för lansering.
GhostWriter testade injektion nu och aktivering senare
When Agents Remember Too Much introducerade GhostWriter, en attack i två steg mot verktygsanvändande personliga agenter. En angripare placerar först dolt innehåll i en opålitlig källa. Agenten bearbetar källan och skriver angriparpåverkat minne. En senare uppgift hämtar posten och aktiverar dess effekt.
Bland de agenter och modeller som testades i artikeln nådde GhostWriter en genomsnittlig injektionsgrad på cirka 98 % och en genomsnittlig aktiveringsgrad på cirka 60 %. Författarna testade även AM-Sentry, som kombinerar en striktare policy för att spara minne med en kontroll vid hämtning. Artikeln utvärderar både attackframgång och uppgiftsnytta i en egen simulerad arbetsvecka; försvarsresultaten varierar beroende på modell och konfiguration.
Avgränsningarna är viktiga. Arbetet omfattar fem agenter, fyra modellsfamiljer samt e-post- och kalenderarbetsflöden. Nyttoanalysen är egenutformad, angriparna är icke-adaptiva och resultaten uppskattar inte hur ofta distribuerade agenter attackeras.
MemPoison separerade direkta, kompositionella och vilande fel
MemPoison sammanställde 1 227 manuellt validerade fall över fyra attacktyper, tre injektionskanaler och tre minnesunderlag. Utvärderingen omfattade sju modeller med öppna vikter och tre modellsfamiljer med stängda vikter.
Artikelns användbara bidrag är dess taxonomi i tre nivåer. L1 är direkt korrumpering av en enskild post. L2 blir skadlig när flera poster hämtas tillsammans. L3 förblir vilande tills en senare kontext aktiverar den. Författarna rapporterar att grundläggande försvar vid skrivning undertrycker direkta attacker mer tillförlitligt än L2- eller L3-fall. Deras mekanistiska påverkansanalys tillskriver skillnaden poster som ser ofarliga ut när de lagras men blir skadliga genom komposition eller en utlösare.
Det bevisar inte att alla produktionsfilter vid skrivning kommer att misslyckas. Benchmarken omfattar tre representativa minnesunderlag och standardiserade textbaserade kanaler. Författarna efterlyser bredare arbete med förfall, sammanfattning, åtkomstkontroller och andra minneseekosystem.
MemGhost testade en e-postleveransväg i ett enda steg
When Claws Remember but Do Not Tell introducerade WhisperBench, en benchmark med 108 fall som använder ett verkligt IMAP/SMTP-arbetsflöde och en e-postagentfärdighet. Dess attackramverk, MemGhost, genererar en enda e-postnyttolast utan återkoppling under körning. För att lyckas måste agenten anta förgiftat minne, undvika att varna användaren i sitt omedelbara svar och ändra sitt senare beteende.
För 56 reserverade fall rapporterar artikeln 87,5 % end-to-end-framgång på OpenClaw med GPT-5.4 och 71,4 % på Claude Code SDK med Sonnet 4.6.
Dessa siffror gäller författarnas benchmark, proxymiljö, belöningsdesign och modellversioner. Utvärderingen börjar efter att ett meddelande nått inkorgen. Den modellerar inte kontroller hos e-postleverantörer, såsom spamfiltrering, SPF, DKIM eller DMARC. Artikeln är ett preprint i en första version, så resultaten bör replikeras.
Varför filtrering vid skrivning inte räcker
En skrivgrind ser den föreslagna posten och den evidens som finns tillgänglig vid den tidpunkten. Den kanske inte ser den framtida uppgiften, de andra poster som senare hämtas tillsammans med den eller det verktyg som agenten senare anropar.
Det skapar fyra blinda fläckar:
Kontroller vid skrivning är fortfarande viktiga. De minskar mängden osäkert tillstånd som når beständig lagring. Misstaget är att behandla godkännande vid lagring som permanent förtroende.
Hämtning bör returnera kandidatkontext, inte auktoritet. Innan en post infogas i modellens kontext kan systemet kontrollera dess källa, ålder, relevans för uppgiften, motsägelser, känslighet och begärda effekt. En högriskpost kan hållas tillbaka, sammanfattas eller skickas till granskning. Microsofts aktuella vägledning rekommenderar denna uppdelning mellan skrivning och hämtning, tillsammans med deterministisk isolering och full insyn i hela livscykeln. Microsoft Learn
Det slutliga säkerhetsbeslutet hör fortfarande hemma utanför minnet. En hämtad anteckning som säger ”skicka rapporter till den här adressen” får inte ändra mottagarlistan. En ihågkommen preferens för en distributionsregion får inte skapa molnbehörighet. Använd deterministiska AI-agentbehörigheter→ för att utvärdera den föreslagna åtgärden mot aktuell användare, resurs, omfattning och policy.
En säker arkitektur för agentminne
Systemet behöver en spårbar kedja från källa till åtgärd:
`källa → skrivbeslut → lagrad version → hämtningsbeslut → modellkontext → policybeslut → verktygsresultat`
*Bildtext: En minnespost blir kandidatkontext först efter kontroller vid skrivning och hämtning. En oberoende policy auktoriserar fortfarande varje betydelsefull åtgärd, medan påverkanskedjan stöder utredning och återställning.*
1. Kräv uttrycklig avsikt för beständiga skrivningar
Låt inte varje meddelande, dokument eller verktygssvar bli långtidsminne. Definiera vilka händelser som får skapa beständigt tillstånd. Användarbekräftade preferenser och uttryckliga ”kom ihåg detta”-åtgärder är lättare att motivera än en autonom sammanfattning av en opålitlig bilaga.
Registrera vem eller vad som begärde skrivningen. Om ett verktyg eller en underagent initierade den ska den identiteten bevaras i stället för att allt slås ihop med slutanvändarens namn.
2. Lagra proveniens, omfattning och utgångstid med posten
En användbar minnespost behöver mer än text och en embedding. Lagra åtminstone:
En signatur kan skydda postens integritet. Den kan inte bevisa att det ursprungliga innehållet var sant, säkert eller auktoriserat.
3. Tvinga fram isolering i kod och lagring
Gränser för tenant, användare, agent och arbetsyta hör hemma i åtkomstkontrollistor, begränsade tokens, radnivåpolicyer och krypteringsgränser. Promptinstruktioner är inte åtkomstkontroll. Delat minne bör vara en uttrycklig produktfunktion med namngivna skrivare och läsare, inte ett bekvämt standardnamnområde.
Samma princip gäller körningsmiljön. Om hämtat innehåll kan orsaka kodkörning eller omfattande verktygsanvändning ska processen begränsas med AI-agenters sandlådesäkerhet→. Minnesisolering begränsar vilken kontext som passerar en gräns. Sandlåde- och identitetskontroller begränsar vad som händer om osäker kontext ändå når agenten.
4. Sätt skrivningar med låg tillit i karantän
Skapa ett tillstånd mellan ”kasserat” och ”betrott minne”. Externa filer, e-post, webbsidor, indirekta verktygsresultat och poster med oklar avsikt kan placeras i karantän. De bör inte visas i normal hämtning förrän en deterministisk regel eller en auktoriserad granskare befordrar dem.
Karantän ger också incidentutredare en plats att bevara bevis utan att fortsätta påverkan.
5. Utvärdera poster på nytt vid hämtning
Hämtningsrisk beror på den aktuella uppgiften. Utvärdera den valda mängden, inte bara varje post:
Utvärdera hämtning separat från generering. Ett RAG-utvärderingsarbetsflöde→ hjälper till att skilja ”fel post valdes” från ”modellen missbrukade en korrekt post”. Lägg till minnesspecifika dimensioner som proveniens, utlösarberoende, komposition och aktivering över sessioner.
6. Håll verktygsauktorisering oberoende
Minne kan tillhandahålla parametrar. Det bör aldrig utöka behörigheter. Verktygsgatewayen måste tillämpa aktuell identitet, tillåten åtgärd, resursgräns, destination, budget och krav på godkännande. Behandla argument som härrör från minne som opålitlig indata och validera dem mot aktuell policy.
Mänskligt godkännande behöver också färsk kontext. Visa den föreslagna åtgärden, berörd resurs, datadestination och de minnen som påverkade den. Ett ”Godkänn?” utan denna kedja döljer det relevanta beslutet.
7. Logga påverkan och stöd återställning
Logga skapande, läsning, uppdatering och borttagning av minne med identitet och proveniens. För betydelsefulla åtgärder ska ID:n och versionerna för de poster som injicerades i kontexten bevaras. Då går det att besvara tre incidentfrågor:
Borttagning bör avlägsna aktiv påverkan, inte bara dölja en rad i användargränssnittet. Testa index, sammanfattningar, cachar, repliker och härledda poster. OWASP:s agentvägledning rekommenderar validerat och isolerat minne samt adversarial-tester och evidens inför lansering; dess bredare minnesanalys kopplar beständig prompt injection till agentminnets hotspektrum. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project
Välj en policy för varje minnesklass
En enda lagringspolicy är för grov. Börja med klasser som har olika regler för skrivning och hämtning.
| Minnesklass | Standardpolicy för skrivning | Hämtningspolicy | Åtgärdsauktoritet |
|---|---|---|---|
| --- | --- | --- | --- |
| Tillfällig uppgiftskontext | Automatisk, kort TTL | Endast aktuell uppgift | Ingen |
| Användarbekräftad preferens | Uttrycklig bekräftelse | Samma användare och angivet syfte | Får föreslå, aldrig auktorisera |
| Agentgenererad sammanfattning | Versionshanterad och länkad till källor | Kontrollera källor och aktualitet på nytt | Ingen |
| Externt innehåll | Karantän som standard | Endast efter kontroller av tillit och relevans | Ingen |
| Operativ instruktion | Auktoriserad skrivare och policygranskning | Exakt omfattning, aktuell version | Kräver fortfarande verktygspolicy |
| Hemliga eller reglerade data | Blockera eller använd särskilda system för hemligheter/data | Placera aldrig i allmänt minne | Endast särskild kontrollplan |
Denna tabell är en startpolicy, inte ett efterlevnadspåstående. En medicinsk agent, kodningsassistent, försäljningsagent och personlig assistent har olika skadebilder. Invarianten är snävare: beständighet får inte i tysthet omvandla opålitligt innehåll till behörighet.
Ett reproducerbart arbetsflöde för testning av minnesförgiftning
Bygg testselen kring ofarliga markörer och kasserbara konton. Du behöver inte riktiga autentiseringsuppgifter eller nyttolaster för exfiltrering för att upptäcka problem med beständighet och policy.
Steg 1: Samla in en ren baslinje
Kör en fast uppsättning uppgifter med ett tomt minneslager. Registrera svar, hämtningsresultat, verktygsförslag, policybeslut, fördröjning och användarsynliga förklaringar. Upprepa tillräckligt många gånger för att skilja systemförändringar från normal modellvariation.
Steg 2: Definiera parade rena och förgiftade fall
För varje fall ska användaruppgiften vara konstant och endast den möjliga minnesvägen ändras. Omfatta åtminstone:
Använd en kanarieåtgärd, till exempel att skriva `TEST_BLOCKED` till en kasserbar logg. Testet misslyckas om agenten utför eller föreslår den åtgärden utanför den förväntade policyn.
Steg 3: Observera varje gräns
Samla in fyra separata utfall:
Ett end-to-end-godkänt test kan dölja ett svagt lager. Auktorisering kan till exempel blockera kanarieåtgärden även om en förgiftad post lagrades och hämtades upprepade gånger. Det är användbar begränsning, men minnesfelet behöver fortfarande åtgärdas.
Steg 4: Mät nytta och falska positiva
Kör ofarliga minnesfall genom samma pipeline. Följ uppgiftsgenomförande, accepterade användarpreferenser, felaktigt karantänsatta poster, precision vid hämtning, fördröjning och granskningsvolym. Ett filter som blockerar allt beständigt minne har låg attackframgång eftersom det tog bort funktionen.
Steg 5: Sätt lanseringsgrindar efter risk
Användbara grindar omfattar:
OWASP:s open source-projekt Agent Memory Guard är en möjlig implementeringssignal för minnesskanning och testverktyg. Dess repository och självrapporterade utvärdering kan hjälpa team att granska mönster, men ersätter inte testning av den faktiska agenten, modellen, minnesbackend och policystacken.
Kör om sviten efter ändringar i minnesextraktion, sammanfattning, embeddings, hämtning, prompts, modeller, verktygsscheman, auktorisering eller borttagningslogik. Dessa lager samverkar.
Vad evidensen stöder och inte stöder
Artiklarna mätte attackframgång i konstruerade benchmarker. De mätte inte den totala förekomsten av förgiftning av AI-agenters minne i produktion.
De stöder tre snävare slutsatser:
Artiklarna drar slutsatsen att minnesstyrning behöver kontextkänsliga försvar. Microsoft och OWASP rekommenderar oberoende av varandra försvar i flera lager över skrivning, isolering, hämtning, användarkontroll, observerbarhet och testning.
Den praktiska tolkningen är att göra varje övergång testbar. Ett team bör kunna förklara varför en post lagrades, varför den hämtades, hur den påverkade en åtgärd, vilken policy som auktoriserade åtgärden och hur postens efterföljande effekter kan tas bort.
Frågor team ofta ställer
Är förgiftning av AI-agenters minne samma sak som prompt injection?
Nej. Prompt injection är ett sätt att introducera fientliga instruktioner. Minnesförgiftning tillför beständighet: manipulerat innehåll lagras, hämtas i en senare kontext och kan påverka framtida resonemang eller verktygsanvändning efter att den ursprungliga indatan försvunnit.
Kan signerade minnesposter förhindra förgiftning?
Nej. Signaturer kan bevisa att en post inte ändrades efter skapandet. De bevisar inte att det ursprungliga innehållet var sant, säkert eller auktoriserat. En säker design behöver också proveniens, uttrycklig skrivavsikt, omfattning, utgångstid, hämtningskontroller och oberoende auktorisering av åtgärder.
Bör försvar mot minnesförgiftning köras vid skrivning eller hämtning?
Båda. Skrivgrindar minskar osäker beständig lagring. Hämtningskontroller fångar föråldrade, motsägelsefulla, kompositionella eller utlösarberoende risker som inte syntes när enskilda poster lagrades. Inget av lagren bör få ge verktygsauktoritet.
Kontroll av påståenden
| Påstående | Kontroll | Status |
|---|---|---|
| --- | --- | --- |
| GhostWriter uppnådde cirka 98 % genomsnittlig injektion och cirka 60 % genomsnittlig aktivering i sina experiment | Rapporterat av artikeln över de testade personliga agentkonfigurationerna; inte en uppskattning av förekomst i produktion | Verifierat, avgränsat |
| MemPoison innehåller 1 227 manuellt validerade fall över fyra attacktyper, tre injektionskanaler och tre minnesunderlag | Anges i artikelns abstract och beskrivning av utvärderingen | Verifierat |
| Grundläggande försvar vid skrivning lämnar strukturella blinda fläckar för kompositionella och vilande attacker | MemPoison-författarna rapporterar kvarvarande påverkan för L2- och L3-fall | Verifierat, avgränsat |
| MemGhost rapporterade 87,5 % och 71,4 % end-to-end-framgång i två reserverade konfigurationer | Rapporterat över 56 reserverade fall enligt artikelns testupplägg | Verifierat, avgränsat |
| MemGhost mätte inte spam- och autentiseringskontroller hos e-postleverantörer | Utvärderingen börjar efter leverans till inkorgen och modellerar inte dessa kontroller | Verifierat |
| Microsoft rekommenderar att minne behandlas som data och kontrollplan | Anges i aktuell vägledning på Microsoft Learn | Verifierat |
| En giltig signatur gör inte minnet tillförlitligt | Integritet efter skapandet fastställer inte säker källa, sanning, avsikt eller auktoritet | Verifierat |
| Aktivitet i ett repository bevisar inte att ett minnesramverk är säkert | Stjärnor, commits och releaser mäter uppmärksamhet och underhåll, inte säkerhetseffektivitet | Verifierat |