Garantia independente de liberação para atualizações de endpoint
O Kestrel é um plano de controle independente que se posiciona entre seus fornecedores de software e sua frota de produção. Ele intercepta a atualização de um fornecedor antes que ela atinja qualquer endpoint, comprova deterministicamente a assinatura de falha da classe CrowdStrike, controla o rollout com políticas que um modelo consultivo não pode sobrepor e exporta um registro de evidência assinado que um conselho diretor e um regulador podem reexecutar. O que você pode assistir aqui é uma demonstração sobre uma frota sintética de 8.500 endpoints, e não uma esteira em produção.
20 → 21
A divergência na contagem de campos que derrubou a frota
Causa raiz da CrowdStrike, RCA de agosto de 2024
12/12
Decisões corretas de liberação
Em um conjunto de fixtures rotulado de 12 itens, determinístico
0/6
Falsos bloqueios nas atualizações benignas
6 fixtures benignos no mesmo conjunto
A frota, o fornecedor SentinelEdge e seu agente de classe Falcon são sintéticos. O cenário C-00000291 reproduz a assinatura de falha documentada da CrowdStrike de 19 de julho, e não os sistemas de nenhum cliente real.
Em 19 de julho de 2024, um único arquivo de canal do Rapid Response Content da CrowdStrike travou milhões de máquinas Windows em menos de 90 minutos. A causa raiz publicada não foi uma invasão hacker nem um modelo defeituoso. Foi uma incompatibilidade de schema: o validador em nuvem aprovou uma atualização de 21 campos enquanto o interpretador de kernel ainda esperava 20, gerando uma leitura fora dos limites e uma BSOD instantânea. Como a falha ocorria logo no início da inicialização, o agente que falhava nunca conseguia reinicializar para receber um comando de rollback, fazendo com que a recuperação exigisse consertar as máquinas manualmente, uma a uma, em Safe Mode. (CrowdStrike Root Cause Analysis, agosto de 2024.)
O validador que aprovou a atualização pertencia ao mesmo fornecedor que a enviou. Uma esteira que se policia não conta com nenhuma parte independente inspecionando o payload a caminho da sua frota de produção.
Ferramentas de SBOM e SCA cobrem dependências de código aberto, e não os arquivos proprietários de canal de um fornecedor. A segurança de conteúdo monitora prompts e a identidade monitora o acesso. Ninguém lê a atualização do próprio fornecedor no momento da entrada.
Uma empresa com 5.000 endpoints executa de 8 a 12 agentes com privilégios de kernel de fornecedores que ela não controla, cada um capaz de enviar um arquivo de canal diretamente para o ring 0. Comitês consultivos de mudança aprovam atualizações de fornecedores com base na confiança, porque não há nada entre essa esteira e a produção.
Uma equipe consultiva raciocina sobre cada atualização, mas não pode tomar a decisão. O Kestrel direciona cada pacote por uma esteira que o normaliza, ancora-o contra a frota, permite que a equipe debata e, em seguida, entrega a decisão a um verificador determinístico e a um gate de políticas escrito em Python puro. Um agente consultivo inclinado à liberação nunca pode anular uma constatação determinística crítica, pois a confiança em um produto de governança não pode depender de que o próprio elemento governado ateste a si mesmo.
01 / SCHEMA-COMPATIBILITY DIFF
A verificação compara a contagem de campos declarada de uma atualização com o que o interpretador de kernel implantado espera. Uma atualização de 21 campos chegando a um interpretador de 20 campos é a causa raiz literal do 19 de julho, detectada por aritmética antes que qualquer endpoint reinicie.
02 / SANDBOX REBOOT-CYCLE MODEL
Uma sandbox simulada modela o comportamento de BSOD e boot loop por perfil de SO ao longo de ciclos de reinicialização, a partir de um sinal de compatibilidade de drivers independente da verificação de schema. Quando ela relata 5 de 6 perfis falhando, isso corrobora o achado do schema em vez de apenas repeti-lo.
03 / BLAST-RADIUS AND CANARY MATH
A verificação calcula a primeira onda em relação à sua política de canary máximo. Um rollout para 100% da frota de uma só vez, ou um sem plano de canary declarado, viola a política e é recusado, enquanto uma primeira onda escalonada de 1.2% fica em conformidade.
04 / DEAD-AGENT AND CONFLICT DETECTOR
A verificação sinaliza um agente de pré-inicialização que é ele próprio o receptor do rollback, de modo que uma falha deixaria o endpoint órfão e forçaria o uso de Safe Mode máquina por máquina, além de sinalizar dois fornecedores modificando o mesmo callback de kernel na mesma janela. Essa foi a falha que transformou o 19 de julho em uma recuperação manual.
A equipe consultiva é construída sobre o Pydantic AI: um normalizador, um interpretador de sandbox e dois críticos opostos — um argumentando que a atualização é segura para envio e outro argumentando que ela causará falhas. Esse par adversário testa o veredito por ambos os lados (red-teaming) antes que o código decida. O veredito em si é uma de quatro disposições: ALLOW para liberar para o canary, HOLD para encaminhar para revisão, BLOCK para recusar o rollout e ABSTAIN para encaminhar um payload indecifrável para um humano, porque o gate nunca dá sinal verde para o que não pode comprovar.
A equipe é neutra em relação a provedores, com Anthropic, OpenAI ou Gemini selecionáveis por meio de uma variável de ambiente e o modelo padrão claude-opus-4-8, funcionando totalmente offline sem chave de API através de um fallback consultivo determinístico. Em todos os modos, o verificador e o gate permanecem inalterados e continuam gerando o veredito completo e o registro de evidências. O verificador e o gate situam-se deliberadamente fora do framework de agentes.
A demonstração governa uma frota sintética, Acme Financial: Global Endpoint Fleet, de 8.500 endpoints distribuídos em 6 perfis de SO e 8 agentes privilegiados, sendo 5 deles em ring-0. O fornecedor SentinelEdge envia duas atualizações de Rapid Response Content. Veja o que o Kestrel faz com cada uma.
Uma aba View Benchmark executa o conjunto completo de fixtures rotulados e computa um placar. Leia cada número com o escopo que a demonstração mantém associado a ele. Trata-se de resultados de cobertura de governança em um conjunto fixo, não de uma garantia em ambiente aberto, e eles são determinísticos, de modo que as mesmas entradas produzem as mesmas decisões a cada execução.
| Pergunta | O que o Kestrel faz nesta demonstração | O que fica fora da demonstração |
|---|---|---|
| Precisão do gate | 12 de 12 decisões corretas em um conjunto rotulado de fixtures de 12 itens, incluindo 6 benignos, vários bloqueios e retenções, e 1 abstenção honesta. | Uma garantia universal de que toda atualização defeituosa seja interceptada. O resultado refere-se a um conjunto fixo, não a um ambiente aberto. |
| Tempo de inatividade evitado | Uma estimativa de $13.3M em todo o conjunto, sendo $5M na atualização bloqueada de classe CrowdStrike, a partir de um modelo exibido na tela de parcela afetada vezes taxa por hora vezes piso de uma hora. | Dinheiro economizado por um cliente real ou retorno garantido. Trata-se de uma estimativa sintética sobre fixtures sintéticos. |
| Cobertura de sandbox | Um modelo determinístico de resultados por perfil em 5 de 6 perfis da frota, com hosts legados Server 2012 sinalizados e excluídos em vez de presumidos como seguros. | Uma fazenda real de sandboxes em VMs Windows. A matriz aqui é um modelo simulado, não VMs ativas, e a fazenda está no roadmap. |
| Integrações | Lê um feed de canal de atualização de fornecedor e roteia para uma fila de ITSM como stubs de fixture, e assina o registro com um SHA-256 local. | ITSM bidirecional ativo, feed real de fornecedor e assinatura por PKI corporativa. Essas são integrações simuladas na demonstração. |
O Kestrel não é um EDR e não compete com Falcon, Defender ou Cortex XDR. Ele não varre endpoints, não aplica patches nem remove malware, e nunca requer acesso ao kernel. A matriz de sandbox é um modelo determinístico de resultados por perfil, e não VMs Windows reais; a assinatura de evidências é um SHA-256 local, e não PKI corporativa; e o feed de canal de atualização do fornecedor e a fila de ITSM são stubs de fixture, e não conectores ativos. Acme Financial, SentinelEdge e o agente de classe Falcon são fictícios, e nenhum fornecedor real é cliente, parceiro ou endossante da Veriprajna. Os valores 12 de 12 e 0 de 6 são resultados em um conjunto rotulado fixo de 12 fixtures, e as cifras em dólares são o modelo de estimativa de tempo de inatividade evitado da própria demonstração, não constituindo certificação, assessoria jurídica ou retorno garantido. Uma fazenda real de sandboxes em VM, ITSM bidirecional ativo, auditoria de responsabilidade em contratos de fornecedores, verificação formal de kernel e blindagem para incorporação no local estão no roadmap e ainda não foram construídos. Esta página é explicativa, contendo vídeo, capturas de tela, detalhamento do mecanismo e respostas, e não uma aplicação operável diretamente daqui.
Não. O Kestrel não é um EDR e nunca requer acesso ao kernel. Ele atua uma camada acima dos seus agentes de EDR, DLP, criptografia e aplicação de patches, governando o que esses fornecedores têm permissão para enviar para a sua frota de produção. Ele não varre endpoints, não aplica patches nem remove malware. Ele analisa a atualização proposta por um fornecedor, comprova se é segura para liberação e controla o rollout por meio de políticas — uma função que nenhum dos seus agentes de kernel executa em relação ao fornecedor acima deles.
As empresas que ficaram fora do ar em 19 de julho de 2024 não eram donas da esteira do fornecedor, mas arcaram com as consequências. A lacuna estrutural é que nenhuma camada independente se interpõe entre a esteira de atualização do fornecedor e seus endpoints de produção: o validador do fornecedor se policia sozinho, ferramentas de SBOM e SCA cobrem dependências de código aberto em vez de arquivos proprietários de canal, e comitês de mudança tendem a aprovar atualizações de fornecedores sem questionar. O Kestrel é a camada que faltava. Ele analisa o payload real que o fornecedor está prestes a enviar e decide, em código controlado por você, se ele chega à produção.
A equipe consultiva apenas raciocina sobre a atualização. O veredito é definido por um verificador determinístico e um gate de políticas escrito em Python puro, com aritmética recálculável que um regulador pode reexecutar, de modo que um agente consultivo inclinado à liberação nunca possa anular uma constatação determinística crítica. Como a decisão é código e não um autorrelato de modelo, a mesma entrada produz a mesma decisão a cada execução e não apresenta variância de modelo. A demonstração também opera de forma totalmente offline, sem chave de API, por meio de um fallback consultivo determinístico, e o gate e seu veredito permanecem inalterados nesse modo.
Trata-se de um gate, e não de um tutor que bloqueia tudo. Na demonstração, uma atualização benigna de Rapid Response Content do mesmo fornecedor é aprovada nas verificações e liberada para um anel canary de 1.2% em segundos, enquanto a perigosa é bloqueada. Nos 6 fixtures benignos do conjunto rotulado, houve 0 falsos bloqueios. O Kestrel é decisivo apenas no momento de perigo, e hosts legados que ele não consegue modelar são sinalizados e excluídos, em vez de presumidos como seguros.
Com um clique, exporta-se um registro de evidências assinado como uma visualização em HTML e um arquivo JSON contendo um hash de conteúdo SHA-256, o veredito, as comprovações determinísticas, os resultados da sandbox por perfil, os vereditos dos agentes consultivos com seus IDs de modelo, as regras de políticas disparadas e um rastreamento de avaliação passo a passo com a latência de cada etapa. O registro também traz o enquadramento do EU Cyber Resilience Act, divulgações da SEC e o precedente da Delta, adequando-se a discussões regulatórias. A assinatura é um SHA-256 local para integridade, não uma PKI corporativa, e o registro foi desenvolvido para se alinhar a essas necessidades regulatórias sem se constituir em uma certificação.
Não. A equipe consultiva é construída sobre o Pydantic AI e é neutra em relação a provedores, com Anthropic, OpenAI ou Gemini selecionáveis por meio de uma variável de ambiente e o modelo padrão claude-opus-4-8 acessado por uma ponte local ou pela API da Anthropic. Ela também funciona totalmente offline, sem chave de API, por meio de um fallback consultivo determinístico. Em todos os modos, o verificador determinístico e o gate de políticas permanecem inalterados e continuam gerando o veredito completo e o registro de evidências, pois a garantia nunca dependeu das propriedades do modelo.
A pesquisa por trás desta demonstração — a arquitetura, o design de verificação e a estrutura corporativa.
Somos uma equipe de engenharia de IA, não um fornecedor de middleware. Construímos a camada independente que decide em código o que um fornecedor tem permissão para enviar à sua frota de produção e entrega o comprovante a você.
Uma primeira conversa produtiva é prática: os agentes com privilégios de kernel que sua frota executa, as vias de atualização de fornecedores que chegam à produção sem verificação independente e a política de rollout e canary que você deseja aplicar. Podemos estruturar as verificações determinísticas, o gate de políticas e o formato de registro de evidências em conjunto com suas equipes de endpoint e conformidade.
