Exportação da atividade do agente para revisão jurídica: como criar uma prova

Uma exportação da atividade do agente deve permitir que alguém de fora responda a quatro perguntas simples sem confiar na pessoa que a montou: quais ações ocorreram, quando ocorreram, se os registros foram alterados e quem controlou o material depois da coleta. A maioria das equipes consegue responder à primeira. As outras três são onde um incidente comum se transforma em uma discussão sobre evidências.

Não espere uma intimação judicial, uma disputa com um funcionário, um incidente de segurança ou uma reclamação de cliente para decidir o que preservar. Até lá, tarefas de retenção podem ter removido logs, pessoas podem ter aberto e reorganizado arquivos, e um engenheiro sob pressão pode ter exportado apenas os registros que pareciam relevantes. Isso é compreensível. Também é exatamente assim que um pacote de revisão perde credibilidade.

Este é um método prático para preparar registros de ações de agentes para advogados, investigações internas, revisões de conformidade ou um examinador externo. Ele não substitui aconselhamento jurídico. Mas oferece aos advogados algo muito melhor do que uma planilha com um nome tranquilizador.

Trate o pacote como evidência, não como relatório

Um pacote de evidências preserva o material de origem e explica como ele foi tratado. Um relatório seleciona, interpreta e constrói argumentos a partir desse material. Talvez você precise dos dois, mas misturá-los sem cuidado cria problemas.

Um relatório pode dizer: «O agente tentou executar um comando SSH neste host neste horário». O pacote de evidências deve permitir que o revisor encontre o registro da ação, veja como o horário foi representado, examine o resultado registrado, confirme qual sistema o produziu e verifique se a exportação foi alterada. O relatório deve ficar ao lado do pacote, não dentro da única cópia dele.

A distinção importa quando uma hipótese inicial se mostra errada. Os investigadores costumam estreitar o foco à medida que aprendem mais. Se exportaram um conjunto escolhido de eventos «ruins» e depois descartaram os registros ao redor, não poderão testar mais tarde se uma nova tentativa, uma aprovação, uma mudança de sessão ou uma ação do operador explica o evento. O contexto não é decoração. Muitas vezes, ele é a diferença entre uma ação realmente não autorizada e uma sequência enganosa de falhas comuns.

Defina o escopo da coleta antes de coletar. Escreva-o em uma frase curta que identifique:

• os identificadores de processo ou sessão do agente incluídos
• os canais de ação incluídos, como HTTP e SSH
• o início e o fim do período em UTC
• os sistemas ou contas abrangidos
• as exclusões conhecidas e o motivo de cada uma

Não amplie o escopo silenciosamente depois. Faça uma coleta complementar. Por exemplo, se o primeiro pacote cobrir uma janela de incidente de seis horas e um revisor solicitar depois o dia anterior, crie um segundo pacote com seu próprio manifesto e seus próprios hashes. Relacione-o ao primeiro pacote no registro de custódia. Assim, fica preservado o fato de que a primeira decisão tinha um limite.

É também aqui que as equipes cometem um erro grave: confundem uma visão de atividade com um registro completo da fonte. Um painel pode ser útil para a triagem, mas costuma aplicar filtros, paginação, preferências do usuário e limites de retenção que não aparecem em uma captura de tela. Colete os registros brutos ou a exportação de origem mais próxima disponível e produza as visualizações legíveis a partir desse material.

Separe autenticidade de completude

Autenticidade e completude são afirmações diferentes, e um bom pacote sustenta cada uma separadamente.

A autenticidade pergunta se determinado registro veio da fonte declarada e se alguém o alterou depois da coleta. Hashes, assinaturas, armazenamento somente para acréscimo e cadeias de hash ajudam com essa afirmação. A completude pergunta se o pacote contém todos os registros que deveriam estar dentro do escopo declarado. Consultas, contagens da fonte, configurações de retenção e notas de coleta ajudam com essa afirmação.

As equipes costumam exagerar o que um hash de arquivo prova. Um hash SHA-256 pode mostrar que activity.jsonl corresponde hoje à versão que você calculou antes. Ele não prova que o arquivo incluía todas as ações do período, que o relógio do sistema estava correto ou que o arquivo se originou no sistema citado no memorando. Um hash é uma excelente evidência de continuidade byte a byte. Não é um selo universal de verdade.

Da mesma forma, uma cadeia de auditoria pode revelar exclusões ou alterações dentro da sequência que cobre, mas não corrige uma definição de escopo ruim. Se você coletar apenas uma sessão do agente quando o incidente envolveu duas, uma cadeia intacta da primeira sessão não torna o pacote completo.

Use um manifesto para tornar essas afirmações verificáveis. O manifesto deve identificar a fonte, o escopo, o responsável pela coleta, o horário da coleta, o inventário de arquivos e o material de verificação. Mantenha-o em um formato de texto simples que não exija um aplicativo específico para ser lido.

case_reference: IR-2025-017
package_id: 2025-017-agent-actions-01
collected_at_utc: 2025-03-08T14:27:19Z
collected_by: employee-id-1842
source_system: macOS workstation, asset WS-042
scope_start_utc: 2025-03-07T18:00:00Z
scope_end_utc: 2025-03-08T02:00:00Z
channels: HTTP, SSH
included_files:
  - original/activity-records.jsonl
  - original/session-records.jsonl
  - original/audit-verification.txt
  - derived/action-timeline.csv
exclusions: Browser history and local shell history were outside this collection.

O diretório original deve conter o material de origem coletado. O diretório derived pode conter uma linha do tempo em CSV, um memorando de revisão ou uma cópia com redações. Essa separação evita um problema comum: alguém abre um arquivo JSON, salva-o em um editor que altera as quebras de linha ou a codificação de caracteres e depois descobre que o hash original não corresponde mais.

As Federal Rules of Evidence tratam da autenticidade na Rule 901, por meio de evidências suficientes para sustentar a conclusão de que um item é aquilo que seu apresentador afirma ser. A Rule 902(14) trata especificamente de dados certificados copiados de um dispositivo eletrônico, meio de armazenamento ou arquivo, quando uma pessoa qualificada os identifica por um processo de identificação digital. Essas regras não permitem que a equipe técnica pule a documentação. Elas fazem do processo de identificação parte da prova.

Congele a fonte antes de torná-la legível

Colete uma vez, preserve essa coleta e faça a classificação e a formatação em cópias. Isso parece excesso de cuidado até a primeira vez que um investigador precisa explicar por que um arquivo mudou depois que a equipe o declarou evidência.

Comece criando um diretório do caso com acesso restrito. Registre o local exato do sistema de onde os registros foram coletados, a conta usada na coleta e se a fonte continuou ativa depois dela. Se a fonte puder continuar recebendo eventos, anote isso. Um sistema ativo não é um elemento estático, e fingir o contrário produz linhas do tempo confusas.

Depois, faça uma exportação direta da fonte. Evite abrir arquivos em um programa de planilhas antes de calcular os hashes. Aplicativos de planilha reinterpretam datas, truncam valores longos, alteram delimitadores e tratam identificadores como números. Isso pode ser aceitável em um arquivo de análise de trabalho. É inaceitável na cópia preservada.

No macOS, calcule um inventário SHA-256 dentro do diretório do pacote, depois de colocar os originais nele:

find original -type f -print0 | sort -z | xargs -0 shasum -a 256 \u003e SHA256SUMS.txt
cat SHA256SUMS.txt

A saída terá uma linha por arquivo, com um resumo hexadecimal de 64 caracteres seguido pelo caminho do arquivo. Salve a saída do comando como parte do pacote e registre quem o executou. Mais tarde, verifique-a com o mesmo inventário:

shasum -a 256 -c SHA256SUMS.txt

Uma verificação bem-sucedida imprime cada caminho seguido de OK. Se um caminho imprimir FAILED, pare de tratar o pacote como inalterado. Preserve a cópia que falhou, documente o resultado e determine se a causa foi uma transferência, uma renomeação, uma conversão de quebras de linha ou uma alteração real. Não gere novamente o arquivo de hashes e continue em silêncio.

Os nomes dos arquivos devem ser simples e estáveis. Inclua o identificador do pacote, a categoria da fonte e o horário da coleta em UTC quando isso for útil. Evite nomes como final-final-v3 ou suspicious stuff. Um revisor não deve precisar de uma história contada oralmente para distinguir uma exportação original de uma planilha filtrada do analista.

A publicação NIST Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response, enfatiza a preservação dos dados e a documentação da coleta e do manuseio. Suas orientações são anteriores às ferramentas de agentes, mas a disciplina continua adequada. As ações dos agentes acontecem rapidamente; isso é motivo para anotações de coleta melhores, não para reduzir o padrão.

Registre os horários com o contexto do relógio

Um horário sem um relógio definido é um fato incompleto. Preserve o valor original do horário, seu fuso ou deslocamento, o nome do campo e qualquer identificador de ordem conhecido.

Use UTC como referência temporal do pacote. Escreva-o no formato ISO 8601, como 2025-03-08T14:27:19Z. Mantenha também os horários exatamente como foram exportados pela fonte. Se uma fonte mostrar o horário local, inclua o fuso configurado e informe se o sistema sincronizou o relógio por meio de um serviço aprovado. Não substitua um horário da fonte apenas porque a equipe prefere outro formato de exibição.

Uma ação do agente pode gerar vários horários. Um registro pode incluir o momento em que o agente solicitou uma operação, quando uma aprovação apareceu, quando uma pessoa aprovou, quando o sistema executou e quando um serviço remoto respondeu. Esses momentos não são intercambiáveis.

Para uma linha do tempo útil, identifique-os pelo tipo de evento em vez de juntá-los em uma única coluna timestamp. Uma solicitação às 10:00:01, aprovação às 10:00:28, execução às 10:00:29 e falha remota às 10:00:31 contam uma história diferente de uma execução que ocorreu antes da aprovação. A ordem pode confirmar ou derrubar uma alegação de controle humano.

Capture os identificadores de sequência quando existirem. Uma sequência de auditoria crescente, um número de chamada local da sessão ou um identificador de solicitação pode resolver empates quando dois registros têm a mesma precisão de horário. Se os registros fornecerem apenas horários no nível de segundos, diga isso. Não invente precisão de milissegundos registrando o horário da exportação.

Diferenças entre relógios merecem uma nota própria. Se a estação de trabalho local e uma API remota divergirem vários minutos, preserve essa observação e identifique as fontes. Não «corrija» um registro para deixar a linha do tempo mais limpa. Um revisor talvez precise testar depois se os sistemas usavam relógios diferentes ou se um evento atravessou um limite de horário.

O pacote de evidências deve incluir uma breve declaração temporal, por exemplo: «Todas as visualizações da linha do tempo usam UTC. Os valores da fonte permanecem nos arquivos originais. A estação de trabalho informou deslocamento UTC +00:00 durante a coleta. Nenhuma comparação independente de relógios foi realizada.» A última frase pode parecer insatisfatória, mas é honesta. Uma certeza sem suporte causa mais danos do que uma limitação documentada.

Preserve a ação e o contexto da decisão

Um registro de ação precisa de contexto suficiente para distinguir uma solicitação tentada, uma execução autorizada e um efeito externo concluído. São eventos separados.

Para atividades HTTP, preserve o horário da ação, o identificador da sessão ou do processo, o método, o host de destino, o caminho, os cabeçalhos relevantes da solicitação depois da remoção de segredos, o tratamento do corpo da solicitação, o status da resposta e os metadados do resultado. O pacote de revisão não deve conter tokens bearer reutilizáveis, senhas ou chaves privadas apenas porque passaram por um sistema de ações. Um segredo pode criar um segundo incidente dentro do processo de evidências.

Para atividades SSH, preserve o host de destino ou alias, a identidade do usuário usada pelo sistema de ações, o comando ou a categoria do comando quando registrada, o resultado da autenticação, o status de saída e a saída retornada, de acordo com uma regra de redação documentada. Se a saída puder conter dados de clientes, preserve o original sob acesso restrito e crie uma cópia de revisão que descreva cada redação. Barras pretas sem um registro de redações fazem os revisores se perguntarem o que mais desapareceu.

A identidade do processo importa tanto quanto a ação. Registre o processo do agente que iniciou a chamada, sua autoridade de assinatura de código quando disponível, seu identificador de sessão e a duração da sessão. A afirmação «foi o agente de programação» é vaga demais para uma revisão jurídica. Processos diferentes podem ter origens, aprovações e permissões diferentes, mesmo quando uma pessoa chama todos eles de agente.

Os registros de aprovação exigem uma redação cuidadosa. Uma aprovação significa que uma pessoa permitiu uma operação ou sessão definida de acordo com o desenho do sistema. Ela não prova que a pessoa leu todos os detalhes, entendeu todas as consequências ou tinha autoridade conforme uma política da empresa. Não faça essas afirmações sem evidências separadas que as sustentem.

O Sallyport registra as execuções dos agentes em um diário Sessions e as chamadas individuais em um diário Activity, com as duas visualizações projetadas a partir de um único log de auditoria criptografado e encadeado por hash. Esse desenho é útil para a revisão porque uma pergunta sobre a sessão e outra sobre a chamada podem apontar para a mesma sequência de registros subjacente.

Mantenha intacta a relação entre a solicitação original e o resultado. Uma chamada que falhou pode ser tão relevante quanto uma chamada bem-sucedida. Falhas repetidas podem mostrar um agente tentando novamente usar uma credencial bloqueada, um endpoint alterado ou um operador corrigindo uma configuração. Remover falhas para encurtar a linha do tempo costuma remover a explicação para o único sucesso que importa.

Verifique as evidências de adulteração enquanto a fonte ainda estiver disponível

Execute a verificação de integridade durante a coleta e salve a saída com os registros originais. Uma verificação posterior ainda tem valor, mas um resultado inicial conecta o pacote ao estado do sistema de logs no momento da coleta.

Um log encadeado por hash funciona vinculando cada registro ao material anterior por meio de dados criptográficos. Alterar, excluir ou inserir registros normalmente rompe a relação com os links posteriores. Isso oferece aos revisores uma propriedade específica para testar: se a sequência é verificada como emitida. Não prova que a ação registrada foi eticamente justificável nem que todos os eventos possíveis do sistema chegaram ao log. Mantenha essas afirmações separadas.

Para um log de auditoria do Sallyport, execute sp audit verify sobre a fonte coletada antes de confiar nas visualizações dos diários. A verificação pode ser executada offline sobre texto cifrado e não exige uma chave do cofre, permitindo que um investigador preserve um resultado de integridade sem obter as credenciais usadas para ações externas.

Salve a transcrição completa do terminal, incluindo o comando, o diretório atual, a identidade da conta se o seu procedimento a capturar, os horários de início e término e o status de saída. Uma captura de tela é mais fraca do que texto porque é difícil pesquisá-la, copiá-la e executá-la novamente de forma independente. Se o comando informar uma falha, preserve esse resultado. Não exporte apenas os registros que parecem estar íntegros.

A verificação precisa de condições reproduzíveis. Anote a versão do aplicativo, a versão do sistema operacional quando relevante e o caminho exato da coleta. Se a ferramenta de verificação depender de uma instalação local específica, preserve um registro dessa dependência. Você não precisa empacotar todos os executáveis por padrão, mas os revisores devem saber do que precisariam para reproduzir a verificação.

Uma nota simples de verificação pode dizer: «O responsável pela coleta executou o comando de verificação da auditoria em 2025-03-08T14:31:02Z contra o log de auditoria criptografado copiado em original/. O comando terminou com sucesso. A transcrição de terminal sem edição está em original/audit-verification.txt.» Se o comando não tiver terminado com sucesso, diga isso claramente e registre o efeito sobre o pacote. As evidências de integridade são úteis porque podem contradizer a explicação que você prefere.

Mantenha um registro de custódia que identifique pessoas e transferências

A cadeia de custódia é um registro cronológico de posse e controle. Não é uma página de assinaturas preenchida depois do fato, quando alguém pede uma.

Comece o registro quando o responsável pela coleta criar o pacote. Cada entrada deve informar o identificador do pacote, a data e o horário em UTC, a pessoa ou conta de serviço que transferiu o controle, o destinatário, a finalidade, o método de transferência, o local de armazenamento e o hash do pacote ou a referência ao inventário de hashes. Se uma pessoa mantiver a custódia durante toda a coleta, registre isso também.

Use nomes ou identidades internas estáveis que a empresa possa consultar depois. «Equipe de segurança» não é um custodiante. «Jane do jurídico» também não basta. Pessoas mudam de função, deixam empresas e se lembram dos acontecimentos de maneiras diferentes sob pressão.

2025-03-08T14:38:11Z
Package: 2025-017-agent-actions-01
Released by: employee-id-1842
Received by: legal-ops-id-77
Purpose: counsel review under incident hold
Method: encrypted internal file transfer
Integrity reference: SHA256SUMS.txt verified before transfer
Storage: matter workspace, restricted folder

Quando uma transferência usa armazenamento criptografado ou um serviço seguro de troca de arquivos, registre o método, mas não presuma que a criptografia prova a custódia. A criptografia protege a confidencialidade durante o transporte. A entrada de custódia estabelece quem transferiu e recebeu o pacote intencionalmente. Peça ao destinatário que confirme o recebimento e registre qualquer cópia posterior feita para um consultor, seguradora, órgão regulador ou advogado externo.

Os logs de acesso podem apoiar o registro de custódia, mas não o substituem. Um log de armazenamento pode mostrar que uma conta acessou um arquivo. Nem sempre ele explica por que a conta o acessou, se pertencia à pessoa esperada naquele momento ou se uma transferência aprovada ocorreu fora do sistema de armazenamento.

Evite enviar o único original por e-mail comum. O e-mail cria cópias sem controle, risco de encaminhamento automático, complicações de retenção e ambiguidade sobre as versões dos anexos. Se os advogados precisarem de uma cópia, crie uma cópia de distribuição documentada, verifique seu hash depois da transferência e preserve o original no local controlado.

A redação deve ser reversível no processo, não nos arquivos

Faça redações para um público e uma finalidade definidos, mas preserve um original sem redações quando a lei, a política e a investigação exigirem isso. Não transforme a versão com redações no único pacote sobrevivente.

Os registros dos agentes podem conter segredos, código-fonte, dados pessoais, dados de clientes, nomes internos de hosts ou detalhes operacionais que criam novos riscos quando compartilhados amplamente. A revisão jurídica raramente exige uma credencial de API reutilizável ou material de SSH privado. Exclua esses itens da cópia de revisão e explique como o processo de coleta os tratou. Se uma exportação da fonte contiver segredos, restrinja ainda mais o original em vez de distribuí-lo a todos os revisores.

Use um registro de redações com uma linha para cada item ou categoria consistente. Informe o arquivo, o identificador do registro, o campo, o motivo, a pessoa que fez a redação, a data e se o original continua disponível sob acesso restrito. O revisor deve conseguir distinguir um cabeçalho de autorização redigido de um resultado de ação removido.

Não dependa de sobreposições visuais em PDFs ou capturas de tela. Redações inadequadas já expuseram o texto subjacente muitas vezes para que isso seja tratado como um detalhe menor de produção. Crie um novo artefato de revisão a partir de uma cópia controlada, examine-o com ferramentas comuns de extração e verifique se o conteúdo sensível não aparece mais. Depois, calcule um hash separado para o artefato com redações. Esse hash não deve substituir o inventário original.

Uma linha do tempo filtrada pode ser útil, especialmente quando um caso abrange milhares de chamadas rotineiras. Identifique-a como um elemento derivado e inclua a lógica do filtro. Por exemplo: «Inclui chamadas para o tenant de cliente indicado entre os horários UTC informados; exclui todos os outros destinos; os registros de origem permanecem em original/activity-records.jsonl.» Essa frase permite que os advogados expliquem o que é o elemento sem afirmar que ele representa todo o histórico de auditoria.

Torne o pacote revisável seis meses depois

A pessoa que coleta o pacote talvez não seja a mesma que o explicará mais tarde. Escreva as notas de coleta para quem assumirá o caso depois que o chat do incidente desaparecer e o engenheiro original esquecer os detalhes.

Inclua um readme curto que responda a perguntas práticas: quais arquivos são originais, quais são derivados, qual ferramenta produziu cada exportação, como verificar os hashes, como interpretar os horários e onde o acesso ao original preservado é controlado. Mantenha opiniões em uma análise separada do incidente, a menos que o pacote as identifique claramente como uma declaração do analista.

O bloqueio do cofre, a autorização de sessão e as aprovações por chamada do Sallyport podem criar registros que ajudam a explicar o controle humano sobre uma ação. Preserve o nível exato de evidência de aprovação necessário para o caso e evite afirmar que um controle do produto responde a uma questão jurídica que pertence à política, à autoridade ou à intenção.

Faça um exercício de simulação antes que uma investigação force a questão. Peça a um colega que não coletou o pacote para usar apenas o readme, o manifesto, os hashes e a transcrição de verificação e responder: Quais registros da fonte estão incluídos? Posso verificá-los? Qual base temporal se aplica? Quem teve a custódia? Se esse colega precisar fazer perguntas básicas ao responsável pela coleta, o pacote não está pronto.

A primeira melhoria útil costuma ser pouco glamorosa: crie agora um modelo de diretório de caso, um manifesto em texto simples, um comando de inventário de hashes e um registro de custódia. Quando um incidente real chegar, esses quatro itens impedirão que uma exportação feita às pressas se transforme em uma história impossível de verificar.