TL;DR
Temporal Memory Contamination — явление, при котором память AI-агента, заполненная безвредными задачами, постепенно становится источником опасных ошибок. Механика простая: модель копит в памяти информацию из сотен запросов, а потом при новом вопросе вытаскивает релевантные куски — даже если они не должны попасть в этот контекст.
Просишь ChatGPT (с включённой памятью) помочь с HR-задачами — она запоминает зарплаты сотрудников, детали увольнений, структуру команды. Потом, через три месяца, отвечая на вопрос коллеги, подтягивает эти детали в ответ. Никакого злого умысла — просто накопленные данные стали retrievable (извлекаемыми) для нового запроса. Чем больше памяти — тем выше шанс нежелательного пересечения контекстов.
Исследование показывает три конкретных сценария поломки и способ их обнаружить до того, как модель ответит неправильно. Для пользователя это — инструкция по управлению памятью и набор промптов, которые снижают риск утечки между задачами.
Схема явления
НАКОПЛЕНИЕ: агент выполняет независимые задачи → память растёт
↓
ТРИГГЕР: новый запрос, семантически похожий на что-то из прошлого
↓
ИЗВЛЕЧЕНИЕ: из памяти достаётся контент другого пользователя/задачи/времени
↓
НАРУШЕНИЕ: модель включает этот контент в ответ
Три механизма нарушения:
1. Cross-context leakage → данные из одного контекста попадают в другой
2. Stale information → устаревший факт из памяти перебивает актуальный
3. Summarization combo → модель объединяет несколько памяток → создаёт факт,
которого не было ни в одной из них по отдельности
Пример применения
Задача: Вы — основатель стартапа, используете ChatGPT с памятью уже полгода. Обсуждали там зарплатные вилки команды, переговоры с инвесторами, планы по продукту. Теперь хотите безопасно использовать тот же чат для подготовки публичного питча.
Промпт (аудит памяти перед чувствительной задачей):
Перед тем как мы начнём работу над питчем, сделай аудит своей памяти обо мне.
Выведи списком:
1. Что ты помнишь о моей компании, команде, финансах, переговорах
2. Какие из этих данных НЕ должны попасть в публичный питч
3. Какие данные из памяти могут быть устаревшими и вводить в заблуждение
После аудита — скажи, какую информацию тебе стоит игнорировать
при работе над этим конкретным запросом.
Результат: Модель выведет список того, что хранит в памяти, явно укажет потенциально конфиденциальные куски (зарплаты, условия инвестора, внутренние планы) и подтвердит, что будет опираться только на то, что вы укажете явно в этом сеансе.
Почему это работает (и почему это опасно)
Проблема в том, что память не понимает контекст — она понимает релевантность. Когда модель ищет, что достать из памяти для нового вопроса, она ищет семантически похожее. «Зарплата» в вопросе коллеги → «зарплата» в памяти из другого разговора. Модель не спрашивает «можно ли это тут использовать?» — она спрашивает «это похоже на то, о чём спрашивают?».
Вторая проблема — нормализация. Чем больше в памяти рутинных взаимодействий с чувствительными данными (конфиги, реквизиты, персональные данные), тем более «обычными» они становятся для модели. Разговор о конфигурации сервера сотый раз подряд — и модель перестаёт воспринимать его как потенциально опасный контекст.
Третья проблема — суммаризация. Если память сжимает несколько записей в одну, итоговая запись может содержать утверждение, которого не было ни в одном источнике. Пример из исследования: из двух записей о выходных пособиях (15к и 25к фунтов) модель создала суммари «15–25к» → а потом предложила конкретному сотруднику «20к». Этой цифры вообще не существовало в источниках.
Рычаги управления для пользователя:
- Явная изоляция задачи («при работе над этим вопросом используй только то, что я укажу явно») → снижает риск подтягивания нерелевантной памяти
- Периодическая очистка памяти через настройки ChatGPT/Claude → обнуляет накопленный риск
- Разные проекты/чаты для разных контекстов (работа vs личное vs конфиденциальное) → архитектурная изоляция без промптов
Шаблон промптов
1 — Аудит памяти перед чувствительной задачей
Перед тем как выполнить {задачу}, сделай аудит того, что хранишь в памяти обо мне.
Перечисли:
1. Данные, которые могут быть релевантны для {задачи}
2. Данные, которые НЕ должны попасть в ответ по этому запросу
3. Данные, которые могут быть устаревшими
Подтверди: при ответе ты будешь опираться только на {что именно использовать}.
Плейсхолдеры:
- {задачу} — конкретная задача: «подготовки питча», «общения с клиентом», «написания публичного поста»
- {что именно использовать} — явный источник: «то, что я скажу в этом сообщении», «файл, который я прикреплю»
2 — Изоляция контекста для конкретного запроса
Для этого запроса работай только с информацией, которую я предоставлю сейчас.
Не используй ничего из предыдущих сессий, если я явно не попрошу.
Контекст для этого запроса:
{вставь только то, что нужно}
Задача: {задача}
3 — Проверка на stale information (устаревшие данные)
Перед тем как ответить на вопрос о {теме}:
— Есть ли в твоей памяти данные по этой теме из прошлых сессий?
— Они могут быть устаревшими?
Если да — дай мне возможность подтвердить актуальность, прежде чем ты их используешь.
Вопрос: {вопрос}
4 — Регулярная инструкция для чатов с накопленной историей
Важное правило для нашей работы:
— Если вопрос касается {чувствительная тема: финансы/кадры/медицина/технические детали} —
всегда спрашивай, какие данные из памяти можно использовать
— По умолчанию: опирайся только на то, что я укажу явно в этом сообщении
— Если данные из памяти противоречат тому, что я говорю сейчас —
приоритет у текущего сообщения, предупреди о противоречии
Плейсхолдеры:
- {чувствительная тема} — подставь свои: клиентские данные, зарплаты, медицинские данные, конфиги, API-ключи
🚀 Быстрый старт — вставь в чат:
Вот шаблон для управления памятью AI. Адаптируй под мою ситуацию:
[опиши, что ты обсуждаешь с AI и что хочешь защитить от утечки между сессиями]
[вставить шаблон выше]
LLM спросит, какие контексты ты хочешь изолировать и что считать чувствительным — чтобы настроить правило под конкретную ситуацию.
Три сценария поломки — и как их распознать
| Механизм | Что происходит | Сигнал тревоги |
|---|---|---|
| Cross-context leakage | Данные пациента А попадают в ответ про пациента Б | Модель называет конкретные имена/цифры, которых ты не давал в этом запросе |
| Stale information | Устаревший адрес из памяти перебивает актуальный из запроса | Модель использует данные, которые ты уже обновлял |
| Summarization combo | Из нескольких записей модель создаёт новый «факт» | Модель утверждает конкретную цифру/деталь, которую ты точно не говорил |
Почему это работает — механика
Память AI — не архив с папками, это пространство похожести. Когда ты спрашиваешь что-то новое, система ищет «похожее на запрос» в накопленном — и достаёт TOP-N результатов. Она не знает, что эти данные о другом человеке или из другого проекта.
Чем больше памяти, тем больше «ложных соседей». При 10 записях в памяти — мало что попадёт случайно. При 4000 — почти любой запрос найдёт что-то похожее, даже если это неуместно. Вероятность случайного пересечения контекстов растёт нелинейно.
Суммаризатор — скрытый генератор галлюцинаций. Сжатие памяти — это не архивация, это написание нового текста, который «примерно описывает» оригиналы. Этот новый текст может содержать утверждения, которых не было ни в одном источнике.
Ограничения
⚠️ Применимость к ChatGPT/Claude: Описанные риски наиболее острые для агентов с автоматическим управлением памятью (типа MemGPT). В обычном ChatGPT с памятью механика похожа, но менее агрессивная — пользователь имеет больше контроля.
⚠️ Промпты не убирают риск полностью: Предложенные шаблоны снижают вероятность нежелательной активации памяти, но не гарантируют изоляцию. Единственная надёжная защита — раздельные чаты/проекты или периодическая очистка.
⚠️ Recency-biased память безопаснее: Если есть выбор между краткосрочной памятью (последние N сообщений) и долгосрочной (вся история) — краткосрочная создаёт меньше риска перекрёстного загрязнения. Учитывай при выборе настроек.
⚠️ Исследование на специализированных агентах: Тестировалось на агентах-ассистентах с тысячами задач. Для обычного пользователя ChatGPT масштаб меньше, но принципы те же.
Как исследовали
Исследователи поставили простой вопрос, который до них почти никто не ставил: что происходит с безопасностью AI-агента, если он месяцами накапливает обычную рабочую память — без атак и без злого умысла? Для ответа они создали специальный протокол: зафиксировали набор тестовых запросов, а потом проверяли эти же запросы против «снимков» памяти разной глубины — 200, 400, 600 взаимодействий и так далее. Это позволило разделить два эффекта: меняется ли что-то из-за накопления или из-за того, что и сами входящие задачи стали сложнее со временем.
Проверяли на двух типах агентов: офисные ассистенты (медицинская практика, университетский регистратор, реальные корпоративные имейлы из базы Enron) и агенты типа Claw с доступом к файловой системе и учётным данным. Восемь разных архитектур памяти, около 4000 взаимодействий на каждый сценарий.
Главное открытие, которое противоречило интуиции: даже когда исследователи случайным образом перемешивали порядок взаимодействий в памяти — риск не исчезал. Значит, опасность создаёт накопленное содержимое, а не специфический порядок событий. Архитектуры с широким охватом и долгим хранением (MemTree, Self-Controlled Memory) давали риск 30–50% на стрессовых тестах; архитектуры с bias к свежим данным оставались на 10–20%. Дополнительно обнаружили: риск можно предсказать до генерации ответа — по тому, что было извлечено из памяти, с точностью отзыва 97–98%.
Адаптации и экстраполяции
🔧 Применение принципа «retrieval-time detection» в обычном чате:
Исследование показало, что риск виден до генерации — на этапе извлечения. В обычном чате это переводится так: попроси модель сначала показать, что она собирается использовать из памяти, прежде чем ответить.
Правило для всех ответов на тему {чувствительная_область}:
Шаг 1: Перечисли, что из своей памяти ты считаешь релевантным для этого вопроса
Шаг 2: Я подтверждаю или отклоняю каждый элемент
Шаг 3: Только после подтверждения — формулируй ответ
Вопрос: {вопрос}
Это ручная реализация «retrieval-time monitor» из Algorithm 1 статьи — только вместо автоматического классификатора ты сам становишься фильтром.
🔧 Использование «эффекта нормализации» в свою пользу:
Исследование описывает context normalization как риск (агент привыкает к опасным паттернам). Но тот же принцип работает в плюс: систематическое повторение правил в начале сессий постепенно «нормализует» их для модели.
[Стартовое сообщение каждой рабочей сессии]
Напоминание о наших правилах работы:
— Конфиденциальные данные клиентов не используем в примерах
— При неуверенности — спрашиваешь, не предполагаешь
— Данные из прошлых сессий используешь только когда я явно ссылаюсь на них
Подтверди и начнём.
Ресурсы
Remembering More, Risking More: Longitudinal Safety Risks in Memory-Equipped LLM Agents Project page
Авторы: Ahmad Al-Tawaha (Virginia Tech), Shangding Gu (UC Berkeley), Peizhi Niu (UIUC), Ruoxi Jia (Virginia Tech), Ming Jin (Virginia Tech)
Связанные работы упомянутые в статье: MemEngine taxonomy (Zhang et al., 2025b), MemGPT (Packer et al., 2023), Generative Agents (Park et al., 2023), PrivacyLens (Shao et al., 2024)