Жизненный цикл AI-агента: от онбординга до отзыва доступа

AI-агента заводят за минуты: дали токен, подключили MCP-сервер — и он уже ходит в Jira. А снимают — забывают. Через полгода в компании десятки агентов, и никто не помнит, какие из них всё ещё имеют доступ в прод, чьи токены истекли, а чьи — нет. Висячий агент с непогашенным refresh-токеном — это бывший сотрудник, у которого не забрали пропуск.

Жизненный цикл агента должен быть таким же явным, как у сотрудника: онбординг, эксплуатация, ротация, офбординг.

Агент как сотрудник — почему нужен lifecycle

Модель «агент = скрипт» ломается на масштабе. Агент — долгоживущий субъект с идентичностью, правами и секретами. Его создают, ему выдают доступы, он работает, его права меняются, его отключают. Без явного lifecycle каждый этап делается руками и забывается.

Последствия — классика: избыточные привилегии, неотозванные токены, серверы без владельца. OWASP MCP Top 10 прямо называет неотозванные и избыточные доступы одним из топ-рисков.

Онбординг: каталог, владелец, scope, версия

Онбординг — не «вставил ключ», а запись в каталоге:

Идентичность: Client ID Metadata Document (с 2026 — предпочтительно) или DCR, с верифицируемым URL — чтобы IdP знал, кто это;
Владелец: человек, который отвечает за агента и его доступы;
Scope: только нужные на старте, из WWW-Authenticate или scopes_supported — по принципу наименьших привилегий;
Версия и hash описаний: чтобы ловить rug pull при обновлении сервера.

Без владельца и версии онбординг — это тень, которую потом некому отзывать. Храните запись в репозитории с ревью, как любую инженерную политику.

Эксплуатация: ротация и scope upgrade

Агент живёт долго — секреты и scope должны меняться:

Ротация секретов: короткоживущие токены + refresh, хранение по OAuth 2.1 §4.3, refresh_token в grant_types. Чем короче жизнь access-токена, тем меньше окно после компрометации.
Scope upgrade: когда сервер отвечает 403 insufficient_scope с WWW-Authenticate: Bearer scope="...", клиент делает step-up — проситunion старых и новых scope, а не «всё сразу» на старте.

С 2026 клиент обязан поддерживать оба discovery-механизма (RFC 8414 и OIDC Discovery) и слать resource (RFC 8707) на обоих этапах — иначе audience не привяжется и токен станет skeleton key для другого сервиса.

Аудит на каждом этапе

Каждый переход lifecycle — событие аудита:

кто создал агента и с какими scope;
когда и кто расширил scope;
когда ротировали секрет;
кто и когда отозвал доступ.

Без этого офбординг превращается в «кажется, отключили», а инцидент — в «не знаем, чей это был агент». Журнал должен связывать identity, scope, ресурс и время — то, что требует и MCP-спека, и любой комплаенс.

Офбординг: отзыв в одном месте

Офбординг — это отзыв всего, что было выдано:

отозвать access и refresh токены у authorization server;
удалить запись из каталога и закрыть scope;
проверить, что ни один downstream-сервис не принимает старый audience через passthrough.

Если секреты жили на ноутбуках, офбординг — обход команды. Если они жили в централизованном шлюзе — одна операция. Чем больше агентов, тем дороже ручной обход и тем важнее единая точка отзыва.

Чек-лист против висячих доступов

У каждого агента есть владелец и запись в каталоге?
Scope выдан по WWW-Authenticate / scopes_supported, а не «всё»?
Токены короткоживущие, refresh хранится конфиденциально?
Есть ротация по расписанию и по событию?
Офбординг отзывает и access, и refresh, и чистит каталог?
Аудит покрывает создание, расширение, ротацию и удаление?

Если хотя бы один пункт «нет» — у вас уже есть висячие доступы, просто вы о них не знаете.

Где Codenik: lifecycle как управляемый слой

Codenik держит жизненный цикл агента целиком: provision через каталог с владельцем и версией, выдача узких scope, ротация и отзыв секретов в одном месте, аудит каждого перехода. Агент получает доступ не как «ключ на ноутбуке», а как управляемая запись с жизненным циклом.

Так онбординг и офбординг становятся операциями, а не проектами. Подробнее про каталог — в статье «Каталог MCP-инструментов», про секреты — в «Централизованное хранение секретов».

Короткий вывод

Относитесь к агенту как к сотруднику: заведите явный lifecycle — онбординг с владельцем и scope, ротация и upgrade в эксплуатации, аудит каждого шага и офбординг с отзывом всего. Без этого масштаб превращается в зоопарк висячих токенов.

Единая точка управления делает lifecycle исполнимым: создали один раз по процессу, отозвали один раз везде.