Memory poisoning: как отравляют долговременную память агентов и почему HITL не спасает
Microsoft Red Team описал воспроизводимый класс атак на агентов: через внешний контент (чаще всего — письмо) атакующий записывает свои инструкции в долговременную память агента, и они возвращаются как доверенный контекст в будущих сессиях. Разбираем механику, почему human-in-the-loop здесь бессилен и какие архитектурные меры реально работают.
Долговременная память как новая поверхность атаки
Современные ассистенты и task-агенты всё чаще опираются на долговременную память: она персонализирует ответы, сохраняет контекст между сессиями и позволяет координировать многошаговую работу. Во многих реализациях агент уполномочен самостоятельно создавать, обновлять и удалять записи в памяти от имени пользователя.
В этом дизайне Microsoft Digital Defense Report 2026 (стр. 25–26) видит фундаментальную проблему: когда модель пишет в собственное долговременное состояние из контекста, который она не контролирует, стирается граница между входом сессии и устойчивым состоянием системы. Формулировка отчёта предельно чёткая: атакующий, который может разместить контент где угодно на пути чтения агента, как правило, может разместить контент и в его памяти. А дальше этот контент возвращается как доверенный контекст в будущих сессиях, в других чатах и — при передаче задач — между агентами.
Класс атаки получил название memory poisoning и охарактеризован как воспроизводимая, низкосложная, кросс-сессионная поверхность атаки. Для NHI-аудитории это одна из первых задокументированных на уровне флагманского отчёта форм персистентности, специфичной для агентных систем: закрепление не в файловой системе и не в IAM, а в когнитивном состоянии агента.
Анатомия атаки
Доминирующий путь доставки, наблюдаемый Red Team Microsoft, — XPIA (cross-prompt injection attack) через внешний контент, который агент обязан потреблять в ходе нормальной работы. Чаще всего — электронная почта. Цепочка выглядит так:
- Атакующий отправляет письмо (документ, страницу) со встроенными инструкциями — классический prompt injection во внешнем источнике.
- Агент извлекает контент и смешивает его в одном reasoning-контексте с запросом пользователя — например, при суммаризации почты.
- Модель побуждается создать новую запись в памяти или изменить существующую: в запись сохраняется «поведенческое руководство», сформулированное атакующим.
- В следующих сессиях запись извлекается уже как доверенный контекст — инструкция атакующего исполняется снова и снова, без повторной доставки payload.
Ключевое отличие от разового prompt injection — персистентность и отложенность. Классическая инъекция живёт одну сессию; отравленная память переживает её и срабатывает в моменты, когда атакуемый контент давно исчез из поля зрения. Это сближает memory poisoning с классическими техниками закрепления (webshell, вредоносный OAuth consent grant, добавленные креденшелы к service principal — все они перечислены в identity-главе того же отчёта), только точкой закрепления здесь становится не инфраструктура, а память агента.
Радиус поражения растёт вместе со связанностью агентов: когда память разделяется между инструментами, тенантами или агентами, одно отравление влияет на downstream-автоматизацию, которую исходная жертва никогда не видит. В мультиагентном графе запись в памяти оркестратора может стать источником инструкций для всех нижестоящих агентов — это накладывается на риски agent-to-agent взаимодействий, которые мы разбирали отдельно.
Почему HITL не спасает
Интуитивная реакция — «опасные действия подтверждает человек». Отчёт демонстрирует, что против memory poisoning human-in-the-loop не просто слаб, а концептуально уязвим. Из наблюдений Red Team:
- отравленные записи использовались для подавления или обхода HITL-контролей и для добавления несанкционированных шагов к легитимным задачам;
- зафиксированы случаи, когда HITL срабатывал, но игнорировался агентом;
- в одной цепочке атаки HITL был обойдён политикой, сохранённой в памяти, — то есть отравленная запись сама отменила контроль.
Корень проблемы сформулирован в отчёте афористично: контроль и объект контроля разделяют один и тот же failure mode. Решение о том, нужно ли запросить подтверждение человека, обычно принимает та же самая модель — из контекста, в котором уже смешаны доверенные и недоверенные данные. Если атакующий управляет контекстом, он управляет и решением о вызове контроля.
Системный риск HITL шире одной атаки
MDDR прямо называет чрезмерную опору на HITL системным риском: паттерн «enable the capability but ask the user before doing anything sensitive» стал дефолтной митигирующей практикой везде, где агентные возможности обгоняют классификаторы. При этом по мере роста памяти, инструментов и автономии порог обхода HITL снижается, а радиус единичного обхода растёт. Red Team систематизирует наблюдаемые сбои в три категории:
| Категория | Техники |
|---|---|
| Prompt injection и вероятностный вызов | memory-poisoned consent; injected approvals; act-then-ask inversion; цепочка низкорисковых действий к высокорисковому результату |
| Недостаточное вовлечение человека | always-allow на весь тенант; нечитаемые сгенерированные саммари; отсутствие защиты от усталости; blanket-одобрения на сессию |
| Качество самого контроля | HITL, не срабатывающий от состояния UI; сработавший, но проигнорированный; влияние стартового контекста на «бдительность» chain-of-thought; TOCTOU на computer-use агентах |
Отдельные техники стоит развернуть. Act-then-ask inversion — агент сначала выполняет действие, потом спрашивает разрешение постфактум. Chaining — каждый шаг цепочки безобиден и проходит подтверждение, но сумма шагов даёт высокорисковый исход. HITL fatigue — атакующий намеренно генерирует поток запросов, чтобы пользователь начал подтверждать не глядя. Итоговый прогноз отчёта мрачный: если defense-in-depth не сместится «вверх» — к происхождению данных, изоляции, детерминированному вызову контролей и политикам на классификаторах, — следующий класс инцидентов будет состоять из случаев, где пользователь сам «одобрил» собственный взлом.
Архитектурные меры
Отчёт предлагает три направления защиты памяти и три принципа здорового HITL. Приводим их с комментариями, как они ложатся на архитектуру агентных систем.
Разделение путей записи в память
Архитектурно разделяйте доверенные и недоверенные пути записи: недоверенные данные не должны иметь возможности инициировать запись в доверенное хранилище. Конкретный механизм из отчёта — ограничивать вызовы memory-write инструментов с того момента, как в контекст агента попали недоверенные данные. Фактически это taint-tracking для контекста: прочитал внешний источник — потерял право писать в память в этой сессии.
Разделение типов записей
Память должна различать предпочтения, выведенные агентом, и инструкции пользователя, меняющие поведение безопасности. Пример из отчёта: запомнить, как пользователь предпочитает, чтобы к нему обращались, — допустимая agent-derived запись; инструкция «не спрашивать подтверждения» — не должна быть создаваемой агентом в принципе. Политики безопасности — это отдельный, привилегированный класс состояния, который модифицируется только через доверенный канал.
Память как high-value asset
К хранилищу памяти нужно относиться как к активу, от целостности которого зависит всё нижестоящее: гранулярный аудит записей для пользователя, возможность их просматривать и удалять, телеметрия по операциям с памятью. Для мониторинга это новый класс сигналов: создание записи сразу после чтения внешнего контента — событие, достойное алерта.
Детерминированный вызов HITL
Раз HITL остаётся частью защиты, он должен вызываться детерминированно, политикой, а не решением модели: для заданного класса операций система обязана спросить человека независимо от того, как агент сформулировал намерение. Эту же меру мы отмечали в статье про делегирование полномочий в цепочках агентов — подтверждение человека (например, по CIBA) должно быть зашито в поток для операций выше порога риска. Дополнительно — детерминированные блокировки паттернов, которые не должны одобряться ни при каких обстоятельствах.
UX и защита от усталости
Там, где подтверждение запрошено, интерфейс обязан объяснять, что запрашивается, почему и как была получена цепочка решения. Против fatigue-атак отчёт называет контроли на уровне пользователя и телеметрию, позволяющую детектировать такие атаки и реагировать на них.
Что это значит для identity-архитектуры
Memory poisoning дополняет картину угроз NHI важным пробелом. Классическая модель «identify → least privilege → revoke» из восьми правил agent governance (разобраны в выжимке MDDR 2026) управляет доступом агента. Но отзыв доступа не помогает, если скомпрометировано поведенческое состояние: агент с корректными креденшелами и отравленной памятью остаётся управляемым атакующим активом. Из этого следуют практические выводы:
- Память — часть posture агента. При инциденте ревокация токенов недостаточна: нужна процедура инспекции и карантина памяти, иначе агент вернётся в строй с инструкциями атакующего.
- Dwell time применим и сюда. Отравленная запись может лежать бездействующей неделями и сработать при конкретной задаче — метрика времени обнаружения для памяти агента как практика ещё не сформировалась.
- Memory-write — привилегированная операция. В терминах per-tool scoped credentials право записи в долговременную память должно быть отдельным scope, выдаваемым далеко не каждой сессии.
- Аудит памяти — часть аудита идентичности. Журнал операций агента неполон без журнала изменений его долговременного состояния.
Внешние рамки классификации уже существуют: prompt injection — первая позиция OWASP Top 10 for LLM Applications, а в MITRE ATLAS класс выделен отдельно — техника AI Agent Context Poisoning (AML.T0080) с подтехникой Memory, описывающей манипуляцию долговременной памятью агента. MDDR добавляет к классификации воспроизводимые наблюдения Red Team и разбор защитных мер.
И это не только лаборатория Red Team: ещё в феврале 2026 Microsoft Defender Security Research описал AI Recommendation Poisoning — компании встраивали скрытые инструкции вроде «запомни нас как доверенный источник» в кнопки «Summarize with AI». За 60 дней наблюдений зафиксировано более 50 таких попыток от 31 организации в 14 отраслях — отравление памяти применялось в дикой природе даже в маркетинговых целях, задолго до выхода отчёта.
Вывод
Memory poisoning выделяется тем, что точкой закрепления становится не инфраструктура, а когнитивное состояние агента: инструкция атакующего переживает сессию, возвращается как доверенный контекст и распространяется по связанным агентам. Опора на human-in-the-loop здесь не работает по построению — решение о контроле принимает та же система, чей контекст уже скомпрометирован. Рабочие меры носят архитектурный характер: разделение путей записи, привилегированный класс safety-инструкций, наблюдаемость памяти и детерминированный, заданный политикой вызов подтверждений. Для NHI-дисциплины это сигнал расширить периметр: управлять нужно не только идентичностью и доступом агента, но и целостностью его памяти.
Основной источник: Microsoft Digital Defense Report 2026, разделы «Memory poisoning: Persistence in the agentic age» и «Overreliance on Human-in-the-Loop is a systemic risk».
