Что такое ИИ-агент без прав на запись: тест показал, как он всё равно изменил CRM

Спор вокруг безопасности ИИ-агентов обычно сводится к двум лагерям. Одни говорят: «Мы ограничили модель, значит система безопасна». Другие возражают: «Ограничение модели ничего не гарантирует, пока вся цепочка исполнения не проверена до последнего узла». Лабораторный эксперимент, который разобрал инженер в изолированной среде на связке n8n (визуальный конструктор автоматизаций), DeepSeek (открытая языковая модель) и HubSpot (облачная CRM), впервые показал обе стороны на конкретном примере.

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

Что произошло в лабораторном тесте?

Исследователь собрал цепочку: DeepSeek получает задачу, формирует структурированное предложение, а следующий узел в n8n выполняет действие в HubSpot. Модели не давали учётных данных CRM. Она физически не могла обратиться к HubSpot напрямую.

Но учётные данные на запись оставались у промежуточного узла n8n. Когда модель сформировала предложение, этот узел принял параметры и выполнил команду PATCH (запись изменений) в CRM.

Контрольный сценарий был ещё жёстче. Запрос человека касался одной синтетической сделки (LAB-042), а структурированное предложение модели указывало на другую (LAB-043). Результат: изменилась не та сделка, которую просил человек, хотя модель по-прежнему не имела прав на запись.

Аргументы за ограничение на уровне модели

• Простота внедрения. Убрать у модели учётные данные CRM можно за минуту. Это первый и самый дешёвый уровень защиты.
• Прозрачность для аудита. В архитектурном описании строка «модель работает в режиме только чтения» понятна любому проверяющему, от CTO до внешнего аудитора.
• Снижение поверхности атаки. Если модель скомпрометирована (галлюцинация, то есть уверенная выдумка несуществующих данных, или подмена промпта), она всё равно не дотянется до записи напрямую.

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

Аргументы против: почему одного уровня мало?

• Полномочия модели и полномочия системы не совпадают. В классической информационной безопасности такой класс проблем называется confused deputy (запутанный посредник): компонент с правами выполняет чужое задание, не проверяя, имеет ли заказчик эти права.
• Downstream-узел (следующее звено цепочки) не знает контекста. Он получает параметры и исполняет. Нет отдельной проверки, нет границы, нет отказа.
• Wrong-object scenario (сценарий с неправильным объектом) реален. Лабораторный тест показал: изменилась сделка LAB-043 вместо LAB-042. В боевой среде это может быть чужой контакт, чужая сумма, чужой статус сделки.

Когда исследователь добавил между предложением модели и записью в CRM отдельный детерминированный шлюз (deterministic gateway, узел, который проверяет параметры по жёстким правилам, а не по «мнению» модели), результат изменился. Нормальный запрос к LAB-042 получил разрешение и завершился записью. Запрос с подменой объекта на LAB-043 был заблокирован до обращения к CRM.

Полномочия модели не равны полномочиям системы. Если downstream-компонент всё ещё способен изменить внешнее состояние, это полномочие тоже нужно увидеть и проверить. : Автор лабораторного исследования

Что делать с этим прямо сейчас, по ролям?

Авторам Дзена и контент-специалистам. Если вы подключаете ИИ-агента к таблицам, CMS или базе подписчиков, проверьте: кто именно держит пароль от записи? Часто это не модель, а скрипт-посредник (Zapier, Make, n8n). Ограничьте его права до минимума или добавьте ручное подтверждение перед каждой записью.

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

Предпринимателям в РФ и СНГ. Инструменты из теста (n8n, HubSpot, DeepSeek) доступны, DeepSeek работает без VPN, n8n разворачивается на своём сервере. Но в российских CRM (Битрикс24, amoCRM) архитектура интеграций устроена похоже: вебхук или API-ключ с правами на запись живёт не в модели, а в промежуточном сервисе. Принцип тот же: контроль нужен не на уровне модели, а на границе, где реально происходит запись.

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