Пример внедрения · Данные и управление
Дать аналитикам агентов над рабочими данными — не раздавая ключей.
Команда данных хотела самообслуживаемых ИИ-агентов над хранилищем и внутренними API, но не мира, где ноутбук каждого аналитика хранит рабочие ключи. Портал onemcp удержал аутентификацию на стороне хоста, а доступ — централизованным.
- Отрасль
- Данные и аналитика
- Команда
- около 25 аналитиков плюс команда платформы данных из 4 человек
- Стек
- Snowflake · dbt · Postgres · внутренний API метрик · GitHub
# Кратко
- Ни одного рабочего ключа на машинах аналитиков
- 1 портал как центральная точка контроля доступа
- Новые инструменты добавляются централизованно, а не по ноутбукам
Иллюстративный сценарий по мотивам типичных внедрений onemcp. Команда является собирательным образом, а не названным клиентом; приведённые цифры носят представительный характер и не являются измеренными.
Предыстория
Команда данных примерно из двадцати пяти аналитиков хотела применять ИИ-агентов в повседневных делах: писать запросы, отслеживать определения метрик, проверять состояние конвейеров. У нужных им инструментов — Snowflake, dbt, внутреннего API метрик, нескольких реплик Postgres — имелись доступные MCP-серверы.
Препятствием никогда не был сам агент. Препятствием был вопрос, который служба безопасности задавала каждый раз: *где живут ключи?*
Задача
Очевидный путь состоял в том, чтобы отдать MCP-серверы каждому аналитику и позволить ему авторизоваться самому. Служба безопасности этого не одобрила бы — и была права.
- Ключи распространились бы. Два с половиной десятка аналитиков, каждый из которых держит на личной машине ключи к хранилищу и API, — это два с половиной десятка мест, откуда может утечь секрет, без чистого способа ротации.
- Доступ был по принципу «всё или ничего». Передать сервер означало передать всё, на что способен его токен, при почти полном отсутствии видимости, у кого что есть.
- Управление не масштабировалось. Проверять и отзывать доступ по одному ноутбуку — процесс, который никто не хотел брать на себя.
Подход
Команда платформы данных использовала единый портал onemcp как границу между аналитиками и рабочими системами.
- Ключи остаются на стороне хоста. Каждый вышестоящий сервис авторизуется один раз, в портале. Нативный вышестоящий OAuth и токены живут там — никогда на машине аналитика, никогда в репозитории. Агенты аналитиков подключаются к порталу, а не к базам данных.
- Доступ централизован. Какие серверы доступны и кому, решается в одном месте. Внедрение нового инструмента — это изменение портала; отзыв доступа не требует трогать чью-либо настройку.
- Каталог остаётся лёгким в контексте. Через Code Mode портал раскрывает
search,describeиexecuteвместо схемы каждого инструмента, поэтому агенты забирают лишь инструменты, нужные задаче, а контекст аналитика остаётся при анализе.
Результаты
- Никаких рабочих ключей на ноутбуках. Секреты живут в портале. Уход аналитика или потеря машины больше не означают аврала с ротацией ключей.
- Одно место управления. Служба безопасности проверяет и управляет доступом в портале, а не в двадцати пяти отдельных конфигурациях.
- Самообслуживание без разрастания. Аналитики получили своих агентов; команда платформы сохранила единую, поддающуюся аудиту точку контроля — а добавить следующий инструмент значит внести одно централизованное изменение.
Прорывом был не агент — а то, что мы смогли сказать ему «да». Доступ живёт в портале, поэтому службе безопасности нужно было проверить одно место, а не тридцать ноутбуков.