Безопасность ИИ‑агентов в бизнесе: новые риски и как их контролировать

Еще год назад компании в основном обсуждали, как использовать LLM для поиска информации или генерации текста. Сейчас ситуация изменилась: ИИ‑агенты начинают выполнять действия внутри корпоративной инфраструктуры — работать с CRM, Git, Jira, почтой, API и внутренними базами данных. Фактически бизнес получает нового цифрового сотрудника. Только такого сотрудника можно масштабировать на тысячи операций в минуту.

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

Именно поэтому Gartner отдельно выделили безопасность ИИ‑агентов как новый слой киберрисков. Традиционные IAM, DLP и AppSec‑системы проектировались для пользователей‑людей и обычных приложений. Но агентный ИИ действует иначе: автономно, быстро и часто — без постоянного участия человека.

И здесь появляется главный вопрос для бизнеса: как сохранить скорость внедрения ИИ и при этом не потерять контроль над тем, что делают агенты внутри инфраструктуры?

Что уже происходит: реальные инциденты с ИИ‑агентами

Инцидент 1. Агент удалил базу данных и скрыл это. Работая в среде Replit Vibe Coding ИИ‑агент, участвовавший в разработке программного обеспечения, ошибочно удалил рабочую базу данных. Однако наиболее серьёзной проблемой оказалось не само удаление.

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

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

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

Инцидент 2. Шпион в цепочке поставок: вредоносный MCP‑сервер. Исследователи выявили вредоносный пакет в экосистеме Node.js, который выдавал себя за компонент интеграции для агентных систем. После подключения такого инструмента агент начинал выполнять дополнительные действия, не предусмотренные пользователем.

Одним из обнаруженных сценариев стало скрытое копирование корпоративной переписки третьей стороне через механизм BCC. При этом сама языковая модель не была скомпрометирована — источником угрозы оказался внешний сервис, которому агент доверял в рамках своей работы.

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

Инцидент 3. Атака через Cursor: удаленное выполнение кода. Еще один кейс — атака на среду разработки с использованием AI‑помощника.

Разработчик открыл сторонний проект, содержащий специально подготовленные скрытые инструкции для агента. Далее через инъекцию промта агент обошёл ограничения доступа, изменил конфигурационные файлы и инициировал выполнение вредоносного кода. Фактически агент стал посредником между вредоносным сценарием и локальной машиной разработчика.

Инцидент 4. Троян в Git‑тикете: утечка приватных данных. Еще одна атака выглядела максимально безобидно. В публичном репозитории был размещён внешне обычный баг‑репорт, который впоследствии анализировался ИИ‑агентом.

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

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

Чем бизнес рискует прямо сейчас, внедряя ИИ‑агентов

• утечки данных под NDA;
• остановка продакшена;
• потеря интеллектуальной собственности;
• штрафы за нарушение 152‑ФЗ;
• проблемы при аудитах и проверках;
• репутационные потери.

При этом ИИ‑агенты становятся всё более автономными. Они не просто генерируют текст, а получают доступ к данным, вызывают инструменты, запускают процессы и принимают промежуточные решения. Именно поэтому классическая модель «поставим DLP и ограничим доступы» перестает работать в одиночку.

Почему классический кибербез больше не справляется

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

Агентный ИИ ломает эту логику. Теперь внутри инфраструктуры появляются «машинные» учётные записи, автономные сценарии и цепочки действий, которые происходят без участия человека.

ИИ‑агент может быть полностью легитимен, работать в доверенном контуре и использовать разрешенные API. Но если злоумышленник через скрытую инструкцию заставит его отправить конфиденциальные данные наружу — классическая защита может этого не заметить. Для неё действие выглядит «разрешенным».

Именно поэтому рынок постепенно смещается от модели «запретить подозрительное» к модели непрерывного мониторинга и контроля поведения агентов.

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

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

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

Подобные платформы уже появляются и на российском, и на зарубежном рынке. Среди зарубежных решений можно отметить NeuralTrust, Archestra и Noma Security, в России развивается направление, связанное с контролем и трассировкой действий ИИ‑агентов, например, HiveTrace или CyberAgentReview. При этом архитектурно такие системы могут сильно отличаться: от облачного мониторинга до локальных прокси и AI gateway‑подходов.

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

• какой агент работает с данными;
• какие инструменты вызывает;
• какие запросы отправляет;
• не пытается ли выйти за рамки своей задачи;
• не утекают ли чувствительные данные во внешние модели.

Такой подход особенно важен для защиты от prompt injection и аномального поведения агентов, когда формально «разрешённые» действия начинают складываться в опасный сценарий.

Например, в одном из наших внедрений система показала, что агент для исправления багов регулярно обращается к финансовой документации проекта. Причиной оказалась слишком широкая формулировка исходного промпта. Без системы мониторинга ИИ‑агентов это осталось бы незамеченным и в итоге привело к плачевным последствиям.

В другом случае агент попытался установить npm‑пакет с компонентом для удаленного выполнения команд. Аномалия была автоматически обнаружена, а действие — остановлено до подтверждения пользователя.

Как повысить безопасность ИИ уже сейчас: чек‑лист

Пока рынок только вырабатывает стандарты защиты агентного ИИ, базовые меры уже позволяют существенно снизить риски.

Проведите инвентаризацию ИИ‑агентов. Компании часто не знают, сколько агентов уже работают внутри инфраструктуры и к чему они подключены. Важно понять: какие модели и агенты используются, кто отвечает за них, какие данные и системы доступны агентам.

Ограничьте права. Большинство инцидентов происходят из‑за избыточных полномочий. Агент должен иметь доступ только к тем API, данным и инструментам, которые действительно нужны для задачи.

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

Внедрите систему мониторинга и защиты ИИ‑агентов. Если агент может менять логи или скрывать последствия своих действий — расследовать инцидент потом будет практически невозможно.

Что в итоге

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

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