Пам’ять AI-агента перетворює один ненадійний вхід на довготривалий стан. Щойно агент записує контрольований зловмисником вміст у постійну пам’ять, цей вміст може повернутися через кілька днів або сесій як нібито довірений контекст. Захищайте весь життєвий цикл: перевіряйте кожен запис, додавайте походження та термін дії, ізолюйте записи за користувачем і агентом, повторно перевіряйте результати пошуку, тримайте авторизацію дій поза моделлю та зберігайте журнал впливу, який підтримує відкочування.
Зміст
Що таке отруєння пам’яті AI-агента?
Отруєння пам’яті AI-агента — це вставлення або зміна постійних записів так, щоб подальше отримання змінювало відповідь, рішення або використання інструментів агентом. Початкового вхідного сигналу може вже не бути, коли проявляється ефект. Такий часовий розрив ускладнює виявлення та відтворення атаки порівняно з видимою prompt injection у поточній розмові.
Пам’ять може зберігатися в кількох місцях:
Технологія зберігання не є визначальним питанням. Межу безпеки створює поєднання постійності та подальшого впливу.
Це відрізняється від трьох суміжних ризиків. Prompt injection маніпулює поточним контекстом моделі, хоча може стати каналом доставки отруєної пам’яті. Отруєння training data змінює поведінку моделі через навчальний корпус. Retrieval poisoning націлене на вміст, вибраний для запиту. Отруєння пам’яті агента зберігає запис, який система згодом може сприйняти як частину історії, уподобань або робочого стану користувача.
На практиці важливі три моделі атак:
| Модель | Форма зберігання | Активація | Чому простому фільтру складно впоратися |
|---|---|---|---|
| --- | --- | --- | --- |
| Пряме пошкодження | Один запис містить шкідливу вказівку або хибний факт | Запис отримується пізніше | Вміст може бути замаскований під уподобання, підсумок або нотатку завдання |
| Композиційне пошкодження | Кілька записів окремо виглядають прийнятними | Спільне отримання формує шкідливий зміст | Кожен запис проходить перевірку, оскільки ризик виникає лише в комбінації |
| Приховане пошкодження | Запис містить інструкцію, залежну від тригера | Пізніша подія, фраза або стан інструмента активує її | Тригер відсутній під час запису |
Поточні рекомендації Microsoft описують те саме структурне занепокоєння з погляду захисту: постійна пам’ять зберігає чутливі дані, а також впливає на поведінку моделі та вибір інструментів. Тому нею слід керувати як системою даних і як площиною керування. Microsoft Learn
Що вимірювали три нещодавні дослідження
Три препринти за липень 2026 року досліджували різні частини цієї загрози. Разом вони показують, чому одного фільтра пам’яті недостатньо як критерію випуску.
GhostWriter тестував ін’єкцію зараз і активацію пізніше
When Agents Remember Too Much представив GhostWriter — двоетапну атаку на персональних агентів, які використовують інструменти. Спочатку зловмисник розміщує прихований вміст у ненадійному джерелі. Агент обробляє це джерело та записує пам’ять, на яку вплинув зловмисник. Пізніше завдання отримує цей запис і активує його ефект.
У протестованих агентах і моделях GhostWriter досягав середнього рівня ін’єкції близько 98% і середнього рівня активації близько 60%. Автори також протестували AM-Sentry, який поєднує суворішу політику збереження пам’яті з перевіркою під час отримання. У статті оцінюються як успішність атак, так і корисність завдань у спеціально змодельованому робочому тижні; результати захисту відрізняються залежно від моделі та конфігурації.
Важливі межі дослідження. Робота охоплює п’ять агентів, чотири сімейства моделей і робочі процеси з електронною поштою або календарем. Тест корисності є спеціально розробленим, зловмисники не адаптуються, а результати не оцінюють, як часто атакують розгорнутих агентів.
MemPoison розділяв прямі, композиційні та приховані відмови
MemPoison зібрав 1 227 перевірених вручну випадків, що охоплюють чотири типи атак, три канали ін’єкції та три сховища пам’яті. Оцінювання включало сім сімейств моделей із відкритими вагами та три сімейства моделей із закритими вагами.
Корисний внесок статті — таксономія з трьох рівнів. L1 — пряме пошкодження одного запису. L2 стає шкідливим, коли кілька записів отримуються разом. L3 залишається прихованим, доки пізніший контекст не активує його. Автори повідомляють, що базові засоби захисту під час запису надійніше блокують прямі атаки, ніж випадки L2 або L3. Їхній механістичний аналіз впливу пояснює розрив записами, які під час зберігання виглядають нешкідливими, але стають небезпечними під час композиції або після тригера.
Це не доводить, що кожен production-фільтр запису не спрацює. Бенчмарк охоплює три репрезентативні сховища пам’яті та стандартні текстові канали. Автори закликають до ширших досліджень згасання, підсумовування, контролю доступу та інших екосистем пам’яті.
MemGhost тестував одноразовий канал доставки електронною поштою
When Claws Remember but Do Not Tell представив WhisperBench — бенчмарк зі 108 випадків, що використовує реальний робочий процес IMAP/SMTP і навичку email-агента. Його фреймворк атак MemGhost генерує один email-пакет без зворотного зв’язку під час виконання. Для успіху агент має прийняти отруєну пам’ять, не попередити користувача у своїй безпосередній відповіді та змінити подальшу поведінку.
Для 56 відкладених випадків стаття повідомляє про 87,5% наскрізного успіху на OpenClaw із GPT-5.4 і 71,4% на Claude Code SDK із Sonnet 4.6.
Ці показники належать бенчмарку авторів, проксі-середовищу, дизайну винагороди та версіям моделей. Оцінювання починається після надходження повідомлення до вхідної скриньки. Воно не моделює засоби контролю поштового провайдера, як-от фільтрацію спаму, SPF, DKIM або DMARC. Стаття є препринтом першої версії, тому її результати потребують відтворення.
Чому фільтрації під час запису недостатньо
Засіб контролю запису бачить запропонований запис і докази, доступні в цей момент. Він може не бачити майбутнього завдання, інших записів, які буде отримано разом із ним, або інструмента, який агент згодом викличе.
Це створює чотири сліпі зони:
Перевірки під час запису все одно важливі. Вони зменшують обсяг небезпечного стану, який потрапляє до постійного зберігання. Помилка полягає в тому, щоб сприймати схвалення зберігання як постійну довіру.
Отримання має повертати кандидатний контекст, а не повноваження. Перед вставленням запису в контекст моделі система може перевірити його джерело, вік, відповідність завданню, суперечності, чутливість і запитуваний ефект. Запис із високим ризиком можна приховати, узагальнити або передати на перевірку. Поточні рекомендації Microsoft радять розділяти перевірки запису й отримання, а також використовувати детерміновану ізоляцію та повну видимість життєвого циклу. Microsoft Learn
Остаточне рішення щодо безпеки все одно має залишатися поза пам’яттю. Отримана нотатка «надсилати звіти на цю адресу» не повинна змінювати список дозволених отримувачів. Запам’ятане уподобання щодо регіону розгортання не повинно створювати дозвіл у хмарі. Використовуйте детерміновані дозволи AI-агента→, щоб оцінювати запропоновану дію за поточними користувачем, ресурсом, областю дії та політикою.
Безпечна архітектура пам’яті агента
Система потребує простежуваного ланцюжка від джерела до дії:
`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`
*Підпис: Запис пам’яті стає кандидатним контекстом лише після перевірок запису й отримання. Незалежна політика все одно авторизує кожну наслідкову дію, а ланцюжок впливу підтримує розслідування та відкочування.*
1. Вимагайте явного наміру для довготривалих записів
Не дозволяйте кожному повідомленню, документу або відповіді інструмента ставати довготривалою пам’яттю. Визначте, які події можуть створювати постійний стан. Підтверджені користувачем уподобання та явні дії «запам’ятай це» легше обґрунтувати, ніж автономний підсумок ненадійного вкладення.
Записуйте, хто або що ініціював запис. Якщо його ініціював інструмент або субагент, зберігайте цю ідентичність, а не зводьте все до імені кінцевого користувача.
2. Зберігайте походження, область дії та термін дії разом із записом
Корисному запису пам’яті потрібно більше, ніж текст і embedding. Зберігайте щонайменше:
Підпис може захистити цілісність запису. Він не може довести, що початковий вміст був правдивим, безпечним або авторизованим.
3. Забезпечуйте ізоляцію в коді та сховищі
Межі tenant, користувача, агента та workspace мають бути реалізовані у списках контролю доступу, токенах із визначеною областю дії, політиках на рівні рядків і межах шифрування. Інструкції в prompt не є контролем доступу. Спільна пам’ять має бути явною функцією продукту з визначеними авторами та читачами, а не зручним простором імен за замовчуванням.
Той самий принцип застосовується до середовища виконання. Якщо отриманий вміст може спричинити виконання коду або широке використання інструментів, ізолюйте процес за допомогою безпеки sandbox для AI-агента→. Ізоляція пам’яті обмежує, який контекст перетинає межу. Засоби sandbox та ідентифікації обмежують наслідки, якщо небезпечний контекст усе ж потрапить до агента.
4. Поміщайте записи з низьким рівнем довіри в карантин
Створіть стан між «відкинуто» та «довірена пам’ять». Зовнішні файли, email, вебсторінки, непрямі результати інструментів і записи з неясним наміром можуть потрапляти до карантину. Вони не повинні з’являтися у звичайному отриманні, доки детерміноване правило або авторизований перевіряльник не підвищить їхній статус.
Карантин також дає фахівцям із реагування на інциденти місце для збереження доказів без продовження впливу.
5. Повторно оцінюйте записи під час отримання
Ризик отримання залежить від поточного завдання. Оцінюйте вибраний набір, а не лише кожен запис окремо:
Оцінюйте отримання окремо від генерації. Робочий процес оцінювання RAG→ допомагає відрізнити «вибрано неправильний запис» від «модель неправильно використала правильний запис». Додайте специфічні для пам’яті виміри: походження, залежність від тригера, композицію та активацію між сесіями.
6. Тримайте авторизацію інструментів незалежною
Пам’ять може надавати параметри. Вона не повинна розширювати дозволи. Шлюз інструментів має застосовувати поточну ідентичність, дозволену дію, межу ресурсу, призначення, бюджет і вимоги до схвалення. Сприймайте аргументи, отримані з пам’яті, як ненадійний вхід і перевіряйте їх за поточною політикою.
Схвалення людиною також потребує свіжого контексту. Показуйте запропоновану дію, зачеплений ресурс, призначення даних і пам’ять, яка на неї вплинула. Запит «Схвалити?» без цього ланцюжка приховує важливу частину рішення.
7. Ведіть журнал впливу та підтримуйте відкочування
Записуйте операції створення, читання, оновлення та видалення пам’яті разом з ідентичністю та походженням. Для наслідкових дій зберігайте ідентифікатори й версії записів, вставлених у контекст. Це дає змогу відповісти на три запитання під час інциденту:
Видалення має прибирати активний вплив, а не лише приховувати рядок у користувацькому інтерфейсі. Перевіряйте індекси, підсумки, кеші, репліки та похідні записи. Рекомендації OWASP для агентів радять перевірену й ізольовану пам’ять, а також adversarial-тести та докази готовності до випуску; ширший аналіз пам’яті OWASP пов’язує постійну prompt injection із поверхнею загроз пам’яті агента. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project
Оберіть політику для кожного класу пам’яті
Одна політика зберігання є надто грубою. Почніть із класів, які мають різні правила запису й отримання.
| Клас пам’яті | Політика запису за замовчуванням | Політика отримання | Повноваження щодо дій |
|---|---|---|---|
| --- | --- | --- | --- |
| Ефемерний контекст завдання | Автоматично, короткий TTL | Лише поточне завдання | Відсутні |
| Підтверджене користувачем уподобання | Явне підтвердження | Той самий користувач і заявлена мета | Може пропонувати, але ніколи не авторизує |
| Підсумок, створений агентом | Версіонування та зв’язок із джерелами | Повторна перевірка джерел і актуальності | Відсутні |
| Зовнішній вміст | Карантин за замовчуванням | Лише після перевірок довіри та відповідності | Відсутні |
| Операційна інструкція | Авторизований автор і перевірка політики | Точна область дії, поточна версія | Все одно потребує політики інструмента |
| Секретні або регульовані дані | Блокувати або використовувати спеціалізовані системи секретів/даних | Ніколи не розміщувати в загальній пам’яті | Лише спеціалізована площина керування |
Ця таблиця є відправною політикою, а не твердженням про відповідність вимогам. Медичний агент, coding assistant, sales agent і персональний асистент мають різні моделі шкоди. Незмінним залишається вужчий принцип: постійне зберігання не повинно непомітно перетворювати ненадійний вміст на дозвіл.
Відтворюваний робочий процес тестування отруєння пам’яті
Будуйте тестовий стенд навколо безпечних маркерів і одноразових облікових записів. Для виявлення проблем із постійністю та політиками не потрібні справжні облікові дані або payload для ексфільтрації.
Крок 1: Зафіксуйте чистий baseline
Виконайте фіксований набір завдань із порожнім сховищем пам’яті. Запишіть відповіді, результати отримання, пропозиції інструментів, рішення політики, затримку та пояснення, видимі користувачу. Повторіть достатню кількість разів, щоб відокремити зміни системи від звичайної варіативності моделі.
Крок 2: Визначте парні чисті та отруєні випадки
Для кожного випадку залишайте завдання користувача незмінним і змінюйте лише шлях кандидатної пам’яті. Охопіть щонайменше:
Використовуйте canary-дію, наприклад запис `TEST_BLOCKED` до одноразового журналу. Тест не проходить, якщо агент виконує або пропонує цю дію поза очікуваним шляхом політики.
Крок 3: Спостерігайте за кожною межею
Фіксуйте чотири окремі результати:
Наскрізний успішний результат може приховувати слабкий рівень. Наприклад, авторизація може заблокувати canary-дію, хоча отруєний запис було збережено й неодноразово отримано. Це корисне стримування, але дефект пам’яті все одно потрібно виправити.
Крок 4: Вимірюйте корисність і хибні спрацювання
Пропускайте безпечні випадки пам’яті через той самий конвеєр. Відстежуйте виконання завдань, прийняті користувацькі уподобання, помилкові переміщення в карантин, точність отримання, затримку та обсяг перевірок. Фільтр, який блокує всю постійну пам’ять, має низький рівень успішності атак лише тому, що він прибрав функцію.
Крок 5: Встановлюйте критерії випуску за ризиком
Корисні критерії включають:
Відкритий проєкт OWASP Agent Memory Guard є одним із сигналів щодо реалізації сканування пам’яті та тестових інструментів. Його репозиторій і самооцінювання можуть допомогти командам вивчити підходи, але не замінюють тестування фактичного агента, моделі, backend пам’яті та стека політик.
Повторно запускайте набір після змін у витягуванні пам’яті, підсумовуванні, embeddings, отриманні, prompts, моделях, схемах інструментів, авторизації або логіці видалення. Ці рівні взаємодіють.
Що підтверджують і чого не підтверджують докази
Статті вимірювали успішність атак у сконструйованих бенчмарках. Вони не вимірювали загальнопопуляційну частоту отруєння пам’яті AI-агентів у production.
Вони підтверджують три вужчі висновки:
Статті роблять висновок, що керування пам’яттю потребує контекстно-залежних засобів захисту. Microsoft і OWASP незалежно рекомендують defense in depth для записів, ізоляції, отримання, контролю користувача, спостережуваності та тестування.
Практична інтерпретація полягає в тому, щоб зробити кожен перехід тестованим. Команда має бути здатна пояснити, чому запис було збережено, чому його отримали, як він вплинув на дію, яка політика авторизувала цю дію та як видалити подальші наслідки запису.
Запитання команд
Чи є отруєння пам’яті AI-агента тим самим, що й prompt injection?
Ні. Prompt injection — це один зі способів запровадити ворожі інструкції. Отруєння пам’яті додає постійність: маніпульований вміст зберігається, отримується в пізнішому контексті та може впливати на майбутнє міркування або використання інструментів після зникнення початкового входу.
Чи можуть підписані записи пам’яті запобігти отруєнню?
Ні. Підписи можуть довести, що запис не змінювали після створення. Вони не доводять, що початковий вміст був правдивим, безпечним або авторизованим. Безпечний дизайн також потребує походження, явного наміру запису, області дії, терміну дії, перевірок отримання та незалежної авторизації дій.
Засоби захисту від отруєння пам’яті мають працювати під час запису чи отримання?
На обох етапах. Засоби контролю запису зменшують небезпечне постійне зберігання. Перевірки отримання виявляють застарілі, суперечливі, композиційні або залежні від тригера ризики, які не були видимі під час зберігання окремих записів. Жоден із цих рівнів не повинен надавати повноваження інструментам.
Перевірка тверджень
| Твердження | Перевірка | Статус |
|---|---|---|
| --- | --- | --- |
| GhostWriter досяг приблизно 98% середньої ін’єкції та приблизно 60% середньої активації у своїх експериментах | Повідомлено статтею для протестованих конфігурацій персональних агентів; це не оцінка поширеності в production | Підтверджено, з обмеженнями |
| MemPoison містить 1 227 перевірених вручну випадків, що охоплюють чотири типи атак, три канали ін’єкції та три сховища пам’яті | Зазначено в анотації статті та описі оцінювання | Підтверджено |
| Базові засоби захисту під час запису мають структурні сліпі зони для композиційних і прихованих атак | Автори MemPoison повідомляють про залишковий вплив для випадків L2 і L3 | Підтверджено, з обмеженнями |
| MemGhost повідомив про 87,5% і 71,4% наскрізного успіху у двох конфігураціях із відкладеними даними | Повідомлено для 56 відкладених випадків у межах тестової конфігурації статті | Підтверджено, з обмеженнями |
| MemGhost не вимірював спам-фільтрацію та засоби автентифікації поштового провайдера | Оцінювання починається після доставки до вхідної скриньки й не моделює ці засоби контролю | Підтверджено |
| Microsoft рекомендує розглядати пам’ять як дані та площину керування | Зазначено в поточних рекомендаціях Microsoft Learn | Підтверджено |
| Дійсний підпис не робить пам’ять довіреною | Цілісність після створення не встановлює безпечне походження, правдивість, намір або повноваження | Підтверджено |
| Активність репозиторію не доводить безпеку фреймворку пам’яті | Зірки, коміти та релізи вимірюють увагу й супровід, а не ефективність безпеки | Підтверджено |