A encriptação de mensagens entre agentes faz sentido para segurança. Mas quando o histórico de uma execução multi-agente se torna num monte de ciphertext ilegível, perdemos a capacidade de fazer debugging, auditoria e análise forense.
No dia 5 de Junho de 2026, o PR #26210 foi mergeado no Codex CLI. O título dizia tudo: “Encrypt multi-agent v2 message payloads”. A ideia era boa — encriptar as mensagens trocadas entre agentes para que o modelo receptor não conseguisse ler o conteúdo em texto claro.
Menos de duas semanas depois, a issue #28058 abriu. O autor, ignatremizov, identificou uma regressão clara: as mensagens encriptadas tornaram o histórico de execução multi-agente opaco. Não dava para perceber o que cada sub-agente recebeu, o que lhe foi pedido, ou sequer por que razão uma thread filha existia.
Neste artigo vou analisar o problema, o código envolvido, e a solução proposta — que ainda não está concluída.
O que o PR #26210 fez
O PR introduziu o método InterAgentCommunication::new_encrypted(). O construtor recebe o conteúdo da mensagem e guarda-o exclusivamente no campo encrypted_content. O campo content fica vazio:
pub fn new_encrypted(...) -> Self {
Self {
content: String::new(), // ← vazio
encrypted_content: Some(content), // ← aqui está o payload
// ...
}
}
O to_model_input_item() prepara a mensagem para o histórico. Se encrypted_content existe, emite apenas o ciphertext. O modelo receptor recebe a mensagem encriptada — e o histórico também. Um rollout multi-agente deixa de ter um registo legível do que foi delegado.
O problema de auditabilidade
A issue #28058 lista três perguntas que se tornaram difíceis de responder: que tarefa foi dada ao sub-agente no spawn_agent? Que mensagem foi enviada? Porque é que uma thread filha existia ao rever um rollout?
Num sistema multi-agente, inspecionar o histórico de comunicação é essencial para debugging, auditoria e análise de comportamento. Quando as mensagens são substituídas por ciphertext, o rollout trace perde todo o valor como ferramenta de análise.
O autor separa este problema do reportado na #26753 (erros de schema validation). Este é diferente: a encriptação funciona, mas ao preço de cegar quem precisa de fazer debugging.
A arquitetura da comunicação encriptada
O código mostra a cadeia completa. As funções que tratam as mensagens recebem o payload, passam-no pelo construtor encriptado, e o record_inter_agent_communication() grava o ResponseItem — que, para comunicação encriptada, contém apenas o payload cifrado. O problema acumula-se em várias camadas: InterAgentCommunication.content fica vazio, o ResponseItem emitido só tem ciphertext, e os logs estruturados fazem o mesmo. Nenhuma superfície de auditoria escapa.
A solução proposta: dual-content
O ignatremizov propôs e já implementou parcialmente uma abordagem que preserva a encriptação para o modelo sem sacrificar a auditabilidade local:
Mecanismo de dual-content: manter o campo message encriptado para o modelo receptor, e adicionar um campo não encriptado — task_message para spawn_agent, e algo como message_text para send_message / followup_task — que contém o texto legível para o histórico.
Implementação: o InterAgentCommunication passa a ser construído com ambos preenchidos: encrypted_content com o payload cifrado, e content com o texto legível. O to_model_input_item() continua a enviar só o ciphertext para o modelo. O rollout trace e os logs passam a ler o content.
O protótipo para spawn_agent já existe no commit df9a7c4. Falta o mesmo tratamento para send_message e followup_task.
Os critérios de aceitação da issue são claros:
- O rollout/history do agente-pai mostra o texto legível
- O modelo filho continua a receber apenas o payload encriptado
- Os communication logs usam o conteúdo de auditoria quando existe
O que isto nos diz sobre engenharia de agentes
Esta issue é um bom caso de estudo sobre um conflito que vamos ver cada vez mais: privacidade vs. observabilidade em sistemas multi-agente.
Encriptar mensagens entre agentes faz sentido. Se um modelo pode ser comprometido, não queremos que o conteúdo de mensagens internas esteja em texto claro. Mas encriptação total, sem um canal de auditoria separado, transforma o sistema numa caixa negra.
A solução de dual-content é elegante: não sacrifica a segurança nem a capacidade de debugging. Mas obriga a gerir dois canais de comunicação — um cifrado para operação, um legível para auditoria — sem que um vaze para o outro. Para sistemas que ambicionem produção em contextos regulados, esta separação vai ser requisito, não extra.
O PR #26210 não estava errado ao querer encriptar. Estava incompleto. E a issue #28058 mostra que em engenharia de sistemas de IA, “incompleto” é muitas vezes o mesmo que “partido”.
Conclusão
A encriptação de mensagens entre sub-agentes do Codex foi necessária — mas partiu a auditabilidade do sistema. A issue #28058 documenta o problema com precisão e propõe uma solução viável. O spawn_agent já tem protótipo; falta o mesmo para send_message e followup_task.
O caso serve de aviso a quem trabalha com sistemas multi-agente: encriptação não se faz a martelo. A resposta certa não é “nunca encriptar” nem “encriptar tudo”. É encriptar para quem deve — e deixar uma cópia de auditoria para quem precisa.
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário