Ключи доступа ИИ-агентов могут пережить самих агентов — и превратиться в непонятную строку в отчёте IAM, которую никто из платформенной команды не берётся объяснить. Для компаний, внедряющих автономные сценарии в разработке, поддержке и операциях, это не экзотическая угроза, а очередная версия старой проблемы: доступ выдан, владелец исчез, отзыв забыли.
На этот риск обращает внимание The New Stack в материале о том, как управлять учётными данными ИИ-агентов. Исходная ситуация выглядит узнаваемо для любого инженера безопасности: в облачном аккаунте или корпоративной системе остаётся сервисная учётная запись либо API-ключ. У него есть права, иногда вполне широкие, но происхождение доступа уже неясно: эксперимент закрыли, агент заменён другой версией, команда реорганизована, а запись в IAM осталась.
Разница между обычным сервисом и агентом в том, что жизненный цикл последнего часто особенно хаотичен. Агентов запускают для пилотов, временной автоматизации, обработки инцидентов, генерации кода, работы с внутренними базами знаний. Они могут появляться через low-code-инструменты, скрипты разработчиков или функции облачного провайдера — быстрее, чем платформа успевает добавить их в реестр систем. Если для выполнения задачи агенту выдали токен к Git-репозиторию, CRM, хранилищу документов или облачному API, этот токен не исчезает сам по себе вместе с чатом, контейнером или задачей в бэклоге.
Проблема не сводится к «плохой гигиене паролей». Неучтённый ключ лишает команду двух базовых ответов: кто отвечает за доступ и зачем он всё ещё нужен. Без них невозможно нормально применять принцип минимальных привилегий, расследовать подозрительную активность и уверенно проводить аудит. Атакующему при этом не обязательно ломать сложную защиту: достаточно найти действующую учётную запись, которую перестали мониторить и у которой слишком много разрешений.
Для платформенных команд здесь есть неприятный организационный нюанс. Традиционный процесс управления доступом обычно привязан к человеку, команде или давно известному приложению. Сотрудника увольняют — аккаунт отключают. Сервис выводят из эксплуатации — его владелец оформляет заявку на закрытие. С агентом такая связка часто отсутствует: владелец может быть не назначен, агент может быть частью цепочки автоматизации, а его идентичность — смешана с учётной записью инструмента, который его запускает.
Практический вывод — относиться к агенту как к полноценной рабочей нагрузке, а не как к временному помощнику в интерфейсе. Каждому агенту нужны отдельная идентичность, явный владелец, описание цели и ограниченный набор разрешений. Долгоживущие секреты лучше не раздавать по умолчанию: где возможно, безопаснее использовать краткоживущие токены, ролевой доступ и механизмы автоматического обновления учётных данных. Это не отменяет риск, но заметно сокращает окно, в котором забытый доступ остаётся полезным для злоумышленника.
Не менее важен процесс завершения работы. Удаление агента, остановка пилота или смена поставщика модели должны запускать проверку связанных учётных записей, секретов, интеграций и журналов. В идеале такие связи видны заранее в инвентаре: какой агент использует доступ, кто подтвердил выдачу, когда ключ применялся в последний раз и при каких условиях его следует отозвать. Если ответ приходится искать по чатам, тикетам и памяти одного инженера, контроль уже проигрывает автоматизации в скорости.
Для разработчиков это означает ещё одну обязанность при подключении агентных инструментов: не запрашивать «временный» токен с запасом прав. Для CISO и IT-директоров — повод включить агентные идентичности в существующие правила IAM, а не строить для них параллельный и менее строгий контур. Для продуктовых команд — ограничение, которое лучше принять заранее: быстрый пилот не должен оставлять после себя постоянный след в доступах к данным и инфраструктуре.
ИИ-агенты сделают автоматизацию доступнее, но не отменят дисциплину управления доступом. Напротив, чем больше задач компания делегирует программным исполнителям, тем ценнее становится простой вопрос в отчёте безопасности: кому принадлежит этот ключ и зачем он всё ещё активен?
