Uber рассказал о внутренней схеме, которая позволяет не терять права ИИ-агентов, контекст пользователя и цепочку действий в многошаговых AI-процессах. Для русскоязычных команд, которые уже экспериментируют с MCP, внутренними copilot’ами и автоматизацией через агентов, это важный сигнал: старые модели доступа здесь не работают, а раздавать агентам один «сервисный» логин на всех — быстрый путь к инциденту.
О подходе компании 17 июня 2026 года сообщило InfoQ. Повод не академический: Uber говорит, что система уже используется тысячами внутренних агентов, а P99 задержки API для обмена токенами остается ниже 40 мс. То есть речь не о красивой схеме на слайде, а о попытке решить реальную проблему в проде, где агент не просто отвечает на вопрос, а ходит по внутренним инструментам, дергает сервисы и делегирует задачи другим агентам.
Главная сложность в том, что агент плохо вписывается в привычные категории IAM. Пользователь обычно ограничен интерфейсом, сессией и явными действиями: нажал кнопку, получил результат. Бэкенд-сервис, наоборот, предсказуем: у него фиксированный код, понятные вызовы и более-менее стабильный периметр. Агент устроен иначе. Он может разбить задачу на шаги, вызвать инструменты, передать часть работы другому агенту и сделать это от имени человека, который не утверждал каждое конкретное действие. Именно поэтому права ИИ-агентов нельзя сводить ни к пользовательской сессии, ни к классическому service account.
В Uber эту задачу решают через связку из нескольких компонентов: Agent Registry, AI Agent Mesh, Security Token Service, MCP Gateway, AI Gateway или AI Guard и downstream-системы. Agent Registry хранит связь между агентом и тем workload, где он вообще имеет право жить. Security Token Service проверяет эту связку и на каждом переходе выдает короткоживущий JWT. Дальше MCP Gateway контролирует доступ к внутренним инструментам, проверяет политики и при необходимости вырезает чувствительные данные. Ключевая идея в том, что по цепочке не летит один долгоживущий ключ. Каждый агент, получив входной контекст, локальные метаданные, целевую аудиторию и workload identity от SPIRE, запрашивает новый токен под конкретный следующий шаг. Концептуально это похоже на OAuth 2.0 Token Exchange, но с доработкой под агентскую идентичность, аудит и внутренние требования по производительности.
Самая интересная деталь здесь — так называемая actor chain, цепочка участников. В примере Uber дежурный инженер просит Oncall Agent разобраться с проблемой. Тот делегирует работу Investigation Agent, а уже потом кто-то из них идет во внутренний инструмент через MCP Gateway. В токене при этом сохраняется не только непосредственный вызывающий, но и вся цепочка: исходный человек, первый агент, второй агент. Для downstream-систем это критично. Они могут принимать решение не по принципу «запрос пришел от доверенного сервиса, пропускаем», а по более взрослой логике: кто инициировал действие, какой агент его выполняет, есть ли у него право на этот инструмент и не вышел ли он за рамки исходного поручения. Если говорить проще, права ИИ-агентов начинают жить не в табличке «кому можно всё», а в конкретном контексте задачи.
На ту же проблему с другой стороны смотрит Auth0. В изложении Cameron Pavey для production-систем с агентами нужны как минимум три слоя защиты: capability-scoped permissions, task-scoped credentials и layered enforcement. Перевод на человеческий язык такой: агенту нельзя выдавать доступ «на всякий случай», доступ должен быть привязан к конкретной способности и конкретной задаче, а контроль надо дублировать на нескольких уровнях — у провайдера идентичности, в рантайме агента и на уровне инструмента. В случае Uber эти идеи практически совпадают с per-hop token exchange, audience scoping, проверкой через registry и контролем на gateway-слое. Это показательный момент для рынка: разные игроки приходят к одной и той же мысли. Автономность агента полезна ровно до тех пор, пока ошибка агента не превращается в широкий blast radius внутри компании.
Отдельно Uber подсветил разработческую сторону вопроса. Компания сначала рассматривала внешний прокси для вызовов agent-to-agent, но быстро уперлась в проблему потери контекста. Если identity propagation не живет в стандартном клиентском пути, команды начинают реализовывать ее каждая по-своему, а потом безопасность получает коллекцию «почти одинаковых» костылей. Поэтому Uber сделал стандартный A2A-клиент, который автоматически занимается обменом токенов и передачей actor chain. Для инженерных команд это, пожалуй, самый практичный вывод из всей истории. Без secure-by-default SDK и единого клиентского слоя права ИИ-агентов очень быстро превращаются в локальные договоренности в коде, которые никто не сможет нормально аудировать через полгода.
Для разработчиков, архитекторов и ИТ-руководителей здесь есть несколько прямых выводов. Во-первых, агентам нужен отдельный контур идентичности, а не переиспользование старых сервисных учеток. Во-вторых, доступ должен быть короткоживущим и одношаговым: выдал токен на конкретный hop, ограничил Audience, через несколько минут токен умер. В-третьих, точкой контроля становится gateway к инструментам и внутренним системам, особенно если компания идет в сторону MCP. И наконец, аудит должен видеть не только «какой сервис стучался», но и полную причинно-следственную цепочку от человека до инструмента. Это уже не nice to have, а базовая гигиена для любой организации, которая собирается всерьез внедрять агентные сценарии в поддержку, on-call, аналитику, разработку или внутренние операции.
Следующий большой вопрос для отрасли звучит так: успеют ли стандарты догнать практику. Uber уже смотрит на работу IETF WIMSE и черновики по аутентификации и авторизации AI-агентов. Но пока рынок движется быстрее спецификаций, каждая крупная команда будет собирать свой вариант Zero Trust для агентных систем. И похоже, что через год спор будет уже не о том, нужны ли отдельные права ИИ-агентов, а о том, кто сумел встроить их в прод так, чтобы безопасность не убила полезность, а полезность не убила безопасность.