Diários de auditoria à prova de adulteração para agentes de IA que comprovam ações

Agentes de IA não precisam de uma transcrição de conversa melhor. Eles precisam de evidências produzidas no momento em que uma ação sai da máquina.

Essa diferença decide se você conseguirá responder a uma pergunta de incidente como «Este agente fez uma implantação em produção, com qual processo, sob qual aprovação e o que o sistema remoto retornou?». Um resumo da conversa não suporta esse peso. Um diário à prova de adulteração pode suportá-lo, desde que você seja preciso sobre o que ele prova e o que não prova.

Já vi equipes tratarem a saída do terminal de um agente como registro de auditoria porque era fácil salvá-la. Isso é inverter a ordem das coisas. A saída do terminal é útil durante a depuração, mas é uma evidência fraca: o processo que a escreveu pode ter falhado antes do efeito colateral, pode ter ocultado o argumento importante ou pode ter sido completamente substituído.

A resposta mais simples costuma ser a melhor.

Um gateway de ações deve criar o registro enquanto executa uma chamada HTTP ou um comando SSH, selar esse registro em um diário ordenado e tornar visíveis as alterações posteriores. Assim, o investigador tem um artefato que não depende da memória, do prompt ou da disposição do agente de admitir o que fez.

Uma transcrição e um diário de auditoria respondem a perguntas diferentes

Uma transcrição mostra o que o agente afirma ter tentado; um diário de auditoria mostra o que a fronteira de ação aceitou e retornou. Confundir esses dois artefatos deixa uma lacuna justamente onde o trabalho autônomo se torna arriscado.

Considere um agente que afirma ter executado terraform apply depois de abrir uma sessão SSH. Esse texto não prova que a conexão SSH foi bem-sucedida, que o comando chegou ao host pretendido ou que o host o aceitou. Pode ser um comando planejado, exibido antes da execução. Pode ser um comando que falhou na primeira linha. Também pode ter sido alterado posteriormente por um wrapper.

Um registro de ação útil reúne fatos de camadas diferentes:

• a execução do agente que solicitou a ação
• a identidade do processo local que recebeu autorização
• o canal e o destino, como o host SSH ou a origem HTTP
• um resumo normalizado da ação e o status do resultado
• a posição no diário e o hash do registro anterior

O registro não precisa virar um despejo de vigilância. Na verdade, gravar todos os corpos de solicitação e de resposta completos em um diário permanente costuma ser imprudente. Uma API de implantação pode retornar um token de acesso. Um comando SSH pode incluir um segredo temporário em uma atribuição de ambiente. Capture os fatos necessários para reconstruir a decisão de segurança e imponha limites rígidos à retenção de cargas úteis sensíveis.

A NIST SP 800-92 trata o gerenciamento de logs como um processo que abrange geração, armazenamento, análise e descarte, não como uma pasta onde os aplicativos despejam texto. Essa orientação antiga se aplica surpreendentemente bem aos agentes: a geração deve ocorrer no executor, o armazenamento precisa sobreviver ao incidente e a análise não pode depender da confiança no próprio ator investigado.

A fronteira de ação é onde a verdade fica mais restrita. Isso é bom.

Se um agente nunca recebe a credencial e, em vez disso, pede a um gateway local que faça a chamada, o gateway pode registrar a solicitação que realmente enviou. O agente ainda pode ser comprometido. Mas não consegue reescrever silenciosamente, de dentro do próprio contexto, o histórico de ações concluídas pelo gateway.

À prova de adulteração não significa imutável

À prova de adulteração significa que um verificador pode detectar certas alterações; imutável significa que ninguém pode alterar ou remover os dados. São promessas diferentes, mas os fornecedores costumam misturá-las porque «imutável» parece mais fácil de comprar.

Uma cadeia de hashes faz cada registro depender do registro anterior. Um registro simplificado poderia ser assim:

record_1042 = {
  sequence: 1042,
  run_id: "run_7f3c",
  time: "2026-03-18T14:22:09Z",
  action: "ssh.exec",
  destination: "deploy@release-host",
  result: "exit 0",
  previous_hash: "a4c1...",
  hash: "8d72..."
}

A implementação serializa os campos de forma determinística, calcula um hash sobre essa serialização e coloca o hash do registro anterior dentro do registro seguinte. Altere exit 0 para exit 1, mude o host ou reordene duas entradas, e a verificação falhará a partir desse ponto.

O Secure Hash Standard da NIST define algoritmos de hash aprovados que geram resumos de mensagem de tamanho fixo. Um resumo não é criptografia nem assinatura. É o material de vinculação compacto que faz um registro posterior depender dos bytes exatos dos registros anteriores.

Isso detecta alterações. Não detecta todas as formas de desonestidade.

Um invasor que possa reescrever o diário e recalcular todos os hashes posteriores consegue produzir uma cadeia que passa na verificação. Se apagar os 40 registros finais, pode deixar um prefixo anterior válido. Se mantiver duas cadeias separadas, pode mostrar históricos diferentes a revisores diferentes. A cadeia informa que uma sequência apresentada é internamente consistente. Sozinha, ela não estabelece que a sequência está completa ou é globalmente única.

Por isso contesto quando alguém chama uma cadeia de hashes local de «não repúdio». Ela não é. O não repúdio exige uma vinculação de identidade e uma história de verificação que continue válida mesmo contra a parte acusada de agir. Uma cadeia local ainda vale a pena, mas chame-a pelo que ela é: uma evidência forte contra alterações casuais e corrupção do armazenamento.

Uma cadeia precisa de um ponto de ancoragem fora do alcance de quem escreve

Uma cadeia de hashes fica muito mais difícil de reescrever quando alguém preserva pontos de verificação que o escritor do diário não pode substituir silenciosamente. Sem uma referência externa, o invasor que controla o escritor também controla o início da sua história.

Há várias formas de ancorar um diário. Elas diferem em custo e adequação operacional.

• Exporte pontos de verificação assinados para uma conta separada, com acesso de escrita estritamente limitado.
• Envie periodicamente as raízes do diário para um armazenamento de eventos de segurança que o host do agente não possa administrar.
• Replique segmentos criptografados do diário para um armazenamento offline ou somente de acréscimo.
• Faça um monitor independente guardar as raízes observadas e informar inconsistências.

Não confunda mais destinos com evidências melhores. Cinco cópias em buckets de nuvem controlados pelo mesmo administrador podem falhar juntas. A separação de autoridade importa mais que a quantidade de réplicas.

O Certificate Transparency oferece um modelo mental útil. A RFC 9162 usa árvores de Merkle para apoiar logs somente de acréscimo, provas de inclusão e provas de consistência entre cabeças de árvore publicadas. A RFC também declara claramente o ponto difícil: um log desonesto pode tentar mostrar visões inconsistentes a clientes diferentes.

Uma cadeia simples de hashes não é uma árvore de Merkle. Ela oferece verificação sequencial eficiente, não provas compactas para entradas arbitrárias nem um protocolo público de consistência. Em geral, esse é o equilíbrio certo para um único Mac executando um volume moderado de ações de agentes. Adicionar um serviço de Merkle só porque a palavra aparece em artigos sobre transparência é complexidade desnecessária, a menos que você tenha monitores independentes, muitos verificadores ou precise provar a inclusão em um diário compartilhado grande.

O custo da ancoragem é real. Você precisa operar outra fronteira de armazenamento, decidir a frequência dos pontos de verificação, lidar com indisponibilidades e manter metadados suficientes para associar um ponto de verificação a um diário local. Um ponto de verificação a cada ação gera tráfego e mais situações de falha. Um por dia deixa um intervalo longo em que pode ser difícil revelar um truncamento. Escolha um intervalo compatível com a velocidade com que ações indevidas se tornam caras.

Para credenciais de implantação em produção, eu prefiro ancorar cada ação privilegiada concluída a discutir se uma exportação diária é tecnicamente suficiente. Para chamadas de API somente de leitura e baixo risco, uma raiz periódica pode bastar.

A criptografia oculta o registro, não o histórico

Diários criptografados protegem os detalhes sensíveis das ações contra leitores casuais, mas a criptografia sozinha não diz nada sobre alterações nos registros. As equipes costumam criar uma propriedade, descrever as duas e perceber a diferença apenas durante uma investigação.

Suponha que uma entrada do diário contenha um caminho HTTP, o identificador de uma credencial de autorização, metadados da solicitação e um erro retornado. Criptografar essa entrada impede que alguém que roube o disco descubra qual endpoint de cliente o agente acessou. Mas não impede que um processo local privilegiado substitua o bloco de texto cifrado por outro bloco de texto cifrado. Você precisa de criptografia autenticada para cada registro e de uma cadeia entre os registros cifrados ou suas representações autenticadas.

O desenho mais limpo permite verificar a integridade sem expor o conteúdo. O verificador lê a sequência de registros criptografados, confere o enquadramento e as relações com os predecessores, recalcula a cadeia e informa se os bytes apresentados ainda formam o histórico esperado. Ele não precisa desbloquear o cofre de credenciais para concluir que o registro 1042 já não segue o registro 1041.

Essa separação ajuda durante a contenção. Um investigador pode copiar o diário, executar a verificação e preservar o resultado antes de pedir que alguém desbloqueie material sensível. A pessoa que faz o primeiro atendimento do incidente não deve precisar de acesso amplo às credenciais de implantação só para saber se as evidências foram alteradas.

A criptografia também exige uma decisão de retenção. Se ninguém puder descriptografar entradas antigas depois de uma migração de dispositivo, sua prova de integridade pode continuar intacta enquanto o diário perde seu significado operacional. Mantenha os procedimentos de recuperação e retenção separados do formato de auditoria. Não guarde o segredo de descriptografia ao lado do arquivo criptografado e considere o problema resolvido.

No macOS, a proteção apoiada por hardware pode reduzir a exposição dos segredos locais. A documentação de segurança da Apple descreve o Secure Enclave como um processador de segurança de hardware isolado, e a documentação para desenvolvedores da Apple observa que o material secreto em texto puro não pode ser transferido para dentro ou para fora do mecanismo do Secure Enclave descrito. Isso apoia o desenho de um cofre local, mas não autentica magicamente todos os processos do Mac.

O diário ainda precisa identificar qual processo recebeu aprovação e qual ação atravessou o gateway. A proteção de hardware protege uma fronteira. As evidências de auditoria precisam proteger várias.

A falha geralmente começa antes do comando perigoso

Um incidente plausível com um agente raramente começa com um comando que parece malicioso. Começa com uma solicitação banal que herda autoridade demais.

Imagine que um agente de programação receba uma tarefa para diagnosticar uma implantação com falha. Ele lê o repositório, encontra um script de implantação e abre um canal SSH para um host de lançamento. O primeiro comando é inofensivo:

systemctl status web.service

A saída inclui o caminho para um arquivo de configuração temporário. O agente então lê esse arquivo, encontra uma referência a uma credencial de implantação e executa um segundo comando que altera um valor de ambiente. O comando remoto retorna o código de saída 0. Vinte minutos depois, um cliente relata falhas nas solicitações.

Onde os controles poderiam ter interrompido ou revelado isso?

Primeiro, o bloqueio do cofre poderia ter impedido todas as ações externas enquanto ele estivesse bloqueado. Isso não decide se o comando era sensato, mas impede que um agente em segundo plano use credenciais depois que o usuário fechou a fronteira de segurança.

Segundo, a autorização da sessão poderia ter mostrado a identidade do processo do agente antes da primeira ação. É aqui que a autoridade de assinatura de código importa. Um processo de editor conhecido e um auxiliar não assinado iniciado a partir de /tmp não deveriam receber o mesmo tratamento só porque ambos falam MCP.

Terceiro, uma exigência de aprovação para a credencial do host de lançamento poderia ter interrompido a segunda ação. O aviso deveria mostrar contexto suficiente sobre o destino e a operação para que uma pessoa percebesse que aquilo já não era diagnóstico. Um botão genérico «permitir SSH» não atende a esse padrão.

Por fim, o diário precisa mostrar os dois comandos como ações concluídas distintas dentro da mesma execução. Se o registro do incidente contiver apenas «agente investigou uma falha de implantação», ele esconderá o momento em que a execução passou de observação para alteração.

Prefiro a aprovação a cada uso para credenciais capazes de alterar o estado da produção. É mais lento. Também força uma pessoa a encarar o momento específico em que uma tarefa de diagnóstico passa a ser uma mudança operacional.

Não exija um clique para toda solicitação inofensiva. As pessoas aprovarão uma parede de avisos idênticos sem lê-los, porque a interface as ensinará a fazer exatamente isso. Coloque o atrito no uso de credenciais cujo impacto potencial muda a cada chamada.

A identidade do processo pertence ao registro

Um diário de auditoria que diga «Claude Code usou SSH» é vago demais para resolver uma disputa. Você precisa saber qual processo local iniciou a execução, qual autoridade de assinatura o sistema operacional informou e se a aprovação abrangia aquela instância do processo.

Essa é outra definição que as equipes simplificam demais: identidade do aplicativo não é identidade do processo. Um nome de marca pode descrever um produto legítimo, enquanto uma extensão comprometida, um binário copiado ou um wrapper de shell invoca o mesmo protocolo a partir de um contexto executável diferente. A decisão de aprovação deve estar vinculada ao processo real que pediu para agir e expirar quando essa execução terminar.

O log deve registrar um identificador estável da execução e informações suficientes sobre a origem do processo para responder depois:

• O mesmo processo fez a primeira e a última solicitação?
• O usuário aprovou essa execução antes que ela realizasse a chamada?
• A execução foi revogada antes de chegar uma solicitação posterior?
• Um processo local não relacionado tentou reutilizar o canal?

Evite registrar um nome de exibição mutável como seu campo de identidade mais importante. Nomes mudam. Caminhos podem ser substituídos. Uma autoridade de assinatura ou identidade equivalente da plataforma é mais útil porque conecta a tela de aprovação, o diário da sessão e a investigação posterior.

Há um custo. Compilações legítimas de desenvolvimento, forks locais e ferramentas não assinadas gerarão mais trabalho de revisão. Isso não é um defeito do modelo de auditoria. É o preço visível de permitir que software experimental acesse credenciais reais. Decida se essas ferramentas deveriam usar uma credencial separada e de baixo privilégio, em vez de ensinar os revisores a ignorar detalhes de identidade desconhecidos.

O registro também precisa distinguir tentativas negadas de ações concluídas. Uma solicitação SSH negada é evidência de que um controle funcionou. Uma conexão malsucedida é evidência de um caminho tentado, não prova de execução remota. Uma solicitação concluída com resultado retornado é ainda mais forte. Não reduza esses resultados a um único booleano chamado success.

Um único diário para execuções e chamadas cria uma linha do tempo melhor

Eventos de sessão e eventos de ação devem ser projetados a partir da mesma fonte ordenada de verdade, embora os operadores os leiam por motivos diferentes. Arquivos de log separados, escritos por componentes separados, se afastam uns dos outros sob pressão.

A visão da sessão responde a perguntas sobre o ciclo de vida do agente: quando uma execução apareceu, a qual processo pertencia, se um usuário a autorizou e se alguém a revogou. A visão da atividade responde a perguntas sobre ações individuais: qual identificador de credencial foi selecionado, qual destino foi usado, se a chamada foi permitida e qual resultado retornou.

Essas visões não devem ser fontes independentes. Se uma ação aparecer sem a sessão, ou se uma execução revogada parecer continuar emitindo chamadas, o investigador precisará de uma única sequência para determinar se os dados são inconsistentes ou se o comportamento do sistema está errado.

É aqui que um diário criptografado e sem permissão de leitura prática oferece uma vantagem concreta. Os componentes podem acrescentar as informações que têm autorização para relatar, enquanto o formato do diário os impede de navegar casualmente por entradas não relacionadas. O ganho de segurança não vem de tornar os logs misteriosos. Vem de reduzir o número de caminhos de código capazes de ler, editar e reinterpretar registros históricos.

O Sallyport projeta os diários Sessions e Activity a partir de um único log de auditoria criptografado e encadeado por hashes, e sp audit verify verifica essa cadeia offline sobre o texto cifrado sem precisar desbloquear o cofre. Esse é o formato certo para evidências locais de agentes, porque o caminho de verificação continua disponível durante a contenção.

Ainda assim, eu exportaria pontos de verificação para ambientes de alto impacto. A verificação local informa se a cópia em mãos tem integridade interna. Um ponto de verificação externo ajuda a perceber que alguém entregou uma versão mais antiga e curta do histórico.

Mantenha a apresentação do diário separada da verdade do diário. Uma interface conveniente pode filtrar, agrupar e ocultar entradas para o uso diário. O verificador subjacente precisa operar sobre bytes estáveis e ordenação determinística, não sobre o que a interface atual decidiu exibir.

A verificação precisa ser rotina, não cerimônia

Um comando de verificação executado apenas depois de um incidente é um recurso que ninguém testou. Inclua-o na manutenção normal e torne o tratamento de falhas previsível.

Em uma instalação do Sallyport, a primeira verificação concreta é:

sp audit verify

Execute-o sobre uma cópia do diário antes de uma grande atualização, antes de apagar um Mac de desenvolvimento e quando suspeitar que o estado local mudou inesperadamente. Preserve a cópia exata do diário que foi verificada. Executar o comando novamente mais tarde em outra cópia não estabelece o que existia durante o incidente.

O comando sozinho não basta. Combine-o com uma rotina operacional simples:

1. Preserve a cópia do diário e sua referência de ponto de verificação antes da correção.
2. Registre o identificador da execução afetada e o intervalo de tempo investigado.
3. Compare as ações HTTP e SSH concluídas com os próprios logs do provedor remoto.
4. Revogue a execução ativa antes de pedir ao agente que faça a limpeza.
5. Verifique novamente depois da exportação ou transferência para confirmar que as evidências copiadas permaneceram intactas.

O terceiro item importa porque a integridade local e a verdade externa se complementam. Um diário válido pode mostrar que o gateway emitiu POST /deployments; o provedor da implantação pode mostrar se aceitou, colocou em fila ou rejeitou a operação. O status de saída do SSH pode dizer que um comando de shell terminou; os logs de serviço do host podem mostrar qual processo agiu depois.

Tenho pouca paciência para sistemas de auditoria que apenas renderizam eventos em um painel. Se você não consegue validar o diário armazenado sem o painel, tornou a resposta ao incidente dependente da mesma pilha de aplicativos que pode estar sendo questionada.

A verificação também deve falhar de forma evidente diante de segmentos ausentes, números de sequência inválidos, enquadramento malformado do texto cifrado ou divergência no predecessor. Uma ferramenta que ignora registros inválidos para produzir uma linha do tempo mais bonita é um triturador de evidências com boas maneiras.

Os registros de aprovação precisam do mesmo rigor que os registros de ação

Um clique de aprovação faz parte do evento de segurança, não é um detalhe decorativo da interface. Se o sistema registrar apenas que uma ação foi permitida, você não conseguirá estabelecer depois se a pessoa aprovou uma execução específica, uma categoria de credencial ou um prompt completamente diferente.

Armazene o contexto da decisão que a pessoa realmente viu: a identidade do processo solicitante, o escopo da aprovação, o identificador da credencial relevante e o horário. Para uma decisão no nível da sessão, registre quando a sessão começou e quando terminou ou foi revogada. Para uma decisão por uso, vincule a aprovação a uma única ação tentada para que ela não autorize silenciosamente um destino posterior.

Uma boa fronteira de aprovação envolve uma troca direta. Uma autorização de sessão mais ampla reduz interrupções e torna os ciclos autônomos utilizáveis. Uma autorização restrita a cada chamada oferece mais oportunidades para uma pessoa interromper uma decisão ruim, mas se torna exaustiva quando aplicada a leituras rotineiras. Nenhuma configuração é universalmente mais segura; o efeito da credencial determina o escopo sensato.

O modelo de três controles costuma ser suficiente: mantenha o cofre bloqueado até que o usuário o abra, autorize um processo identificado por uma sessão e exija confirmação explícita para credenciais selecionadas a cada uso. Uma linguagem de regras pode parecer mais sofisticada, mas cada condição se torna outra afirmação que as pessoas precisam testar durante uma implantação. Para um gateway de ações de desktop, eu escolheria um pequeno conjunto fixo de controles em vez de um mecanismo de políticas que ninguém consegue explicar às duas da manhã.

Essa escolha exclui alguns fluxos de trabalho. Você não consegue expressar toda exceção de ambiente ou política baseada em horário em uma sequência fixa de decisões. Equipes com uma frota de servidores e delegação complexa podem precisar de outro sistema. Fingir que um aplicativo focado na barra de menus deve se tornar um servidor geral de autorização é a forma de transformar uma fronteira de segurança objetiva em algo frágil.

Decida o que precisa provar antes de conceder acesso

A pergunta útil não é «Temos logs?». É «Qual afirmação precisaremos estabelecer quando essa execução der errado?».

Para cada credencial que um agente possa usar, escreva a afirmação em linguagem simples. Por exemplo: este processo assinado recebeu autorização para esta execução; esta execução chamou este endpoint de API; este comando SSH atravessou o gateway local; esta credencial estava bloqueada no momento de uma solicitação negada; estes registros não foram modificados desde o ponto de verificação retido.

Depois, teste o diário em um cenário incômodo. Apague suas últimas 50 linhas. Altere um campo de destino. Copie-o para outro Mac. Bloqueie o cofre e tente fazer a verificação. Revogue uma execução entre duas chamadas. Se você não conseguir dizer qual controle deveria interromper o evento e qual registro deveria mostrá-lo, tem observabilidade, não evidência.

Uma cadeia de hashes não torna segura uma credencial insegura. A criptografia não prova completude. Um prompt de aprovação não salva um revisor desatento. Cada controle tem uma função mais restrita.

Crie o registro onde a ação ocorre, proteja seu conteúdo, encadeie sua ordem, mantenha uma âncora além do alcance de quem escreve e pratique a verificação antes que um agente tenha acesso a qualquer coisa capaz de prejudicá-lo. Essa sequência é menos chamativa que um grande mecanismo de políticas. Também é muito mais fácil de defender quando alguém pergunta o que realmente foi executado.