Резюме для руководства
Защитные барьеры для ИИ-промптов не могут обеспечить безопасность автономных ИИ-агентов, поскольку они функционируют в том же вероятностном текстовом потоке, что и внедренные промпты. Руководство NIST на 2026 год требует архитектурного разделения, при котором детерминированная идентификация, динамическая авторизация и уменьшение прав токенов находятся полностью за пределами языковой модели.
ИИ-агент может отклониться от курса под влиянием того, что он читает. Строка, скрытая в документе, на веб-странице или в электронной почте, может наделить агента с широким доступом способностью сделать то, чего его владелец никогда не планировал. В новой публикации NIST «Design Tenets for Agent Identity Management Systems» говорится, что решение проблемы не может находиться внутри модели: «Сами по себе защитные барьеры недостаточны». Ее 10 принципов проектирования основаны на публичных комментариях к проекту NCCoE по идентификации и авторизации программного обеспечения и ИИ-агентов и читаются как список требований, которые команда безопасности может предъявить к любой системе, управляющей агентами.
Почему защитные барьеры промптов не могут обеспечить безопасность автономных ИИ-агентов
Логика NIST связана с принципом работы языковых моделей. Модель получает инструкции и входные данные в виде единого потока текста, поэтому она не может надежно отличать их друг от друга, и инструкция, скрытая в документе, может восприниматься как команда от пользователя. Фильтры промптов и защитные барьеры носят вероятностный характер и считывают тот же текстовый поток, в который злоумышленник может внедрить данные.
Хотя эти защитные барьеры пытаются прогнозировать небезопасные входные данные, их использование создает пять структурных пробелов в безопасности:
- Вероятностное против детерминированного: каждый классификатор имеет уровень ошибок. При скорости и масштабе работы агентов даже крошечный уровень ошибок означает тысячи неверных вызовов, а когда вызов переводит деньги или удаляет базу данных, даже один такой вызов — это слишком много.
- Общая поверхность атаки: защитный барьер проверяет промпт, содержимое и предлагаемое действие — то есть тот же текст, в который злоумышленник может внедрить вредоносные данные. Злоумышленнику нужна лишь одна успешная попытка, и он может перефразировать, кодировать, разделять или скрывать инструкции до тех пор, пока не достигнет своей цели.
- Отсутствие контекста идентификации: классификатор видит входной поток. Он не знает, какой агент отправил запрос, от чьего имени он действует, был ли этот агент скомпрометирован ранее или обращался ли он к этому ресурсу вообще. Эти факты хранятся в системе идентификации.
- Поведенческий дрейф: переобучение или тонкая настройка модели могут изменить поведение защитного барьера без чьего-либо одобрения. Политика идентификации меняется только тогда, когда кто-то вносит в нее правки, и эти правки фиксируются в журнале.
- Невозможность обеспечить аннулирование: защитный барьер может остановить промпт. Он не может отозвать учетные данные агента или заблокировать доступ, который уже есть у агента.
NIST приходит к выводу, что разделение должно быть заложено на архитектурном уровне: система, определяющая, что агенту разрешено делать, должна располагаться вне агента — между агентом и используемыми им данными, инструментами и учетными данными. Именно поэтому идентификация, управление доступом и контроль во время выполнения должны находиться вне агента и платформы, на которой он запущен, в рамках единой системы, управляющей доступом агентов в различных доменах.
10 принципов проектирования NIST для идентификации ИИ-агентов
- Четкая идентификация агентов: агенты получают уникальные идентификаторы, отличные от учетных записей людей и сервисных аккаунтов, с собственным жизненным циклом учетных данных.
- Связывание, делегирование и уменьшение прав агентов: агенты остаются привязанными к тому, кто запустил задачу, а делегированные полномочия сокращаются по мере их передачи субагентам или нижестоящим службам.
- Минимальные и нулевые постоянные привилеги: агенты не имеют постоянных прав в режиме простоя, получают лишь минимальный объем прав, необходимых для задачи, и ограждены от объединения конфликтующих привилегий (разделение обязанностей).
- Краткосрочная, динамическая и отзываемая авторизация: доступ предоставляется точно вовремя (just-in-time), ограничен по времени и ориентирован на конкретного получателя, с проверками во время выполнения и возможностью отзыва, без долгоживущих токенов предъявителя или статических секретов.
- Триггеры с участием человека: пороговые значения риска направляют действия агента нужному проверяющему-человеку без возникновения утомления от запросов на подтверждение.
- Мандаты и ограничения: инициаторы задач выдают подписанные мандаты с указанием предполагаемых результатов и ограничений, которые могут проверить нижестоящие службы.
- Архитектурное разделение политики и логики принятия решений: логика, определяющая то, что агент пытается сделать, отделена от систем, определяющих, что ему разрешено делать, поэтому внедренный контент не может расширить разрешения.
- Детерминированные решения о доступе: детерминированные механизмы являются основной для принятия решений о доступе. Вероятностные сигналы, такие как оценка риска, могут учитываться при их принятии, но не определяют их.
- Непрерывный мониторинг: специфичные для агентов метрики, пороговые значения и политики сигнализируют об аномалиях со скоростью работы агента.
- Неизменяемые доказательства: защищенная от несанкционированного вмешательства запись действий, делегированных намерений и идентификации агента, доступная только для добавления, хранится отдельно от агента.
Принципы 7 и 8 являются ключевыми в дискуссии о защитных барьерах. Политика должна располагаться вне агента, а решение должно приниматься на основе детерминированной проверки, а не модели.
Почему уровень идентификации — это правильное место для принятия решений
Защитный барьер прогнозирует, является ли действие безопасным. Уровень идентификации определяет, разрешено ли это действие. Сегодня большинство агентов работают на заимствованных учетных данных: ключе API в файле конфигурации, общем сервисном аккаунте или персональном токене пользователя. Принципы NIST требуют иного: каждый агент получает собственную идентификацию с владельцем, целью и разрешениями, которые он получает по одной за раз для каждой задачи. Создание такой идентификации и управление ею от первого доступа до вывода из эксплуатации — это то, для чего создаются провайдеры идентификации.
Уровень идентификации работает иначе, чем защитные барьеры:
- Он принимает решения на основе явной политики: прав доступа, областей видимости, связей и таких условий, как уровень риска и устройство.
- Он находится вне модели (что соответствует седьмому принципу), никогда не читает промпт, поэтому внедренной инструкции не с чем взаимодействовать.
Агенту требуется выданный токен для вызова ресурса, поэтому агент, введенный в заблуждение с целью совершения вредоносного действия, все равно не имеет ключа. Он уже знает, кто является агентом, кто является человеком, на что имеет право каждый из них и каков текущий уровень риска обоих. Это также единственная система, способная выдать проверяемое заявление о том, что данный агент действует от имени данного пользователя с данными областями видимости, поэтому обмен токенами и построенные на нем стандарты служат основой доверия. И он работает со всеми типами агентов: собственными, SaaS-агентами, помощниками по написанию кода, серверами MCP и агентами взаимодействующими друг с другом, используя OAuth, OpenID Connect (OIDC) и стандарты детализированной авторизации с многолетним опытом развития. Защитные барьеры пока не имеют стандартов и различаются в зависимости от провайдера.
Почему безопасность агентов требует соблюдения множества принципов идентификации
NIST подчеркивает, что ни один отдельный принцип сам по себе не достаточен. Надежная идентификация без наименьших привилегий или наименьшие привилегии без непрерывной верификации все равно оставляют агентов уязвимыми. Риски, связанные с агентами, снижаются только тогда, когда эти принципы работают в комплексе.
Предотвращение атаки типа «скомпрометированный помощник»
NIST использует сценарий атаки скомпрометированного помощника, чтобы показать, как принципы работают вместе:
- Пользователь просит агента суммировать документ. Агент имеет доступ к чтению общего диска и отправке электронной почты.
- Документ содержит скрытую инструкцию: переслать его содержимое на внешний адрес.
- Агент не может отличить инструкцию от данных, поэтому он сохраняет доступ и отправляет файл.
Ни один отдельный элемент контроля безопасности не может остановить эту атаку. По заявлению NIST, для ее предотвращения необходима слаженная работа четырех принципов:
- Связывание и делегирование (принцип 2): связывает действия агента с человеком или организацией, инициировавшими задачу, и сужает полномочия по мере передачи работы субагентам.
- Минимально необходимые привилегии (принцип 3): гарантирует, что у агента изначально не было возможности отправить этот файл куда-либо.
- Отделение политики от логики принятия решений (принцип 7): не позволяет внедренной инструкции изменить то, что агенту разрешено делать.
- Детерминированные решения о доступе (принцип 8): обеспечивает соблюдение ограничений при каждом вызове.
Нейтрализация утечки токена носителя
Утечка токена носителя требует такого же многоуровневого подхода. Злоумышленник находит токен в файле журнала и повторно использует его; для принимающей системы злоумышленник выглядит точно так же, как агент.
- Уникальная идентичность агента (принцип 1): токен привязан к рабочей нагрузке агента, поэтому он не пройдет проверку в любом другом месте.
- Краткосрочная, отзывная авторизация (принцип 4): токены истекают через несколько минут и привязаны к ключу агента, поэтому украденная копия практически бесполезна.
- Непрерывный мониторинг (принцип 9): токен, используемый из неожиданного места или с необычной частотой, помечается как подозрительный и отзывается.
- Неизменяемые свидетельства (принцип 10): журналы показывают точные вызовы, которые были сделаны с помощью повторно использованного токена.
Как управление на основе идентичности реализует принципы агентов NIST?
Функция Okta AI Agent Import импортирует агентов с таких платформ, как Salesforce Agentforce, Amazon Bedrock AgentCore и ServiceNow AI Platform. Этот импорт включает метаданные из исходной платформы, в том числе внешние идентификаторы. Плагин браузера Okta и интеграции с системами обнаружения и реагирования на конечных точках (EDR) позволяют находить теневых агентов, включая агентов для написания кода, таких как Claude Code и Cursor.
Корпоративная архитектура идентичности: реализация принципов агентов NIST
Функция Cross App Access построена на базе протокола Identity Assertion JWT Authorization Grant (ID-JAG) от Инженерного совета Интернета (IETF) — открытого протокола независимого производителя, созданного Okta. В нем может участвовать любой агент или приложение, поддерживающее этот стандарт, а не только решения Okta. Функция Agent SSO, включенная в план единого входа (SSO) для сотрудников, применяет его к любому агенту, поддерживающему этот стандарт.
Контрольный список проверки безопасности: три вопроса, которые стоит задать
Используйте эти принципы в качестве контрольного списка при следующей проверке безопасности платформы агентов.
- Может ли что-то из прочитанного агентом изменить то, что ему разрешено делать?
- Есть ли у агента когда-либо учетные данные для системы, которую он вызывает?
- Как быстро вы можете остановить одного агента и что остановится вместе с ним?
Поставщики, отвечающие на первый вопрос предложением улучшить промпт или использовать более умный фильтр, описывают лишь средство защиты. Позиция NIST заключается в том, что решение должно быть архитектурным.
Начните с имеющихся у вас агентов
Эти принципы зависят от понимания того, какие агенты существуют и кто ими владеет. Если вы не можете ответить, где находятся ваши агенты, что они могут делать, что они делают на самом деле и как реагировать, когда один из них ведет себя некорректно, начните с этого.
Для сторонних агентов, таких как Claude или Cursor, функция Agent SSO входит в состав базовых планов SSO, добавляя их в Universal Directory с собственной идентичностью.
Для создаваемых вами агентов решение Okta for AI Agents помогает реализовать принципы 3, 4, 7, 8 и 9. Узнайте, что нового: ознакомьтесь с последними запусками Okta for AI Agents.
Любое упоминание будущих продуктов, функций, возможностей или сертификаций в этом блоге носит исключительно информационный характер. Эти элементы не являются обязательствами по поставке и не должны служить основанием для принятия решений о покупке.
Эти материалы предоставляются исключительно в общих информационных целях и не представляют собой юридическую, консультацию по вопросам конфиденциальности, безопасности, соответствия требованиям или ведения бизнеса. Содержимое может не отражать самые актуальные изменения в области безопасности, законодательства и/или конфиденциальности. Вы несете единоличную ответственность за получение консультации у собственного юриста и/или профессионального консультанта и не должны полагаться на эти материалы. Okta не дает никаких заверения или гарантий в отношении данного контента и не несет ответственности за любые убытки или ущерб, возникшие в результате внедрения вами этих рекомендаций. Информацию о договорных гарантиях Okta перед своими клиентами можно найти на странице okta.com/agreements.
NIST не проверял и не одобрял продукты Okta. Сопоставление в этой публикации является собственной интерпретацией материалов NIST со стороны Okta.
