Модель действительно не имела доступа на запись в HubSpot, но лабораторный тест всё равно изменил CRM — не ту синтетическую сделку, которую указал исходный запрос.
Суть события
В эксперименте с n8n, DeepSeek и HubSpot проверили простой, но неприятный сценарий: модель предлагает изменить один объект, а следующий компонент цепочки исполняет действие над другим. DeepSeek не имел учётных данных HubSpot и не мог вызвать запись напрямую. Однако credential на запись оставался у downstream-узла n8n — оркестратора, который передаёт параметры внешнему сервису.
В контрольном тесте использовали две синтетические сделки — LAB-042 и LAB-043. Запрос относился к LAB-042, но структурированное предложение указывало LAB-043. Без отдельной проверки n8n выполнил PATCH, и CRM изменила LAB-043. LAB-042 осталась без изменений. Иными словами, ограничение модели было настоящим, но система в целом read-only не была.
Детали
Это не история о злой или намеренно обходящей правила модели. Это wrong-object case — контролируемая проверка несовпадения целевого объекта. Ошибка возникла на границе между предложением и исполнением: downstream-компонент доверился параметрам предложения и обладал полномочием на запись.
Затем между предложением модели и вызовом HubSpot добавили независимый детерминированный шлюз. Он сверял ожидаемый target, зафиксированный отдельно от результата генерации, непосредственно перед внешним действием. Для LAB-042 проверка дала allow и запись прошла. Для LAB-043 — deny: PATCH не запускался, а повторное чтение подтвердило, что состояние CRM не изменилось.
Контекст
Для CTO, владельца продукта и security lead формулировка «агент работает в режиме read-only» может попасть в архитектурное описание, security review или клиентский опросник. Но полномочия модели и полномочия системы — разные вещи. Удалить credential из модели полезно, однако это не отменяет доступ следующего узла к CRM, ERP, ticketing или инфраструктуре.
Проблема близка к классическому confused deputy: компонент с правом действия выполняет его на основании чужого, недостаточно проверенного указания. Поэтому при оценке agentic execution chain нужно смотреть не только на инструменты модели, а на компонент, который способен вызвать реальное последствие. Для общего контекста о том, как AI-ограничения сталкиваются с реальным поведением систем, полезен материал «Хабр запретил нейротексты, но пользователи всё равно находят их в ленте».
Что дальше
Перед production-запуском стоит пройти короткий checklist: где находятся credentials на запись; какой компонент делает внешний вызов; какие параметры проверяются непосредственно перед ним; может ли target измениться между запросом и записью; есть ли независимая граница между предложением и последствием; как подтверждается итоговое состояние после действия.
Лабораторный тест не доказывает, что любой агент обязательно изменит не тот объект. Он показывает другое: заявление read-only нельзя подтверждать только отсутствием write-доступа у модели. Нужны воспроизводимый wrong-object тест, контроль на runtime-границе и evidence, что внешний вызов действительно остановлен при несовпадении.
