Почему запрет записи для ИИ-модели не гарантирует read-only режим всей CRM-системы
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Лабораторный эксперимент показал, что даже если нейросеть лишена прав на запись, оркестратор может изменить данные CRM из-за несоответствия объектов. Решение требует контроля на границе исполнения, а не только ограничения модели.
Ценность: Статья выявляет критическую уязвимость в архитектуре агентных систем: полномочия модели и системы различаются. Это важно для CTO и security-команд перед production-запуском, так как декларативные ограничения могут не соответствовать фактическим возможностям downstream-компонентов.
В современной практике внедрения ИИ-агентов часто возникает заблуждение: если модели запрещено выполнять операции записи (write), то вся система работает в режиме read-only. Однако, как показывает лабораторный эксперимент с использованием n8n, DeepSeek и HubSpot, это утверждение некорректно. Ключевая проблема заключается в том, что полномочия на изменение данных могут принадлежать не самой нейросети, а downstream-оркестратору. Если оркестратор принимает структурированное предложение модели и выполняет его без дополнительной проверки, система сохраняет способность изменять внешнее состояние, даже если сама модель лишена соответствующих учётных данных.
В ходе теста была смоделирована ситуация, когда исходный запрос пользователя относился к одной синтетической сделке (LAB-042), а структурированное предложение модели — к другой (LAB-043). В первой конфигурации архитектуры n8n использовал собственные учётные данные HubSpot и успешно выполнил PATCH-запрос для LAB-043. Проверка состояния после прогона подтвердила, что именно эта сделка была изменена, тогда как целевая LAB-042 осталась нетронутой. Этот сценарий демонстрирует классическую проблему «confused deputy»: система выполняет действие, отличное от того, которое было явно запрошено пользователем, из-за отсутствия контроля на этапе исполнения.
Чтобы устранить эту уязвимость, во второй конфигурации между моделью и внешним API был добавлен детерминированный gateway. Его задача состояла в проверке ключевых параметров непосредственно перед запуском внешнего вызова: целевой системы, идентификатора объекта, ожидаемого исходного состояния и разрешённого перехода. В этом случае предложение с несоответствующим объектом (LAB-043) было заблокировано на этапе проверки, и запись в CRM не произошла. При этом учётные данные n8n остались прежними; изменился лишь механизм контроля доступа к этим полномочиям.
Для CTO, product owner или security lead этот опыт имеет практическое значение при принятии решений о production-запуске или расширении автономии агентов. Формулировка «модель работает в read-only» может попасть в архитектурные документы или клиентские опросники, но она недостаточна для оценки безопасности. Важнее определить, какой именно компонент execution chain способен вызвать внешнее последствие и что ограничивает его непосредственно перед действием. Удаление credential из модели — полезный шаг, но он не автоматически устраняет write-capability всей системы.
Практический вывод состоит в том, что проверка безопасности должна быть направлена на подтверждение того, где именно находится исполнительное полномочие и работает ли контроль на runtime-границе. Необходимо проследить цепочку: что предложено моделью, кто реально может исполнить действие, какие параметры проверяются перед исполнением и какое состояние возникло после вызова. Это переход от декларативного контроля к подтверждённой управляемости в реальном времени.
Перед запуском агентов с доступом к CRM или ERP рекомендуется проверить шесть ключевых аспектов: физическое расположение учётных данных, компонент, выполняющий внешний вызов, параметры, проверяемые перед исполнением, возможность изменения target между запросом и записью, наличие независимой границы контроля и способ подтверждения итогового состояния. Эти вопросы помогают понять, на чём именно основано решение о безопасности системы.