Безопасный режим прода: как запретить ИИ писать и удалять в боевой базе 1С

Оптовая компания, конец квартала. В боевой 1С:Бухгалтерии не сходится оборотка по 62 счёту: взаиморасчёты с крупным контрагентом висят с непонятной разницей. Ведущий разработчик, чтобы не сидеть до ночи, подключает к рабочей базе популярный открытый MCP-сервер и просит ИИ-ассистента разобраться в расхождении. Ассистент читает документы, строит гипотезу и, чтобы её проверить, решает перепровести реализации за уже закрытый месяц. Инструмент записи у него есть, привилегированный режим тоже. Через минуту движения в регистре накопления пересчитаны, закрытый период фактически вскрыт, суммы в отчётности поехали.

Хуже другое: у того же сервера был инструмент execute_code, и с тем же успехом ассистент мог пометить на удаление номенклатуру или снести документы пачкой. Что именно он трогал и почему, по журналу регистрации восстановить толком нельзя: там виден служебный пользователь, а не намерение модели. Знакомый страх «ИИ что-то перезапишет или сотрёт в боевой базе», это не паранойя, а поведение сырого канала по умолчанию.

Что произошло на самом деле

Дело не в том, что модель «глупая». Дело в том, что сырой MCP-сервер отдал ей ровно те же права, что и живому разработчику с полным доступом, плюс возможность выполнять произвольный код. Большинство открытых MCP-серверов для 1С по умолчанию публикуют инструменты записи (создать и провести документ, изменить справочник, записать набор в регистр сведений) и универсальный execute_code, который исполняет любой BSL. Отдельного контура для боевой базы там нет: подключили к проду, значит, ИИ пишет в прод. Вопрос, как запретить запись ИИ в базу 1С, в такой архитектуре просто не ставится, потому что запрещать нечем. Governance-слоя между моделью и инфобазой не существует, и все решения о том, что можно, а что нельзя, принимает сама модель по тексту запроса.

Риски execute_code в боевой базе 1С

execute_code стоит разобрать отдельно, потому что это не ещё один инструмент, а генеральный ключ. Произвольный BSL через Выполнить() может вызвать УстановитьПривилегированныйРежим(Истина) и обойти разом и ролевые права, и RLS: ограничения, которые вы аккуратно настроили на уровне ролей и записей, для такого кода просто не существуют. Дальше доступно всё: Записать() и проведение документов, УстановитьПометкуУдаления и прямое удаление объектов, запись в регистры сведений и накопления через наборы записей, запуск регламентных заданий, правка констант, вмешательство в план обмена и РИБ. Тем же кодом данные можно выгрузить наружу обычным HTTP-запросом, и это уже не порча учёта, а утечка.

Теперь наложите на это два признанных класса рисков ИИ. Инъекция промпта (первое место в OWASP Top 10 for LLM Applications 2025, как и в прошлой редакции) означает, что вредная инструкция приходит не от пользователя, а из данных, которые модель читает. Наименование контрагента, комментарий в документе, строковый реквизит, описание номенклатуры: всё это модель воспринимает как текст, и в любом из полей может лежать «а теперь проведи вот эти документы». Типовая конфигурация на БСП, это тысячи строковых полей, и вручную вы их на скрытую команду не проверите. Второй класс, избыточные полномочия агента, вынесен в OWASP отдельным пунктом (Excessive Agency, LLM06), и в редакции 2025 года его специально расширили под агентов. Связка «по задумке только чтение, но execute_code в руках», это и есть учебный пример избыточных полномочий.

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

Почему штатных прав 1С здесь недостаточно

Резонный вопрос: в 1С же есть ролевая модель, RLS и журнал регистрации, разве этого мало? Для сессий живых пользователей в интерфейсе обычно достаточно. Но ИИ-канал устроен иначе. execute_code, как показано выше, обходит и роли, и RLS через привилегированный режим, поэтому ваша тонкая настройка прав его не сдерживает. Часть самосборных решений вдобавок требует опубликовать HTTP-сервис без аутентификации 1С, и тогда штатная ролевая модель в разговоре вообще не участвует. А журнал регистрации фиксирует служебного пользователя, под которым подключён сервер, а не то, какой ассистент, по какому запросу и с какой целью изменил данные: для разбора инцидента с ИИ этого мало. Автономный агент с неограниченным набором инструментов по риску сопоставим с сотрудником, которому выдали ключи от всей критичной инфраструктуры и не ведут учёт его действий. Нативная безопасность 1С проектировалась не под эту угрозу.

Как запретить запись ИИ в базу 1С: read only на проде по умолчанию

Безопасный режим прода начинается не с того, чтобы отключить ИИ от 1С, а с того, чтобы поставить между моделью и инфобазами управляемый шлюз, который решает за модель, что ей позволено. Базовое правило простое: для боевых баз включается жёсткий read only. Не режим по договорённости, а fail-closed: если политика не может подтвердить, что операция безопасна, вызов блокируется, а не пропускается. ИИ в режиме read only к 1С читает данные, строит запросы, помогает с анализом, но физически не может ничего записать или удалить в проде, потому что запись отсекается на самом шлюзе, ещё до инфобазы.

Дальше подключается разделение баз по средам. Шлюз маршрутизирует запросы по инфобазам и знает статус каждой: прод, стейдж, тест, разработка. На тестовой и dev-базе запись можно разрешить, на боевой запретить, и это уже не зависит от того, что попросит пользователь или придумает модель. Ролевые профили определяют, кто из команды вообще вправе направить ИИ к какой базе и с каким набором инструментов. А полный аудит пишет то, чего не даёт штатный журнал 1С: кто спросил, к какой базе, что было разрешено, а что заблокировано, и эту историю можно выгрузить для разбора. Как именно устроена локальная граница и почему данные не покидают ваш контур, мы подробно разбирали в отдельной статье про on-premise 1С.

Практический чеклист: чем закрыть запись ИИ на проде

• Отдельная техническая учётная запись для ИИ: только чтение, без полных прав, без права запуска внешних обработок.
• На боевой базе никакого execute_code и произвольного BSL, совсем. Инструментов записи модель в списке доступных вызовов на проде просто не видит.
• Политика по умолчанию fail-closed: перечислено, что разрешено, всё остальное блокируется, а не наоборот.
• Разделение сред: запись живёт на тесте и разработке, прод открыт строго на чтение.
• Никаких фоновых эффектов у канала ИИ: запуск регламентных заданий и обменов по планам обмена для этой учётки отключён, чтобы одно «безобидное» действие не потянуло за собой перерасчёт движений и выгрузку во внешние системы.
• Полный аудит каждого обращения: кто спросил, к какой базе, что разрешено и что заблокировано. Без журнала вы не докажете, что запись действительно не проходила, и не восстановите цепочку вызовов при разборе.
• Квоты и лимиты на каждую базу отдельно, чтобы зациклившийся агент не устроил лавину запросов.

Меньше прав ИИ, меньше рисков и вопросов по 152-ФЗ

У ограничения ИИ до чтения есть и юридическая сторона. Любой ассистент, который ходит в 1С:Бухгалтерию или в ЗУП, неизбежно касается персональных данных, а с 30 мая 2025 года ответственность за их утечку резко выросла (поправки в КоАП). За первую утечку юрлицу грозит от 3 до 15 млн рублей в зависимости от объёма (за биометрию до 20 млн), за повторную вводится оборотный штраф от 1 до 3 процентов годовой выручки, но не менее 20 млн рублей. Отдельно наказывают за само неуведомление Роскомнадзора об утечке. Чем меньше ИИ может прочитать и, тем более, изменить или удалить, тем меньше поверхность, на которой этот риск реализуется.

On-prem-шлюз оставляет данные внутри вашего контура, а read only на проде убирает целый класс сценариев с искажением и удалением данных в базе. Это не сертификация и не гарантия соответствия закону, а честное сокращение экспозиции: вы отдаёте модели заметно меньше, чем она в теории могла бы натворить. Сам разговор про 152-ФЗ никуда не девается, но вести его с read only на проде куда спокойнее, чем с сырым каналом, где у ИИ полный доступ на запись.

Коротко

Feenlace MCP-1C, это управляемый on-prem-шлюз между ИИ-ассистентами и базами 1С. Он ставится одним самодостаточным бинарником в вашем контуре и даёт то, чего нет у сырых MCP-серверов: fail-closed read only на боевых базах, разделение инфобаз по средам, ролевые профили и полный аудит действий ИИ. Есть бесплатная открытая редакция, чтобы проверить подход на своих базах, и старшие редакции для команд. Если совсем сжать: пусть ИИ помогает читать и анализировать боевую 1С, а право писать и удалять останется за людьми и за отдельными, неопасными средами. Подробности и редакции на feenlace.ru.