АНАТОМИЯ ФИЧИ: Как устроен MCP Gateway в UberПодключить MCP-сервер к агенту – это строчка в конфиге, операция настолько дешёвая, что корпоративное внедрение MCP легко принять за неё же, помноженную на число команд.
У Uber за одним входом больше тысячи MCP-эндпоинтов, и хостинг там самая скучная часть работы.
🔬 Команды Uber MCP-серверы не пишут
Внутренних сервисов больше десяти тысяч, каждый описан proto- или thrift-файлом, и любой такой эндпоинт становится MCP-сервером изменением конфига. Для своих сервисов Gateway генерирует MCP-серверы сам, а сторонние SaaS проксирует.
⚙️ Описание инструмента живёт по правилам кода
Если серверы никто не пишет руками, откуда берётся описание инструмента, по которому агент его и выбирает? Черновик пишет модель: краулер обходит эти proto и thrift, описания составляет LLM по именам сообщений и комментариям.
Напрямую в раздачу правка не идёт. Владелец сервиса открывает дифф, дифф уходит в сканер инженерной безопасности, и только после скана изменение доезжает до gateway'я.
Проходить весь этот путь описание обязано потому, что одобренное можно изменить задним числом, а повторно никто не переспрашивает. В старой версии Cursor одобрение привязали к имени записи MCP-сервера, и подменённую внутри неё команду IDE запустила молча (CVE-2025-54136).
Цену за безопасность Uber платит скоростью: поправить описание инструмента стоит полного цикла ревью, и инструменты меняются не быстрее, чем код. Размен оправдан, пока агент по неверному описанию ломает больше, чем стоит эта очередь.
🧬 В диффе написано "Monitoring Agent"
Описание закрывает половину вопроса. Вторая половина: кто стоит за вызовом.
Инженер просит Oncall Agent разобраться с алертом, тот делегирует Investigation Agent, а дифф с новым порогом открывает третий, Monitoring Agent. Дежурного, с которого всё началось, в авторстве нет.
Протокол тут не помощник: авторизация в MCP помечена как OPTIONAL и опознаёт в лучшем случае непосредственного клиента.
Личность агента Uber описал вне протокола: выдать агенту токен вправе только Security Token Service. Agent SDK просит у него JWT, аутентифицируясь удостоверением своего workload'а (процесса на хосте), а STS через Agent Registry проверяет, что этот workload вправе хостить заявленный
agent_id.Токен несёт аттестованную цепочку акторов: gateway видит
[user1, oncall-agent, investigation-agent].Собрать эту цепочку снаружи нельзя: контекст исполнения рождается в приложении агента, поэтому обмен токенами живёт в его SDK. Готовый agentgateway Uber рассматривал и отказался.
🤝 Доступ агента к внутренним инструментам в других системах
Отсюда и расхождения: границу доверия каждый проводит в своём месте.
🔸 AWS Bedrock AgentCore Gateway – склеивает подключённые цели (targets) в один виртуальный MCP-сервер, каталог по умолчанию обновляется вызовом API.
🔸 Google Agent Gateway – граница в IAM: Identity-Aware Proxy включён всегда, незарегистрированное закрыто. Идентичность агенту выдают, а цепочку "кто кого попросил" дальше не переносят.
🔸 Cloudflare Code Mode – граница в песочнице: код исполняется в изолированном V8 и ходит наружу только через bindings, ключи держит супервизор.
🔸 Block с агентом Goose – центрального прокси нет: сервер проходит два ревью в allow-list, а нужные серверы агент включает на клиенте под запрос.
Главный выбор здесь в том, кто отвечает за описание инструмента и за личность того, кто его вызвал.
Пока агенты у вас только читают и никто не спрашивает "кто это сделал", хватает памяти одного человека. Считать порог надо не по числу агентов, а по числу мест, где ответить уже некому.
Вторая команда-потребитель – самое раннее, когда gateway осмыслен; строить пора с третьей.
📚 Что почитать:
"
Solving the Identity Crisis for AI Agents" – Uber Engineering, 21.05.2026"
Running a Software Factory Efficiently at Uber Scale" – Uber Engineering, 27.08.2026