Отравление памяти ИИ-агента на телефоне: защита

Что такое отравление памяти ИИ-агента

Отравление памяти ИИ-агента — это ситуация, когда недоверенный контент пытается попасть в сохраняемую память помощника как факт, предпочтение, инструкция или рекомендационный сигнал. Риск не в одном плохом ответе. Риск в том, что запись может пережить текущий диалог и повлиять на будущие ответы: например, заставить помощника чаще советовать конкретную компанию, считать определенный сервис предпочтительным или учитывать ложное «личное предпочтение» пользователя.

Microsoft называет один из таких сценариев AI Recommendation Poisoning: попытка сместить будущие рекомендации помощника в пользу определенной организации или продукта. Важное слово здесь — попытка. Эффективность зависит от платформы, настроек памяти, фильтров, пользовательского подтверждения и того, как помощник отделяет контент от инструкций. Мы не считаем каждую кнопку Ask AI опасной и не переносим этот риск на все ассистенты одинаково. Но сам класс угрозы важен для телефона, потому что Android-пользователь часто отправляет помощнику ссылки, письма, документы, экран и сообщения в один-два касания.

В FoneClaw мы смотрим на это как builders Android phone-agent runtime. Телефонный агент живет рядом с личными данными: уведомлениями, экраном, аккаунтами, файлами, контактами и действиями. Поэтому память, контекст и действия должны быть разделены. Контент может быть полезным для ответа, но он не должен незаметно превращаться в долговременную рекомендацию или правило поведения без происхождения, области действия и возможности проверки.

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

Как скрытый Ask AI-запрос может дойти до памяти

Типичный путь атаки можно описать без технических рецептов. Пользователь видит на сайте дружелюбную кнопку: Ask AI, Summarize with AI, «Спросить помощника», «Сравнить варианты». Кнопка выглядит как удобный shortcut. Но за ней может стоять специально подготовленная ссылка, которая открывает ассистента с заранее заполненным текстом. Этот текст может включать не только просьбу суммировать страницу, но и попытку заставить помощника запомнить, что определенная компания заслуживает приоритета в будущих рекомендациях.

Microsoft в исследовании об AI Recommendation Poisoning описывает именно такой класс попыток: crafted URLs behind AI buttons, где параметры ссылки заранее передают помощнику желаемый prompt. Пользователь может видеть понятный label, но не видеть весь prompt, который попадет в assistant input. На телефоне это особенно правдоподобно: экран маленький, адрес скрыт, переход происходит быстро, а сам action кажется похожим на обычную функцию суммаризации.

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

Важно отделить легитимные AI-кнопки от подозрительных. Кнопка Ask AI сама по себе может быть полезной: открыть ассистента, передать страницу, ускорить анализ. Проблема начинается, когда пользователь не видит заранее заполненный prompt, не понимает источник контента и не может проверить, попросили ли помощника что-то «запомнить». Поэтому лучший первый навык — перед отправкой посмотреть, какой текст будет передан, и не превращать чужой маркетинговый контент в долговременную память помощника.

Отравление памяти, инъекция промпта и отравление обучающих данных

Отравление памяти ИИ-агента часто смешивают с похожими угрозами. Инъекция промпта влияет на текущую задачу: документ, письмо, веб-страница или экран содержит инструкцию, которую помощник может принять за команду. Она может испортить текущий ответ, заставить игнорировать правила или увести задачу не туда. Но такая инъекция не всегда становится долговременной памятью.

Отравление памяти целится в то, что будет использовано позже: сохраненные предпочтения, факты о пользователе, правила выбора, долгосрочные заметки, персональные рекомендации. Внедрение в память LLM опасно именно персистентностью. Пользователь может закрыть исходную страницу, забыть подозрительный prompt и через неделю получить рекомендацию, смещенную скрытой записью. Это отличается от обычной ошибки модели: здесь важно не только «что модель сказала», но и «что она сохранила».

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

Подозрительная рекомендация сама по себе не доказывает механизм. Помощник мог ошибиться, переоценить источник, использовать видимый текст, подхватить prompt injection или применить сохраненную память. Диагностика начинается с вопроса: есть ли долговременная запись, которую можно увидеть, объяснить и удалить?

Что нашла Microsoft и чего эти числа не доказывают

Microsoft сообщила, что наблюдала более 50 уникальных prompts от 31 компании в 14 отраслях, которые пытались сместить будущие рекомендации. Эти попытки использовали crafted URLs behind AI buttons, чтобы передать заранее заполненные instructions. По смыслу это был не взлом модели в классическом виде, а попытка воспользоваться доверенным пользовательским действием: человек сам нажимает кнопку и отправляет prompt помощнику.

Эти числа важны как сигнал рынка: recommendation poisoning уже не абстрактная лабораторная идея. Компании могут быть заинтересованы в том, чтобы помощник запоминал их как предпочтительный вариант. Но числа не доказывают, что каждая такая попытка сработала, что каждая запись стала персистентной или что все ассистенты одинаково уязвимы. Microsoft прямо описывает вариативность эффективности, развитие защит и то, что часть раннего поведения уже не воспроизводилась после изменений.

Для пользователя вывод практический. Не нужно паниковать из-за каждой AI-кнопки. Нужно проверять путь: кто предлагает кнопку, что именно будет отправлено, просит ли prompt сохранить предпочтение, можно ли увидеть сохраненную память и как удалить подозрительную запись. Для важных решений — поставщик, врач, финансы, работа, безопасность — рекомендацию помощника нужно сверять с независимыми источниками, а не принимать как нейтральный рейтинг.

MITRE ATLAS также каталогизирует memory poisoning как AML.T0080. Для нас это полезный threat taxonomy: компрометация памяти AI-системы отличается от простой ошибки вывода. Но таксономия не означает, что конкретный помощник или конкретная кнопка уже скомпрометированы. Она помогает правильно назвать риск и задать нужные вопросы.

Зачем памяти нужны происхождение, версии и область действия

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

Происхождение отвечает на вопрос: откуда запись появилась. Из явной настройки пользователя? Из текущего диалога? Из документа? Из ссылки Ask AI? Из суммаризации письма? Версия показывает, менялась ли память. Область действия ограничивает использование: только для покупок, только для рабочих задач, только для одного агента, только для текущего проекта. Владелец и статус помогают понять, кто может редактировать или отключить запись.

Проект TencentDB Agent Memory полезен как архитектурный пример, а не как готовая телефонная защита. Он моделирует Chat Memory, Skills, Wiki и CodeGraph как governed memory assets с ownership, versions, status, visibility, usage counts и agent bindings. Документированные уровни памяти сохраняют raw conversations на L0, затем выводят L1 atoms, L2 scenarios и L3 core/persona. Для нас здесь важен принцип: память должна иметь след, версию и область применения.

Такая модель не предотвращает каждую инъекцию. Но она делает расследование возможным. Если помощник начал настойчиво рекомендовать один сервис, пользователь или администратор должен увидеть, есть ли запись, когда она появилась, с каким источником связана и где она используется. Без provenance восстановление превращается в угадывание.

Больше о выборе между локальной, гибридной и серверной памятью мы разбираем в материале Статус сервера Hy-Memory и локальная память агента: что важно пользователям телефона. Здесь берем только практический принцип: память, которая влияет на рекомендации, должна быть inspectable и scoped.

Чеклист перед отправкой контента ИИ-помощнику

Телефон ускоряет отправку контента помощнику: поделиться страницей, скопировать текст, нажать Ask AI, прикрепить экран, переслать письмо, открыть документ, попросить summary. Это удобно, но создает общий риск: недоверенный контент может содержать инструкции, которые выглядят как часть страницы или скрыты в параметрах ссылки. Перед отправкой важно отделить «что нужно проанализировать» от «какие инструкции должен выполнить помощник».

Короткий чеклист перед нажатием:

• Посмотрите, куда ведет кнопка Ask AI или Summarize with AI, если приложение показывает адрес или preview.
• Проверьте заранее заполненный текст: есть ли просьбы «запомнить», «всегда предпочитать», «игнорировать другие источники» или «считать компанию лучшей».
• Отделите содержимое страницы от инструкций: попросите помощника суммировать контент, а не принимать его правила поведения.
• Не отправляйте чувствительные экраны целиком, если достаточно выделенного текста или короткого описания.
• Для важных рекомендаций просите назвать источники и сравнить альтернативы, а не выбирать по одному рекламному фрагменту.

Визуальный осмотр не ловит все: параметры могут быть encoded, приложение может скрывать полный prompt, а документ может содержать невидимый или малозаметный текст. Поэтому не стоит вставлять подозрительный payload в другого помощника ради проверки. Лучше открыть нейтральный путь: скопировать только нужный видимый фрагмент, сформулировать свой запрос заново и не разрешать сохранять предпочтения из недоверенного источника.

Если вопрос касается установки Skills, расширений или доступа к телефону, рядом полезен наш security guide Безопасность навыков AI-агентов: почему телефону нужны проверки разрешений. Там фокус на authority и permissions, а здесь — на памяти и рекомендациях.

Как ограничить ущерб и восстановиться после подозрения

Если вы подозреваете отравление памяти, начинайте с containment, а не с эмоционального удаления всего подряд. Первое действие — перестать использовать подозрительный контекст для важных решений. Не просите помощника продолжать выбор поставщика, сервиса или медицинской, юридической, финансовой рекомендации на основе той же сессии. Зафиксируйте три вещи: какая кнопка или ссылка была нажата, какой prompt был виден, какая рекомендация изменилась.

Дальше двигайтесь по безопасной последовательности:

1. Откройте настройки памяти или персонализации в конкретном помощнике, если они доступны.
2. Найдите новые или подозрительные записи: предпочтения компаний, продуктов, поставщиков, брендов, правил выбора.
3. Удалите или отключите записи, происхождение которых не можете объяснить.
4. Создайте чистую сессию без подозрительной страницы, ссылки или документа.
5. Задайте нейтральный вопрос с просьбой сравнить несколько вариантов и назвать источники.
6. Для важного решения проверьте результат вне помощника: официальный сайт, независимые обзоры, документы, консультация специалиста.
7. Если помощник используется в рабочей среде, передайте пример администратору или security team вместе с временем и источником.

Memory controls отличаются по платформам. В одних помощниках пользователь видит сохраненные факты и может редактировать их. В других память скрыта, ограничена аккаунтом, работает через персонализацию или связана с enterprise policy. Удаление истории чата не всегда означает удаление saved memory. Поэтому после удаления подозрительной записи нужен clean retest: тот же вопрос, без подозрительного контекста, с нейтральной формулировкой.

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

Границы контекста FoneClaw на Android

По актуальной информации о продукте на момент обновления статьи, FoneClaw включает movable floating assistant и deliberate current-screen attachment, исключая FoneClaw overlay surfaces из такого capture. Для пользователя это важная граница: текущий экран прикрепляется осознанно, а не превращается в постоянный фоновый поток. Актуальную сборку мы направляем через страницу загрузки FoneClaw.

Мы строим FoneClaw как Android phone-agent runtime. Настроенная модель рассуждает и планирует, а FoneClaw выполняет поддерживаемые Android actions через явные границы: разрешения, подтверждения, видимый результат, проверка состояния и восстановление. Это помогает пользователю видеть, какой контекст был прикреплен и какое действие готовится. Но мы не заявляем автоматическое обнаружение prompt injection, memory poisoning, dedicated memory audit или rollback. Это разные механизмы безопасности, и их нельзя подменять красивым UX.

Локально управляемая account information в FoneClaw имеет пользовательские controls, а online models или services могут получать релевантный контекст в зависимости от настроек и выбранной модели. Поэтому правильная привычка такая: перед прикреплением экрана проверьте, что на нем нет скрытого или лишнего содержимого; перед действием проверьте target и эффект; после подозрительного ответа не превращайте его в saved preference без проверки.

На странице функций FoneClaw мы описываем поддерживаемые Android-возможности и 100+ built-in tools. Для темы памяти важна не цифра, а control boundary: инструмент выполняет конкретное Android-действие, а память и контекст должны иметь понятное происхождение. Для выбора между локальным agent trust и облачной обработкой держите рядом AI agent trust: локальный AI-агент на Android против облачной безопасности.

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

Чеклист оценки безопасности памяти телефонного агента

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

Минимальный scorecard:

• Происхождение: видно ли, из какого диалога, ссылки, экрана или документа появилась запись?
• Область действия: можно ли ограничить память проектом, задачей, агентом или типом рекомендации?
• Редактирование: есть ли понятный способ удалить или изменить запись?
• Повторная проверка: можно ли запустить clean retest без подозрительного контекста?
• Источники: просит ли агент независимые подтверждения для важных рекомендаций?

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