MCP для 1С: права доступа

Обновлено 8 сентября 2026 г. · 13 мин чтения

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

Что MCP-сервер на самом деле отдаёт агенту

При подключении сервер публикует список инструментов. По протоколу у каждого инструмента есть имя, текстовое описание и JSON Schema аргументов, а по желанию автора ещё схема ответа и аннотации поведения вроде «только чтение» или «может удалять данные». Кроме инструментов сервер может отдавать ресурсы и собственные инструкции по работе с ним.

Всё это уходит модели в системную инструкцию. Агент не подключается к вашей базе напрямую и не знает ни строки подключения, ни пароля. Он видит перечень доступных вызовов и вызывает их по имени с аргументами, а данные из базы достаёт сам сервер, под своей учётной записью.

Аннотации инструментов остаются заявлением сервера о самом себе. Спецификация MCP прямо требует от клиента считать их недоверенными, пока сервер не из доверенных. Инструмент с пометкой «только чтение» спокойно пишет в базу, если так написан его код, поэтому реальную границу задаёт роль пользователя в 1С, и проверять надо её.

Схема ответа — та часть описания, которую можно сверить с фактом. Если сервер объявил outputSchema, спецификация требует от него возвращать структурированный результат по этой схеме, а клиенту предписывает такой результат проверять — требование к серверу здесь жёстче, чем к клиенту. На поле прав это не влияет, зато сужает то, что вообще способно приехать в контекст модели из одного инструмента. Инструкции, которые MCP-сервер присылает при подключении, доходят до агента наравне с вашими, и чужой сервер может влиять на его поведение текстом, который вы не читали. Спецификация предписывает показывать аргументы вызова человеку до обращения к серверу.

Почему «агент видит базу» не означает права администратора

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

Права пользователя 1С работают для OData в полном объёме: что этому пользователю не видно в интерфейсе, того он не получит и через запрос. Ограничение доступа на уровне записей (RLS) отсекает записи вне отбора — без специального параметра запроса такой запрос вообще завершится ошибкой, а с ним вернёт только разрешённые записи. Состав стандартного интерфейса OData определяет, какие объекты метаданных вообще выходят наружу. Набор инструментов сервера сужает картину ещё раз, но именно он и держится слабее всех.

Три верхних слоя настраиваются в самой 1С и к MCP отношения не имеют. Коротко: наружу по умолчанию не уходит ничего, пока объект не внесён в состав интерфейса явно; режим совместимости с версией 8.3.4 эту избирательность отменяет и открывает всё поддерживаемое разом; отчётов, обработок, регламентных заданий, внешних источников и журнала регистрации через OData нет в принципе; а пользователю вместо полных прав достаточно роли УдаленныйДоступOData. Как это устроено целиком — как включается публикация, что именно интерфейс не отдаёт, как ведут себя RLS и параметры запроса — разобрано отдельно: что 1С отдаёт наружу по OData и чего не отдаёт. Здесь важно другое: настраивает это администратор базы один раз, а агент про эти настройки ничего не знает и спросить о них не может.

Поэтому перед подключением сервера сделайте две вещи своими глазами. Первое — откройте $metadata ровно тем пользователем, под которым сервер будет ходить в базу. То, что вы там увидите, и есть картина мира агента: не то, что задумывал администратор, и не то, что написано в описании инструментов. Второе — заведите под MCP отдельного служебного пользователя, а не переиспользуйте того, под которым ходит ночная выгрузка: по нему видно, что именно вытянул агент, и права режутся независимо. Полные права не давайте — это ровно тот случай, когда «пока настроим, потом сузим» остаётся навсегда.

Отдельно про канал, потому что для агента он тот же, что и для любого другого клиента. Авторизация идёт заголовком Authorization: Basic с логином и паролем в base64, а base64 строку только кодирует, не шифруя. Публикация OData по обычному HTTP наружу становится самостоятельной уязвимостью независимо от того, кто на другом конце. И одна оговорка про границы протокола, которая касается именно агента: закрытие месяца через штатный OData не запустить, а вот у документов доступны их собственные методы, поэтому провести или распровести документ агент может — выглядит это обычным POST-запросом, и право проведения у служебного пользователя отбирается осознанно.

Где живёт пароль и с чьими правами работает сервер

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

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

Пароль служебного пользователя при локальном подключении попадает в конфигурацию редактора. Обычно это файл mcp.json — в профиле пользователя либо рядом с проектом; точный путь смотрите в документации своего редактора. Если редактор умеет спросить значение один раз и положить его в защищённое хранилище, пользуйтесь этим; если пароль остаётся в JSON открытым текстом, этот файл нельзя коммитить, а именно там его чаще всего и находят.

Сервер, который ходит мимо OData

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

Свой HTTP-сервис на встроенном языке возвращает всё, что написано в его коде, и права применяются к тому пользователю, под которым он выполняется; состав интерфейса OData на выдачу такого сервиса не влияет. Прямое подключение к СУБД снимает и это: роли и RLS проверяет платформа 1С; сервер базы данных о них ничего не знает и отдаёт всё подряд — роль служебного пользователя на такой выдаче не сказывается никак.

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

Персональные данные и зарплата в выгрузке

В справочнике сотрудников лежат ФИО, паспорта, адреса, телефоны, в регистрах начислений хранятся суммы по каждому человеку, в контрагентах записаны контактные лица с почтой. Агент это не «посмотрит и забудет». Контекст ничего не забывает. Любой результат вызова инструмента попадает в него и вместе с запросом уезжает провайдеру, если модель облачная.

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

Что происходит на боевой базе

Запрос по OData идёт в ту же рабочую базу, где сейчас работают люди. Он читает данные через сервер приложений и конкурирует с пользователями за те же ресурсы, поэтому массовая выборка легко превращается в чужие таймауты. Для интеграций по OData стандартно рекомендуют забирать данные порциями через $top и $skip, вместо одного запроса на всю таблицу. Про поведение агента замера у нас нет. Всё, что сказано о нём дальше, выведено из спецификации MCP и документации редактора: связку «MCP-сервер над OData плюс живой агент» мы на базе не поднимали и частоту промахов не считали. Границы прав это не двигает — платформа проверяет их на каждом обращении, кто бы ни пришёл. А как агент распорядится открытым ему куском, видно только на своей конфигурации.

С агентом правило про порции ломается сразу. Агент не знает, что в вашем регистре продаж восемь миллионов строк. Он видит имя сущности и делает запрос, который кажется ему разумным. Ограничение ставится на сервере. Это жёсткий предел на количество возвращаемых записей, обязательный отбор по периоду, отказ на запрос без фильтра.

Отсюда простое правило. Первый заход — на копии.

Самый спокойный сценарий начинается с копии базы. Для задач «объясни структуру», «найди, где используется этот реквизит», «напиши запрос по этим регистрам» свежая рабочая база не нужна. Подойдёт копия с обезличенными данными, поднятая отдельно. Там же можно спокойно дать агенту право записи и проверить его правки, не рискуя проведёнными документами.

Отвечает уверенно по неверным данным

Через OData данные приходят как есть. Логику, которую пользователь применяет в голове, никто не применяет за него.

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

Два способа не дать агенту выдумать реквизит

Модель знает платформу 1С хуже массовых языков и легко выдумывает правдоподобные имена реквизитов, которых в вашей конфигурации нет: Контрагент вместо Партнёр, СуммаДокумента вместо СуммаВзаиморасчётов. Выглядит это как рабочий код, который падает на первом же выполнении.

Первый способ — дать инструмент чтения схемы и требовать читать метаданные объекта до написания запроса. Второй — поставить ссылку на $metadata прямо в описание инструмента, чтобы агент знал, откуда брать правду, даже без отдельного вызова. Когда ответ всё равно расходится с конфигурацией, чаще всего объекта просто нет в опубликованном составе. Тот же приём работает и вне MCP: агент, у которого перед глазами выгруженная в файлы конфигурация, выдумывает имена заметно реже.

С чего начинать

• Заведите отдельного служебного пользователя с ролью УдаленныйДоступOData. Полных прав не давайте.
• Публикуйте только по HTTPS и закройте адрес сетью или списком IP.
• Внесите в состав интерфейса OData объекты текущей задачи и ничего сверх этого. Кадровые и зарплатные объекты не публикуйте.
• Посмотрите режим совместимости конфигурации. На 8.3.4 и ниже избирательный состав не работает.
• Прочитайте, каким способом сервер читает базу. Строка подключения к СУБД в его настройках означает, что права 1С к делу больше не относятся.
• Поставьте на стороне сервера предел на количество записей в ответе и потребуйте обязательный отбор по периоду.
• Первый заход сделайте на копии базы. Боевую подключайте, когда станет понятно, какие запросы агент реально делает.

Частые вопросы