Один шлюз вместо десятка MCP-контейнеров: как не утонуть в наборе ИИ-инструментов

Подключить ИИ к 1С на одной базе это работа на вечер. Проблемы начинаются позже: когда серверов становится десять, разработчиков шесть, а правила доступа расползаются по их ноутбукам.

Пятница, перепроведение в боевой УТ

Отдел из шести разработчиков 1С в торговой компании подключил ИИ-ассистента к своим базам. Начали скромно: один mcp сервер для 1с, чтобы ассистент видел метаданные и искал по коду. За пару месяцев к нему приросли ещё пять контейнеров: отдельный для выполнения запросов, отдельный для семантического поиска, RAG-граф на своей СУБД, диспетчер как ещё один контейнер и локальная модель. Каждый жил в своём Docker, каждый включался в конфиге ассистента у каждого разработчика. Права, режим read-only и списки разрешённых операций лежали там же, на стороне клиента, в mcp.json каждого рабочего места.

В пятницу вечером новый сотрудник, чтобы не настраивать всё руками, скопировал конфиг у ведущего разработчика. В этом конфиге контейнер с пометкой «тест» на самом деле смотрел в боевую УТ: несколько недель назад строку подключения переставили на прод во время отладки и забыли вернуть. Новичок попросил ассистента почистить дубли контрагентов и перепровести документы за день. Ассистент через тот самый контейнер, у которого запись была разрешена, начал перепроводить документы в боевой базе. Регистры накопления по взаиморасчётам поехали в разгар закрытия месяца.

Дальше началось знакомое. Руководитель отдела спросил: кто запустил, через какой инструмент, к какой базе обращались, что именно выполнили. Единого ответа не нашлось. Один контейнер писал свой лог, другой не писал ничего, диспетчер знал только про свои вызовы. Картину собирали почти сутки, проведение восстанавливали руками.

Как из одного сервера вырастает зоопарк

История выше не про криворукого новичка. Она про архитектуру, в которую загоняет разрозненный набор MCP-инструментов. Логика роста простая: ассистенту нужны метаданные, значит нужен сервер метаданных. Нужен поиск по коду, значит второй сервер. Нужны запросы к данным, генерация макетов СКД, сравнение расширений .cfe, прогон тестов YAxUnit, значит третий, четвёртый, пятый. Каждый инструмент приезжает своим образом, своим контейнером, своими переменными окружения и своей инструкцией по запуску.

Сложность эксплуатации Docker с MCP для 1С растёт нелинейно. Пять контейнеров это пять точек обновления, пять наборов переменных, которые дрейфуют, пять мест, где может протухнуть строка подключения. Отдельная беда с диспетчером: в популярных сборках он сам оформлен как ещё один контейнер, а вместе с RAG-графом и локальной моделью стек легко перебирает десяток гигабайт только под инфраструктуру, до того как ассистент задал первый вопрос. Плюс перегрузка контекста: сырые дампы метаданных на тысячи строк ассистент вынужден глотать целиком, и токены утекают в никуда.

Почему правила на стороне клиента не держат периметр

Главная проблема не в числе контейнеров, а в том, ГДЕ живут правила безопасности. В связке из нескольких Docker-контейнеров с правилами на стороне клиента режим read-only, список разрешённых операций и выбор базы заданы в конфиге ассистента у каждого разработчика. Клиентский конфиг это не периметр: его правит сам пользователь, он не проверяется на стороне сервера, его нельзя проаудировать централизованно. Периметр размазан по N рабочим местам и держится ровно до первого скопированного конфига, первой забытой переменной окружения, первого сервера, который кто-то поднял с флагом «разрешить запись, я быстро проверю».

Нативные механизмы 1С тут помогают лишь частично. РЛС, ролевые права и журнал регистрации защищают сеансы живых пользователей в интерфейсе. Они не рассчитаны на то, чтобы гейтить поток вызовов от ИИ, который ходит через опубликованный HTTP-сервис в расширении, нередко в привилегированном режиме. Отдельная категория инструментов вообще отдаёт ассистенту execute_code за грубым списком разрешений: одна ошибка в промпте или одна инъекция, и в боевой базе выполняется произвольный код. Инъекции в промпт OWASP держит в верхней строке своего рейтинга рисков для LLM-приложений, и защита от них строится слоями, одной галочкой её не закрыть. Токен-маскировщики, которые прячут ФИО и телефоны, но не дают ни ролей, ни аудита, закрывают лишь узкий кусок и создают ложное ощущение контроля.

Свежие данные показывают, что страх обоснован. По совместному исследованию УЦСБ и ГК «Солар» (июль 2026, опрошены 102 компании), половина российских компаний, 50,5%, подозревает или уже фиксирует утечки данных через ИИ-инструменты. А среди тех, кто ИИ пока не внедряет, риск утечки исходников и коммерческой информации назвали главной причиной отказа 42,5% респондентов. Разрозненный набор контейнеров этот риск только умножает: чем больше точек доступа и чем меньше единого контроля, тем шире поверхность, за которой целиком не следит никто.

Что меняет единый управляемый шлюз

Разумная альтернатива это не ещё один контейнер, а один управляемый mcp шлюз 1с, через который проходят все обращения ассистентов и на котором централизованно живёт политика доступа. Правила уезжают со стороны клиента на сторону шлюза, где их не переопределить копированием чужого конфига.

Что это даёт на практике:

• Ролевые профили (RBAC) на самом шлюзе. Что разработчик, аналитик или внешний подрядчик может спросить и выполнить, решает роль на сервере, а не строчка в mcp.json на его ноутбуке.
• Жёсткий fail-closed read-only для боевых баз. Даже если ассистент попросит записать или перепровести в проде, шлюз откажет на своей стороне. Тот самый инцидент из начала статьи здесь не случается в принципе.
• Маршрутизация по нескольким инфобазам со статусами сред (прод, стейдж, тест) и квотами на каждую базу. База выбирается по идентификатору и статусу, а не по порту в дрейфующей переменной окружения.
• Единый журнал аудита: кто спросил, к какой базе обратился, что было разрешено и что заблокировано. На вопрос «кто и что запустил» есть один ответ, а не сутки раскопок.
• Управление рабочими местами и лицензирование по местам, с централизованным отзывом доступа, когда человек уходит из команды.

Работает всё это в вашем контуре: шлюз это один самодостаточный бинарь on-prem, данные не покидают периметр компании. Как устроена локальная граница и почему обращение к 1С не выходит наружу, подробно разобрано в нашей статье про локальный контур 1С, поэтому здесь не повторяюсь.

С 152-ФЗ ситуация та же по сути, но цена ошибки в 2026 году выросла. После поправок 420-ФЗ (действуют с 30 мая 2025) за утечку персональных данных для юрлица предусмотрен штраф от 3 до 15 миллионов рублей в зависимости от объёма, а за повторное нарушение введены оборотные штрафы, привязанные к годовой выручке. Любой ИИ, который читает справочник контрагентов или зарплатные регистры, работает с ИСПДн. Речь не про «сертификат соответствия»: on-prem-контур и меньший объём данных, доходящих до модели, снижают сам риск, а десяток неконтролируемых контейнеров, наоборот, его умножают. О законе стоит помнить всегда, но начинается всё с того, где физически лежат данные и кто ими управляет.

Один бинарь вместо контейнерного зоопарка

Операционный выигрыш не менее важен, чем безопасность. Один процесс проще развернуть, обновить и мониторить, чем стек из полудюжины контейнеров с диспетчером и графовой СУБД. Хранилище на выбор (PostgreSQL, SQLite или MSSQL), метрики наружу, и никаких лишних образов.

Тот же бинарь закрывает и dev-продуктивность, ради которой обычно и разводят зоопарк: статический анализ BSL с security-разметкой (CVSS и SARIF), оптимизатор запросов по типовым антипаттернам, сравнение конфигураций и расширений (.cfe) по структурному diff, генерация тестов под YAxUnit и Vanessa. Отдельные контейнеры под метаданные, поиск и тесты не нужны: это инструменты одного сервера. Маскирование ПДн на выходе шлюза готовится в Корпоративной редакции, так что о нём честнее говорить как о ближайших планах, а не как о том, что уже стоит в бесплатной версии.

Проверьте себя за пять вопросов

Быстрый способ понять, есть ли у вас проблема, это пройтись по короткому списку.

1. Сколько у вас MCP-серверов и где физически лежат их правила доступа? Если в клиентских конфигах, у вас не контроль, а договорённости.
2. Есть ли одно место, где видно все обращения ИИ к базам? Если журнал приходится собирать из логов разных контейнеров, аудита у вас нет.
3. Как разделены прод и тест: на уровне доступа или на уровне «мы условились не трогать»?
4. Кто и как отзывает доступ, когда разработчик уходит из команды?
5. Во сколько обходится держать в согласии N контейнеров против одного бинаря?

Если хотя бы один ответ неуютный, узкое место не в самих инструментах, а в отсутствии слоя управления над ними.

С чего начать

Если хочется просто попробовать, начните с бесплатной Открытой редакции: это персональный mcp сервер для 1с одним бинарём, без облака и без контейнерного стека, на своём железе. Когда встанет вопрос про доступ ИИ к нескольким боевым базам с ролями, аудитом и защитой прода, тот же продукт разворачивается в управляемый шлюз для всей команды в Корпоративной редакции.

Идея простая: не собирать безопасность из десятка контейнеров и клиентских правил, которые рано или поздно разъедутся, а поставить один управляемый шлюз и держать политику в одном месте. Посмотреть редакции и условия можно на feenlace.ru.