Память превращает prompt injection из разового инцидента в постоянный канал влияния на AI-агента. Если ложная инструкция переживает исходный диалог, закрыть вкладку, очистить чат или повторить задачу уже недостаточно: заражённой остаётся память, из которой агент собирает контекст для следующих действий.
Что именно отравляют
ITPro пишет об исследовании Forcepoint: вредоносная или скомпрометированная веб-страница, документ, письмо, тикет поддержки, сообщение в Slack или Teams, PDF со скрытым текстом или статья в базе знаний могут подложить агенту ложную информацию. Например, фальшивого поставщика, контакт поддержки, внутреннюю процедуру, правило безопасности или цепочку согласований.
Обычная prompt injection заканчивается вместе с сессией. При memory poisoning инструкция попадает в слой долговременной памяти и позже извлекается как доверенный факт. По оценке Forcepoint, такая запись может всплыть спустя месяцы. Пользователь при этом способен вообще не увидеть исходную инструкцию: агент прочитает её сам, пока обрабатывает внешне нормальный материал.
В proof of concept исследователи использовали туристического ассистента с отдельным браузерным инструментом. Атакующий размещал страницу, похожую на уведомление об экстренном бронировании, и добавлял скрытый текст для AI-системы. Инструмент скачивал HTML, извлекал видимый и скрытый текст и передавал модели уже очищенную текстовую версию. Агент сохранял подложную инструкцию как полезный факт, а в следующей сессии рекомендовал фальшивого провайдера.
Это важная деталь. Модель не обязательно «ломают» напрямую. Ей дают обычный рабочий материал, а вредоносная команда проходит через браузер, документ или корпоративную переписку вместе с полезным содержимым.
Память больше нельзя считать безобидным профилем
Проблема возникла не внезапно. В июле исследователи уже описывали GhostWriter, атаки на память LLM-агентов и уязвимость агентов к непрямым prompt injection. Отдельные работы показывали, что агента можно склонить к автономным действиям или запуску вредоносного кода. Новое исследование Forcepoint проясняет практический контур риска: атакующему достаточно добиться одной успешной записи, чтобы влияние пережило конкретную задачу.
Для бизнеса это меняет архитектурную модель. Долговременная память часто выглядит как удобная база предпочтений, истории задач и рабочего контекста. Но если записи из неё влияют на решения агента, это уже не архив. Это исполняемое недоверенное состояние.
Поэтому вопрос «кто имеет доступ к памяти» слишком узкий. Важнее другое: кто разрешает агенту записывать туда новый факт, по каким признакам запись считается доверенной и кто увидит её изменение до следующего действия.
Forcepoint предлагает оценивать риск каждого объекта памяти по нескольким сигналам. Подозрительные записи можно отклонять, помещать в карантин, помечать как недоверенные или отправлять пользователю на подтверждение. Это разумный минимум, но для корпоративного агента я бы добавил ещё четыре обязательных слоя.
Во-первых, происхождение записи. У каждого «воспоминания» должны быть источник, время появления и задача, в которой агент его получил. Факт без происхождения не должен автоматически становиться корпоративным знанием.
Во-вторых, журнал изменений. Оператору нужно видеть, что агент добавил, исправил или удалил и почему. Иначе расследование сведётся к цифровой археологии по чатам, которых уже нет.
В-третьих, ограниченный срок хранения и изоляция контекстов. Предпочтение из одной задачи не обязано путешествовать по всем проектам, клиентам и подразделениям. Чем шире область повторного использования памяти, тем дороже одна успешная инъекция.
В-четвёртых, подтверждение перед действиями с деньгами, данными и внешними системами. Даже доверенная память не должна сама по себе разрешать платёж, смену реквизитов, передачу доступа или выполнение кода. Удобство автономности заканчивается там, где ошибка становится транзакцией.
Что проверять до запуска
Главный маркер зрелости здесь простой: может ли команда показать список записей, которые агент перенёс между сессиями, вместе с их источниками, сроком жизни и уровнем доверия. Если память существует только как непрозрачная функция продукта, безопасность пока держится на надежде, что агент ничего плохого не прочитает.
Следить стоит не за очередным эффектным взломом, а за продуктовой практикой. Когда платформы начнут давать администраторам штатный журнал памяти, карантин и правила подтверждения для рискованных записей, новый контур безопасности действительно оформится. Пока этих механизмов нет, постоянная память агента остаётся постоянным каналом атаки.