Controles de administrador do Claude Code: guia completo para equipes de TI e DevOps (2026)
Rama Adi Nugraha
Katelin Teen
Última edição June 9, 2026
Por que o Claude Code precisa de controles de administrador
Quando você implanta um agente de codificação em uma organização de engenharia, o perfil de risco é diferente do de implantar uma ferramenta de chat. O Claude Code pode executar comandos de shell, ler arquivos em toda uma base de código, abrir pull requests e — com as permissões certas — acessar a internet ou escrever em arquivos de segredos. Sem controles, dois modos de falha aparecem: os desenvolvedores ficam presos em uso cauteloso e confirmam cada ação manualmente, ou concedem permissões amplas e acabam com um agente que pode tecnicamente fazer qualquer coisa.
Nenhum desses é o que você quer. O que você realmente quer é algo mais próximo da Política de Grupo para IA: você define o que a ferramenta tem permissão de fazer no nível organizacional, os desenvolvedores obtêm um ambiente produtivo dentro dessas limitações, e você tem capacidade de auditoria se algo der errado.
É para isso que os controles de administrador do Claude Code foram projetados. Vamos percorrer cada camada do sistema.
A hierarquia de configuração de quatro níveis
Cada configuração do Claude Code é resolvida por uma pilha de precedência. Da prioridade mais alta para a mais baixa:
- Managed — implantado pela TI, maior prioridade, não pode ser substituído por nada
- Argumentos CLI — substituições apenas para a sessão (
--model sonnet,--permission-mode plan) - Projeto local (
.claude/settings.local.json) — substituições pessoais para este repositório, no gitignore - Projeto compartilhado (
.claude/settings.json) — compartilhado pela equipe, confirmado no git - Usuário (
~/.claude/settings.json) — padrões globais pessoais
A camada gerenciada é o teto e as configurações do usuário são o piso. As configurações de projeto são onde as equipes padronizam ferramentas. Configurações com valor de array como permissions.allow são mescladas entre escopos em vez de se substituírem — uma regra allow nas configurações do usuário se acumula com uma regra allow nas configurações do projeto. Valores escalares seguem a regra de winner-take-all do escopo mais alto que os define.
Uma nuance que vale a pena saber: o modo auto é ignorado quando definido nas configurações de projeto ou locais a partir da v2.1.142. Se você estiver definindo defaultMode: "auto" em uma configuração de projeto e se perguntando por que não tem efeito, é por isso — precisa vir das configurações do usuário ou gerenciadas.
Implantando configurações gerenciadas
Quatro mecanismos de entrega, todos lendo o mesmo formato JSON:
Gerenciado pelo servidor (Teams/Enterprise): Envie configurações a partir do console de administração em claude.ai. Requer um plano Claude for Teams ou Enterprise. Use forceRemoteSettingsRefresh: true para bloquear a inicialização da sessão até que o envio seja confirmado — útil quando sua atualização de política precisa entrar em vigor antes que qualquer desenvolvedor possa continuar trabalhando.
MDM do macOS (Jamf, Kandji, Mosyle): Implante um perfil de configuração visando o domínio plist com.anthropic.claudecode. As chaves de nível superior espelham os nomes dos campos JSON; as configurações aninhadas usam dicionários plist, arrays usam arrays plist. Abordagem padrão para organizações que já gerenciam Macs com MDM.
Política de Grupo do Windows / Intune: Escreva JSON em HKLM\SOFTWARE\Policies\ClaudeCode com um valor Settings do tipo REG_SZ. Implante via Objeto de Política de Grupo ou um perfil de configuração do Intune. Para política somente em nível de usuário (quando nenhuma fonte de nível administrativo está presente), use HKCU\SOFTWARE\Policies\ClaudeCode.
Baseado em arquivo: Coloque managed-settings.json em:
- macOS:
/Library/Application Support/ClaudeCode/ - Linux / WSL:
/etc/claude-code/ - Windows:
C:\Program Files\ClaudeCode\
Baseado em arquivo também suporta um diretório drop-in managed-settings.d/ no mesmo local. Os arquivos são classificados alfabeticamente e mesclados profundamente — escalares de arquivos posteriores ganham, arrays são concatenados e desduplicados. Útil se várias ferramentas de segurança ou equipes precisam contribuir com fragmentos de política separados sem sobrescrever uns aos outros.
Para política dinâmica derivada de postura de dispositivo ou um serviço de conformidade remoto, a chave policyHelper aponta para um executável que calcula o JSON de configurações na inicialização. O binário escreve um envelope JSON (com configurações sob uma chave managedSettings) no stdout, e o Claude Code o lê antes do início da sessão. Disponível desde a v2.1.136.
Para verificar o que está ativo, execute /status dentro do Claude Code. A guia Status mostra uma linha Setting sources listando cada camada ativa, com o canal de entrega entre parênteses: Enterprise managed settings (remote), (plist), (HKLM), (file).
Permissões: regras allow, ask e deny
O sistema de permissões é como você expressa o que o Claude pode fazer sem perguntar e o que não pode tocar. Três tipos de regras:
- Allow — o Claude executa a ferramenta automaticamente, sem prompt
- Ask — o Claude solicita ao desenvolvedor antes de executar (padrão para a maioria das ferramentas)
- Deny — o Claude não pode usar a ferramenta de forma alguma
As regras seguem o formato Tool ou Tool(specifier). Um deny simples como "Bash" remove a ferramenta inteira do contexto do Claude, de modo que o Claude nunca tenta usá-la. Um deny com escopo como "Bash(rm *)" mantém a ferramenta disponível, mas bloqueia chamadas correspondentes em tempo de execução.
A ordem de avaliação é sempre deny primeiro, depois ask, depois allow — e a primeira regra correspondente vence independentemente de qual escopo ela veio. Um deny nas configurações do usuário bloqueia um allow de nível de projeto. Um deny gerenciado não pode ser desbloqueado por nenhum escopo inferior.
Uma base prática em .claude/settings.json para um ambiente de equipe:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)"
],
"deny": [
"Bash(curl *)",
"Bash(wget *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"WebFetch"
]
}
}
Isso aprova automaticamente comandos de desenvolvimento comuns enquanto bloqueia ferramentas de rede e leituras de arquivos sensíveis.
Padrões de regras de permissão que você deve conhecer
Wildcards correspondem a argumentos. Bash(npm run *) corresponde a npm run test --watch — o * abrange múltiplos argumentos, incluindo espaços. Bash(git *) corresponde a git log --oneline --all. Um espaço antes de * impõe um limite de palavra: Bash(ls *) corresponde a ls -la, mas não a lsof.
Curl com restrição de URL é frágil. Bash(curl http://github.com/ *) falha em curl -X GET http://github.com/... (opções antes da URL), curl https://github.com/... (protocolo diferente) ou variáveis de ambiente contendo a URL. Para restrição de domínio confiável, use WebFetch(domain:github.com) para domínios permitidos e negue completamente as ferramentas de rede Bash. A explicação completa está na referência de permissões.
Comandos compostos são divididos antes de corresponder. Uma regra allow para npm test não cobre npm test && curl evil.com. O Claude Code divide em &&, ||, ;, | e verifica cada subcomando independentemente.
Padrões Read/Edit seguem a sintaxe gitignore. Read(./.env) e Read(**/.env) são equivalentes — ambos bloqueiam qualquer .env no diretório atual ou abaixo. Use Read(//**/.env) para bloquear arquivos .env em qualquer lugar do sistema de arquivos.
Modos de permissão
Seis modos de permissão mudam como chamadas de ferramentas sem correspondência são tratadas:
| Modo | O que faz |
|---|---|
default | Prompt no primeiro uso de cada ferramenta |
acceptEdits | Aprovar automaticamente edições de arquivos e comandos de sistema de arquivos seguros |
plan | Somente leitura — sem modificações de arquivos |
auto | Verificações de segurança em segundo plano aprovam automaticamente chamadas alinhadas (visualização de pesquisa) |
dontAsk | Negar automaticamente a menos que pré-aprovado via regras allow |
bypassPermissions | Ignorar todos os prompts — apenas para contêineres/VMs isolados |
Defina defaultMode nas configurações para bloquear o modo de início. Para evitar que o modo bypassPermissions seja ativado, adicione às suas configurações gerenciadas:
{
"permissions": {
"disableBypassPermissionsMode": "disable"
}
}
Isso fecha completamente o flag --dangerously-skip-permissions — os desenvolvedores veem um erro se tentarem usá-lo. Mesmo padrão para o modo auto: "disableAutoMode": "disable".
Configurações somente gerenciadas: os controles de bloqueio exclusivos do administrador
Várias configurações só têm efeito quando implantadas via configurações gerenciadas. Colocá-las em arquivos de usuário ou de projeto não tem efeito — elas são genuinamente somente para administradores:
| Configuração | O que aplica |
|---|---|
allowManagedPermissionRulesOnly | Bloqueia configurações de usuário e projeto de definir qualquer regra allow/ask/deny. Apenas regras gerenciadas se aplicam. |
allowManagedHooksOnly | Apenas hooks de configurações gerenciadas ou plugins habilitados por força são executados. Hooks de usuário e projeto são bloqueados. |
allowManagedMcpServersOnly | Apenas servidores MCP em allowedMcpServers de configurações gerenciadas são usados. |
strictKnownMarketplaces | Controla quais marketplaces de plugins os usuários podem adicionar. Array vazio bloqueia todas as novas adições de marketplace. |
strictPluginOnlyCustomization | Força habilidades, agentes, hooks e/ou servidores MCP a virem apenas de plugins. |
forceLoginMethod | Restringir login a contas claudeai ou contas console. |
forceLoginOrgUUID | Exigir login em um UUID de org Anthropic específico. |
requiredMinimumVersion | Bloquear inicialização se a versão do Claude Code estiver abaixo disso. |
requiredMaximumVersion | Bloquear inicialização se a versão do Claude Code estiver acima disso. |
claudeMd | Injetar instruções de toda a organização que aparecem em cada sessão. |
channelsEnabled | Habilitar ou desabilitar canais (integrações) em toda a organização. |
forceRemoteSettingsRefresh | Bloquear a inicialização até que as configurações gerenciadas sejam obtidas novamente do servidor. |
A combinação de allowManagedPermissionRulesOnly: true + allowManagedHooksOnly: true lhe dá um perímetro sólido: nenhum desenvolvedor pode expandir o que o Claude está autorizado a fazer além do que suas configurações gerenciadas definem. Tudo passa por regras e hooks aprovados pela TI, nada mais.
Sandbox: isolamento de sistema de arquivos e rede no nível do sistema operacional
O sandbox é uma camada de segurança separada das permissões. As permissões regem o que o Claude tenta fazer. O sandbox aplica o que os comandos Bash podem realmente alcançar no nível do sistema operacional — usando o isolamento de processo nativo do macOS (Seatbelt) e Linux seccomp/namespaces para aplicar limites de leitura/escrita do sistema de arquivos e regras de acesso à rede.
Uma configuração de sandbox base para uma máquina de desenvolvedor:
{
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519"
],
"allowWrite": ["/tmp/build", "~/.kube"]
},
"network": {
"allowedDomains": [
"github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com"
]
}
}
}
Com autoAllowBashIfSandboxed: true (o padrão), os comandos Bash que permanecem dentro dos limites do sandbox são executados sem prompts — o limite do sandbox substitui os diálogos de confirmação por comando. Os desenvolvedores obtêm um fluxo mais rápido; você obtém a aplicação da política.
Três flags de sandbox somente gerenciados valem a pena conhecer para ambientes mais rigorosos:
sandbox.network.allowManagedDomainsOnly: true— apenas domínios emallowedDomainsgerenciados são acessíveis; adições no nível do projeto são ignoradassandbox.filesystem.allowManagedReadPathsOnly: true— apenas caminhosfilesystem.allowReadgerenciados são respeitadossandbox.network.allowUnixSockets— necessário no macOS para permitir o acesso ao socket Docker (/var/run/docker.sock)
O sandbox se aplica apenas a comandos Bash e seus processos filhos. Ele não restringe as ferramentas Read/Write integradas do Claude — essas são governadas pelas regras de permissão acima. Use ambas as camadas juntas para defesa em profundidade: as regras de permissão bloqueiam o Claude de tentar acesso não autorizado, e o sandbox impede qualquer coisa que passe pelo nível do sistema operacional.
Para ambientes de contêiner, CI e WSL, consulte o guia de sandboxing da Anthropic — a configuração difere nesses ambientes.
Hooks para aplicação de políticas
Hooks são comandos shell, endpoints HTTP ou prompts avaliados por LLM que são acionados em pontos específicos do ciclo de vida. Para uso administrativo, PreToolUse é o evento chave: ele é acionado antes de qualquer chamada de ferramenta e pode bloquear a chamada antes que ela aconteça — mesmo que uma regra allow a permitisse.
Um hook de segurança baseado em shell que bloqueia comandos destrutivos:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "/usr/local/bin/claude-security-check.sh",
"args": []
}
]
}
]
}
}
O hook recebe a chamada de ferramenta completa como JSON no stdin. Para bloquear:
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "rm -rf bloqueado pela política de segurança da organização"
}
}
Código de saída 0 sem saída significa "sem decisão" — o fluxo normal de permissões continua. O hook pode negar, mas o silêncio não aprova.
Para política centralizada baseada em HTTP, use type: "http" para postar eventos de chamada de ferramenta para seu serviço de segurança e ler a decisão da resposta. Isso permite que uma equipe central execute a avaliação de políticas sem distribuir scripts shell para cada máquina de desenvolvedor.
Dois outros eventos úteis para governança:
ConfigChange— acionado quando um arquivo de configurações muda no meio da sessão. Use isso para detectar quando os desenvolvedores modificam suas regras de permissão durante uma sessão e poste no seu SIEM ou Slack para visibilidade.SessionStart— acionado na abertura da sessão. Bom para injetar metadados de auditoria, verificar requisitos de versão ou confirmar que o usuário está na rede antes de permitir operações sensíveis.
Com allowManagedHooksOnly: true nas configurações gerenciadas, apenas os hooks implantados via seu canal gerenciado são executados. Hooks criados por desenvolvedores no projeto .claude/settings.json são silenciosamente ignorados. Consulte a referência completa de hooks para todos os eventos disponíveis.
Configuração de rede e proxy
Para ambientes que roteiam o tráfego por um proxy corporativo, o Claude Code lê variáveis de ambiente de proxy padrão:
HTTPS_PROXY=https://proxy.example.com:8080
HTTP_PROXY=http://proxy.example.com:8080
NO_PROXY="localhost,192.168.1.1,.internal.example.com"
Defina-as no bloco env das configurações gerenciadas para que se apliquem a cada sessão sem configuração do desenvolvedor:
{
"env": {
"HTTPS_PROXY": "https://proxy.example.com:8080",
"NO_PROXY": "localhost,.internal.example.com"
}
}
Para inspeção TLS empresarial (CrowdStrike Falcon, Zscaler), o Claude Code confia tanto no seu conjunto de CA Mozilla incluído quanto no armazenamento de certificados do sistema operacional por padrão. Se seu proxy usa uma CA personalizada que não está no armazenamento do sistema operacional:
{
"env": {
"NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/enterprise-ca.pem"
}
}
Para autenticação TLS mútua:
{
"env": {
"CLAUDE_CODE_CLIENT_CERT": "/etc/ssl/certs/claude-client.pem",
"CLAUDE_CODE_CLIENT_KEY": "/etc/ssl/private/claude-client-key.pem"
}
}
Sua lista de permissões do firewall precisa destas URLs no mínimo:
| URL | Necessário para |
|---|---|
api.anthropic.com | Chamadas à API do Claude |
claude.ai | Autenticação de conta Claude.ai |
platform.claude.com | Autenticação de conta de console |
downloads.claude.ai | Downloads de plugins e atualização automática |
bridge.claudeusercontent.com | Extensão Claude in Chrome |
raw.githubusercontent.com | Notas de versão e marketplace de plugins |
Ao implantar pelo Amazon Bedrock, Google Vertex AI ou Microsoft Foundry, o tráfego do modelo vai para seu provedor de nuvem em vez de api.anthropic.com. Defina CLAUDE_CODE_USE_BEDROCK=1 (ou o equivalente) no bloco env e configure ANTHROPIC_BEDROCK_BASE_URL se estiver roteando por um gateway LLM. A configuração completa do provedor de nuvem está no guia de integrações de terceiros da Anthropic.
Governança de MCP e plugins
Servidores MCP estendem o Claude com integrações de ferramentas externas — Jira, Notion, GitHub, bancos de dados internos. Do ponto de vista da governança, o risco é que os desenvolvedores se conectem a servidores não confiáveis ou instalem plugins de marketplace não verificados.
Controlar o acesso MCP via configurações gerenciadas:
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverName": "jira" }
],
"deniedMcpServers": [
{ "serverName": "filesystem" }
],
"allowManagedMcpServersOnly": true
}
Com allowManagedMcpServersOnly: true, os arquivos .mcp.json do projeto são ignorados — apenas servidores na lista de permissões gerenciada são executados. Entradas de lista de negação ainda se mesclam de todos os escopos, portanto qualquer escopo pode bloquear um servidor mesmo quando a lista de permissões está em vigor.
Controlar marketplaces de plugins:
{
"strictKnownMarketplaces": [
{ "source": "github", "repo": "acme-corp/approved-claude-plugins" }
],
"blockedMarketplaces": [
{ "source": "github", "repo": "untrusted-org/plugins" }
]
}
strictKnownMarketplaces com uma lista específica significa que os desenvolvedores só podem adicionar marketplaces nessa lista. Um array vazio [] bloqueia completamente todas as novas adições de marketplace. blockedMarketplaces é aplicado antes de operações de rede ou sistema de arquivos — fontes bloqueadas nunca tocam o disco.
strictPluginOnlyCustomization vai mais longe, exigindo que todas as habilidades, agentes, hooks e servidores MCP venham de plugins em vez de arquivos de usuário ou de projeto:
{
"strictPluginOnlyCustomization": ["skills", "hooks"]
}
Passe true para bloquear todas as quatro superfícies (habilidades, agentes, hooks, MCP) ou um array nomeando apenas as que você quer bloquear. Isso garante que toda a personalização do Claude Code em sua organização flua por plugins aprovados e distribuídos em vez de configuração ad-hoc do desenvolvedor. Consulte a visão geral do plugin do Claude Code para contexto sobre o que o sistema de plugins permite.
CLAUDE.md como contexto de toda a organização
Os arquivos CLAUDE.md são a camada de instrução — eles dizem ao Claude o que priorizar, enquanto os arquivos de configurações definem o que ele tem permissão de fazer. A configuração gerenciada claudeMd injeta instruções de toda a organização em cada sessão, independentemente do conteúdo de CLAUDE.md no nível do projeto:
{
"claudeMd": "Sempre execute `make lint` antes de confirmar. Nunca modifique arquivos em /vendor. Segurança: use consultas parametrizadas, nunca registre credenciais. Documentação interna em wiki.internal/engineering."
}
Ao contrário de um CLAUDE.md no nível do projeto que os desenvolvedores podem substituir localmente, o claudeMd gerenciado não pode ser excluído ou ignorado. É um canal confiável para padrões de codificação de toda a organização, requisitos de segurança e links para recursos internos que devem estar em cada sessão.
Para contexto específico do projeto, confirme CLAUDE.md na raiz do repositório — cada colaborador recebe as mesmas instruções, e o guia de implantação do Claude Code explica como estruturá-los para grandes monorepos. A configuração claudeMdExcludes permite que você pule arquivos CLAUDE.md de diretórios vendor ou código de terceiros que você não quer que polua o contexto do Claude.
Monitorando o uso do Claude Code
O Claude Code exporta telemetria via OpenTelemetry, que se integra a qualquer stack compatível com OTLP — Datadog, Honeycomb, Grafana:
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-collector:4318",
"OTEL_RESOURCE_ATTRIBUTES": "service.name=claude-code"
}
}
As métricas disponíveis incluem atividade de sessão, contagens de uso de ferramentas por tipo, uso do modelo e taxas de erro. Para sessões na nuvem, todas as operações são registradas automaticamente para conformidade.
O hook ConfigChange (descrito acima) fornece sinais em tempo real quando os arquivos de configurações mudam no meio da sessão. Combiná-lo com seu SIEM fornece uma trilha de auditoria de modificações de configuração.
Para relatórios de uso no nível da equipe, o blog usage-analytics-claude-code tem um guia completo sobre a configuração de análise de uso do Claude Code, incluindo as métricas OTLP disponíveis e o que cada uma indica.
Teams vs Enterprise: o que cada plano adiciona para administradores
| Capacidade | Teams | Enterprise |
|---|---|---|
| Configurações de projeto (.claude/settings.json) | Sim | Sim |
| Configurações gerenciadas baseadas em MDM/arquivo | Sim | Sim |
| Configurações gerenciadas pelo servidor (push do console de admin) | Limitado | Completo |
| SSO e captura de domínio | Não | Sim |
Aplicação de forceLoginOrgUUID | Não | Sim |
| Configurações de política gerenciadas em toda a organização | Parcial | Completo |
| Controle remoto e controles de administrador de sessão web | Sim | Sim |
| Acesso à API de conformidade (SOC 2 / ISO 27001) | Não | Sim |
| Painel de uso centralizado | Sim | Sim |
| Suporte dedicado / SLA | Não | Sim |
Para implantar o Claude Code em equipes de aproximadamente menos de 50 pessoas, o Claude for Teams com configurações gerenciadas baseadas em arquivo ou MDM geralmente cobre o essencial. O Enterprise adiciona SSO, forceLoginOrgUUID para impor associação à organização e configurações gerenciadas pelo servidor enviadas de um console central — a escolha certa para organizações com Active Directory, Okta ou gerenciamento de identidade similar, ou com requisitos de conformidade que precisam da documentação do Anthropic Trust Center (SOC 2 Tipo 2, ISO 27001 ambos certificados a partir de 2026).
O guia completo do Claude Code Enterprise cobre aquisição, provisionamento de usuários e as etapas de configuração de SSO.
Um template de início rápido para configurações gerenciadas
Aqui está um managed-settings.json base que cobre o essencial para a maioria das organizações de engenharia conscientes de segurança. Implante em /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux), ou envie via MDM/Política de Grupo:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git diff *)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git stash *)",
"Bash(make *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(//home/**/.ssh/*)",
"Read(//root/.ssh/*)"
],
"disableBypassPermissionsMode": "disable"
},
"sandbox": {
"enabled": true,
"autoAllowBashIfSandboxed": true,
"filesystem": {
"denyRead": [
"~/.aws/credentials",
"~/.ssh/id_rsa",
"~/.ssh/id_ed25519",
"~/.ssh/id_ecdsa"
]
},
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"*.npmjs.org",
"registry.yarnpkg.com",
"api.anthropic.com",
"*.anthropic.com"
]
}
},
"claudeMd": "Siga o CLAUDE.md do projeto para padrões de codificação. Nunca registre credenciais, tokens ou segredos. Use consultas parametrizadas. Documentação interna: wiki.internal/engineering",
"companyAnnouncements": [
"A política corporativa do Claude Code se aplica a todas as sessões. Dúvidas: security@yourcompany.com"
],
"requiredMinimumVersion": "2.1.100",
"availableModels": ["opus", "sonnet", "haiku"]
}
Este template fecha --dangerously-skip-permissions, bloqueia leituras de chaves SSH e credenciais AWS, habilita o sandbox com Bash sandboxado aprovado automaticamente, restringe a rede de saída a domínios aprovados, injeta uma política de segurança mínima e fixa uma versão mínima.
Depois de executar isso por uma semana e auditar o que seus desenvolvedores realmente precisam na lista de permissões, considere adicionar "allowManagedPermissionRulesOnly": true para o bloqueio mais rigoroso possível. Essa configuração foi omitida aqui intencionalmente — ela deve ser adicionada apenas depois que você tiver certeza de que a lista de permissões cobre o fluxo de trabalho real da sua equipe.
A referência completa de settings.json cobre todas as ~80 chaves disponíveis se você precisar ajustar mais, e o guia de melhores práticas do Claude Code cobre a configuração do lado do desenvolvedor que complementa esta camada de administração.
Experimente o eesel.ai
Se você está pensando cuidadosamente sobre governança de IA para sua organização de engenharia, provavelmente está respondendo às mesmas perguntas no suporte, nas operações e em outras equipes. O eesel.ai implanta agentes de IA autônomos diretamente nas ferramentas que essas equipes já usam — Zendesk, Freshdesk, Slack, Jira e 100+ outros — com a mesma abordagem do sistema de permissões do Claude Code: os agentes operam dentro de limites claros que você configura, a equipe permanece no controle do que podem e não podem fazer, e a configuração leva minutos a partir do histórico de conhecimento existente. Sem nova interface para adotar, sem necessidade de engenharia de prompts.
Perguntas frequentes
Como impedir que desenvolvedores usem --dangerously-skip-permissions no Claude Code?
permissions.disableBypassPermissionsMode como "disable" nas suas configurações gerenciadas do Claude Code. Como as configurações gerenciadas estão no topo da pilha de precedência, não podem ser substituídas por nenhuma configuração de usuário ou projeto, nem mesmo por argumentos de linha de comando. Consulte a referência de permissões da Anthropic para a sintaxe completa.Qual é a diferença entre as configurações gerenciadas do Claude Code e as configurações de projeto?
.claude/settings.json, são confirmadas no git e se aplicam a todos os colaboradores do repositório, mas podem ser substituídas por configurações locais ou de usuário. Use configurações gerenciadas para política de conformidade; use configurações de projeto para convenções da equipe.Posso restringir quais modelos Claude os desenvolvedores podem usar no Claude Code?
availableModels às suas configurações gerenciadas para limitar quais modelos os usuários podem selecionar via /model ou --model — por exemplo ["sonnet", "haiku"] para excluir o Opus. Combine com a chave model para definir um padrão específico em toda a organização. Para implantações Bedrock ou Vertex, a variável de ambiente ANTHROPIC_DEFAULT_SONNET_MODEL fixa versões exatas do modelo.Como implanto os controles de administrador do Claude Code em todas as máquinas dos desenvolvedores?
com.anthropic.claudecode), Política de Grupo do Windows ou Intune (escrevendo JSON em HKLM\SOFTWARE\Policies\ClaudeCode), ou um arquivo colocado em /Library/Application Support/ClaudeCode/managed-settings.json no macOS ou /etc/claude-code/managed-settings.json no Linux. Os três leem o mesmo formato JSON. Para configurações gerenciadas pelo servidor em planos Team/Enterprise, use o console de administração.O que faz allowManagedPermissionRulesOnly nos controles de administrador do Claude Code?
true nas configurações gerenciadas, impede que configurações de usuário e projeto definam regras de allow, ask ou deny de permissões. Apenas as regras nas suas configurações gerenciadas se aplicam. Este é o bloqueio de permissões mais rigoroso disponível — útil quando a política de segurança exige que nenhum desenvolvedor possa auto-autorizar uma ferramenta que o Claude Code não foi pré-aprovado para usar.
