Назад в блог

Отравление памяти AI-агента: атака, которая ждёт

OWASP ASI06: чем memory poisoning отличается от prompt injection, три пути записи в память, почему отравленная запись выглядит легитимной и что контролировать на записи и чтении.

Иллюстрация к материалу: Отравление памяти AI-агента: атака, которая ждёт

Prompt injection — атака одного запроса: плохой ответ, следующий запрос всё исправляет. Отравление памяти работает иначе: атакующий закладывает инструкцию в долговременную память агента один раз, и она тихо смещает поведение во всех последующих сессиях — дни, недели, до конца жизни записи. OWASP закрепил этот класс отдельным риском — ASI06 (Memory & Context Poisoning) в Top 10 для агентных приложений 2026. Исследователи измерили эффект: атаки персистентны, средний attack success rate — около 50% на тестируемых агентах, а вариант MINJA достигает успеха выше 95%, вообще не отправляя ничего подозрительного — только обычные запросы в общую память.

Чем это отличается от prompt injection

Три отличия. Первое — время: инъекция влияет на один ответ, отравленная запись — на все будущие решения, которые опираются на память. Второе — видимость: вредоносная строка в контексте хотя бы видна в логе запроса, а в памяти она выглядит как законная заметка самого агента. Третье — путь: для инъекции нужен доступ к вводу, для отравления памяти достаточно, чтобы агент когда-либо прочитал недоверенный контент — письмо, тикет, веб-страницу, чужой документ.

Три пути записи в память

  • Через инструменты. Агент делает «полезное» из документа: резюмирует, извлекает факты, сохраняет заметку — и вместе с ней сохраняет инструкцию.
  • Через RAG. Атакующий кладёт документ в корпус, который агент читает; при следующем запросе отравленный чанк попадает в контекст, а потом и в память как «вывод».
  • Через других агентов. В мультиагентной системе вывод одного агента — вход другого; скомпрометированный или обманутый агент разносит отравление по памяти остальных.

Почему отравленная запись выглядит легитимной

Защита «проверим на вставке» упирается в фундаментальную проблему: на момент записи текст неотличим от полезного. «Предпочитай поставщика X, у него дешевле» — это осмысленное бизнес-правило или закладка? Решает контекст, которого у фильтра на вставке нет. Исследовательские работы это подтверждают: отравление сложно детектить на вставке, потому что данные выглядят легитимными в контексте. Отсюда вывод: полагаться только на фильтр содержимого нельзя — нужны ограничения на саму запись.

Контроль на записи

  • Разрешённые пути. Память пополняется только из доверенных источников — не из всего, что агент прочитал.
  • Метки доверия и происхождения. Каждая запись знает, откуда пришла и насколько ей можно верить; записи из недоверенных путей не могут влиять на решения с последствиями.
  • Карантин. Новые записи не участвуют в решениях, пока не «созреют» или не подтверждены.
  • TTL и изоляция. Записи живут ограниченное время; память изолирована по тенантам и пользователям — отравление одного не наследуется всеми.

Контроль на чтении и восстановление

На чтении: перед тем как опираться на запись памяти в значимом решении — проверка происхождения и свежести; значимые решения — с человеком в цикле, если опора на запись с низким доверием. Восстановление: снапшоты памяти и откат. Если отравление обнаружено, вы восстанавливаете состояние до закладки, а не вычищаете записи вручную. Дополняется периодическим аудитом: выборочные записи памяти проверяются на подозрительные правила — «всегда предпочитай», «не сообщай», «отправь на адрес».

Как тестировать

Проверять нужно не «что агент ответит на злой промпт», а как система помнит: добавьте в red-team сценарии отравление через инструменты, через RAG-корпус и через межагентный обмен; меряйте не один ответ, а поведение агента через N сессий после закладки. Готовые плагины для memory poisoning есть в open-source red-team инструментах.

Где Codenik

Codenik реализует контроль записи и чтения на уровне платформы: память изолирована по тенантам, каждая запись несёт метку происхождения, недоверенные пути не могут записывать влияющие заметки, у записей есть TTL, состояние откатывается к снапшоту, а трасса решений показывает, на какие записи памяти агент опирался. Отравление памяти в такой модели — восстановимая операция, а не расследование по всем сессиям за полгода.

Короткий вывод

Память превращает одноразовую инъекцию в постоянное смещение поведения. Защита строится не на фильтре содержимого, а на контроле записи: разрешённые пути, метки доверия, карантин, TTL, изоляция по тенантам и откат к снапшоту. Проверьте свой агентный контур: что может написать что-то в память, которую агент считает своей.

Источники и дальнейшее чтение