Агент не должен переписывать организацию на ходу

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

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

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

Отделите предложение от активации

Это адаптация подходов из защиты цепочки поставки ПО, а не утверждение, что существующие стандарты уже регулируют автономные организации. SLSA определяет provenance как проверяемую информацию о том, где, когда и как был создан программный артефакт. Более высокие уровни сборки добавляют подписанное происхождение, размещенные платформы сборки, более строгую изоляцию и защиту от подмены. Фреймворк in-toto также фиксирует шаги цепочки поставки, их порядок и исполнителей, а затем проверяет подписанные метаданные шагов относительно подписанной схемы.

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

“Результат агента может предложить изменение. Принять изменение вправе только плоскость управления.

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

Собирайте артефакт, а не изменяемую инструкцию

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

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

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

Сделайте свидетельства независимыми от запуска-автора

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

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

NIST SP 800-218 описывает практики безопасной разработки, предназначенные для встраивания в жизненный цикл разработки и снижения уязвимостей в выпускаемом ПО. Здесь это полезная дисциплина: результат, меняющий производство, заслуживает определенных практик, а не импровизированного доверия. Но ни прошедший набор тестов, ни подписанное утверждение не доказывают, что артефакт безопасен, соответствует требованиям или свободен от вредоносной логики. GitHub так же предупреждает об аттестациях артефактов: потребитель должен проверить их и оценить по собственным критериям политики.

Допускайте по политике, а не по инерции

После сборки и проверки сервис допуска должен решить, может ли артефакт войти в активную плоскость управления. Kubernetes дает полезную структурную аналогию. Его admission controllers перехватывают изменяющие ресурс API-запросы после аутентификации и авторизации, но до сохранения; валидирующие контроллеры могут отклонить несоответствующий запрос. В управляемом рантайме аналогом будет шлюз между репозиторием артефактов и активным реестром политик, процессов, инструментов или конфигураций.

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

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

Не смешивайте продвижение с полномочием на последующее действие

Допуск отвечает на узкий вопрос: может ли этот идентифицированный артефакт стать активным состоянием организации? Он не отвечает, вправе ли конкретный агент позже совершить деловое действие по этому артефакту. Во время исполнения агенту по-прежнему нужны применимые идентичность, цель, авторизация, оценка политики и контроли эффекта. Даже безопасно допущенный процесс может быть вызван не тем субъектом, не в то время или с недопустимым входом.

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

Стройте журнал артефактов вокруг вопросов, которые действительно возникнут

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

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

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