# Como manter as evidências de agentes separadas das anotações do investigador

Uma investigação sobre agentes dá errado no momento em que uma pessoa analista transforma o arquivo de evidências em caderno de anotações. A tentação é compreensível. Você tem um registro de auditoria criptografado, uma solicitação externa estranha e um prazo. Descriptografa ou exporta o registro, acrescenta um comentário ao lado da chamada suspeita, reordena alguns campos para facilitar a leitura da linha do tempo e salva o resultado como registro do caso. Meses depois, ninguém consegue separar o que o agente fez daquilo que o investigador achou que isso significava.

Mantenha o registro criptografado original intacto. Coloque cada conclusão, pergunta, hipótese e correção em um arquivo de caso separado, que remeta a identificadores estáveis de sessão e chamada. Essa divisão parece excessivamente cuidadosa até alguém contestar a conclusão, uma segunda pessoa analista assumir o caso ou a área jurídica perguntar quais bytes existiam antes do início da investigação. Nesse momento, ela é a diferença entre um relato auditável e um documento persuasivo de histórico desconhecido.

## Evidência e análise respondem a perguntas diferentes

A evidência responde: "Que registro o sistema preservou?" As anotações do investigador respondem: "O que acho que esse registro significa?" São perguntas relacionadas, mas exigem tratamentos diferentes, pois a primeira precisa permanecer estável e a segunda precisa mudar conforme o caso avança.

Um registro de auditoria criptografado pode conter fatos desconfortáveis: um processo de agente invocou uma ação HTTP com credenciais, um comando SSH devolveu um resultado inesperado ou uma pessoa usuária aprovou uma execução que depois se comportou de modo diferente do esperado. O registro não é um rascunho. Não melhore sua redação, não remova entradas aparentemente irrelevantes nem reescreva um carimbo de data e hora em um formato mais amigável. Até uma edição inofensiva destrói a resposta clara para uma pergunta básica da revisão: este é o mesmo registro produzido pelo sistema?

As anotações devem continuar editáveis porque boas investigações se revisam. Uma anotação inicial pode dizer: "A chamada c-204 parece ter enviado dados de clientes." Depois de ler o contexto da solicitação e da resposta, a pessoa analista pode corrigi-la para: "A chamada c-204 enviou um identificador interno em um cabeçalho de solicitação. O registro não estabelece que dados de clientes deixaram o ambiente." Essa correção é saudável. Ela pertence ao arquivo do caso, onde permanece uma mudança de raciocínio, e não uma alteração da evidência.

A distinção que as pessoas costumam confundir é preservação versus legibilidade. Descriptografar, exportar, pesquisar, analisar e renderizar tornam a evidência utilizável. Isso não transforma o resultado no original. Uma exportação JSON, planilha, impressão em PDF ou transcrição copiada é uma derivação. Ela pode ser precisa e útil, mas precisa de uma etiqueta que diga como foi produzida e de qual objeto preservado veio.

Trate isto como uma regra de trabalho: o registro-fonte é somente leitura, e toda frase explicativa vive em outro lugar. Essa regra também torna a colaboração menos frágil. Uma segunda pessoa analista pode discordar da sua conclusão sem tocar na fonte, e quem revisa pode testar sua citação sem reconstruir seu histórico de edições.

## Identificadores estáveis tornam as alegações verificáveis

Uma conclusão deve citar a menor unidade estável que a sustenta. Em atividades de agentes, isso normalmente significa um identificador de sessão da execução do agente e um identificador de chamada para a ação individual. Use os dois quando a relação entre eles for relevante.

Um identificador de sessão responde: "De qual execução do processo do agente estamos falando?" Um identificador de chamada responde: "Qual ação HTTP ou SSH específica dentro dessa execução sustenta esta alegação?" Nenhum dos identificadores prova algo por conta própria. Eles são endereços duráveis. A prova vem do registro preservado nesse endereço, junto com sua explicação do que ele diz.

Não invente um esquema de identificação amigável quando o sistema já atribui um. Às vezes, analistas escrevem referências como "a terceira solicitação após a aprovação" ou "a solicitação perto das 14:00". Essas frases podem ajudar quem lê, mas não funcionam como citações. Uma linha do tempo muda quando a visualização é filtrada; relógios podem divergir; registros posteriores podem tornar "terceira" ambígua. Os IDs de sessão e chamada atribuídos sobrevivem melhor à ordenação, à exportação e à transferência do que atalhos em prosa.

Use uma tabela de alegações no arquivo de caso separado. Você não precisa de um produto de gestão de casos. Um documento estruturado simples basta, desde que preserve a diferença entre a alegação e a citação.

| ID da alegação | Conclusão do investigador | Referência de evidência | Status |
| --- | --- | --- | --- |
| C-01 | A execução do agente alcançou a API de pagamentos após sua primeira autorização. | Sessão `s-7f31`; chamadas `c-204`, `c-205` | Sustentada |
| C-02 | A solicitação alterou um registro de pagamento. | Sessão `s-7f31`; chamada `c-205`; registro de resposta | Não resolvida |
| C-03 | A pessoa pretendia essa alteração. | Registro de aprovação; nenhuma evidência de chamada estabelece intenção | Não sustentada |

Essa tabela faz duas coisas úteis. Primeiro, impede que uma citação seja confundida com explicação. Segundo, permite que a pessoa analista marque uma história atraente como não sustentada sem apagá-la. Isso importa quando um caso fica tenso. As pessoas frequentemente apagam teorias que falharam e depois não conseguem explicar por que a equipe as descartou.

Use exatamente os identificadores expostos pela fonte. Não presuma seu formato, comprimento ou unicidade global além do escopo documentado pelo sistema. Se um identificador só fizer sentido dentro de um diário coletado, registre ao lado dele o identificador do diário ou do pacote de evidências. Estável não significa mágico. Significa que outro investigador pode resolver a referência usando a mesma fonte preservada.

## Uma exportação legível é uma derivação, não o registro

A maioria das investigações precisa de uma visualização legível. Não é possível examinar bytes criptografados apertando os olhos, e ninguém deve fingir o contrário. Crie uma derivação para revisão, mas deixe explícita a relação dela com a fonte antes de começar a anotá-la.

Comece com uma entrada no registro de evidências. Registre a referência do caso, o nome do arquivo ou pacote original, quando e de onde ele foi coletado, quem o coletou, o escopo da sessão se conhecido e o resultado da verificação. Acrescente o comando usado na verificação e preserve sua saída de terminal junto dos materiais do caso. Não preencha lacunas com suposições. Se não souber quem coletou ou quando ocorreu a coleta, escreva "desconhecido" e abra uma questão.

O Sallyport projeta seus diários de Sessions e Activity a partir de um único registro de auditoria criptografado, encadeado por hash e cego para escrita. Seu verificador offline não precisa da chave do cofre, portanto um investigador pode verificar o material criptografado preservado antes de pedir que alguém exponha conteúdo legível:

```
sp audit verify <preserved-audit-record>
```

Registre no registro de evidências o comando real, seus argumentos, o status de saída e a saída completa. Não escreva uma linha fictícia de sucesso em um relatório porque um comando "deveria" ter funcionado. A saída faz parte do evento de verificação. Se a verificação falhar, deixe de tratar as interpretações posteriores como evidência estabelecida. Preserve o resultado da falha, colete novamente a fonte intacta se possível e explique a interrupção, em vez de trocar discretamente por uma exportação posterior.

Depois, crie uma derivação de revisão com um nome que diga o que ela é. Por exemplo:

```
case-2026-041/
  original/
    audit-record.enc
  verification/
    verify-command.txt
    verify-output.txt
  derivatives/
    activity-readable-2026-07-24.json
  notes/
    findings.md
    claim-table.md
```

Os nomes das pastas não constituem, por si só, uma cadeia de custódia. Eles incentivam um hábito útil: originais, material de verificação, derivações legíveis e análise não ocupam a mesma categoria conceitual. Restrinja o acesso de escrita ao diretório de originais. Se seus controles de armazenamento não puderem garantir isso, calcule e registre um resumo criptográfico quando seu processo de evidências permitir, depois crie uma cópia nova para análise. A ideia é tornar edições acidentais evidentes e permitir recuperação.

Não chame um arquivo transformado de "bruto" só porque você não editou manualmente o texto. Uma ferramenta que descriptografa, analisa, filtra, formata, normaliza fusos horários ou remove campos transformou a representação. Essa transformação pode ser perfeitamente legítima. Dê um nome a ela.

## Reserializar registros cria discussões impossíveis de vencer

Reserialização significa decodificar conteúdo estruturado e gravá-lo novamente. Investigadores fazem isso ao reformatar JSON, salvar uma planilha, regenerar um relatório ou canalizar dados por um analisador que escolhe sua própria ordem de campos e escape. Parece inofensivo porque o conteúdo semântico pode parecer idêntico. Em uma investigação contestada, "parece idêntico" é um padrão péssimo.

Suponha que uma pessoa analista exporte a atividade em JSON, ordene as chamadas por um horário local exibido, acrescente um campo `reviewed: true` e salve o arquivo como `audit-final.json`. Mais tarde, quem revisa percebe que dois eventos compartilham o mesmo segundo exibido, mas sua ordem original importa. A exportação já não informa se a ordenação preservou a ordem da fonte. Se houve um erro durante a análise, o arquivo alterado pode escondê-lo. A pessoa analista agora precisa defender uma cadeia de ferramentas e um fluxo de trabalho, em vez de apontar para um registro preservado.

Outro erro comum é a ocultação por substituição. Alguém troca um valor que parece uma credencial por `REDACTED` e depois distribui o registro editado como evidência. Isso cria dois problemas. O valor talvez não fosse uma credencial, e a cópia de revisão agora difere do original em um conjunto desconhecido de posições, a menos que a equipe tenha documentado todas as mudanças. Oculte informações em uma cópia para compartilhamento, rotule-a como derivação com informações ocultadas e retenha a fonte sob os controles de acesso adequados.

Anotações humanas também podem reserializar evidências por acidente. Um corpo de solicitação colado em um ticket pode perder escapes, espaços em branco, ordem ou caracteres não imprimíveis. Uma captura de tela pode ocultar conteúdo fora da área visível. Uma citação em relatório pode omitir a resposta que muda o significado da solicitação. Cite primeiro o ID da chamada. Transcreva somente o texto mínimo necessário para explicar a conclusão e diga que a citação veio de uma derivação legível.

Um bom arquivo de caso registra as transformações em uma linguagem que outra pessoa pode testar. Por exemplo: "D-03 foi produzida a partir do original O-01 após uma verificação offline bem-sucedida. O processo de exportação descriptografou o registro para revisão, limitou a visualização à sessão s-7f31 e não sobrescreveu O-01." Se você filtrou, diga isso. Se normalizou fusos horários, diga isso. Se uma ferramenta descartou campos, diga isso. É no silêncio que se esconde a lavagem acidental de evidências.

## Registros de aprovação limitam a alegação, não determinam o significado

Um registro de aprovação comprova algo mais limitado do que as pessoas gostariam. Ele pode mostrar que uma pessoa aprovou uma execução específica do processo do agente ou que aprovou o uso de uma credencial quando um controle por chamada exigia isso. Ele não prova que a pessoa leu cada ação proposta, entendeu todas as consequências ou pretendia a mudança comercial resultante.

Esse limite importa quando uma investigação chega a uma pergunta desconfortável: "A pessoa usuária autorizou isto?" Não responda com uma única palavra. Divida a afirmação. A pessoa pode ter autorizado o processo a operar naquela sessão. O processo pode ter usado uma credencial depois. A solicitação pode ter sido bem-sucedida. Ainda assim, a ação resultante pode ter ultrapassado o que a pessoa acreditava estar permitindo. A evidência pode sustentar algumas dessas proposições e deixar outras em aberto.

A escala de decisões do Sallyport torna essas distinções concretas. Um cofre bloqueado nega todas as ações. A autorização por sessão, ativada por padrão, aprova uma execução de processo de agente recém-encontrada até que ela termine. Uma configuração de chave por chamada exige aprovação para cada uso daquela credencial. Uma investigação deve identificar qual controle se aplicou e declarar somente o que esse controle estabelece.

Escreva as conclusões deixando esse limite visível. "A evidência mostra que a pessoa usuária aprovou o processo assinado da sessão s-7f31" é uma alegação sobre autorização de sessão. "A evidência mostra que a pessoa usuária aprovou a chamada c-205" exige um registro de aprovação por chamada para essa chamada. "A pessoa pretendia alterar um registro de pagamento" exige evidência sobre intenção, que pode estar totalmente fora do diário de ações. Não transforme a primeira frase na terceira só por conveniência.

Há uma recomendação comum que rejeito: tratar todas as aprovações como evidência equivalente de consentimento informado. Ela é popular porque produz um veredito simples. Está errada porque os controles têm escopos diferentes. Uma aprovação no nível da execução e uma aprovação no nível da ação respondem a perguntas diferentes, e nenhuma delas lê a mente de alguém.

## Crie anotações que possam mudar sem contaminar o caso

Suas anotações devem convidar à correção e, ao mesmo tempo, deixar visíveis autoria e data. Uma boa conclusão contém uma alegação, uma razão, citações, limites e uma classificação. Ela não precisa de uma voz narrativa teatral.

Use um formato como este:

```markdown
Finding: The agent called the payment API after session approval.

Claim: Session s-7f31 included a credentialed HTTP call to the payment API.
Evidence: Session s-7f31; call c-205; derivative D-03.
Reasoning: The call record identifies the configured HTTP channel and the destination represented in the record.
Limits: This record does not establish the human's business intent or the full downstream effect.
Analyst: initials
Recorded: 2026-07-24T18:32:00Z
Status: supported
```

A palavra "raciocínio" merece estar ali. Uma lista de IDs não é uma conclusão. Declare a conexão que você infere e o que o registro não consegue estabelecer. Quem lê confia mais em uma conclusão quando seu limite está escrito com clareza.

Não incorpore anotações pessoais mutáveis em nomes de arquivos de evidência ou metadados de objetos. Um nome como `bad-call-confirmed.enc` transforma uma opinião em aparente verdade da fonte. Use nomes neutros, como `O-01-audit-record.enc`, e coloque a opinião em `F-04-findings.md`. Isso evita problemas quando "confirmada" se torna "não sustentada" após uma segunda revisão.

Mantenha observações e conclusões separadas nas anotações. Uma observação pode dizer: "O registro de atividade de c-205 informa uma resposta bem-sucedida." Uma conclusão pode dizer: "O agente provavelmente concluiu a ação solicitada." A primeira depende do conteúdo do registro. A segunda depende do que uma resposta bem-sucedida significa para essa API e pode exigir documentação da API ou um registro de sistema independente. Marcar esse limite evita que analistas apresentem interpretação como fato alegado.

Se várias pessoas trabalharem no caso, deixem que discordem nas anotações. Dê a cada conclusão concorrente um ID de alegação e referências de evidência. Não transforme a discordância em uma frase de consenso sem conteúdo. Uma revisão posterior deve mostrar se a evidência resolveu a divergência ou se a equipe apenas deixou de discuti-la.

## Uma linha do tempo que falha geralmente começa com uma edição inofensiva

Considere um incidente em que um agente de programação acessa uma API interna de implantação. A pessoa operadora percebe uma alteração desconhecida e exporta o diário de atividade para uma planilha. Para facilitar a leitura, ela ordena as linhas pelo horário local, exclui campos que parecem repetitivos e destaca a linha considerada a causa. Em seguida, acrescenta um comentário, "O agente implantou configuração não aprovada", e envia a pasta de trabalho para a equipe de resposta.

O primeiro problema surge quando outra pessoa analista pergunta qual processo fez a chamada. A planilha contém um ID de chamada, mas a coluna de ID de sessão era um dos campos "repetitivos" excluídos. A equipe não consegue distinguir rapidamente uma execução de outra. A pessoa operadora se lembra de que todas as linhas vieram da mesma execução, mas memória não é citação.

O segundo problema surge quando a equipe compara a ação a uma aprovação. A pasta de trabalho mostra um horário de aprovação próximo, mas não preserva contexto suficiente para estabelecer se a aprovação se aplicava à execução ou àquele uso individual de credencial. O comentário já moldou a discussão, então as pessoas começam a discutir se a ação não foi aprovada, em vez de primeiro perguntar que tipo de aprovação a evidência registra.

O terceiro problema surge quando a equipe de implantação diz que a resposta da API significava "aceito para processamento", e não "configuração implantada". A linha destacada era real. A conclusão era ampla demais. Como a pessoa operadora a colocou dentro do artefato que parecia evidência, quem leu tratou-a como uma propriedade do registro, e não como uma interpretação falível.

Uma reconstrução mais limpa é diferente. Preserve o registro de auditoria criptografado como O-01. Execute `sp audit verify` contra O-01 e salve o resultado do comando. Crie D-01 como visualização legível. No arquivo de caso, escreva três alegações separadas: qual sessão fez qual chamada, qual escopo de aprovação se aplica e o que a resposta estabelece. A terceira alegação pode exigir um registro do sistema de implantação. Se continuar sem solução, deixe-a sem solução. Isso não é uma investigação incompleta, é uma investigação honesta.

O detalhe que salva esse caso é simples: a chamada c-205 não é a mesma coisa que a frase escrita sobre a chamada c-205. Uma é uma referência a atividade preservada. A outra é uma conclusão com autor, data e possibilidade de estar errada.

## A verificação deve ocorrer antes que a interpretação se consolide

Verifique o material de auditoria preservado antes que a equipe construa uma história em torno dele. Quando uma teoria circula no chat, em tickets e em reuniões, as pessoas começam a ler os registros para defendê-la. A verificação então vira um ritual feito depois que a conclusão ganha peso social.

A sequência deve ser simples. Colete a fonte sem alterá-la. Registre de onde ela veio e quem a manipulou. Verifique o material criptografado com o comando offline compatível. Preserve o resultado da verificação. Crie uma derivação legível identificada somente depois disso. Então comece a tabela de alegações e as anotações.

A verificação por cadeia de hashes é especialmente útil porque verifica o registro criptografado armazenado sem exigir a chave do cofre. Isso separa duas perguntas que as pessoas costumam juntar: "O registro manteve a integridade de sua cadeia?" e "Quem tem permissão para ler o conteúdo sensível?" Um investigador pode responder à primeira sem ampliar o acesso a segredos apenas para realizar uma verificação básica de integridade.

Um resultado de verificação bem-sucedido não resolve a identidade da fonte, a completude fora do intervalo coletado nem a interpretação. Ele informa que o verificador aceitou a cadeia apresentada. Registre o escopo que você realmente coletou. Se o caso tratar de uma lacuna suspeita anterior à primeira sessão retida, não escreva "a auditoria não mostra nenhuma ação anterior" a menos que você saiba que a coleta contém o histórico anterior relevante. A frase defensável é mais limitada: "O registro coletado não contém ação anterior desse tipo."

A mesma disciplina vale para revogação. Uma sessão pode ser revogada no diário, mas esse registro descreve o evento de controle e seu escopo registrado. Ele não explica automaticamente ações concluídas antes da revogação, trabalho já aceito por um serviço externo ou efeitos colaterais fora da resposta do canal. Vincule cada proposição ao registro que pode sustentá-la.

## Coloque o arquivo de caso sob revisão, não a fonte sob alteração

A evidência deve permanecer estável. As conclusões devem passar por revisão. Faça as pessoas revisoras questionarem a ligação entre cada conclusão e a sessão ou chamada citada, em vez de pedir que comparem versões sem explicação de uma exportação modificada.

Uma revisão útil faz quatro perguntas diretas:

1. Consigo localizar cada sessão e chamada citadas no registro preservado ou em uma derivação documentada?
2. A conclusão distingue o evento registrado da inferência da pessoa analista?
3. O escopo de aprovação declarado corresponde à conclusão extraída?
4. A autoria nomeou alguma transformação, filtro, ocultação ou contexto ausente que afete essa alegação?

Se uma pessoa revisora não conseguir responder a uma dessas perguntas, a correção pertence ao arquivo de caso, a menos que a própria fonte preservada tenha sido coletada incorretamente. Não ajuste uma derivação até que ela pareça a narrativa desejada. Corrija o processo de derivação, produza uma nova derivação identificada e retenha a anterior se ela tiver informado uma conclusão relevante.

Para equipes que usam Sallyport, os diários de Sessions e Activity oferecem aos investigadores dois níveis naturais de citação, enquanto a revogação instantânea de sessão fornece um evento de controle separado para examinar. Use esses registros como âncoras, não como substitutos da análise. O diário pode dizer o que registrou. O arquivo de caso deve explicar o que a equipe pode concluir de forma responsável a partir dele.

A primeira ação depois da coleta deve ser simples e precisa: reserve um original, verifique-o e abra ao lado dele um arquivo de conclusões vazio. Escreva a primeira conclusão somente depois de poder citar a sessão e a chamada que a sustentam. Esse pequeno cuidado evita meses de discussão sobre se a evidência mudou durante a investigação.