MCP (Model Context Protocol) — общий способ, с помощью которого программа с ИИ находит и вызывает внешние инструменты. В Eon такие обращения идут через шлюз: он определяет, кто отправил запрос, проверяет его права и только затем передаёт запрос дальше.
Две минуты в результатах Eon относятся к настройке доступа к инструментам для разбора сбоев. Это не срок обучения нового сотрудника и не время устранения неисправности.
Для разбора сбоя нужны журналы событий, показатели и код
Чтобы понять причину сбоя, инженеру часто приходится открывать несколько систем. В Grafana он проверяет показатели, в Kubernetes — состояние развёртывания приложения, в GitHub — связанные изменения кода. Дополнительно могут понадобиться сведения о работе облачного провайдера.
В Eon для каждого инструмента требовались свои данные входа, отдельный MCP-сервер на компьютере и настройка подключения. Доступ к тем же источникам был нужен и ИИ-помощнику службы эксплуатации — SRE-агенту. При этом у него должен был быть собственный набор разрешений, отличный от прав инженера. [1]
Каждое новое подключение добавляло данные входа, программу на компьютере и правила доступа, которые нужно было поддерживать.
Одна точка входа вместо настройки каждого инструмента
Команда выбирала между собственным сервером-посредником и Amazon Bedrock AgentCore Gateway. В первом случае пришлось бы самостоятельно поддерживать вход пользователей, преобразование протоколов, проверку прав и работу сеансов. Eon выбрала готовый сервис шлюза, через который можно проверять разрешения и запускать инструменты на удалённых серверах.
Отдельные MCP-серверы на компьютере
Инженеры настраивали данные входа для каждого инструмента и запускали несколько MCP-программ у себя. Для связи между аккаунтами AWS дополнительно требовалась настройка сети.
- Отдельная настройка входа в каждый сервис
- Около десяти локальных MCP-программ у одного разработчика
- Повторная настройка сети между аккаунтами AWS
Один адрес с проверкой прав
Инженер подключается к одному MCP-адресу и входит через корпоративную учётную запись. Шлюз показывает разрешённые инструменты, а выполняются они на удалённых серверах в соответствующих аккаунтах.
- Один вход через корпоративную учётную запись — SSO
- MCP-программы на компьютере больше не нужны
- Роли IAM связывают аккаунты без отдельного сетевого соединения VPC peering для каждого
Проверка доступа сохраняется. Команда задаёт общие правила на шлюзе, а он применяет их при обращении к инструментам. [1]
У инженера и ИИ-помощника отдельные учётные записи
Внедрение объединяет компоненты AgentCore Gateway, Runtime, Identity и Policy. Через них запросы идут к десяткам подключённых серверов, которые предоставляют сотни инструментов. Каждый запрос проверяется от имени того пользователя или агента, который его отправил.
Отдельные учётные записи людей и ИИ
Сотрудники используют единый корпоративный вход — SSO, связанный с Cognito. ИИ-помощник входит с собственными данными приложения и получает отдельный набор разрешений.
Правила доступа Cedar
Шлюз проверяет, может ли этот пользователь или агент вызвать выбранный инструмент и выполнить нужное действие. Проверка работает в системе доступа и не зависит от текста промпта.
Инструменты работают на удалённых серверах
Разрешённые запросы выполняются через MCP-компоненты в средах AgentCore Runtime. Для доступа к другому аккаунту система использует разрешённую роль IAM.
В рабочих системах Eon разрешено только чтение. Запись ограничена отдельными действиями в инструментах совместной работы — например, комментарием к запросу на изменение кода или к заявке. Такие действия мало влияют на работу систем, и для них нужны специальные разрешения. Агент не получает общих прав администратора. [1]
От всплеска ошибок к связанному изменению приложения
В статье AWS приведён пример: инженер разбирает ошибку сервиса через шлюз, не входя по отдельности в каждую систему.
Подключиться из редактора кода
Инженер открывает Claude Code, Cursor или Codex, указывает MCP-адрес шлюза и входит через корпоративную учётную запись.
Получить разрешённые инструменты
Шлюз собирает доступные действия подключённых серверов в один список.
Проверить всплеск ошибок
ИИ выбирает запрос к Grafana. Перед отправкой шлюз проверяет по правилам Cedar, имеет ли инженер право выполнить это действие.
Сопоставить с состоянием приложения
Следующими запросами ИИ проверяет состояние развёртывания в Kubernetes и связанный запрос на изменение кода в GitHub. Эти действия выполняются на разных удалённых серверах.
Собрать результаты в одном сеансе
Инженер видит связанные сведения в одном месте, не входя в каждый сервис заново. Для действий, которые могут повлиять на работу систем, нужны соответствующие отдельные разрешения.
Пример показывает общий доступ к инструментам. Он не подтверждает, что ИИ самостоятельно устраняет сбои или выпускает код в рабочую среду. [1]
Права проверяются перед каждым обращением к инструменту
Eon разделяет права на чтение сведений о рабочих системах, комментарии в инструментах совместной работы и изменение самих правил доступа. Правки Cedar проверяют в GitHub как изменения кода через запросы на слияние. Так сохраняется история изменений разрешений.
Доступ только для чтения
Права на инструменты рабочей среды ограничены ролью пользователя или агента. Доступ выдают по согласованию в момент, когда он нужен, и записывают в журнал. Сам вход в шлюз не открывает доступ ко всем рабочим системам.
Только явно разрешённые действия
Внутренний ИИ-помощник службы эксплуатации может выполнять отдельные действия с записью в инструментах совместной работы, если их разрешают правила Cedar. Это действия, которые мало влияют на работу систем: например, оставить комментарий. Разрешения менять рабочую инфраструктуру у агента нет.
Такой подход полезен и для ИИ, подключённого к CRM, системе заявок или инфраструктуре: разрешения нужно проверять перед выполнением действия. Одной инструкции в промпте недостаточно. [1]
Поиск инструментов и вход пользователей требуют отдельной настройки
AWS описывает не только результат, но и сложности, которые Eon встретила после запуска. Даже с общим шлюзом команде нужно продумать, как система будет работать при большом числе инструментов.
Большие списки инструментов
Если заранее включать в правила описания всех инструментов, размер политики Cedar может оказаться слишком большим. Для разных подключений Eon сочетает режимы DEFAULT и DYNAMIC: они по-разному получают список доступных действий.
Совместимость входа OAuth
Небольшой промежуточный сервис на API Gateway согласует различия в привязке сеансов. Благодаря ему обычные MCP-клиенты в редакторах кода могут пройти вход без доработки.
Избыточный набор действий
Дополнительные программы-обёртки в Runtime ограничивают список инструментов, который видит разработчик. Это сокращает лишнюю информацию и число непреднамеренных вызовов.
Доступ между аккаунтами
Правила доверия IAM разрешают шлюзу обращаться к нужным средам выполнения в других аккаунтах. Для каждого аккаунта не приходится заново настраивать сетевое соединение VPC peering.
Для сотен инструментов нужно заранее определить, как их находить, как ограничить размер правил и как обрабатывать токены доступа. Также нужны журналы действий и запрет по умолчанию на операции, которые агенту выполнять нельзя. [1]
По данным Eon, доступ к инструментам настраивается примерно за две минуты
AWS и Eon сообщают, что общий шлюз уже несколько месяцев работает внутри компании. Им пользуются более 100 разработчиков и ИИ-помощник службы эксплуатации. За это время система обработала около 10 000 сеансов.
Настройка доступа для нового инженера
До: Около 2 дней
После: Около 2 минут
Локальные MCP-программы на одном компьютере
До: 10
После: 0
Настройка данных входа для разработчика
До: Отдельно для каждой системы
После: Один корпоративный вход SSO
Правила доступа к инструментам
До: Отдельно для каждого инструмента
После: Общие правила Cedar
Подключение инструментов
До: Много отдельных соединений
После: Сотни инструментов через один адрес шлюза
Что эти цифры не показывают
Это заявленные Eon результаты работы инфраструктуры и доступа разработчиков. В статье нет независимого замера времени устранения сбоев, измеренного процентного улучшения точности ИИ или времени полного ввода сотрудников в работу по всей компании. Подтверждённая финансовая отдача от инвестиций также не опубликована.
Так можно организовать доступ и к другим бизнес-системам
Подход можно рассмотреть, если ИИ нужно читать сведения из нескольких систем, а у сотрудников и программ разные разрешения.
История клиента и его обращения
ИИ может читать историю клиента и готовить черновики следующих сообщений. Для реального изменения данных клиента требуется отдельное разрешение.
Проверка поставщика и заказа
Система может получать данные поставщика, уточнять состояние заказа и готовить отчёт о расхождениях без выдачи прав на оплату.
Документы проекта и сведения о сбоях
Можно объединить журналы событий, системы учёта задач и документацию проекта, сохранив права на уровне инструментов и журнал действий.
Общий адрес полезен, если разрешения во всех системах остаются актуальными, а допустимые действия ИИ соответствуют рискам для бизнеса.
Сначала определите разрешённые действия ИИ
Eon изменила способ подключения людей и ИИ к рабочим инструментам. Общая система доступа избавляет от повторной настройки. При этом отдельные учётные записи и проверка прав определяют, что может сделать каждый участник.
Шлюз упрощает подключение и проверяет права перед каждым обращением к инструменту.
Для B2B-компании поменьше можно сначала определить два-три источника данных, несколько действий только для чтения и одно требование к согласованию. Затем можно рассматривать инструменты с широкими правами на запись. Это рекомендация Maak.Digital по внедрению, а не описание продуктовых планов Eon.
К каким системам нужен доступ вашему ИИ-помощнику?
До внедрения разберём, из каких систем нужны данные, какие права потребуются ИИ и где человек проверит результат. Затем выберем первый рабочий процесс и показатель, по которому оценим результат.
Это независимый разбор стороннего внедрения, подготовленный Maak.Digital. Материал не описывает проект, выполненный Maak.Digital, и не является техническим аудитом, рекомендацией продукта или независимым воспроизведением заявленных результатов. Цифры, технические сведения и сроки приведены по сообщениям компаний и авторов указанной ниже публикации. Примеры применения в других отраслях показывают возможное использование подхода и не описывают внедрения Eon. Дата публикации разбора Maak.Digital — 20 октября 2026 года. Числовые показатели сообщены компаниями и не гарантируют такой же результат в другой организации. Описание процессов упрощено для объяснения; полное техническое описание находится в первоисточнике.