O que o time não desliga: configuração gerenciada de IA

Por que a configuração de cada pessoa não é governança?

Porque ela vale até a primeira pessoa com pressa. Nos textos anteriores, mostramos que regra escrita não é regra e que um guardrail decide cada ação do assistente pelo risco, pela regra da casa e pelo pedido da pessoa. Os dois dependem de uma coisa que ainda não discutimos: estar ligados na máquina de quem trabalha, e continuar ligados.

Imagine um time de cinco pessoas, cada uma com o seu assistente de IA configurado à mão. Uma instalou o guardrail, outra esqueceu, uma terceira desligou numa sexta à noite porque ele pediu aprovação para um push urgente e nunca religou. A quarta tem um arquivo de projeto que afrouxa um limiar. A quinta entrou ontem e ainda não sabe que o guardrail existe. O desenho é o mesmo para as cinco; a proteção real é diferente em cada máquina, e ninguém sabe qual.

A configuração gerenciada resolve isso tirando a decisão da máquina. A empresa define, num lugar só, o que vale para todos: quais plugins estão ligados, quais valores estão fixados, quais segredos sistêmicos a ferramenta recebe. O usuário não sobrescreve nada disso. Não por desconfiança das pessoas, mas porque a governança não pode depender da memória de cada uma.

Onde a configuração do assistente pode ser mudada, e quem vence?

Em vários níveis, e vence o mais alto que define a chave. Num assistente como o Claude Code, a mesma configuração pode vir de cinco lugares, do mais forte para o mais fraco.

A regra geral é simples: uma chave definida no nível da empresa vence a mesma chave em qualquer nível abaixo. Há uma exceção que importa. As listas de regras de permissão não se substituem; elas se somam. O que a empresa nega continua negado, e cada nível pode acrescentar permissões. Por isso uma permissão ampla num arquivo de projeto também vale, ao lado das da empresa, e algumas ferramentas oferecem um ajuste, só disponível no nível da empresa, para aceitar apenas as regras de permissão definidas por ela.

O erro comum é ler "a empresa vence" como "a empresa controla tudo". Ela vence nas chaves que define. Uma chave que a política da empresa não menciona fica livre para qualquer nível abaixo, inclusive o arquivo de um repositório, que qualquer pessoa com acesso altera, e que o próprio assistente pode editar. É daí que vem a próxima regra.

Por que fixar um valor que já é o padrão?

Porque uma chave ausente na configuração da empresa pode ser definida por qualquer nível abaixo, e uma chave presente vence todos. Fixar o valor, mesmo quando ele é igual ao padrão do código, é o que impede que alguém o rebaixe em silêncio.

Um exemplo. O guardrail lê seus limiares de variáveis de ambiente, com um padrão no código. Se a política da empresa não define o limiar de pedir aprovação, um `.claude/settings.json` de repositório pode definir um valor perto de 1, e naquele projeto o guardrail quase nunca pergunta nada. Não houve ataque, nem desligamento visível. Houve um arquivo de configuração num PR que ninguém leu com atenção, talvez sugerido pelo próprio assistente para "parar de pedir confirmação". Com o limiar fixado na política da empresa, esse arquivo não tem efeito.

Por isso a nossa política fixa os valores que decidem alguma coisa: os limiares de risco e de regra, a lista de ferramentas cujo conteúdo nunca vai ao classificador, os plugins obrigatórios. E um teste do próprio plugin falha se o padrão no código e o valor da política divergirem, para que a máquina fora da política, como a de CI, caia no mesmo valor que as outras.

A regra tem um complemento: o que fica ausente de propósito precisa estar escrito como decisão. Quando a postura do guardrail é de falha aberta, a chave que inverteria isso fica fora da política, e o documento da política diz que ligá-la é decisão da diretoria. Ausência por esquecimento e ausência por decisão parecem iguais no arquivo. Só o registro as distingue.

Como a empresa distribui plugins e regras sem pedir nada a ninguém?

Por um catálogo próprio, registrado pela configuração gerenciada. Um catálogo de plugins, que o Claude Code chama de marketplace, é um repositório da empresa com os plugins aprovados: guardrails, skills de contexto, conectores. A política registra o catálogo e liga os plugins obrigatórios. Plugin ligado pela política não pode ser desligado pelo usuário, e é isso que torna o guardrail obrigatório de fato, e não só recomendado.

Quatro decisões tornam a distribuição confiável.

1. Atualização automática ligada. Sem ela, cada máquina fica no commit em que clonou o catálogo, e um plugin corrigido na semana passada não chega a quem instalou no mês passado.
2. A versão é o commit. Sem número de versão declarado, cada merge chega como atualização. Se um plugin declarar versão, ela precisa mudar a cada entrega, porque a ferramenta compara o texto e mantém a cópia antiga em cache quando ele é igual.
3. Código de terceiro entra copiado, revisado e fixado por commit. Plugin com hook roda em toda ação de toda máquina da organização. Apontar o catálogo para o repositório de outra pessoa entrega a ela, a um commit de distância, a execução de código em todas as máquinas da empresa.
4. O catálogo tem CI própria. Cada PR valida o JSON de tudo que a ferramenta carrega, a sintaxe dos scripts, a fusão da política e os testes de cada plugin, e um check agregador reprova também o job que foi pulado. A CI do catálogo é a primeira aplicação do caminho estreito à própria governança.

Falta um detalhe que só aparece na prática: validar não é testar. Há configurações de catálogo que o validador aceita e que a ferramenta ignora ao carregar, e o plugin simplesmente não aparece. Por isso o checklist de cada PR do catálogo termina em "testado instalando de fato", com o plugin instalado numa máquina limpa e as skills, os hooks e os conectores conferidos um a um. E renomear um plugin exige atualizar a política à mão: a ferramenta migra a configuração das pessoas, mas não a da empresa, que para ela é só leitura.

O resultado é o que dá nome a este texto: quem entra no time faz login com a conta da empresa e recebe tudo. Ninguém precisa lembrar de instalar o guardrail, porque não há o que instalar.

Onde ficam os segredos da configuração?

Só no console, preenchidos direto no campo da política, que funciona como cofre. Nunca no arquivo versionado, nem com valor vazio.

Alguns plugins precisam de um segredo sistêmico, um só para a organização, como a chave do classificador do guardrail. Esse valor vai na configuração gerenciada, para chegar a todas as máquinas, e é preenchido no console. O valor não passa por terminal, histórico de shell, registro de sessão ou disco. O arquivo versionado da política lista o nome do segredo, num lugar só, e nunca o valor.

O "nem vazio" é a parte que costuma surpreender. Se o arquivo versionado tiver a chave do segredo com valor vazio, a próxima versão da política colada no console sobrescreve o valor configurado com nada. A ferramenta aceita, todos perdem o acesso ao mesmo tempo, e o sintoma aparece depois, como uma falha de autenticação sem causa aparente. Por isso o script que monta a política remove qualquer valor vazio e, ao terminar, lista os segredos que ficaram de fora, com o lembrete de preservá-los no console.

Dois cuidados completam a regra.

• O campo do console é um documento só. A política pode viver em vários arquivos no repositório, mas o console recebe um JSON único, sem fusão. Colar os arquivos um depois do outro produz JSON inválido, ou duas chaves iguais em que a última vence e apaga a primeira sem aviso. A fusão é trabalho de script, não de atenção humana.
• Preserve os segredos da lista, e só eles. Ao colar uma versão nova, preservar tudo o que já estava no console mantém distribuída para a organização inteira a credencial de uma integração aposentada. A lista canônica diz o que fica; o resto sai.

E vale dizer em voz alta o custo do segredo sistêmico. O sistema do outro lado não distingue quem agiu, a troca do valor afeta todos de uma vez e o escopo do segredo é o teto de privilégio de qualquer pessoa com o assistente configurado. É um compromisso consciente, e não uma solução sem custo.

O que a configuração gerenciada não garante?

Ela não é uma fronteira de segurança contra quem quer contorná-la. A configuração entregue pelo console é aplicada pela própria ferramenta, na máquina da pessoa. Numa máquina que a pessoa administra, quem estiver decidido a contornar consegue: com outra versão da ferramenta, outro provedor de modelo ou um arquivo alterado.

Ela também não é instantânea. A política chega quando a sessão abre e é atualizada de tempos em tempos, então uma mudança feita agora não alcança na hora quem está com a sessão aberta. Ao mudar algo que importa, peça a todos que reiniciem e confira numa máquina: a ferramenta mostra quais fontes de configuração carregou, e o guardrail diz, ao abrir a sessão, se está operante.

O que a configuração gerenciada resolve é outra coisa: a pressa, o esquecimento e a diferença entre máquinas. Para o caso de má-fé, a resposta não está nela. Está no gerenciamento de dispositivos, onde existe, porque ele protege o arquivo de política no sistema operacional, e na trilha do guardrail, que mostra o que aconteceu. E está, sobretudo, no fato de que nada chega a produção sem passar pelo repositório, pela revisão e pela CI.

A Anthropic, ao anunciar os controles de administração do Claude Code para planos empresariais, em agosto de 2025, descreveu a política gerenciada como a forma de a ferramenta seguir as regras internas da organização: ferramentas permitidas, acesso a arquivos e configuração de conectores. É uma camada de política. Não é uma promessa de que ninguém consegue sair dela. A ideia também não é nova. O guia de gestão de configuração com foco em segurança do NIST, de 2011, trata a configuração de base aprovada, aplicada e monitorada como parte da segurança de qualquer sistema. O assistente de IA é só mais um software que precisa da sua.

O que ainda depende de decisão, e quem paga cada uma?

Três escolhas costumam ficar em aberto depois da primeira versão da política. Nenhuma é óbvia, e cada uma tem um custo que alguém paga.

A segunda decisão tem uma ordem certa. Primeiro, inventarie o que está instalado em cada máquina e de onde veio. Depois, decida o que é aprovado. Só então ligue o bloqueio, com a lista completa. Fazer o inverso é descobrir a lista pelo que quebrou.

A terceira fecha uma lacuna que o texto sobre guardrails deixou aberta: a leitura pura não passa pelo classificador, e o bloqueio certo para arquivo de segredo é uma regra de negação da própria ferramenta, aplicada antes de qualquer hook. Ela custa pouco e protege muito, mas custa alguma coisa, e quem paga precisa saber antes.

Em todas as três, quem decide é a diretoria, por escrito, com o custo na mesa. Quem executa é quem administra a política, por PR.

Por onde começar?

Pela política num repositório, antes de qualquer valor no console.

1. Crie um repositório para a política e o catálogo, com revisão por PR.
2. Registre o catálogo e ligue os plugins obrigatórios pela configuração gerenciada, com atualização automática.
3. Fixe os valores que decidem alguma coisa, mesmo os que já são o padrão.
4. Ponha os segredos sistêmicos só no console, com a lista de nomes num lugar só e um script que monta a política.
5. Dê ao catálogo uma CI que bloqueia, e teste cada plugin instalando de fato.
6. Escreva as decisões pendentes, com o custo e quem paga.

A configuração gerenciada é a camada mais próxima de quem digita. Ela faz o mesmo trilho valer em todas as máquinas, inclusive na de quem chegou ontem. O que o assistente alcança a partir dali, e o que ele nunca escreve, é a próxima camada.