Scanners já falam MCP: os riscos que começam fora do modelo de IA

A notícia mais importante de hoje talvez não seja sobre um modelo novo. Ela aparece nas bordas: no endpoint que aceita MCP sem autenticação, no executor que interpreta um schema, no cache que faz 32 mil tokens levarem menos de um segundo ou quase um minuto e meio, e na camada de dados que pode ser apagada e reconstruída. O modelo segue no centro do discurso. Na prática, os problemas ficam em volta dele.

Scanners já falam MCP e procuram as chaves ao redor

Um diário do SANS Internet Storm Center descreve uma mudança incômoda no ruído da internet. Scanners não estão apenas procurando portas abertas. Em logs de Apache e ModSecurity de um pequeno host, analisados durante 14 dias, apareceram requisições MCP válidas vindas de 49 endereços IP distintos.

Os pedidos incluíam corpos initialize em JSON-RPC 2.0 usando a versão de protocolo 2025-03-26. O nível de especificidade sugere reconhecimento suficiente para não ser confundido com uma varredura genérica de HTTP. Depois do handshake, os mesmos padrões de exploração procuravam arquivos e endpoints do ecossistema de assistentes: .claude, .cursor, .vscode/mcp.json, arquivos de credenciais, /v1/models, /api/tags do Ollama e caminhos associados a requisições para metadados de nuvem.

A leitura precisa ficar no tamanho certo. O SANS observou reconhecimento em um host anonimizado. Isso não prova comprometimento, roubo de credenciais ou sucesso em SSRF. O número de 49 IPs vale para aquele conjunto de logs, não para “a internet inteira”. Ainda assim, já é motivo para mudar a prioridade de quem expõe um servidor de desenvolvimento em uma VPS.

Vale auditar autenticação e autorização do seu servidor MCP, a exposição de /mcp, /v1/models e /api/tags, os diretórios web e qualquer caminho que permita alcançar o serviço de metadados da máquina. Um endpoint que responde com simpatia demais pode entregar a lista de modelos e a pista necessária para o próximo passo do atacante. O protocolo pode ser novo; os erros de configuração continuam bastante tradicionais.

Fonte: SANS Internet Storm Center.

Migrar o agente revelou por que trocar o modelo não é trocar uma variável

A Ploy publicou um relato da migração do seu agente de construção de sites, do Claude Opus 4.8 para o GPT-5.6 Sol. O interesse do relato está nos detalhes da troca. Os números pertencem a um produto, uma carga e uma metodologia específicos, então não servem para declarar um vencedor universal. Eles mostram quantas coisas podem quebrar antes da discussão abstrata sobre inteligência.

Nos testes reportados pela Ploy, o Claude Opus 4.8, modelo anterior, teve média de 8 minutos, custo de 3,06 dólares, saída de 33,0 mil tokens e pontuação visual de 0,936. O GPT-5.6 Sol, modelo novo, ficou em 3 minutos e 42 segundos, 2,22 dólares, 17,1 mil tokens e 0,970, respectivamente. A Ploy atribuiu aproximadamente um terço das falhas iniciais a suposições do próprio harness, o conjunto de código que coordena chamadas, ferramentas, histórico e resultados.

Um detalhe chama atenção: o GPT-5.6 enviava todos os 25 parâmetros de uma ferramenta, enquanto o executor esperava um comportamento mais seletivo. Também foi necessário corrigir a fronteira de schemas anuláveis, redesenhar o uso de cache e tratar o replay de raciocínio com store:false. O modelo mudou. Com ele, mudou também o contrato entre modelo e sistema, justamente onde o sistema tinha acumulado suas suposições.

A compatibilidade vai além do formato da resposta final. Ela inclui a serialização dos argumentos, a passagem de valores nulos pelos schemas, os trechos que entram no cache, o que é persistido entre turnos e a retomada de uma falha. Um agente de produção se parece mais com um pequeno sistema distribuído do que com uma função prompt -> texto.

A própria Ploy apresenta os resultados como específicos do seu workload. Esses tempos, custos e notas visuais não viram benchmark geral. Servem como lembrete de engenharia: antes de trocar de modelo, teste o executor, o schema, o cache e o caminho de trace. Muitas vezes o primeiro bug está na interpretação que o resto da aplicação faz da resposta.

Fonte: relato de migração da Ploy.

Bobbin trata o AppView como algo que pode morrer e voltar

O Bobbin, sistema apresentado pela Tangled, é um AppView somente leitura e voltado a API para os lexicons sh.tangled.*, acessados por XRPC. Ele não mantém dados permanentes. Em vez disso, reconstrói seu índice a partir do dataset upstream do AT Protocol usando o Hydrant.

Durante o aquecimento, o Bobbin usa o Slingshot para responder consultas pontuais com precisão. Nas medições do autor, o índice residente ocupa aproximadamente entre 100 e 200 MB de RAM. Um backfill em condições favoráveis leva cerca de 30 segundos, com meta de ficar abaixo de 90 segundos. Se a fonte upstream estiver fria, o mesmo processo pode chegar a 20 minutos no cenário de desastre descrito.

Isso não transforma todo banco derivado em algo descartável. É um relato de implementação e operação de um sistema específico. A ideia depende de uma fonte autoritativa e reproduzível e de um protocolo capaz de alimentar a reconstrução. Sem essas duas coisas, “apagar e refazer” é apenas outra forma de dizer “perder os dados”.

Quando as condições existem, o ganho aparece no trabalho de operação. Migrações, rotinas de reconciliação e tratamento de drift deixam de ser o caminho principal para recuperar uma visão derivada. O sistema aceita que o índice é uma consequência temporária do log e concentra a durabilidade onde ela importa. Para um componente desse tipo, poder reconstruir é uma escolha operacional bem concreta.

Fonte: apresentação do Bobbin pela Tangled.

No Mac, o salto de velocidade veio do caminho do cache

Um relato sobre o qMLX, rodando Qwen 3.5 122B MoE em um M3 Ultra, mostra como detalhes pouco glamorosos decidem a latência percebida de um agente local. O caminho de serving usa atenção híbrida, mas os hits de prefixo em memória estavam efetivamente ausentes em uma medição: zero hits em memória contra 109 hits em disco.

O autor encontrou três problemas. O identificador de mensagem incluído no prompt armazenado mudava a cada turno e destruía a reutilização do prefixo. Respostas interrompidas não eram confirmadas no histórico, então a conversa persistida deixava de coincidir com o que o usuário já tinha visto. Gravações de checkpoints sem utilidade expulsavam checkpoints bons do espaço disponível.

Depois das correções, um prefill repetido de 32 mil tokens teria caído de 88 segundos a frio para 0,64 segundo a quente, uma melhora de aproximadamente 137 vezes nesse teste. É um número enorme, mas também é estreito: hardware, modelo, fork pessoal, formato do prompt e implementação de serving fazem parte do resultado. Não é uma promessa para qualquer Mac, runtime ou janela de contexto.

A parte transferível é menos cinematográfica e mais útil. Bytes estáveis no prompt são parte da API do cache. Histórico completo é requisito de consistência, não apenas conveniência de interface. A política de eviction pode destruir a vantagem de ter cache antes mesmo de a inferência começar. Quando um agente local parece lento, essas três camadas merecem uma olhada antes de concluir que falta um modelo mais rápido.

Fonte: relato técnico sobre qMLX.

Verifiers v1 separa tarefa, harness e runtime

A Prime Intellect anunciou em 10 de julho que a versão 0.2.0 apresenta um núcleo reescrito sob o namespace verifiers.v1. O projeto separa três peças que frequentemente acabam misturadas: o taskset, com dados, ferramentas e pontuação; o harness, que conduz o loop do agente e os rollouts; e o runtime, que pode ser um subprocesso local, Docker ou sandbox remoto.

A proposta combina tasksets e harnesses, troca runtimes e trabalha com traces ramificados para cenários de compactação ou subagentes. Os traces também podem ser preparados para treinamento. Há um servidor de interceptação que faz proxy do tráfego de inferência e pode registrar traces ou reescrever respostas de ferramentas, além de adaptadores para OpenAI Chat Completions, OpenAI Responses e Anthropic Messages.

Essa separação ajuda a localizar uma falha. Uma avaliação de agente precisa dizer se a tarefa era impossível, se o harness montou o loop errado, se o runtime isolou mal uma ferramenta ou se o protocolo foi interpretado de forma inesperada. Colocar tudo no mesmo componente transforma um resultado ruim em um diagnóstico ruim.

O projeto está em preview, não em uma versão 1.0.0, e o anúncio é de primeira parte, acompanhado por cobertura técnica secundária. O exemplo de treinamento com seis H200 e os resultados internos mencionados são demonstrações atribuídas, não evidência de ganhos amplos de desempenho. O ganho imediato está na fronteira explícita entre componentes, que deixa o sistema experimental mais fácil de examinar quando ele se aproxima da produção.

Fontes: anúncio da Prime Intellect e cobertura técnica do MarkTechPost.

Quick Hits

sqlite-utils 4.1.1 fecha uma armadilha de transação

O table.transform() agora levanta TransactionError quando uma combinação de chave estrangeira e ação destrutiva aparece dentro de uma transação. A documentação também passou a cruzar as APIs de CLI e Python. É um release de acompanhamento. A diferença para a história do sqlite-utils 4.0 está nessa proteção concreta para scripts e pipelines que mexem com SQLite.

Fonte: Simon Willison e release 4.1.1.

PyOpenGL 4.0.0a1 leva testes para bugs adormecidos

O mantenedor relata que testes produzidos com ajuda de LLM encontraram erros antigos nos wrappers. A versão alpha também abandona Python anterior ao 3.9 e NumPy anterior ao 2, além de incluir correções em GLES, EGL e tamanhos de wrappers. É um relato do mantenedor, não um estudo controlado sobre programação com LLM. O caso mostra como testes novos podem iluminar uma camada de bindings que passou anos sem ser cutucada.

Fonte: blog do mantenedor do PyOpenGL.

AT Protocol aparece como infraestrutura para apps local-first

Em uma proposta apresentada por Jake Lazaroff, PDSs ficariam responsáveis pelos dados do usuário, enquanto a infraestrutura compartilhada do AT Protocol cuidaria de armazenamento, autorização, sincronização e atualizações. A consequência imaginada é reduzir a quantidade de backend específico que cada aplicação precisa construir. É uma discussão de arquitetura e de uma palestra, não uma garantia de produção. A proposta conversa com o AppView reconstruível do Bobbin, mas continua sendo uma proposta.

Fonte: InfoQ sobre a proposta de aplicações web com AT Protocol.

Um if “inútil” muda o comportamento da CPU

Em um loop dependente e limitado pela latência, o autor mostra que uma ramificação explícita pode permitir que a previsão de desvios esconda a dependência. O benchmark sintético cai de 320 microssegundos para 80, um ganho de quatro vezes. Em um experimento mais realista, o resultado fica em aproximadamente duas vezes. O uso de volatile evita que o compilador elimine o trabalho. O efeito depende de carga, compilador e CPU, então o benchmark local vem antes de transformar o truque em regra.

Fonte: PurpleSyringa.

O fio que passa por tudo isso

As histórias encontram a mesma fronteira, sem dizer que todos os modelos ou arquiteturas se comportam da mesma maneira: a engenharia durável está se deslocando para fora do modelo. A migração da Ploy esbarra primeiro em harness, schemas, ferramentas e cache. O Verifiers torna taskset, harness, runtime e dialetos de protocolo explícitos. O qMLX encontra a velocidade no prompt estável, no histórico e na eviction. O Bobbin assume que uma visão derivada pode ser refeita. O alerta do SANS mostra que as interfaces ao redor dos agentes já viraram superfície de ataque.

A pergunta prática passa a incluir o contrato que o sistema consegue sustentar, o estado que pode ser reconstruído, o trace que pode ser auditado e os endpoints que devem permanecer fechados. A resposta depende do caso de uso. E o caso de uso inclui toda a tubulação.

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