Глава 27. Инвентаризация агентов, реестр и борьба с разрастанием¶

1. Почему почти у каждой успешной агентской программы появляется разрастание¶

Как только первые агентские системы доказывают полезность, в организации обычно начинается одна и та же история:

• одна команда делает агента поддержки;
• другая делает внутреннего агента знаний;
• третья добавляет ассистента рабочего процесса;
• четвертая быстро собирает узкоспециализированного агента под локальную задачу.

Сами по себе эти решения могут быть разумными. Проблема начинается позже, когда никто уже не может быстро ответить:

• сколько агентов вообще существует;
• какие из них работают в промышленной среде, а какие “временные”;
• кто их владелец;
• какие возможности у них есть;
• какие идентичности, соединители и принципалы инструментов они используют;
• какие из них вообще еще живы;
• какие из них все еще держат приостановленные подтверждения, фоновые маршруты, устаревшие пути контрактов или устаревшие контракты проверяющего.

Именно это состояние и стоит называть разрастанием агентов.

Слой реестра нужен здесь прежде всего для одной вещи: сделать весь контур подотчетным.

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

Эта глава отвечает на один вопрос: как инвентарь и реестр превращают набор агентоподобных сущностей в подотчетный производственный контур.

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

2. Почему разрастание опасно не только организационно¶

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

Но на практике разрастание быстро превращается в усилитель риска:

• осиротевшие агенты продолжают жить без владельца;
• устаревшие агенты сохраняют доступ к системам и данным;
• разные команды по-разному трактуют подтверждения и границы политик;
• покрытие наблюдаемостью становится фрагментарным;
• дрейф инвентаря делает шлюзы выпуска и разбор инцидентов менее надежными.

Microsoft прямо связывает это с состоянием безопасности: неполный инвентарь и непрозрачные агентские контуры приводят к слепым зонам, непоследовательному применению правил и запоздалому обнаружению.¹²

Та же базовая дисциплина хорошо совпадает с NIST SP 800-53: инвентарь должен быть полным, обновляемым и привязанным к accountability, иначе контроль быстро становится декоративным.³

3. Инвентарь и реестр — не одно и то же¶

Полезно различать два слоя:

• инвентарь агентов — полный список агентных и агентоподобных сущностей;
• реестр агентов — управляемый список признанных и подотчетных агентов.

Инвентарь отвечает на вопрос:

• какие агентоподобные сущности вообще существуют в нашей среде.

Реестр отвечает на более строгий вопрос:

• какие из них признаны, классифицированы, управляются и допускаются в производственные контуры.

То есть:

• инвентарь нужен для полноты видимости;
• реестр нужен для управления.

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

4. Что должно быть в минимальной записи агента¶

Минимальная запись в реестре для производственной агентской системы обычно должна включать:

• agent_id;
• команду-владельца;
• бизнес-назначение;
• состояние жизненного цикла;
• разрешенные возможности;
• идентичность среды исполнения;
• принципалы инструментов;
• требования к подтверждениям;
• владельцы для приостановленных запусков, фоновых запусков и сессий возможностей;
• статус наблюдаемости;
• статус проверяющего или доказательств оценки;
• ссылки на активные и устаревшие контракты проверяющего;
• связь с набором артефактов;
• связь с планом вывода из эксплуатации.

Чтобы такая запись не превращалась в длинную форму ради формы, ее удобно читать как пять групп:

1. Идентичность: agent_id, идентичность среды исполнения, команда-владелец и бизнес-назначение.
2. Жизненный цикл: состояние жизненного цикла, план вывода из эксплуатации и устаревшие пути.
3. Возможности: разрешенные возможности, принципалы инструментов и требования подтверждения.
4. Владельцы среды исполнения: кто отвечает за приостановленные запуски, фоновые запуски и сессии возможностей.
5. Ссылки на доказательства: статус наблюдаемости, доказательства проверяющего и оценок, контракты проверяющего и связь с набором артефактов.

Эта запись важна не ради “таблички”, а потому что она связывает агента как сущность с:

• механизмами контроля безопасности;
• операционным владельцем;
• решениями жизненного цикла.

5. Какие состояния жизненного цикла нужны почти всегда¶

Слишком простая модель “active / inactive” быстро перестает работать.

Минимально полезнее иметь хотя бы такие состояния:

• proposed
• development
• pilot
• production
• restricted
• deprecated
• retired

Тогда становится легче:

• ограничивать автономность до промышленного состояния;
• отслеживать устаревших агентов;
• видеть, какие агенты еще не должны иметь полный исходящий доступ или полный путь подтверждений;
• управлять заменой и выводом из эксплуатации без серой зоны.

6. Реестр полезен не только команде безопасности¶

Хороший реестр агентов нужен не только безопасности или управлению.

Он полезен и:

• платформенной команде;
• продуктовым командам;
• инженерам эксплуатации и надежности;
• аудиту и соответствию требованиям;
• реагирующим на инциденты.

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

7. Разрастание часто начинается с “маленьких исключени锶

На практике разрастание почти никогда не начинается как официальная стратегия.

Оно начинается с маленьких послаблений:

• “это всего лишь внутренний помощник”;
• “этот агент временный”;
• “пока без реестра, потом добавим”;
• “approval path здесь избыточен”;
• “телеметрию потом подключим”.

Через несколько месяцев оказывается, что именно эти исключения и образуют самую непрозрачную часть контура.

Поэтому надежное правило по умолчанию здесь простое: Поэтому надежное правило по умолчанию здесь простое:

• если сущность может действовать от имени организации, читать важный контекст или вызывать инструменты, она должна попадать хотя бы в инвентарь;
• если она идет в промышленный контур, она должна попасть и в реестр.

8. Как реестр связан с наблюдаемостью¶

Глава про наблюдаемость уже показала, что покрытие инвентаря — часть доказательного слоя.

Реестр делает эту связь еще жестче:

• трассы можно обогащать метаданными из реестра;
• обнаружения можно строить по состоянию жизненного цикла;
• инциденты можно фильтровать по владельцу, уровню риска и режиму подтверждения;
• доказательства выпуска можно проверять не только по трассам, но и по статусу записи в реестре и связи с доказательствами проверяющего.

То есть реестр превращает наблюдаемость из “сырых событий” в управляемую операционную карту.

Но его не нужно путать с происхождением артефактов. Происхождение хранит, какой утвержденный набор артефактов и какая версия обосновывали поведение.

Реестр хранит, какая именованная производственная сущность, какой владелец и какое состояние жизненного цикла принадлежали этому пути.

Именно здесь и проходит чистая граница между двумя главами. Наблюдаемость сохраняет доказательства.

Реестр привязывает доказательства к именованным сущностям, владельцам, состояниям жизненного цикла и путям подотчетности по всему контуру.

И это же граница с главой про происхождение. Происхождение отвечает, под какой утвержденной версией или утвержденным набором система работала.

Реестр отвечает, какая производственная сущность владела этим путем и кто отвечает за него сейчас.

Заметка о сквозных сценариях реестра: каждый канонический сценарий должен становиться именованной записью реестра, а не только примером в прозе. Разбор обращений поддержки требует владельцев пишущих возможностей, режима подтверждения и плана вывода из эксплуатации для устаревших путей тикетов. Внутренний ассистент знаний требует владельцев корпуса, проверки свежести, клиентской области действия и связи с политикой извлечения. Координация инцидентов требует владельцев ролей инцидента, полномочия на эскалацию, каналов уведомлений и состояния жизненного цикла для возможностей только аварийного режима.

8.1. Реестр без непрерывной сверки быстро становится красивым, но неточным¶

Здесь важно не переоценить сам реестр. Наличие реестра еще не доказывает, что слой контроля действительно работает.

Если реестр:

• не сверяется с реальным покрытием телеметрии;
• не проверяется против живых принципалов;
• не сопоставляется с активными возможностями;
• не сверяется с доказательствами проверяющего, на которые опираются поэтапный выпуск или заверение;
• не участвует в гигиене вывода из эксплуатации,

то он довольно быстро превращается в аккуратную, но частично вымышленную картину контура.

Поэтому зрелый реестр лучше мыслить не как статический каталог, а как контрольную поверхность, которую непрерывно сверяют с живым контуром.

9. Как реестр связан с подтверждениями и политиками¶

Реестр не должен дублировать набор политик или контракт подтверждения.

Его задача другая:

• показать, какие набор политик и режим подтверждения относятся к данному агенту;
• показать, имеет ли агент право на определенный набор возможностей;
• показать, какие утвержденные MCP-серверы, источники обнаружения и режимы авторизации входят в управляемую поверхность возможностей этого агента;
• показать, в каком состоянии жизненного цикла агент сейчас живет.

Если у тебя нет этой связки, то легко возникает состояние, в котором:

• политику обновили;
• поток подтверждения поменяли;
• трассы стали богаче;
• но никто не знает, какие именно агенты вообще должны этим пользоваться.

Это становится еще важнее, когда подтверждения и долгая работа превращаются в явные пути среды исполнения.

Тогда реестр должен помогать отвечать на вопросы:

• какие агенты вообще имеют право ставить запуск на паузу подтверждения;
• какие агенты могут продолжать работу в фоновом режиме;
• какие агенты могут повторно инициализировать сессии возможностей с состоянием и в каком режиме подтверждения;
• кто владелец застрявших запусков на паузе;
• кто владелец стареющих фоновых запусков;
• кто владелец дрейфа срока действия сессии возможности и аварийных действий заморозки;
• какую версию контракта должны соблюдать их полезные нагрузки подтверждений и возможностей;
• какой проверяющий или контракт оценивания считается доверенным для их доказательств оценки высокого риска;
• не ссылаются ли где-то в контуре на устаревшие контракты проверяющего;
• не появились ли теневые конечные точки MCP вне утвержденного реестра.

Иначе контур может выглядеть управляемым, но при этом скрывать операционную неоднозначность.

Поэтому реестр — это не столько слой про происхождение выпуска, сколько слой операционной подотчетности.

Это карта владения на уровне всего контура, которая удерживает решения, инциденты и дрейф привязанными к правильной сущности.

Обычно именно эта неоднозначность первой и бьет по реагированию на инциденты.

У команды уже могут быть телеметрия, политики и подтверждения, но она все равно теряет время на самом базовом вопросе контура: какая именно производственная сущность отвечает за этот путь прямо сейчас?

10. Пример минимальной записи в реестре агентов¶

agent:
  agent_id: support-triage-ref
  owner_team: customer-platform
  business_purpose: support_ticket_triage
  lifecycle_state: production
  runtime_identity: agent://support-triage-ref
  tool_principals:
    - svc-ticket-writer
  allowed_capabilities:
    - ticket_read
    - ticket_write
  mcp_surface:
    approved_servers:
      - support-registry/ticketing-mcp
    discovery_sources:
      - platform_registry
    auth_mode: managed_oauth
  policy_bundle: policy-v4
  approval_mode: required_for_high_risk
  runtime_controls:
    approval_pause_allowed: true
    background_mode_allowed: true
    capability_session_mode: stateful
    reinit_policy: approval_bound
    paused_run_owner: support-ops
    capability_session_owner: support-ops
    contract_version: capability-contract-v3
  observability:
    trace_enabled: true
    inventory_covered: true
    verifier_evidence_linked: true
  verifier_contract: verifier-v2
  deprecated_verifier_contracts:
    - verifier-v1
  artifacts:
    bundle_id: bundle-2026-04-07-a
  retirement_plan: retire-support-v1

Такая запись уже достаточно полезна, чтобы связывать агента с владением, механизмами контроля, жизненным циклом и ожиданиями к доказательствам проверяющего.

На уровне контура это еще и помогает отвечать на вопрос, который команды часто упускают: какие контракты проверяющего сейчас активны, какие уже устарели и какие агенты все еще зависят от старых версий.

11. Пример проверки здоровья реестра¶

from dataclasses import dataclass


@dataclass
class AgentRegistryState:
    has_owner: bool
    has_lifecycle_state: bool
    has_policy_linkage: bool
    has_observability: bool
    has_runtime_control_linkage: bool
    has_capability_session_owner: bool


def registry_ready(state: AgentRegistryState) -> bool:
    return (
        state.has_owner
        and state.has_lifecycle_state
        and state.has_policy_linkage
        and state.has_observability
        and state.has_runtime_control_linkage
        and state.has_capability_session_owner
    )

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

12. Самые частые режимы отказа¶

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

13. Быстрый тест зрелости для управления агентами¶

Команде не стоит думать, что она контролирует свой агентский контур только потому, что у нее есть таблица с реестром и примерное число развернутых агентов.

Более сильная планка такая:

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

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

В этот момент реестр все еще ведет себя как свободный каталог.

Зрелый реестр ведет себя скорее как слой подотчетности, который непрерывно сверяет производственные сущности, владение контролем и правду жизненного цикла.

14. Практический чеклист¶

• Можешь ли ты быстро назвать число активных, устаревших и выведенных из эксплуатации агентов?
• У каждого промышленного агента есть владелец?
• Связана ли запись в реестре с набором политик, режимом подтверждения, владением управления средой исполнения и bundle_id?
• Видно ли из инвентаря, какие агенты не шлют телеметрию?
• Можно ли быстро найти осиротевших или устаревших агентов с живыми принципалами?
• Есть ли у тебя различие между “обнаружен” и “одобрен для промышленной среды”?

Если несколько ответов подряд “нет”, то агентский контур у тебя уже есть, а управления агентами еще нет.

15. Модель доказательности этой главы¶

Эту главу стоит читать как слой подотчетности, а не как таблицу инвентаризации:

• Устойчивые утверждения: управление агентами требует больше, чем обнаружение; каждому промышленному агенту нужны владение, состояние жизненного цикла, связь с политикой и наблюдаемый статус контроля.
• Вендорская практика: рекомендации по инвентарю инфраструктуры и агентному риску сходятся к непрерывному покрытию активов, владению и подотчетности контроля.
• Практика среды исполнения: записи реестра, артефакты жизненного цикла, наборы политик, режимы подтверждения, статус принципала и покрытие телеметрией делают парк агентов проверяемым.
• Авторская интерпретация: реестр — закрывающий слой, который связывает наблюдаемость, политику, жизненный цикл и вывод из эксплуатации в одну подотчетную производственную сущность.
• Быстро меняющаяся область: средства построения агентов, реестры и механизмы обнаружения будут меняться; различие между обнаруженными сущностями и агентами, одобренными для промышленной среды, — нет.

16. Полезные справочные страницы¶

• Схема артефактов жизненного цикла
• Схема набора политик и контракта подтверждения
• Схема запроса на подтверждение и записи о решении
• Схема трасс и каталог событий
• Схема наборов для оценки и правил проверки
• Схема памяти и извлечения

• Исследовательский фронтир: память, наблюдаемость и надежность многоагентных систем

• Глава 23. Вывод из эксплуатации, замена и дисциплина завершения жизненного цикла

• Глава 24. Агентное несоответствие целей и инсайдерский риск
• Глава 26. Наблюдаемость для ИИ-систем, покрытие реестра и телеметрия для обнаружения проблем