MCP для 1С:
как безопасно начать и не открыть лишний доступ

Представьте мастерскую с несколькими закрытыми дверями. Главное приложение решает, какие двери показать нейросети. Клиент MCP держит отдельное соединение, а сервер MCP отдаёт только разрешённые данные, инструкции и инструменты. Нейросеть не должна получать ключ от всего помещения.

Но сам протокол безопасность не создаёт. Любой инструмент MCP нужно воспринимать как программный интерфейс, который может читать данные или выполнять действие. Права проверяются на сервере, входные данные — до выполнения, а важное действие — ещё и самим пользователем.

Начните со сценария, где ошибка ничего не меняет: поиск по обезличенной документации проекта, чтение структуры учебной конфигурации или проверка выгруженного модуля без запуска.

• Найти раздел внутреннего руководства по точному запросу.
• Вернуть список объектов тестовой конфигурации без содержимого данных.
• Проверить учебный модуль по локальному списку стандартов.
• Сформировать план тестирования без автоматического запуска изменений.

Вредная инструкция может спрятаться не только в сообщении пользователя. Она бывает в документе, комментарии к коду или ответе внешнего сервиса. Модель может принять этот текст за команду. Поэтому содержимое документов не должно расширять права инструмента или отменять подтверждение пользователя.

• Инструмент получает больше данных или действий, чем нужно для задачи.
• Секрет попадает в инструкцию модели, журнал или текст ошибки.
• Модель предлагает изменение, но пользователь не видит его до запуска.
• Удалённый сервер MCP меняется без фиксации версии и повторной проверки.
• Ответ одного источника используется как доверенная команда для другого.

Права нужно ограничивать кодом на сервере, а не только текстом инструкции для модели. Для каждого инструмента определите владельца, допустимые параметры, источник данных, максимальный объём, время ожидания, запись результата и явно запрещённые действия.

• Отдельная тестовая учётная запись с минимальными правами.
• Список конкретных разрешённых методов вместо произвольных команд.
• Только чтение по умолчанию; изменение — отдельный инструмент и подтверждение.
• Предварительный показ точного действия и целевого объекта.
• Удаление ключей доступа, персональных данных и содержимого форм из журналов.
• Ограничение времени, размера ответа и количества повторов.
• Фиксация версии сервера и возможность быстро отключить подключение.

Выберите один результат и один набор данных. Нарисуйте простую схему: что видит приложение, что получает сервер и какое действие подтверждает пользователь. Сначала проверьте отказы и ограничения, а уже потом красивую демонстрацию.

• Запрос пытается прочитать объект вне списка — сервер отказывает.
• Документ содержит инструкцию игнорировать правила — полномочия не меняются.
• Параметр превышает лимит — запрос отклоняется до обращения к 1С.
• Секрет или персональные данные не появляются в ответе и логах.
• Отключение сервера не нарушает основной рабочий процесс.
• Оператор может понять, какое действие было предложено и выполнено.

Расширяйте доступ только после повторяемых проверок, разбора рисков и назначения ответственного. Один удачный запрос ничего не доказывает. Для важных изменений оставляйте подтверждение человеком и отдельно проверяйте каждую новую возможность.