Source: https://aiprimetech.io/pt/blog/alibaba-bans-claude-code/ Jul 5, 2026 · 3 min · Notícias # Alibaba teria proibido o Claude Code por preocupações com segurança A Por [AI Prime Tech](https://aiprimetech.io/pt/) · Com auxílio de IA ## Alibaba Proíbe Claude Code: Trate o Relato como um Sinal para Aquisições, Não como um Veredito Uma grande organização de engenharia não precisa de prova de uma backdoor para suspender um agente de programação com IA. Basta uma pergunta sem resposta no lugar errado: “Esta ferramenta pode ler código-fonte que não podemos expor por restrições legais ou contratuais?” Essa é a perspectiva prática que eu usaria para analisar a suposta proibição do Claude Code no ambiente de trabalho da Alibaba. A preocupação relatada é séria, mas a conclusão para a engenharia não é “o Claude Code tem uma backdoor confirmada”. Isso não está comprovado pelos fatos públicos. A conclusão útil é mais específica e operacional: os agentes de programação com IA agora estão próximos o suficiente do código-fonte, dos sistemas de build, dos segredos, dos logs e dos fluxos de implantação para passarem pelo mesmo processo de aquisição e análise de segurança que plataformas de CI/CD, ferramentas de busca de código, ferramentas de observabilidade e notebooks de desenvolvedores. Em outras palavras: separe a alegação do plano de controle. A preocupação alegada ou relatada sobre uma backdoor deve ser tratada como uma afirmação não verificada até que haja evidências técnicas concretas. Mas as categorias de risco em torno do Claude Code são muito reais e merecem uma avaliação cuidadosa: qual código o agente pode acessar, quais comandos pode executar, qual telemetria sai da máquina, qual modelo processa o prompt, quais regras de retenção se aplicam e como a organização impõe políticas em milhares de estações de trabalho de desenvolvedores. Essa é a questão que deve importar para os líderes de engenharia. ## O Que uma Proibição do Claude Code no Trabalho Realmente Significa Quando uma empresa proíbe ou suspende uma ferramenta de desenvolvimento, as pessoas costumam interpretar isso como uma condenação técnica. Na prática, as proibições frequentemente refletem situações do processo de aquisição. Uma “proibição” pode significar várias coisas diferentes: | Situação da política | O que geralmente significa | Impacto na engenharia | Suspensão temporária | A análise de segurança, jurídica ou de aquisição está incompleta | Os desenvolvedores deixam de usar a ferramenta até a conclusão da análise | Bloqueio por política de rede | Domínios, instalações de pacotes ou binários estão sujeitos a restrições | A ferramenta pode não conseguir se autenticar ou chamar APIs de modelos | Uso restrito | Permitido apenas em repositórios ou categorias de dados aprovados | As equipes precisam de classificação de repositórios e orientações de uso | Aprovação com controles | A ferramenta é permitida com registro de logs, configuração e treinamento | Os desenvolvedores podem usá-la dentro dos limites definidos | Proibição total | A organização decidiu que o risco supera o benefício | As equipes precisam de ferramentas alternativas e de um caminho de migração Portanto, se há relatos de que a Alibaba proíbe o Claude Code, isso não prova automaticamente um problema técnico oculto. Pode indicar que os avaliadores internos não ficaram satisfeitos com as garantias disponíveis ou que o fluxo de trabalho padrão da ferramenta entrava em conflito com a política interna de segurança. Essa distinção importa. Os engenheiros devem evitar transformar cada interrupção no processo de aquisição em uma conspiração. Mas também devem evitar descartá-la como mera burocracia. Ferramentas de desenvolvimento que atuam como agentes criam uma superfície de segurança maior que a de plugins de preenchimento automático. O Claude Code pode inspecionar um repositório, propor diffs, executar comandos quando permitido e ajudar a navegar por um sistema. É exatamente por isso que ele é útil e exatamente por isso que merece uma análise de verdade. ## A Questão Central de Segurança: O Que o Agente Pode Ver? O primeiro controle a avaliar é o acesso ao código. O Claude Code funciona dentro de um ambiente de desenvolvimento local e raciocina sobre os arquivos e o contexto disponíveis. Isso é poderoso porque permite compreender um projeto real, em vez de trechos isolados. Também significa que as equipes precisam pensar no repositório como dados. Na prática, os casos de risco não se limitam a arquivos que obviamente contêm segredos. Eles incluem: - Algoritmos proprietários - Detalhes de implementação específicos de clientes - Infraestrutura como código - Esquemas de APIs internas - Controles de segurança e lógica de detecção - Fixtures de teste contendo dados copiados de produção - Notas sobre incidentes, análises pós-incidente ou arquivos locais de rascunho - Arquivos de ambiente incluídos acidentalmente em um commit no repositório Uma armadilha comum: as equipes se concentram em verificar se os arquivos .env são ignorados, mas esquecem que testes e documentação frequentemente contêm informações suficientes para reconstruir fluxos de trabalho sensíveis. Um agente que analisa tests/integration/payments/ pode ver credenciais simuladas, endpoints de parceiros, regras do ciclo de vida de contas e comportamentos em situações de falha. Mesmo quando não há nenhum segredo, o repositório ainda pode ser confidencial. Uma política interna simples pode começar pela classificação dos repositórios: ``` { "repo": "payments-core", "classification": "restricted", "ai_tools": { "claude_code": "requires_security_exception", "allowed_models": [], "external_context_upload": false }, "data_notes": [ "Contains payment processor workflows", "Includes customer contract-specific behavior", "No production secrets permitted" ] } ``` A melhor política é sem graça e explícita. Os desenvolvedores não deveriam ter de deduzir se um repositório é seguro para um agente. ## Permissões do Agente: A Diferença Entre Ler e Agir O Claude Code não é apenas uma caixa de chat. Ele foi projetado para trabalhar no terminal, inspecionar arquivos, editar código e participar dos fluxos de desenvolvimento. Dependendo da configuração e da aprovação do usuário, um agente pode passar de “sugerir” para “agir”. Esse limite de permissões é o segundo ponto que as equipes de segurança devem analisar. Um padrão seguro comum é: ``` # Start Claude Code inside a specific repo, not from a broad home directory cd ~/work/approved-service claude ``` Depois, mantenha o diretório de trabalho bem delimitado. Não inicie ferramentas agênticas a partir de ~/work, ~/, nem da raiz de um monorepositório, a menos que toda a árvore esteja aprovada para esse uso. Para repositórios de maior risco, as equipes frequentemente desejam regras como: - O agente pode ler arquivos de código-fonte no repositório atual - O agente não pode acessar diretórios superiores - O agente não pode ler .env, material de chaves ou armazenamentos locais de credenciais - O agente pode propor patches, mas não executar comandos de implantação - O agente precisa de aprovação explícita antes de instalar pacotes ou executar comandos de shell - O agente não pode chamar serviços internos de produção a partir da máquina de um desenvolvedor Os mecanismos exatos dependem do seu ambiente, mas o modelo de segurança deve ser concreto. “Os desenvolvedores terão cuidado” não é um controle. Um padrão útil é combinar a política da ferramenta com limites do sistema operacional e do shell. Por exemplo, execute trabalhos sensíveis em um contêiner de desenvolvimento limpo, com uma montagem de sistema de arquivos restrita: ``` docker run --rm -it \ -v "$PWD:/workspace" \ -w /workspace \ --network=none \ node:22-bookworm bash ``` Esse exemplo desativa completamente o acesso à rede. Não é prático para todos os fluxos de trabalho, mas demonstra a ideia: não dependa apenas da ferramenta de IA para definir o limite. Use as mesmas primitivas de isolamento nas quais você já confia para builds e testes. ## Telemetria, Logs e o Que Sai da Máquina A próxima área de análise é a telemetria. Para qualquer agente de programação com IA, faça duas perguntas separadas: - Quais prompts e contextos do projeto são enviados a um provedor de modelos? - Qual telemetria operacional é coletada pela própria ferramenta? Esses aspectos são relacionados, mas não idênticos. A requisição ao modelo pode incluir contexto de código selecionado, nomes de arquivos, diffs, saída do terminal e instruções do usuário. A telemetria da ferramenta pode incluir metadados de uso, erros, dados de desempenho, eventos de funcionalidades ou logs de diagnóstico. Uma estrutura mínima de requisição para uma tarefa de programação poderia ser, conceitualmente, assim: ``` { "model": "claude-sonnet-4-6", "messages": [ { "role": "user", "content": "Refactor the auth middleware to return typed errors." } ], "context": { "files": [ { "path": "src/auth/middleware.ts", "content": "..." }, { "path": "src/auth/errors.ts", "content": "..." } ], "terminal_output": "npm test failed in auth.middleware.spec.ts" } } ``` Os detalhes reais de implementação variam, mas essa é a estrutura que os avaliadores de segurança devem considerar. O ativo sensível costuma ser o contexto, e não a instrução curta do usuário. Uma avaliação prática deve perguntar: - Os desenvolvedores conseguem ver quais arquivos estão incluídos no contexto? - É possível excluir caminhos sensíveis? - Os prompts ou as respostas são retidos? - Os prompts são usados para treinamento? - Como são tratados o monitoramento de abusos e os registros de segurança? - As configurações empresariais ou da API podem alterar o comportamento de retenção? - Quais logs são armazenados localmente? - Quais logs são enviados remotamente? A resposta adequada pode variar entre assinaturas pessoais, planos de equipe, planos empresariais, acesso direto à API e revendedores terceirizados. Não presuma que todos funcionem da mesma maneira. ## Roteamento de modelos e limites do fornecedor O roteamento de modelos é outra questão pouco discutida. Na linha atual do Claude, as equipes podem escolher entre Opus 4.8, Sonnet 4.6, Haiku 4.5 e Fable 5 com uma janela de contexto de 1M, dependendo da interface do produto e da disponibilidade. Para fluxos de trabalho de desenvolvimento, modelos da classe Sonnet costumam oferecer o equilíbrio adequado entre raciocínio, latência e custo; o Opus é útil para sessões mais difíceis de arquitetura ou depuração; o Haiku pode ser útil para tarefas rápidas e bem delimitadas; modelos de contexto longo mudam a avaliação para repositórios grandes e documentos de design extensos. Mas a área de compras precisa de uma pergunta mais precisa do que “qual modelo é o melhor?”. Ela precisa saber para onde vão os prompts. Uma lista de verificação de roteamento de modelos deve incluir: - Quais IDs de modelo são permitidos? - Qual limite geográfico ou contratual se aplica? - A ferramenta pode rotear solicitações para modelos alternativos? - Os usuários podem alterar o modelo selecionado? - Modelos beta ou de prévia são permitidos? - O endpoint da API é direto, passa por um proxy ou é intermediado por outro fornecedor? - Há registro de logs, armazenamento em cache ou transformações de prompts antes da chamada ao modelo? Para equipes que usam a API do Claude diretamente, centralizar o acesso por meio de um gateway interno pode ajudar: ``` from anthropic import Anthropic client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"]) message = client.messages.create( model="claude-sonnet-4-6", max_tokens=1200, messages=[ { "role": "user", "content": "Review this patch for unsafe database migrations:\n\n..." } ], ) print(message.content[0].text) ``` Esse padrão de acesso direto à API é mais fácil de compreender do que uma proliferação de ferramentas de desktop sem gerenciamento, mas traz suas próprias responsabilidades: você precisa implementar por conta própria autenticação, registro de logs, classificação de dados, limitação de taxa e aplicação de políticas. Algumas organizações usam um proxy interno que rejeita modelos não permitidos ou bloqueia repositórios restritos. Um esboço de política poderia ser assim: ``` { "allowed_models": [ "claude-sonnet-4-6", "claude-haiku-4-5" ], "blocked_models": [ "preview-*" ], "repo_rules": { "public": ["claude-sonnet-4-6", "claude-haiku-4-5"], "internal": ["claude-sonnet-4-6"], "restricted": [] } } ``` Isso não é glamoroso, mas é o tipo de controle que torna a avaliação de segurança concreta. ## A retenção de dados é uma questão contratual, não uma impressão Um erro comum é discutir a segurança de ferramentas de IA como se fosse apenas uma questão técnica. A retenção de dados também é uma questão contratual e de configuração da conta. Para o Claude Code e os fluxos de trabalho relacionados ao Claude, as equipes de engenharia devem confirmar os termos aplicáveis ao seu tipo exato de conta e à forma de implantação. Não copie uma resposta de outro nível de produto nem presuma que uma configuração de consumidor se aplique a uma integração empresarial. Em reuniões de avaliação, gosto de separar as questões de retenção em quatro categorias: | Tipo de dado | Exemplo | Pergunta de avaliação | Conteúdo do prompt | Instrução do usuário mais os arquivos de código-fonte selecionados | Ele é armazenado, por quanto tempo e para qual finalidade? | Conteúdo da resposta | Código gerado, análise, sugestões de patches | A saída é retida junto com o prompt? | Metadados | Modelo, carimbo de data e hora, contagens de tokens, erros | Eles estão vinculados à identidade do usuário ou ao repositório? | Artefatos locais | Logs, transcrições, contexto em cache | Onde eles são armazenados na máquina do desenvolvedor? É fácil deixar passar a categoria de artefatos locais. Mesmo que uma política do provedor seja aceitável, uma transcrição local contendo código proprietário ainda pode ser um problema se for parar em uma pasta sincronizada, em um backup não criptografado ou em um pacote de suporte. Na prática, recomendo que as equipes documentem uma regra simples de tratamento: transcrições de programação com IA são artefatos de desenvolvimento e herdam a sensibilidade do arquivo mais sensível incluído na sessão. ## Controles de políticas internas que realmente funcionam As melhores políticas para ferramentas de IA são curtas o suficiente para os desenvolvedores lembrarem e específicas o suficiente para a equipe de segurança aplicar. Uma política viável de Claude Code para uma organização de engenharia de médio porte poderia incluir: - Somente tipos de conta aprovados - Não usar em repositórios restritos sem uma exceção - Não incluir segredos, credenciais, dados de produção ou dados de clientes nos prompts - Iniciar somente a partir da raiz do repositório pretendido - Exigir aprovação para comandos de shell que modifiquem arquivos, instalem pacotes, acessem redes ou interajam com sistemas de implantação - Usar somente modelos da lista aprovada - Armazenar transcrições conforme a classificação do repositório - Relatar comportamentos inesperados da ferramenta pelo canal de recebimento de relatos de segurança Essa política deve ser acompanhada de controles técnicos. Os exemplos incluem: ``` # Block accidental secret exposure before commits git secrets --scan gitleaks detect --source . ``` E um arquivo de exclusão no nível do projeto para o contexto de IA, se o seu conjunto de ferramentas oferecer suporte a isso: ``` .env .env.* *.pem *.key secrets/ credentials/ customer_exports/ prod_dumps/ incident_notes/ ``` Arquivos de exclusão não são suficientes por si só. São mecanismos de proteção, não um programa de governança de dados. Mas reduzem o número de erros comuns que se tornam incidentes de segurança. Para equipes que estão padronizando o uso do Claude Code, eu também manteria um arquivo versionado AI_USAGE.md próximo à raiz do repositório: ``` # AI Tool Policy Classification: internal Allowed: - Use Claude Code for tests, refactors, local debugging, and documentation. - Include source files from this repository. Not allowed: - Do not paste customer data. - Do not include `.env` files, credentials, or production logs. - Do not ask the agent to run deployment commands. Approved models: - claude-sonnet-4-6 - claude-haiku-4-5 ``` Os desenvolvedores precisam ter a política disponível onde trabalham, não apenas em uma wiki de conformidade. ## A alegação de backdoor deve ser tratada separadamente A preocupação relatada com um backdoor é a parte que mais chama a atenção na história da Alibaba, mas também é a mais fácil de tratar de forma inadequada. Um backdoor é uma alegação técnica específica. Ele implica acesso oculto intencional, comportamento não autorizado ou um caminho de controle encoberto. Isso exige evidências: comportamento reproduzível, rastros de rede, análise de binários, logs, revisão do código-fonte ou um relatório de incidente confiável com detalhes suficientes para avaliação. Sem isso, continua sendo uma alegação ou um relato, não uma constatação confirmada. As equipes de segurança ainda devem responder de forma racional. Uma empresa pode suspender o uso de uma ferramenta enquanto investiga uma alegação, especialmente se a ferramenta tiver amplo acesso ao código-fonte. Isso não é pânico; é gestão normal de riscos. A postura adequada é: - Não afirmar que o Claude Code tem um backdoor confirmado, a menos que as evidências o comprovem. - Não descartar a preocupação apenas porque ela não foi confirmada. - Avaliar a ferramenta com base em controles verificáveis. - Decidir se uma restrição temporária é justificada para o seu ambiente. - Reavaliar a decisão à medida que os fatos, as respostas do fornecedor e os testes internos se aprimorem. Esse é o meio-termo maduro. ## O que realmente acontece quando as equipes pulam a avaliação A falha raramente é dramática no início. Ela parece conveniência. Uma equipe usa um agente em um repositório de frontend voltado ao público. Outra o usa em um serviço com contratos de API internos. Alguém cola um rastreamento de pilha de produção. Outra pessoa pede que ele resuma um documento local sobre um incidente. Um engenheiro sênior o executa a partir da raiz de um monorepositório porque quer contexto entre serviços. Ninguém está tentando vazar dados; o fluxo de trabalho simplesmente não tem limites. Então a área de compras pergunta quais repositórios foram usados com quais ferramentas, e ninguém consegue responder. Esse é o verdadeiro risco por trás da proibição relatada da Alibaba: não que todo agente de programação com IA seja secretamente malicioso, mas que as organizações adotem ferramentas de desenvolvimento com agentes mais rápido do que conseguem observá-las e governá-las. O Claude Code é valioso justamente porque atua onde os engenheiros trabalham. Ele pode acelerar a escrita de testes, a navegação pela base de código, o planejamento de migrações e refatorações tediosas. Mas a mesma proximidade que o torna útil significa que ele deve ser tratado como parte do conjunto de elementos sujeitos aos controles de engenharia. ## Recomendações Práticas Trate a proibição relatada da Alibaba como um motivo para reforçar seu próprio processo de avaliação, não como prova de um backdoor confirmado no Claude Code. Antes de aprovar o Claude Code ou qualquer ferramenta comparável de programação com agentes, avalie: - Acesso ao código: quais repositórios, arquivos e artefatos locais a ferramenta pode ver - Permissões do agente: se ele pode executar comandos, editar arquivos, instalar pacotes ou acessar redes - Telemetria: quais prompts, respostas, metadados e diagnósticos são coletados - Roteamento de modelos: quais modelos Claude são permitidos e se existe roteamento para modelos alternativos - Retenção de dados: como o conteúdo dos prompts, as saídas, os metadados e os logs locais são armazenados - Controles de políticas: como a classificação dos repositórios e as orientações aos desenvolvedores são aplicadas Para a maioria das equipes, o objetivo não deve ser um sim ou não irrestrito. A melhor meta é a adoção controlada: contas aprovadas, modelos aprovados, classificações claras dos repositórios, isolamento local quando necessário e regras escritas que os desenvolvedores possam seguir sem interromper o trabalho. A alegação de backdoor pertence à categoria “investigar e verificar”. As práticas de segurança relacionadas pertencem à categoria “fazer agora”. [Programação](/pt/blog/tag/coding/)[Claude](/pt/blog/tag/claude/)[Segurança](/pt/blog/tag/security/) A [AI Prime Tech](https://aiprimetech.io/pt/) A AI Prime Tech publica este blog. Os artigos são redigidos com assistência de IA; confira detalhes específicos de cada versão, como IDs de modelos, preços e limites, na documentação oficial antes de se basear neles. Obtenha acesso mais barato à API do Claude Uma única chave de API para Claude Opus 5.5, Sonnet 5, Haiku 4.5 e Fable 5.1, além de GPT-6 modelos. Pague conforme o uso, sem assinatura. [Obtenha Sua Chave de API →](/register) A AI Prime Tech é um gateway de API independente de terceiros. Claude™ e Anthropic® são marcas comerciais da Anthropic, PBC. Não há afiliação nem endosso implícitos.