Observabilidade de agentes: evidência útil sem expor contexto sensível

Um trace, o encadeamento de eventos de uma execução, pode facilitar uma investigação e também criar uma segunda cópia de informações que não deveriam circular. A questão de arquitetura é quais evidências são necessárias para explicar uma decisão, quem precisa acessá-las e por quanto tempo. Capturar tudo e decidir depois transfere o problema para o armazenamento e para as pessoas que receberão o material.

Este texto propõe um contrato de observabilidade para sistemas com agentes. Não descreve um mecanismo já operando em todos os produtos Trustyu, nem apresenta resultados de clientes ou uma implementação certificada. O contrato deve ser ajustado ao risco, ao domínio e às obrigações da organização.

Comece pelas perguntas de investigação

Uma equipe precisa conseguir responder qual objetivo foi autorizado, qual versão do sistema foi executada, quais ferramentas puderam atuar, como o resultado foi verificado e quais efeitos ocorreram. Em muitos fluxos, essas perguntas podem ser atendidas por identificadores, versões, estados e medidas, sem armazenar o corpo completo de uma conversa ou documento.

Isso não significa que conteúdo nunca seja necessário. Significa que a necessidade deve ser definida por finalidade, com acesso e retenção compatíveis. Um incidente pode exigir investigação especializada sob controles diferentes dos que servem ao acompanhamento cotidiano.

Separe três planos de evidência

1. Operação: duração, estado final, falha, intervenção e unidades de trabalho, usando dimensões controladas para evitar que campos livres transformem métricas em um repositório de contexto.
2. Decisão: referências para objetivo, política, versão e verificador, suficientes para explicar por que uma ação era elegível e quem assumiu o aceite.
3. Investigação: dados adicionais, quando necessários e autorizados, com fronteira de acesso, finalidade, prazo e possibilidade de retirada definidos.

Os três planos não precisam ter o mesmo backend, os mesmos leitores nem a mesma retenção. Um painel de operação usado por muitas pessoas não deve herdar automaticamente o acesso a um documento que contém informação restrita. Uma correlação técnica é uma ligação entre registros, não uma permissão para consultar todos eles.

A evidência deve limitar, não ampliar a autoridade do agente

O agente pode emitir observações sobre sua execução. O registro que comprova autorização, efeitos e aceite não deve depender somente de uma declaração gerada por ele. Preserve referências verificáveis em componentes com responsabilidades próprias. Histórico, política e isolamento de execução são fronteiras diferentes; escolher outro modelo não substitui esse desenho. [HARNESS31-C2]

Um identificador de política ajuda a localizar a regra usada, mas não prova sozinho que ela foi aplicada. Um campo verified também não é evidência se o próprio executor puder preenchê-lo sem verificação externa. O contrato precisa indicar quem emite cada registro e qual observação independente sustenta o estado apresentado.

Minimize antes da exportação

A orientação de segurança do OpenTelemetry trata da minimização de dados e de processadores para remover ou transformar atributos. A OWASP recomenda definir eventos, proteger logs e excluir segredos e dados sensíveis desnecessários. Essas orientações não validam uma configuração específica.

No contrato proposto, atributos aceitos pertencem a um conjunto explícito. Cabeçalhos, tokens, corpos de documentos, instruções de usuário e respostas livres não entram por conveniência. Exceções precisam ser justificadas e exercitadas com dados sintéticos antes de acessar conteúdo real autorizado.

O OpenTelemetry também alerta para a possibilidade de recuperar valores de entrada previsíveis a partir de seus hashes. Hash ou pseudônimo não equivalem a anonimização automática. A utilidade da referência, a possibilidade de reidentificação e a permissão de acesso precisam ser avaliadas no contexto por responsáveis técnicos e de privacidade.

Uma configuração no coletor não desfaz uma exposição anterior no SDK, no console, numa fila ou no fornecedor do modelo. A proposta é reduzir a coleta na origem e verificar cada saída. Isso inclui argumentos de ferramentas, mensagens de exceção e campos livres de bibliotecas instrumentadas. Uma lista de atributos permitidos também precisa restringir os valores: um campo chamado status que aceita a resposta inteira do modelo continua carregando contexto.

Um caso sintético: investigar sem copiar a solicitação inteira

Imagine um agente autorizado a abrir um chamado interno. Ele prepara a solicitação, mas a integração retorna timeout. A interface informa que o chamado foi criado. Uma trilha útil precisa permitir descobrir essa divergência sem enviar a descrição do problema ou dados da pessoa ao painel geral. O exemplo abaixo é ilustrativo; não representa um incidente, cliente ou controle implantado.

O painel recebe estado, duração e versão. O registro de decisão guarda referências protegidas. Se a investigação exigir a solicitação original, o acesso acontece no sistema autorizado, com finalidade e prazo próprios. O identificador usado para correlacionar registros não concede essa permissão.

O timeout cria outra decisão: antes de repetir uma operação com efeito, consulte o destino ou use o mecanismo de idempotência que ele realmente oferecer. Um trace, sozinho, não impede duplicação. O resultado da verificação também pode chegar depois: registre essa confirmação como um novo evento ligado à mesma operação, preservando o estado anteriormente observado e distinguindo horário do evento de horário de ingestão.

No W3C Trace Context, seção 6, traceparent e tracestate servem à correlação e não devem carregar informação pessoal ou sensível. Na proposta deste artigo, nenhum deles funciona como credencial de acesso ou como lugar para guardar o contexto do chamado.

Controle a qualidade da própria telemetria

Um sistema pode executar corretamente e produzir um registro incompleto. Também pode registrar uma ação que não chegou ao destino. Separe tentativa, aceitação pela ferramenta, efeito observado e confirmação do resultado. Se o processo depende de um recibo para liberar uma ação material, a ausência desse recibo deve permanecer visível como falha ou inconclusão.

Não imponha bloqueio universal por qualquer perda de métrica. Defina quais sinais são necessários para a autorização e quais servem apenas ao diagnóstico. A decisão depende do impacto e do modo de recuperação; transformar toda falha de painel em parada pode criar outro problema operacional.

Custo, retenção e investigação também têm limites

Amostragem é a seleção de parte das execuções para diagnóstico. Na proposta, ela pode reduzir o volume de traces operacionais, mas não deve decidir se o recibo exigido para uma ação material será preservado. Essa obrigação precisa de um caminho de registro próprio. Um painel deve mostrar o denominador: execuções elegíveis, amostradas, incompletas e sem verificação; uma taxa calculada só sobre traces bem formados pode ocultar justamente as falhas de coleta.

Para custos, acompanhe separadamente unidades informadas pelo provedor, tentativas, volume de telemetria, armazenamento e trabalho humano de investigação. Uma contagem de tokens não é a fatura total. Identificadores de execução devem permitir consulta pontual, sem virar dimensão livre em todas as métricas; o conjunto de combinações de valores, chamado cardinalidade, precisa de um orçamento.

Retenção não é um número universal. Defina finalidade, responsável, prazo, obrigação de preservação, backups, exportações e fornecedores abrangidos. Se uma cópia não permite retirada imediata, registre o limite e seu ciclo de expiração; não anuncie exclusão concluída em toda a cadeia. A política precisa conciliar investigação, integridade da evidência e obrigações aplicáveis. Dados agregados também merecem avaliação quando grupos pequenos permitem inferir quem participou.

Mais conteúdo pode melhorar a reprodução de uma falha, e menos conteúdo pode proteger melhor o contexto. Não existe solução única para essa tensão. Uma alternativa a avaliar é uma captura diagnóstica temporária, autorizada para um caso delimitado, com expiração e leitores restritos. Ela não torna aceitável a captura permanente de todas as conversas.

Matriz mínima de validação

Esses testes são propostas defensivas. Passar neles não certifica privacidade, segurança ou conformidade. A evidência precisa incluir a configuração exercitada, a versão, o escopo e o limite remanescente, inclusive nos caminhos que não foram avaliados.

Mantenha uma lista de destinos e leitores exercitados. Não encontrar um marcador em um destino inspecionado é um resultado delimitado; não prova ausência de vazamento em componentes não testados. A OWASP inclui testes de falha do logging, controles de acesso e resistência a injeção entre as verificações recomendadas; a matriz acima é uma aplicação proposta ao caso de agentes.

A decisão que conecta engenharia e negócio

Uma observabilidade útil deve ajudar a entender qualidade, custo, falhas e recuperação sem criar um acervo indiscriminado de informações. Negócio define quais resultados merecem acompanhamento; engenharia demonstra como os sinais são produzidos; os responsáveis pelo domínio definem as condições de acesso e uso. Nenhuma dessas responsabilidades desaparece quando a ferramenta exporta um trace visualmente completo.

O AI RMF Core do NIST relaciona avaliação, monitoramento e tratamento de riscos ao longo do ciclo de vida. Aqui ele orienta a separação entre medir, interpretar e agir; não prescreve os três planos propostos nem certifica sua adoção.

Para uma revisão concreta, escolha uma ação de negócio e percorra autorização, execução, verificação, efeito e retirada dos registros com as pessoas responsáveis. Se a empresa precisar estruturar esse contrato, converse com a Trustyu sobre seu fluxo e suas restrições. O diagnóstico depende do caso; o artigo não promete prazo, conformidade ou resultado comercial.

Glossário de leitura

• Telemetria: sinais coletados sobre a execução, como métricas, logs e traces.
• Idempotência: propriedade que permite repetir uma operação sob um contrato definido sem repetir indevidamente o efeito; precisa existir no sistema que executa a ação.
• Recibo de efeito: referência verificável ao resultado observado no destino, diferente da intenção do agente ou do simples envio de uma chamada.
• Minimização: limitar a coleta e a circulação ao necessário para a finalidade definida.

Fontes e limites

1. OpenTelemetry — Handling sensitive data. Orientação de projeto de telemetria; não é auditoria de uma implantação Trustyu.
2. OWASP — Logging Cheat Sheet. Recomendações de logging, exclusão de dados e proteção; aplicação depende do contexto.
3. NIST — AI RMF Core. Referencial voluntário de responsabilidades e monitoramento, sem certificação implícita.
4. W3C — Trace Context, recomendação de 23/11/2021. Seções 6 e 7: privacidade e segurança da propagação de correlação; não é um contrato de autorização.

Nota editorial e de responsabilidade

As fontes foram consultadas em 20/10/2026. Os três planos, a matriz de validação e o contrato são propostas de engenharia do autor em preparação editorial, não resultados experimentais nem descrição de controles já operando. Pesquisa e redação tiveram assistência de IA. Autoria, revisão factual e aprovação final de publicação por Fernando Parreiras, com auto-revisão declarada. Esta versão não passou por revisão humana independente. Trustyu e Tech Human atuam comercialmente em engenharia e governança de IA. O conteúdo não substitui análise técnica, jurídica, de segurança ou de privacidade do caso concreto.