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

Почему ограничения на уровне модели ещё не означают, что вся AI-система работает в режиме read-only — и почему это важно перед production rollout, расширением полномочий агента и передачей решения клиенту. В первой статье я разбирал более узкий случай: человек одобряет одно действие, а 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 и что именно меняет результат. 💡 Где захостить и как запустить: рассчитать точные требования к объёму VRAM под разные типы квантования этой модели (4-bit Q4, FP8, FP16), оценить скорость генерации токенов в секунду и подобрать совместимый сервер с GPU можно на ServerSales в интерактивном подборщике AI-моделей или каталоге GPU-серверов.