Regras que o repo
não desfaz.
Policies controlam se o MVCode pode usar um recurso nomeado — hoje, provedores de modelo. São a camada de governança acima das permissões, pensadas para indivíduos cuidadosos e frotas inteiras.
Permissões controlam o que as ferramentas fazem durante a sessão. Policies controlam se o MVCode pode usar um recurso — um provedor negado some da seleção de modelos, mesmo com credencial válida.
01A forma
Cada statement tem três campos — effect, action, resource — no array experimental.policies:
{
"experimental": {
"policies": [
{ "effect": "deny", "action": "provider.use", "resource": "openai" }
]
}
}02Ações disponíveis
| Action | Resource | Controla |
|---|---|---|
| provider.use | provider ID · curinga | Uso de um provedor de modelo. |
O vocabulário de ações cresce com o produto — o formato statement é estável.
03Casamento e ordem
resource aceita * e ?. A última regra que casa vence — negue largo primeiro, permita o específico depois. Allowlist só-Anthropic:
{
"experimental": {
"policies": [
{ "effect": "deny", "action": "provider.use", "resource": "*" },
{ "effect": "allow", "action": "provider.use", "resource": "anthropic" }
]
}
}Sem statement casando, o uso é permitido.
04Global vence o projeto
Policies existem na config global e na do projeto. Quando as duas casam o mesmo provedor, a global tem prioridade — um repositório clonado não consegue reabilitar um provedor que você negou globalmente. É a inversão deliberada da precedência normal de config, porque aqui o objetivo é proteção.
05Substituindo as listas antigas
Prefira policies aos campos disabled_providers / enabled_providers — mesma capacidade, semântica auditável e à prova de ordem:
- Blocklist: um
denypor provedor indesejado. - Allowlist:
deny *seguido de umallowpor provedor aprovado.
06Em frotas
Policies dentro de configuração gerenciada (arquivo de admin ou MDM) tornam-se invioláveis pelo usuário — a base do controle de provedores em enterprise. Combine com política de rede para governança completa de egress.