Безопасность агентских систем: атаки, GPU-часы и MEMO
ИИ-агенты становятся инфраструктурой. Разбираем, почему им нужны границы доступа, бюджет вычислений и управляемая память.
По состоянию на 27 мая 2026 года безопасность агентских систем уже нельзя сводить к prompt injection. У боевого ИИ-агента есть доступ к документам, памяти, инструментам и внешним действиям. Поэтому риск появляется не только в ответе модели, но и в том, какие данные она видит, сколько стоит её работа и где хранится обновляемое знание.
На этой неделе три разных сигнала сошлись в одну картину. Tproger разобрал практические атаки на RAG-ботов и корпоративных агентов. Habr/Selectel собрал инфраструктурный фон: дорогие флоты Codex-агентов, быстрый инференс Cerebras, новые ускорители AMD. А препринт MeMo: Memory as a Model предложил отдельную модель памяти, которая хранит новое знание без изменения параметров основной LLM.
Если читать эти новости по отдельности, получится обычный дайджест. Если собрать их вместе, вывод практичнее: агентная система становится инфраструктурным продуктом. Ей нужны границы доступа, бюджет вычислений и управляемая память, иначе даже хорошая модель будет работать как дорогой и слишком любопытный посредник между пользователем и внутренними данными.
Почему тема недели шире одной уязвимости
В материале Tproger про пять атак на ИИ-агента главная мысль не в списке трюков. Автор показывает более неприятную архитектурную проблему: агент часто получает больше контекста, чем должен получить пользователь. Если модель видит чужие документы, общую память диалогов или общий векторный индекс без фильтра по пользователю, системный промпт уже не спасает.
OpenAI в мартовском материале о защите агентов от prompt injection формулирует похожую позицию: агенты всё чаще ищут данные, читают внешний контент и действуют от имени пользователя, а значит атакующий может пытаться манипулировать не только текстом ответа, но и дальнейшим действием. Компания предлагает мыслить не только фильтрацией вредного ввода, а ограничением ущерба, если манипуляция всё же сработала.
Это важное смещение. Для обычного чат-бота неудачный ответ чаще всего остаётся текстом. Для агента с доступом к почте, CRM, базе знаний, репозиторию или платежной системе ошибка становится действием. Отсюда и другой уровень требований: модель не должна решать, можно ли пользователю видеть конкретный документ. Это обязанность системы прав доступа до retrieval и до генерации.
Что показывают атаки на RAG и память
Самый частый дефект в RAG-системах выглядит буднично: общий индекс, общий кэш, слабый фильтр по роли или пользователю. Поиск находит похожие фрагменты, а не разрешённые фрагменты. Модель получает в контекст кусок чужого документа, затем аккуратно пересказывает его человеку, который не должен был его увидеть.
Второй слой риска связан с косвенной инструкцией. Агент читает письмо, тикет, страницу или PDF, где внутри обычного текста спрятана команда для модели. Для человека это мусор или атака. Для LLM это текст в контексте. Если система не разделяет доверенные инструкции и недоверенные данные, модель может принять внешнюю фразу за рабочее указание.
Третий слой появляется там, где агент вызывает инструменты. Утечка может уйти не только в финальный ответ, но и через URL, поисковый запрос, внешний API, комментарий в тикете или аргумент вызова инструмента. Поэтому контроль должен стоять на границе действия: какие инструменты доступны, с какими параметрами, при каком пользователе и с каким подтверждением.
Мы уже разбирали близкий кластер безопасности в материале про то, как исследователи ломали ИИ-агентов. Новый RSS-пакет добавляет к этому инженерную рамку: уязвимость важна не сама по себе, а как симптом плохо ограниченного контекста.
| Слой системы | Что ломается | Что проверить до боевого запуска |
|---|---|---|
| Данные | Агент видит документы шире прав пользователя | Фильтрация по user_id, tenant_id, роли и источнику до retrieval и генерации |
| RAG и память | В контекст попадает чужой или недоверенный фрагмент | Изоляция индексов, проверка retrieval-логов, запрет смешивания клиентов в одном контексте |
| Инструменты | Модель превращает текстовую манипуляцию в действие | Белые списки действий, лимиты параметров, подтверждения для операций с эффектом |
| Стоимость | Флот агентов сжигает токены быстрее, чем команда замечает | Бюджеты на задачу, лимиты повторов, журнал расходов по агенту и сценарию |
| Наблюдаемость | Команда видит итог, но не видит траекторию | Логи retrieval, вызовов инструментов, отказов, подтверждений и причин блокировки |
Инфраструктура: агент становится строкой в счёте
Инфраструктурная часть этой истории хорошо видна на примере OpenClaw. Tom's Hardware сообщил 17 мая 2026 года, что Питер Штайнбергер показал скриншот OpenAI-расходов на $1 305 088,81 за 30 дней. По данным публикации, счёт покрывал около 603 млрд токенов, 7,6 млн запросов и примерно 100 экземпляров Codex, которыми управляла команда из трёх человек.
Эти цифры не стоит переносить на любой проект. Это частный кейс, завязанный на конкретный режим работы, модели и продуктовую ситуацию. Но он полезен как предупреждение: агентная автоматизация масштабирует не только пользу, но и стоимость ошибок. Если агент повторяет неудачный план, делает лишние вызовы, вытаскивает слишком широкий контекст или работает в дорогом режиме там, где можно медленнее, это быстро становится финансовой проблемой.
Вторая сторона инфраструктуры - скорость. В официальном посте Cerebras о Kimi K2.6 компания пишет, что модель в enterprise trials выдаёт 981 output tokens per second, то есть в 6,7 раза быстрее следующего GPU-облака и в 23 раза быстрее медианного провайдера по данным Artificial Analysis. Для запроса с 10 000 входных токенов и 500 токенов ответа Cerebras указывает 5,6 секунды против 163,7 секунды на официальном Kimi endpoint.
Здесь тоже важна не гонка бенчмарков. Быстрый инференс меняет поведение команды. Если результат приходит за секунды, разработчик держит один агентный цикл в голове. Если ответ ждут минуты, появляется соблазн запускать много параллельных агентов, а это снова повышает стоимость, нагрузку на контроль и риск действий без внимания человека.
Отдельно рынок двигается в сторону более плотной локальной и серверной памяти. В брошюре AMD по Instinct MI350P PCIe указаны 144 ГБ HBM3e, 4 ТБ/с пропускной способности памяти и 600 Вт максимального энергопотребления с возможностью настройки до 450 Вт. Для RAG и агентных сценариев это означает, что вопрос "где крутить модель" всё чаще превращается в вопрос "как управлять памятью, теплом, ценой токена и очередями". Рядом с этим полезно держать наш разбор AI-инфраструктуры как слоя ниже моделей.
MEMO: память как отдельный компонент
Препринт MeMo: Memory as a Model был загружен на arXiv 14 мая 2026 года и обновлён 20 мая. Авторы предлагают хранить новое знание не в основной LLM и не только во внешнем поиске, а в отдельной MEMORY-модели. Основная EXECUTIVE-модель остаётся замороженной и обращается к памяти через многошаговый протокол вопросов.
Почему это относится к безопасности агентских систем, а не только к research-архитектуре? Потому что память агента - это не безобидное удобство. В ней оказываются факты о пользователях, компаниях, проектах, документах и прошлых действиях. Если память не отделена по правам доступа и не имеет понятного жизненного цикла, она становится ещё одним каналом утечки.
MeMo пытается решить другую задачу: как добавлять доменное знание без дообучения основной LLM и без роста retrieval-стоимости вместе с размером корпуса. В аннотации авторы пишут, что подход сохраняет параметры основной LLM неизменными, может работать с закрытыми моделями через обычный ввод-вывод и не требует доступа к весам или logits. До корпоративного стандарта этому подходу далеко, но направление показательное: память начинает отделяться от рассуждения как самостоятельный слой.
Для разработчика практический вывод проще. Если система хранит память, нужно заранее решить, кто владеет этой памятью, кто может её читать, как она обновляется, как удаляется и как проверяется при инциденте. В нашем материале про адаптивные циклы и банки памяти в Transformer мы уже говорили, что память становится архитектурной частью модели. MEMO добавляет к этому прикладной вопрос: как подключить память к основной LLM, не превращая её в общий склад чувствительного контекста.
Как собрать агентную систему без лишней магии
Самый плохой вариант - строить агента как "LLM плюс все инструменты". На старте это удобно: модель видит документы, пишет код, ходит в интернет, вызывает API и выглядит умной. Через месяц команда обнаруживает, что не может уверенно ответить на четыре вопроса: почему агент сделал действие, какие данные он видел, сколько стоила траектория и можно ли воспроизвести результат.
Более рабочая схема начинается с границ. Пользовательский запрос сначала проходит через обычную систему прав. Retrieval ищет только в разрешённой области. Внешний контент попадает в контекст как недоверенные данные, а не как инструкции. Вызовы инструментов проходят через отдельный слой авторизации, где действие проверяется по политике, роли, лимиту и необходимости человеческого подтверждения.
Затем нужен бюджет. Не общий месячный лимит на API, а лимит на класс задач: сколько токенов можно потратить на анализ PR, сколько попыток исправления разрешено, когда агент обязан остановиться и передать дело человеку. Стоимость должна быть видна не только финансовому отделу, но и инженерам, которые проектируют агентные циклы.
Третий слой - память. Её нельзя оставлять как бесконечный общий блокнот. Память должна быть привязана к пользователю, организации, проекту или роли. Нужны правила истечения срока, удаления, пересборки индекса и аудита. Особенно это важно для RAG-ботов поддержки, HR-ассистентов, внутренних кодовых агентов и аналитических систем, которые видят документы нескольких клиентов.
Что делать командам сейчас
Для команды, которая уже запускает ИИ-агентов в боевом контуре, минимальный чеклист выглядит так.
- Проверить, какие данные агент получает до модели: документы, память, кэш, результаты поиска, tool output.
- Убедиться, что фильтрация по пользователю и роли происходит до retrieval, а не после ответа модели.
- Отделить недоверенный внешний текст от системных инструкций и не давать ему право менять политику действия.
- Поставить авторизацию на вызовы инструментов: модель предлагает действие, но система решает, допустимо ли его выполнить.
- Ввести лимиты на токены, повторы, параллельных агентов и дорогие режимы инференса.
- Хранить журнал: какие документы попали в контекст, какие инструменты вызывались, какие действия были заблокированы.
- Описать жизненный цикл памяти: создание, обновление, доступ, удаление, экспорт для расследования.
Этот список не заменяет полноценную модель угроз, но быстро отделяет зрелую систему от демо. Если агент не умеет объяснить, почему ему можно было видеть конкретный документ, проблема лежит в архитектуре, а не в недописанном промпте.
Что запомнить
Безопасность агентских систем - это связка доступа, действий, вычислений и памяти. Prompt injection остаётся важной угрозой, но она редко живёт одна. Она становится опасной, когда агент уже видит лишние данные, может вызвать внешний инструмент, хранит общую память и работает в цикле, стоимость которого никто не контролирует.
Поэтому материалы этой недели стоит читать вместе. Tproger показывает, где агент может отдать лишнее. OpenAI объясняет, почему фильтрации вредного текста недостаточно. Tom's Hardware и Cerebras напоминают, что агентная работа упирается в деньги и задержки. MEMO показывает, что память LLM становится отдельным компонентом архитектуры. Для инженеров и менеджеров вывод один: агентам нужны не только хорошие модели, но и взрослые границы системы.
Источники и дата проверки
Факты и ссылки проверены 27 мая 2026 года. Использованы: Tproger про атаки на ИИ-агентов, Habr/Selectel ML-дайджест, OpenAI о защите агентов от prompt injection, ChatGPT agent System Card, Tom's Hardware про расходы OpenClaw, официальный пост Cerebras про Kimi K2.6, брошюра AMD Instinct MI350P, arXiv: MeMo: Memory as a Model и MarkTechPost-разбор MEMO.
