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

• Архитектура автономного агента и границы доверия
• Идентификация агента и делегирование полномочий
• Сценарии компрометации и злоупотребления доступом
• Архитектура контроля и порядок внедрения

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

Архитектура автономного агента и границы доверия​

Автономный ИИ-агент объединяет языковую модель, оркестратор, память, набор инструментов и механизмы доступа к внешним системам. Модель интерпретирует задачу и предлагает план. Оркестратор управляет состоянием выполнения, передает контекст и вызывает инструменты. Инструменты выполняют операции от имени агента: читают документы, обращаются к API, создают заявки, изменяют записи или запускают программный код. В корпоративной среде такой агент фактически становится отдельным субъектом доступа.

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

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

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

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

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

Идентификация агента и делегирование полномочий​

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

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

Предпочтительна модель zero standing privilege (отсутствие постоянных полномочий): агент не обладает постоянными правами доступа в состоянии ожидания. Полномочия выдаются только после запуска конкретной задачи, ограничиваются ее целью и сроком выполнения, а после завершения отзываются. После запуска задачи брокер доступа выдает краткоживущий токен или временную сессию. Срок действия, аудитория токена, перечень разрешенных ресурсов и операций, а также допустимые действия ограничиваются задачей. По завершении работы токен истекает или отзывается. Долгоживущие ключи, встроенные в системный промпт, переменные окружения без защиты или файлы конфигурации, создают риск повторного использования после компрометации.

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

NIST в опубликованных в октябре 2026 года принципах проектирования систем идентификации агентов выделяет связь агента с инициатором, сужение полномочий при делегировании и отсутствие постоянных привилегий как базовые ориентиры. Это проектные принципы, а не универсальный готовый стандарт сертификации. Организации могут использовать их при разработке собственной архитектуры IAM и проверять, что цепочка делегирования прослеживается от исходной задачи до последнего вызова инструмента.

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

Сценарии компрометации и злоупотребления доступом​

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

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

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

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

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

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

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

Архитектура контроля и порядок внедрения​

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

Следующий элемент — policy enforcement point (узел проверки и применения правил доступа), через который проходят все действия. Политика проверяет идентичность агента и инициатора, цель задачи, ресурс, метод, параметры, временное окно и лимит. Для операций с повышенным риском добавляют подтверждение независимого субъекта. Подтверждение должно относиться к конкретному действию и его параметрам: кто получит доступ, какие данные будут удалены, на какую сумму оформляется платеж. Общая кнопка «разрешить агенту работать» не обеспечивает осмысленного контроля.

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

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

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

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

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

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



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

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

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

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

Для каждого класса операций полезно определить уровень автономности. Чтение общедоступной справочной информации может выполняться без подтверждения, если объем выборки и источники ограничены. Создание черновика письма или заявки допустимо с последующей проверкой сотрудником. Отправка сообщения внешнему адресату, изменение прав пользователя, удаление данных, публикация кода и финансовые операции требуют отдельного согласования. Критерий определяется возможным ущербом, обратимостью действия, чувствительностью данных и сложностью восстановления. Уровни автономности закрепляют в политике и связывают с техническими настройками шлюза, чтобы модель не могла самостоятельно повысить категорию операции.

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

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

​

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