Ограничение доступа модели не гарантирует безопасность CRM: почему runtime-control критичен для AI-агентов
Внедрение AI-агентов в корпоративные процессы часто сопровождается ошибочным убеждением: если у самой нейросети нет прав на запись, система работает в режиме read-only. Кейс с использованием n8n, DeepSeek и HubSpot доказывает, что полномочия оркестратора способны обойти эти ограничения, меняя нецелевые записи в базе данных.
# ИИ-агенту запретили запись в CRM. Но CRM всё равно изменилась
Введение AI-агентов в рабочие процессы предприятий часто сопряжено с серьёзными рисками безопасности. Частой ошибкой архитекторов и продуктовых команд становится формальное ограничение доступа к инструментам у языковой модели (LLM). Если из контекста агента удаляются учётные данные для записи (write-credentials), система часто объявляется «безопасной» или работающей только в режиме чтения. Однако, как показывает практика, это заблуждение может привести к утечке данных или некорректному изменению бизнес-объектов.
В данной статье мы разберём лабораторный эксперимент, где ограничение прав у модели не помешало изменить запись в CRM. Анализ поможет понять разницу между полномочиями самого модели и всей цепочки выполнения, а также покажет, как внедрить контроль на уровне runtime (время работы) для реального обеспечения безопасности.
Разделение полномочий: модель против системы
Проблема кроется в путанице понятий. Когда говорят, что «модель работает в read-only», имеется в виду то, что сама нейросеть не может напрямую вызвать API для изменения состояния базы данных. В описанном сценарии модель DeepSeek действительно не обладала учётными данными HubSpot и не могла выполнить запрос на запись. Однако полномочия на модификацию данных находились у другого компонента — downstream-оркестратора, в данном случае workflow-платформы n8n.
Архитектура системы выглядит следующим образом: 1. Пользователь отправляет запрос модели. 2. Модель генерирует структурированное предложение (например, ID сделки для обновления). 3. Оркестратор (n8n) получает это предложение. 4. Если в конфигурации оркестратора присутствуют учётные данные (credential) на запись, он использует их для выполнения действия.
В классической информационной безопасности эта уязвимость напоминает атаки через «путаниций поверенных» (confused deputy). Зловредный или ошибочный агент (в данном случае оркестратор) использует предоставленные ему полномочия для действий, которые не были явно санкционированы исходным запросом пользователя.
Лабораторный сценарий: неправильный объект
Для проверки гипотезы был создан изолированный тестовый окружение в HubSpot Lab. В качестве целей выступали две синтетические сделки: LAB-042 и LAB-034. Сценарий был спроектирован так, чтобы смоделировать ситуацию «wrong-object» (неправильный объект).
Нормальный сценарий: Запрос был направлен на обновление сделки LAB-042. Оркестратор получил целевой ID, проверил его (без отдельной границы) и успешно применил изменения к LAB-042.
Сценарий аномалии: Исходный текстовый запрос пользователя относился к сделке LAB-042. Однако в процессе генерации или передачи параметров к структурированному предложению (JSON-объекту для API) произошла ошибка формирования целевого идентификатора, и он указывал на LAB-043.
Поскольку модель не имела прав на запись, она просто сгенерировала этот ошибочный ID. Оркестратор n8n, обладая валидными credentials и не имея сложной проверки соответствия между пользовательским запросом и целевым ID, автоматически исполнил PATCH-запрос для LAB-043. В результате, сделка, о которой не просил пользователь, была изменена, а исходный объект остался нетронутым.
Этот результат демонстрирует ключевой вывод: удаление учётных данных у модели не устраняет возможность изменения внешнего состояния, если у оркестратора эти данные присутствуют. Система в целом обладает capability (способностью) на запись, даже если конкретный узел в цепочке его не запрашивал.
Внедрение детерминированной границы
Вторая фаза эксперимента заключалась в попытке устранить уязвимость через архитектурные изменения. Была добавлена независимая детерминированная граница (deterministic gateway) между генерацией предложения моделью и вызовом API HubSpot.
Новый узел не просто передавал данные дальше. Он выполнял строгую проверку параметров, которые определяют допустимое последствие. В частности, проверялся целевой идентификатор (target) и ожидаемый исходный объект. Учётные данные никуда не исчезали — они всё ещё находились в конфигурации n8n. Изменилось только условие их использования.
При повторном тесте с несовпадением целевого объекта (запрос на LAB-042, параметр для LAB-043):* * Новый узел заблокировал транзакцию. * PATCH-запрос к HubSpot не был выполнен. * Состояние обеих сделок осталось неизменным.
Это подтверждает, что контроль должен осуществляться непосредственно перед выполнением внешнего вызова (runtime-control), а не полагаться только на ограничения модели.
Практические выводы для CTO и security-лидов
Эксперимент показывает, что декларативное утверждение «агент работает в режиме только для чтения» может быть вводящим в заблуждение, если основано исключительно на анализе доступа у модели. Для принятия решения о переходе на production-среду необходимо понимать, где именно находится реальное исполнительное полномочие.
Перед расширением полномочий AI-системы или запуском новых сценариев взаимодействия с CRM, ERP или инфраструктурой необходимо ответить на ряд вопросов:
1. Где физически находятся учётные данные? Только ли у модели или есть доступ у оркестратора? 2. Какой компонент выполняет внешний вызов? Кто имеет право инициировать изменение состояния? 3. Где находится точка контроля? Есть ли независимая проверка параметров непосредственно перед исполнением? 4. Может ли целевой объект измениться? Как система реагирует на расхождение между пользовательским запросом и сгенерированным параметром? 5. Как подтверждается итоговое состояние? Существуют ли гарантии, что после вызова API произошло именно то, что планировалось?
Главный вывод заключается в переходе от декларативной модели контроля к подтверждённой runtime-controllability. Безопасность AI-системы нельзя строить на допущениях о поведении модели, если архитектура позволяет оркестраторам действовать автономно с использованием делегированных прав. Необходимо явно определить границы полномочий на уровне исполнения и обеспечить проверку этих границ до момента взаимодействия с внешними системами.
*«Полномочия модели — не то же самое, что полномочия системы. Ограничение доступа у нейросети полезно, но недостаточное. Реальная защита требует контроля над тем, кто и как выполняет внешние действия.»*
Для инженерных команд и владельцев продуктов важнее не бояться AI как такового, а чётко понимать, какие компоненты в их цепочке выполнения (execution chain) способны вызвать нежелательные последствия и как это ограничение поддерживается на практике.