Агентов не настраивают единожды и не оставляют без присмотра. Они проходят этапы создания, публикации, развёртывания и вывода из эксплуатации. Если идентичность не отслеживает всю эту дугу, она превращается в запись, которую сделали и забыли — именно так учётные данные переживают тех агентов, для которых были созданы.
Поэтому относитесь к идентичности как к жизненному циклу. Выдача учётных данных должна происходить строго в контрольной точке, а не хаотично, когда кому-то что-то понадобилось. Отзыв прав не сложнее их предоставления. Если запуск агента — один управляемый шаг, а его удаление требует заявки и недели ожидания, вы создали систему, накапливающую риски по умолчанию.
Контрольные точки — это минимум, а не предел
Точки предоставления и отзыва прав необходимы. Однако это не самая сильная реализация идеи. Более сильный вариант, к которому стоит стремиться в 2026 году, — полностью избавиться от постоянных привилегий.
Агент не должен хранить персистентные разрешения. Доступ должен выдаваться точно в срок, ограничиваться текущей задачей и освобождаться сразу после её завершения. Между задачами базовый доступ агента равен нулю. Разрешения появляются, когда есть работа, которая в них нуждается, и исчезают с окончанием этой работы.
Для людей такая модель была недостижимой мечтой последние десять лет. Своевременный доступ для сотрудников постоянно буксует: бизнес-процессы хаотичны, а людей раздражают задержки. Агенты меняют расчёт в обе стороны.
С одной стороны, проблема становится острее. Агенты плодятся тысячами. Они эфемерны. Постоянное разрешение, умноженное на парк такого размера и простаивающее большую часть времени, даёт зону поражения, на которую никто не соглашался.
С другой стороны, решение становится реальнее. Агент способен запросить учётные данные и освободить их программно, в потоке собственного выполнения, — так, как человеческие процессы никогда не смогут. Трение, убивающее своевременный доступ для людей, почти незаметно для программ. То, что было лишь стремлением для людей, становится рабочей реальностью для агентов.
Для практической реализации существует стандартная зацепка. Операции жизненного цикла — активировать, приостановить, отозвать, удалить — это именно то, что определяет спецификация OpenID Provider Commands. Вам не нужно изобретать глаголы управления идентичностью на всём её пути. Задача — привязать их к контрольным точкам вашей агентской платформы, чтобы выдача и отзыв прав были полноправными операциями, а не ручной уборкой.
Замкнуть цикл
Вот к чему привела вся эта серия материалов.
Всё началось с простого наблюдения. Агент недетерминирован. Невозможно предугадать, какие действия он предпримет в момент выдачи разрешений, поскольку он выбирает инструментарий во время выполнения на основе своего промта, контекста и результата того, что его вызвало. Этот единственный факт объясняет, почему заимствованные учётные данные подводят, почему область доступа должна быть узкой, цепочка делегирования — обозримой, а авторизация — находиться в контрольной плоскости, принимающей решения на лету.
Именно поэтому авторизация не может быть разовым актом на этапе проектирования. Нельзя заранее решить, что будет позволено субъекту, если он сам определяет свои действия только в процессе работы. Авторизация должна быть непрерывной и оцениваться во время выполнения применительно к той задаче, которая сейчас стоит перед агентом.
Жизненный цикл превращает это в рабочий механизм. Выдача прав точно в срок — это авторизация во время исполнения, выраженная через идентичность: агент получает ровно тот доступ, который нужен для этой задачи, в нужный момент и возвращает его. Отзыв прав — та же идея, но с обратной стороны. Непрерывная переоценка — это жизненный цикл, работающий параллельно с агентом, а не конфигурация, которую один раз задали и забыли.
Идентичность агента, для которой нельзя на лету выдать права, ограничить их, отозвать и переоценить в рамках чёткого жизненного цикла, — это не идентичность. Это обуза с приклеенной биркой.
Что делать дальше
Возьмите одного агента, уже работающего в вашем окружении. Последовательно задайте ему пять вопросов.
- Имеет ли он собственную идентичность или заимствует человеческую?
- Соответствуют ли его разрешения решаемой задаче или унаследованы целиком и без разбора?
- При вызове инструмента или другого агента сохраняется ли цепочка делегирования или она схлопывается в перевыпущенный токен?
- Принимаются ли решения об авторизации во время выполнения контрольной плоскостью или жёстко закодированы на этапе развёртывания?
- Можете ли вы выдать права, ограничить их и отозвать в рамках чёткого жизненного цикла или перед вами статическая запись, которую кто-то однажды создал и забросил?
Там, где ответ окажется неудовлетворительным, вы нашли, что нужно исправить в первую очередь. Начните с агента, способного нанести наибольший ущерб, и двигайтесь вниз по списку.