Глава 22. Цепочка поставки, происхождение и доверенные артефакты¶

1. Почему у агентных систем цепочка поставки шире, чем у обычного сервиса¶

Когда инженеры слышат слова «цепочка поставки ПО», они обычно думают о знакомых вещах:

• пакетные зависимости;
• контейнеры;
• артефакты CI/CD;
• подписи и происхождение для результатов сборки.

Для агентных систем этого мало.

Проблема в том, что рабочее поведение здесь зависит не только от кода. На него влияют еще:

• маршруты к моделям;
• наборы prompt- и routine-правил;
• конфигурации политик;
• корпуса для извлечения;
• контракты возможностей;
• наборы для оценки;
• verifier contracts, rubric definitions и правила связывания доказательной базы;
• правила и схемы approval;
• схемы runtime-control;
• governance-правила для orchestration pattern и определения worker-safe catalog;
• правила interruption и re-initialization для capability sessions;
• наборы для раскатки.

То есть цепочка поставки у агента шире, потому что сама система шире.

2. Что такое доверенный артефакт в агентной системе¶

Полезно заранее дать очень прямое определение:

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

Это означает, что доверенные артефакты — это не только образы или wheel-файлы. Это еще и управляемые объекты, к которым потом должен уметь точно вернуться разбор раскатки, assurance-решение или разбор инцидента.

В агентной платформе к ним часто относятся:

• утвержденный маршрут к модели;
• утвержденный набор prompt-правил;
• утвержденный набор политик;
• утвержденный контракт возможности;
• утвержденная approval schema;
• утвержденная runtime-control schema;
• утвержденный источник для извлечения;
• утвержденный набор для оценки;
• утвержденный шаблон раскатки.

Если у команды нет такой категории, она очень быстро начинает жить в неявной системе доверия: «Кажется, это нормальный артефакт, потому что кто-то его уже использовал».

3. Происхождение нужно для ответа на очень практичные вопросы¶

Google Research очень точно показывает, что подтверждение происхождения для ИИ-систем нужно не только как формальная идея безопасности, но и как практическая рабочая необходимость.¹

Тебе нужно уметь отвечать:

• откуда взялась эта модель;
• какой набор prompt-правил сейчас активен;
• какая конфигурация политик была во время инцидента;
• какой корпус для извлечения использовался;
• какой набор для оценки подтвердил выпуск;
• какой verifier contract, grading rubric и правила связывания доказательной базы были активны;
• какие contract version и approval schema были активны;
• какая interruption или expiry policy управляла этим run;
• какой orchestration pattern и какая worker-boundary policy управляли этим run;
• какой delegated authorization mode, principal binding и revoke policy управляли этим run;
• кто одобрил это изменение.

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

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

Эта глава отвечает на один вопрос: на какой именно проверенный набор артефактов потом опирается rollout review, incident analysis или assurance-решение. Здесь provenance нужно не как общее слово про evidence, а как управляемую преемственность доверенных версий и контрактов. Главный артефакт этой главы — approved artifact bundle: проверенный набор версий, контрактов и схем, а не общая папка с доказательствами.

Если тебе нужен мост, который показывает, как этот governed backbone остается связан с request, policy, approvals, traces, evals, incidents и rollout judgment, используй отдельную страницу Evidence Spine.

4. У агента должно быть несколько цепочек доверия, а не одна¶

В обычной системе команда часто мыслит одной цепочкой доверия: «Код собран в CI, контейнер подписан, значит все хорошо».

В агентных системах лучше мыслить несколькими связанными цепочками:

• цепочкой кода и сборки;
• цепочкой моделей;
• цепочкой prompt- и routine-правил;
• цепочкой политик;
• цепочкой возможностей;
• цепочкой approval и runtime-control;
• цепочкой правил управления capability sessions;
• цепочкой delegated authorization;
• цепочкой данных и извлечения;
• цепочкой оценки.

flowchart LR
    A["Код и сборка"] --> G["Утвержденный release bundle"]
    B["Артефакты модели"] --> G
    C["Prompt- и routine-наборы"] --> G
    D["Policy bundles"] --> G
    E["Capability contracts"] --> G
    F["Approval и runtime-control schemas"] --> G
    H["Eval datasets и отчеты"] --> G

5. Утвержденный реестр и доверенные артефакты не одно и то же¶

Это близкие, но разные понятия.

approved inventory отвечает на вопрос:

• какие рантаймы, шлюзы, возможности и шаблоны вообще разрешены на платформе.

approved artifacts отвечает на вопрос:

• какие конкретные версии и наборы разрешены к запуску прямо сейчас.

Например:

• возможность create_ticket может быть частью утвержденного реестра;
• но конкретный policy_bundle_v12 или prompt_bundle_support_v7 — это уже доверенный артефакт.

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

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

То же правило важно и для failed runs. Если capability упала по timeout, путь approval закончился validation failure или внешняя dependency обрушилась, последующий разбор все равно должен видеть, какой набор доверенных артефактов и какая идентичность выпуска управляли этим сбоем, какое экспортируемое поле, например failure_reason, сохранило конкретное условие сбоя, отображалось ли оно в operator-facing summary через поля вроде latest_failure_reason и продолжал ли этот run учитываться как traceable_failed_runs на уровне session review. Иначе организация сохраняет подтвержденное происхождение только для happy path, а деградировавшее поведение превращает в бесхозный остаток.

6. Набор prompt-правил без происхождения — это такой же пробел, как неподписанная сборка¶

Очень частая ошибка команд: относиться к изменениям prompt как к живому тексту, а не как к артефакту выпуска.

Но если ты не знаешь:

• кто менял prompt;
• какая версия сейчас в проде;
• какие оценки ее покрыли;
• на какой волне раскатки она активна;

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

То же самое относится к:

• routines;
• policy YAML;
• конфигурациям извлечения;
• порогам подтверждения;
• runtime-control schemas, которые определяют paused/background behavior.

7. Наборы для оценки тоже должны быть доверенными артефактами¶

Очень легко считать набор для оценки чем-то второстепенным: «Ну это просто набор тестовых примеров».

На самом деле это критичный артефакт управления.

Если он:

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

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

Поэтому хороший ADLC должен относиться к наборам для оценки как к части модели доверенных артефактов.

То же все больше верно и для verifier contracts. Если выпуск или assurance зависят от process scores, outcome scores, failure attribution или связанной доказательной базы, verifier layer уже нельзя считать неформальной вспомогательной логикой. Это полноценный управляемый промышленный артефакт.

8. Контракты возможностей и правила сетевого выхода тоже входят в цепочку поставки¶

В агентных системах контракт инструмента — это не просто документация, а часть доверенной рабочей поверхности.

У возможности должно быть понятно:

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

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

То же самое верно и для approval и runtime-control schemas. Если команда меняет timeout, pause/resume behavior, expiry semantics, правила re-initialization или ожидаемую форму payloads без дисциплины управления артефактами, она меняет рабочее поведение системы, даже если ни модель, ни исходный код не сдвинулись.

Это означает, что подтвержденное происхождение все чаще должно хранить не только сам факт существования runtime-control schema, но и то, какая версия interruption-governance реально была активна:

• paused runs истекали или могли ждать бесконечно;
• capability-session re-init была allowed, denied или approval-bound;
• telemetry обязана была связывать исходную и reinitialized capability sessions или нет;
• какой orchestration pattern был утвержден для этого path и действовали ли worker-safe catalog boundaries;
• approval и session-control logic еще управлялись одним contract version или уже начали расходиться;
• delegated access была platform-owned или user-delegated;
• какое principal-binding rule и revoke behavior управляли in-flight или paused actions.

Более поздняя работа Anthropic про harness design показывает еще одно следствие для цепочки происхождения.² Если длинная работа зависит от context resets, разделения ролей planner/generator/evaluator, sprint contracts и структурированных handoff artifacts, то такие handoff artifacts уже нельзя считать одноразовыми координационными заметками. Они тоже становятся артефактами с управляемым происхождением. Поздний incident review или спор о rollout может потребовать выяснить, какой handoff artifact перенес scope, какой evaluator critique изменил следующий sprint и на какой reset boundary активный контекст сменился без смены user-visible run.

Это вопросы происхождения именно потому, что они определяют управляемую идентичность поведения, а не просто факт того, что поведение было видно в telemetry.

9. Пример политики доверенных артефактов¶

Ниже очень практичный каркас:

artifacts:
  require_owner: true
  require_version: true
  require_provenance: true
  require_review_status: true
  types:
    - model_route
    - prompt_bundle
    - policy_bundle
    - capability_contract
    - approval_schema
    - runtime_control_schema
    - capability_session_contract
    - verifier_contract
    - eval_dataset
    - retrieval_source

Такой список убирает разговор в стиле «Ну вроде нормальная конфигурация» и заставляет относиться к артефактам как к полноценным рабочим объектам.

10. Пример политики утвержденного реестра¶

А вот более платформенный пример:

inventory:
  approved_runtimes:
    - agent_runtime_v3
  approved_gateways:
    - shared_tool_gateway
    - approval_gateway
  approved_patterns:
    - staged_rollout
    - approval_required_for_high_risk
    - governed_background_mode
    - reviewed_routing
    - bounded_parallelization
    - worker_safe_orchestrator_workers
  deprecated_patterns:
    - direct_prod_tool_access
    - unversioned_prompt_override

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

11. Пример проверки готовности артефакта¶

Ниже очень простой каркас:

from dataclasses import dataclass


@dataclass
class ArtifactRecord:
    has_owner: bool
    has_version: bool
    has_provenance: bool
    review_passed: bool
    schema_linked: bool


def artifact_ready(record: ArtifactRecord) -> bool:
    return (
        record.has_owner
        and record.has_version
        and record.has_provenance
        and record.review_passed
        and record.schema_linked
    )

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

12. Что чаще всего ломается в дисциплине артефактов¶

Обычно проблемы выглядят так:

• наборы prompt-правил не версионируются;
• наборы для оценки тихо меняются;
• контракты возможностей редактируются без следа проверки;
• approval или runtime-control schemas меняются без дисциплины версий;
• изменения в orchestration pattern не имеют прослеживаемого происхождения артефактов;
• никто не знает, какой именно артефакт был активен в момент инцидента;
• в доказательном слое отсутствует связь с версией контракта;
• устаревшие шаблоны живут в промышленной среде слишком долго;
• утвержденный реестр существует в wiki, но не в рабочих инструментах.

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

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

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

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

• prompt-, policy-, eval-, capability-, approval-, runtime-control- и verifier-артефакты считаются полноценными производственными артефактами;
• происхождение можно быстро восстановить и для разбора инцидента, и для решений о раскатке;
• release- и assurance-доказательства можно проследить до активного verifier contract и семейства контрактов;
• approved inventory и approved artifacts существуют как разные уровни контроля;
• deprecated patterns можно заблокировать до того, как они тихо закрепятся в промышленной среде;
• доверие привязано к явным свойствам артефакта, а не передается социально.

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

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

Если хочешь быстро проверить свою дисциплину артефактов, пройди по вопросам:

• У всех рабочих артефактов есть владелец?
• У model-, prompt-, policy-, approval-, runtime-control-, eval- и verifier-артефактов есть версии?
• Можно ли быстро восстановить происхождение, verifier lineage и активные версии контрактов и схем для разбора инцидента?
• Есть ли утвержденный реестр платформы?
• Отличаете ли вы шаблон, разрешенный на уровне платформы, от артефакта, разрешенного к выпуску?
• Можно ли быстро заблокировать устаревший артефакт?

Если на несколько вопросов подряд ответ «нет», у тебя пока еще нет полноценного слоя управления артефактами.

15. Что читать дальше¶

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

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

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

• Эталонный пакет

• Глава 21. Assurance loop: red teaming, detection и response

• Глава 17. Слой политик и каталог возможностей
• Глава 18. Чеклист промышленного запуска
• Источники