Назад в блог

Governance флота AI-агентов: политики, квоты и жизненный цикл в enterprise

Как управлять флотом из сотен AI-агентов: инвентарь, владелец, policy as code, квоты и жизненный цикл create→review→revoke. Модель зрелости и RACI для enterprise.

Иллюстрация к материалу: Governance флота AI-агентов: политики, квоты и жизненный цикл в enterprise

Один агент — пет-проект одной команды. Сто агентов — флот без владельца, без квот и без понимания кто за что отвечает. Масштаб ломает не модель, а управление: где реестр, какие политики применяются, сколько стоит вызов и когда агент должен умереть. Governance флота отвечает на эти вопросы до того как инцидент ими займется.

От пилота к флоту: что ломается

На пилоте хватает чата и токена. На флоте появляются:

  • дублирующие агенты с разными версиями одного инструмента;
  • агенты без владельца после ухода автора;
  • агенты с безлимитным доступом к прод-системам;
  • отсутствие ответа на базовый вопрос аудитора: «какие агенты имеют доступ к PII и на каком основании».

Без governance каждый новый агент увеличивает не ценность, а площадь атаки и стоимость владения. Gartner прогнозирует что к 2028 треть enterprise-приложений будет содержать агентику — инфраструктура governance должна появиться раньше, чем флот.

4 вопроса governance

Для каждого агента должны быть ответы:

  1. Что существует? Инвентарь: агент, версия, какие MCP/инструменты, какие данные, какое окружение, какой human delegator.
  2. Кто владелец? RACI: владелец (Accountable), операторы (Responsible), потребители (Consulted), аудит (Informed). Нет владельца — нет ревью доступа.
  3. Что может? Политика как код: Cedar/OPA-правила principal, action, resource, context с deny по умолчанию, scoped инструменты, разделение чтения и действий.
  4. Когда умирает? Срок жизни, условия продления, процедура offboard: отзыв NHI, удаление секретов, архивация аудита.

Эта четверка — минимальный evidence pack для SOC 2, HIPAA, 152-ФЗ и страховщика, который уже задает AI-вопросы.

Модель: инвентарь → политики → квоты → аудит

Инвентарь. Реестр агентов как CMDB: кто создал, зачем, какие инструменты, какие секреты через брокер (не в конфиге), какая классификация данных. Тень ищется тем же стеком что и shadow AI — если агента нет в реестре, он вне governance.

Владелец и RACI. У каждого агента — владелец из бизнеса или платформы. Смена владельца — событие с переоценкой прав, уход владельца — триггер ревью.

Policy as code. Политики версионируются, симулируются и применяются на каждый tools/call через шлюз, а не раз при выдаче токена. Чтение отделено от действий, необратимые операции — с human-in-the-loop.

Квоты и лимиты. На агента, на инструмент, глобально: tools/call в час, стоимость LLM-вызовов, размер контекста, egress. Квоты защищают от петель и runaway costs и делают бюджет предсказуемым.

Аудит. Единый журнал: кто (агент + delegator), что вызвал, с какими аргументами, что вернулось, какая политика сработала, сколько стоило. Экспорт в SIEM, ретеншен по классу данных.

Жизненный цикл: create → review → revoke

  • Create. Заявка с владельцем, scope, классификацией данных, оценкой рисков и выбором инструментов из одобренного каталога. Секреты — через брокер, не в репозиторий.
  • Operate. Агент работает через шлюз, политики и квоты применяются на каждый вызов, логи пишутся в единый аудит.
  • Review. Периодический пересмотр: нужен ли агент, актуальны ли инструменты, не вырос ли scope. Триггер — квартал или смена владельца/данных.
  • Revoke. Агент выключен — NHI отозвана, секреты удалены, сессии завершены, аудит заархивирован. Проверка что credential не остался в логах или бэкапах (persistent blast radius).

Между review и revoke помогает следующий слой — guardian agents: агенты-наблюдатели, которые отслеживают поведение флота, ищут аномалии и содержат действия операционных агентов. Но и у guardian должна быть своя scoped идентичность и аудит — иначе наблюдатель становится новой точкой атаки.

Уровни зрелости

  • L1 Базовый. Есть реестр и владельцы, секреты в Vault, аудит собирается, отзыв ручной (<24ч).
  • L2 Управляемый. Policy as code на шлюзе, short-lived credentials, квоты по агенту/инструменту, ревью по расписанию, offboard в день.
  • L3 Автоматизированный. Инвентаризация shadow-агентов, симуляция политик до деплоя, just-in-time secretless доступ, guardian agents, экспорт evidence для комплаенса в один клик.

Переход на следующий уровень дешевле чем расследование инцидента без ответов на четыре вопроса.

Где Codenik: control plane флота

Codenik — control plane для флота: реестр агентов и инструментов с владельцами, каталог одобренных MCP, Cedar-политики и квоты на каждый tools/call, брокер секретов без локальных токенов, session governance и единый аудит с OTel-экспортом. Добавление агента — процедура с scope и сроком жизни, а не копирование конфига. Offboard — одна операция в шлюзе.

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

Флот без governance — это сотня пет-проектов с прод-доступом. Начните с реестра и владельцев, переведите политики в код на шлюзе, введите квоты и жизненный цикл с обязательным отзывом. Тогда масштаб агентов дает скорость, а не хаос.

Источники и дальнейшее чтение