В одиночку настройка агента - личное дело; в команде она становится вопросом того, чья настройка главнее. Как только за одним репозиторием стоят несколько человек и администратор, появляется иерархия, которую нельзя игнорировать, и попытка вести себя так, будто её нет, дорого обходится - обычно в тот день, когда чьи-то локальные послабления встречаются в общей ветке.
Наивный взгляд - думать, что каждый настраивает своего агента сам, а общий порядок сложится из личных настроек. Или что всё можно описать в одном AGENTS.md и раздать команде как единый закон. Оба ожидания кажутся практичными ровно до первого расхождения между тем, что разрешено на бумаге, и тем, что реально делает агент у соседа.
Ломается это на том, что личная настройка не может ослабить организационную. Organization-уровень deny и ask нельзя снять project-конфигом - и это не баг, а смысл: если бы локальный файл переопределял политику, политики бы попросту не было. Личное живёт под организационным, а не наравне с ним, и это единственный порядок, при котором слово политика вообще что-то значит.
Что даёт командный контур: централизованные billing и analytics, управление доступными агентами, реестр MCP, plugins и permissions на уровне организации. Enterprise добавляет SSO по SAML или OIDC, централизованные контроли и варианты dedicated deployment. Например, policy AllowedExtensions задаёт allowlist издателей расширений на уровне устройства, а update mode и телеметрия управляются оттуда же - личный выбор внутри этих рамок уже ограничен тем, что поставил администратор.
Профессиональный механизм - политика слоями, а не одним документом. Разворачивайте её по слоям: identity, затем доступ к репозиториям, затем разрешённые агенты, затем permissions и sandbox, затем plugins и MCP, затем аудит и branch protection. Каждый слой отвечает за свой вопрос, и вместе они дают контроль, который один AGENTS.md заменить не может, потому что находится в другой плоскости.
Почему слоями, а не одним документом. AGENTS.md - это контекст и влияние, не enforcement. Он не аутентифицирует пользователя, не ограничивает агентов на уровне организации, не защищает ветку от слияния без проверок. Слой identity решает кто; repository access - куда; permissions и sandbox - что можно руками агента; plugins и MCP - какие внешние возможности вообще подключены; audit и branch protection - что нельзя без независимой проверки. Свести это в один файл значит перепутать инструкцию с границей.
Минимум администратора умещается в пять пунктов. Определены разрешённые агенты и каналы. Cascade выключен или ограничен осознанно, а не по инерции переходного периода. Реестр MCP и ACP проходит review, а не пополняется кем угодно. Training, retention и sharing задокументированы. Protected branches требуют независимых проверок до слияния. Это не бюрократия, а места, где отсутствие решения само становится решением - и обычно не в вашу пользу.
Цена размытой политики - тихое расхождение между тем, что разрешено на бумаге, и тем, что реально может агент у каждого. Один разработчик снял ограничение локально, другой поставил непроверенный plugin, третий оставил Cascade с прежними правами и memories - и общей границы больше нет, хотя на уровне слов всё выглядело согласованным. Такие расхождения не шумят, пока не сойдутся в одном pull request.
Когда слоёная политика оправдана. С того момента, когда за репозиторием больше одного человека и есть что защищать. Для маленькой команды хватает identity, allowed agents и branch protection. Enterprise добавляет SSO, аудит и dedicated deployment по мере роста ставок - не раньше, чем это оправдано нагрузкой и рисками, но и не позже, чем появился первый реальный риск утечки или неконтролируемого действия.
Проверять политику стоит предъявлением, а не доверием. Убедитесь на реальной машине, что организационный deny не снимается project-конфигом. Пройдите чек-лист администратора и отметьте, что у каждого пункта есть владелец, а не общая ответственность всех сразу. Проверьте, что protected branch отклоняет слияние без независимых проверок. Каждая такая проверка превращает декларацию в факт, который можно показать.
Типичный провал - пытаться закрыть всё одним AGENTS.md; считать личную настройку достаточной; оставлять Cascade и MCP-реестр без review по умолчанию; путать наличие политики с её enforcement. Признак один: на вопрос кто это разрешил ответ звучит как никто явно. Назначьте слой и владельца каждому решению - и политика перестаёт быть декларацией и становится границей, которая держит без вашего постоянного присутствия.