NIST даст ИИ-агентам отдельные личности — постоянные ключи признали опасными

В сообщении NIST от 29 сентября 2026 года говорится о публикации сводки более 600 откликов по идентификации и авторизации ИИ-агентов. Национальный центр передового опыта в кибербезопасности (NCCoE) выбрал разработку ПО первым сценарием практической проверки: в нём предстоит показать, как различать агентов, подтверждать их личность и ограничивать доступ.

Предлагаемый участниками подход даёт агенту собственную проверяемую идентичность, связанную с породившим его сервисом, а права на конкретное задание выдаёт на короткий срок. В сводке комментариев один из участников выразил различие так: «The credential expressing that identity should be short-lived». Постоянные ключи API и унаследованные права пользователя участники считают опасными: доступ может сохраняться после завершения работы, а утечка ключа открывает его постороннему. Это выводы обсуждения и план будущей проверки, пока без утверждённого стандарта.

Отдельная идентичность и устойчивый корень доверия

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

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

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

Временное полномочие ограничивает последствия утечки

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

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

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

При передаче задачи права сужаются

Подтверждённая личность агента ещё не даёт разрешения на любую операцию. Участники предлагают принимать решение о доступе в момент обращения к инструменту или API, с учётом текущей задачи и контекста. Когда агент разбивает поручение на части, проверка должна повторяться для каждой значимой операции, а полномочия вспомогательного агента — оставаться уже полномочий того, кто передал задачу.

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

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

Журнал должен показывать основание решения

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

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

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

Первой проверкой станет разработка ПО

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

Большинство участников высказалось за развитие действующих стандартов через расширения и согласованные профили. Независимый проект Agentic Frontier Observatory относит опубликованную сводку к этапу формирования архитектуры, а не к нормативному стандарту или результату проверки совместимости. Следующим документом NCCoE намерен представить проект описания работ с границами, сценариями, архитектурой и стандартами для обсуждения; он уточнит, какие из предложенных механизмов проверят в жизненном цикле разработки ПО.

Читайте также:

• Faro привлекла $37,3 млн — ИИ-агентам доверят разработку лекарств
• Признаки харизматичного человека, личности и лидера
• Seoseed.ru принимает заявки бесплатно — но продавца курса проверяйте отдельно