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

С AI-агентами компании нередко потупают иначе.

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

Проблема здесь не только в искусственном интеллекте. Это архитектурная ошибка управления доступом.

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

AI уже не только отвечает. Он действует

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

AI-агент меняет саму природу риска.

Он может не только предложить письмо, но и отправить его. Не только написать код, но и открыть pull request или запустить deployment. Не только проанализировать заявку, но и изменить её статус, заказать услугу, обновить права доступа или инициировать платёж.

NIST отдельно выделяет переход от генерации контента к выполнению действий — вплоть до развёртывания кода в production — и указывает, что рост автономности увеличивает масштаб и диапазон потенциальных последствий. (nccoe.nist.gov)

В декабре 2025 года OWASP выпустил Top 10 for Agentic Applications. Среди ключевых категорий риска — захват поведения агента, эксплуатация инструментов, а также злоупотребление идентичностью и привилегиями. Это важный сдвиг: индустрия начинает обсуждать не только безопасность модели, но и полномочия системы, которая способна действовать. (OWASP Gen AI Security Project)

Именно поэтому вопрос «насколько хорошо отвечает модель?» постепенно уступает место другому:

что именно эта система может сделать, от чьего имени и кто остановит её при ошибке?

Главная ошибка — спрятать агента за пользователем

Самый удобный путь интеграции — позволить агенту использовать учётную запись сотрудника.

Пользователь авторизовался в приложении, агент получил его токен и начал работать с корпоративными системами «от его имени». Технически решение может выглядеть простым. С точки зрения безопасности оно создаёт сразу несколько проблем.

Во-первых, исчезает достоверная атрибуция действий.

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

Во-вторых, агент наследует слишком широкий контекст доступа.

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

В-третьих, невозможно независимо остановить агента, не блокируя самого пользователя.

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

AI-агент нельзя прятать за учётной записью пользователя или общим API-ключом. Автономная система должна быть самостоятельным и наблюдаемым субъектом доступа.

Агенту нужна собственная identity Отдельная identity не означает, что AI-агента нужно искусственно превращать в сотрудника или создавать для каждого агента обычную пользовательскую учётную запись.