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

Актуальность главы

Последняя редакционная проверка: 14 мая 2026 года. Следующая плановая проверка: 14 июня 2026 года.

Что изменилось после предыдущей проверки: поверхности безопасности MCP/A2A, контракты проверяющего, управленческая телеметрия и замечания по готовности к печатной версии теперь покрыты конкретными контрактами и проверками документации.

Быстрее всего здесь меняются:

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

Медленнее меняются:

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

Роль главы в части VIII

Главный вопрос: каким утвержденным артефактам команда может доверять при выпуске и расследовании.

Уникальный артефакт: утвержденный набор артефактов.

Граница с соседними главами: происхождение артефактов, не наблюдаемость.

Что эта глава не покрывает: обнаружение событий в трассах, оперативное реагирование и реестр владельцев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сквозной кейс: происхождение для исправления дубля тикета

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

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

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

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

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

Нужны артефакты цепочки поставки?

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

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

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

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

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

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

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

flowchart LR
    A["Код и сборка"] --> G["Утвержденный набор выпуска"]
    B["Артефакты модели"] --> G
    C["Наборы инструкций и процедур"] --> G
    D["Наборы политик"] --> G
    E["Контракты возможностей"] --> G
    F["Схемы подтверждения и управления средой исполнения"] --> G
    H["Наборы данных оценки и отчеты"] --> G

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

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

утвержденный реестр отвечает на вопрос:

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

доверенные артефакты отвечают на вопрос:

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

Например:

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

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

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

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

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

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

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

кто менял инструкцию;
какая версия сейчас в проде;
какие оценки ее покрыли;
на какой волне поэтапного выпуска она активна;

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

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

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

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

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

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

Если он:

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

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

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

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

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

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

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

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

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

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

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

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

Более поздняя работа Anthropic про проектирование harness-среды показывает еще одно следствие для цепочки происхождения.² Если длинная работа зависит от сбросов контекста, разделения ролей planner/generator/evaluator, контрактов спринта и структурированных артефактов передачи управления, то такие артефакты передачи управления уже нельзя считать одноразовыми координационными заметками. Они тоже становятся артефактами с управляемым происхождением. Поздний разбор инцидента или спор о поэтапном выпуске может потребовать выяснить, какой артефакт передачи управления перенес область работы, какая критика оценщика изменила следующий спринт и на какой границе сброса активный контекст сменился без смены видимого пользователю запуска.

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

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

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-правил не версионируются;
наборы для оценки тихо меняются;
контракты возможностей редактируются без следа проверки;
схемы подтверждения или схемы управления средой исполнения меняются без дисциплины версий;
изменения в схеме оркестрации не имеют прослеживаемого происхождения артефактов;
никто не знает, какой именно артефакт был активен в момент инцидента;
в доказательном слое отсутствует связь с версией контракта;
устаревшие шаблоны живут в промышленной среде слишком долго;
утвержденный реестр существует в wiki, но не в рабочих инструментах.

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

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

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

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

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

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

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

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

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

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

Шаблон завершения главы

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

Типичные ошибки: хранить наборы оценок без версии и источника; не фиксировать происхождение правил инструкций; путать утвержденный реестр с папкой файлов.

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

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

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

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

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