Rodrigo Jorge · Preparado em 29 de outubro de 2026, às 06:05 (horário de Brasília, UTC-3). Horário de publicação a confirmar.
O agente consulta uma ferramenta usando uma credencial protegida. A chamada falha. Para investigar, a integração registra o pedido inteiro, incluindo o header de autenticação.
Nesse cenário hipotético, o armazenamento da credencial pode estar bem protegido e o segredo ainda assim acabar em outro lugar: no log de erro. Quem pode consultar esse log passa a ter acesso a uma cópia que o desenho original talvez não previsse.
A mesma pergunta vale para prompts, argumentos de ferramentas, documentos recuperados e respostas. Ativar captura completa para facilitar o debug muda o conjunto de dados que a observabilidade recebe. Essa mudança precisa de uma decisão explícita.
A OWASP recomenda que dados como access tokens, senhas e chaves não sejam normalmente registrados diretamente. A documentação do OpenTelemetry orienta minimizar a coleta e revisar o que as bibliotecas de instrumentação emitem. Ela também deixa claro que a ferramenta não determina sozinha o que é sensível em cada contexto.
Minha proposta para um agente que pode agir é começar por um contrato de eventos. Que informação permite reconstruir a ação sem repetir seu conteúdo sensível? Um exemplo conceitual, com valores ilustrativos, seria:
operation_id:op-exemplotool:consultar-alertaauthorization:allowedresult:upstream_errorcontent_recorded:false
Esse registro ajuda a correlacionar chamadas, mas não é uma trilha de auditoria completa. Conforme a operação, ainda serão necessários horário, referência controlada ao alvo, versão da policy e identidade responsável. Esses campos também precisam de classificação e controle de acesso. Metadado não é sinônimo de dado público.
O erro também faz parte do teste
Uma verificação que só acompanha a chamada bem-sucedida pode deixar passar o caminho que imprime o request inteiro ao ocorrer uma exceção. Eu pediria o mesmo ensaio com erro de autenticação, timeout e resposta malformada, usando marcadores sintéticos no lugar de segredos reais.
A conferência precisa alcançar os destinos usados pela integração: logs da aplicação, traces, filas de exportação e eventuais pacotes de suporte. Procurar o marcador apenas na tela de debug não mostra o que foi transmitido ou retido nos outros pontos.
O OpenTelemetry documenta processadores para remover ou transformar atributos. Eles podem ajudar, mas filtrar no Collector não elimina uma cópia já gravada pela aplicação antes dele. Por isso, reduzir a captura na origem e conferir o caminho inteiro são decisões diferentes.
Há investigações que exigem conteúdo detalhado. Nesses casos, eu separaria a captura excepcional do log operacional: finalidade definida, escopo restrito, acesso controlado e prazo de retenção escolhido para aquela necessidade. Não existe neste artigo um prazo universal nem uma promessa de que mascarar alguns padrões removerá todo dado sensível.
O resultado esperado do ensaio é duplo: conseguir explicar qual ação foi tentada e qual resposta recebeu, e comprovar onde o marcador sintético apareceu ou deixou de aparecer. Se retirar o segredo torna a investigação impossível, falta redesenhar a evidência coletada. Copiar tudo para descobrir depois o que importa transfere o problema para quem guarda e consulta os logs.
Referências
- OWASP: Logging Cheat Sheet, seção Data to exclude, consultada em 29 de outubro de 2026.
- OpenTelemetry: Handling sensitive data, consultado em 29 de outubro de 2026.