Claude Code ou OpenCode: qual é mais fácil de aprovar com o time de segurança?

Um agente de terminal lê o repositório inteiro, roda comando na máquina do dev e conversa com um modelo que mora fora da sua rede

É nesse ponto que o time de segurança entra na conversa, e a discussão deixa de ser sobre produtividade

Este post é roteiro pra reunião interna, não parecer jurídico: a ideia é você chegar na pauta com as perguntas certas e com o que cada ferramenta responde na documentação oficial

E são sempre as mesmas três perguntas

1. pra onde vai o código que o agente lê
2. quem controla a credencial e o que o agente pode fazer
3. o que fica na máquina do dev, e o que dá pra auditar depois

Bora responder uma por uma?

Para onde vai o código: trânsito de dados nas duas ferramentas

Essa é a primeira pergunta e costuma ser a que derruba a reunião logo no começo

A segurança quer saber duas coisas diferentes que todo mundo mistura: se o conteúdo vira treino de modelo, e quanto tempo ele fica guardado em algum lugar

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O seu código vira treino de modelo?

Nos termos comerciais da Anthropic a resposta é não, com uma exceção clara: se o cliente optar por fornecer os dados pra melhoria de modelo, como no Developer Partner Program

No OpenCode a documentação Enterprise vai por outro caminho: ela diz que a ferramenta não armazena o código nem o contexto, porque o processamento é local ou a chamada é direta pro provedor de IA

Se liga na diferença de natureza aqui, porque ela muda a pergunta da reunião: num caso você audita a política de UMA empresa que recebe o dado, no outro você audita a política do provedor de modelo que você mesmo escolheu plugar

Conta pessoal do dev entra nessa conta?

Esse é o furo silencioso e ele quase nunca aparece na apresentação bonita

Em contas Free, Pro e Max existe a configuração de permitir o uso dos dados pra melhorar modelos futuros, e quando ela está ligada isso inclui o uso do Claude Code a partir dessas contas

A retenção acompanha o botão: 5 anos com a opção ligada, 30 dias com ela desligada

Ou seja: aprovar a ferramenta e deixar cada dev entrar com a assinatura pessoal dele é aprovar outra coisa, não a mesma

O que sai da máquina quando alguém compartilha a conversa?

No OpenCode o compartilhamento vem em modo manual por padrão, e aceita manual, auto ou disabled

Quando o share é acionado, a conversa e os dados associados saem da máquina e vão pro serviço que hospeda as páginas de compartilhamento em opencode.ai

No Claude Code o equivalente é o /feedback, que manda uma cópia do histórico da conversa (código incluso) pra Anthropic, com escopo escolhido pelo usuário: a sessão atual por padrão, ou também as outras sessões do mesmo projeto das últimas 24 horas ou 7 dias

E tem o polegar pra cima ou pra baixo: a conversa ligada ao feedback fica retida por até 5 anos e é material passível de uso em treino

Esses dois botões, o share e o feedback, são o que eu levaria impresso pra reunião

Dá pra zerar a retenção?

No Claude Code existe o Zero Data Retention, mas com uma pegadinha operacional importante: ele não vem no Enterprise padrão nem é ligado pelo painel de admin

O ZDR é liberado por organização pelo time de conta da Anthropic, pra contas qualificadas do Claude for Enterprise, e cada nova organização precisa de habilitação separada

Ou seja, é conversa de contrato, não de checkbox 🙂

Quem controla a credencial e as permissões

Aqui a pergunta muda de tom: não é mais pra onde vai o dado, é quem manda no agente

O contraste entre as duas é bem nítido nesse eixo

Imposição pelo admin ou configuração versionada no repositório?

Essa é A diferença de filosofia entre as duas, e vale explicar o porquê antes do como

No Claude Code o controle desce de cima: as managed settings são distribuídas pelo admin, têm precedência máxima, e um deny em qualquer nível prevalece sobre os demais, inclusive sobre argumento de linha de comando

O dev não desliga

No OpenCode o controle mora no arquivo: ~/.config/opencode/opencode.json no perfil do usuário e opencode.json na raiz do projeto, e o do projeto tem a maior precedência entre os arquivos padrão

É ótimo pra revisar em pull request, porque a política vira diff

E é exatamente por isso que a segurança levanta a sobrancelha: se a regra está no repositório, quem tem commit no repositório mexe na regra

Pra fechar esse buraco, a oferta Enterprise do OpenCode existe justamente com config central, SSO e gateway de IA interno forçado, com os demais provedores desabilitados

Se a sua conversa já passou por quantos assentos o time precisa, lembra que os managed policy settings do Claude Code foram anunciados junto com os assentos premium pra clientes Team e Enterprise: controle de admin e plano andam juntos

E a flag que aprova tudo?

O OpenCode pode ser iniciado com opencode --auto, que aprova automaticamente os pedidos de permissão não negados explicitamente

Tome cuidado com essa: ela é a que mais assusta comitê em demonstração ao vivo

A ressalva importante, que está na própria documentação, é que as regras de deny continuam sendo aplicadas mesmo com a flag ligada

Então o desenho seguro é o mesmo dos dois lados: escreva o deny primeiro, discuta a conveniência depois

Como provar em qual endpoint a sessão está falando

O time de segurança não quer sua palavra, quer evidência

No Claude Code o /status exibe provider, base URL e proxy da sessão, e isso é literalmente a captura de tela que resolve a pergunta "tem certeza que não está saindo direto pra internet?"

O deploy também pode ser feito por Amazon Bedrock, Google Cloud e Microsoft Foundry, com proxy corporativo via HTTPS_PROXY ou HTTP_PROXY, e com um LLM gateway entre o Claude Code e o provedor

Já me ferrei com um detalhe parecido em outro contexto, e aqui tem um bem específico: ao implantar por Bedrock, Google Cloud, Microsoft Foundry ou Claude Platform na AWS, a Anthropic orienta fixar as versões de modelo por variável de ambiente, senão os apelidos resolvem pro padrão embutido do Claude Code

ANTHROPIC_DEFAULT_OPUS_MODEL=...
ANTHROPIC_DEFAULT_SONNET_MODEL=...
ANTHROPIC_DEFAULT_HAIKU_MODEL=...

Se a sua política diz "só modelo homologado", esse é o parafuso que segura a política de pé

No OpenCode o parafuso equivalente é a lista: disabled_providers pra bloquear e enabled_providers pra allowlist, e o provedor desabilitado não carrega nem se tiver variável de ambiente ou chave de API configurada na máquina

O que fica na máquina do dev e o que dá para auditar depois

A terceira pergunta é a mais concreta de todas: se o notebook do dev for parar numa perícia, o que tem dentro dele?

E logo em seguida vem a irmã dela, que é a pergunta do auditor: como eu provo daqui a seis meses o que foi feito?

Texto puro no disco do dev

O Claude Code guarda transcrições de sessão localmente, em texto puro, em ~/.claude/projects/, por 30 dias por padrão, e esse período é ajustável pela configuração cleanupPeriodDays

Isso é bom e ruim ao mesmo tempo, e é honesto dizer os dois

Bom porque você sabe onde está e consegue encurtar o prazo

Ruim porque conversa com trecho de código sensível fica legível no disco, e a política de disco criptografado da empresa passa a fazer parte da aprovação da ferramenta

No OpenCode o que a documentação consultada aponta na pasta do usuário é credencial: chaves de API de provedor em ~/.local/share/opencode/auth.json e tokens de MCP em ~/.local/share/opencode/mcp-auth.json, em arquivos separados

Dois arquivos, dois escopos de segredo, e os dois entram na conversa sobre o que acontece quando um notebook some

Como levar o uso pro seu observability

Esse ponto costuma decidir reunião de plataforma

O Claude Code exporta telemetria por OpenTelemetry pro coletor da própria empresa: métricas pelo protocolo de métricas e eventos pelo protocolo de logs

CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=<endereço do seu coletor>

Do lado do audit log, a coisa é de plano: os audit logs da Claude são exclusivos de organizações Enterprise, e a exportação fica em Organization settings > Data and Privacy > Export logs, restrita a Organization Owners e Primary Owners

Tem também a Compliance API, que passou a cobrir o Claude Code (via CLI e Claude Desktop) além dos chats, em beta pra clientes Claude Enterprise, com eventos de audit log

Pro OpenCode eu não achei documentação oficial de audit log nativo ou integração com SIEM, então aqui eu prefiro não afirmar nada: essa é pergunta pra fazer direto no contato comercial do Enterprise deles

O trunfo do OpenCode: você pode ler o agente

O OpenCode é distribuído sob licença MIT, o que significa que a sua empresa pode ler e modificar o código-fonte do agente

Pra time de segurança que trabalha com análise de terceiros, isso vale muito, porque a resposta pra "o que exatamente essa binária faz com meus arquivos?" deixa de ser confiança e vira leitura

O repositório oficial hoje é o github.com/anomalyco/opencode, que antes ficava em sst/opencode, mudança que veio depois de a empresa passar a usar publicamente o nome Anomaly

E quem mantém é a Anomaly, a mesma equipe por trás do framework SST

Anota esse detalhe do endereço, porque link antigo em documento de aprovação interna gera aquela confusão chata de "esse repo é o mesmo projeto?"

O que a prática mostra ao rodar o OpenCode no dia a dia

Agora sai da documentação e vai pro terminal, porque tem coisa que só aparece quando você roda

No vídeo eu instalo o OpenCode ao vivo, com um comando só, e ele abre direto na pasta do projeto pelo terminal

O primeiro comando que eu dei foi o mais bobo possível de propósito: pedi pra ferramenta dizer em que pasta estava e quais arquivos existiam ali

Parece besteira, mas é o teste que a segurança entende: o agente enxerga o diretório onde você abriu ele, e isso é a primeira linha do escopo que vocês vão definir na reunião

Sobre credencial, eu preferi conectar a minha assinatura que já existia em vez de pagar por API, e o fluxo abriu um link no navegador e voltou pro terminal

Traduzindo pra pauta interna: se o dev conecta assinatura pessoal, a credencial que autoriza a chamada não é da empresa, e é aí que entra a conversa de enabled_providers e de gateway interno

Tem um ponto que eu levantei no vídeo e que vale repetir aqui em negrito mental: nos modelos gratuitos oferecidos dentro da ferramenta, é bem provável que prompts e resultados sejam compartilhados com quem oferece o modelo

Eu recomendei ler os termos antes de sair usando, e a lógica é simples: eles são um bom caminho pra testar sem gastar, mas a contrapartida é o dado de teste que a empresa do modelo ganha

Pra brincar em projeto pessoal, ótimo

Pra repositório da empresa, é exatamente o tipo de coisa que vira incidente

Outro detalhe que eu vi na hora: eu tinha desinstalado a ferramenta antes de gravar, pra instalar junto com o público, e mesmo assim ela reabriu com um modelo já selecionado

Ou seja, configuração ficou salva em algum canto da máquina, e isso conversa direto com os arquivos de config e de credencial que a gente listou lá em cima

Eu também mostrei que dá pra apontar a ferramenta pra um modelo rodando localmente, com a ressalva sincera de que isso pede um computador bem mais parrudo (PC da Nasa, digamos assim haha)

E o esforço de raciocínio do modelo é escolhido na conexão e pode ser trocado depois, lembrando que quanto maior o esforço, mais token consome

Última coisa, e essa é hábito mais do que dica: a documentação oficial é a fonte fiel de informação, acima da opinião de qualquer usuário, inclusive a minha

Leve os links de doc pra reunião, não o print de um post no LinkedIn

Qual escolher pelo perfil da sua empresa

Não existe resposta única aqui, existe perfil de empresa

Empresa regulada que exige certificação e BAA

Se a diligência de fornecedor pede papel antes de qualquer POC, o Claude Code chega mais pronto

A Anthropic mantém ISO 27001:2022, ISO/IEC 42001:2023, SOC 2 Tipo I e Tipo II, além de configuração HIPAA-ready com BAA disponível

Do lado do OpenCode eu não consegui confirmar em fonte oficial uma lista equivalente de certificações ou de contratos formais, então nesse cenário o atrito tende a ser menor com o Claude Code

O controle que sustenta a decisão: certificação verificável mais a possibilidade de ZDR pra contas qualificadas do Claude for Enterprise

Organização que precisa impor política sem depender do dev

Se a exigência é "a regra não pode ser desligada por quem usa", o Claude Code responde melhor

Managed policy settings distribuídos pelo admin cobrem permissões de ferramenta, acesso a arquivos e servidores MCP, têm a maior precedência e não podem ser sobrescritos pelos demais escopos

E o deny feito em qualquer nível não é liberado por outro nível, nem por argumento de linha de comando

No OpenCode a política padrão mora em arquivo do usuário e em arquivo do projeto, e a imposição central aparece na oferta Enterprise com SSO e gateway interno forçado

Time que precisa auditar o próprio agente ou rodar modelo em endpoint próprio

Aqui o OpenCode ganha sem discussão

Licença MIT significa ler e modificar o agente, e a ferramenta suporta apontar pra modelos self-hosted em endpoint próprio, além dos provedores comerciais

Se a sua política diz que nenhum código sai da rede, essa combinação é o caminho mais curto

O controle que sustenta a decisão: enabled_providers como allowlist, com provedor desabilitado que não carrega nem com variável de ambiente ou chave configurada

Startup com repositório sensível e sem equipe de plataforma

Sem gente pra manter gateway, coletor e política central, o que importa é o que dá pra travar em uma tarde

Dos dois lados existe um caminho: no OpenCode, "share": "disabled" no opencode.json da raiz do projeto versionado no Git, mais o bloco permission com curinga global

No Claude Code, encurtar cleanupPeriodDays e combinar com o time que ninguém usa /feedback nem o polegar em sessão com código sensível

O atrito aqui não é a ferramenta, é a disciplina: escolha a que o seu time consegue configurar de verdade

Veredito: qual é mais fácil de aprovar com o time de segurança

Sem ficar em cima do muro

Na média das empresas, a ferramenta mais fácil de aprovar com o time de segurança é o Claude Code

O motivo não é ser melhor, é ser mais fácil de avaliar: certificação verificável, managed settings com precedência máxima, audit log de Enterprise, Compliance API cobrindo Claude Code em beta e telemetria por OpenTelemetry pro seu coletor formam um pacote que o comitê já sabe ler

A exceção é clara, e ela vira a regra em uma parte dos casos

Se a sua política exige inspeção do agente ou soberania do modelo, o OpenCode é o que passa mais fácil: MIT deixa você ler o código-fonte, e o suporte a modelo self-hosted em endpoint próprio mais a allowlist de provedores resolvem a exigência de "nada sai da nossa rede" sem depender de contrato

Agora os pontos que mais travam comitê, um de cada lado

No Claude Code, o problema quase nunca é a empresa: é a conta de consumidor

Free, Pro e Max com a configuração de melhoria de modelo ligada abrangem o Claude Code usado nessas contas, com retenção de 5 anos, e o feedback de polegar retém a conversa relacionada por até 5 anos, podendo ser usada pra treinar modelos

No OpenCode, o problema é onde a política mora: config na raiz do projeto tem a maior precedência entre os arquivos padrão, e o share, apesar de vir em manual, manda a conversa e os dados associados pro serviço hospedado em opencode.ai quando acionado

E tem o que eu NÃO consigo afirmar com fato na mão, e prefiro dizer isso do que inventar conforto

• não encontrei página oficial de certificações, DPA ou BAA do OpenCode ou da Anomaly
• não encontrei documentação oficial de audit log nativo ou integração com SIEM no OpenCode Enterprise
• preço não entra: a página do OpenCode Enterprise pede contato comercial, e eu não tenho valor verificável dos assentos premium de Claude Team e Enterprise
• se o Zero Data Retention do Claude Code tem custo adicional ou exigência de volume, também não tenho fonte

Então a resposta prática pra "Claude Code ou OpenCode" é essa: se o seu gargalo é papel e política central, a aprovação sai mais rápido com o Claude Code

Se o seu gargalo é "não confiamos em binário fechado" ou "o modelo tem que rodar onde a gente manda", o OpenCode passa mais fácil, com o custo de você mesmo montar a parte de governança

Conclusão

Recapitulando o roteiro que você leva pra reunião

As três perguntas: pra onde vai o código, quem controla a credencial e as permissões, e o que fica na máquina do dev

Os controles que eu exigiria por escrito antes de qualquer piloto, do lado que você escolher

1. desligar ou proibir o compartilhamento de conversa (share em disabled no OpenCode, política de /feedback e polegar no Claude Code)
2. proibir conta de consumidor com melhoria de modelo ligada, se o caminho for Claude Code
3. definir o caminho da chamada e conseguir PROVAR ele (/status mostrando provider, base URL e proxy, ou allowlist de provedores no OpenCode)
4. fixar versão de modelo por variável de ambiente quando o deploy for por provedor de nuvem
5. definir a retenção local (cleanupPeriodDays) e quem tem acesso ao disco do dev
6. combinar quem exporta o audit log, e por onde (Organization settings > Data and Privacy > Export logs é restrito a Organization Owners e Primary Owners)

E o escopo do teste: repositório de baixo risco, sem segredo, sem dado de cliente, com um punhado de gente

Se você quiser o desenho desse teste com calma, eu já escrevi sobre como rodar um piloto com um time pequeno antes de contratar pra empresa toda

Dá uma olhada no vídeo aí de cima pra ver o OpenCode rodando de verdade no terminal, porque metade das dúvidas da segurança some quando a pessoa vê a tela

até o próximo post! =)