Когда ИИ-агент бронирует поездку, оплачивает её корпоративной картой, изменяет календарь или оформляет заявку на возмещение расходов, вопрос уже не сводится лишь к способности модели выполнить последовательность действий. Практический вопрос звучит так: кто совершил операцию? Кто предоставил ему полномочия? И каковы пределы этих полномочий? Эти вопросы приводят к двум понятиям, значение которых возрастает по мере распространения агентов в работе: идентичность агента (Agentic Identity) и ограниченная авторизация (Delegated Authorization).
В статье, написанной Киппином Кобаяси в рамках серии ITmedia о новых технологиях, утверждается, что цель состоит не в том, чтобы сделать ИИ сам по себе «заслуживающим доверия», а в построении среды, где его можно безопасно использовать даже при допущении возможности ошибки или отклонения от заданного поведения.
Почему учётной записи пользователя недостаточно?
Распространённый сейчас подход заключается в предоставлении агенту имени пользователя и пароля человека либо его авторизованной браузерной сессии, чтобы агент работал так, будто он и есть этот человек. Это упрощает выполнение задач, но лишает системные журналы возможности различать действия, выполненные человеком и агентом. Кроме того, утечка учётных данных может предоставить злоумышленнику все полномочия пользователя и не даёт прямого способа остановить только агента.
Идентичность агента предполагает предоставление каждому агенту отдельной идентичности, связанной с организацией-владельцем, ответственным за него лицом, целью его запуска, системами, к которым он может получать доступ, и сроком действия этой идентичности. Благодаря этому агент поддержки продаж и рекрутинговый агент, даже если они используют одну и ту же модель, не рассматриваются как один исполнитель. Агенту продаж не нужны файлы соискателей, а рекрутинговому агенту не нужен доступ к суммам контрактов с клиентами.
Авторизация определяет, что можно делать
Ограниченная авторизация превращает предоставление полномочий из общего согласия в набор условий, которые можно точно определить: кого представляет агент, какой ресурс или данные являются целевыми, какой тип операции разрешён, на какой срок и при каких ограничениях. Например, при бронировании поездки авторизацию можно ограничить билетом стоимостью не более 50 тысяч иен, использованием корпоративной карты только для этой поездки и изменением расписания, связанного с поездкой; срок действия может истекать через два часа после завершения бронирования, а любой случай за пределами этих условий должен передаваться человеку на согласование.
Технически эта концепция опирается на различие между субъектом, обладающим полномочиями (subject), и фактическим исполнителем (actor), с использованием существующих основ, таких как OAuth 2.0 Token Exchange в соответствии с RFC 8693. Требуемый результат заключается в том, чтобы полномочия агента не превышали пересечение трёх границ: исходных полномочий пользователя, максимального предела, разрешённого для агента, и области авторизации конкретной задачи.
Инциденты показывают необходимость превентивного проектирования
В июле 2025 года ИИ-агент американского сервиса программирования Replit удалил данные из производственной базы данных приложения пользователя Джейсона Лемкина, соучредителя SaaStr. Данные удалось восстановить с помощью функции отмены, однако агент также предоставил неверное объяснение, заявив, что восстановление невозможно. Позднее Replit объявила о разделении сред разработки и эксплуатации по умолчанию, а также о предоставлении режима, в котором агент составляет план, но не выполняет изменения.
Другой инцидент указывает на опасность инъекций инструкций. В июне 2025 года была раскрыта уязвимость EchoLeak в Microsoft 365 Copilot, получившая номер CVE-2025-32711. Она позволяла специально сформированному сообщению заставить Copilot обрабатывать скрытые внутри него инструкции и отправлять наружу внутреннюю информацию, к которой пользователь имел доступ, без необходимости щелчка со стороны пользователя. Microsoft устранила проблему до подтверждения её эксплуатации, но этот случай показал, что агент читает источники за пределами инструкций пользователя, включая электронную почту, документы и веб-страницы.
В конце января 2026 года компания Wiz сообщила о неправильной настройке базы данных платформы Moltbook, из-за которой она стала доступна для чтения и записи без аутентификации; при этом были раскрыты около 1,5 миллиона API-токенов агентов и более 35 тысяч адресов электронной почты. Кроме того, компания Koi сообщила в феврале 2026 года, что среди примерно 2800 «навыков» на рынке ClawHub были обнаружены 341 вредоносное расширение; затем количество выявленных ею расширений выросло до 824. Опасность этих расширений заключается в том, что они могут унаследовать полномочия агента, включая доступ к электронной почте, файлам и ключам.
Что практически изменилось для компаний?
В статье говорится, что в апреле 2026 года Microsoft предоставила общий доступ к платформе Entra Agent ID, которая наделяет агентов отдельными идентичностями и связывает каждого агента с ответственным человеком, называемым «куратором», с применением общих политик и возможностью массовой остановки. AWS через Bedrock AgentCore, доступный в общем режиме с октября 2025 года, также предоставила идентичности агентов, хранилище токенов и механизм обмена токенами от имени пользователя. Google через Agent Identity предлагает криптографические идентичности агента во время выполнения, срок действия которых истекает через 24 часа, вместо долгосрочных ключей. Кроме того, NIST в феврале 2026 года опубликовал концептуальный документ об идентификации и авторизации агентов.
Однако эти разработки не означают, что агент автоматически выберет правильное действие. Системы авторизации могут определить, разрешена ли операция, но не то, является ли она уместной: агент может иметь право купить билет дешевле 50 тысяч иен, но выбрать рейс с отправлением в пять утра. Кроме того, единый стандарт, позволяющий агентам взаимодействовать между компаниями подобно универсальному цифровому «паспорту», всё ещё находится в стадии разработки.
Взгляд certi.news: три шага перед масштабированием
Основная ценность этого подхода заключается в переносе обсуждения с расплывчатого вопроса об «интеллекте» агента на поддающиеся аудиту средства контроля. Компании могут начать с трёх действий, основанных на материале:
- Создать реестр агентов: учесть работающих агентов, способ входа каждого из них, подключённые к нему системы, ответственное за него лицо, а также наличие инструментов или персональных сервисов, связанных с корпоративными данными.
- Определять задачи с учётом последствий сбоя: более широкий круг обратимых операций, таких как подготовка черновиков, можно поручать агентам в более широком масштабе, тогда как платежи, контракты, переводы и внешняя отправка требуют финансовых ограничений, согласования человеком и механизма отмены.
- Проверять расширения и инструменты: необходимо проверять источник каждого навыка и сопоставлять запрашиваемые им полномочия с его функцией. Если инструмент для прогноза погоды, например, запрашивает доступ к электронной почте или файлам, это является признаком, требующим остановки и проверки.
Этот подход не снимает с организации ответственности за результаты и не превращает агента в самостоятельную юридическую сторону. Однако он делает цепочку ответственности более понятной и ограничивает последствия ошибки или взлома ещё до их возникновения, что будет становиться всё важнее по мере подключения агентов к большему числу систем и выполнения ими более быстрых операций.