Маскирование PII и safe-режим

Шлюз стоит между ассистентом и данными 1С, поэтому политики приватности и защиты продовых баз применяются на самом шлюзе: маскирование персональных данных на выходе и режим «только чтение» для продакшена.

Trust Layer

Trust Layer маскирует персональные данные в MCP-трафике до того, как ответ достигнет внешней LLM. Он включён по умолчанию; выключение это явное решение (TRUST_ENABLED=false). Маскирование сопровождается детальным аудитом: SHA256 оригинала, идентификатор сработавшего правила, токен и инструмент. Для замкнутых контуров есть опциональный прокси Ollama.

Как применяется маскирование

Маскируется ответ (response-side): каждый успешный результат инструмента маскируется по строгости роли вызывающего, затем нормируется по подробности и только после этого сериализуется в транспорт. Точка применения выбрана из-за SSE: маскирование на уровне HTTP-middleware обходилось бы потоком событий, а маскирование в точке диспетчеризации покрывает и потоковые ответы.

Поведение fail-closed: ошибка маскирования возвращает ошибку вызова, немаскированное тело не уходит никогда; отсутствующая или повреждённая настройка строгости приводит к самому строгому маскированию.

Строгость маскирования настраивается per-role через ролевые профили: inherit / strict / moderate / off.

Режимы распознавания имён

Распознавание русских ФИО в свободном тексте управляется переменной TRUST_NAME_DETECTION: off / balanced / aggressive, по умолчанию balanced.

• balanced: маскирует ФИО с отчеством и формы «Фамилия И.О.» / «И.О. Фамилия».
• aggressive: дополнительно маскирует словарные пары имени и фамилии (например «Иван Сидоров») и одиночные известные фамилии («Петрову»), ценой большей поверхности ложных срабатываний.

Что маскирование не ловит

Маскирование сознательно документируется как не исчерпывающее:

• в режиме balanced не маскируются одиночная фамилия и пара имени и фамилии без отчества;
• в любом режиме не маскируются имена ЗАГЛАВНЫМИ БУКВАМИ и в иностранной транслитерации, редкие фамилии вне словаря, числовые персональные данные в нераспознанных полях и ключи JSON-объектов.

Safe-режим прода: только чтение

Для каждой информационной базы включается режим safe_read_only, который жёстко блокирует все операции записи на самом шлюзе. Пока режим включён, шлюз отклоняет операции записи; при сомнении шлюз отказывает, а не пропускает (fail-closed: неизвестный инструмент или неопределённое состояние трактуются как запись и отклоняются).

Ключевые свойства:

• Блокировка действует на всех воронках записи, включая асинхронное проведение одобренных черновиков, поэтому запрет не объехать мимо диспетчеризации.
• Действие блокировки не зависит от состояния лицензии: истёкшая лицензия не откроет записи заново.
• Переключатель: POST /web/admin/onec/{id}/read-only. RBAC асимметричный: включить режим может право управления настройками, а снять его с продовой базы только Owner или право биллинга.
• База с включённым режимом помечается в консоли красным бейджем «Только чтение».
• По умолчанию режим выключен; включение это явное решение по каждой базе.

Allowlist именованных операций

Для write/action-поверхности dev-MCP администратор ведёт allowlist именованных операций: операция вне списка отклоняется (fail-closed) с внятной причиной отказа. У каждой операции два переключателя: включена ли она вообще и разрешена ли на проде. Изменения подхватываются живым путём диспетчеризации в пределах кэш-окна около 10 секунд, без перезапуска. Действия проходят тот же поток черновиков с одобрением.