A OpenAI está trabalhando para corrigir uma falha no Codex que tem causado um volume excessivo de gravações em SSDs de usuários. O problema está ligado a uma implementação de logs locais baseada em SQLite, que passou a armazenar dados de diagnóstico em uma intensidade muito maior do que o previsto, gerando preocupação sobre desgaste prematuro de unidades de armazenamento. SSDs possuem vida útil limitada, normalmente medida em TBW, sigla para terabytes written, ou terabytes gravados. Esse indicador estima quanto uma unidade pode receber de dados ao longo de sua operação antes de apresentar maior risco de degradação, queda de desempenho ou falhas. O valor varia conforme modelo, capacidade e fabricante, mas gravações constantes e desnecessárias podem consumir rapidamente parte dessa margem. O alerta ganhou força após a abertura de um relatório de bug no repositório do agente de programação Codex. O título do issue já indicava a gravidade do comportamento observado: os logs de feedback em SQLite poderiam escrever cerca de 640 TB por ano e consumir rapidamente a resistência de SSDs. O desenvolvedor Rui Fan, integrante do comitê de gerenciamento do projeto Apache Flink, relatou que, após cerca de 21 dias de uptime, o SSD principal de sua máquina havia registrado aproximadamente 37 TB de dados gravados. Verificações em nível de processo e arquivo indicaram que os logs SQLite do Codex eram o principal responsável pela escrita contínua. Ao projetar esse ritmo para um ano, o volume chegaria a cerca de 640 TB. Em um SSD de 1 TB, isso representaria aproximadamente 640 gravações completas da unidade em 12 meses. Como alguns SSDs de consumo possuem garantia de resistência em torno de 600 TBW, esse comportamento poderia consumir praticamente toda a endurance coberta pela garantia em menos de um ano. O problema não significa necessariamente que todos os usuários sofrerão o mesmo impacto. A escala do desgaste depende de fatores como frequência de uso do Codex, modelo do SSD, capacidade da unidade, configuração do ambiente, tempo de atividade e volume real de logs gerados. Ainda assim, o caso expõe um risco operacional relevante em ferramentas de IA executadas localmente em máquinas de desenvolvimento. Outro desenvolvedor que participou da discussão afirmou que o próprio Codex analisou o uso de disco e estimou que o bug teria consumido US$ 38,64 em valor proporcional da vida útil de um SSD Samsung 990 NVMe de 2 TB. O mesmo usuário citou uma estimativa gerada pelo Codex segundo a qual a regressão poderia ter causado um consumo de endurance equivalente a alguns milhões de dólares entre usuários durante o período de março a junho. Essa estimativa parte de uma conta econômica simples: o custo por terabyte gravado é calculado com base no preço do SSD dividido pela resistência nominal em TBW. Assim, quanto mais dados são escritos sem necessidade, maior é a parcela proporcional da vida útil consumida. Em um exemplo citado no texto original, um SSD de 1 TB avaliado em US$ 200 e com resistência de 600 TBW teria custo estimado de US$ 0,333 por terabyte gravado. Nesse cenário, os 37 TB registrados por Rui Fan representariam cerca de US$ 12,33 em desgaste proporcional. Unidades maiores e mais caras, com ratings de TBW superiores, podem apresentar custo menor por terabyte escrito. Um SSD de 2 TB com resistência de 1.200 TBW, por exemplo, dilui melhor o impacto de cada gravação. Mesmo assim, o ponto central permanece: uma ferramenta de software não deveria gerar escrita contínua desnecessária a ponto de afetar a durabilidade de hardware dos usuários. A falha está relacionada a logs diagnósticos locais, não diretamente à telemetria enviada à OpenAI. Em dezembro de 2025, desenvolvedores do Codex anunciaram planos para adicionar telemetria por padrão ao Codex CLI, exceto onde a prática fosse proibida por lei. O caso atual, porém, envolve registros armazenados no próprio dispositivo do usuário, criados para auxiliar engenheiros da empresa na investigação de problemas. Esses logs permanecem localmente, a menos que sejam incluídos pelo usuário em um relatório de feedback. Ainda assim, por serem gerados em grande volume, acabaram produzindo atividade intensa de disco. Segundo a OpenAI, os registros tinham finalidade diagnóstica, mas dados de alto volume foram armazenados de uma forma que criou muito mais I/O do que o antecipado. Um porta-voz da empresa confirmou que os engenheiros estão cientes do problema e trabalham em correções. Pull requests recentes no projeto indicam esforços para ajustar o comportamento dos logs e reduzir o volume de gravações. Apesar disso, usuários continuaram registrando problemas, o que sugere que a mitigação ainda exige validação adicional em diferentes ambientes. A origem do comportamento parece estar associada a mudanças feitas em fevereiro para gravar logs SQLite do app-server no nível TRACE. Esse nível é muito mais detalhado do que níveis como ERROR, que registram apenas falhas mais graves. Em ferramentas distribuídas amplamente, manter logs em nível muito verboso pode causar impactos em desempenho, armazenamento, privacidade e durabilidade de dispositivos. O caso também chama atenção porque a própria série de commits relacionada teria sido revisada pelo Codex, possivelmente executando GPT-5.3. Isso torna o episódio particularmente simbólico: uma ferramenta de IA usada para apoiar revisão de código não teria identificado adequadamente uma decisão de engenharia capaz de gerar desgaste significativo em hardware. Para desenvolvedores, o incidente reforça a necessidade de monitorar o comportamento operacional de ferramentas de IA instaladas localmente. Agentes de programação podem executar processos persistentes, indexar projetos, observar arquivos, analisar código, manter estados locais e registrar diagnósticos continuamente. Mesmo sem intenção maliciosa, decisões inadequadas de logging podem gerar custos reais. Em ambientes corporativos, o problema também tem implicações práticas. Máquinas de desenvolvimento e runners de CI já lidam com cargas intensas de I/O, builds, testes, containers, cache de dependências e ferramentas de análise. Um agente que grava dados continuamente pode afetar a confiabilidade desses endpoints, aumentar custos de suporte e reduzir a vida útil de equipamentos. A recomendação para usuários do Codex é aplicar atualizações assim que correções forem disponibilizadas, monitorar o volume de escrita em disco e revisar diretórios de logs associados à ferramenta. Também é prudente observar processos com atividade contínua de I/O e avaliar configurações de logging até que o problema seja resolvido de forma definitiva. O episódio mostra que ferramentas de IA para desenvolvimento precisam ser avaliadas não apenas pela produtividade que entregam, mas também pelo impacto sobre o sistema do usuário. Consumo de CPU, memória, rede, armazenamento e operações de escrita em disco passam a fazer parte da análise de segurança, governança e confiabilidade desses agentes.

Usuários do Claude Code, ferramenta de programação da Anthropic, vêm relatando a exclusão inesperada de históricos de conversa dentro do aplicativo. Segundo reclamações abertas no repositório do projeto no GitHub, transcrições de chats estão desaparecendo sem aviso claro, especialmente quando ultrapassam 30 dias de idade. O problema estaria relacionado à opção de configuração cleanupPeriodDays, que vem definida por padrão para 30 dias. Na prática, sempre que o Claude Code é iniciado, o mecanismo de limpeza verifica arquivos de transcrição no formato .jsonl e remove aqueles considerados antigos demais. Para usuários que dependem dessas conversas como registro de decisões técnicas, raciocínios de depuração, análises e contexto de projeto, a exclusão pode representar perda relevante de informação. A Anthropic afirmou que a política de apagamento em 30 dias existe desde o lançamento do Claude Code como uma medida de segurança e está documentada. Segundo a empresa, manter transcrições em texto claro de sessões de programação no disco por tempo indefinido cria riscos reais de segurança e privacidade, já que esses registros podem conter código-fonte, credenciais e outros dados sensíveis. A companhia argumenta que o padrão de 30 dias busca equilibrar a capacidade de retomar trabalhos recentes com a necessidade de não armazenar dados locais por mais tempo do que o necessário. Do ponto de vista de segurança, a decisão tem lógica: históricos de interação com assistentes de código podem conter trechos de sistemas internos, tokens, chaves de API, caminhos de infraestrutura, erros de configuração e outras informações que não deveriam permanecer indefinidamente no dispositivo. A crítica dos usuários, porém, está menos na existência de uma política de retenção e mais na forma como ela é aplicada. De acordo com relatos no GitHub, o Claude Code não informa claramente durante a instalação, na primeira execução ou antes da limpeza que conversas com mais de 30 dias serão apagadas automaticamente. Também não haveria um aviso visível sobre a existência dessa configuração. Um dos usuários afirmou que a limpeza é executada “out of the box”, sem divulgação no momento da instalação nem diálogo inicial, levando pessoas a acreditarem que o histórico de conversas é mais durável do que realmente é. Para quem usa o Claude Code como parte de um fluxo contínuo de trabalho, essa diferença entre expectativa e comportamento real pode gerar impacto direto na produtividade. Outro relato destacou que, após a limpeza, o código do projeto e o histórico do Git continuaram disponíveis, mas o “rastro de raciocínio” foi perdido. Isso inclui discussões de design, contexto de debugging e análises feitas ao longo do processo. Para trabalhos de pesquisa, desenvolvimento exploratório ou investigação de problemas complexos, esse contexto pode ser tão importante quanto o próprio código final. O recurso de limpeza também parece não oferecer mecanismos de recuperação. Usuários apontam ausência de exclusão reversível, período de carência, opção de restauração ou registro detalhado do que foi removido. Isso significa que, depois da exclusão, pode não haver forma simples de confirmar quais conversas foram apagadas ou recuperar o conteúdo perdido. Outro ponto levantado na discussão é que aumentar o período de retenção nem sempre resolveria o problema. Alguns usuários relataram que configurar valores maiores não funciona como esperado. Uma análise de causa raiz feita por um participante sugere que a exclusão se baseia no mtime, ou horário de modificação do arquivo, em vez de usar o horário real da última atividade da conversa. Esse detalhe técnico pode gerar resultados inesperados porque o mtime é mutável por fatores externos. Um processo de restauração, uma ferramenta de sincronização, um script ou um backup que altere a data de modificação dos arquivos pode fazer uma sessão ainda relevante parecer antiga para o mecanismo de limpeza. Na próxima execução do Claude Code, o transcript pode ser removido silenciosamente. Até o momento, a principal solução sugerida pelos próprios usuários é manter backups das transcrições do Claude Code. Diferentes abordagens foram propostas na discussão, incluindo cópias periódicas dos arquivos de conversa antes da inicialização da ferramenta. Ainda assim, parte da comunidade considera essa recomendação insuficiente. Para esses usuários, backup é uma boa prática, mas não substitui uma política clara de produto para uma operação destrutiva. A expectativa é que o Claude Code informe melhor a existência da retenção automática, registre o que foi apagado, ofereça opções de recuperação ou permita configurar o comportamento de forma mais transparente. O caso expõe uma tensão recorrente em ferramentas locais de IA para desenvolvimento. Por um lado, armazenar conversas indefinidamente em texto claro pode ampliar riscos de vazamento, especialmente quando o conteúdo envolve código proprietário, credenciais, dados sensíveis ou detalhes de infraestrutura. Por outro, apagar automaticamente esse histórico sem aviso explícito pode comprometer fluxos de trabalho, auditoria técnica e continuidade de projetos. Em ambientes corporativos, a questão é ainda mais relevante. Assistentes de código vêm sendo usados para depuração, revisão, arquitetura, documentação e tomada de decisão técnica. Quando a conversa com a IA passa a conter justificativas, hipóteses, decisões de design e contexto de incidentes, o histórico deixa de ser apenas um chat e passa a funcionar como um artefato de trabalho. A controvérsia também reforça a necessidade de políticas internas para uso de agentes de IA. Empresas que utilizam ferramentas como Claude Code, GitHub Copilot, Codex ou outros assistentes de desenvolvimento devem definir onde conversas podem ser armazenadas, por quanto tempo, com que nível de criptografia, quem pode acessá-las e como backups ou retenção devem ser tratados. Para usuários individuais, a recomendação prática é revisar a documentação e as configurações de retenção do Claude Code, especialmente a opção cleanupPeriodDays. Quem depende dos históricos para pesquisa, desenvolvimento ou documentação deve considerar backups externos e verificar se ferramentas de sincronização ou restauração podem alterar metadados dos arquivos. A Anthropic defende que o comportamento foi desenhado como medida de segurança. Ainda assim, os relatos indicam que a experiência de uso não deixou essa política clara o suficiente para parte da base de usuários. Em ferramentas que lidam com código e dados potencialmente sensíveis, a transparência sobre retenção, exclusão e recuperação é tão importante quanto o próprio mecanismo de proteção.

Ferramentas de pentest totalmente automatizadas vêm perdendo espaço entre profissionais de segurança da informação. Segundo o relatório 2026 State of Pentesting, da Cobalt, a parcela de profissionais abertos à adoção de pentests totalmente autônomos caiu de 29% no ano passado para apenas 9% neste ano. O recuo ocorre em meio à frustração de equipes de segurança com ferramentas que prometem encontrar falhas de forma automatizada, mas ainda deixam passar vulnerabilidades críticas. De acordo com a Cobalt, 78% dos entrevistados no levantamento relataram ter enfrentado “falsos negativos críticos” em ferramentas automatizadas de varredura. Na prática, falsos negativos críticos ocorrem quando uma solução deixa de identificar uma vulnerabilidade grave existente no ambiente. Esse tipo de falha é especialmente preocupante porque pode criar uma sensação indevida de segurança. A organização acredita que determinado sistema foi validado, quando, na realidade, uma brecha relevante permanece explorável. A Cobalt afirma que scanners automatizados funcionam bem para identificar vulnerabilidades conhecidas e baseadas em assinaturas, mas apresentam desempenho muito inferior em cenários envolvendo segurança de inteligência artificial. O problema está no tipo de falha que ambientes baseados em IA e LLMs tendem a introduzir. Explorações de prompt injection, falhas de agência excessiva e vulnerabilidades lógicas em modelos de linguagem normalmente exigem interação criativa, múltiplas etapas, adaptação ao contexto e compreensão adversarial do comportamento do sistema. Esses elementos são difíceis de capturar por ferramentas que executam consultas automatizadas simples, de uma única tentativa. Prompt injection, por exemplo, ocorre quando um usuário ou atacante manipula entradas para fazer um sistema de IA ignorar instruções, vazar informações, executar ações indevidas ou alterar seu comportamento esperado. Já falhas de agência excessiva aparecem quando um agente de IA recebe autonomia demais para interagir com ferramentas, sistemas, APIs ou dados sensíveis sem controles adequados. Essas vulnerabilidades não se parecem com falhas tradicionais facilmente detectáveis por assinatura, como versões desatualizadas de software, configurações inseguras conhecidas ou endpoints expostos. Muitas dependem de lógica de negócio, fluxo de conversação, permissões, contexto operacional e combinações específicas de ações. Esse descompasso ajuda a explicar a queda na confiança em pentests totalmente automatizados. Após um ano de uso e avaliação dessas ferramentas, muitas organizações parecem ter concluído que cobertura automatizada não equivale necessariamente a garantia real de segurança. A própria Cobalt interpreta a redução de interesse como um sinal positivo de maturidade. Para a empresa, os profissionais estão enxergando além do discurso de fornecedores e exigindo validações mais concretas, em vez de aceitar apenas relatórios extensos de cobertura automatizada. O levantamento da Cobalt ouviu 450 profissionais, uma amostra relativamente pequena. Ainda assim, os dados indicam uma mudança relevante na percepção do mercado, especialmente porque a queda foi expressiva: de quase um terço dos respondentes abertos à ideia de pentest totalmente autônomo para menos de um décimo. A preocupação se torna maior diante do aumento de vulnerabilidades em ambientes que utilizam IA. Segundo dados de pentest citados pela Cobalt, cerca de 12% das vulnerabilidades detectadas em ambientes tradicionais são classificadas como de severidade alta ou crítica. Em ambientes com IA e LLMs, esse índice sobe para 32%. Esse percentual de 32% teria se mantido nos últimos dois anos, indicando que sistemas baseados em IA continuam introduzindo uma proporção maior de falhas relevantes. Quando esse cenário é combinado a ferramentas automatizadas que não conseguem detectar bem esse tipo de vulnerabilidade, o risco operacional aumenta. O desafio não está apenas na adoção de IA pelas equipes de segurança, mas também no uso de IA por áreas de desenvolvimento, atendimento, automação, análise de dados e operações. À medida que empresas incorporam modelos de linguagem e agentes em processos internos, novas superfícies de ataque surgem em integrações com APIs, bases de dados, ferramentas corporativas e fluxos de decisão automatizados. A Cobalt defende uma abordagem híbrida. Nesse modelo, sistemas de menor criticidade podem passar por varreduras automatizadas, enquanto ambientes críticos, aplicações sensíveis e sistemas baseados em IA exigem avaliação humana especializada. A proposta é combinar velocidade e escala das ferramentas com análise contextual de profissionais experientes. A recomendação tem interesse comercial, já que a própria Cobalt vende soluções nessa linha. Ainda assim, a conclusão não está isolada no mercado. A Veracode, empresa de segurança de aplicações, também alertou anteriormente que o desenvolvimento assistido por IA vem criando mais vulnerabilidades do que as equipes conseguem corrigir. Segundo a Veracode, 82% das empresas deixam vulnerabilidades conhecidas sem correção por mais de um ano, enquanto a participação de falhas de alto risco no total de vulnerabilidades descobertas também vem crescendo. Esse dado reforça a pressão sobre equipes de AppSec, DevSecOps e segurança ofensiva, que precisam lidar com mais código, mais automação e mais sistemas gerados ou modificados com apoio de IA. Nem todos, porém, adotam uma visão tão cética sobre pentest automatizado. CJ Moses, chefe de segurança da Amazon, afirmou que ferramentas de pentest baseadas em IA tornaram as equipes de segurança da companhia 40% mais eficientes, embora a métrica exata usada para esse cálculo não tenha sido detalhada. Mesmo assim, Moses também defendeu a presença de humanos no processo. Em entrevista durante a RSA Conference, ele afirmou que a IA é muito boa para executar tarefas, especialmente quando há grandes volumes de dados e necessidade de visão ampla. Porém, do ponto de vista de tomada de decisão, ainda não é uma tecnologia na qual a empresa esteja pronta para confiar integralmente. Essa visão reflete uma tendência mais equilibrada no setor. A automação pode acelerar tarefas repetitivas, ampliar cobertura, priorizar achados, correlacionar dados e apoiar analistas. Mas a identificação de falhas complexas, especialmente em sistemas de IA, ainda depende de raciocínio adversarial, conhecimento de contexto, criatividade e validação manual. O caso também reforça uma diferença importante entre “scanner” e “pentest”. Uma varredura automatizada pode identificar problemas conhecidos, mas um teste de invasão efetivo busca entender como falhas podem ser encadeadas, exploradas e transformadas em impacto real para o negócio. Em ambientes com IA, essa diferença fica ainda mais evidente. Para empresas, a principal lição é evitar tanto a rejeição total da automação quanto a confiança excessiva nela. Ferramentas automatizadas podem ser úteis, mas não devem substituir avaliações humanas em sistemas críticos, ambientes com dados sensíveis, aplicações expostas à internet, integrações com IA e fluxos que envolvem tomada de decisão ou acesso privilegiado. À medida que a IA passa a gerar código, operar agentes, interagir com APIs e apoiar processos corporativos, a segurança ofensiva também precisa evoluir. O pentest do futuro tende a ser menos uma disputa entre humanos e máquinas e mais uma combinação entre automação, análise especializada e validação contínua de riscos reais.

Líderes de agências de inteligência dos países Five Eyes — Austrália, Canadá, Nova Zelândia, Estados Unidos e Reino Unido — emitiram um alerta conjunto para que organizações tratem a segurança cibernética como prioridade executiva diante da aceleração dos riscos impulsionados por inteligência artificial. A orientação afirma que o avanço rápido da IA de fronteira pode tornar premissas de risco cibernético obsoletas em questão de meses, não de anos. Para as agências, embora a IA também possa fortalecer a defesa ao longo do tempo, ela já amplia a velocidade, a escala e a sofisticação das ameaças digitais. O comunicado aponta que modelos avançados de IA devem superar expectativas atuais da indústria e transformar tanto capacidades ofensivas quanto defensivas no ambiente cibernético. A mensagem central é direta: a janela de adaptação para empresas, governos e organizações críticas ficou mais curta. Segundo os líderes de inteligência, a resiliência cibernética deve ser vista como parte essencial da continuidade de negócios, da confiança do mercado e da geração de valor de longo prazo. O alerta busca tirar a segurança da informação do campo puramente técnico e colocá-la no centro da gestão de risco corporativo. As recomendações dos Five Eyes se concentram em quatro frentes: entender e avaliar risco, prontidão e responsabilidade; priorizar práticas e controles fundamentais de segurança; dar autoridade e recursos aos líderes de cibersegurança; e manter envolvimento ativo conforme ameaças e orientações evoluem. O documento reforça que o risco cibernético não pode mais ser tratado como uma questão exclusiva de TI. Para as agências, ele é um risco central de negócio e uma responsabilidade da liderança, porque violações vão ocorrer. A diferença estará na capacidade de conter rapidamente os incidentes e impedir que eles escalem para crises operacionais e financeiras de grande impacto. Esse ponto ganha peso em um contexto no qual ataques digitais podem interromper serviços, comprometer cadeias de suprimentos, gerar perdas financeiras, expor dados sensíveis e afetar reputação. Com IA acelerando reconhecimento, exploração e automação de ataques, o tempo entre a descoberta de uma falha e sua exploração tende a ficar ainda menor. Os chefes de inteligência também defendem que organizações testem sua resiliência cibernética de forma prática. Segundo o comunicado, não basta possuir controles implementados; líderes precisam ter confiança de que esses controles funcionarão durante um incidente real. Essa orientação envolve reavaliar escolhas antigas, testar planos de resposta, simular cenários adversos e usar IA de maneira deliberada para fortalecer a defesa. O objetivo não deve ser apenas melhorar eficiência, mas aumentar a capacidade de detectar, conter e recuperar operações em caso de ataque. O alerta também reconhece o lado defensivo da IA. Organizações que integram ferramentas de inteligência artificial em suas operações de segurança podem detectar vulnerabilidades mais cedo, melhorar a qualidade do software, monitorar comportamentos incomuns e responder a incidentes com mais rapidez. Essas capacidades podem reduzir tanto o custo quanto o impacto dos ataques. Ainda assim, o documento deixa claro que a mesma tecnologia também amplia o potencial ofensivo dos invasores. IA generativa e agentes autônomos podem ajudar na criação de phishing mais convincente, automação de reconhecimento, priorização de alvos, exploração de vulnerabilidades, geração de código malicioso e adaptação de ataques em larga escala. O interesse por esse risco aumentou após a divulgação de modelos avançados voltados à descoberta de falhas, como o Mythos, da Anthropic. A preocupação é que capacidades criadas para apoiar defensores também possam ser usadas por criminosos para encontrar brechas em softwares importantes com maior velocidade. Embora o alerta tenha tom forte, as ações recomendadas pelos Five Eyes não são novas. O próprio documento reconhece que são medidas conhecidas, mas agora urgentes para reduzir não apenas riscos técnicos, mas também exposição operacional, financeira e reputacional. A primeira ação prática é reduzir a superfície de ataque. Isso significa limitar acessos desnecessários a sistemas, revisar conectividade externa, questionar se determinados ambientes realmente precisam estar expostos e isolar sistemas que não deveriam estar acessíveis a redes amplas ou à internet. A segunda recomendação é acelerar processos de correção. As agências afirmam que a IA está encurtando o intervalo entre a descoberta de uma vulnerabilidade e sua exploração. Atrasos em patches aumentam o risco, especialmente em sistemas operacionais, ambientes críticos e plataformas com ciclos longos de atualização. A terceira orientação é enfrentar sistemas legados. Ambientes sem suporte não devem ser vistos apenas como dívida técnica, mas como passivos estratégicos. Sistemas antigos, desatualizados ou difíceis de corrigir continuam sendo alvos fáceis, principalmente quando permanecem conectados a operações relevantes. A quarta medida é revisar e fortalecer controles de identidade e acesso. As organizações devem limitar quem pode acessar sistemas críticos, aplicar autenticação forte e revisar permissões regularmente. Contas privilegiadas, acessos antigos, credenciais compartilhadas e permissões excessivas seguem entre os caminhos mais explorados por invasores. A quinta recomendação é preparar-se para incidentes antes que eles aconteçam. Isso inclui testar planos de resposta, treinar equipes, simular ataques e assumir que violações ocorrerão. O foco deve ser contenção rápida, recuperação eficiente e redução do impacto sobre operações, finanças e reputação. O alerta dos Five Eyes também reforça a importância de dar autoridade e recursos reais aos líderes de segurança. Sem apoio executivo, equipes de cibersegurança podem ter dificuldade para corrigir riscos estruturais, substituir sistemas legados, impor controles de acesso, reduzir exposição e acelerar atualizações críticas. A mensagem é especialmente relevante para organizações de grande porte, setores regulados, infraestrutura crítica e empresas com cadeias de suprimentos complexas. Nessas estruturas, um incidente cibernético pode se espalhar rapidamente e gerar efeitos além do ambiente técnico, afetando clientes, parceiros, fornecedores e operações essenciais. A conclusão das agências é que a IA muda o ritmo do risco cibernético. Empresas que ainda dependem de controles frágeis, processos lentos de patching, sistemas legados e baixa governança de identidade tendem a ficar mais expostas. A resposta precisa ser liderada no nível executivo, com foco em resiliência, continuidade e capacidade de reação.

A implantação de autenticação multifator em ambientes corporativos costuma ser tratada como uma das medidas básicas para reduzir o risco de comprometimento de contas. Ainda assim, um caso relatado à coluna On Call, do The Register, mostra como decisões internas e pressão operacional podem levar empresas a recuar justamente em controles de segurança considerados essenciais. O relato foi enviado por um leitor identificado pelo pseudônimo “Colin”, que trabalhava em um projeto para um cliente interessado em melhorar a segurança de sua implementação do Microsoft 365. O objetivo era elevar o Secure Score, métrica usada pela Microsoft para avaliar a postura de segurança e resiliência de ambientes Microsoft 365. Segundo Colin, a equipe passou um período considerável alinhando com o cliente um plano de implantação para habilitar MFA em toda a organização, seguindo uma linha de base de segurança previamente acordada. A autenticação multifator adiciona uma etapa extra de verificação além da senha, como aplicativo autenticador, token, biometria ou confirmação em dispositivo confiável, reduzindo o impacto de credenciais roubadas ou reutilizadas. A implementação começou de forma tranquila. A equipe técnica ativou as melhorias planejadas, e o processo parecia seguir sem incidentes relevantes. O problema surgiu na manhã seguinte, quando uma diretora sênior da empresa entrou em contato com o service desk em tom de forte reclamação. De acordo com o relato, a executiva, descrita como suposta COO de uma empresa de cibersegurança, acusou a equipe de ter paralisado a organização ao exigir o registro dos usuários no MFA. A reclamação indicava que o processo teria afetado um sistema de faturamento e poderia gerar impacto grave nos negócios em um curto período. Após a equipe conseguir entender o problema em meio às acusações, ficou claro que a falha afetava apenas três ou quatro telefones. A investigação apontou que o problema não estava na implantação do Microsoft 365 nem no MFA em si, mas no software de faturamento usado pela empresa. O sistema prometia suporte à autenticação multifator, mas dependia de uma implementação defeituosa para operar corretamente. Em outras palavras, o controle de segurança planejado funcionava no ambiente Microsoft, enquanto a interrupção estava associada à baixa qualidade ou instabilidade do software de terceiros integrado ao processo. Mesmo com essa explicação, a diretora não aceitou aguardar uma solução alternativa. A ordem foi realizar um rollback imediato, removendo a exigência de MFA. Segundo o relato, essa reversão continuava em vigor, deixando a empresa com uma postura de segurança inferior à planejada originalmente. Para Colin, o aspecto mais surpreendente foi a resistência de uma liderança supostamente ligada ao setor de segurança em manter uma medida básica de proteção. Na prática, a decisão priorizou a eliminação imediata do atrito operacional, mesmo que isso significasse deixar contas corporativas menos protegidas. O caso ilustra um dilema comum em projetos de segurança: controles técnicos podem ser bem planejados e executados, mas ainda assim enfrentar resistência quando sistemas legados, aplicações de terceiros ou processos internos não acompanham o mesmo nível de maturidade. Quando a pressão por continuidade operacional é tratada sem análise adequada, o resultado pode ser a remoção de mecanismos importantes de proteção. A autenticação multifator é especialmente relevante em ambientes Microsoft 365 porque credenciais de e-mail e colaboração corporativa continuam sendo alvos frequentes de phishing, ataques de força bruta, credential stuffing e campanhas de roubo de sessão. Sem MFA, uma senha comprometida pode ser suficiente para dar acesso a e-mails, arquivos, calendários, chats e aplicações integradas. Ao mesmo tempo, a implantação de MFA exige planejamento operacional. Organizações precisam mapear sistemas dependentes, fluxos de autenticação, dispositivos móveis, usuários privilegiados, contas de serviço, aplicativos legados e exceções temporárias. Quando aplicações críticas afirmam oferecer suporte a MFA, esse suporte deve ser validado antes da ativação ampla, preferencialmente em piloto controlado. O relato também mostra a importância de comunicação executiva em projetos de segurança. A implantação de controles como MFA deve ser acompanhada de mensagens claras sobre impacto esperado, benefícios, etapas de suporte, exceções documentadas e critérios para rollback. Sem esse alinhamento, incidentes pontuais podem ser interpretados como falha generalizada do projeto. Segundo Colin, o mesmo cliente já havia feito outras solicitações consideradas sem sentido, incluindo exigir que um engenheiro que não dirigia fosse imediatamente a um local remoto para corrigir uma impressora. Em outra ocasião, a mesma pessoa teria atribuído a um trabalho feito no Microsoft 365 a causa de uma queda de energia. Embora o caso tenha sido apresentado em tom leve pela coluna do The Register, ele aponta para um problema real em muitas organizações: a segurança pode ser enfraquecida não por falta de tecnologia, mas por decisões apressadas, baixa maturidade de governança e dificuldade de lidar com exceções operacionais. A principal lição é que MFA não deve ser tratado como um recurso opcional a ser removido ao primeiro atrito. Quando uma aplicação falha ao lidar com autenticação multifator, a resposta adequada é identificar a causa, aplicar contornos temporários bem documentados e corrigir a integração, não abandonar o controle em toda a organização. Em ambientes corporativos, especialmente aqueles que dependem de Microsoft 365, o equilíbrio entre segurança e operação exige processos de mudança bem definidos. A ausência de MFA pode parecer uma solução rápida para um problema imediato, mas aumenta a exposição a ataques de conta, comprometimento de e-mail corporativo e acesso indevido a dados sensíveis.

O desenvolvedor Python Roman Imankulov quase caiu em uma armadilha disfarçada de oportunidade de trabalho. O ataque, conduzido por uma pessoa que se apresentou como recrutadora de uma pequena startup de criptomoedas, usava um repositório aparentemente problemático como pretexto para induzir a execução de código malicioso durante uma avaliação técnica. O contato ocorreu pelo LinkedIn. A suposta recrutadora afirmou que a empresa precisava de um lead engineer e pediu ajuda para analisar um código de prova de conceito que não funcionava. Segundo ela, o problema estaria relacionado a um módulo Node depreciado. A abordagem parecia plausível, mas algo no pedido chamou a atenção de Imankulov. Em entrevista por telefone, o desenvolvedor afirmou que já havia ouvido falar desse tipo de ataque e, por experiência anterior, levantou a hipótese de que ele próprio poderia ser o alvo. Em vez de clonar e executar o projeto diretamente em sua máquina, ele adotou uma postura mais cautelosa: criou uma VPS na Hetzner, clonou o repositório nesse ambiente isolado e usou seu agente de codificação Pi, executando Codex, para realizar uma análise somente leitura do código. A expectativa inicial era que a ferramenta apenas apontasse baixa qualidade no código e autorizasse uma revisão convencional. O resultado foi diferente. Segundo Imankulov, o agente respondeu quase imediatamente com um alerta para não executar o projeto, indicando que havia uma armadilha no repositório. A análise com IA apontou o arquivo app/test/index.js como suspeito. O conteúdo escondia uma backdoor por meio de uma URL de servidor fragmentada para parecer parte de uma configuração de suíte de testes. O script incluía uma requisição de rede capaz de executar qualquer código enviado pelo servidor em resposta. Imankulov afirmou que havia aberto o arquivo manualmente e, ao passar os olhos pelo conteúdo, interpretou o código como apenas mal escrito. Para ele, parecia um arquivo típico de um desenvolvedor descuidado, não uma ameaça evidente. O agente de IA, no entanto, identificou no mesmo arquivo a vulnerabilidade que ele havia deixado passar. O ataque não exigia que a vítima executasse manualmente um binário suspeito. Bastaria instalar o projeto usando npm. O arquivo package.json do repositório continha um hook “prepare”, executado após a instalação, projetado para rodar o script malicioso durante o processo de instalação das dependências. Esse detalhe torna o ataque especialmente perigoso para desenvolvedores. O comando npm install faz parte da rotina de trabalho em projetos JavaScript e Node.js, e muitos profissionais o executam automaticamente ao avaliar um repositório. Ao esconder a execução dentro de um hook de ciclo de vida do npm, os invasores transformam um fluxo legítimo de desenvolvimento em vetor de comprometimento. A arquiteta independente de open source e segurança Devashri Datta explicou ao The Register que a abordagem é insidiosa justamente por sequestrar workflows comuns de desenvolvimento. O adversário não depende de um arquivo executável claramente suspeito. Ele se apoia em um comando rotineiro e confiável, executado durante a resolução de dependências. Segundo Datta, a fragmentação da string usada para montar a URL maliciosa também foi deliberada. Em vez de deixar um domínio suspeito escrito de forma direta no código, os operadores dividiram a informação em pequenas constantes, dificultando a detecção por ferramentas de análise estática que procuram indicadores de comprometimento hardcoded. O repositório malicioso original não está mais acessível, provavelmente removido pelo GitHub após a denúncia de Imankulov, embora uma cópia ainda tenha sido encontrada. A investigação também mostrou outro elemento comum em ataques de engenharia social contra desenvolvedores: a aparência de legitimidade. Os commits no repositório pareciam ter sido feitos por um desenvolvedor com presença pública estabelecida e histórico real de trabalho. Quando Imankulov entrou em contato com o suposto autor, ele afirmou que já havia sido impersonado no GitHub mais de uma vez e que não havia escrito aquele código. A identidade da recrutadora também levantou sinais de falsificação. O perfil no LinkedIn fazia referência a uma jornalista de artes real, mas Imankulov acredita que a conta associada era falsa. As interações com a suposta recrutadora indicavam um nível de conhecimento técnico que não aparecia no histórico profissional exibido no perfil. O caso ocorre em um cenário no qual contas falsas em plataformas profissionais continuam sendo usadas para golpes. Embora o LinkedIn afirme remover dezenas de milhões de contas falsas antes que elas interajam com usuários, centenas de milhares ainda conseguem ser criadas e entrar em contato com pessoas antes de serem detectadas. Entre janeiro e junho de 2025, a plataforma restringiu 386 mil contas após denúncias de usuários, acima das 266 mil no semestre anterior e das 86 mil registradas no primeiro semestre de 2021. Ataques de engenharia social contra a cadeia de suprimentos de software se tornaram cada vez mais comuns. Campanhas recentes associadas à Coreia do Norte, por exemplo, têm usado entrevistas falsas e ofertas de emprego para comprometer contas de desenvolvedores, roubar credenciais e obter acesso a ambientes internos. Outros desenvolvedores também relataram quase ter caído em golpes semelhantes, em alguns casos igualmente salvos por agentes de IA usados para revisar o código antes da execução. Para Datta, a resposta de Imankulov aponta uma mudança importante na higiene de revisão de código entre profissionais mais atentos à segurança. Historicamente, a recomendação era revisar manualmente código não confiável ou executá-lo em sandbox. Neste caso, o desenvolvedor usou um agente local de IA em um ambiente restrito e somente leitura para analisar a base de código antes de executar qualquer comando. A IA, nesse contexto, atuou como uma camada defensiva no endpoint do desenvolvedor, capaz de identificar rapidamente comportamentos anômalos, como uma suíte de testes fazendo conexão externa para buscar código não verificado. O incidente também mostra por que a segurança da cadeia de suprimentos de software precisa considerar o ambiente local dos engenheiros. Uma estação de trabalho de desenvolvedor pode conter chaves SSH ativas, tokens de provedores cloud, sessões autenticadas e acesso a repositórios internos. Se esse dispositivo for comprometido durante uma falsa entrevista técnica, o impacto pode ir além do usuário individual e atingir a organização. Uma mudança relevante pode reduzir esse vetor no ecossistema npm. O GitHub, mantenedor do npm, prepara o lançamento do npm 12, que altera o comportamento do comando npm install. A configuração allowScripts passará a vir desativada por padrão, impedindo que scripts preinstall, install ou postinstall de dependências sejam executados automaticamente, a menos que sejam explicitamente autorizados no projeto. Segundo Leo Balter, gerente de produto do GitHub, scripts de ciclo de vida executados durante a instalação representam a maior superfície de execução de código no ecossistema npm. Como cada npm install pode rodar scripts de dependências transitivas, um único pacote comprometido em qualquer ponto da árvore de dependências pode executar código arbitrário em uma máquina de desenvolvimento ou runner de CI. Para Imankulov, a mudança é bem-vinda, mas ele já adotou uma medida prática por segurança pessoal: passou a usar pnpm para garantir que scripts desse tipo não sejam executados por padrão. A decisão reflete uma postura crescente entre desenvolvedores que lidam com código de terceiros ou projetos recebidos em contextos de baixa confiança. Datta defende que empresas devem ir além de orientações genéricas e aplicar barreiras técnicas. Entre as medidas estão o uso de contêineres isolados para desenvolvimento, workstations seguras em nuvem e ambientes descartáveis para avaliar código externo ou não confiável. Essas práticas reduzem o risco de que uma avaliação técnica, uma prova de conceito ou um processo seletivo se transforme em ponto de entrada para credenciais corporativas. O caso reforça uma mudança no alvo dos ataques à cadeia de suprimentos. Em vez de esperar que um pacote malicioso chegue a um repositório corporativo, invasores estão tentando comprometer desenvolvedores antes mesmo que uma linha de código entre no pipeline da empresa. A ameaça começa no endpoint individual, no momento em que o profissional clona um repositório, instala dependências e confia em fluxos automatizados do próprio ecossistema de desenvolvimento.

A Anthropic voltou a disponibilizar mundialmente o Claude Fable 5 após o Departamento de Comércio dos Estados Unidos suspender, em 30 de junho, os controles de exportação impostos ao modelo e ao Mythos 5 cerca de duas semanas e meia antes. O Fable 5 retorna aos usuários em 1º de julho, com acesso pelo Claude.ai, Claude Platform, Claude Code e Claude Cowork. A medida encerra, ao menos por enquanto, uma disputa envolvendo segurança de modelos avançados de IA, risco de uso dual, competição internacional e a ausência de um processo regulatório claro para respostas rápidas do governo americano diante de possíveis capacidades perigosas em sistemas de fronteira. Os controles de exportação restringem quem pode receber ou usar determinada tecnologia. A ordem de 12 de junho determinava que a Anthropic interrompesse o acesso aos modelos Fable 5 e Mythos 5 para qualquer cidadão estrangeiro, dentro ou fora dos Estados Unidos, incluindo funcionários não cidadãos da própria empresa. Como a regra entrou em vigor imediatamente e a Anthropic não tinha uma forma confiável de verificar em tempo real a nacionalidade de todos os usuários, a companhia decidiu retirar ambos os modelos do ar para todos. Na prática, uma restrição voltada a usuários estrangeiros levou à suspensão global temporária do acesso. O gatilho para a decisão foi um jailbreak identificado por pesquisadores da Amazon no Fable 5. Jailbreaks são prompts ou técnicas criadas para fazer um modelo contornar suas regras de segurança. Segundo a Anthropic, o prompt fazia o modelo sinalizar algumas falhas de software e, em um caso, escrever código demonstrando como uma vulnerabilidade poderia ser abusada. A Anthropic minimizou a gravidade da descoberta. A empresa afirmou que solicitações semelhantes funcionam em vários modelos considerados menos avançados, incluindo seu próprio Claude Opus 4.8, o GPT-5.5 da OpenAI e o Kimi K2.7, da China. Para a companhia, o comportamento apontado estava mais próximo de atividades rotineiras de segurança defensiva do que de uma capacidade oculta e extraordinária. O governo americano e o parceiro que relatou o jailbreak, no entanto, trataram o caso como suficientemente sério para justificar controles emergenciais. A preocupação central era que um modelo capaz de ajudar defensores a encontrar e corrigir falhas também pudesse ser usado por agentes maliciosos para acelerar a descoberta e exploração de vulnerabilidades. Para responder à preocupação, a Anthropic treinou um novo filtro de segurança, chamado de classificador, voltado a identificar a técnica exata descrita no relatório. Segundo a empresa, o mecanismo passou a bloquear mais de 99% das tentativas relacionadas a esse método, conforme publicação de 30 de junho. Quando uma solicitação é bloqueada, ela passa a ser encaminhada ao modelo mais fraco Claude Opus 4.8, e o usuário é informado. A empresa reconhece, porém, que essa abordagem tem um custo: aumento de falsos positivos em tarefas legítimas de programação, depuração e análise de código. O Mythos 5, descrito como o mesmo modelo subjacente, mas com menos barreiras de segurança, permanece sob controle mais rígido. O acesso foi restabelecido em 26 de junho para cerca de 100 empresas americanas e agências federais envolvidas na defesa de infraestrutura crítica. A Anthropic afirma que ainda trabalha com o governo para ampliar o acesso. O secretário de Comércio dos EUA, Howard Lutnick, responsável pela reversão, afirmou que o departamento passou duas semanas revisando os modelos junto com a Anthropic. Em uma carta, a empresa concordou em buscar problemas de segurança por conta própria, coordenar lançamentos futuros e reportar usos maliciosos que venha a identificar. As negociações teriam sido conduzidas pelo cofundador Tom Brown, e não pelo CEO Dario Amodei, que vinha enfrentando atritos com a administração americana ao longo do ano. A disputa também foi marcada por ruído político e competitivo desde o início. Relatos de veículos como The Wall Street Journal indicaram que a pesquisa da Amazon e preocupações do CEO Andy Jassy ajudaram a impulsionar a ordem original. O ex-czar de IA David Sacks acusou a Anthropic de ter priorizado a continuidade da oferta do modelo de consumo em detrimento da segurança. Outros analistas interpretaram a resposta do governo como um exagero. Francesco Bailo, pesquisador de governança de IA da Universidade de Sydney, disse à Al Jazeera que a reversão parecia indicar que o governo havia reconhecido ter ido longe demais. Um grupo de líderes de segurança também assinou uma carta aberta pedindo a suspensão dos controles. A disputa ocorreu em meio à crescente competição internacional em IA. A pausa no acesso aos modelos americanos veio em um momento no qual modelos chineses open source, mais baratos e cada vez mais capazes, vinham ganhando espaço. Executivos do setor alertaram que congelar modelos dos Estados Unidos poderia dar tempo adicional para concorrentes estrangeiros avançarem. Além de restaurar o Fable 5, a Anthropic está propondo algo que ainda falta à indústria: uma forma compartilhada de classificar a gravidade de jailbreaks. Em colaboração com Amazon, Microsoft, Google e outros parceiros, a empresa quer avaliar cada técnica com base em quatro critérios principais. O primeiro é o ganho de capacidade, ou seja, até que ponto o jailbreak leva o usuário além das ferramentas e capacidades que ele já teria. O segundo é a amplitude, medindo quantos tipos diferentes de ataque uma mesma técnica desbloqueia. O terceiro é a facilidade de weaponization, isto é, quanto conhecimento e esforço são necessários para transformar a técnica em um ataque real. O quarto é a descobribilidade, que avalia quão fácil é encontrar, copiar ou reproduzir o método. Para os casos mais graves, como jailbreaks capazes de permitir ataques contra redes elétricas, bancos ou outras infraestruturas críticas, a Anthropic afirma que começará a implementar correções assim que a severidade for confirmada. A empresa também está criando uma equipe para acompanhar relatos de jailbreaks de forma contínua. A companhia abriu ainda um programa no HackerOne para que pesquisadores reportem novos jailbreaks no Fable 5. Como parte dos compromissos assumidos, a Anthropic também prometeu ao governo dos Estados Unidos acesso antecipado para testar futuros modelos de fronteira antes do lançamento. A Anthropic não é a única empresa pressionada por esse dilema. Dias antes, a OpenAI apresentou o GPT-5.6 a um grupo pequeno e aprovado pelo governo, em vez de abrir o acesso ao público, citando a mesma preocupação de uso dual. O problema é estrutural: um modelo bom o suficiente para ajudar defensores a corrigir vulnerabilidades também pode ser útil para atacantes encontrarem e explorarem falhas. O risco não é apenas teórico. No início do ano, a Anthropic testou uma versão anterior do Mythos que encontrou e explorou vulnerabilidades zero-day sob comando em grandes sistemas operacionais e navegadores, incluindo uma falha de 27 anos no OpenBSD. A equipe de red team da empresa também conseguiu transformar falhas recém-divulgadas em exploits funcionais em menos de um dia. A crise imediata envolvendo o Fable 5 foi resolvida com a suspensão dos controles emergenciais, mas a questão regulatória permanece aberta. Uma ordem executiva de 2 de junho criou um caminho voluntário para que empresas submetam modelos de fronteira a revisão antes do lançamento. Também estabeleceu um benchmark classificado para definir quais modelos seriam considerados “cobertos”, mas descartou a exigência de licença obrigatória para disponibilizar um modelo. O Fable 5 não passou por esse caminho. Em vez disso, o governo recorreu a controles de exportação, uma ferramenta tradicionalmente usada para restringir acesso a tecnologias sensíveis. O episódio mostra que, quando Washington precisa agir rapidamente sobre um modelo de fronteira, ainda não há um processo obrigatório e bem definido, apenas respostas improvisadas.

O Notepad, conhecido no Brasil como Bloco de Notas, sempre foi um dos símbolos da simplicidade no Windows. Mas, para Dave Plummer, ex-engenheiro da Microsoft e autor do Gerenciador de Tarefas, a versão atual do editor de texto reflete um problema maior: a tendência de adicionar recursos demais a ferramentas que nasceram para executar tarefas básicas. Plummer afirma que, em sua época na Microsoft, havia uma divisão clara de papéis. O Notepad era voltado exclusivamente para texto puro, enquanto o WordPad ficava responsável por documentos em RTF, fontes mais elaboradas e funções adicionais. Essa separação, segundo ele, ajudava a manter o editor leve, direto e previsível para o usuário. Décadas depois, o cenário mudou. O WordPad foi descontinuado, e o Notepad passou a receber novas funções, incluindo recursos alimentados por Copilot para sugerir ajustes em textos. Para Plummer, essa evolução representa uma perda de foco. Em resposta, ele decidiu reconstruir o editor do zero, criando uma versão extremamente enxuta, sem telemetria e sem recursos considerados desnecessários. O resultado é o TinyRetroPad, um fork do Dave’s Tiny Editor, conhecido como DTE, criado por Matt Power. O projeto foi escrito em assembly e utiliza o componente RICHEDIT50W da WinAPI, aproveitando elementos já presentes no próprio Windows em vez de recriar funcionalidades do sistema. Essa abordagem permitiu reduzir drasticamente o tamanho do executável. Segundo Plummer, o TinyRetroPad tem apenas 2.686 bytes. Em testes mencionados pelo The Register, a compilação chegou a 2.794 bytes, ocupando 4.096 bytes em disco por causa do tamanho mínimo de cluster do sistema de arquivos. Ainda assim, trata-se de um tamanho muito inferior ao do Notepad.exe atual, descrito como mais de 100 vezes maior que o executável criado pelo ex-engenheiro. Apesar do tamanho reduzido, o TinyRetroPad não é apenas uma janela vazia para digitação. O aplicativo conta com diálogos de abertura e salvamento de arquivos, seleção de fonte e até suporte a impressão. A diferença é que essas funções dependem fortemente de componentes nativos do Windows, o que reduz o volume de código próprio necessário para entregar a experiência. Plummer brincou que o sistema de impressão do Windows é “meio assustador”, comparando-o a abrir uma escotilha no chão e descobrir um segundo sistema operacional por baixo. A observação reforça a complexidade acumulada em certas partes do Windows, mesmo quando a aplicação em si tenta permanecer mínima. Visualmente, o TinyRetroPad foi criado para lembrar o Notepad da época do Windows XP. A proposta não é competir com editores modernos cheios de recursos, mas demonstrar que uma ferramenta simples de texto ainda pode ser construída de forma extremamente leve quando se apoia em componentes já disponíveis no sistema operacional. A crítica de Plummer vai além do Bloco de Notas. Para ele, o Notepad funciona como um exemplo simbólico de como softwares simples podem se tornar inflados ao longo do tempo. A inclusão de novas funções, integrações e camadas adicionais pode aumentar o tamanho do código e a complexidade de manutenção sem necessariamente entregar uma melhoria proporcional para todos os usuários. O caso também reacende uma discussão antiga no desenvolvimento de software: até que ponto adicionar funcionalidades torna um produto melhor? No caso de ferramentas básicas, como editores de texto, calculadoras ou utilitários de sistema, muitos usuários valorizam previsibilidade, velocidade e baixo consumo de recursos mais do que integrações avançadas. Embora existam diversas alternativas ao Notepad, poucas seguem uma abordagem tão radicalmente minimalista quanto o TinyRetroPad. O projeto mostra que, em determinadas situações, manter o código enxuto ainda pode ser uma escolha técnica relevante, especialmente em um contexto no qual sistemas operacionais e aplicativos acumulam dependências, recursos e camadas de abstração. Mesmo que a versão atual do Notepad ofereça funções úteis para parte dos usuários, o experimento de Plummer aponta para uma tensão recorrente na indústria de software: a busca por inovação pode transformar ferramentas simples em produtos mais pesados do que deveriam ser. O TinyRetroPad, com seus poucos kilobytes, funciona como uma provocação técnica e nostálgica sobre o valor da simplicidade no Windows.

Durante o período, maior pressão sobre a segurança a riscos digitais impulsiona ações de monitoramento e reforço operacional por parte das organizações O megaevento global passou a representar um período de maior atenção para a segurança digital, diante de movimentações maliciosas que exploram momentos de distração e grande volume de acessos. Em meio a transmissões online, apostas esportivas, pagamentos instantâneos e milhões de usuários conectados simultaneamente, organizações de diversos setores ampliam monitoramento, revisam planos de resposta e reforçam operações para reduzir riscos durante o campeonato. De acordo com a Delfia, curadoria de jornadas digitais, eventos de grande audiência funcionam como uma espécie de “cortina de fumaça” para ataques digitais. Enquanto empresas concentram esforços em garantir disponibilidade, performance e estabilidade de seus ambientes durante as partidas, criminosos aproveitam o aumento do tráfego, da distração e da pressão operacional para executar fraudes, golpes e movimentações maliciosas que podem passar despercebidas. “O ambiente fica mais barulhento. Há mais acessos, mais consumo digital, mais alertas e mais pressão sobre os times. E é justamente nesse cenário que muitos ataques conseguem operar abaixo do radar”, afirma Leonardo Santos, CTO da Delfia. Em um momento no qual a economia digital ligada ao futebol cresce, plataformas de apostas, aplicativos financeiros, transmissões via streaming, carteiras digitais e transações de Pix devem registrar picos de acesso durante o campeonato, ampliando o risco operacional e a superfície de ataque das empresas. Golpes personalizados por IA Além do aumento da exposição digital, a inteligência artificial sofisticou o nível dos ataques associados a grandes eventos. Golpes utilizando promoções falsas, transmissões piratas, QR Codes fraudulentos, páginas clonadas, apostas esportivas e uso indevido de marcas de patrocinadores tendem a crescer durante o período da Copa, agora impulsionados por IA para personalização em escala. “A IA aumenta velocidade e capacidade de automação dos ataques. Hoje é possível criar campanhas de phishing muito mais convincentes, páginas falsas mais realistas e abordagens extremamente contextualizadas ao comportamento do usuário”, explica Leonardo Santos, da Delfia. Para ele, o problema não está apenas na tecnologia utilizada pelos criminosos, mas no comportamento das pessoas nesse período. “Durante a Copa, o usuário está mais emocional, mais distraído e mais propenso a clicar sem verificar. O risco aumenta porque existe uma combinação de empolgação, urgência e excesso de informação circulando ao mesmo tempo”, destaca. Esse cenário também impacta as operações corporativas. “Em momentos de muita atenção por exemplo, durante um gol ou uma jogada decisiva, um alerta importante pode deixar de ser analisado imediatamente. Às vezes, alguns minutos fazem diferença entre conter uma ameaça rapidamente ou permitir que ela avance dentro do ambiente”, salienta Leonardo Santos da Delfia. Empresas criam operações especiais Para reduzir riscos durante o campeonato, organizações de setores mais expostos vêm reforçando operações de monitoramento e resposta rápida a incidentes. Leonardo explica que é comum a criação de operações preventivas de “war rooms” em empresas com maior maturidade digital, que são as estruturas que integram times de segurança, infraestrutura, redes, aplicações, fornecedores, integradores, fabricantes e parceiros estratégicos para reduzir tempo de resposta em caso de incidentes ou de algum comportamento estranho. “Não é apenas uma questão de tecnologia e o principal ganho é que a atuação deixa de ser apenas reativa. Esses ambientes funcionam para garantir coordenação rápida entre diferentes áreas caso ocorra qualquer comportamento suspeito ou instabilidade operacional”, ressalta o CTO da Delfia. Leonardo também destaca que empresas de apostas esportivas, bancos, fintechs, meios de pagamento, call centers, patrocinadores e plataformas de transmissão estão entre os segmentos mais expostos durante o período da Copa. “As BETs, por exemplo, devem sofrer enorme pressão durante os jogos, principalmente em pagamentos, autenticação e volume de acessos. Já empresas de transmissão lidam com risco reputacional imediato caso exista qualquer indisponibilidade durante partidas importantes”, acrescenta. “Patrocinadores também ficam expostos porque a marca pode ser usada como isca em golpe, promoção falsa, página fraudulenta e em campanhas maliciosas contextualizadas. Às vezes, o risco não está só na infraestrutura da empresa, mas no uso indevido da marca contra o consumidor”. O erro mais comum: olhar apenas para disponibilidade De acordo com a Delfia, um dos principais erros das empresas em períodos de alta exposição é concentrar toda a atenção apenas em estabilidade e performance, sem observar movimentações que "voam" por baixo do radar, como fraude, abuso de credenciais ou exploração de vulnerabilidades. “Muitas organizações entram nesses eventos olhando apenas para indisponibilidade e DDoS. Mas, enquanto isso, outros ataques podem acontecer de forma mais discreta, aproveitando exatamente o momento de distração operacional”, reforça Santos. Ainda, uma questão levantada pelo CTO da Delfia é montar uma operação de “war room” focada em algo específico e deixar de ver o todo. “No fim, o erro não é só técnico. É operacional. Não basta ter ferramenta ou sala de guerra. Precisa ter escala, cobertura e visão ampla para tomar boas decisões”. Outro desafio é a própria exaustão das equipes de tecnologia e segurança em operações que exigem monitoramento contínuo durante jogos e horários críticos. “A segurança depende também de processo, coordenação, cobertura e capacidade de resposta rápida. Grandes eventos amplificam riscos que muitas vezes já existem no ambiente”, avalia Santos. Mais vulnerável X mais consciência dos riscos Na avaliação da Delfia, apesar do aumento da conscientização sobre segurança digital nos últimos anos, empresas e usuários ainda ficam mais vulneráveis durante grandes eventos como a Copa do Mundo. Para reduzir riscos durante esses períodos, a recomendação do especialista é reforçar monitoramento, revisar planos de resposta e validar previamente a capacidade dos ambientes digitais. Segundo o executivo, empresas mais preparadas costumam ajustar limiares de monitoramento, revisar fluxos críticos, validar fornecedores e acompanhar movimentações de ameaças observadas em outros países e setores, utilizando essas informações como alerta antecipado. Além disso, a Delfia reforça que a preparação precisa considerar múltiplas camadas de proteção, envolvendo mitigação global e local, firewalls, WAF, SOC, proteção de identidade, endpoints e resposta coordenada entre equipes e parceiros. “Grandes eventos não criam riscos do zero, mas ampliam vulnerabilidades que muitas vezes já existem. Nesse contexto, segurança não significa apenas bloquear ataques, mas garantir continuidade operacional, experiência do usuário, reputação e capacidade de resposta rápida”, conclui Leonardo Santos, da Delfia.

A T-Mobile parece estar em processo de saída do ecossistema VMware, ao mesmo tempo em que trava uma disputa judicial com a Broadcom pelo direito de manter suporte a um ambiente de virtualização considerado crítico para suas operações internas. Segundo documentos judiciais, o caso envolve uma infraestrutura de grande escala, com software VMware executado em mais de 303 mil núcleos de CPU e usado como base para parte relevante da rede interna da operadora. A disputa tem origem em um acordo firmado entre a T-Mobile e a VMware em agosto de 2023. Na ocasião, a operadora adquiriu licenças perpétuas e dois anos de suporte para determinados softwares, além de uma opção contratual para estender esse suporte por mais um ano. Pouco depois, a Broadcom concluiu a aquisição da VMware e mudou de forma significativa o modelo comercial da empresa. Após assumir o controle da VMware, a Broadcom deixou de vender licenças perpétuas e contratos de suporte independentes para clientes que já possuíam esse tipo de licença. A companhia também reduziu o portfólio da VMware, que tinha mais de 150 produtos, para dois pacotes principais baseados em assinatura. Hoje, a estratégia comercial da Broadcom está concentrada principalmente no VMware Cloud Foundation, conhecido como VCF, uma suíte voltada para nuvens privadas corporativas. A mudança gerou atrito com grandes clientes que afirmam ter direito contratual à extensão de suporte. AT&T e Tesco já tentaram exercer opções semelhantes. A AT&T chegou a um acordo confidencial, enquanto a Tesco continua discutindo o caso nos tribunais. A T-Mobile agora aparece em uma disputa parecida, mas com um agravante operacional importante: o ambiente VMware da empresa sustenta uma parte expressiva de sua infraestrutura interna. Em uma das audiências, a defesa da T-Mobile descreveu a implementação VMware da operadora como a base de toda a rede interna e o local onde residem cerca de mil aplicações. Em outra petição, apresentada pela Broadcom, consta que a T-Mobile executa softwares VMware em mais de 303 mil núcleos de CPU, dimensão que ajuda a explicar a complexidade de qualquer migração. De acordo com os documentos, a Broadcom teria informado em 2024 que não renovaria o suporte após o fim do contrato inicial de dois anos, previsto para 2025. As duas empresas continuaram discutindo possíveis novos acordos, enquanto a T-Mobile também buscava uma liminar para obrigar a Broadcom a fornecer o suporte estendido. A Broadcom contestou a liminar e argumentou que a T-Mobile esperou tempo demais para pedir a medida judicial. A empresa sustenta, em linhas gerais, que não poderia oferecer suporte nos termos originais porque os produtos cobertos pelo contrato deixaram de existir em sua forma anterior. Também afirma que seus contratos permitem negar suporte para produtos descontinuados e que o modelo de assinatura se tornou o padrão do setor. Em determinado momento da negociação, a T-Mobile sugeriu um acordo de US$ 20 milhões para obter mais dois anos de suporte. Uma declaração apresentada na semana passada por Kevin Luu, vice-presidente de tecnologia da T-Mobile, afirma que a operadora buscava esse arranjo para conseguir concluir a transição para fora da VMware em um ritmo mais controlado. A Justiça acabou concedendo uma liminar que obrigou a Broadcom a oferecer suporte além de agosto de 2025. Como condição, a T-Mobile teve de pagar US$ 5,28 milhões e apresentar uma garantia de US$ 500 mil. A Broadcom continuou prestando suporte, mas também passou a buscar indenização, alegando que a liminar teria impedido a conclusão de um novo acordo comercial com a operadora. A T-Mobile rejeita esse argumento. Para a empresa, não faria sentido afirmar que a Broadcom perdeu um contrato definitivo se as duas partes ainda estavam discutindo possíveis termos comerciais. A operadora também questiona o valor proposto pela Broadcom para a continuidade do suporte. Segundo os documentos, a Broadcom propôs cobrar US$ 24 milhões pelo suporte estendido de seis produtos. A justificativa apresentada foi que seriam necessários mais de 20 profissionais para atender à T-Mobile. A operadora rebateu esse ponto ao afirmar que fez apenas duas chamadas de suporte em 2026, o que, segundo sua visão, não sustentaria a necessidade de uma equipe tão grande nem de um custo tão elevado. O caso ganhou urgência porque a liminar atual expira em 3 de agosto de 2026. Caso não haja nova decisão ou acordo, a T-Mobile pode ficar sem suporte para um ambiente VMware de grande porte enquanto tenta concluir sua migração. Um detalhe relevante é que a juíza responsável pelo caso, Jennifer G. Schecter, também presidiu a disputa entre VMware e AT&T. Naquele processo, as partes chegaram a um acordo confidencial. Em uma audiência realizada em outubro de 2025, Schecter indicou que considerava o caso da T-Mobile ainda mais forte que o da AT&T. A defesa da VMware argumentou que os casos seriam diferentes porque a AT&T teria agido rapidamente, enquanto a T-Mobile teria esperado muitos meses antes de buscar o suporte estendido e a liminar. A empresa também afirmou que milhares de clientes já migraram para assinaturas, tratando T-Mobile e AT&T como exceções em um universo de cerca de 10 mil clientes. A juíza, porém, demonstrou ceticismo diante desse argumento. Para ela, o fato de outros clientes terem aceitado a migração para assinatura não significa necessariamente concordância plena com a estratégia da Broadcom. Alguns clientes podem não querer enfrentar uma disputa judicial, podem considerar a briga inviável financeiramente ou podem ter ambientes menores e mais fáceis de migrar. A Broadcom, por sua vez, defende que os clientes que migram para assinaturas VCF passam a operar uma infraestrutura mais eficiente, capaz de melhorar o desempenho geral dos negócios. A empresa também aponta o crescimento de receita da VMware como evidência de que sua estratégia comercial está funcionando. Na semana passada, a VMware citou a Nationwide Building Society, do Reino Unido, como uma das organizações que aderiram ao VCF. Para grandes empresas que dependem de plataformas legadas de virtualização, o embate mostra como mudanças de licenciamento podem se transformar em risco operacional. Mesmo quando há uma estratégia de migração definida, ambientes com centenas de milhares de núcleos, milhares de aplicações e dependências internas profundas não costumam ser substituídos rapidamente. No caso da T-Mobile, a disputa não envolve apenas preço ou modelo de assinatura, mas a continuidade do suporte a uma base tecnológica considerada central para suas operações. A decisão final poderá ter impacto além da própria operadora. Caso a Justiça reconheça de forma ampla o direito de clientes a extensões de suporte previstas em contratos anteriores, outros grandes usuários de licenças perpétuas podem ganhar força em disputas semelhantes. Se a Broadcom prevalecer, a pressão para migração a modelos de assinatura tende a aumentar, especialmente entre organizações que ainda mantêm ambientes VMware extensos e difíceis de substituir no curto prazo.

Uma vulnerabilidade de vazamento de memória no Squid, popular servidor proxy de cache open source, permaneceu sem detecção por 29 anos e poderia expor requisições HTTP em texto claro, incluindo credenciais, tokens de sessão e outros dados sensíveis. A falha foi apelidada de Squidbleed e comparada ao Heartbleed por permitir a leitura indevida de dados da memória. O problema foi identificado por pesquisadores de segurança com apoio do Mythos Preview, da Anthropic, e reportado aos mantenedores do projeto Squid, que corrigiram o código no início de junho. A vulnerabilidade é rastreada como CVE-2026-47729 e foi corrigida no Squid v7.6, lançado em 8 de junho. O Squid é amplamente usado por grandes empresas, escolas, provedores de internet e outras organizações para armazenar em cache, filtrar e monitorar tráfego de rede. O pesquisador Lam Jun Rong, da Calif.io, afirmou ter se deparado com o proxy open source enquanto tentava se conectar à internet durante um voo. Segundo ele, a versão do Squid usada naquele avião tinha quase dez anos e estava vulnerável ao problema que viria a ser documentado. Rong relatou a falha aos mantenedores do Squid em abril. Após a publicação inicial do artigo original, também foi informado que outro pesquisador havia encontrado o bug antes: Pavel Kohout, da Aisle, identificou e reportou a vulnerabilidade em 4 de março, antes do relatório inicial da Calif.io. A Calif.io já havia chamado atenção anteriormente por pesquisas como a HTTP/2 Bomb, descoberta com apoio do agente Codex da OpenAI. A empresa também colaborou com a OpenAI na iniciativa Patch the Planet, anunciada recentemente, voltada à identificação e correção de vulnerabilidades em larga escala. De acordo com Rong, a Squidbleed pode vazar memória interna de todas as versões do Squid em configuração padrão, desde que duas condições estejam presentes. A primeira é que o Squid consiga ler e inspecionar o tráfego de rede, o que significa que ele precisa estar processando HTTP em texto claro ou operando em cenários nos quais termina conexões TLS. A segunda condição é que o proxy tenha permissão para alcançar um servidor FTP controlado por um atacante pela porta TCP 21. O FTP, ou File Transfer Protocol, é um protocolo antigo para transferência de arquivos entre sistemas. Embora tenha perdido espaço e seja considerado inadequado para muitos usos modernos, o Squid ainda oferece suporte a esse tipo de tráfego, e é justamente nesse ponto que a vulnerabilidade aparece. O bug está no parser de listagem de diretórios FTP do Squid. A falha foi introduzida no código open source em um commit de 1997, identificado como bb97dd37a, criado para oferecer suporte a servidores NetWare antigos. O NetWare foi um sistema operacional de rede popular nas décadas de 1980 e 1990, usado principalmente para serviços de arquivos e impressão em redes locais antes da ampla dominância de servidores Windows e Linux. Servidores FTP baseados em NetWare adicionavam espaços extras entre o timestamp de modificação e o nome do arquivo, diferentemente da maioria dos servidores FTP, que usavam apenas um espaço. O commit de 1997 tentou resolver essa diferença instruindo o código a ignorar os espaços adicionais. Para isso, usava um loop baseado em strchr para avançar o ponteiro enquanto encontrasse caracteres de espaço. O problema surge quando um servidor FTP controlado pelo atacante não fornece um nome de arquivo após o timestamp de modificação. Nesse cenário, o ponteiro copyFrom passa a apontar para o caractere NUL que marca o fim da string. Como a função strchr também trata esse terminador como parte da string pesquisada, ela retorna um ponteiro em vez de NULL. O loop, então, não para no momento correto e avança além do fim do buffer. Como consequência, a função xstrdup copia o conteúdo que aparece depois daquela região de memória e o devolve ao atacante como se fosse um nome de arquivo. O resultado é um heap overread, uma leitura indevida de memória heap, que pode revelar dados processados pelo proxy. O impacto é relevante porque o Squid pode estar manipulando requisições HTTP em texto claro. Essas requisições frequentemente incluem informações sensíveis, como senhas, chaves de API, tokens de sessão, cookies e outros dados enviados por aplicações ou usuários. Rong demonstrou a exploração em uma prova de conceito. A correção, segundo o pesquisador, é simples: verificar a presença do terminador nulo antes de chamar strchr. Apesar da simplicidade do patch, a falha permaneceu escondida desde a década de 1990, em uma área de compatibilidade com tecnologias legadas que ainda podia afetar implantações modernas. O caso mostra como trechos antigos de código, mantidos por compatibilidade com sistemas praticamente abandonados, podem permanecer ativos em softwares amplamente usados. Mesmo recursos pouco utilizados, como suporte a FTP em proxies modernos, podem manter superfícies de ataque relevantes quando expostos a tráfego controlado por invasores. A recomendação principal para administradores é atualizar o Squid para a versão v7.6 ou posterior, que inclui a correção para a CVE-2026-47729. Organizações que usam versões antigas devem revisar seus pacotes e confirmar se o patch foi aplicado pela distribuição ou pelo fornecedor responsável. Além da atualização, Rong recomenda desabilitar o suporte a FTP no Squid, exceto quando houver uma necessidade específica e incomum. Navegadores baseados em Chromium deixaram de oferecer suporte a FTP há anos, e, para a maioria das organizações, o volume de tráfego FTP legítimo tende a ser próximo de zero. Desativar esse recurso remove uma superfície de ataque inteira sem grande impacto operacional na maior parte dos ambientes. Em redes corporativas, escolares e de provedores, a medida também ajuda a reduzir o risco associado a protocolos antigos que continuam habilitados por padrão ou por herança de configuração. A Squidbleed reforça uma lição recorrente em segurança: vulnerabilidades críticas nem sempre estão em funcionalidades novas ou complexas. Às vezes, elas permanecem em caminhos de código criados décadas atrás, ligados a tecnologias legadas, protocolos obsoletos e comportamentos de compatibilidade que raramente recebem atenção.

A Cloudflare anunciou uma colaboração com os principais fabricantes de navegadores comerciais para desenvolver um protocolo voltado a ajudar sites a distinguir tráfego desejado de requisições consideradas abusivas, automatizadas ou inadequadas. A iniciativa envolve Google Chrome, Microsoft Edge e Mozilla Firefox, e tem como base os chamados Private Access Control Tokens, ou PACTs. Segundo a Cloudflare, os PACTs foram projetados como um mecanismo de preservação de privacidade para que sites consigam emitir tokens digitais capazes de indicar que determinada sessão de navegação pertence a um usuário humano ou a um bot com intenção legítima. A proposta é reduzir a necessidade de verificações repetidas de identidade, como CAPTCHAs, bloqueios agressivos e checagens invasivas, especialmente em um cenário de aumento do tráfego automatizado e de agentes baseados em inteligência artificial. Na prática, os PACTs funcionariam como uma espécie de resultado compartilhável e anônimo de uma verificação de confiança. Em vez de tentar apenas responder se o visitante é humano ou bot, a lógica se concentra em avaliar se aquele tráfego é desejável ou indesejável para o site. Essa distinção tem se tornado mais complexa à medida que bots legítimos, agentes autônomos e automações autorizadas passam a conviver com crawlers abusivos, scraping agressivo, fraude publicitária, ataques automatizados e tráfego malicioso. A ideia é permitir que sites com forte conhecimento sobre a “personhood” de um visitante emitam tokens anônimos que possam ser apresentados em outros sites. O termo, no entanto, ainda não está totalmente claro no contexto técnico da proposta. A noção de “personhood” parece incluir não apenas pessoas reais, mas também softwares autorizados a agir em nome de uma pessoa legítima para uma finalidade aprovada. Esse ponto é importante porque o protocolo pode acabar influenciando quem recebe ou não permissão para acessar determinados serviços sem atrito adicional. Ainda não está definido, por exemplo, quais critérios serão usados para determinar se uma sessão, navegador, comportamento ou sinal de rede é suficientemente confiável para receber um token. Discussões técnicas anteriores envolvendo desenvolvedores do Google e da Mozilla indicam que excluir determinados hardwares, plataformas ou user-agents não é o objetivo declarado. Dane Knecht, CTO da Cloudflare, afirmou que a forma como as pessoas interagem com a web está mudando e tende a envolver cada vez mais agentes autônomos. Para ele, com a disseminação do tráfego impulsionado por IA, as ferramentas atuais para lidar com esse uso são genéricas e pouco granulares. A colaboração, segundo Knecht, permitiria reduzir o atrito causado por protocolos de segurança para visitantes humanos e agentes, sem abrir mão da privacidade. A promessa de privacidade, porém, exige cautela. Os tokens PACT, ao que indica a proposta, não carregariam dados pessoais diretamente. Ainda assim, eles não resolvem outros problemas estruturais de rastreamento na web, como fingerprinting de navegadores, correlação de sessões, identificação por comportamento e uso combinado de sinais técnicos. Se implementados de forma inadequada, também podem introduzir novos riscos de privacidade, exclusão ou controle de acesso. O ponto central é que os PACTs criam uma camada adicional para classificar tráfego da internet como bem-vindo ou indesejado. Esse tipo de separação já ocorre amplamente por meio de firewalls, sistemas antibot, reputação de IP, WAFs e mecanismos de mitigação de abuso. A diferença é que, neste caso, a proposta busca padronizar parte dessa avaliação dentro do ecossistema de navegadores e sites, em um modelo que pode afetar a experiência de acesso em larga escala. A Mozilla, por meio de Bobby Holley, CTO do Firefox, afirmou que segue comprometida com a abertura e a privacidade dos usuários na web. Segundo ele, uma avalanche de tráfego automatizado tem levado sites a adotarem defesas mais bruscas, como paywalls, verificações de identidade, CAPTCHAs e rastreamento invasivo, apenas para tentar determinar se uma requisição vem de uma pessoa. Para operadores de sites, o apelo é evidente. Muitas empresas enfrentam custos crescentes para lidar com crawlers agressivos, scraping não autorizado, fraudes, automações abusivas e tráfego que consome infraestrutura sem gerar valor. Os PACTs podem oferecer uma forma menos intrusiva de identificar visitantes considerados genuínos e priorizar recursos para acessos mais relevantes. Ao mesmo tempo, a proposta levanta preocupações sobre o futuro da web aberta. Caso esses tokens se tornem uma espécie de credencial de acesso confiável, sites, navegadores e intermediários podem ganhar poder adicional para decidir quais visitantes, softwares ou agentes merecem tratamento preferencial. Isso pode criar barreiras para usuários com configurações menos comuns, navegadores alternativos, ferramentas de privacidade, automações legítimas ou projetos menores que não tenham capacidade de negociar reconhecimento com grandes plataformas. A Cloudflare apresenta a iniciativa como uma alternativa mais privada e menos incômoda aos modelos atuais de detecção de bots e verificação de usuários. Ainda assim, o equilíbrio entre combate a abusos, privacidade, interoperabilidade e abertura da web dependerá dos detalhes técnicos finais, dos critérios de emissão dos tokens e da forma como navegadores e sites implementarão o protocolo. O avanço dos PACTs também reflete uma mudança maior no tráfego da internet. Com agentes de IA, bots de indexação, automações corporativas e ferramentas de coleta de dados disputando espaço com usuários humanos, os mecanismos tradicionais de distinção entre pessoa e máquina se tornaram insuficientes. A nova disputa não é apenas identificar bots, mas determinar quais automações são aceitáveis, em quais condições e sob controle de quem.