Безопасность ИИ-агента в Битрикс24: права, подтверждение и prompt injection

Что делает платформа Битрикс24

Для MCP-сервера Битрикс24 справка (helpdesk.bitrix24.ru/open/26952788/, обновлена 16.10.2026) описывает такие меры: подключение включает администратор, команды выполняются в пределах прав пользователя, перед действием запрашивается подтверждение. Для REST по входящему вебхуку запросы выполняются с правами сотрудника, который создал вебхук, а набор доступных методов ограничивают права (скоупы), отмеченные при создании (apidocs.bitrix24.ru, проверено 11.11.2026). Там же есть важная деталь: если администратор отредактирует чужой вебхук, секретный код обновится, а владельцем вебхука станет администратор, то есть запросы пойдут уже с его правами.

Учтите и ограничение скоупов: скоуп CRM открывает методы и чтения, и записи. Разделить «только читать» на стороне портала можно ролью пользователя в правах доступа CRM, а не галочкой в вебхуке.

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

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

1. Отдельный пользователь. Заведите для ИИ отдельного сотрудника, а не вешайте вебхук на личный аккаунт владельца.
2. Минимум прав. Начните с доступа на чтение нужных разделов: CRM, задачи. В ролях CRM можно дать пользователю только чтение. Права на пользователей, настройки и диск выдавайте, только если это нужно задаче.
3. Узкий скоуп вебхука. Отметьте только необходимые разрешения, а не «всё». Правьте вебхук под тем же пользователем, а не из-под администратора.
4. Чтение раньше записи. Пилот проводите без права записи. Запись включайте после того, как отчёты совпали с реальностью.
5. Подтверждение человеком. Любое изменение карточки идёт через согласование: сначала план, потом «да».
6. Журнал. Проверяйте, что видно, что сотрудник читал и что менял, по каждой задаче.
7. Отзыв доступа. Знайте, как отключить вебхук: удалите его в Битрикс24 или отключите подключение на стороне сервиса. Проверьте это до пилота, а не в момент проблемы.

Как с этим справляется VibeLab

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

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

Что с prompt injection? Полностью исключить его не может ни один продукт, мы этого не обещаем. Но два правила сильно уменьшают ущерб: без права «Писать» инструменты записи в CRM откажут, даже если текст в карточке «уговаривает» сотрудника, а запись в режиме согласования показывает вам действие до выполнения. Вредную команду из письма вы увидите на подтверждении и отклоните.

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

Чего мы не утверждаем

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

Что проверить на пилоте

За две недели пилота ответьте на четыре вопроса. Видны ли в журнале все обращения сотрудника к CRM. Совпадает ли набор прочитанных данных с выданными правами. Отказывает ли сотрудник, когда вы просите сделать то, на что у него нет права. Умеете ли вы быстро отключить доступ. Если хотя бы на один вопрос ответ «нет», остановитесь и разберитесь, прежде чем расширять права.

Типичные ошибки админа

Первая: сделать вебхук от учётной записи владельца портала, потому что «так быстрее». Тогда у агента права владельца, и ошибка или подмена команды затронет всё. Вторая: выдать разрешения «на будущее». Лишние права накапливаются и забываются, а через полгода никто не помнит, зачем агенту доступ к диску. Третья: хранить адрес вебхука в общем чате или документе. Код внутри адреса работает как пароль, поэтому при утечке вебхук нужно удалить и создать заново. Четвёртая: включить запись сразу, потому что «в пилоте ничего страшного». Ошибка в карточках клиентов всегда стоит дороже, чем неделя без записи.

Как часто пересматривать права

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

Как отвечать на вопросы службы безопасности

Если вопросы появятся, заранее подготовьте короткий документ из четырёх частей: какой пользователь создан для ИИ, какие разрешения у вебхука, какие действия запрещены переключателями «Читать» и «Писать», где смотреть журнал. Это не заменяет договор и проверку, но снимает половину вопросов на первой встрече. Конкретные требования по хранению и обработке данных обсуждайте напрямую с нами до подключения, а не по рекламным обещаниям.

Как начать в VibeLab

Заведите отдельного пользователя, создайте входящий вебхук с минимальными правами и подключите его по пошаговой инструкции. Про различие подходов к доступу читайте в статье «Встроенный ИИ или внешний сотрудник», а про сами вебхуки и лимиты — в разборе API и вебхука Битрикс24. Какие системы подключаются, показано на странице подключений. Первый месяц бесплатно, карта не нужна.