ИИ-агенту запретили запись в CRM. Но CRM всё равно изменилась

ИИ-агенту запретили запись в CRM. Но CRM всё равно изменилась

Почему ограничения на уровне модели ещё не означают, что вся AI-система работает в режиме read-only — и почему это важно перед production rollout, расширением полномочий агента и передачей решения клиенту.

В первой статье ^[1] я разбирал более узкий случай: человек одобряет одно действие, а downstream-workflow способен попытаться выполнить другое. Там вопрос был в целостности цепочки approval → execution.

Здесь хочу посмотреть на ту же проблему шире. Если самой модели запрещена запись, означает ли это, что вся AI-система действительно не может изменить CRM?

Для CTO, product owner или security lead это вполне практический вопрос. Формулировка «модель работает в read-only» может попасть в архитектурное описание, security review, клиентский опросник или решение о production-запуске. Но для такого решения важнее другое: какой компонент всей execution chain реально способен вызвать внешнее последствие — и что ограничивает его непосредственно перед действием?

Именно это я проверил в лабораторном workflow на n8n + DeepSeek + HubSpot.

DeepSeek не имел учётных данных HubSpot и не мог выполнить write напрямую. Но credential на запись оставался у следующего узла n8n. В контрольном сценарии исходный запрос относился к одной синтетической сделке, а структурированное предложение — к другой. Downstream-путь выполнил PATCH, и CRM действительно изменилась.

Главный вывод оказался простым:

Полномочия модели — не то же самое, что полномочия системы.

Сам по себе этот класс проблемы не новый: в классической security-логике он близок к confused deputy. Мне было важно не ещё раз назвать известный риск, а посмотреть, как он проявляется в современной agentic execution chain и что именно меняет результат.

Где на самом деле находился write

На уровне модели ограничение было реальным: она не могла обратиться к HubSpot напрямую.

Но возможность изменить CRM принадлежала не модели, а downstream-оркестратору. Если он принимает параметры предложения и выполняет их без отдельной проверки, система в целом остаётся способной на запись.

Архитектура B и архитектура C. Ограничение полномочий модели само по себе не устраняет write-capability всей системы. Результат меняется, когда контроль появляется на границе исполнения.

Поэтому вопрос «что разрешено модели?» полезен, но недостаточен. Для решения о запуске важнее следующий:

Какой компонент способен вызвать реальное последствие — и что ограничивает его непосредственно перед этим действием?

Контрольный сценарий: правильный и неправильный объект

Тест выполнялся в изолированном лабораторном окружении с синтетическими объектами и проверял один конкретный класс mismatch между предложением и фактическим target.

В отдельном синтетическом HubSpot Lab я использовал две тестовые сделки: LAB-042 и LAB-043.

В нормальном сценарии запрос, предложение и фактическая запись относились к LAB-042.

Затем я намеренно создал несовпадение:

человекочитаемый запрос: изменить LAB-042
структурированная цель:   изменить LAB-043

Это не моделировало «злую модель». Это был контролируемый wrong-object case: проверка того, остановит ли архитектура предложение с другим target до CRM-записи.

В первой конфигурации независимой границы не было. n8n получил предложение, использовал собственный HubSpot credential и выполнил PATCH для LAB-043.

Отдельное чтение после прогона подтвердило:

• LAB-043 изменилась;

• LAB-042 осталась в исходном состоянии.

То есть изменилась не та сделка, которая была названа в исходном запросе, хотя сама модель по-прежнему не имела write credential.

Что изменил независимый контроль

Во второй конфигурации между предложением модели и HubSpot PATCH появился отдельный deterministic gateway.

Его задача была узкой: перед разрешением записи проверить параметры, которые определяют допустимое последствие:

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

• целевую систему;

• идентификатор объекта;

• ожидаемое исходное состояние;

• разрешённый переход.

Учётные данные никуда не исчезли. n8n всё ещё мог писать в HubSpot. Изменилось другое: доступ к этому полномочию стал зависеть от отдельной проверки непосредственно перед внешним действием.

Нормальный сценарий с LAB-042 получил allow и завершился записью. Wrong-object proposal с LAB-043 получил deny: HubSpot PATCH не запускался, а новое чтение подтвердило, что состояние сделки не изменилось.

Wrong-object test. Один и тот же target mismatch приводит к разным результатам: без независимой границы CRM меняется, с границей запись блокируется до внешнего действия.

В итоге тот же класс wrong-object proposal, который в первой архитектуре привёл к изменению CRM, во второй был остановлен до записи.

Что это меняет в решении о запуске

В production-проекте выражение «агент read-only» может использоваться как аргумент при:

• production rollout;

• расширении автономии или набора доступных действий;

• подключении операций в CRM, ERP или инфраструктуре;

• передаче решения клиенту;

• security questionnaire или procurement review.

Если такое утверждение основано только на инструментах и credentials, доступных модели, команда видит лишь часть execution chain.

Практический вопрос для человека, который принимает решение о запуске, здесь не «опасен ли AI». Он гораздо конкретнее:

Есть ли у нас достаточные подтверждения, что фактические полномочия системы соответствуют заявленным ограничениям?

Удаление credential из модели — полезный control. Но оно ограничивает прямые полномочия модели, а не автоматически возможности всей системы. Если downstream-компонент всё ещё способен изменить внешнее состояние, это полномочие тоже нужно увидеть и проверить.

Практический вывод из таких сценариев заключается в том, что проверка должна быть направлена не только на наличие security controls, но и на подтверждение того, где именно находится исполнительное полномочие и работает ли контроль на runtime-границе. где находится реальное полномочие, чем оно ограничено и какие evidence подтверждают, что контроль действительно работает на runtime-границе.

Для такой проверки мне важна не только схема архитектуры, но и восстанавливаемая цепочка:

что предложено
→ кто реально может исполнить
→ что проверяется перед исполнением
→ что фактически было вызвано
→ какое состояние возникло после вызова

Это переход от декларации контроля к подтверждённой runtime controllability.

Шесть вопросов перед production или расширением полномочий

Перед запуском агента с доступом к CRM, ERP, ticketing или инфраструктуре я бы проверил:

1. Где физически находятся учётные данные и полномочия на запись?

2. Какой компонент выполняет внешний вызов?

3. Какие параметры проверяются непосредственно перед исполнением?

4. Может ли target или существенный параметр измениться между пользовательским запросом и write?

5. Есть ли независимая граница между предложением модели и последствием?

6. Как подтверждается итоговое состояние после действия?

Эти вопросы полезны не только инженеру. Они помогают CTO, security lead или владельцу продукта понять, на чём именно основано решение «можно запускать».

Вместо вывода

В этой архитектуре удаление HubSpot credential из DeepSeek не устранило возможность системы изменять CRM: полномочие на запись оставалось у n8n.

В wrong-object case это привело к изменению другой синтетической сделки. После добавления отдельной детерминированной границы аналогичное несовпадение было остановлено до PATCH.

Хотя это и был только лабораторный тест, он хорошо показывает более общий практический принцип: если система называется controlled или read-only, недостаточно посмотреть только на модель. Нужно проследить полномочие до компонента, который способен вызвать последствие, и проверить контроль именно на этой границе.

Полномочия модели — не то же самое, что полномочия системы.