k8s-aibom encontra a IA escondida no cluster: o que ainda escapa

É fácil aprovar uma arquitetura de IA no diagrama e perder o que realmente entrou em produção. Um container muda, um modelo aparece num argumento de linha de comando e, quando alguém pergunta onde a IA está rodando, começa a caça ao inventário. O Google abriu uma ferramenta para observar esse estado vivo no Kubernetes. Ela não resolve tudo: além de registrar o que reconhece, admite o que não conseguiu identificar. Hoje também há identidade delegada para agentes e provas formais em criptografia com Rust. Outra mudança obriga uma migração para passkeys. E um experimento da Meta levou a política de escalonamento para fora do kernel.

k8s-aibom procura o que já está rodando no cluster

O Google abriu o código do k8s-aibom. O controlador procura sinais de uso de IA. Para isso, observa recursos de workload de um cluster Kubernetes. A diferença para um inventário feito durante o build é o momento da fotografia. Ele examina o estado em execução, onde imagens trocadas, configurações e serviços instalados fora do caminho esperado já podem ter mudado a paisagem.

A ferramenta roda como um único Deployment sem privilégios. Ela inspeciona imagens de container, variáveis de ambiente e argumentos. Nesses dados, procura runtimes e frameworks. Também identifica bancos vetoriais. O resultado é um documento determinístico no formato CycloneDX 1.6, voltado a componentes de aprendizado de máquina.

Para times de plataforma e segurança, a vantagem é procurar “shadow AI” sem injetar contêineres auxiliares, os chamados sidecars. Também não é preciso alterar a especificação dos pods. A instalação dispensa DaemonSets privilegiados. Também não depende de eBPF para observar o sistema. O controlador complementa scanners de build, mas não os substitui. O Google chama os documentos de adequados para auditoria e descreve registros imutáveis no armazenamento. São propriedades declaradas do desenho, não uma certificação de conformidade.

Há três níveis de confiança. Declared indica que o componente apareceu de forma explícita. Inferred marca o que foi deduzido por padrões. Já Unresolved avisa que existem sinais, mas não identidade suficiente. Os casos não resolvidos continuam pedindo revisão humana. Uma imagem pode revelar a família do ambiente de execução e ainda esconder o peso ou a versão exata do modelo. O inventário pode ficar no status de um recurso customizado, seguir para o Cloud Storage ou ser enviado por webhook.

Fonte: Google Cloud.

Um agente multi-tenant pode agir por você sem fingir que é você

Quando um agente chama uma ferramenta em nome de um usuário, repassar o mesmo bearer token para todos os serviços parece simples. Também mistura destinatários e amplia o estrago caso a credencial escape. A AWS publicou uma implementação de troca de tokens “on behalf of”. Ela funciona no Amazon Bedrock AgentCore Gateway e segue o padrão OAuth 2.0. O comportamento adotado está definido na RFC 8693.

O fluxo preserva o identificador do usuário no campo sub. Depois, troca a audiência registrada em aud para o serviço que receberá a próxima chamada. O ator intermediário fica registrado separadamente. Antes de acionar a ferramenta, os componentes Gateway e Identity fazem a troca. O resultado é um token destinado à API que será chamada. Assim, o serviço final consegue distinguir quem pediu a ação de qual componente a executou.

A receita não vale para qualquer cenário. Em um sistema de um único tenant, com a mesma audiência de ponta a ponta, o encaminhamento direto pode bastar. Os servidores de autorização do tipo Org, oferecidos pela Okta, não têm o suporte necessário a audiência e escopo customizados. A arquitetura também exige desativar DPoP nesse repasse. Isso aumenta a importância de tokens curtos e da proteção do segredo usado pelo delegante. O repositório de referência foi prometido para depois da publicação e não fazia parte da evidência inspecionada.

O exemplo usa a Okta como serviço de autorização. A empresa fictícia Acme recebe um servidor separado. A outra empresa do exemplo, chamada Globex, recebe o seu próprio servidor. O API Gateway valida emissor, audiência e escopo. No desenho completo, a audiência é conferida em três pontos independentes. Para equipes com agentes multi-tenant, esse é um caminho padronizado para evitar tanto a personificação por conta de serviço quanto o encaminhamento inseguro de uma credencial recebida de outro contexto.

Fonte: AWS Machine Learning Blog.

A Microsoft põe provas formais ao lado do Rust de produção

Rust elimina várias classes de erro de memória, mas não prova que uma função criptográfica calculou exatamente o algoritmo do padrão. A Microsoft publicou implementações para a biblioteca SymCrypt. O código foi escrito em Rust. O pacote inclui especificações e provas formais para ML-KEM. Também cobre o algoritmo SHA-3. Esse código já é usado em versões de teste do Windows Insider. A biblioteca SymCrypt atende o Windows. Também está na distribuição Azure Linux.

O processo usa Aeneas para traduzir um modelo do código Rust. A tradução produz uma representação para o assistente de provas Lean. A partir daí, o assistente verifica se a implementação corresponde à especificação formal, desde que as precondições declaradas sejam verdadeiras. As provas desta primeira entrega cobrem por completo o código Rust desses dois algoritmos. Otimizações para x86-64 precisam de modelos explícitos. O mesmo vale para a arquitetura aarch64, inclusive seus intrínsecos e a seleção de implementação. Essas camadas não ganham passe livre por serem mais rápidas.

“Formalmente verificado” não é sinônimo de “sem falhas”. A prova vale para o teorema escrito, a especificação formalizada e os modelos considerados confiáveis. Ela não garante que a especificação esteja completa. Também não elimina automaticamente canais laterais nem aposenta testes ou auditorias. A expansão para o algoritmo AES-GCM está em andamento. O mesmo vale para FrodoKEM e para o esquema ML-DSA. Nenhum deles faz parte do conjunto já concluído.

Há ainda um uso sóbrio de agentes. Eles podem sugerir passos e escrever trabalho de prova, mas a aceitação não depende da eloquência do modelo. O pequeno kernel do Lean confere o resultado de maneira determinística. Aqui, uma tarefa trabalhosa pode ser automatizada dentro de uma fronteira em que a máquina recusa uma saída errada.

Fonte: Microsoft Research.

Passkeys viram o caminho padrão no Entra; telefone ganha prazo

A partir de 1º de setembro de 2026, a Microsoft pretende começar a tornar passkeys a experiência padrão de autenticação. A mudança será aplicada no Entra ID. Conforme a implantação chegar a cada organização, usuários que hoje têm SMS ou chamada de voz habilitados serão ativados para passkeys. O convite de cadastro aparecerá durante o fluxo de autenticação multifator.

O suporte inclui passkeys sincronizadas e vinculadas ao dispositivo. Para administradores, porém, a data mais importante vem depois. Em 1º de fevereiro de 2027, a Microsoft encerrará sua própria entrega de códigos por SMS e voz. Isso não torna telefone tecnicamente impossível. Organizações que ainda precisarem desse canal poderão contratar um provedor compatível da Security Store. Elas terão de pagar os custos de telecomunicações.

O rollout será gradual por organização, então 1º de setembro não significa uma virada simultânea para todos. Também é preciso separar duas decisões. Passkeys se tornam o padrão. A aposentadoria anunciada atinge a entrega nativa de SMS e voz pela Microsoft. Quem precisa conservar esses métodos terá uma rota paga para planejar e operar.

O calendário deixa pouco espaço para tratar a mudança como um ajuste cosmético. A Microsoft planeja divulgar provedores e preços em 18 de setembro. A configuração desses parceiros começa em 30 de outubro. Antes disso, vale levantar usuários afetados, testar o cadastro e a recuperação, escolher um grupo piloto e explicar a mudança, principalmente onde há dispositivos compartilhados, exigências regulatórias ou dependência de fallback por telefone.

Fonte: Microsoft Security Blog.

A Meta trocou a política de escalonamento sem manter um kernel próprio

Ao levar sua frota de anúncios para o Linux 6.9, a Meta encontrou uma regressão. A causa relatada foi o comportamento do EEVDF, introduzido no kernel 6.6. O serviço processa, em média, mais de 5 milhões de requisições por segundo. Uma política genérica de escalonamento esbarrou nas necessidades particulares de uma carga enorme e sensível à latência de cauda.

A saída foi usar sched_ext, mecanismo que permite definir a política de escalonamento fora do kernel. Essa política é escrita com BPF e distribuída a partir do espaço do usuário. A implementação divide CPUs de forma flexível conforme a sensibilidade à latência e ajusta os grupos com heurísticas de carga. Como a política não exige recompilar o kernel, a frota pôde avançar sem carregar uma versão própria só para essa carga. O mecanismo entrou no Linux upstream na versão 6.12.

Os números foram medidos e publicados pela própria Meta. A redução inicial de 28% vale para uma etapa específica, não para o serviço inteiro. A medição foi feita no maior tipo de servidor AMD Bergamo usado pela empresa. A economia de energia também deriva de efeitos internos, não de uma medição universal que outro operador possa copiar. O mecanismo abre espaço para experimentar sem bifurcar o kernel, mas a decisão continua dependendo de benchmark com a carga real.

Segundo a Meta, a primeira política reduziu em 28% o p99 da etapa de recuperação de anúncios. A empresa também relata economia de 3,28 megawatts e alta de 1,1% na quantidade ponderada de anúncios ranqueados. Evoluções posteriores teriam cortado mais 60% do p99 e reduzido em 18% os timeouts no caminho crítico.

Fonte: Engineering at Meta.

Notas rápidas para levar no café

SQS completa vinte anos sem deixar de ser um amortecedor de falhas

O Amazon SQS foi lançado em 13 de julho de 2006. Ele chegou junto da primeira geração de serviços de computação, representada pelo EC2. O armazenamento de objetos S3 também fazia parte daquele início. O retrospecto de vinte anos mantém a ideia original: desacoplar produtores e consumidores para absorver picos e isolar falhas. Desde outubro de 2022, novas filas recebem criptografia SSE-SQS por padrão. Entre as adições recentes está o redrive, que recoloca em circulação mensagens de uma fila de erros. Também chegaram filas justas, chamadas de fair queues, e mais escala para o modo FIFO.

Limites variam por região e modo. Em regiões selecionadas, filas FIFO chegaram a até 70 mil transações por segundo, por ação de API, em novembro de 2023. O limite de mensagens em voo subiu para 120 mil em 2024. O cliente estendido de Python fala em até 2 GB, mas guarda o conteúdo no S3. Pela fila SQS segue apenas uma referência, não uma mensagem nativa de dois gigabytes. O conteúdo nativo alcançou 1 MiB em 2025.

Fonte: AWS News Blog.

Argo CD gerenciado atravessa a rede privada até o Git

A capacidade gerenciada de Argo CD não entra diretamente na rede privada do cliente. Essa rede é a VPC do cliente. A capacidade faz parte do Amazon EKS. Para acessar um GitHub Enterprise Server privado, a AWS documentou uma ponte. O mesmo caminho aceita uma instalação autogerenciada do GitLab. A ligação usa o serviço CodeConnections. O host da conexão fica na rede do cliente. Para usá-lo, o Argo CD assume uma função IAM.

O suporte descrito é para esses servidores nomeados, não para qualquer host Git. Certificados emitidos por uma autoridade privada pedem configuração explícita. Manter o repositório de GitOps privado ainda exige trabalho de rede. São necessários roteamento e DNS. A saída HTTPS deve estar liberada pela porta 443. Também são necessárias permissões administrativas para instalar a integração no servidor Git. O procedimento exige a ferramenta AWS CLI na versão 2.x ou mais nova. Para alta disponibilidade, a AWS recomenda múltiplas sub-redes e zonas de disponibilidade.

Fonte: AWS Containers Blog.

Um draft quer entregar IPv4 sem manter ARP no primeiro salto

O draft-vanmook-intarea-ipv6-resolved-gateway, na versão 3, propõe usar o endereço sentinela 192.0.0.11. O DHCPv4 continua distribuindo uma opção comum de roteador. Hosts atualizados resolvem o próximo salto pela tabela de vizinhos IPv6. O pacote IPv4 permanece nativo de ponta a ponta, sem tradução ou túnel. Máquinas antigas ainda podem usar ARP e coexistir durante a transição.

O mecanismo ainda é um draft individual, com apresentação prevista para o IETF 126. Não é RFC nem comportamento garantido. A ideia complementa o RFC 8950. Também conversa com outro trabalho do IETF sobre a entrega entre os dois protocolos. Nesse desenho, o tráfego IPv4 usa uma rede IPv6. Se for padronizada e implementada, pode reduzir estado de dois protocolos e gambiarras de gateway /32. A experiência é atribuída ao autor e não foi reproduzida aqui. Ele relata um ambiente anterior em que 10 mil servidores e máquinas virtuais geravam cerca de 500 mil pedidos ARP por segundo.

Fonte: RIPE Labs.

Logseq 2.0 abre o primeiro beta da versão baseada em banco

O Logseq lançou o Desktop App 2.0.1 em 13 de julho. Esse é o primeiro beta público da chamada versão DB. Já dá para experimentar a nova geração, mas o próprio projeto a chama de beta inicial e pede backup de dados importantes, além de relatos de problemas.

As notas não trazem um inventário completo de funcionalidades ou do caminho de migração. Portanto, “versão DB” não autoriza inferir detalhes de arquitetura ausentes no release. Para quem tem uma base de notas importante, o teste sensato é feito numa cópia ou ambiente separado. O número da versão é 2.0.1; a maturidade ainda não é 2.0. A página oferecia 29 artefatos para desktop. Também havia pacotes para Android.

Fonte: releases do Logseq no GitHub.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.