AI-агенты всё чаще получают доступ к продакшену, облакам, базам данных и внутренним API — то есть ведут себя не как чат-боты, а как привилегированные пользователи. Проблема в том, что людей компании проверяют через MFA, условный доступ и журналы входа, а машинные идентичности часто живут на длинных токенах и слишком широких правах.
Об этом пишет Dark Reading в колонке Рави Шармы, Senior IT Audit & Cybersecurity Leader в Pitney Bowes, опубликованной 28 сентября 2026 года. Его главный тезис простой и неприятный: автономный агент, который может выполнять действия, становится частью identity attack surface. И следующая крупная авария с агентным AI может выглядеть не как смешная галлюцинация модели, а как скучный, дорогой и очень реальный инцидент с доступами.
Компании уже привыкли считать сотрудников периметром риска. Вход с подозрительного IP? Проверка. Попытка обойти MFA? Сигнал в SOC. Доступ к чувствительным системам? Через роли, согласования и ревью. Но параллельно инженерные команды подключают AI-агентов к репозиториям, облачным сервисам, базам данных, пайплайнам деплоя и финансовым системам. Такие агенты обычно работают через non-human identities: сервисные аккаунты, API-токены, делегированные облачные разрешения. На бумаге это автоматизация. В реальности — ещё один субъект с правом менять состояние систем.
Самый опасный сценарий начинается не с «модель сказала ерунду». Он начинается с доступа. Например, команда создаёт агента для мониторинга инфраструктуры и выдаёт ему сервисный аккаунт с широкими AWS IAM-разрешениями: условные s3:* или слишком свободные пути sts:AssumeRole. Агент замечает замедление, меняет скрипт деплоя, запускает цепочку provisioning-действий в нескольких продакшен-средах — и внезапно бизнес получает простой, нарушение целостности данных или скачок облачных расходов. Никакого злого инсайдера в худи. Просто автоматизация, которой дали ключи от нескольких дверей сразу.
Для аудиторов и безопасников здесь особенно болезненна тема разделения обязанностей. В нормальном процессе один пользователь не должен одновременно инициировать, одобрять и выполнять действие с высоким риском. Разработчик не выкатывает код в прод без ревью. Менеджер склада не должен сам создать заявку на закупку и сам же её утвердить. AI-агент без границ ломает эту архитектуру: он может принять сигнал, выбрать действие, выполнить его и оставить в логах только машинный след, который не объясняет бизнес-контекст.
Шарма предлагает смотреть на AI-агентов не как на «интеграции», а как на привилегированные идентичности. Первый вопрос — чья это идентичность. Агент не должен работать под общим системным токеном, который используется ещё десятком сервисов и превращает расследование в археологию по логам. Для продакшен-агента нужна отдельная неинтерактивная учётная запись, короткоживущие токены и понятная привязка к конкретному процессу.
Второй вопрос — радиус поражения. Если агенту нужно читать записи из базы для отчёта, у него не должно быть прав на запись или удаление. Это звучит банально, пока в реальном проекте не появляется «временно дадим шире, потом сузим». В агентных системах такое «потом» особенно опасно: prompt injection может направить инструмент не туда, а лишние права позволят этой ошибке пройти дальше — уже в backend, хранилища или платёжные контуры.
Третий блок — владение риском и журналы. Если агент испортил таблицу, изменил конфигурацию или вывел данные наружу, ответственность не может висеть на «фреймворке» или безымянной библиотеке. Нужен владелец бизнес-процесса, который принимает риск автономных действий. Логи тоже должны быть богаче обычной cloud-телеметрии: важны не только API-вызовы, но и входной prompt, вызванные инструменты, ответ модели, решение policy engine и последующие действия во внутренних системах. Всё это — с ретеншеном и редактированием чувствительных данных, иначе аудит быстро превращается в новую утечку.
Отдельная ловушка — жизненный цикл. У человеческого сотрудника есть найм, перевод, увольнение, периодическая проверка прав. У AI-агента часто есть репозиторий, забытый проект и сервисный аккаунт, который пережил три реорганизации. Без регулярной сертификации доступов такие сущности становятся «зомби»-аккаунтами: уже никто не помнит, зачем они нужны, но токен всё ещё может ходить в продакшен.
Для русскоязычных IT-команд практический вывод не про запрет AI-агентов. Запретить их так же легко, как запретить Excel в финансах: красиво в политике, смешно в жизни. Но если агент читает код, создаёт тикеты, меняет инфраструктуру, запускает пайплайны или трогает клиентские данные, его надо заводить в IAM и PAM как полноценного участника системы. С отдельной ролью, минимальными правами, журналированием, владельцем и аварийной кнопкой отключения, которая не валит половину архитектуры.
Рынок сейчас быстро учится давать моделям руки: инструменты, API, доступы, workflow. Следующий этап взросления — научиться проверять эти руки так же внимательно, как проверяют руки администраторов, DevOps-инженеров и финансовых контролёров. Иначе первый крупный инцидент с AI-агентом будет расследоваться не вопросом «что модель ответила», а куда более неприятным: кто вообще разрешил ей это сделать.
