Расширения редактора заслуживают отдельного разговора, потому что это самостоятельная цепочка поставки, живущая по своим правилам. Разрешённые издатели, проверка подписи и задержка перед установкой новых версий - три механизма, которые вместе снижают риск короткоживущего вредоносного релиза. Логика простая: такие инциденты обычно длятся часы до момента, когда релиз отзывают, и задержка в установке пропускает их мимо ваших машин без единого решения со стороны разработчика.

Под этими механизмами лежит другой реестр. Расширения берутся из Open VSX, а не из магазина Microsoft: там есть не всё, а одно и то же имя вида издатель.расширение может указывать на другого издателя и другой код, чем в привычном магазине. Поиск и загрузка идут не напрямую, а через собственный посредник marketplace.cursorapi.com, где расширение прогоняют через автоматический разбор на вредоносный код и цепочку поставки, а не прошедшее проверку блокируют. Для нескольких ходовых расширений, которых в Open VSX нет, выпущены собственные замены Anysphere. Следствие простое: сверять надо издателя, а не название, иначе список разрешённого одобрит совпадающее имя вместо ожидаемого кода.

У плагинов свой регулятор - режимы установки и командный каталог. Разница между предложить и обязать здесь не косметическая. Каталог с одобренным набором отвечает на вопрос, что разрешено ставить, но не гарантирует, что нужное поставлено: у половины команды может не оказаться того, на что вы рассчитывали, когда писали правила. Обязательный режим, наоборот, даёт гарантию присутствия, и именно он нужен для вещей, от которых поведение агента должно зависеть одинаково у всех. Оба режима полезны, но отвечают на разные вопросы, и путать их - значит строить политику на предположении об окружении коллег.

Главная мысль формулируется одной фразой: направление - не принуждение. Обязательное командное правило может подсказать модели, что делать, но оно не заменяет ни список разрешённых моделей, ни ограничение внешних серверов, ни песочницу, ни обработчик события. Политика должна жить в механизме, который технически контролирует нужный ресурс, а не в тексте, который модель принимает во внимание наравне с остальным содержимым контекста.

Эта ошибка встречается чаще, чем кажется, и выглядит убедительно. В правилах написано не подключать неодобренные серверы - значит, никто не подключит. На практике правило видят не все поверхности, оно не применяется к части сценариев, его влияние зависит от объёма контекста, и проверить соблюдение постфактум нечем: отказа не было, записи не осталось. Ограничение на уровне администратора, наоборот, даёт наблюдаемый отказ и строку в журнале, то есть предъявляемое доказательство.

Отсюда практический порядок внедрения. Сначала инвентаризация: какие модели, серверы, плагины и расширения используются сегодня. Затем список разрешённого, собранный по факту, а не по идеалу, - в него честно попадает то, без чего команда не работает. И только потом ужесточение: то, что не попало в список, отключается по объявленному расписанию и с понятным путём исключения. Обратный порядок, когда сначала запрещают, а потом выясняют, гарантирует поток исключений, обход политики и репутацию инструмента, который мешает работать.

Инженерный вывод простой: управляйте тем, что можете наблюдать, и принуждайте тем, что технически контролирует ресурс. Тогда политика становится свойством системы, а не соглашением о намерениях, и её соблюдение видно в журналах, а не выясняется опросом команды накануне аудита.

Типичные провалы предсказуемы. Записать требование в правила вместо ограничения в механизме. Составить список разрешённого без инвентаризации фактического использования. Одобрить внешний сервер и не ограничить его инструменты и сеть. Оставить расширения вне политики, считая их частью редактора. И запретить всё сразу, не оставив понятного пути исключения.