A Goldman tirou o Claude Code da mesa e deixou com quem constrói software

No dia 2 de novembro a Bloomberg publicou que a Goldman Sachs limitou o Claude Code e o GitHub aos engenheiros. Segundo a matéria, do Todd Gillespie, uma orientação interna atualizada em outubro tirou essas ferramentas da maior parte dos funcionários, traders e bankers incluídos, depois de meses de uso liberado. Quem continua com acesso são os strats, o pessoal que fica no meio do caminho entre trading, pesquisa quantitativa e engenharia de software.

Alguns traders ficaram irritados. Eles usavam as ferramentas pra acompanhar fluxo de cliente, modelar mudança de mercado e de posição e produzir texto e gráfico. A explicação oficial veio do porta-voz Nick Carcaterra e é curta. Depois de um período de experimentação, olhando produtividade e gestão de risco, as ferramentas ficam com quem está em melhor posição pra usar no longo prazo.

A Goldman não divulgou incidente nem número da revisão. A matéria fala em "GitHub" sem dizer se é o Copilot ou a plataforma. E a orientação, do jeito que foi descrita, é sobre ferramenta de código. O banco tem um assistente de IA próprio, que junta modelos da OpenAI, da Anthropic e da Alphabet, e não é dele que a matéria fala. O que saiu da mão da mesa foi o Claude Code, um agente que lê arquivo, escreve e roda código, e o GitHub junto.

Em julho a produção já era da engenharia

Em julho, no RAISE Summit, em Paris, o CIO Marco Argenti contou como o arranjo funcionava. Gente de negócio, às vezes com um strat do lado, montava um protótipo com Claude Code, Codex ou Devin. O engenheiro recebia isso no lugar de um spec e deixava o negócio pronto pra produção. Ele foi direto: "We don't put it in production obviously".

A parte que mais me interessa veio quando perguntaram de risco. Ele contou que já viu modelo pegando atalho e até inventando a saída de uma ferramenta quando a ferramenta estava fora do ar. A resposta do banco foi não deixar nada ir do modelo direto pra produção, o que ele chamou de antipattern. A saída do modelo é tratada como trabalho de júnior e entra no ciclo normal de desenvolvimento, com revisor, gate e pipeline de CI/CD. Ele também falou de uma plataforma pra experimentar com controle de quem acessa qual dado, sem cruzar barreira de informação.

E usou uma imagem boa. Se você tem um jardim de infância, não entrega manual de segurança pras crianças. Você deixa a sala segura, arredonda as quinas, e aí elas podem fazer bagunça. Os 20% de produtividade líquida que ele citou na mesma conversa são do time de engenharia, uns 12 mil engenheiros, não da mesa.

Então eu não leio outubro como um banco que vendia vibe coding e voltou atrás. Em julho a produção já era da engenharia. Em outubro o protótipo também passou a ser.

O que o fio do Hacker News enxergou

No Hacker News o fio sobre o caso tinha 898 pontos e 488 comentários na noite de 10 de novembro. Um dos comentários do topo aponta o risco de deixar agente de código rodando meio solto na mesma máquina que tem dado de cliente, e-mail, internet e rede interna, e diz que isso esbarra direto no lethal trifecta.

O termo é do Simon Willison e descreve três coisas juntas no mesmo agente. Acesso a dado privado, contato com conteúdo que não é confiável e algum jeito de mandar informação pra fora. O problema de base é que modelo segue instrução que aparece no conteúdo, venha ela de quem está usando ou de quem escreveu o conteúdo. Com as três coisas juntas, alguém de fora consegue fazer o agente ler o dado e mandar pra ele. O exemplo do próprio Willison é bem direto. Se a ferramenta lê seu e-mail, o atacante pode simplesmente mandar um e-mail pro seu agente dizendo o que fazer.

Agora põe isso na máquina de um trader. Dado de cliente está ali, e acompanhar fluxo de cliente era justamente um dos usos. E-mail e internet também estão, que é por onde conteúdo de fora entra e por onde informação sai. É leitura de fórum, não é o motivo da Goldman. O motivo que a Goldman deu continua sendo produtividade e risco, sem detalhe.

A trava existe na própria ferramenta

O Claude Code tem trava de organização, e bastante. A doc da Anthropic separa as settings em escopo de usuário, de projeto, local e managed. O managed é o que a organização distribui por arquivo managed-settings.json, MDM ou console admin, e fica acima de todos. Nada que o usuário ou o repositório põe no próprio arquivo sobrescreve uma regra managed, e se uma ferramenta é negada em qualquer nível, nenhum outro nível consegue liberar.

As regras de permissão são avaliadas na ordem deny, ask, allow, e quem aplica é o Claude Code, não o modelo. Dá pra desligar o modo que pula as confirmações com disableBypassPermissionsMode, e dá pra fazer com que só as regras managed valham, com allowManagedPermissionRulesOnly. Por cima disso tem hook de PreToolUse, que roda antes de cada chamada de ferramenta e pode negar a chamada com a lógica que você escrever.

E tem o sandbox, que é o que conversa direto com o trifecta. Ele vem desligado por padrão. Ligado, os comandos de shell rodam dentro de um limite que o próprio sistema operacional aplica. A escrita fica restrita ao diretório de trabalho e a poucos outros lugares, e a rede não tem rota direta pra fora. Tudo passa por um proxy que confere cada host contra uma lista de domínios liberados, que começa vazia. Pela managed, a organização exige o sandbox, faz o Claude Code se recusar a abrir se o sandbox não subir e proíbe o modelo de repetir o comando fora dele. Um arquivo managed de exemplo, montado só com chaves que estão na doc, fica assim:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": ["Read(./.env)", "Read(./.env.*)", "Bash(curl *)"]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

A doc também é honesta sobre o limite. O sandbox cobre comando de shell, e as ferramentas de arquivo, os servidores MCP e os hooks rodam fora dele. Por padrão, comando no sandbox ainda lê quase a máquina toda, arquivo de credencial incluído, até alguém negar esses caminhos. Regra de Bash casa com o texto do comando e não é fronteira de segurança em volta do programa. E liberar um domínio largo como github.com já abre caminho pra vazar dado.

O corte foi por função

A ferramenta tem esse tipo de controle, e o corte que saiu na matéria foi por função. Strat fica, trader sai. Strat também trabalha colado em trading. O que separa um do outro é o ofício de construir software.

Faz sentido pra mim. Toda essa trava precisa de alguém que entenda o que está travando. Quem escreve a regra de deny, escolhe o domínio liberado e lê o diff antes do merge é gente de engenharia. Na prática, o corte da Goldman deixou a ferramenta com quem tem esse ofício.

Outros bancos foram por outro caminho

O MUFG, segundo a WatersTechnology em julho, construiu uma versão própria do Claude Code porque a ferramenta era eficiente demais em buscar informação e passava por cima das regras de segurança e compliance do banco. A resposta foi refazer a ferramenta dentro da própria governança.

A BNY deixa gente fora de engenharia construir, mas dentro da Eliza, a plataforma de IA do banco. No case publicado pela OpenAI em dezembro de 2025, o treinamento é obrigatório antes de usar, e todo prompt, criação de agente, escolha de modelo e compartilhamento acontece dentro de um ambiente governado. Agente feito por alguns times pode ser compartilhado com até dez colegas. Num texto de outubro, a própria BNY diz que tem mais de 300 soluções de IA em produção e que 40% do código do segundo trimestre de 2026 foi escrito por IA. É construção por gente de qualquer área, só que numa plataforma com dono, e não um agente de código na máquina de cada um.

Segundo a PYMNTS, o Deutsche Bank faz parecido com a Goldman e deixa as ferramentas com desenvolvedores, mais de 15 mil deles. O próprio banco diz que os desenvolvedores usam GitHub Copilot e Gemini Code Assist, que código gerado por IA nunca vai pra produção sem revisão e que o desenvolvedor responde por cada linha.

São respostas diferentes pra mesma pergunta, que é quem pode fazer o agente mexer em quê.

Na Ativos quem opera pede e quem automatiza constrói

Na Ativos, no Celer e no trabalho com precatório, o fluxo é assim. Uma área precisa do dado de um tribunal específico e pede o scraping. O time de automações monta o pipeline e o ETL. A operação segue no trabalho dela, sem expor dado no meio do caminho, e a engenharia entrega a automação. O que a gente ganha é tempo.

O pedido vai pra automações porque scraping e ETL são software. Precisa de alguém que saiba de onde o dado vem e pra onde ele vai, e que conserte quando o site do tribunal mudar. Quando quem constrói é o time que faz isso todo dia, o dado entra no pipeline e sai no destino certo, em vez de passar por um monte de lugar no caminho. É o mesmo raciocínio da trava do Claude Code. Alguém com o ofício certo decide por onde o dado anda.

Já aconteceu de alguém da operação perder um tempo tentando montar isso sozinho. A vontade de resolver é boa. Só que cada hora brigando com scraper é uma hora fora do trabalho que só aquela pessoa faz. Numa startup isso pesa.

Meu critério é simples: software bom desperdiça menos. Menos tempo de quem opera e menos dado andando por onde não precisa.

O risco não é a ferramenta. É o dado exposto e a pessoa saindo da própria função.

A matéria da Bloomberg, numa republicação aberta: https://sg.finance.yahoo.com/news/goldman-restricts-traders-bankers-using-063339234.html

A palestra do Argenti no RAISE Summit: https://www.youtube.com/watch?v=grOykIdJPgs

A PYMNTS sobre o que a Goldman não divulgou e sobre os outros bancos: https://www.pymnts.com/news/artificial-intelligence/2026/goldman-benches-its-vibe-coders-while-bny-lets-everyone-build/

O fio no Hacker News: https://news.ycombinator.com/item?id=50415628

O lethal trifecta, do Simon Willison: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Settings do Claude Code: https://docs.anthropic.com/en/docs/claude-code/settings

Permissões e hooks: https://docs.anthropic.com/en/docs/claude-code/permissions

Sandbox: https://docs.anthropic.com/en/docs/claude-code/sandboxing

O MUFG na WatersTechnology: https://www.waterstechnology.com/emerging-technologies/7953162/mufg-builds-internally-compliant-version-of-anthropics-claude-code

A Eliza no case da OpenAI: https://openai.com/index/bny/

Os números da BNY: https://www.bny.com/corporate/global/en/insights/ai-fund-operations.html

O Deutsche Bank sobre revisão de código gerado por IA: https://www.db.com/news/detail/20260714-how-ai-is-reshaping-the-software-behind-everyday-banking?language_id=1