Rubrik Code Guardian Expande o Project Hourglass, mas Suas Alegações de Segurança Enfrentam um Teste no Mundo Real

A Rubrik apresentou o Rubrik Code Guardian em 9 de outubro, expandindo o Project Hourglass para além dos controles de tempo de execução, com a inspeção de repositórios de código em busca de cadeias de ataque exploráveis. Segundo a empresa, o serviço em prévia privada usa um modelo da Anthropic em um ambiente de testes isolado. A iniciativa mira um conflito crescente no desenvolvimento de software: as ferramentas de programação com IA aumentam a produção, enquanto as equipes de segurança têm dificuldade para revisar esse resultado na mesma velocidade.

A expansão aproxima a Rubrik da segurança de aplicações, um mercado em que scanners já sinalizam código vulnerável antes da implantação. A promessa da Rubrik é diferente. Em vez de produzir outra longa lista de possíveis falhas, o Code Guardian foi projetado para conectar fraquezas entre arquivos, serviços, identidades e limites de nuvem. Em seguida, prioriza caminhos que poderiam causar danos relevantes aos negócios.

Essa abordagem também cria o principal teste para o Project Hourglass. Um sistema de IA pode analisar um grande repositório, mas as empresas ainda precisam de evidências de que suas descobertas são precisas, reproduzíveis e mais seguras do que o código que ele revisa. O Code Guardian não está disponível de forma geral, e a Rubrik afirma explicitamente que seus recursos e desempenho continuam sujeitos a mudanças.

Rubrik Code Guardian Leva o Project Hourglass à Base de Código

O Project Hourglass está evoluindo do controle de agentes de programação em tempo de execução para a análise do software que esses agentes ajudam a produzir.

A Rubrik lançou originalmente o Project Hourglass para ajudar integradores globais de sistemas a implantar o Rubrik Agent Cloud em torno do Claude Code, da Anthropic. Essa arquitetura inicial se concentrou no que um agente de programação com IA faz enquanto está em operação.

Seus controles incluíam proteções comportamentais, proteção para o contexto de prompts e o Agent Rewind. A Rubrik descreve o Agent Rewind como uma forma de reverter ações não intencionais realizadas por um agente. Essas funções tratam do risco operacional de permitir que agentes de software leiam arquivos, modifiquem repositórios, chamem ferramentas e interajam com sistemas corporativos.

O Rubrik Code Guardian adiciona uma segunda camada. Ele examina uma cópia clonada do repositório de código-fonte de um cliente em um ambiente air-gapped, o que significa que a cópia fica isolada dos sistemas de produção e das redes externas. A Rubrik afirma que esse desenho permite que as equipes realizem testes de segurança agressivos sem expor aplicações em produção ou código-fonte sensível a riscos operacionais desnecessários.

Segundo o lançamento do Code Guardian da empresa, o sistema usa o Claude Mythos 5 por meio de uma estrutura especializada de segurança. O modelo foi concebido para analisar cenários de ameaça em várias etapas, em vez de inspecionar cada arquivo como uma unidade independente.

Essa distinção importa porque vulnerabilidades prejudiciais frequentemente surgem de combinações de fraquezas que, isoladamente, parecem modestas. Um serviço pode aceitar entradas inseguras, uma função de identidade pode ter permissões excessivas e um recurso de nuvem pode estar acessível por uma rota negligenciada. Uma ferramenta convencional pode reportar cada condição separadamente sem mostrar como um invasor as conectaria.

A Rubrik afirma que o Code Guardian analisará arquivos-fonte, serviços, funções de identidade e perímetros de nuvem para identificar essas cadeias. Em seguida, testará se um caminho suspeito é realmente explorável e classificará a descoberta de acordo com sua importância para os negócios.

O objetivo não é simplesmente encontrar mais alertas. É reduzir a fadiga de alertas ao ajudar as equipes de engenharia a determinar quais avisos merecem atenção imediata.

Isso representa uma mudança importante no posicionamento de segurança da Rubrik. A empresa tradicionalmente enfatiza resiliência de dados, backups protegidos e recuperação após ataques. O Code Guardian a leva para uma fase mais cedo do ciclo de vida do software, antes que uma aplicação vulnerável chegue à produção.

O Project Hourglass também está se tornando uma aliança de entrega mais ampla. AHEAD, Trace3 e World Wide Technology juntaram-se aos participantes existentes Cognizant, Deloitte, LTM, HCLTech, NTT DATA e Wipro. Esses parceiros podem ajudar empresas a avaliar arquiteturas, executar testes controlados e incorporar a tecnologia aos processos existentes de desenvolvimento e segurança.

A Rubrik anunciou a expansão em sua GSI Summit, em Goa, na Índia. A localização geográfica é menos importante que o modelo de entrega. Grandes empresas frequentemente compram programas de segurança por meio de integradores de sistemas, não por testes isolados de produtos conduzidos por uma única equipe de desenvolvimento.

Portanto, os parceiros poderão determinar se o Rubrik Code Guardian se tornará um controle operacional ou permanecerá como uma demonstração interessante em prévia privada. Eles precisarão conectar seus resultados a sistemas de tickets, pipelines de software, controles de identidade e ferramentas existentes de segurança de aplicações.

A designação de prévia privada impõe um limite claro ao anúncio. A Rubrik afirma que o serviço está sendo oferecido a parceiros de design selecionados em uma base “as is”. Ele não está disponível de forma geral, e a empresa não garante que todos os recursos descritos chegarão a uma versão comercial.

Essa ressalva é central para a história. A Rubrik delineou uma arquitetura ambiciosa, mas os clientes ainda não podem avaliá-la por meio de dados amplos de implantação, benchmarks independentes ou uma versão estável em produção.

Por Que a Segurança de Código com IA Está se Tornando um Gargalo Empresarial

A pressão vem de uma crescente lacuna de velocidade entre a criação automatizada de código e a revisão humana de segurança.

Assistentes de programação com IA podem gerar recursos, testes, arquivos de configuração e código de infraestrutura em minutos. Essa velocidade altera a economia do desenvolvimento, mas não elimina a necessidade de revisão. Em vez disso, ela pode aumentar a quantidade de código que as equipes de segurança precisam avaliar antes de uma versão ser lançada.

O risco não é que toda função gerada por IA contenha uma vulnerabilidade. O problema é que um código aparentemente plausível pode passar por uma revisão visual rápida enquanto preserva premissas inseguras sobre permissões, entradas, dependências ou limites de sistema.

Uma avaliação da Veracode de 2025 relatou que os modelos testados introduziram uma vulnerabilidade detectável do OWASP Top 10 em 45% dos resultados de suas tarefas. O estudo de segurança de código da empresa usou tarefas controladas de programação, nas quais as implementações podiam seguir padrões seguros ou inseguros.

Esse número não deve ser tratado como a taxa de vulnerabilidade de todo software em produção. Tarefas controladas diferem de repositórios empresariais mantidos, e os resultados dependem da linguagem, do prompt, do modelo e do método de teste. Ainda assim, o estudo ilustra por que a correção funcional não pode substituir a validação de segurança.

O risco também vai além do código-fonte gerado. Agentes de programação podem acessar repositórios, terminais, rastreadores de problemas, gerenciadores de pacotes e ferramentas de implantação. Uma instrução maliciosa incorporada a conteúdo recuperado pode redirecionar um agente com privilégios excessivos, enquanto um erro comum pode se propagar por muitos arquivos.

A OWASP descreve agência excessiva como uma condição em que um modelo recebe funcionalidades, permissões ou autonomia desnecessárias. Suas orientações sobre agência excessiva recomendam limitar o acesso a ferramentas, minimizar permissões, exigir aprovação para ações consequentes e validar resultados antes da execução.

Esses controles se concentram no que um agente tem permissão para fazer. O Code Guardian aborda uma questão relacionada, mas distinta: quais fraquezas de segurança existem na base de código depois que humanos e agentes contribuíram para ela?

A Rubrik cita sua própria pesquisa Zero Labs para explicar a urgência. A empresa afirma que 86% dos líderes de cibersegurança e TI entrevistados esperam que a adoção de agentes de IA ultrapasse as proteções de segurança de suas organizações dentro de um ano. Como esse número vem de uma pesquisa da Rubrik, os leitores devem tratá-lo como evidência da preocupação dos clientes, e não como prova independente da eficácia do Code Guardian.

A preocupação mais ampla está bem estabelecida. Agentes autônomos podem operar com identidades de máquina, credenciais e permissões de ferramentas. Eles também podem executar sequências de ações mais rápido do que uma pessoa consegue revisar cada etapa.

Isso faz do repositório de software apenas uma parte da superfície de ataque. As equipes de segurança precisam proteger o contexto do modelo, as permissões do agente, o código gerado, o pipeline de implantação e os dados afetados por uma ação malsucedida.

O Project Hourglass agora tenta cobrir várias dessas camadas. O Rubrik Agent Cloud se concentra no comportamento e na recuperação de agentes. O Code Guardian se concentra na análise de repositórios e na descoberta de cadeias de ataque. Os produtos existentes de resiliência da Rubrik fornecem a camada de recuperação caso a prevenção e os controles de tempo de execução falhem.

Esse posicionamento de ponta a ponta é comercialmente atraente, mas também cria questões de integração. As empresas já usam testes estáticos de segurança de aplicações, análise de composição de software, detecção de segredos, ferramentas de postura de segurança na nuvem e testes manuais de penetração.

O Code Guardian precisa demonstrar que contribui com algo que esses produtos não conseguem fornecer de forma eficiente. Encontrar uma fraqueza hipotética não é suficiente. O serviço precisa explicar como um invasor chega até ela, quais ativos ficam expostos e por que a descoberta deve ter prioridade sobre trabalhos de correção concorrentes.

É nesse ponto que a segurança de código com IA se torna um problema de priorização. Um scanner que dobra o número de alertas sem melhorar as decisões pode tornar um programa de segurança mais lento. Um sistema de raciocínio eficaz deve reduzir a incerteza, não apenas produzir relatórios mais longos.

Para líderes de engenharia, a lição imediata é prática. A geração mais rápida de código exige controles mais fortes nos níveis de repositório, identidade e tempo de execução. As equipes também precisam de registros duradouros de decisões arquiteturais, premissas de ameaça e trabalho de correção.

Uma base de conhecimento de engenharia pesquisável pode preservar esse contexto entre as equipes de segurança, desenvolvimento e operações. Ela não substitui os testes de código, mas ajuda os revisores a entender por que componentes sensíveis foram projetados de determinada maneira.

Project Hourglass Coloca o Raciocínio sobre Cadeias de Ataque Contra o Volume de Alertas

A principal aposta da Rubrik é que a IA pode priorizar caminhos de ataque realistas melhor do que ferramentas que examinam fraquezas de forma isolada.

A análise estática tradicional avalia o código-fonte sem executar a aplicação. Ela pode identificar padrões inseguros conhecidos, como entradas não sanitizadas, chamadas de função perigosas ou escolhas criptográficas fracas. A análise de composição de software examina pacotes externos e vulnerabilidades conhecidas em dependências.

Esses métodos continuam essenciais porque são repetíveis, conhecidos e adequados a pipelines automatizados de desenvolvimento. No entanto, podem gerar falsos positivos ou descobertas isoladas que não têm contexto de negócio.

Um aviso em um componente de teste inacessível não apresenta o mesmo risco que uma falha explorável em um serviço de autenticação exposto à internet. Ainda assim, ambos podem aparecer na mesma fila, a menos que uma pessoa ou outro sistema reconstrua a arquitetura ao redor.

O Rubrik Code Guardian foi projetado para realizar uma parcela maior dessa reconstrução. A empresa afirma que seu modelo pode analisar arquivos e serviços, incluir relações de identidade e considerar limites de nuvem. O resultado deve descrever uma cadeia de ataque, em vez de uma falha desconectada.

Considere uma aplicação empresarial hipotética com três fragilidades. Uma API aceita um parâmetro validado de forma inadequada. Uma identidade de serviço pode ler um bucket de armazenamento sensível. Um worker em segundo plano confia em mensagens vindas da API.

Um scanner em nível de arquivo poderia gerar três tickets. A análise de cadeia de ataque perguntaria se um invasor pode usar a falha no parâmetro para controlar uma mensagem, acionar o worker, herdar a identidade de serviço e alcançar o bucket de armazenamento. Se essa sequência funcionar dentro da cópia isolada, a equipe de segurança ganha uma prioridade de remediação mais clara.

Esse é o mecanismo por trás da alegação da Rubrik sobre impacto nos negócios. O modelo não é valioso apenas porque consegue ler mais código. Ele se torna útil se puder distinguir uma cadeia plausível de uma combinação teórica e explicar sua conclusão a revisores humanos.

A Anthropic já apresentou a descoberta de vulnerabilidades assistida por modelos como um uso defensivo de modelos avançados de programação. Em fevereiro de 2026, a empresa afirmou que o Claude Code Security havia encontrado mais de 500 vulnerabilidades em projetos open source de produção. Seu anúncio de pesquisa em segurança descreveu um processo que combina análise por modelos com revisão humana e divulgação coordenada.

A Anthropic também publicou um painel de vulnerabilidades que registra descobertas após triagem externa e revisão pelos mantenedores. Esse fluxo de trabalho é importante porque a suspeita inicial de um modelo não equivale a uma vulnerabilidade confirmada.

A Rubrik está levando essa capacidade geral para um ambiente empresarial controlado. Em vez de examinar repositórios open source públicos, o Code Guardian foi projetado para analisar código privado de clientes por meio de parceiros participantes.

O clone isolado por air gap oferece duas vantagens potenciais. Primeiro, pode reduzir a chance de que código proprietário vaze para um serviço externo ou alcance um sistema de produção ativo. Segundo, dá ao processo de testes espaço para investigar agressivamente sem afetar clientes ou operações.

O isolamento não resolve todas as questões de segurança. As empresas ainda precisarão de detalhes sobre como as cópias dos repositórios são criadas, onde ocorre a inferência do modelo, como os resultados são retidos e quais profissionais dos parceiros podem acessar as descobertas.

O termo “air-gapped” também pode abranger diferentes arranjos técnicos. Um ambiente fisicamente separado, uma nuvem privada com fortes restrições e uma rede logicamente isolada não oferecem as mesmas garantias. O anúncio público da Rubrik não fornece detalhes de arquitetura suficientes para comparar esses modelos.

O teste competitivo se concentrará na qualidade das evidências. Fornecedores consolidados de segurança de aplicações podem acrescentar explicações de IA e classificação contextual aos seus scanners existentes. Fornecedores de segurança em nuvem podem correlacionar identidades, serviços e ativos alcançáveis usando telemetria de produção.

A Rubrik traz ativos diferentes. Ela mantém relacionamentos ligados a dados empresariais protegidos, fluxos de recuperação e resiliência cibernética. O Project Hourglass também lhe oferece parceiros integradores de sistemas capazes de unir análise de código a decisões mais amplas de infraestrutura.

A versão mais forte da estratégia da Rubrik combina esses ativos. O Code Guardian identificaria a cadeia, o Agent Cloud restringiria o comportamento dos agentes, e os controles de recuperação da Rubrik restaurariam código ou dados afetados após um incidente.

A versão mais fraca cria outro console com alertas sobrepostos. Os clientes da prévia privada precisarão determinar qual resultado estão vendo.

A Parte Difícil É Validar o Revisor de IA

Um sistema de IA que revisa código assistido por IA cria um ciclo de verificação que não pode ser resolvido apenas pela confiança do modelo.

A Rubrik afirma que o Code Guardian verificará as descobertas quanto à explorabilidade real. Essa é uma alegação mais exigente do que identificar padrões suspeitos. A explorabilidade depende de configuração, estado de implantação, entradas alcançáveis, permissões de identidade e controles ambientais.

Um repositório clonado pode não conter todos os fatos necessários para reproduzir o ambiente de produção. As configurações de infraestrutura podem estar em sistemas separados. As identidades em tempo de execução podem diferir das funções declaradas. As políticas de rede podem mudar depois que o clone é criado.

Isso significa que o caminho de ataque do sistema pode ser logicamente coerente e ainda assim impossível em produção. O problema oposto também existe. Um teste centrado no repositório pode deixar passar um caminho perigoso criado por divergência em tempo de execução, uma integração não documentada ou uma credencial comprometida.

Portanto, os testes de prévia privada devem medir mais do que o número de problemas encontrados. Eles devem acompanhar cadeias exploráveis confirmadas, descobertas rejeitadas, alertas duplicados, tempo até a validação, tempo de remediação e falhas que o sistema não detectou.

A comparação independente será especialmente importante. Um parceiro de design deve executar o Code Guardian ao lado de seus scanners existentes e de seu processo de testes de penetração. Isso cria uma base para determinar se o serviço descobre riscos exclusivos ou reembala descobertas conhecidas.

As equipes de segurança também precisam de evidências reproduzíveis. Um relatório útil deve identificar os caminhos de código relevantes, as permissões necessárias, as pré-condições, os ativos afetados e as etapas usadas para validar a cadeia. Os revisores precisam conseguir contestar o raciocínio do modelo sem aceitar uma pontuação de risco de caixa-preta.

A Rubrik não publicou resultados de benchmark para taxas de falsos positivos, taxas de falsos negativos, cobertura de repositórios, tempo de análise ou classes de vulnerabilidades. Seu anúncio também não revela como o desempenho muda em monorepositórios grandes ou linguagens de programação pouco comuns.

Essas omissões são razoáveis para uma prévia inicial, mas limitam o que as empresas podem concluir. O Code Guardian é um controle de segurança proposto, não um substituto validado de forma independente para os testes existentes de segurança de aplicações.

O modelo subjacente cria outro risco de concentração. A Rubrik depende da tecnologia da Anthropic para inspecionar código que pode ter sido criado com Claude Code ou outros assistentes de IA. Um modelo capaz ainda pode compartilhar pontos cegos com os sistemas que geraram o código.

A diversidade de modelos não resolve automaticamente esse problema, mas métodos independentes de teste podem ajudar. Scanners determinísticos, testadores humanos de penetração, observações em tempo de execução e modelos distintos podem contestar diferentes pressupostos.

A estrutura mais ampla de segurança de agentes da OWASP trata sistemas agênticos como combinações de modelos, ferramentas, identidades, memória e serviços externos. Essa perspectiva desaconselha depender de um único revisor automatizado.

Há também uma questão de governança. Um modelo só pode sinalizar um caminho como crítico para os negócios se receber informações precisas sobre sua importância empresarial. O repositório sozinho pode não revelar qual serviço processa dados regulados, atende um grande cliente ou controla um fluxo operacional crítico.

Os parceiros precisarão fornecer esse contexto. Fazer isso exige cooperação entre responsáveis por aplicações, equipes de segurança, administradores de nuvem, equipes de identidade e líderes de negócios.

Integradores de sistemas podem coordenar esses grupos, o que ajuda a explicar a estratégia da Rubrik de priorizar alianças. No entanto, a entrega liderada por parceiros pode produzir resultados desiguais se as práticas de implementação variarem. Certificação e suporte direto de engenharia podem reduzir essa variação, mas a Rubrik ainda não publicou dados de resultados operacionais.

O posicionamento da empresa em recuperação também merece análise. A recuperação instantânea da base de código pode restaurar arquivos conhecidos como bons após uma alteração não intencional, mas restaurar código não reverte automaticamente todas as consequências.

Um agente comprometido pode expor um segredo, acionar uma transação externa, alterar um sistema de terceiros ou modificar dados de produção. Esses efeitos exigem resposta a incidentes além da reversão do repositório.

Portanto, o Project Hourglass deve ser avaliado como um controle em camadas, não como uma garantia. Barreiras de proteção podem reduzir ações perigosas. Testes de código podem encontrar caminhos vulneráveis. A recuperação pode limitar danos. Nenhum deles elimina a necessidade de acesso com privilégio mínimo, aprovação humana, práticas de desenvolvimento seguro e planejamento de incidentes.

Esse é o trade-off central. O raciocínio de IA pode examinar relações que ferramentas baseadas em regras têm dificuldade de conectar, mas o próprio raciocínio exige validação. As empresas ganham velocidade apenas quando o ônus de verificação se torna menor que o problema automatizado.

Rubrik Code Guardian Agora Tem Três Testes a Superar

As próximas evidências devem vir de resultados de implantação, comparação independente e uma arquitetura de produção claramente definida.

O primeiro sinal é a qualidade dos resultados dos parceiros de design. AHEAD, Trace3, WWT e os participantes atuais do Project Hourglass têm acesso a empresas com repositórios complexos e programas de segurança maduros.

Os resultados mais úteis não serão declarações promocionais sobre encontrar “mais” riscos. Os compradores precisam de exemplos anonimizados que mostrem quais cadeias de ataque as ferramentas existentes não detectaram, como o Code Guardian as validou e com que rapidez as equipes concluíram a remediação.

Descobertas confirmadas fortaleceriam o argumento da Rubrik de que o raciocínio baseado em modelos melhora a priorização. Taxas elevadas de rejeição ou grandes cargas de revisão o enfraqueceriam.

O segundo sinal é o caminho da prévia privada à disponibilidade geral. A versão atual da Rubrik inclui um aviso explícito de que o Code Guardian pode mudar, chegar mais tarde ou nunca se tornar amplamente disponível.

Uma versão de produção deve esclarecer os idiomas suportados, limites de tamanho dos repositórios, modelos de implantação, tratamento de dados, políticas de atualização de modelos, controles de retenção e integração com pipelines de desenvolvimento. Também deve explicar como os clientes auditam ações realizadas durante os testes.

A disponibilidade geral, por si só, não provaria eficácia. No entanto, documentação estável e compromissos contratuais de segurança mostrariam que a Rubrik está preparada para ir além de um experimento controlado.

O terceiro sinal é a resposta competitiva. Fornecedores de segurança de aplicações e segurança em nuvem já possuem scanners de código, bancos de dados de vulnerabilidades, inteligência de dependências e contexto de produção. Eles têm incentivos claros para adicionar análise agêntica de cadeias de ataque.

Se esses fornecedores produzirem raciocínio comparável por meio de ferramentas que os clientes já usam, a Rubrik precisará se diferenciar por recuperação, isolamento ou entrega por parceiros. Se os concorrentes tiverem dificuldade para correlacionar código com identidade e impacto nos negócios, o Project Hourglass ganha uma oportunidade mais forte.

Os próprios produtos de segurança da Anthropic são outro ponto de referência. O Claude Code Security demonstra que o fornecedor do modelo vê a descoberta de vulnerabilidades como uma categoria direta de produto. A Rubrik precisa explicar como seu ambiente de segurança, contexto empresarial e arquitetura de recuperação agregam valor além do acesso ao modelo subjacente.

Desenvolvedores e compradores empresariais devem observar esses sinais antes de tratar o Rubrik Code Guardian como um controle consolidado. O anúncio identifica um problema real e propõe um mecanismo crível, mas as evidências continuam preliminares.

Para equipes de desenvolvimento, a resposta prática não deve esperar pelo lançamento de um único fornecedor. Inventariem onde os agentes de programação operam, restrinjam suas credenciais, registrem alterações relevantes e preservem a aprovação humana para ações sensíveis. Continuem usando scanners determinísticos e testes independentes mesmo quando houver um revisor de IA disponível.

Os líderes de segurança também devem fazer uma pergunta mais difícil: uma nova ferramenta reduz o caminho entre a descoberta e a remediação verificada? Um sistema que descobre cadeias sofisticadas, mas sobrecarrega os revisores, não resolve o gargalo operacional.

O Rubrik Code Guardian será relevante se o Project Hourglass transformar o raciocínio de modelos em evidências repetíveis sobre as quais engenheiros possam agir. Sua prévia privada é o início desse teste, não o resultado. Nos próximos meses, os compradores devem buscar cadeias de ataque validadas, taxas de erro transparentes e uma arquitetura de produção que proteja o código inspecionado.