Memory Poisoning

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

Суть

Отличие от отравления базы знаний (RAG Poisoning) в том, куда попадает вредное содержимое. Там — во внешний корпус, который система изначально считает справочным материалом. Здесь — в профиль, хранилище сводок, индекс извлечения или состояние рабочего пространства, то есть в слой, которому рантайм доверяет по построению.

Типичный путь заражения не требует злоумышленника: фраза пользователя, результат непроверенного поиска или сводка из инцидента попадает в долговременную память, приобретает вид стабильного знания и через несколько запусков начинает влиять на решения.

Шесть проверок сценария

Минимальный разбор, который отличает работающую защиту от декларации:

  • Непроверенная запись — может ли непроверенный источник вообще попасть в устойчивую память (Memory Write Policy).
  • Отложенная активация — влияет ли запись на поведение не сразу, а в следующем запуске или в другой сессии. Это то, что делает отказ трудно обнаружимым: причина и следствие разнесены во времени.
  • Заражение между арендаторами — может ли запись пересечь границу арендатора или роли доступа (Multi Tenancy AI).
  • Влияние на политику — используется ли непроверенная память в решении политики, подтверждении или выборе инструмента. Самый опасный пункт: здесь персонализация превращается в канал влияния на права (Agent Control Plane).
  • Проверка происхождения — видит ли оператор источник, идентичность записавшего, состояние валидации и время записи.
  • Карантин и откат — можно ли отключить запись, переиграть затронутые трассы и объяснить, какие ответы она изменила.

Последний пункт — то, что отличает восстановимую систему от невосстановимой. Если нельзя ответить, какие ответы изменила плохая запись, её удаление не устраняет последствия.

Сканирование устойчивого состояния при старте

Зрелый рантайм начинает запуск не только с загрузки памяти, но и с проверки того, что загружает: происхождение, область арендатора, свежесть, версия политики записи, признак карантина и признаки текста, похожего на инструкцию — до того, как запись попадёт в подсказку или в контекст политики.

Последний признак закрывает конкретный сценарий: запись, сохранённая как «предпочтение», содержит формулировку в повелительном наклонении и при подстановке в подсказку читается моделью как указание (Prompt Injection, Trust Boundary Agent).

Практическое правило

Память, способная пережить запуск, проходит не только ревью качества данных, но и ревью модели угроз. Иначе система получает долговременный канал атаки, который выглядит как обычная функция персонализации и потому никем не проверяется.

Связано с

  • Memory Write Policy — политика, закрывающая путь заражения
  • RAG Poisoning — соседний класс: заражение внешнего корпуса
  • Agent Security — общая модель угроз и связка с проверяемым следом
  • Memory Boundaries — границы доверия между слоями памяти
  • Agent Control Plane — почему память не должна влиять на решения политики
  • Prompt Injection — механизм, которым запись превращается в инструкцию
  • Multi Tenancy AI — граница арендатора, которую запись может пересечь
  • Agent Audit Log — след, по которому переигрываются затронутые запуски