Comments 2
Хорошо, что это проверили руками, а не просто нарисовали схему. Но смущает одно: в лабе шлюзу заранее сказали, какая сделка правильная. В жизни так не бывает. Человек пишет "поправь сделку с Ромашкой", и в конкретный ID это превращает та же самая модель. Шлюзу сверять не с чем, он сверяет модель с ней же.
С фильтрами тулов по имени та же беда, кстати: имя говорит, что можно вызвать, но не с какой записью.
Короче, пока у n8n лежит токен на запись в HubSpot, никакой это не read-only, хоть десять проверок перед PATCH поставь. Read-only - это когда токена на запись просто нет.
Спасибо за внимательное чтение — радует, когда в комментариях копают именно в механику, а не только в общий вывод.
По сути замечания правильные. В лабе можно было сделать схему ближе к production:
deal_idбрать из независимого источника — например, из UI/approval artifact, а не разрешать той же модели и выбрать запись, и потом действовать по ней;проверять не только разрешённый tool, но и конкретный resource: какую именно сделку и какие поля можно менять;
read-only обеспечивать на уровне credential/capability, а не только логики самого workflow. Если у runtime лежит write-token, то технически write capability у него всё равно есть.
В статье scope был уже: хотелось руками показать именно approval-to-execution mismatch т.е. когда одобрено одно действие, а workflow пытается выполнить другое. Поэтому часть production-grade ограничений сознательно не включал, чтобы не раздувать эксперимент.
Но замечание полезное. Если продолжать эту тему, следующую лабу имеет смысл делать уже с независимым object binding, resource-level authorization и разделением credentials. Так будет гораздо ближе к реальной жизни. Спасибо за коммент!
ИИ-агенту запретили запись в CRM. Но CRM всё равно изменилась