Важна не доля активности
Отчёты о парках агентов обычно подаются как статистика активности: большинство агентов спят, гласит заголовок, но при этом сохраняют учётные данные и открытые соединения. Цифра активности — наименее интересная часть этого предложения. Операционный факт — сохранение прав: учётные данные переживают работу.
Материалы, стоящие за этой формулировкой, стоит прочитать напрямую (один источник и другой). Ни один из них не меняет базовый механизм: агент, который месяцами не вызывал инструмент, по-прежнему предъявляет действительный токен каждой нижестоящей службе, которой когда-либо был предоставлен доступ.
Спящее состояние — артефакт развёртывания, а не проектное решение. Прототипы, которые так и не продвинули. Сезонные задачи, чей сезон прошёл. Интеграции, заброшенные после смены поставщика. Заменённые версии агента, развёрнутого под новым именем, потому что в консоли это проще, чем миграция. Ничто из этого не должно было сохраняться. Оно сохраняется потому, что ничто в конвейере не принуждает к терминальному состоянию. Создание — это кнопка; вывод из эксплуатации — это проект.
На границе ресурсов — в API-шлюзе, роли базы данных, тенанте SaaS — простаивающий принципал с действительным токеном неотличим от активного. Токен действителен, область действия присутствует, вызов проходит. Различить их может только запись жизненного цикла, а в большинстве парков такой записи не существует в форме, доступной для машинного запроса.
Почему агенты деградируют иначе, чем сервисные учётные записи
Сервисная учётная запись — обычно один учётный данные с одной областью действия, выданные командой платформы и ротируемые по расписанию. Полномочия агента — это композит, и каждый элемент работает по своим часам:
- ключ провайдера модели, часто общий для нескольких агентов и потому никогда не ротируемый ради какого-то одного из них;
- учётные данные инструментов — пароль базы данных, внутренний ключ API — подготовленные при сборке и забытые при развёртывании;
- нижестоящие OAuth-гранты, которые имеют собственный срок действия и поведение обновления и часто хранятся в хранилище токенов, которое никто не инвентаризирует;
- область действия делегатора, когда агент действует от имени человека и наследует всё, до чего этот человек мог дотянуться в момент согласия.
Поскольку они истекают независимо, композит почти никогда не истекает как единое целое. Ключ модели ротируется, OAuth-грант обновляется незаметно, пароль базы данных остаётся. Агент выглядит обслуживаемым. Это не так: это набор учётных данных в разных стадиях распада, и ни одно представление не показывает их объединение.
Второе отличие — происхождение. Агентов регулярно создают команды вне платформенной функции через консоли, рассчитанные на низкое трение. Это правильный дизайн для внедрения и неправильный для инвентаризации. Число принципалов растёт быстрее числа владельцев, и разрыв между этими двумя кривыми и есть экспозиция.
Отзыв как плановый контроль
Если относиться к отзыву как к проекту по очистке, он гарантированно повторится. Очистка — это событие с началом и концом; очередь заявок пополняется на следующей неделе после её закрытия. Контроль должен быть плановым процессом с исходом по умолчанию.
Истечение — это исход по умолчанию. Определите порог неактивности для каждого класса агентов — интерактивные ассистенты, плановые задачи, обработчики событий — и сделайте порог триггером автоматической приостановки учётных данных, а не заявкой на чью-то проверку. Повторная авторизация — это явное действие; продолжение полномочий — то, что требует обоснования. Значения порогов — решение политики для каждой организации; важен механизм.
Владелец и назначение — предварительные условия. Агента нельзя создать без названного владельца и заявленного назначения, и нельзя повторно авторизовать, если оба условия больше не выполняются. Это небольшое изменение схемы с большим эффектом: инвентарь становится самоописывающимся, а осиротевшие принципалы проваливают проверку по построению, а не по результатам аудита.
Срок жизни учётных данных отделён от срока жизни процесса. Учётные данные должны истекать по своему расписанию независимо от того, работает ли агент. Привязка истечения к жизненному циклу контейнера означает, что остановленный процесс бессрочно хранит действующий секрет — именно тот сбой спящего состояния. Краткоживущие токены, выдаваемые на каждый вызов, при том что долгоживущий секрет хранится в брокере, которого агент никогда не видит, полностью устраняют сохранение.
События отзыва попадают в тот же журнал аудита, что и действия агента. Большинство журналов аудита фиксируют, что делал принципал. Немногие фиксируют, когда полномочия были отозваны, каким процессом, по какой версии политики. Если журнал показывает только использование, следователь не может отличить агента, который молчал, от агента, чьи полномочия отозваны, — и не может доказать, что отзыв вообще произошёл.
Минимальная запись об отзыве выглядит так:
{
"principal_id": "agent:invoice-recon-v3",
"event": "credentials_revoked",
"reason": "inactivity_threshold_exceeded",
"last_successful_tool_call": "2025-01-14T09:22:07Z",
"grants_revoked": ["oauth:ledger.read", "db:recon_rw"],
"owner": "finance-ops",
"policy_version": "reclamation-v4",
"reauthorisation_path": "ticket:OPS-2214"
}
Компромисс реален, и его следует обозначить прямо. Агрессивный отзыв ломает работу. Сезонные задачи провалятся в свой сезон, если никто их не переавторизовал; прототип, переданный партнёру, остановится посреди демонстрации; дежурный инженер проведёт вечер, перевыпуская гранты. Издержки несут люди, немедленно, а выгода — неслучившееся нарушение, невидимо. Именно эта асимметрия приводит к тому, что отзыв деградирует, если он не автоматизирован, а его сбои не сделаны громкими и дешёвыми в исправлении — путь самопереавторизации, занимающий минуты, а не комитет по изменениям.
Что измерять
Важное измерение — не здоровье контейнера.
Последний успешный вызов инструмента на учётные данные, а не последний heartbeat на процесс. Работающий контейнер может не делать ничего полезного, держа действующий грант; остановленный может держать тот же грант вообще без процесса для наблюдения. Учётные данные — единица риска, значит, учётные данные — единица измерения.
Нижестоящие гранты как полноценные элементы инвентаря, каждый со своим владельцем и сроком действия, связанный с агентом, который их держит. Это единственный способ ответить, до чего агент может дотянуться, не читая четыре системы и не гадая.
Оповещения о дрейфе наборов грантов. Принципал, чьи разрешения изменились без соответствующей записи об изменении, — это либо ошибка конфигурации, либо вторжение, и без записи их не отличить. Оповещайте о дельте, а не об абсолютной области действия.
Правило проектирования
Каждый принципал-агент должен по запросу отвечать на три вопроса: кто им владеет, до чего он может дотянуться и когда истекают его полномочия. Не в вики, не в таблице, которую ведёт тот, кто его создал, — в системе, которая выдаёт учётные данные, доступной для запроса тем же инструментам, что аудируют его действия.
Если любой из этих ответов требует, чтобы человек восстановил его по памяти, истории чата или поиску по репозиторию, парк несёт необъявленный риск. Спящие агенты не исключение из этого правила. Они — причина его существования: агент, переставший действовать, всё ещё принципал, а принципал без жизненного цикла — это учётные данные без владельца.