noticias

Claude escreveu todos os controles de segurança e esqueceu de verificar quem estava entrando

**Uma aplicação financeira criada com forte participação da IA da Anthropic possuía tokens temporários, expiração, limitação de requisições, registros de auditoria e detecção de atividade suspeita. Ainda assim, entregava acesso a dados sensíveis sem confirmar se o solicitante era realmente o dono do cadastro. O caso mostra por que código com aparência profissional pode esconder decisões arquiteturais perigosamente erradas.**

Uma empresa do setor financeiro, responsável pela administração de bilhões de dólares em ativos de clientes, decidiu acelerar o desenvolvimento de seu sistema de cadastro com ajuda do Claude. A aplicação processava documentos oficiais, informações de verificação de identidade, dados financeiros, meios de pagamento e números de seguridade social dos Estados Unidos. Não era um protótipo montado durante um fim de semana nem uma página promocional descartável. Tratava-se de software conectado a informações reguladas e capazes de produzir prejuízos concretos caso fossem expostas.

Durante um teste de invasão autorizado, a empresa de segurança Sygnia encontrou uma falha crítica no processo usado para permitir que candidatos retomassem cadastros incompletos. O sistema precisava resolver uma situação comum: alguém começa a preencher uma proposta, interrompe o processo e retorna posteriormente, antes mesmo de possuir uma conta tradicional com usuário e senha. Para oferecer essa conveniência, a aplicação criava um modelo de acesso temporário.

O problema não estava na ausência de mecanismos de segurança. Havia tokens assinados, validade limitada, registros de auditoria, controle da frequência das requisições e monitoramento de comportamento suspeito. Em uma leitura superficial, a arquitetura parecia cuidadosa. O erro estava em uma pergunta anterior a todos esses controles: o que uma pessoa deveria provar antes de receber o token?

A aplicação aceitava a posse do identificador global do candidato, conhecido como GUID, como contexto suficiente para emitir ou restaurar o acesso associado àquele cadastro. Um GUID pode localizar um registro específico dentro do sistema, mas não demonstra que o solicitante controla a identidade, a sessão, o dispositivo ou algum canal previamente verificado daquele usuário. O código sabia encontrar a ficha correta. Ele não sabia confirmar quem estava pedindo para abri-la.

Essa diferença permitia que o identificador deixasse de funcionar apenas como referência interna e passasse a atuar como uma espécie de senha informal. Quem tivesse acesso ao GUID de outro candidato poderia receber um token correspondente àquele cadastro sem comprovar que era seu proprietário. A partir daí, informações como nome, contato, andamento da proposta, documentos de identidade, dados financeiros, detalhes de pagamento e informações de um eventual segundo candidato poderiam ficar disponíveis fora do escopo autorizado.

A Sygnia não informou o nome da instituição, não publicou o código completo e não apresentou evidências de que criminosos tenham explorado a falha antes do teste. O caso deve ser tratado como uma descoberta em avaliação de segurança, não como confirmação de um vazamento consumado. Ainda assim, a arquitetura descrita é plausível, tecnicamente reconhecível e pertence a uma das famílias mais recorrentes de vulnerabilidades em aplicações modernas: a quebra do controle de acesso.

Um cadeado sofisticado instalado na porta errada

O aspecto mais revelador do caso é que o Claude aparentemente não ignorou a segurança. Ele produziu a linguagem, os componentes e os comportamentos normalmente associados a um sistema protegido. Os tokens expiravam. As requisições podiam ser limitadas. As ações eram registradas. Atividades estranhas poderiam gerar alertas. Havia uma coleção inteira de controles tecnicamente defensáveis.

Todos eles operavam depois que a decisão mais importante já havia sido tomada de forma errada.

Um token com validade de cinco minutos continua perigoso quando é entregue à pessoa errada. Uma assinatura criptográfica garante que o token foi emitido pelo servidor, mas não confirma que o servidor deveria tê-lo emitido para aquele solicitante. O registro de auditoria poderá ajudar a reconstruir o incidente posteriormente, porém não impede a exposição inicial. A limitação de requisições reduz a velocidade de uma tentativa de abuso, mas não transforma um identificador em prova de identidade.

O sistema protegeu cuidadosamente o comportamento do token sem proteger sua concessão. É como instalar fechadura biométrica, alarme, câmera e sensor de movimento em uma porta cuja chave é distribuída a qualquer pessoa que saiba o número do apartamento. Cada componente funciona. O conjunto continua errado.

Essa categoria de falha costuma ser difícil de localizar porque não depende necessariamente de uma função obviamente insegura, de uma biblioteca desatualizada ou de uma linha de código isolada. O problema nasce da lógica do negócio e da interpretação das relações de confiança. O software precisa entender que “este identificador aponta para o cadastro de alguém” e “esta pessoa demonstrou ter direito de acessar esse cadastro” são afirmações completamente diferentes.

Ferramentas tradicionais de análise estática procuram padrões conhecidos, fluxos perigosos de dados, funções vulneráveis, segredos expostos e dependências problemáticas. Elas são fundamentais, mas podem não compreender por que determinado identificador jamais deveria autorizar uma ação. O código pode passar por verificações automáticas, testes funcionais e revisões superficiais porque faz exatamente aquilo que foi programado para fazer. A vulnerabilidade está no fato de que o comportamento programado nunca deveria ter sido aceito.

A IA não inventou essa falha, mas pode reproduzi-la em escala industrial

Seria confortável concluir que o Claude criou uma vulnerabilidade estranha e exclusiva de sistemas generativos. Não foi isso que aconteceu. Desenvolvedores humanos produzem há décadas falhas nas quais um número, uma chave de registro ou um parâmetro controlado pelo usuário permite acessar dados de outra pessoa. A OWASP reúne esse tipo de problema sob categorias como referência direta insegura a objetos e autorização quebrada em nível de objeto.

A novidade está na velocidade e na aparência de completude.

Um modelo de linguagem consegue gerar rapidamente rotas, serviços de token, middlewares, esquemas de banco, testes, integrações e documentação. Ele conhece os nomes dos componentes usados em arquiteturas seguras e consegue reproduzir padrões encontrados em milhares de projetos. O resultado chega com estrutura suficiente para transmitir confiança, especialmente quando compila, executa os testes básicos e resolve a necessidade comercial que motivou sua criação.

Essa competência formal pode mascarar uma fragilidade semântica. O modelo conhece o formato de uma solução segura, mas não possui acesso automático ao modelo de risco daquela instituição. Ele não sabe, por conta própria, onde o GUID aparece, quem consegue visualizá-lo, se ele passa por URLs, mensagens, registros, integrações externas ou ferramentas de atendimento. Também não sabe quais ações a empresa considera críticas, quais dados estão sujeitos a regras específicas e quais evidências devem ser exigidas antes de restaurar uma sessão.

A IA preenche lacunas usando padrões prováveis. Em funções comuns, isso costuma ser produtivo. Em decisões de segurança, uma suposição plausível pode ser suficiente para comprometer toda a arquitetura.

O perigo não é que o código gerado seja necessariamente pior que o código humano. O problema é que uma única pessoa agora consegue produzir, modificar e publicar uma quantidade de software que antes exigiria uma equipe. Se a capacidade de revisão não crescer na mesma proporção, as organizações passarão a criar vulnerabilidades em uma velocidade maior do que conseguem entendê-las.

A produtividade chega imediatamente. A dívida de segurança aparece depois.

O “vibe coding” muda quem consegue criar software, não as obrigações de quem o publica

O caso inevitavelmente será usado como munição contra o chamado vibe coding, expressão adotada para descrever o desenvolvimento em que o usuário apresenta objetivos à IA, recebe grandes blocos de código e continua iterando sem compreender integralmente cada decisão implementada. A crítica tem fundamento quando esse método é levado diretamente para sistemas que processam dinheiro, identidade ou dados pessoais.

Não é razoável tratar uma aplicação financeira como uma sequência de prompts que termina quando a interface começa a funcionar.

Ao mesmo tempo, culpar apenas o modelo seria uma simplificação conveniente para a organização que aprovou, integrou e disponibilizou o software. O Claude não definiu sozinho as regras comerciais, não escolheu os dados processados e não decidiu que a aplicação estava pronta para lidar com clientes. Alguém solicitou a implementação, aceitou seus pressupostos, executou os testes disponíveis e permitiu que o resultado avançasse no ciclo de desenvolvimento.

Uma IA pode sugerir uma arquitetura inadequada. A responsabilidade de aceitar essa arquitetura continua pertencendo à empresa e aos profissionais que controlam o produto.

Esse ponto será cada vez mais importante em contratos, auditorias e processos regulatórios. Dizer que “a IA escreveu” não elimina a obrigação de identificar quem aprovou a mudança, quais testes foram executados, quais requisitos de segurança foram definidos e por que determinada decisão entrou em produção. Modelos não assinam pull requests, não respondem perante autoridades de proteção de dados e não indenizam clientes prejudicados.

A rastreabilidade do código gerado também tende a se tornar parte da governança. Empresas precisarão registrar quando uma IA produziu ou modificou trechos relevantes, qual ferramenta foi utilizada, quais instruções foram fornecidas e quem revisou o resultado. Isso não deve servir para transformar cada linha em um processo burocrático, mas para impedir que sistemas críticos sejam construídos por uma cadeia de decisões que ninguém consegue reconstruir depois.

Segurança do agente não é segurança do software produzido

A Anthropic mantém proteções para reduzir os riscos de uso do Claude Code no computador do desenvolvedor. O agente opera com permissões controladas, solicita autorização para determinadas ações e pode ser limitado por configurações, ambientes isolados e políticas empresariais. Esses mecanismos são importantes porque um agente capaz de editar arquivos e executar comandos possui acesso muito mais sensível que um chatbot comum.

Mas existe uma diferença fundamental entre proteger o ambiente onde o código é criado e garantir a segurança do código criado.

Um agente pode respeitar perfeitamente todas as permissões locais, não acessar arquivos indevidos, não revelar segredos e ainda escrever uma aplicação com controle de acesso defeituoso. O sistema que protege o terminal do desenvolvedor não conhece todas as regras do banco, as obrigações regulatórias da instituição ou o significado comercial de cada identificador.

A confusão entre essas duas camadas pode gerar uma falsa sensação de segurança. Certificações, ambientes corporativos e controles de execução mostram que o fornecedor tenta proteger sua própria ferramenta. Eles não funcionam como certificação automática de tudo o que o modelo produz.

Uma fábrica pode operar de maneira segura e ainda fabricar uma peça com desenho incorreto. O controle da fábrica não substitui a validação do produto.

A mesma IA que ajudou a criar a falha também ajudou a encontrá-la

O caso possui uma ironia técnica importante. Segundo a Sygnia, um modelo de linguagem foi usado durante a revisão do código e ajudou a identificar a falha de confiança no processo de emissão dos tokens. A vulnerabilidade produzida em uma aplicação acelerada por IA foi localizada com auxílio de outra análise baseada em IA.

Isso não absolve o primeiro modelo nem transforma o segundo em auditor infalível. Mostra que a tecnologia amplia capacidades dos dois lados.

Um sistema generativo pode examinar rapidamente uma base desconhecida, relacionar rotas, serviços e regras, levantar perguntas sobre propriedade dos dados e apontar caminhos que merecem investigação humana. Tarefas iniciais que consumiam horas de leitura podem ser comprimidas para minutos. O especialista continua necessário para validar o achado, testar seu impacto e compreender o ambiente, mas deixa de gastar parte do tempo apenas reconstruindo a arquitetura.

A mesma vantagem está disponível para atacantes. Quem obtiver acesso a um repositório exposto, documentação interna ou código vazado poderá pedir que um modelo procure decisões de confiança frágeis, caminhos alternativos de autenticação e diferenças entre endpoints. Não será necessário descobrir um ataque completamente novo. A IA pode ajudar a combinar erros conhecidos em uma velocidade antes reservada a grupos mais estruturados.

A democratização do desenvolvimento está sendo acompanhada pela democratização da análise de vulnerabilidades. Primeiro, ficou mais barato produzir software. Agora também está ficando mais barato procurar onde ele quebra.

Essa simetria altera a economia da segurança. Uma empresa não pode pressupor que uma falha obscura permanecerá escondida porque exige muito tempo de leitura manual. O custo de compreender sistemas alheios está diminuindo, e a janela entre a exposição de um código e a identificação de seus pontos fracos tende a encolher.

O gargalo deixou de ser escrever e passou a ser compreender

Durante décadas, grande parte do custo do desenvolvimento estava na produção do código. Projetos eram limitados pela quantidade de profissionais disponíveis para transformar requisitos em sistemas funcionais. Agentes de programação começam a deslocar esse limite. Uma pequena equipe consegue criar mais telas, integrações e serviços em menos tempo.

A capacidade de compreensão, entretanto, não acompanha automaticamente essa aceleração.

Revisar uma arquitetura exige conhecer o negócio, os dados, os usuários, as ameaças e os efeitos de cada decisão. Quanto mais código é produzido, maior é a quantidade de comportamento que precisa ser validada. Se a organização mede sucesso apenas pela velocidade de entrega, o agente parecerá extremamente produtivo. Se incluir retrabalho, incidentes, auditorias e exposição regulatória, a conta pode mudar bastante.

Esse é um custo oculto do desenvolvimento assistido por IA. O código pode ficar barato enquanto a validação se torna o componente mais caro do projeto.

Empresas que reduzirem equipes experientes acreditando que os modelos eliminaram a necessidade de conhecimento técnico poderão descobrir que perderam justamente as pessoas capazes de questionar os pressupostos da máquina. Um profissional menos experiente consegue pedir a criação de um sistema complexo. Isso não significa que possua repertório para reconhecer quando a solução está protegendo a coisa errada.

Existe ainda um efeito de longo prazo sobre a formação dos desenvolvedores. Quem aprende apenas a solicitar e aceitar implementações pode não desenvolver a intuição construída ao enfrentar erros, modelar estados e compreender protocolos. A produtividade imediata corre o risco de consumir a capacidade futura de revisão.

A indústria poderá terminar com mais código e menos pessoas capazes de explicar por que ele deveria ser confiável.

A solução não é proibir, mas tornar a IA visível

Banir assistentes de programação parece uma resposta simples, porém tende a empurrar seu uso para contas pessoais, ferramentas não monitoradas e processos informais. Funcionários continuarão recorrendo à tecnologia porque ela economiza tempo. A organização apenas perderá visibilidade sobre quais dados foram enviados e quais trechos foram gerados.

Uma abordagem mais realista começa por reconhecer onde a IA está sendo usada.

Alterações que envolvam autenticação, autorização, recuperação de sessão, pagamentos, documentos, exportação de dados, funções administrativas e informações reguladas precisam receber tratamento diferente de uma mudança estética. Não importa se o código foi escrito por um modelo, por um funcionário ou por ambos. Quanto maior o impacto possível, mais rigorosa deve ser a revisão.

Também será necessário transformar requisitos de segurança em instruções verificáveis. Pedir “um sistema de acesso temporário” é insuficiente. A especificação precisa declarar que identificadores não podem funcionar como segredo, que a emissão de tokens exige prova independente de controle, que cada token deve possuir escopo limitado e que os testes precisam demonstrar que um candidato não consegue receber acesso correspondente a outro.

O teste mais importante muitas vezes não é confirmar que o usuário correto consegue entrar. É provar que todos os usuários errados permanecem do lado de fora.

Modelos podem ajudar a escrever esses testes negativos, revisar fluxos e apontar inconsistências. A IA deve ser usada para questionar o próprio código que ajudou a produzir, preferencialmente por meio de contextos separados e critérios previamente definidos. Ainda assim, a decisão final precisa permanecer com profissionais responsáveis pelo risco.

Enviar bases completas, dados pessoais, credenciais ou propriedade intelectual a ferramentas não autorizadas cria outro problema de segurança enquanto se tenta resolver o primeiro. Ambientes empresariais controlados, remoção de informações sensíveis, registro das interações e validação humana não são detalhes administrativos. São parte da arquitetura.

A Sygnia também está vendendo uma resposta para o problema que apresentou

Há um elemento comercial que merece ser observado. A Sygnia divulgou o caso ao mesmo tempo em que anunciou uma linha de serviços voltada à avaliação e à governança de sistemas de inteligência artificial. Isso não invalida a descoberta, mas exige cautela ao interpretar a narrativa.

A empresa tem interesse em demonstrar que aplicações desenvolvidas com IA criam uma nova demanda por testes, consultoria e monitoramento. O relatório utiliza um caso real, porém anonimizado, com trechos e imagens sanitizados. Sem acesso ao código completo, à arquitetura ou ao relatório entregue ao cliente, pesquisadores externos não conseguem reproduzir integralmente a avaliação nem determinar quanto da falha foi sugerido pelo Claude, alterado por humanos ou condicionado por requisitos incompletos.

A formulação mais precisa não é “Claude criou sozinho uma vulnerabilidade crítica”. Partes relevantes da aplicação foram construídas ou aceleradas com o modelo, e o processo resultou em uma decisão insegura que a organização não identificou antes do teste. O grau exato de autoria entre IA e desenvolvedores não foi revelado.

Essa limitação importa porque o debate público tende a transformar casos complexos em disputas simplistas. De um lado, empresas de IA tratam falhas como problemas de uso inadequado. Do outro, fornecedores de segurança podem apresentar qualquer defeito em código assistido como evidência de uma categoria inteiramente nova de ameaça.

A realidade é menos confortável para todos. Modelos reproduzem padrões inseguros, inventam pressupostos e produzem soluções convincentes sem entender completamente o ambiente. Equipes humanas fornecem requisitos incompletos, aceitam resultados sem revisão e colocam sistemas em circulação. O risco nasce da combinação.

O problema não é a IA escrever código; é ninguém assumir a arquitetura

O caso do cadastro financeiro não demonstra que assistentes de programação devem ser abandonados. Ele mostra que segurança não pode ser obtida pela soma de palavras familiares, bibliotecas conhecidas e controles colocados ao redor de uma decisão errada.

Claude escreveu a expiração. Escreveu o token. Escreveu o registro. Escreveu a limitação. A aplicação provavelmente parecia organizada, moderna e defensável em uma apresentação. O ponto ausente era mais básico: antes de entregar acesso, quem deveria ser considerado dono daquela identidade?

Essa pergunta não pertence exclusivamente ao código. Ela envolve produto, segurança, jurídico, privacidade e operação. Quando nenhum desses grupos assume a decisão, o modelo preenche o vazio. Ele produz algo provável, funcional e, às vezes, perigosamente equivocado.

O futuro mais plausível não é composto por sistemas escritos apenas por humanos nem por aplicações inteiramente autônomas. Será um ambiente no qual modelos produzirão grande parte da implementação, outros modelos revisarão o resultado e profissionais precisarão arbitrar as contradições. A vantagem competitiva não estará apenas em gerar mais código, mas em manter uma organização capaz de compreender o que foi gerado.

A falha descoberta pela Sygnia não é impressionante por sua complexidade. Ela assusta justamente porque é simples. O sistema possuía quase tudo o que uma apresentação corporativa chamaria de segurança. Faltava apenas a decisão que dava sentido a todos os controles.

E essa continua sendo a parte que não pode ser terceirizada para o autocomplete mais sofisticado do mundo.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis