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

Искусственный интеллект всё активнее используется не только для генерации текстов и анализа информации, но и для выполнения реальных рабочих операций. Современные ИИ-агенты могут самостоятельно читать электронную почту, обращаться к корпоративным базам данных, обрабатывать счета, изменять записи в CRM и ERP, отправлять сообщения в мессенджеры и взаимодействовать с внешними сервисами. Такая автоматизация экономит время сотрудников, но одновременно создаёт совершенно новый класс рисков информационной безопасности.

Проблема заключается в том, что агенту часто предоставляют доступ к корпоративным ресурсам быстрее, чем организация успевает определить правила его эксплуатации. Сотрудник может создать автоматизацию с помощью конструктора без программирования, подключить несколько сервисов через OAuth и API-ключи, а затем запустить её в рабочей среде. При этом служба информационной безопасности может даже не знать о существовании нового участника корпоративной инфраструктуры.

Условный ИИ-агент, созданный сотрудником финансового отдела для обработки счетов, постепенно получает доступ к почте, ERP и Slack. Впоследствии злоумышленнику удаётся использовать обычное электронное письмо, чтобы заставить систему изменить банковские реквизиты поставщика.

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

Как обычный ИИ-агент получает доступ к корпоративным системам

Представим среднюю компанию, в которой сотрудник бухгалтерии решает автоматизировать обработку входящих счетов. Задача выглядит вполне разумно: агент должен проверять электронные письма, сопоставлять счета с данными в ERP и ежедневно отправлять сводку в Slack.

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

На первый взгляд всё работает правильно. Агент читает письма, извлекает суммы, проверяет данные и формирует отчёты. Однако за этой простой схемой скрывается несколько различных механизмов авторизации:

• Пользовательская сессия. Агент действует от имени сотрудника, используя его активную авторизацию в браузере или приложении.
• OAuth-разрешение. Пользователь один раз подтверждает доступ к определённым данным и операциям, после чего агент может использовать выданный токен до его отзыва или истечения срока действия.
• Статические учётные данные. API-ключи, пароли сервисных аккаунтов и другие секреты позволяют обращаться к системам без непосредственного участия человека.
• Отдельная идентичность агента. Специальная учётная запись или машинная идентичность, созданная для конкретного агента с ограниченными правами и контролируемым жизненным циклом.

В реальной инфраструктуре эти способы могут сочетаться. Например, агент использует пользовательский OAuth-токен для получения писем, передаёт задачу вспомогательному агенту, а тот обращается к MCP-серверу, который подключается к базе данных через общий сервисный аккаунт.

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

Поэтому безопасность ИИ-агента начинается не с выбора модели, а с понимания того, какие учётные данные он использует, от чьего имени действует и какие системы доступны через его инструменты.

Проблема № 1. Неуправляемые идентификаторы и избыточные права доступа

Первая проблема возникает ещё на этапе создания агента. Чтобы автоматизация заработала как можно быстрее, пользователь предоставляет ей собственные полномочия. Например, создаёт персональный API-ключ для ERP, который обладает теми же правами, что и его учётная запись.

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

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

Дополнительная опасность связана с длительным сроком действия токенов. OAuth-разрешение или API-ключ могут продолжать работать даже после того, как сотрудник сменил должность, перешёл в другой отдел или покинул компанию. При этом владелец автоматизации может уже не контролировать её работу.

Для устранения проблемы рекомендуется:

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

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

Проблема № 2. Отсутствие проверки безопасности перед запуском

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

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

В публикации BleepingComputer приводится принцип Rule of Two, связанный с рекомендациями команды безопасности Meta*. Его смысл состоит в том, чтобы до тех пор, пока prompt injection нельзя надёжно обнаруживать и нейтрализовать, не позволять одному агенту одновременно обладать всеми тремя следующими возможностями:

• A — недоверенный ввод. Агент читает письма, документы, веб-страницы и другие данные, содержимое которых может контролироваться внешними лицами.
• B — доступ к чувствительной информации. Агент может обращаться к закрытым корпоративным данным, финансовой информации, персональным сведениям или внутренним системам.
• C — возможность выполнять действия. Агент способен изменять данные, запускать операции, отправлять сообщения или взаимодействовать с внешними сервисами без предварительной проверки человеком.

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

Это не означает, что любой агент с двумя такими возможностями автоматически безопасен. Rule of Two — архитектурный принцип снижения риска, а не математическая гарантия защиты. Его задача — не допустить концентрации опасных возможностей в одной системе без дополнительных ограничений.

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

Проблема № 3. Prompt injection: вредоносные инструкции внутри обычных документов

Третья проблема — одна из наиболее характерных для современных ИИ-систем. Она связана с prompt injection, то есть внедрением инструкций, которые пытаются изменить поведение модели и заставить её действовать в интересах злоумышленника.

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

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

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

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

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

Защита от prompt injection должна строиться на нескольких уровнях:

• Считать внешние данные недоверенными. Любое письмо, вложение, веб-страница или документ должны рассматриваться как потенциальный источник вредоносных инструкций.
• Разделять данные и команды. Содержимое документов не должно автоматически получать тот же уровень доверия, что и системные инструкции разработчика агента.
• Ограничивать доступные инструменты. Даже если модель неправильно интерпретирует документ, она не должна иметь возможности самостоятельно выполнять критические операции.
• Проверять финансовые изменения отдельно. Смена банковских реквизитов, получателя платежа и других критичных параметров должна проходить независимую процедуру подтверждения.
• Сохранять происхождение данных. Важно фиксировать, из какого письма или документа получена информация и какие действия были выполнены на её основании.

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

Проблема № 4. Системы обнаружения не понимают, что агент ведёт себя подозрительно

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

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

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

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

В рассматриваемом примере можно выделить два подозрительных признака:

• Первое использование разрешённого инструмента. Агент три недели только читал информацию из ERP, но внезапно выполнил операцию изменения банковских реквизитов. Даже если действие разрешено, оно выходит за рамки привычного поведения.
• Новая последовательность операций. Ранее агент не выполнял цепочку «прочитать входящее письмо — изменить платёжные данные». Появление такой последовательности может свидетельствовать о манипуляции входными данными или изменении поведения системы.

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

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

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

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

Проблема № 5. Невозможно установить, кто именно разрешил действие

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

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

Для полноценного аудита недостаточно знать только название агента или учётную запись, от которой поступил API-запрос. Необходимо восстановить всю цепочку делегирования полномочий.

В частности, аудитору нужно установить:

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

Если эти сведения не записывались в момент выполнения операции, восстановить их задним числом может оказаться невозможно. Журнал ERP покажет персональный API-ключ, но не обязательно укажет, что запрос фактически сформировал ИИ-агент после обработки конкретного письма.

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

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

Почему традиционной защиты корпоративной инфраструктуры уже недостаточно

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

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

Показательна статистика исследования Cloud Security Alliance, упомянутого в исходной публикации. Согласно опросу 418 ИТ- и ИБ-специалистов, проведённому в январе 2026 года по заказу Token Security, 68% респондентов сообщили о высокой видимости ИИ-агентов в своих организациях. При этом 82% обнаруживали за предыдущий год агентов, о существовании которых ранее не знали.

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

Материал исследования доступен на сайте Cloud Security Alliance.

Как организовать безопасную эксплуатацию ИИ-агентов

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

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

1. Провести инвентаризацию. Найти всех действующих ИИ-агентов, включая созданных сотрудниками через сторонние конструкторы, интеграционные платформы и корпоративные приложения.
2. Назначить владельцев. Для каждой автоматизации определить ответственного сотрудника, бизнес-назначение и подразделение, которое использует систему.
3. Проверить права доступа. Убрать избыточные разрешения, заменить персональные ключи отдельными машинными идентичностями и ограничить возможности изменения критичных данных.
4. Оценить входные данные. Определить, какие письма, документы, веб-страницы и внешние источники обрабатывает агент. Считать их содержимое недоверенным.
5. Разделить чтение и выполнение операций. По возможности отделить получение информации от действий, которые изменяют финансовые, кадровые или административные записи.
6. Добавить подтверждение человека. Для платежей, изменения банковских реквизитов, удаления данных и других критичных операций предусмотреть независимое согласование.
7. Настроить мониторинг поведения. Отслеживать необычные вызовы инструментов, новые последовательности действий, нетипичные обращения к данным и изменения объёма активности.
8. Обеспечить аудит. Хранить историю действий агента, источники входных данных, сведения об инициаторе, использованных разрешениях и результатах выполнения.
9. Подготовить процедуру реагирования. Определить порядок приостановки агента, отзыва токенов, сохранения журналов и восстановления данных после инцидента.

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

Особое внимание следует уделить MCP-серверам и другим промежуточным компонентам. Они могут предоставлять агенту доступ к файловой системе, базам данных, API и командным инструментам. Если такой компонент настроен с избыточными полномочиями, ограничения самой модели не смогут обеспечить полноценную защиту. Критичные операции должны контролироваться на стороне инструментов и инфраструктуры, а не только с помощью текстовых инструкций.

Выводы

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

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

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

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

Часто задаваемые вопросы