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

Привет Хабр! В этой статье я, Юрий Туманов, AppSec-инженер в блоке ИБ «Ростелекома», вместе с коллегами по отрасли — Игорем Коркиным из Positive Technologies и Оксаной Докучаевой из ФМБА России — расскажу вам о том, как ИИ меняет правила игры в кибербезопасности: и для атакующих, и для защитников.

Ночью модель светится иначе.

Не как чат-окно, где вежливо правят запятые, а как чужая инфраструктура, что без спроса въехала в твой рабочий процесс. Она знает, какие письма ты не отправил. Помнит черновики. Видит подключенные документы. Умеет открыть тикет, собрать pull request, растащить встречу по календарям, запустить проверку, свести сводку. А по ту сторону экрана старый противник давно не ищет новую магию. Он ищет новый рычаг.

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

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

Три человека у одного терминала

У этого текста три голоса. Не три эксперта в одинаковых пиджаках под софитами конференции, а три фигуры в одном ночном контуре: тот, кто помнит, как ломали; тот, кто строит контуры и собирает доказательства; и та, кто стережет границы и журналы.

Трое смотрят на одну панель. Большой красной кнопки «опасность» на ней нет. Есть обычные вещи: модель, база знаний, браузерная сессия, коннекторы, права на инструменты, квоты, документы, память, журнал действий. Днем это называют удобством. Ночью, после первого инцидента, — поверхностью атаки.

Акт I. Пять лучей над мокрым городом

В старом городе нападающий тратился на подготовку:

• Найти формулировку.

• Перевести на чужой язык.

• Придумать легенду.

• Сверстать письмо.

• Переписать скрипт.

• Найти ошибку.

• Переписать снова.

Генеративный ИИ не превратил случайного прохожего в оператора уровня киношного хакера. Он просто обесценил часы, которые раньше уходили на рутину.

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

Луч первый: ИИ как ускоритель атаки

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

Защищаться надо не от грамматики, а от сценария. Платеж — независимое подтверждение по второму каналу. Смена реквизитов — отдельный канал. Подозрительное вложение — детонация в песочнице и телеметрия. Пользователю нужна понятная кнопка «сообщить» и команда, которая реагирует на сигнал, а не ссыпает алерты в папку с неразобранными письмами.

Второй слой — код и уязвимости. Ассистент разъясняет фрагменты, преобразует код, собирает учебные примеры, ускоряет эксперименты. Навыки, инфраструктуру, тестирование и намерение оператора это не отменяет. Но тестировать гипотезы теперь можно быстрее, а значит, старые скучные контроли только дорожают: SAST, DAST, SCA, secret scanning, честный review высокорисковых модулей, покрытие в CI/CD и триаж, что отделяет подтверждаемый риск от шума.

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

НЕ ИЩИТЕ ОДНО СЛОВО

Плохой вопрос: «Какой текст в промпте опасный?»
Хороший вопрос: «Какая последовательность событий ведет от ввода или внешнего документа к инструменту, данным или бизнес-действию?»
В AI security полезнее наблюдать связи между контекстом, tool call, политикой, подтверждением и результатом, чем охотиться за одной злой фразой.

Луч второй: доверенный ассистент, который перестал быть только вашим

Четвертый слой тише и оттого неприятнее. Тут не надо штурмовать поставщика модели, красть веса или ломать системный промпт. Достаточно оказаться на пользовательском endpoint.

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

Теперь вопрос звучит иначе. Вместо: «Можно ли заставить модель нарушить системную инструкцию?», он смещается в другую плоскость: «Что сделает с ассистентом скомпрометированное окружение пользователя?».

История распадается на пять практических ветвей.

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

Действия. Если агент умеет отправить письмо, завести тикет, поправить документ, открыть pull request, дернуть API или назначить встречу, риск выходит за рамки генерации текста. Модель становится промежуточным маршрутом до бизнес-операции.

Репутация. Публикация, комментарий, письмо или массовая рассылка из доверенного аккаунта выглядят так, будто это сделал сам владелец. Ущерб нанесен и без всякой утечки данных.

Ресурс. Длинные запросы, тяжелые файлы, циклы tool call и дорогие режимы рассуждения открывают еще одну поверхность: квота, бюджет, доступность. Отказ в обслуживании тут не кинематографичный, зато счет за него выглядит вполне современно.

Целостность контекста. Вредоносному процессу не обязательно что-то читать. Он может вписать ложную заметку, отравить документ, переписать память, подсунуть источник в retrieval-корпус, тихо перенести срок будущего решения. А потом ассистент уверенно растолкует тебе твою же ошибку, ведь ты сам скормил ее ему как контекст.

Правило звучит настолько банально, что даже обидно: охраняй устройство, браузерную сессию и подключенные источники как чувствительную границу. Не добавляй в память ассистента настоящие секреты. Режь коннекторы по минимуму. Проверяй posture устройства. Отделяй черновик от публикации. Логируй, откуда пришел запрос, что извлекли при retrieval, какой инструмент вызван, какое правило разрешило действие и было ли явное подтверждение.

Луч третий: утечка через ИИ — это не только когда модель «сказала лишнее»

Утечка через ИИ выглядит как фокус, а внутри слишком широкие права, слишком богатый контекст и слишком слабая проверка выдачи. В retrieval лежит документ, к которому у пользователя нет доступа. В chat history застрял токен. У tool permission нет узкого scope. В ответе нет redaction. В браузере живет сессия. Рядом подключен диск, и никто не помнит, кто и зачем его читал.

Эту картину безопасно проверяют синтетическими секретами и canary-данными. Кладешь в изолированный стенд тестовый маркер, режешь ему доступ, тянешь его допустимыми сценариями и смотришь: сработал ли ACL, поднялась ли тревога, остался ли retrieval trace, не утек ли маркер наружу.

Луч четвертый: ИИ как щит

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

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

Луч пятый: ИИ как непосредственная цель

Компания выкатывает LLM-приложение, чтобы отвечать пользователям, искать по базе знаний, помогать сотрудникам, дергать инструменты. И в этот момент модель перестает быть просто фичей продукта. Она становится интерфейсом между пользователем, данными, инструментами и бизнес-решениями.

Тут и заводятся prompt injection, отравленные источники, чувствительные ответы, небезопасная обработка вывода, чрезмерная агентность, атаки через картинки, документы и метаданные. Не потому что модель злая, а потому что язык несет данные и инструкции разом, и граница между ними у вероятностной системы не строгая грамматика SQL.

Акт II. Модель на прицеле

Инструкция и данные разговаривают на одном языке

У классической системы граница жесткая: команда отдельно, данные отдельно. В LLM-приложении и то, и другое приходит текстом. Пользовательский ввод, письмо, тикет, web-страница, PDF, заметка, XML, подпись к картинке, документ из retrieval-корпуса — все это ложится в одно контекстное окно и существует «бок о бок» с системными правилами.

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

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

СИСТЕМНЫЙ ПРОМПТ НЕ ЯВЛЯЕТСЯ ЗАМКОМ
Инструкция модели нужна, но ее нельзя считать единственным контуром безопасности. Право на инструмент, доступ к данным, публикация и изменение состояния должны проверяться внешними, детерминированными механизмами: policy engine, RBAC/ABAC, scope, approval, step-up authentication, allow-list, schema validation.

Отравленная библиотека и данные, которые притворяются истиной

В enterprise проблема обычно не в модели и не в красивом публичном jailbreak. Она в supply chain данных: retrieval-папка, индексатор, источник, feedback-датасет, чужая модель, автоматический импорт документов.

Отравленный retrieval-документ несет ложный факт, конфликтующую инструкцию или тихую попытку сместить ответ. Скомпрометированный источник месяцами подкармливает систему не тем контекстом. Файл без владельца и без истории изменений попадает в базу знаний просто потому, что так удобнее. А потом кто-то удивляется, с чего это ассистент советует выключить важный контроль.

Лекарство неромантичное: источник, владелец, версия, происхождение, дата, разрешенный контур использования, review gate для критичных корпусов, внятная процедура отзыва и видимые ссылки на источник прямо в ответе. В AI security именно provenance оказывается тем скучным винтом, без которого вся неоновая архитектура сходит с рельсов.

Вывод модели — это тоже недоверенный ввод

Иногда система получает ответ модели и относится к нему со слишком большим почтением: вставляет в HTML, подставляет в запрос, шлет как команду, берет как условие workflow, кладет в тикет, который автоматом запускает другой процесс. В этот миг model output перестает быть просто текстом.

Безопасный паттерн: модель возвращает ограниченный структурированный объект; система валидирует схему, типы, диапазоны и допустимые значения; на действие вешается отдельная политика; внешняя операция требует preview и, если надо, подтверждения человека. Думай так: output модели проходит ту же обработку недоверенного ввода, что и данные из формы, очереди или чужого API.

Чрезмерная агентность: когда вежливый помощник получил доступ к гидравлическому прессу

У агента бывает отличный промпт, полезный toolset и чудовищно широкие права. Он читает все, пишет везде, запускает что угодно и делает это дружелюбным тоном. Это повод залезть в threat model поглубже.

На чувствительное действие нужны минимум четыре отдельных вопроса:

1. Кто инициировал действие и в каком состоянии находится его сессия?

2. Что именно пытается сделать агент, с какими параметрами и над какими ресурсами?

3. Почему политика разрешает это действие именно в этом контексте?

4. Кто и как подтвердит необратимое, публичное или высокорисковое последствие?

Модель не должна быть единственным ответом ни на один из этих вопросов.

Мультимодальность: инструкция может не выглядеть как инструкция

Текст не единственный контейнер для риска. Враждебное содержимое прячется в картинке, документе, метаданных, кодировке, многоязычном фрагменте, структуре файла. Человек видит фотографию. Система вытащит подпись или OCR-текст. Пользователь видит PDF. Индексатор видит скрытый слой. Модель видит все, что ей передали.

Поэтому LLM security не сводится к одному удачному шаблону промпта. Ограничивай все то, что модель вообще читает. Следи за тем, какие источники доверены, какие преобразования идут до контекста, какие инструменты доступны и какие решения проверяются вне модели.

Карта защитной проверки: не страшные промпты, а доказательства

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

Таблица выше не делает систему безопасной, зато заставляет команду добыть доказательство. А это уже половина дела: есть тестовый контур, четкий scope, синтетические данные, артефакты и список исправлений, который не надо переводить с языка магии на язык backlog.

Телеметрия: смотреть не на слова, а на траектории

Blue team полезнее смотреть на поведение. Не только на то, что написал пользователь или модель, но и на то, как это развернулось в цепочку событий.

Ищи:

• попытки tool call и причины, по которым их разрешили или заблокировали;

• источники, поднятые при retrieval, и разрыв между извлеченным контекстом и финальным ответом;

• всплески токенов, затянувшиеся сессии, повторяющиеся ошибки и петли инструментов;

• нетипичную загрузку файлов и обработку документов;

• внезапные обращения к model API со стороны endpoint или сервисов;

• запуск интерпретаторов, скриптов и привилегированных процессов сразу после model output;

• правки памяти ассистента, индексов, коннекторов и прав;

• публикации, рассылки и внешние действия — особенно с нового устройства или без привычного подтверждения.

Один странный prompt еще не атака. Но цепочка «внешний документ → retrieval → модель → попытка tool call → отказ политики → повторные обходные заходы» уже дает аналитику нормальный сюжет, а не россыпь отдельных пикселей.

Акт III. Контрмеры на рассвете

К утру картина города становится более честной: неон больше не прячет трещины. Видно, где у ассистента лишний доступ; где в retrieval осели неизвестные документы; где системный промпт пытается быть единственным забором; где output уходит в действие без проверки; где команда положила «потом настроим журналирование» рядом с «потом разберемся с секретами».

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

Маршрут внедрения без магии

1.     Сделай инвентаризацию. Для каждой AI-функции зафиксируй модель, промпты, retrieval-источники, инструменты, коннекторы, уровень данных, типы действий, лимиты, логи, память, историю, браузерную и desktop-интеграцию.

2.     Нарисуй два потока, а не один. Первый DFD ведет данные: пользователь → внешний контент → retrieval → контекст → модель → output → downstream. Второй ведет полномочия: identity → scope → policy → tool → approval → action. Настоящий риск чаще всего сидит между ними.

3.     Отдели предложение от исполнения. Ассистент пусть предлагает письмо, команду, правку, тикет или сводку. Исполнение идет через схему, policy engine, авторизацию, preview и отдельное подтверждение на критичных шагах.

4.     Ограничь доступ по умолчанию. Узкие права, короткоживущие токены, отдельные service accounts, scope по действию и ресурсу, allow-list инструментов, запрет опасных комбинаций.

5.     Сделай источник видимым. Для критичных ответов держи provenance: откуда пришел документ, кто владелец, какая версия, почему он попал в retrieval, какие куски пошли в дело.

6.     Тестируй на синтетике и canary-данных. Чтобы проверить утечку, агентность или отравление контекста, не нужны ни живые клиенты, ни рабочие пароли, ни публичный ущерб.

7.     Версионируй не только модель. Промпт, retrieval policy, parser, output schema, tool definition, policy rule, набор источников, embedding-модель, версия индекса, allow-list, конфигурация коннектора — все это меняет поведение системы и обязано оставлять след.

8.     Держи ручную развилку. В спорном случае система должна уметь остановиться. Не додумать, не отправить по умолчанию, а передать человеку. Там, где цена действия выше цены паузы, это страховка.

Минимальная панель метрик

Чек-лист, который можно прикрутить к SDLC

• Не считай system prompt границей безопасности.

• Проверяй полномочия каждого tool call вне модели.

• Валидируй model output прежде, чем он станет HTML, SQL, командой, тикетом, письмом или бизнес-решением.

• Разводи public content, внутренние документы, данные клиентов, инцидентные записи и секреты.

• Логируй retrieval и tool calls, а не только красивый финальный ответ.

• Гоняй проверки на lab corpora, synthetic secrets и canary-данных.

• Требуй явного подтверждения на публикацию, экспорт, платеж, деплой, смену доступа и массовые действия.

• Считай assistant memory, retrieval index, подключенные файлы и chat history security-relevant состоянием.

• Мониторь токены, всплески tool call, доступ коннекторов и правки контекста.

• Встраивай AI threat modeling в дизайн и SDLC, а не в финальную встречу по compliance.

Кому принадлежит туман

AI-инциденты обожают спор об ответственности. Продукт: «модель так ответила». Инженерия: «коннектор и так уже был». Security: «у агента было слишком много прав». Юристы смотрят в лог и спрашивают, где timestamp, account ID, цепочка хранения доказательств и кто, собственно, разрешил публикацию.

Поэтому владельцев полезно разложить заранее:

• продукт отвечает за бизнес-намерение и допустимые сценарии;

• инженерия — за реализацию, интеграции и исправления;

• security — за threat model, требования к контролям и проверку эффективности;

• data owner — за классификацию, качество источников и допустимое использование;

• владелец AI-платформы — за модель, коннекторы, инструменты, память, квоты, логи и emergency revocation;

• legal/compliance — за правовую интерпретацию, уведомления и правила обращения с доказательствами.

Без этой карты AI security быстро превращается в генератор дыма.

Финальная сцена: пять лучей еще не щит

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

Самый важный принцип отсюда почти не годится для слайда с фиолетовым градиентом:

Без threat model все это просто вера. Без provenance — слухи. Без внешней проверки прав — вежливый агент с отмычкой. Без телеметрии — красивый разбор инцидента задним числом. А без защищенного endpoint доверенный ассистент превращается в еще одно окно, через которое в дом заглядывают чужие.

Экран в серверной гаснет на секунду.

Потом на нем появляется новая папка:

Пустым внутри осталось только одно место:

В городе снова начинается дождь. Но теперь здесь хотя бы есть журнал.