Что такое Agent Gateway?
Agent Gateway — это уровень обеспечения идентификации во время выполнения в Okta для ИИ-агентов. Он проверяет каждый запрос «агент-инструмент» на соответствие политикам идентификации с использованием обмена токенами RFC 8693. В отличие от традиционных шлюзов, которые полагаются на общие сервисные ключи, Agent Gateway требует учетные данные, указывающие как действующего ИИ-агента, так и пользователя-человека, что предотвращает атаки типа «confused deputy» (сбитый с толку заместитель) и несанкционированное наследование прав.
Если бы ИИ-агент в вашей среде вышел из-под контроля прямо сейчас, смогли бы вы сказать, от чьего имени он действовал, к чему обращался и когда? Многие команды безопасности не могут этого сделать.
ИИ-агенты появляются быстрее, чем средства контроля, предназначенные для управления ими. Шлюзы могут подключать агентов к инструментам. Однако немногие из них могут сказать, от чьего имени действует агент. Это пробел, которым могут воспользоваться злоумышленники, и он не проявится, пока что-то не пойдет не так.
Шлюзы продаются как средство контроля, но большинство из них не могут проверить, кто на самом деле стоит за запросом. Без этого они ничего не контролируют — они просто маршрутизируют вызовы и регистрируют произошедшее, используя те полномочия, которые им были предоставлены. Без идентификации в качестве основы шлюз — это контрольно-пропускной пункт без правил для соблюдения, без агента для атрибуции и без управления для применения.
Okta Agent Gateway устраняет этот пробел. Это уровень обеспечения безопасности во время выполнения в Okta для ИИ-агентов. Везде, где ИИ-агент может быть настроен на вызов внешнего протокола Model Context Protocol (MCP), Agent Gateway проверяет каждый вызов «агент-инструмент» на соответствие политике, изолирует учетные данные в момент действия и создает единый журнал аудита.
Okta for AI Agents добавляет основу идентификации и управления вокруг Agent Gateway: обнаружение агентов, регистрацию в качестве полноценных субъектов, рабочие процессы доступа, кампании по сертификации и корреляцию аудита между системами. Agent Gateway уже доступен в рамках Okta for AI Agents. Он отвечает на третий вопрос из плана для безопасного агентного предприятия: «Что делают мои агенты?»
В этом блоге вы узнаете об одной из главных проблем большинства агентных шлюзов: они могут подключить агента к инструменту, но не могут проверить, от чьего имени действует агент. И вы увидите, чем отличается Okta Agent Gateway: он не обработает вызов, если учетные данные не содержат имен пользователя и агента, стоящего за ним, что помогает гарантировать, что полномочия не будут заимствованы, переданы или унаследованы случайно.
Почему традиционные MCP-шлюзы не обеспечивают безопасность ИИ-агентов?
Традиционные MCP-шлюзы могут маршрутизировать запросы агентов к инструментам, но им часто не хватает критически важной защиты: они не могут проверить, от чьего имени действует агент.
Уязвимость «confused deputy» (сбитый с толку заместитель)
Давайте начнем с примера сценария, где у ваших агентов нет шлюза:
- Широкое предоставление учетных данных: Ваша команда создает HR-помощника для ответов на вопросы о записях сотрудников. Чтобы он работал для любого, кто задает вопрос, кто-то дает ему сервисную учетную запись с доступом на чтение ко всем записям.
- Несанкционированный запрос пользователя: Кэти — подрядчик. Она просит агента предоставить компенсацию генерального директора.
- Обход политики: Агент предоставляет ее, используя доступ, которым он законно обладает.
- Сбой аудита: Запрос выглядит абсолютно чистым в журнале аудита.
Ничего не было взломано. Единственное, что стояло между Кэти и этими данными, — это собственное суждение агента.
Это проблема «сбитого с толку заместителя»: запрос содержит запрос пользователя, но не его полномочия. Агент действует на основе того, к чему он может получить доступ, а не на основе того, что спрашивающий человек действительно имеет право знать. Это десятилетняя ошибка в работе прав доступа, и именно она проявляется, когда вы предоставляете агенту широкий доступ и доверяете ему самоуправление.
Ограничения традиционных архитектур MCP
Отзыв «все или ничего»
Отзыв общих учетных данных шлюза прерывает доступ для всех подключенных агентов, что заставляет администраторов оставлять чрезмерно разрешительные учетные данные постоянно активными:
- Администратор настраивает шлюз, подключенный к MCP-серверу GitHub, используя одни общие учетные данные
- Каждый агент, подключающийся через этот шлюз, наследует такой же широкий доступ
- Отзыв учетных данных прерывает доступ для всех агентов, работающих через него
- Результат: Никто их не отзывает
Токены носителя с единой идентификацией
Протокол MCP был разработан с учетом проблемы «сбитого с толку заместителя». Но существует фундаментальное ограничение: MCP работает на токенах носителя OAuth 2.1, которые называют только одну личность. Шлюз не может передать токен агента дальше — он должен создать новый. Поэтому, даже если шлюз хочет сказать GitHub: «это агент Кэти, действующий от имени Кэти», он не может этого сделать. Какую бы личность он ни выбрал, она станет единственной, которую увидит GitHub.
Защита с помощью промпт-инжиниринга не работает
Вы могли бы попытаться исправить это в промпте, сказав агенту никогда не обращаться к данным о компенсации. Скорее всего, он не будет. Но учетные данные все равно открывают все, поэтому самая эффективная защита — это если агент решит не смотреть, что и было исходной проблемой.
Okta Agent Gateway: Идентификационно-ориентированное обеспечение безопасности во время выполнения для ИИ-агентов, подключающихся к корпоративным инструментам
Agent Gateway, новая возможность Okta for AI Agents, — это точка контроля во время выполнения, которая определяет, к чему агент может подключаться и что он может делать во время каждого действия. Он не обработает вызов, если вызывающая сторона не предоставит учетные данные, называющие обе стороны — пользователя, запрашивающего действие, и агента, выполняющего запрос. Это требование обеспечения идентификации отличает его от шлюза, который просто ретранслирует трафик.
Настройка Agent Gateway.
Типичный шлюз может аутентифицировать, что чему-то разрешено подключаться. Agent Gateway проверяет, для какого пользователя предназначен запрос, какой ИИ-агент действует и был ли этот агент уполномочен действовать от имени этого пользователя, а затем применяет политику в момент выполнения вызова инструмента.
Каждый вызов инструмента атрибутируется управляемой личности агента, конечному пользователю, инструменту и результату.
Допустим, Кэти — сотрудник, и агент собирается сделать вызов от ее имени. Некоторые шлюзы аутентифицируют вызывающего абонента с помощью ключа платформы и принимают пользователя в качестве параметра:
Шлюз, построенный таким образом, может проверить ключ, но не может проверить Кэти. Ее имя — просто текст в запросе, введенный тем, кто сделал вызов, поэтому любой, у кого есть этот ключ, может представиться кем угодно.
Agent Gateway вообще не принимает такой тип учетных данных. Вместо этого Agent Gateway реализует делегирование, требуя, чтобы каждый вызов инструмента представлял учетные данные, выданные вашим поставщиком идентификации, содержащие два отдельных утверждения личности:
- Субъект (sub): Аутентифицированный конечный пользователь, запрашивающий действие
- Исполнитель (act): Зарегистрированный ИИ-агент, выполняющий запрос
Вот что Agent Gateway ожидает при каждом вызове:
Вызов предназначен для sub, а act указывает, кто его делает. sub_profile говорит, что вызывающий абонент — это приложение и агент.
Ничего не наследуется, поэтому Agent Gateway не может выдумать пользователя. Субъект в этих учетных данных — единственный пользователь, от имени которого Agent Gateway может действовать в рамках данного вызова. Когда Agent Gateway требуются учетные данные для MCP-сервера, он обменивает учетные данные агента в Okta и получает новые, привязанные к тому же пользователю, что соответствует семантике «действия от имени», определенной в RFC 8693. Okta может вернуть эти учетные данные только в том случае, если пользователь ранее дал согласие на MCP-сервере, используя подключение, зарегистрированное администратором.
Таким образом, агент не может убедить Agent Gateway действовать от имени кого-то другого. Кэти все еще может попросить об этом. Однако теперь Agent Gateway действует от ее имени с учетными данными, привязанными к ней, гарантируя, что агент может делать только то, что Кэти могла бы сделать сама.
Матрица возможностей обеспечения идентификации
В целом, шлюз может действовать только на основе того, что уже содержится в полученных им учетных данных. Содержат ли эти учетные данные реальную идентификацию пользователя и агента или не содержат ее вовсе — решается в момент их создания.
Okta Agent Gateway работает только на третьем уровне. Он не будет обрабатывать вызов, если учетные данные не являются проверенным делегированным токеном, указывающим как пользователя, так и агента.
Эффективные правила доступа агентов
На практике то, что агент может делать на самом деле, ограничено точным пересечением разрешений Agent Gateway и прав пользователя:
Что может делать агент = Что разрешает шлюз ∩ Что уже может делать пользователь
Что разрешает шлюз ← обеспечивается шлюзом
Что уже может делать пользователь ← обеспечивается MCP-сервером
Agent Gateway знает, какой агент выполняет вызов и какие инструменты открыты. MCP-сервер знает свои собственные записи и то, какие пользователи могут получить к ним доступ. Вам нужно и то, и другое.
Сам по себе Agent Gateway является зарегистрированной рабочей нагрузкой со своим собственным субъектом и не имеет постоянного разрешения на доступ к чему-либо. Администратор настраивает две вещи до того, как будет разрешен любой вызов:
- Ссылка на делегирование: предоставляет конкретному агенту разрешение на делегирование этому шлюзу от имени пользователя. Без нее обмен отклоняется.
- Подключение к ресурсу: предоставляет этому шлюзу разрешение на доступ к конкретному MCP-серверу и определяет, какие именно инструменты этого сервера открыты.
Ни одно из разрешений не выводится из данных вызывающего абонента и не предоставляется учетными данными агента. Доступ ограничен разрешениями на делегирование и ресурсы, которые настраивает администратор.
Управление идентификацией — это также основа управления затратами
AI-агенты не просто создают риски доступа — они могут создавать расходы с машинной скоростью. Агент, который неоднократно вызывает премиальный API, запускает дорогостоящие рабочие процессы или использует инструменты с высоким потреблением, может генерировать непредвиденные расходы задолго до того, как их заметит человек.
Управление затратами начинается с атрибуции. Если несколько агентов используют одни и те же учетные данные, трудно ответить на базовые вопросы, такие как: какой агент создал активность? От чьего имени он действовал? Какой инструмент или ресурс привел к затратам?
Okta Agent Gateway создает контекст идентификации, необходимый для ответа на эти вопросы. Поскольку каждый запрос привязан как к пользователю, так и к агенту, действующему от его имени, организации могут сопоставлять активность агента с инструментами и ресурсами, к которым он обращается. Это создает более четкую основу для мониторинга использования, расследования непредвиденной активности и применения управления по мере масштабирования развертываний агентов.
Скоро: поддержка Cross App Access и аварийный выключатель через Agent Gateway
Поддержка Cross App Access в Agent Gateway
Агентам необходимо обращаться к обычным SaaS-приложениям, таким как Slack или Salesforce, и у Okta есть протокол с открытым стандартом для этого: Cross App Access. Когда поддержка будет запущена, Cross App Access позволит AI-агентам безопасно получать доступ к приложениям от имени пользователя, сохраняя обе идентификации. Администратор один раз одобряет, какие приложения могут использовать агенты, вместо того чтобы каждый сотрудник одобрял каждое приложение самостоятельно.
Реализация этого через шлюз дает реальную выгоду: он предоставляет центральную точку управления для включения или выключения доступа агента, вместо того чтобы управлять им для каждого приложения отдельно.
Agent Gateway будет поддерживать Cross App Access в ближайшем будущем. Это позволит шлюзу показать «этот запрос поступил из разрешения, которое вы уже одобрили», а затем обменять это утверждение на новый токен без необходимости внесения каких-либо изменений на стороне приложения. Этот механизм предложен в черновике IETF Identity Continuation Assertion.
Аварийный выключатель на базе Agent Gateway
Наконец, поскольку каждый вызов инструмента проходит через единую точку принудительного исполнения во время выполнения, Agent Gateway может останавливать запросы в режиме реального времени. Когда функциональность аварийного выключателя станет доступна, она сделает деактивацию агента мгновенной, вплоть до уже выданных токенов, путем отклонения любого запроса, содержащего токен, выданный деактивированному агенту. Поскольку это будет обеспечиваться на границе Okta, не придется ждать, пока каждое подключенное приложение отзовет доступ независимо.
Как оценить шлюз для AI-агентов: четыре критических вопроса
Четыре вопроса покажут вам, чего стоит любой шлюз:
- Проверка эмитента: какие учетные данные получает MCP-сервер и кто их выдал?
- Подтверждение личности пользователя: может ли шлюз показать, для какого пользователя предназначен вызов, или пользователь — это параметр, который предоставляет вызывающая сторона?
- История согласия: чье согласие санкционировало доступ агента к этому MCP-серверу?
- Риск обхода: владеет ли агент когда-либо учетными данными, которые работают без шлюза в цепочке?
Agent Gateway создан, чтобы ответить на все четыре вопроса.
Agent Gateway — это часть более широкой картины: Okta for AI Agents — это более широкая платформа, которая обеспечивает видимость, контроль и управление, необходимые для защиты агентов, развертываемых вашим бизнесом.
Agent Gateway доступен в составе Okta for AI Agents без дополнительной оплаты.
Текущие клиенты: свяжитесь со своим представителем по работе с клиентами, чтобы начать использовать его уже сегодня.
Еще не являетесь клиентом Okta for AI Agents? Загрузите наш технический паспорт, чтобы узнать, как Okta for AI Agents может помочь вам безопасно управлять вашими AI-агентами из единой панели управления.
Любое упоминание будущих продуктов, функций, возможностей или сертификаций в этом блоге предназначено только для информационных целей. Эти элементы не являются обязательствами по поставке, и на них не следует полагаться при принятии решений о покупке.
Эти материалы предназначены только для общих информационных целей и не являются юридической, консультацией по вопросам конфиденциальности, безопасности, соответствия требованиям или ведения бизнеса.
Содержание может не отражать самые последние изменения в области безопасности, законодательства и/или конфиденциальности. Вы несете единоличную ответственность за получение консультации у своего собственного юридического и/или профессионального консультанта и не должны полагаться на эти материалы при принятии решений о соответствии требованиям, внедрении или покупке.
Okta не делает никаких заявлений и не дает никаких гарантий в отношении этого контента и не несет ответственности за любые убытки или ущерб, возникшие в результате внедрения вами этих рекомендаций. Информацию о договорных гарантиях Okta своим клиентам можно найти на сайте okta.com/agreements.
