SAFE, AutoTuneBench e memória-wiki: segurança de agentes

SAFE: o modelo procura a prova antes de agir?

Avaliamos modelos de fronteira pelo que eles fazem depois que a informação de segurança já está no contexto. O paper muda a pergunta para um ponto anterior e mais incômodo: o modelo escolhe buscar a evidência de segurança antes de executar?

O que mudou: o benchmark SAFE (arXiv 2609.17865) monta um cenário controlado em que o modelo toma uma decisão de deploy com evidência opcional — que varia em custo de recuperação, probabilidade, severidade e forma de apresentação. Rodando em GPT-5.5, o3, Claude Opus 4.8 e Claude Sonnet 4.6, os autores encontram políticas de aquisição bem diferentes entre si: o Opus inspeciona quase por padrão, enquanto o o3 fica no outro extremo do espectro.

Por que importa: segurança de agente costuma ser testada como "o que ele responde quando já sabe". Mas no mundo real a informação de segurança não cai no contexto sozinha — alguém precisa decidir ir buscá-la. Se um modelo age sem inspecionar, a falha acontece antes de qualquer resposta, num ponto que quase nenhum benchmark atual enxerga. Para quem deixa agente rodando em produção, é a diferença entre um sistema que verifica e um que atropela.

AutoTuneBench: a medição que sustentava o auto-tuning era frágil

Agentes de LLM já fecham o ciclo de otimização sozinhos: propõem mudança em kernel de GPU ou em engine de serving, medem, e ficam com o que "ganhou". O problema é que a régua desse ciclo não era confiável.

O que mudou: o AutoTuneBench (arXiv 2609.18123) documenta quatro modos de falha a partir de um piloto de quatro dias com 619 chamadas de modelo: baselines "espantalho" fabricam speedup; tempos absolutos não transferem de uma máquina para outra; tarefas saturadas anulam a comparação; e defeito de infraestrutura se disfarça de resultado científico. A resposta dos autores é um benchmark com protocolo de medição congelado, que torna a confiança uma propriedade da arquitetura do teste, não da boa vontade de quem mede.

Por que importa: auto-tuning de serving é exatamente o tipo de coisa que um agente de Claude Code já faz em loop. Se a medição mente, o agente "otimiza" o kernel errado com convicção total. Para quem queima token afinando engine de inferência, o recado é seco: medir direito é mais difícil que gerar o código — e um speedup fabricado por baseline espantalho, ou medido numa máquina saturada, não vale nada na sua.

WFM: a memória do agente vira wiki, não grafo

Agente real precisa de memória de longo prazo e recuperação para raciocinar sobre o mundo. Grafos de conhecimento sempre deram evidência estruturada, mas a representação esparsa limita a legibilidade de máquina e a densidade semântica que um workflow agêntico complexo exige.

O que mudou: o WFM — Wiki Foundation Model (arXiv 2609.18182) formaliza a troca de paradigma que, segundo os autores, já está acontecendo na indústria: sair do grafo esparso tradicional para a LLM Wiki, uma representação de conhecimento nativa de agente, que acopla densidade semântica à estrutura.

Por que importa: a memória é o que separa um agente de um script que esquece tudo a cada sessão. Se o formato padrão da memória de agente deixa de ser o grafo e vira uma wiki densa que o próprio LLM lê e escreve, muda a forma como se constrói RAG, como se audita o que o agente "sabe" e como se escala contexto de longo prazo. É infraestrutura invisível que decide o teto do agente.

Contrato simbólico no lugar do juiz LLM

Agentes com ferramentas executam tarefas multi-etapa — navegação web, geração de código, orquestração de workflow — fazendo tool calls em sistemas externos. O risco não é teórico: alucinação, instabilidade de distribuição e manipulação adversária podem terminar em tool call irreversível.

O que mudou: o paper Symbolic Temporal Supervision of LLM Agents Using Contracts (arXiv 2609.18128) ataca a limitação das salvaguardas atuais. Os dois caminhos dominantes são fracos por lados opostos: julgar trajetórias depois com juiz LLM estocástico (caro, não determinístico, chega tarde) ou bloquear ação perigosa uma chamada por vez (não enxerga a sequência). A proposta é uma supervisão temporal e simbólica baseada em contratos — um meio-termo determinístico que acompanha a trajetória sem depender de outro LLM para decidir o que é seguro.

Por que importa: para quem dá ferramenta a agente, o ponto é exatamente o "e se". E se o modelo alucinar um comando destrutivo? E se a sequência de chamadas, isoladamente inocentes, somar um desastre? Contratos determinísticos dão uma resposta auditável, que não custa tokens de um segundo LLM e que pode ser verificada antes da ação irreversível — em vez de um pêndulo entre "bloqueia tudo" e "julga depois que já aconteceu".

Status do TOKEN CLUB

Placar

• 🥇 Kogu — 3.128.141.947 tokens
• 🥈 Xepa — 3.035.251.037
• 🥉 JOAO_AMORIM — 2.694.799.519
• 4º Tetz — 302.210.242

Placar congelado: Kogu segue na ponta com 92.890.910 tokens sobre Xepa (3,06%). JOAO_AMORIM está 340.451.518 atrás do 2º, e Tetz a 2,39 bilhões do pódio. São 10 jogadores no clube; 4 pontuam.

Índice

• Hoje (17/09): sem dado — nenhuma máquina reportou ainda.
• Ontem (16/09): passou em branco, sem reporte.
• Último dado: 15/09, com 91.509.794 tokens (1 sessão, 1 jogador).
• Dia normal: 56.223.143 tokens (média de 14 dias).

Dois dias de silêncio não apagam a régua: 12/09 fez 511.858.277 e 14/09 fez 335.129.583 — uma única sessão forte dessas apaga os ~93 mi de vantagem do Kogu. A base segue parada; quem aparecer para queimar token hoje decide o placar.