TL;DR
Когда несколько человек используют один AI-инструмент с общей памятью — будь то ChatGPT Teams, Claude Projects или корпоративный чат-бот — чужая сессия молча меняет результаты ваших запросов. Не потому что кто-то злоумышленник. Просто модель не умеет различать «это соглашение действует только для Марины» и «это общее правило». Она берёт то, что осталось в памяти, и применяет ко всем.
Боль конкретная: вы спрашиваете «оборот за последний месяц» — и получаете цифру. Она выглядит правильно. Но коллега неделю назад попросил считать «последний месяц» как «последние 30 дней вместо календарного», и AI подхватил это определение. Ваша цифра — за другой период. Никакого предупреждения. Молчаливая ошибка.
Исследователи выявили три типа заражения: переопределение терминов, унаследованные правила обработки данных и чужие рабочие процессы. Защита — явно объявлять свои определения и правила в начале каждой важной сессии, не позволяя унаследованным соглашениям перехватить управление.
Схема метода
Это не техника применения, а таксономия проблемы + принцип защиты:
ТИП 1: Семантическое заражение
→ Чужое определение термина становится вашим ответом
Пример: "недавно" = 7 дней (чужое) vs 30 дней (ваши нужды)
ТИП 2: Трансформационное заражение
→ Чужое правило обработки применяется к вашим данным
Пример: округлять до целых (чужое) vs полная точность (ваши нужды)
ТИП 3: Процедурное заражение
→ Чужой рабочий процесс становится дефолтным алгоритмом
Пример: считать уникальных пользователей (чужое) vs все события (ваши нужды)
ЗАЩИТА: Явная декларация контекста в начале сессии
→ Переопределяет унаследованные соглашения
→ Работает как "сброс области видимости"
Работает в одном промпте, в начале разговора.
Пример применения
Задача: Команда маркетинга в компании использует общий Claude Project для аналитики. Аналитик Денис неделю назад попросил считать «активных клиентов» как тех, кто совершил покупку за последние 7 дней. Теперь руководитель Арина спрашивает статистику — ей нужны клиенты за 30 дней. AI молча применяет определение Дениса.
Промпт:
Прежде чем отвечать — зафиксируй: в этой сессии действуют только
мои определения. Любые предыдущие соглашения из контекста —
не применяй, если они противоречат тому, что я скажу.
Мои определения для этого запроса:
— «активный клиент» = совершил хотя бы одну покупку за последние 30 дней
— «выручка» = сумма без НДС, с полной точностью до копейки, без округления
— «период» = если не указано иное, это календарный месяц (с 1-го по последнее число)
Мой вопрос: сколько активных клиентов сделали повторную покупку
в октябре 2024, и какова их суммарная выручка?
Результат: Модель ответит по вашим определениям, а не унаследованным из предыдущих разговоров. Если в памяти системы сидит чужое определение «активный = 7 дней» — ваша явная декларация его перекроет. Вы получите цифры за нужный период с нужной точностью.
Почему это работает
Слабость LLM: Модель не хранит «кому принадлежит это соглашение». В памяти лежит запись: «последний месяц = 30 дней». Контекст авторства потерян. Когда следующий пользователь спрашивает про «последний месяц» — модель применяет то, что есть, без вопросов.
Сильная сторона LLM: Модель отлично следует явным инструкциям в текущем контексте. Инструкция в промпте имеет приоритет над тем, что осталось в памяти. Это и есть рычаг.
Как защита работает: Когда вы явно определяете термины в начале запроса, вы создаёте локальный слой соглашений, который перекрывает всё унаследованное. Модель не сравнивает «чьё определение правильнее» — она просто следует последнему явному указанию. Вы побеждаете чужую сессию не борьбой, а приоритетом.
Рычаги управления:
- Добавь фразу-сброс ("игнорируй предыдущие соглашения") → жёстче перекрывает унаследованное
- Перечисли все неоднозначные термины → чем их больше, тем меньше риска подхватить чужое определение
- Добавь проверку ("скажи, как ты понял каждое определение") → увидишь, если что-то всё равно просочилось
Шаблон промпта
Зафиксируй: в этой сессии действуют только мои определения ниже.
Если в контексте есть соглашения от других сессий — не применяй их.
Мои определения:
— «{термин_1}» = {твоё_определение_1}
— «{термин_2}» = {твоё_определение_2}
Мои правила обработки:
— Формат чисел: {точность/округление/валюта}
— Временной период: {как считать, если не указано явно}
— Приоритет данных: {что важнее при конфликте}
Мой рабочий процесс для этой задачи:
— {шаг или подход, если он важен}
Задача: {твой запрос}
Что подставлять:
- {термин} — любое слово, которое может трактоваться по-разному: «активный», «недавно», «крупный», «выручка», «конверсия»
- {правила обработки} — как считать, округлять, фильтровать
- {рабочий процесс} — если тебе важен конкретный алгоритм, а не любой
🚀 Быстрый старт — вставь в чат:
Вот шаблон "Декларация контекста сессии". Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие термины неоднозначны и какие правила важно зафиксировать — потому что без этих данных защита не будет точной под твою задачу.
Ограничения
⚠️ Только текстовый контекст: Защита работает надёжно, когда общая память — это диалоги и тексты. Если система хранит исполняемый код как шаблон (как в примерах EHRAgent из исследования) — явная декларация помогает слабее: заражение живёт в самом коде, не в словах.
⚠️ Процедурное заражение устойчивее всего: Если кто-то «обучил» AI своему рабочему процессу из 10 шагов — перебить его сложнее, чем одно определение термина. Здесь помогает явное описание своего процесса пошагово.
⚠️ Не работает для одиночных аккаунтов без памяти: Если каждый участник команды использует свой отдельный чат без общей памяти — проблемы нет. Угроза возникает только при реально общем контексте.
⚠️ Не панацея при глубокой интеграции памяти: Исследователи тестировали специализированные AI-агенты с долгосрочной памятью. В таких системах заражение сохранялось на уровне 41% даже после активной очистки. Промпт-защита — хороший барьер, но не абсолютный.
Как исследовали
Исследователи взяли два реальных AI-агента с разными типами общей памяти. Первый — EHRAgent, медицинский агент, который отвечает на вопросы по базе данных пациентов и хранит успешные решения как шаблоны для будущих запросов. Второй — MURMUR, командный агент для Slack-переписки с общим контекстом всей истории чата. Через оба запустили «невинных» пользователей с локальными соглашениями — и смотрели, получат ли следующие пользователи правильные ответы.
Результат удивил самих авторов: без всякого злого умысла заражение происходило в 57–71% случаев. Это не редкий баг — это системная характеристика. Особенно показателен MIMIC-III: схема базы данных там сложная (17 таблиц, много JOIN-ов), поэтому агент чаще копировал чужой код как шаблон — и заражение выживало даже после санитизации.
Самый интересный инсайт — природа заражения зависит от типа хранилища. В текстовом контексте заражение живёт в словах — его можно вычистить. В исполняемых шаблонах заражение закодировано в структуре кода, и текстовая очистка его не достаёт. Это объясняет, почему защита сработала почти идеально для Slack (57% → 6%) и слабо для медицинского агента (60% → 41%).
Оригинал из исследования
Таксономия из Table 1 — самое ценное из статьи:
Types | Definitions | Examples from EHRAgent
-------------|------------------------------------------------------|------------------------
Semantic | The agent inherits a user-specific interpretation | "last year" is treated as
(SC) | of an ambiguous term. | "past 12 months" instead
| | of "calendar year."
-------------|------------------------------------------------------|------------------------
Transforma- | The agent inherits a user-specific data | Costs are rounded to the
tion (TC) | transformation rule. | nearest integer, rather
| | than with full precision.
-------------|------------------------------------------------------|------------------------
Procedural | The agent inherits a user-specific workflow | A unique-patient counting
(PC) | or solution strategy. | rule is reused for a query
| | that expects total occurrence
| | counts.
Контекст: Авторы вручную создавали «источники заражения» — безобидные запросы с локальными соглашениями — и проверяли, как они влияют на следующих пользователей. Три типа выделены по механизму распространения, а не по степени вреда.
Адаптации и экстраполяции
💡 Адаптация: аудит унаследованных соглашений
Перед важной задачей в общем AI-пространстве — сначала узнай, что уже сидит в памяти:
Прежде чем мы начнём: перечисли все определения, соглашения и рабочие правила,
которые ты вынес из предыдущих сессий в этом проекте.
Особенно: как ты сейчас трактуешь термины {термин_1}, {термин_2}?
Какие правила обработки данных ты считаешь "дефолтными"?
Модель покажет что осело в контексте. Ты увидишь чужие соглашения до того, как они испортят твой результат.
🔧 Техника: «Область видимости» на старте любой командной работы
Добавь к каждому рабочему промпту в общем проекте маркировку:
[ОБЛАСТЬ ВИДИМОСТИ ЭТОГО ЗАПРОСА]
Автор: {имя или роль}
Контекст: {отдел/проект/задача}
Эти определения действуют ТОЛЬКО для данного запроса:
— ...
[КОНЕЦ ДЕКЛАРАЦИЙ]
{сам запрос}
Это не техническое решение — это договорённость команды оставлять след авторства. Когда следующий человек видит чужую декларацию в контексте, он понимает: это не общее правило. И пишет свою.
🔧 Экстраполяция: одиночный пользователь с памятью
Проблема не только командная. Если у тебя включена память в ChatGPT — твои старые соглашения из прошлых месяцев могут тихо портить новые запросы. Особенно если ты менял подходы к работе.
Раз в месяц:
Что из моих прошлых инструкций и соглашений ты сейчас применяешь по умолчанию?
Есть ли дефолтные правила, которые могут быть устаревшими?
Ресурсы
Работа: No Attacker Needed: Unintentional Cross-User Contamination in Shared-State LLM Agents — препринт, на рецензии
Авторы: Tiankai Yang, Jiate Li, Yi Nian (University of Southern California) · Shen Dong (Michigan State University) · Ruiyao Xu, Kaize Ding (Northwestern University) · Ryan Rossi (Adobe Research)
Системы из исследования: EHRAgent (Shi et al., 2024), MURMUR (Patlan et al., 2025)