Radar #2 — semana de 28/09: onde mora a garantia

Na primeira edição o fio foi quem vigia os agentes. Nesta, é onde a garantia mora de fato: dois papers a põem no contrato da ferramenta e no servidor MCP, não no prompt; dois laboratórios abrem mais a porta a avaliadores de fora; e um modelo novo muda a conta do cache.

1. Claude Opus 5.5: custo menor, segundo a Anthropic, e thinking sempre ligado

O que é. Em 22/09 a Anthropic lançou o Claude Opus 5.5, primeiro modelo da família 5.5; Sonnet 5.5 e Haiku 5.5 vêm "nas próximas semanas". Por milhão de tokens, em dólares: 4 de entrada, 20 de saída e 0,20 de leitura de cache (no Opus 5: 5, 25 e 0,50). A empresa estima custo 40% menor em cargas típicas.

Por que importa. Na tabela do anúncio, o Opus 5.5 marca 66,4% no Terminal-Bench 4.0 (esforço xhigh), contra 57,9% do GPT-6 Astra (esforço high, número informado pela OpenAI); na mesma tabela, o Astra fica à frente no Terminal-Bench-Science (64,6% contra 58,7%) e no AutomationBench (41,4% contra 40,0%). O próprio anúncio avisa que, nesse nível, margem de benchmark virou guia pouco confiável. Numa avaliação nova de contenção, o modelo tentou contornar limites cerca de 85% menos vezes que o Opus 5, e a empresa diz ver sinais de que ele muitas vezes suspeita estar sendo avaliado.

O que muda para quem constrói. Três detalhes pesam mais que o benchmark. O thinking não pode mais ser desligado. Quando as salvaguardas de ciber, biologia ou destilação intervêm, a requisição passa de forma transparente para outro modelo (ciber vai para o Opus 4.8, e o anúncio avisa que a maior parte das tarefas de cibersegurança será redirecionada; biologia, para o Opus 5). E contas de API criadas desde 31/08 recebem o "preserved thinking", que impede editar o contexto anterior do Claude. Se o seu agente reescreve histórico, teste antes de trocar para claude-opus-5-5.

2. Avaliador de fora, com acesso de dentro

O que é. Em 18/09 a Anthropic anunciou com a Accenture (via Faculty, seu braço de IA) uma parceria de avaliação embarcada: avaliadores dentro da empresa, com acesso comparável ao de um funcionário, acompanhando treinamento e decisões de deploy. Cada uma espera investir pelo menos 1 bilhão de dólares nisso em cinco anos. Em 22/09 a OpenAI publicou Priorities and principles for effective third party assessments, com quatro áreas prioritárias (safety cases, salvaguardas, avaliações, incidentes de desalinhamento) e sete princípios.

Por que importa. Os dois textos propõem que a avaliação externa deixe de ser teste pontual antes do lançamento e vire trabalho contínuo, com acesso profundo; a Anthropic avisa que os detalhes ainda estão sendo definidos. A Anthropic admite que não há padrão para o que o avaliador deve ver nem como deve relatar, nem sistema de financiamento; por isso ela mesma paga. O avaliador pago pelo avaliado é justamente o conflito que um dos princípios da OpenAI pede para declarar e mitigar. A OpenAI pede alegações de segurança pré-registradas e relatórios que separem achado de interpretação.

O que muda para quem constrói. Os princípios servem para auditar qualquer sistema com agentes, inclusive o seu: escopo por escrito, alegações registradas antes, método transparente, prazo para corrigir antes de publicar. Um deles pede lições práticas para quem desenvolve, implanta e defende agentes; minha aposta é que virem a lista de verificação que o seu cliente vai pedir.

3. Exactly-once: onde se evita a cobrança em dobro

O que é. O paper Where Does Exactly-Once Live? (Jiapeng Li, arXiv:2609.29095, submetido em 24/09) parte de uma cena comum: o agente faz uma escrita (cobrança, e-mail, deploy), a chamada estoura o tempo, e a ação pode já ter acontecido. O LIMBO, sandbox com seis serviços expostos via MCP e doze modos de falha, rodou 25.930 episódios com nove modelos e três harnesses de produção (GitHub Copilot CLI, Hermes e Codex CLI), todos conferidos contra um livro-razão dos efeitos gravados.

Por que importa. Quando reler o estado resolve a dúvida, os modelos de fronteira instruídos a agir uma vez só quase nunca duplicam (0,5%). Quando não resolve, porque a requisição ainda está em trânsito ou chegou duas vezes, os mesmos modelos duplicam em 56% e 74% dos episódios; o paper prova que só verificar não basta sem um limite conhecido de tempo em trânsito. Oferecer chave de idempotência em toda escrita derruba a duplicação de 28% para 4%. E em 90% dos episódios com duplicação o agente relatou a tarefa como concluída.

O que muda para quem constrói. Trocar de harness quase não muda nada, e retry transparente no cliente piora (sucesso exactly-once de 72% para 50%). O remédio está no contrato: chave de idempotência nas escritas, status consultável da operação, a mesma chave no retry e limites documentados de visibilidade e de tempo em trânsito. O paper avisa que uma leitura de status que não enxerga efeitos em trânsito foi pior do que não ter leitura nenhuma, porque os agentes confiaram nela. Se o seu servidor MCP escreve em algum sistema, isso é requisito.

4. MCP como controle de acesso: primeiro o papel, depois a ferramenta

O que é. Progressive Skill Discovery as Access Control for Tool-Using LLM Agents (Stettler, Girardet, Canton e Corod, arXiv:2609.28693, submetido em 23/09) é um white paper da Skilder, empresa dos autores. Capacidades vêm empacotadas em papéis (skills, ferramentas, instruções e limites); o agente aprende o papel que a tarefa pede e recebe as ferramentas por um único servidor MCP, que só executa o que pertence a uma skill aprendida.

Por que importa. Em 13 tarefas, seis modelos e 10 execuções cada, quando o modelo concluiu a descoberta, nenhuma chamada não autorizada nem violação de parâmetro (como estourar limite de gasto) executou. Há custo: nos cenários 1 a 4, 198 de 240 aprovações contra 229 da lista plana, porque alguns modelos tropeçam na descoberta. Com 225 ferramentas, uma consulta gastou 9.084 tokens, contra 51.330 da lista plana (uma única execução; com catálogo pequeno, a lista plana gasta menos).

O que muda para quem constrói. A tese vale mais que o produto: política no prompt é conselho probabilístico, não controle de acesso. Se o agente enxerga todas as ferramentas e só "é instruído" a não usar algumas, a barreira não existe. É a descoberta progressiva que o roadmap do MCP já sinalizava. Dois descontos: quem assina vende o produto, e a camada de autorização testada é simulada.

5. Memória persistente na nuvem, com a chave no aparelho

O que é. Em 23/09 o Google descreveu como vai levar memória persistente do lado do servidor ao Private AI Compute. Os dados ficam criptografados por usuário, as chaves só nos aparelhos da pessoa, e um enclave seguro descriptografa em memória isolada durante a requisição e recriptografa ao salvar.

Por que importa. Até agora, diz o texto, o Private AI Compute e soluções parecidas eram "stateless": apagavam o contexto no fim de cada tarefa. Junto, o Google publicou um registro público à prova de adulteração do software do servidor, para os aparelhos conferirem o código antes de enviar dados, e cita uma auditoria independente de uma empresa de cibersegurança que o post não nomeia.

O que muda para quem constrói. É anúncio de arquitetura, no futuro, sem API nem data. Mas fixa uma régua para memória de agente: chave com o usuário, enclave atestado, registro público verificável. É com isso que a memória do seu agente vai ser comparada.

Passou pelo radar

• O Google lançou o Gemini 3.8 Flash TTS e o Flash-Lite TTS (23/09): mais de 2.000 vozes e clonagem a partir de 30 segundos de áudio, condicionada ao consentimento gravado do dono da voz.
• O LIDAR (arXiv:2609.28559, 23/09) identifica o modelo por trás de um agente de código só pelo comportamento, em 36 modelos de sete famílias.
• O ACE (arXiv:2609.28915, 24/09) usa 4.047 sessões para mostrar que syscalls do kernel somadas à telemetria de aplicação em geral detectam melhor ataques a agentes que cada camada sozinha.
• A OpenAI defendeu (21/09) padrões técnicos internacionais para IA de fronteira, inclusive para autoaperfeiçoamento recursivo.
• Especificação do MCP: sem versão nova; segue a 2026-07-28, e o changelog do draft continua vazio.

O que fica desta semana

• A garantia mora no contrato, não no prompt: chave de idempotência e servidor que recusa fora do papel valem mais que instrução.
• Avaliação externa contínua e com acesso profundo entrou no plano de dois laboratórios, mas os padrões ainda não existem; minha aposta é que os princípios da OpenAI sirvam de primeiro rascunho.
• Quando duplica, o agente relata sucesso em 90% das vezes: meça pelo livro-razão, nunca pelo relato dele.

Referências

• ANTHROPIC. Introducing Claude Opus 5.5. 22 set. 2026.
• ANTHROPIC. Partnering with Accenture on embedded evaluation. 18 set. 2026.
• OPENAI. Priorities and principles for effective third party assessments. 22 set. 2026.
• LI, Jiapeng. Where Does Exactly-Once Live? Model, Harness, and Tool-Contract Effects on Duplicate Side Effects in LLM Agents. arXiv:2609.29095, submetido em 24 set. 2026.
• STETTLER, Michael; GIRARDET, Benjamin; CANTON, Jonas; COROD, Nicolas. Progressive Skill Discovery as Access Control for Tool-Using LLM Agents: Structural Governance through Role-Scoped Capability Delivery. arXiv:2609.28693, submetido em 23 set. 2026 (white paper).
• GOOGLE PRIVATE AI COMPUTE TEAM. Advancing Private AI Compute with secure, server-side memory. Google DeepMind, 23 set. 2026.
• GOOGLE. Gemini 3.8 text-to-speech says hello. Google DeepMind, 23 set. 2026.
• WANG, Chuyi; XIE, Xiaohui; WANG, Tongze; LUO, Fangchen; CUI, Yong. Who Is Behind the Harness? Fingerprinting LLMs through Agentic Behavior. arXiv:2609.28559, submetido em 23 set. 2026.
• KING, Spencer; ZHANG, Zhilu; KUZNETSOV, Mikhail et al. On the Effectiveness of Kernel-Level Evidence for Agent Security. arXiv:2609.28915, submetido em 24 set. 2026.
• OPENAI. Building standards for the next phase of AI. 21 set. 2026.
• MODEL CONTEXT PROTOCOL. Specification 2026-07-28: Key Changes. Acesso em 25 set. 2026.