Наблюдаемая закономерность
Агентные системы всё чаще развёртываются для выполнения задач, требующих доступа к корпоративным данным: чтения репозиториев, запросов к базам данных, вызовов внутренних API. В операционных обзорах регулярно отмечается, что после завершения запуска агента его учётные данные остаются действительными. Агент больше не выполняется, но токен или ключ, который он использовал, по-прежнему предоставляет доступ. Это не проблема найма или отзыва доступа. Разрыв — между завершением задачи и истечением срока действия учётных данных.
В традиционных человеческих рабочих процессах доступ привязан к роли человека и периодически пересматривается. В агентных рабочих процессах доступ привязан к задаче, но жизненный цикл учётных данных часто наследуется от статических секретов или долгоживущих сервисных учётных записей. Результат — класс учётных данных, которые живут дольше работы, для которой они были выданы.
Почему TTL — неправильный примитив
Фиксированное время жизни — это догадка о том, сколько займёт задача. Запуски агентов неравномерны: они могут завершиться за секунды или приостановиться на минуты в ожидании ограничения скорости, одобрения человека или внешнего события. TTL, достаточно короткий, чтобы быть безопасным для быстрого запроса, истечёт в середине законной длительной задачи. TTL, достаточно длинный, чтобы покрыть худший случай, оставляет широкое окно ненужного доступа.
Долгоживущие агенты с чекпоинтами могут пережить любой разумный TTL. Когда агент сохраняет состояние и возобновляется позже, исходные учётные данные могут уже истечь, что вызывает их продление. Если продление автоматическое и не переавторизует задачу, учётные данные фактически продлеваются бесконечно. TTL становится формальностью: короткоживущие учётные данные, продлеваемые без проверки, — это постоянные учётные данные с лишними шагами.
Более глубокая проблема в том, что TTL измеряют время, а не полномочия. Они отвечают на вопрос «как долго?», но не «для чего?» или «под чьим контролем?». Агент, завершающий задачу за десять секунд, и агент, работающий десять часов, получают один и тот же класс учётных данных, только с разными метками времени истечения.
Привязка полномочий к запуску
Более надёжная модель привязывает учётные данные к идентификатору запуска и объявленной задаче. Вместо выдачи токена с фиксированным сроком действия оркестратор выдаёт учётные данные, действительные только пока запуск активен и только для операций, объявленных в спецификации задачи. Учётные данные — это не bearer-токен, который можно использовать где угодно; это capability, ограниченная конкретным запуском и конкретным набором действий.
Оркестратор как орган отзыва
Оркестратор, запускающий выполнение, должен также быть органом, способным отозвать учётные данные. Когда запуск завершается — по завершении, сбою или отмене — оркестратор помечает запуск как неактивный. Любые учётные данные, предъявленные с этим идентификатором запуска, отклоняются. Это инвертирует поведение по умолчанию: вместо опоры на истечение срока система опирается на живость. Нет активного запуска — нет действительных учётных данных.
Возобновление как новое событие авторизации
Когда агент возобновляется с чекпоинта, он начинает новый контекст выполнения. Оркестратор должен рассматривать это как новое событие авторизации: переоценить задачу, выдать новые учётные данные, ограниченные возобновлённым запуском, и потребовать те же проверки политики, что и для исходного запуска. Это не позволяет чекпоинту стать чёрным ходом для бессрочного доступа. Компромисс — дополнительная задержка и сложность: каждое возобновление влечёт цикл авторизации, и оркестратор должен хранить состояние о том, какие запуски активны. Для высокочастотных короткоживущих агентов эти накладные расходы могут быть приемлемы; для конвейеров, чувствительных к задержке, может потребоваться кэширование или предварительная авторизация для известных шаблонов задач.
Конкретный механизм: токены с областью запуска
Практическая реализация использует подписанный токен, который включает идентификатор запуска, область задачи и подпись оркестратора. Токен предъявляется точке применения политики (PEP), которая проверяет две вещи: подпись действительна, и идентификатор запуска помечен как активный в хранилище состояния оркестратора. PEP не полагается только на срок действия токена. Если оркестратор пометил запуск как завершённый, токен отклоняется, даже если его срок действия ещё не истёк. Этот механизм требует общего хранилища состояния между оркестратором и PEP, а также пути отзыва, достаточно быстрого, чтобы иметь значение. Компромисс — зависимость от доступности оркестратора: если хранилище состояния недоступно, PEP должен решить, открываться или закрываться при сбое. Закрытие при сбое безопаснее,
Обнаружение
Даже с учётными данными с областью запуска обнаружение необходимо. Журналы аудита должны быть инструментированы для выявления учётных данных, используемых после завершения выдавшего их запуска. Это простой запрос, если учётные данные несут идентификатор запуска: соедините журнал использования учётных данных с журналом жизненного цикла запусков и найдите события использования, где запуск завершился до метки времени использования.
Второй показатель — разрыв между последним вызовом инструмента и истечением срока действия учётных данных. В здоровой системе этот разрыв должен быть близок к нулю для завершённых запусков: учётные данные должны становиться недействительными, как только запуск завершается. Устойчивый разрыв указывает на то, что учётные данные живут дольше своих запусков — будь то через продление, кэширование или неспособность отозвать. Отслеживание этого разрыва во времени выявляет регрессии в пути отзыва.
Третий сигнал — частота событий возобновления, не запускающих повторную авторизацию. Если чекпоинты используются для продления доступа без нового события авторизации, это нарушение политики, которое должно быть видно в журнале аудита.
Операционная реальность
Внедрение учётных данных с областью запуска и отзыва на основе оркестратора не бесплатно. Оно требует изменений в том, как агенты запрашивают доступ, как оркестратор отслеживает состояние запусков и как точки применения политики проверяют учётные данные. Оно вводит зависимость от живости оркестратора и потенциальное узкое место в хранилище состояния. Для систем, уже имеющих центральный оркестратор с надёжным управлением состоянием, изменение инкрементально. Для систем, где агенты порождают суб-агентов или работают через несколько оркестраторов, синхронизация состояния усложняется.
Альтернатива — опора на TTL и периодические проверки — проще в реализации, но оставляет структурный разрыв. Разрыв не между наймом и увольнением; он между завершением задачи и истечением срока действия учётных данных. Закрытие этого разрыва требует отношения к учётным данным как к capability, привязанным к запуску, а не как к секретам с таймером.