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

У агента может быть действующая идентичность и корректное разрешение, но исполняться он может в неподходящей среде. Оркестратор мог остаться без нужного обновления. Оценщик политик могли заменить. Исполнитель инструмента может работать вне ожидаемой границы изоляции. Зависимость или конфигурация могут отличаться от одобренного релиза. Для значимого действия — перевода средств, выдачи учётных данных, расшифровки чувствительных данных или изменения промышленной системы — это не второстепенная деталь реализации. Это вопрос управления.
Поэтому в точке принятия обязательства автономной организации следует задать ещё один вопрос: может ли это действие предъявить актуальное свидетельство о среде, которая будет его исполнять? Для операций высокого риска положительный ответ всё чаще должен становиться условием выдачи полномочия. Шлюз принятия обязательства не должен выдавать платёжный реквизит, ключ расшифровки или доступ к инструменту только потому, что субъект аутентифицирован и авторизован. Ему также нужен вердикт аттестации для цепочки исполнения, которая создаст бизнес-эффект.
Идентичность, разрешение и свидетельство о среде отвечают на разные вопросы
Эти меры контроля часто сводят к расплывчатому понятию доверия. Так делать не следует. Аутентификация отвечает: какой субъект запрашивает действие? Авторизация отвечает: может ли этот субъект выполнить действие при заданных ограничениях? Журналы аудита отвечают: что система зафиксировала как произошедшее? Аттестация среды отвечает на более узкий, но отдельный вопрос: какая измеренная конфигурация программного и аппаратного обеспечения присутствовала, когда было создано свидетельство?
Ни один из этих ответов не отменяет остальные. Аттестованная среда всё ещё может принять плохое решение. У неё может быть разрешение на действие, неуместное в данном бизнес-контексте. Её журналы могут быть неполными, а её идентичность — скомпрометированной. И наоборот, корректное решение политики не доказывает, что в этот момент работал одобренный оценщик политики. Аттестация не подтверждает безопасность, законность, согласованность с намерениями организации или правильность решения агента. Она даёт свидетельство об измеренной среде, в которой работала определённая часть системы.
Для действия высокого риска авторизация должна решать, допустимо ли оно; аттестация должна помогать решать, может ли именно эта среда получить средства для его совершения.
Аттестация должна быть шлюзом, а не посмертным отчётом
Архитектурная ошибка — собирать свидетельства о среде после того, как платёж, развёртывание или раскрытие данных уже состоялись. Тогда аттестация улучшит разбор инцидента, но не помешает несоответствующей среде получить возможность действовать. Полезное место для неё — до необратимого или дорогостоящего бизнес-эффекта: в том же шлюзе принятия обязательства, который управляет реквизитами и возможностями, привязанными к конкретному эффекту.
Практический шлюз состоит из пяти шагов. Сначала запуск агента объявляет планируемый эффект через устойчивый идентификатор эффекта: например, конкретный платёж поставщику, изменение в промышленной среде или экспорт данных клиента. Затем относящиеся к делу компоненты среды предоставляют подписанные свидетельства. Верификатор сопоставляет их с одобренными эталонными значениями и формирует краткоживущий вердикт. Этот вердикт привязывается к идентификатору запуска и эффекта. Наконец, шлюз оценивает его вместе с обычной авторизацией, политикой риска и бизнес-контролями данного эффекта, прежде чем выдать узко ограниченную возможность.
- Объявить планируемый бизнес-эффект и его идентификатор.
- Собрать подписанные свидетельства от относящихся к делу компонентов исполнения.
- Сопоставить измерения с одобренными эталонными значениями.
- Привязать свежий вердикт к конкретному запуску и эффекту.
- Выдать только реквизит или возможность, необходимые для этого эффекта, если все шлюзы пройдены.
Привязка принципиальна. Общее утверждение, что нагрузка была исправна утром, не должно повторно использоваться для авторизации другого перевода или развёртывания. Вердикту нужен короткий срок действия и явная связь с запуском и эффектом. Иначе свидетельство о среде превратится в ещё один переносимый токен, живущий дольше, чем контроль, который оно должно было обеспечить.
Цепочка исполнения составная
Действие агента редко рождается в одном исполняемом модуле. Значимый запуск может включать оркестратор, распределяющий работу; движок политик, оценивающий ограничения; модельный endpoint; сервис памяти; исполнитель инструментов; и защищённую среду нагрузки. Поэтому корректная граница аттестации не обязательно совпадает с «агентом». Это набор компонентов, состояние которых существенно для готовности организации разрешить данный эффект.
Архитектура IETF Remote ATtestation Procedures, RFC 9334, предлагает для этого полезную модель. Она разделяет аттестатор, создающий свидетельство; верификатор, оценивающий его; и полагающуюся сторону, которая использует результат аттестации в прикладном решении. В ней также описаны составные системы, где свидетельства нескольких подсущностей собирает ведущий аттестатор. Это естественно отображается на управляемую цепочку исполнения: верификатор оценивает состояние среды, а шлюз принятия обязательства как полагающаяся сторона решает, выдавать ли полномочие.
Свидетельство не обязательно сводить к одному непрозрачному заявлению. Платформа Entity Attestation Token из RFC 9711 поддерживает вложенные подмодули в свидетельствах и результатах аттестации, в том числе вложенные токены и отделённые дайджесты подмодулей. RFC 10013 определяет структуры для измеренных компонентов, включая их идентичности и криптографические измерения. Вместе это полезные примитивы для представления многоуровневой среды, где одни компоненты измеряются напрямую, а другие аттестуются независимо.
Это не означает, что каждый компонент будет наблюдаем с одинаковой глубиной. Внешний поставщик моделей может не раскрывать измерения весов модели или всего обслуживающего стека. Организация должна честно определить достижимую границу: например, собственные оркестратор, оценщик политик, исполнитель и защищённую среду нагрузки, рассматривая внешний модельный сервис как отдельно управляемую зависимость. Отсутствующее измерение должно быть явно учтённым условием политики, а не подразумеваемой гарантией.
Эталонные значения требуют жизненного цикла управления
Верификатор способен оценить свидетельство только относительно эталонных значений, одобренных организацией. Поэтому эталонные значения — не статические метаданные безопасности, а операционное управление. Новые релизы, экстренные исправления, изменения конфигурации, отозванные зависимости и пересмотренные требования к изоляции меняют то, что организация должна принимать. Одобренное измерение никогда не является бессрочным разрешением доверять.
В первоначальном публичном проекте NIST от мая 2026 года о конфиденциальных облачных нагрузках удалённая аттестация описана как подписанное свидетельство о конфигурации аппаратного и программного обеспечения. Полагающаяся сторона сопоставляет измерения с ожидаемыми значениями до предоставления доступа к секретам или ключам. Этот паттерн напрямую применим здесь, даже если организация использует механизмы обеспечения, отличные от специализированного оборудования. RATS допускает разные подходы к аттестации — от изоляции процессов до специализированного оборудования. Требование управления состоит в свидетельстве, соразмерном риску, а не во всеобщем требовании доверенной аппаратной среды исполнения.
Изменения эталонных значений требуют той же дисциплины, что и изменения политик: владельца, проверки, правил развёртывания, версионирования, отзыва и способа повторно оценить длительную работу после значимого изменения среды. Без такого жизненного цикла организация лишь автоматизирует одобрение устаревающей базовой конфигурации.
Начинать следует там, где отклонение среды создаёт необратимый эффект
Не каждый запрос агента заслуживает отдельного цикла удалённой аттестации. Чтение общедоступных сведений, подготовка внутреннего текста или обратимая рекомендация могут достаточно управляться обычной идентичностью, авторизацией и журналированием. Первыми кандидатами на шлюз с подтверждением среды должны стать действия, открывающие доступ к секретам, фиксирующие деньги, меняющие промышленное состояние, раскрывающие регулируемые данные или вызывающие мощные внешние инструменты. Именно здесь отклонение в пути контроля имеет существенное операционное последствие.
Начните с небольшой и явно заданной цепочки исполнения. Например, потребуйте свидетельства от оркестратора, оценщика политик и исполнителя инструмента, прежде чем выдать одноразовый платёжный реквизит. Определите, какие измерения обязательны, кто отвечает за их эталонные значения, насколько свежим должен быть вердикт и что происходит, если компонент недоступен или не поддаётся аттестации. Безопасное значение по умолчанию для эффекта высокого риска обычно состоит в отказе от выдачи, передаче случая на проверку человеку или отдельно управляемом резервном пути — но не в молчаливом признании отсутствующего свидетельства успешным результатом.
Итог — не заявление, будто организация решила проблему безопасности агентов. Это более точная граница контроля. Организация может утверждать, что конкретный эффект был авторизован по политике, зафиксирован в её системах свидетельств и получил средства для исполнения только после того, как относящаяся к нему измеренная среда прошла действующие правила допуска. По мере того как автономные системы получают власть над значимой работой, это различие стоит провести до того, а не после того, как действие покинет пределы организации.
Источники
- IETF RFC 9334, архитектура Remote ATtestation Procedures (RATS).
- IETF RFC 9711, Entity Attestation Token (EAT).
- IETF RFC 10013, эталонные модели взаимодействия для процедур удалённой аттестации.
- NIST IR 8320E, Confidential Cloud Workloads, первоначальный публичный проект, май 2026 года.
- Confidential Containers, архитектура аттестации.

