Ваш ИИ-агент только читает данные, но CRM всё равно изменилась

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

Что произошло в тесте

Схема была построена на n8n, с DeepSeek в роли модели и HubSpot в роли CRM. У самой модели не было учётных данных HubSpot. Она не могла напрямую обращаться к CRM. Это ограничение было настоящим.

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

Затем автор добавил одну вещь — отдельную детерминированную проверку между предложением модели и реальным вызовом CRM. Эта проверка смотрела на короткий список параметров: какая система затрагивается, какой ID объекта, в каком состоянии должна находиться запись и какой переход допустим. Учётные данные никуда не делись, процесс по-прежнему мог писать. Но теперь запись зависела от прохождения этой проверки. Обычный сценарий прошёл и завершился успешно. Несовпадающий был отклонён, и запись осталась прежней.

Вывод автора короток: то, что разрешено модели, — не то же самое, что разрешено системе. В классических терминах безопасности это близко к проблеме «доверенного посредника» (confused deputy) — старая идея, всплывшая в новом месте.

Почему это важно для малого бизнеса

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

Для бизнеса практический риск не выглядит драматично. Он тихий и скучный: обновляется не та сделка, не тот заказ помечается как оплаченный, не у того клиента меняется статус. Никто не замечает неделю. Потом кто-то пытается свести цифры и не может их объяснить. Журнал аудита, если он существует, показывает успешный вызов API — технически верный, фактически ошибочный.

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

Что проверить, прежде чем агент коснётся данных клиентов

Статья заканчивается шестью вопросами, которые стоит задать перед выходом в продакшн или перед расширением прав агента. В виде чек-листа, который можно выполнить в этом месяце:

• Найдите, где физически хранятся учётные данные для записи. Не где находится модель, а какой компонент делает внешний вызов. Именно этот компонент определяет реальную зону риска.
• Перечислите, что проверяется непосредственно перед вызовом. Целевая система, ID объекта, ожидаемое текущее состояние, допустимый переход. Если в этот момент ничего не проверяется, значит проверки в осмысленном виде нет.
• Спросите, может ли цель измениться между запросом и записью. В лабораторном случае так и было: запрос указывал на одну запись, структурированное предложение — на другую. Ничего злонамеренного, просто несовпадение, которое никто не отловил.
• Поставьте независимый барьер между предложением и последствием. В тесте таким барьером был детерминированный код, а не другая модель, решающая, права ли первая.
• Подтверждайте итоговое состояние после действия, а не только успешность вызова. Именно отдельное чтение доказало результат в обоих направлениях эксперимента.
• Ведите восстанавливаемую цепочку событий. Что было предложено, кто мог это выполнить, что было проверено, что реально было вызвано, какое состояние получилось в итоге. Без этого у вас есть заявление о контроле, а не доказательство его наличия.

Итог

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