Retenção de atividades de agentes de IA: registros em que os investigadores confiam

Os agentes de IA transformam um problema conhecido de logging em um problema de evidências. Uma pessoa pode passar uma tarde clicando em um aplicativo; um agente pode fazer muitas chamadas externas enquanto um desenvolvedor ainda lê seu resumo. Se o registro disser apenas «o agente concluiu a tarefa», ele não responderá às perguntas que surgem depois de uma exclusão equivocada, de uma alteração inesperada em produção ou de uma transferência contestada.

Boas regras de retenção preservam os fatos necessários para reconstruir uma ação sem criar uma segunda cópia, mal protegida, de todos os segredos e registros de clientes que o agente encontrou. Essa distinção define o que será coletado, por quanto tempo ficará armazenado, quem poderá alterá-lo e quando a exclusão deverá ser interrompida.

A retenção começa com a pergunta que o investigador precisa responder

Um registro de atividade merece espaço de armazenamento quando responde a uma pergunta de investigação previsível. Comece pelas perguntas, não por um número padrão de dias copiado de outro produto.

Para um agente que pode chamar uma API HTTP ou abrir uma sessão SSH, os investigadores geralmente precisam estabelecer cinco pontos:

• Qual identidade de execução fez a solicitação e qual pessoa ou serviço autorizou a execução?
• Qual capacidade o agente tentou usar e contra qual destino?
• Que operação ele pediu ao destino para realizar?
• Qual foi o resultado, incluindo rejeição, tempo limite, sucesso parcial ou erro remoto?
• A equipe consegue demonstrar que o registro não foi editado discretamente depois do evento?

Essas perguntas separam evidências de ações do ruído operacional. Um gráfico de CPU pode ajudar a explicar um tempo limite, mas não comprova que um agente emitiu DELETE /customers/42. Uma transcrição do prompt pode explicar por que o agente considerou a exclusão apropriada, mas não prova que a solicitação chegou ao serviço remoto.

A publicação NIST Special Publication 800-92, Guide to Computer Security Log Management, trata o gerenciamento de logs como um ciclo de vida: gerar, transmitir, armazenar, analisar e descartar logs. A parte útil dessa orientação não é um prazo mágico de retenção. É a exigência de que a organização defina o objetivo dos logs e considere armazenamento, acesso e descarte. Equipes que trabalham com agentes costumam ir direto para a coleta porque coletar é fácil. A disciplina de acesso e descarte determina se esses registros ajudarão ou prejudicarão mais tarde.

Escreva uma declaração de investigação para cada classe de registro. Por exemplo: «Mantemos os resultados das ações pelo tempo necessário para identificar e reconstruir uma alteração externa não autorizada depois da detecção e da triagem normais». Essa declaração obriga a equipe a discutir de forma útil o período e os campos. «Manter todos os logs de agentes para sempre» evita a discussão e cria uma pilha permanente de material sensível.

Um registro pode atender a mais de uma finalidade, mas nomeie cada uma separadamente. Investigação de segurança, resposta a incidentes, suporte ao cliente, depuração de versões, reconciliação de cobrança e conformidade podem precisar de fatos e períodos diferentes. Se uma atividade de depuração de baixo valor mantiver uma carga útil completa por anos, a política de retenção falhou.

Um registro de ação precisa de contexto, não de uma transcrição

A retenção das atividades de um agente de IA depende primeiro do esquema de eventos. Capture o menor conjunto de fatos que permita a um investigador competente reconstruir a ação e associá-la a uma sessão, sem manter material de credenciais ou conteúdo irrelevante.

Eu uso quatro camadas de informação.

1. Contexto de identidade e autorização. Registre um identificador de evento imutável, horário com fuso, identificador do processo do agente, caminho do executável ou identidade do pacote, autoridade de assinatura do código quando o sistema operacional a expuser, identificador da sessão e a identidade do aprovador ou serviço associado à sessão. Registre a decisão de autorização e o modo de aprovação usado.
2. Ação solicitada. Registre o canal, o host de destino, a porta quando for relevante, o método HTTP e a rota normalizada ou a classe do comando SSH, o alias ou referência interna da credencial e uma descrição segura da operação solicitada.
3. Resultado observado. Registre sucesso, negação, cancelamento, tempo limite, falha de transporte, código de status remoto quando aplicável, classificação da resposta, bytes enviados e recebidos quando forem relevantes e um resumo redigido do erro.
4. Vínculos de evidências. Registre o hash do evento anterior, o hash do registro atual, a versão do esquema e os identificadores que associam tentativas relacionadas, repetições e ações posteriores.

A diferença entre um destino e uma solicitação importa. api.example.internal é um destino. PATCH /v1/users/42 é uma ação. Um log que contém apenas o host não consegue distinguir uma consulta ao inventário de credenciais da desativação de uma conta. Um log que armazena apenas um caminho pode omitir o ambiente de destino, que muitas vezes é a diferença entre um teste inofensivo e um incidente.

Normalize os dados antes de armazená-los. Coloque identificadores variáveis em um campo estruturado, em vez de obrigar os investigadores a interpretar texto livre. Registre route_template: "/v1/users/{user_id}" ao lado de um campo protegido target_identifier se o identificador for importante. Para SSH, diferencie um comando enviado pelo agente do comando remoto depois da expansão do shell, se o caminho de execução permitir observar os dois. Não afirme uma certeza que você não tem.

Um registro JSON prático pode ser assim:

{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}

Esse registro não contém o token bearer, um cabeçalho de autorização nem o corpo de uma fatura. Ainda assim, informa ao investigador que um processo assinado específico, durante uma sessão aprovada, tentou anular uma fatura em produção por meio de uma referência de credencial identificada e recebeu um 403.

Não esconda campos de alto risco dentro de um bloco details. Blocos de texto livre viram depósitos para prompts, cabeçalhos, dados pessoais e rastreamentos de erros. Eles também tornam impossível aplicar a retenção por classe. Se um campo tem um motivo para existir, dê a ele um nome, uma classificação, um grupo de acesso e uma regra de descarte.

Mantenha classes de evidências por períodos diferentes

Um único prazo para todos os registros de agentes é fácil de explicar e geralmente errado na operação. Mantenha evidências compactas de ações por mais tempo que conteúdos de diagnóstico detalhados, porque o registro compacto pode estabelecer o que aconteceu sem multiplicar a exposição.

Use classes que correspondam ao trabalho real de investigação. Um conjunto inicial possível é:

A tabela é um método, não uma afirmação de que toda equipe precisa de todas as classes. Se o agente apenas lê o status de uma compilação, talvez não haja motivo para uma classe de cargas protegidas. Se ele altera registros financeiros, um livro de ações que omita o identificador exato do alvo pode ser insuficiente.

Evite a recomendação comum de manter solicitações e respostas brutas «por precaução». Ela é popular porque facilita a depuração inicial e porque o armazenamento parece barato. O armazenamento não é a parte difícil. Acesso para pesquisa, alcance de um vazamento, solicitações de acesso do titular, garantias de exclusão e captura acidental de segredos são os custos altos.

Mantenha um resumo criptográfico do corpo quando precisar provar que um corpo específico foi usado sem preservar seu conteúdo. Um resumo sozinho não explica o significado e não ajudará se o corpo original não existir em outro lugar. Use-o para correlação e comparação posterior, não como substituto da descrição da ação.

Mantenha as tentativas malsucedidas e negadas. As negações muitas vezes revelam um agente tentando usar a capacidade errada, um caminho de aprovação quebrado ou um processo comprometido testando limites. Elas podem ter um período diferente do das ações bem-sucedidas se seu volume for muito maior, mas excluí-las primeiro porque «nada aconteceu» remove o contexto necessário depois de uma tentativa bem-sucedida.

Defina o período a partir da descoberta e da resposta, não do custo de armazenamento

Escolha um período de retenção voltando do último momento em que ainda espera investigar um evento. O cálculo não é elegante, mas torna as premissas visíveis.

Para uma classe de registros, some:

• o maior tempo plausível até a detecção;
• o tempo necessário para abrir, delimitar e atribuir uma investigação;
• o tempo necessário para obter registros relacionados de destinos ou fornecedores;
• qualquer obrigação contratual, regulatória ou legal aplicável à classe;
• uma margem moderada para notificações atrasadas e diferenças entre relógios.

Suponha que uma equipe descubra uma ação suspeita em produção durante uma revisão mensal, passe duas semanas confirmando o escopo e possa precisar de um mês para obter o histórico de um serviço remoto. Um período de retenção de ações de 30 dias já terá falhado antes do início da investigação. A resposta correta não é automaticamente um período de vários anos. A equipe deve escolher um período que cubra suas práticas reais de detecção e resposta e depois compará-lo com as obrigações das jurisdições e dos contratos aplicáveis.

Separe a regra da exceção. O cronograma normal deve excluir os registros automaticamente. Um bloqueio de caso deve preservar um conjunto definido de registros por causa de um incidente, disputa, auditoria ou instrução legal ativa. Quando o bloqueio terminar, a exclusão deve continuar conforme a política, em vez de deixar os registros indefinidamente porque ninguém se lembrou deles.

Não confunda retenção de backups com retenção de logs. Um backup de banco de dados que contenha registros de atividade excluídos pode mantê-los disponíveis muito depois de o aplicativo informar que os apagou. Documente se os backups são criptografados, quem pode restaurá-los, por quanto tempo duram e se uma restauração poderia reintroduzir registros removidos pelo processo de exclusão. Se não for possível eliminar um registro individual de backups imutáveis, declare isso na política e defina o período do backup de acordo com essa limitação.

Para sistemas que lidam com dados pessoais, consulte o departamento jurídico e o responsável por privacidade antes de definir um período. A legislação de privacidade normalmente não oferece um número universal adequado à atividade de agentes. Ela exige limitação de finalidade, minimização de dados e exclusão defensável. Uma justificativa vaga de segurança não autoriza manter conteúdo completo para sempre.

A evidência de adulteração precisa de um limite de confiança separado

Um registro que somente o mesmo administrador pode escrever e apagar oferece pouca segurança depois de um incidente grave. A proteção contra alterações exige prevenção e evidências de mudanças posteriores.

O controle AU-9 do NIST SP 800-53 exige a proteção das informações de auditoria contra acesso, modificação e exclusão não autorizados. Isso importa porque um armazenamento que parece imutável não resolve sozinho o controle de acesso, e o controle de acesso sozinho não revela toda alteração indevida. Construa as duas camadas.

Primeiro, separe a execução das ações da administração da auditoria. O processo que registra um evento deve ter permissão para anexar dados, não uma permissão ampla para reescrever ou eliminar o histórico. Administradores que gerenciam a retenção não devem editar casualmente o conteúdo de eventos individuais. Use um processo distinto e auditável para exclusões e correções.

Segundo, associe os registros em uma cadeia ordenada. Cada registro inclui um hash do registro anterior e um hash do próprio conteúdo canônico. Um editor que altera um evento antigo quebra a cadeia nesse evento e em todos os vínculos posteriores, a menos que consiga regenerar toda a sequência afetada. O encadeamento por hash é útil, mas tem um limite: um invasor que controle o escritor e todas as cópias armazenadas pode reescrever a cadeia inteira. Exporte pontos de verificação assinados para um local independente ou organize um processo de revisão que compare pontos de verificação fora do controle do escritor.

Terceiro, proteja o tempo. Os relógios dos sistemas sofrem desvios e podem ser alterados por invasores. Registre o horário de recebimento no coletor, use números de sequência monotônicos quando possível e trate os registros de horário como evidências a serem comparadas com registros externos, não como uma verdade isolada. A RFC 3161 define um protocolo para carimbos de tempo confiáveis. Ele pode fortalecer a prova de que um resumo existia em determinado momento, mas não prova que o conteúdo da solicitação estava correto ou autorizado.

Quarto, verifique em vez de apenas declarar a integridade. Um comando de verificação deve informar a primeira sequência inválida, o hash predecessor esperado, o hash predecessor observado e o identificador do registro. Esse formato dá ao operador algo acionável:

$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched

Quando a verificação falhar, preserve o armazenamento afetado antes que alguém o «corrija». Execute a verificação em um conjunto de dados copiado, capture a saída, identifique o último ponto de verificação válido e compare-o com exportações independentes. Corrigir a cadeia primeiro pode destruir as evidências da própria alteração.

Uma falha plausível revela o que logs superficiais escondem

Considere um agente de programação que recebe permissão para uma tarefa de desenvolvimento e depois tenta fazer uma chamada HTTP para um serviço de cobrança em produção. O gateway de ações rejeita a chamada porque a autorização da sessão cobre um processo diferente daquele que faz a solicitação. Alguns minutos depois, um desenvolvedor tenta novamente em outra execução do agente e aprova a ação sem perceber o destino em produção.

O serviço remoto retorna uma resposta 200. A transcrição do chat do agente diz apenas que ele «resolveu um problema de fatura». A equipe fica sabendo de uma reclamação de cliente três semanas depois.

Com um registro fraco, a equipe encontra uma chamada bem-sucedida de uma conta genérica «agent» e um horário genérico. Não consegue determinar se a primeira chamada negada veio do mesmo executável, se a aprovação ocorreu na mesma sessão, qual credencial foi selecionada, qual fatura foi afetada ou se alguém alterou o registro depois da reclamação. A equipe acaba pesquisando históricos do shell, exportações de chats e logs do serviço remoto que podem ter uma retenção menor que a do próprio sistema.

Com um registro útil, o investigador consegue reconstruir a sequência:

1. Um processo assinado iniciou uma sessão e recebeu uma aprovação vinculada àquela execução.
2. Um processo com identidade diferente tentou realizar a operação em produção e recebeu uma negação.
3. Uma sessão posterior usou uma referência de credencial específica, direcionou a solicitação ao host de produção, pediu a anulação de uma fatura para um identificador protegido e recebeu um resultado 200.
4. A cadeia de atividades foi validada contra um ponto de verificação criado antes da reclamação.

Isso não prova se o desenvolvedor pretendia realizar a ação. Mas estabelece quem aprovou qual processo, o que o caminho de execução fez e onde a investigação deve continuar. Os registros de auditoria devem resistir à tentação de narrar motivos. Eles devem preservar fatos que permitam às pessoas avaliar os motivos mais tarde.

Armazene um identificador de correlação entre as tentativas, mas não transforme todas elas em um único registro final de sucesso. Repetições podem mostrar uma mudança de destino, uma troca de credenciais ou um teste de limites antes de uma ação permitida. Esses detalhes importam quando a solicitação final causa dano.

A redação deve acontecer antes de os registros entrarem no livro de auditoria

Um armazenamento de auditoria criptografado protege os registros em repouso. Isso não torna aceitável registrar senhas, tokens de acesso, cookies de sessão, chaves privadas ou objetos completos de clientes. Quando um conteúdo bruto entra em um livro com retenção longa, todo futuro investigador, operador de restauração e responsável por resposta a vazamentos herda essa exposição.

Crie uma lista de campos permitidos para cada canal. Para HTTP, permita método, destino, modelo de rota, nomes selecionados de parâmetros de consulta seguros, tamanho do conteúdo, status e classe de erro. Descarte explicitamente Authorization, Cookie, Set-Cookie, tokens de API, segredos de cliente e cabeçalhos sensíveis conhecidos. Trate os corpos de solicitações e respostas como proibidos por padrão.

A redação baseada apenas em correspondência de padrões não detectará formatos novos de segredos e pode danificar as evidências. Use primeiro controles estruturais: não ingira campos que nunca deveriam estar presentes. Aplique a redação por padrões como segunda barreira para textos de erro ou dados fornecidos por serviços remotos. Mantenha uma versão da redação no evento para que os investigadores saibam quais regras foram aplicadas.

Os dados pessoais precisam da mesma disciplina. Um identificador de conta pode ser necessário para identificar o objeto afetado. Um perfil completo, documento ou transcrição de suporte raramente pertence a um livro geral de ações. A pseudonimização pode reduzir a exposição rotineira, mas não chame de anônimo um identificador reversível estável. Se alguém com outra tabela puder restaurar a identidade, ela continua sendo um dado pessoal para fins de governança.

Quando um caso realmente exigir conteúdo, crie uma captura de evidência restrita com identificador do caso, grupo de acesso nomeado, validade e data de revisão. Registre a existência da captura no livro de ações, mas não copie seu conteúdo para todos os relatórios posteriores. Assim, as investigações comuns continuam úteis sem dar a todos os leitores acesso ao material mais sensível.

Exclusões, bloqueios e correções também precisam deixar suas próprias evidências

A retenção é um processo operacional, não um parágrafo em uma política de segurança. Um cronograma que ninguém testa acabará se transformando em armazenamento permanente acidental ou em uma exclusão automática durante um incidente.

Execute a exclusão por meio de um trabalho registrado. Para cada execução, preserve a versão da política, a classe do registro, o intervalo de tempo selecionado, a quantidade de registros excluídos, a quantidade ignorada por causa de bloqueios, a identidade do executor e o resultado. O trabalho de exclusão deve seguir a mesma disciplina de anexação usada no registro de ações. Um operador não deve precisar de acesso direto ao banco de dados para «limpar» registros.

Um bloqueio precisa de um escopo que uma máquina possa aplicar. Defina-o por identificador do caso e intervalo de tempo do evento, identificador da sessão, destino, identidade do agente ou outro seletor estável. Evite bloqueios escritos como uma frase em um chamado, porque um trabalho de retenção não consegue avaliar uma frase. Registre a pessoa que aplicou o bloqueio, sua autoridade, a data de revisão e o evento de liberação.

As correções merecem o mesmo cuidado. Às vezes os sistemas registram uma rota interpretada incorretamente, um horário atrasado ou uma classificação enganosa. Mantenha o evento original intacto. Acrescente um evento de correção que nomeie o evento original, identifique a interpretação alterada, informe o motivo e identifique a pessoa ou o processo que fez a correção. Os relatórios devem mostrar a correção sem ocultar o registro de origem.

Teste o processo completo em uma cópia que não seja de produção: crie registros de todas as classes, aplique um bloqueio a parte do intervalo, execute a retenção, verifique a exclusão esperada, libere o bloqueio e execute a retenção novamente. Depois restaure um backup e confirme que ele não cria um arquivo oculto e acessível rotineiramente, em contradição com o cronograma declarado.

Uma política compacta é mais fácil de aplicar que um documento perfeito

Uma política de retenção deve caber no sistema que precisa executá-la. O modelo abaixo é intencionalmente simples porque cada afirmação corresponde a um responsável, um campo, um trabalho ou uma atividade de verificação.

Purpose: reconstruct externally executed agent actions and investigate misuse.

Action ledger: retain for [period].
Fields: actor identity, session, authorization decision, destination,
operation, credential reference, protected target identifier, outcome,
integrity fields. Exclude secrets and raw bodies.

Diagnostic detail: retain for [shorter period].
Fields: bounded error text and timing. Apply allowlist and redaction rules.

Protected evidence capture: case-only. Require case identifier, expiry,
access group, and documented approval.

Integrity: append records; verify chain [cadence]; export or compare
checkpoints [cadence]. Record verification failures.

Deletion: execute [cadence]. Record policy version, range, result, and holds.
Holds: suspend deletion for defined selectors. Review [cadence].
Corrections: append a correction record; never overwrite an action record.

Designe responsáveis identificados para o esquema de registros, o cronograma de retenção, a revisão de privacidade, os bloqueios de incidentes e as verificações de integridade. Uma pessoa pode exercer várias funções em uma equipe pequena, mas as responsabilidades ainda precisam ter nomes. Caso contrário, a pessoa que opera o agente se torna também a pessoa que decide quais evidências desaparecem depois de um incidente.

O Sallyport mantém um diário de Sessões e um diário de Atividades projetados a partir de um único log de auditoria criptografado e encadeado por hash, e sp audit verify pode verificar essa cadeia offline sobre o texto cifrado. Esse design só é útil se as equipes decidirem antecipadamente quais campos pertencem aos registros e como os trabalhos de retenção, bloqueios e exportações os tratarão.

Revise a política depois do primeiro incidente real ou de um exercício de simulação deliberado. Peça aos investigadores que reconstruam uma ação usando apenas os registros que teriam sobrevivido ao cronograma. Se precisarem de um segredo, de uma transcrição bruta ou da memória de um administrador para responder a perguntas básicas, altere o esquema. Se conseguirem responder às perguntas, mas cada registro carregar conteúdo de cliente, reduza o esquema antes que ele se torne permanente.