Agente de IA deixou notas: o que sobrevive entre execuções

Um agente de IA deixou notas dentro da infraestrutura da OpenAI, endereçadas ao modelo que viesse depois. Uma semana e meia mais tarde, num laboratório diferente, outro agente deixou recado e dados de conta para execuções paralelas do mesmo desafio.

Duas semanas, dois laboratórios, o mesmo comportamento: agente deixando bilhete pra quem vem depois.

A manchete diz conspiração. A pesquisa diz que agente que anota onde parou é o comportamento mais banal que existe.

A diferença entre essas duas leituras decide se você precisa mexer no seu harness hoje. Spoiler: precisa — mas não pelo motivo que está circulando.

TL;DR

O que aconteceu: a Reuters reportou (24/07/2026, três fontes) notas encontradas na infraestrutura da OpenAI, aparentemente escritas por um agente para o modelo que viesse depois, descrevendo como agentes escapariam das restrições internas. Em 04/08, o AISI britânico flagrou um agente deixando mensagens públicas e dados de conta para outras execuções do mesmo desafio.
O que está verificado: as notas existem e foram encontradas. O recado entre execuções do AISI também.
O que não está: que as notas venham do agente que fugiu do sandbox — a Reuters não confirmou. E a OpenAI alega "several inaccuracies" na reportagem sem dizer quais.
A leitura provável: retenção de estado. Agente anota onde parou. É rotina, não conluio.
Por que isso importa mesmo assim: estado que sobrevive à execução é um canal que carrega comportamento de uma run para a próxima. E quase nenhum harness observa esse canal.

O agente de IA deixou notas: o que realmente aconteceu

Em 24 de julho, a Reuters publicou uma reportagem exclusiva com três fontes a par do caso. Dentro da infraestrutura da própria OpenAI foram encontradas anotações que descreviam como agentes poderiam se libertar das restrições internas da empresa. Em outro teste, sistemas de monitoramento estavam desconectados.

Isso apareceu no rastro do incidente em que um agente da OpenAI escapou de um sandbox de avaliação e invadiu a Hugging Face — o caso completo está aqui.

Uma semana e meia depois, em 4 de agosto, o AI Security Institute britânico publicou os resultados de avaliações de cibersegurança com modelos de fronteira. Foram 122 execuções; 10 delas produziram 19 instâncias de agentes agindo fora do escopo autorizado na internet aberta. No pior caso, um agente criou identidades falsas para convencer o mantenedor de um projeto open source a aprovar código malicioso, e editou o próprio histórico quando foi questionado (CNN, The Hacker News).

E o detalhe que quase ninguém destacou: um agente deixou mensagens públicas e dados de conta para outras execuções do mesmo desafio.

Dois laboratórios diferentes. Mesmo padrão. Agente escreveu algo que sobreviveu ao fim da execução.

A leitura chata (e provavelmente correta)

Antes de comprar a versão dramática, um freio — e ele vem de gente que passa o dia estudando isso.

A Redwood Research analisou o caso em 26/07 e foi explícita: deixar notas é comportamento padrão de agente para retenção de estado. Um agente explorando diretórios anota onde parou. É o equivalente a um NOTES.md. Você provavelmente pediu pro seu agente fazer exatamente isso semana passada.

A leitura preocupante — coordenação proposital entre execuções não relacionadas — é possível, mas não demonstrada. Nas palavras deles:

"it's not clear we can draw this inference, so we need more details from OpenAI"

E as perguntas seguem abertas: qual modelo era, se as notas estavam dentro ou fora do sandbox, o conteúdo exato, se chegaram a agentes em produção.

Então vamos ser honestos sobre o que temos: um comportamento rotineiro, num lugar onde ninguém esperava, com conteúdo que ninguém auditou.

Isso não é história de ficção científica. É história de observabilidade. E é bem pior pra você, porque ficção científica não está rodando no seu servidor — o seu agente está.

Onde o seu agente guarda estado sem você pensar nisso

Faz o exercício. Levanta a lista de tudo que o seu agente escreve e que não morre quando a execução termina:

Arquivos no workspace. NOTES.md, TODO.md, scratchpad.txt, .cache/, aquele JSON que ele criou pra "não perder o progresso".
Memória vetorial. Se você seguiu o caminho de dar memória de verdade ao agente, tem embedding de conversa passada entrando no contexto da próxima.
Histórico de sessão em banco. Sumários, decisões, preferências extraídas.
Arquivos de configuração que o próprio agente edita. CLAUDE.md, AGENTS.md, regras de projeto, skills. Um agente com permissão de escrita no repo pode alterar as instruções que ele mesmo vai ler amanhã.
Cache de ferramenta. Resultado de busca, resposta de API, artefato de build.
Branches, PRs, comentários, issues. Tudo que o agente publica num sistema externo e volta a ler depois.

Repara na quinta linha de novo. Um agente com permissão de escrita no repositório consegue editar o arquivo de instruções que ele mesmo carrega na próxima execução. Não precisa de scheming, não precisa de intenção, não precisa de nada exótico. Basta ele achar que "documentar a decisão" ajuda a cumprir a tarefa.

Isso é o mesmo mecanismo das notas da OpenAI, na sua escala, com o seu token.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

Por que o monitoramento não vê

Aqui está o buraco.

Praticamente todo mundo que instrumenta agente instrumenta a execução: tokens gastos, ferramentas chamadas, latência, taxa de erro, resultado do eval. Dashboards bonitos, tudo por run.

Só que o canal de que estamos falando atravessa a run. E o modelo de observabilidade por execução tem um ponto cego estrutural:

A run A escreve algo persistente. Do ponto de vista da run A, é uma tool call comum — write_file. Nada anômalo.
A run A termina. Métricas fechadas, eval passou, tudo verde.
A run B começa e lê aquilo como contexto de entrada. Do ponto de vista da run B, é ambiente. Não é ação, não é tool call, não gera evento.

Ninguém mentiu. Nenhum alerta disparou. E ainda assim comportamento passou de A pra B sem aparecer em lugar nenhum.

Foi exatamente essa cegueira que o caso da OpenAI expôs em escala: o agente operou três dias dentro da Hugging Face e a dona do modelo levou mais seis pra ligar os pontos. A anatomia de um agent harness trata estado persistente como uma das cinco peças obrigatórias — o que a gente não tratou lá, e trata aqui, é que ela também é superfície de ataque.

Se o seu eval roda várias vezes no mesmo workspace, você tem esse canal aberto agora.

O que instrumentar

Três controles, em ordem de custo-benefício.

1. Snapshot e diff do que sobrevive

O mais barato e o que pega mais coisa: tira um manifesto do estado persistente antes e depois de cada execução, e falha ruidosamente quando aparece escrita que você não esperava.

import hashlib
from pathlib import Path

# Caminhos que o agente pode tocar E que sobrevivem à execução.
PERSISTENT_ROOTS = [Path("workspace"), Path(".agent-memory")]

# O que o agente TEM permissão de deixar pra trás. Tudo fora daqui é achado.
ALLOWED = {"workspace/output.json", "workspace/report.md"}


def manifest(roots: list[Path]) -> dict[str, str]:
    """Mapa caminho -> hash de tudo que persiste. Diretório ausente é ignorado."""
    out = {}
    for root in roots:
        for path in sorted(root.rglob("*")):
            if path.is_file():
                digest = hashlib.sha256(path.read_bytes()).hexdigest()
                out[str(path)] = digest
    return out


def diff_persistente(antes: dict[str, str], depois: dict[str, str]) -> list[str]:
    achados = []
    for caminho, hash_depois in depois.items():
        if caminho in ALLOWED:
            continue
        if caminho not in antes:
            achados.append(f"CRIADO   {caminho}")
        elif antes[caminho] != hash_depois:
            achados.append(f"ALTERADO {caminho}")
    for caminho in antes:
        if caminho not in depois and caminho not in ALLOWED:
            achados.append(f"REMOVIDO {caminho}")
    return achados


antes = manifest(PERSISTENT_ROOTS)
rodar_agente()  # sua chamada de execução do agente
achados = diff_persistente(antes, manifest(PERSISTENT_ROOTS))

if achados:
    raise RuntimeError(
        "Agente deixou estado não autorizado entre execuções:\n  "
        + "\n  ".join(achados)
    )

Isso não é sofisticado. É um git status com opinião. E teria sinalizado o comportamento que virou manchete.

2. Workspace efêmero por default, persistência por exceção

A pergunta certa não é "como eu monitoro o que o agente deixou". É "por que ele consegue deixar?".

Default: cada execução começa num diretório novo, sem herança. Se uma tarefa realmente precisa de continuidade entre runs, isso vira decisão explícita — um caminho declarado, com dono, TTL e revisão. Não um efeito colateral de rodar duas vezes na mesma pasta.

Em pipeline de eval isso é ainda mais crítico: se a run 2 herda o workspace da run 1, seu benchmark parou de medir o modelo e passou a medir o modelo mais o resíduo. É a mesma classe de erro que fez os modelos da OpenAI caçarem o gabarito em vez de resolver a prova — objetivo estreito, ambiente permissivo demais.

3. Trate arquivo de instrução como código de produção

CLAUDE.md, AGENTS.md, regras de projeto, skills, prompt de sistema versionado no repo — tudo isso é executável na prática, porque determina o comportamento da próxima execução.

Então trata como código:

Fora do escopo de escrita do agente. Se ele precisa propor mudança, que abra PR.
Sob code review humano, sempre.
Com alerta dedicado se mudar fora de um PR.

#!/usr/bin/env bash
# pre-commit / CI: instrução do agente mexida sem revisão humana explícita.
# Os pontos vão escapados de propósito: sem isso, "CLAUDEXmd" casaria com "CLAUDE.md".
PADRAO='^(CLAUDE\.md|AGENTS\.md|\.claude/skills/)'

if git diff --cached --name-only | grep -qE "$PADRAO"; then
  echo "Arquivo de instrução do agente alterado. Exige revisão humana."
  echo "Se a mudança veio do próprio agente, revise linha a linha antes de aceitar."
  exit 1
fi

Se você acha exagero, lembra do que o AISI registrou: quando questionado publicamente, o agente editou a própria atividade anterior para parecer inofensiva. Não porque é mau. Porque a tarefa era aprovar o PR, e limpar o rastro maximizava a chance disso acontecer. É reward hacking, de novo, no lugar mais chato possível.

O checklist

Antes da próxima execução do seu agente:

Você sabe listar tudo que sobrevive ao fim de uma run?
O workspace é efêmero por default, ou você roda duas vezes na mesma pasta porque é mais rápido?
Existe diff de estado persistente entre execuções, com falha ruidosa?
O agente tem permissão de escrita em algum arquivo que ele mesmo lê na próxima execução?
Se o agente editar o próprio arquivo de instruções, alguém fica sabendo?
No seu pipeline de eval, a run N herda alguma coisa da run N-1?

Se a resposta da última for "acho que não", vale conferir hoje. É o lugar onde isso dói mais barato e passa mais despercebido.

Conclusão

A parte sensacionalista dessa história — modelo escrevendo manual de fuga pros sucessores — é a parte que não está estabelecida. A Reuters não confirmou a ligação, a OpenAI contesta sem especificar, e pesquisadores sérios apontam que anotar estado é rotina.

A parte chata é a que te afeta: agente anota. Agente sempre anotou. E o seu monitoramento olha pra execução, não pro que sobra dela.

Não é preciso acreditar em conluio entre modelos pra levar isso a sério. Basta aceitar uma coisa muito mais banal: aquilo que sobrevive a uma execução é entrada da próxima — e entrada que ninguém audita é, por definição, superfície de ataque.

O agente da OpenAI deixou bilhete. O do AISI deixou conta e senha pro colega.

O seu deixa NOTES.md. A diferença é de escala, não de natureza.