Письмо клиента не выдаёт права: защита помощника от скрытых инструкций

Что означает результат испытания

В материале от 4 сентября 2026 года The Decoder разбирает сведения из карточки GPT-6 Astra. Издание сообщает о снижении числа фактических ошибок на специально отобранных проблемных диалогах. Такая выборка не описывает частоту ошибок в обычной переписке сервисной компании.

Для скрытых инструкций статья приводит оценку Gray Swan: использовались 1 810 подобранных атак, по 15 попыток на сценарий. Хотя бы один успешный взлом поведения отмечен в 8,5% сценариев для Astra против 27% для GPT-5.6 Sol.

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

Как инструкция оказывается в заявке

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

Приём запроса на ремонт не даёт клиенту полномочий управлять CRM. Поэтому границу нужно задавать не только словами в системной инструкции, но и доступными действиями интеграции. У помощника по составлению черновиков нет причины читать полный справочник клиентов.

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

Черновик, который можно проверить

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

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

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

Что испытывать на безопасном стенде

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

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

При обнаружении нарушения сохраните входной пример и повторите его после изменения настроек. Новая модель или новый способ извлечения текста из PDF требуют повторной проверки. Успешный тест старой версии не даёт бессрочного допуска.

Где заканчиваются полномочия помощника

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

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