Комментарии 2
Кажется, главный риск здесь даже не Bearer/scopes, а то, что новый /api/* endpoint может автоматически стать agent-callable. Как вы это контролируете: deny-by-default через route metadata/capability registry или blacklist для UI-only handlers?
И второй момент: generic invocation для большого числа endpoints не размывает модель прав? Для write-операций вроде start/approve, наверное, безопаснее явно описывать tool schema и scopes для каждого действия.
Всё по делу, не спорю. deny-by-default и схемы для write — правильно, к этому и иду в v2.
Но если честно — пока тушу пожары, а не строю на опережение. Права сейчас держатся на дисциплине и scope-ах, я это в статье и не скрывал. Руки дойдут, просто сейчас не до этого.
Голова занята другим. Платформу я с самого начала делал так, чтобы юзеру было всё понятно без мануалов. А голос эту логику просто ломает об колено — человек интерфейс не видит вообще. Ни фильтров, ни кнопок, ни превью, только голос туда-обратно. И вот что и как агенту в этих условиях скармливать — там у меня пока больше вопросов, чем ответов.
Ну и скорость. Цепочка длинная, 4–8 секунд на ответ, и это бесит куда сильнее, чем любая теоретическая дыра в правах. Сначала разгребу это.

Подключили B2B email-платформу к голосовым ассистентам через MCP. Архитектура, код, где ломается