Политику стоит отличать от файла разрешений, хотя лежат они рядом. Разрешения задаются файлом на уровне пользователя и таким же файлом в репозитории, и описывают они другое: список команд оболочки, выполняемых без подтверждения, список инструментов протокола подключения инструментов с масками вида server:tool и server:*, и текстовые указания для классификатора автоматического ревью. Политика отвечает на вопрос, что можно установить и куда войти. Разрешения отвечают на вопрос, что агент делает без спроса. Слои разные: политику задаёт администратор парка, а файл разрешений ведут команда и репозиторий - но и его раскатывают тем же средством управления устройствами, причём настройки административной консоли замещают значения файла.

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

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

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

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