Escreva logs de auditoria sem acesso de leitura para agentes de IA, que eles não podem editar

Um agente de IA pode escrever uma explicação bem elaborada do próprio trabalho depois de tomar uma decisão ruim. Essa explicação não é uma evidência. Se o agente puder ver, selecionar, revisar ou evitar os registros usados pelos revisores para avaliá-lo, o registro de auditoria se torna outra superfície de saída que o agente pode otimizar.

Os logs de auditoria sem acesso de leitura para quem escreve resolvem um problema específico, mas importante: o processo que solicita uma ação externa não deve controlar o registro dessa ação. O sistema de ações registra o que observou, devolve o resultado necessário ao agente e mantém o registro para revisão fora do alcance dele. Isso não torna o agente honesto. Torna um agente desonesto, confuso ou comprometido menos capaz de montar a história depois do ocorrido.

Essa distinção é mais importante quando um agente pode implantar código, chamar APIs pagas, alterar configurações de nuvem, enviar e-mails ou executar comandos SSH. Nesses casos, uma transcrição de chat é uma evidência fraca. Ela registra alegações e saídas de ferramentas selecionadas. Um registro gerado no ponto de aplicação das regras pode registrar a solicitação, a autorização, a execução e o resultado, mesmo quando o agente preferiria o silêncio.

O agente não pode controlar a ação e a evidência ao mesmo tempo

Um agente deve ter menos poderes sobre as evidências do que tem sobre a tarefa. Dar a ele um arquivo chamado audit.jsonl e pedir que acrescente registros cria um diário de atividades, não um log de auditoria. Ele pode esquecer uma linha, ocultar um argumento inconveniente, registrar sucesso antes de a chamada falhar ou criar uma segunda cópia que o revisor nunca verá.

O problema aparece até com agentes que seguem instruções. Um agente costuma decidir quais ferramentas chamar, qual exceção capturar e qual contexto manter. Uma injeção de prompt pode instruí-lo a não registrar uma solicitação. Um bug pode enviar uma solicitação por uma biblioteca sem instrumentação. Uma dependência maliciosa pode escrever diretamente na rede. Se o mesmo processo for dono da ação e do registro, qualquer uma dessas falhas poderá deixar um rastro organizado, porém incompleto.

Separe explicitamente estas capacidades:

• O agente solicita uma ação e recebe um resultado limitado.
• O executor mantém a credencial, envia a solicitação e cria o registro do evento.
• O diário aceita registros por um caminho que o agente não pode ler nem modificar.
• Um revisor lê e verifica os registros por uma interface separada.

Essa é uma fronteira de capacidades, não uma promessa sobre comportamento. O agente não deve ter acesso aos arquivos do diário, uma API de consulta para suas entradas, credenciais que permitam reescrevê-lo ou uma forma de definir o horário do evento. Se precisar explicar seu raciocínio, armazene essa explicação em um artefato separado da execução e identifique-a como material fornecido pelo agente. Não a misture com o registro da execução.

As equipes frequentemente confundem intenção e evidência. Intenção é o que o agente diz que pretendia fazer: «reiniciar o serviço de staging». Evidência é o que um componente de execução observou: o agente solicitou um comando específico em determinado horário, uma decisão de aprovação ocorreu, o executor se conectou a uma referência de host e o comando terminou com um status específico. Ambos são úteis. Eles respondem a perguntas diferentes e precisam de níveis de confiança diferentes.

Escrever sem acesso de leitura significa separar capacidades, não atrasar a visualização

Escrever sem acesso de leitura significa que o ator pode fazer um registro existir sem obter acesso ao registro armazenado ou ao contexto futuro de revisão. Isso não significa que o agente não receba retorno. Uma tarefa SSH ainda precisa de stdout, stderr e status de saída. Uma tarefa HTTP ainda precisa do status e do corpo da resposta, ou de uma extração limitada. Remover os resultados torna o agente inútil sem fortalecer as evidências.

A fronteira tem quatro partes práticas. Primeiro, o agente usa uma interface de solicitação, não uma credencial. Segundo, o executor cria um registro a partir das próprias observações, em vez de confiar em um objeto JSON fornecido pelo agente. Terceiro, o agente não pode listar, buscar, modificar ou excluir registros. Quarto, um revisor pode inspecionar o registro depois sem depender da memória do agente ou do histórico do chat.

Um projeto de leitura adiada não atende a esse padrão. Suponha que um agente escreva eventos em um banco de dados e receba a promessa de que não poderá consultar a tabela até o fim da sessão. Ele ainda conhece o esquema. Pode adaptar strings de argumentos, escolher omissões, provocar falhas de transação e usar diferenças no tempo dos erros para descobrir se um registro foi gravado. Também pode ter credenciais do banco que outro caminho de código consiga abusar.

A separação de leitura é mais forte quando o caminho dos eventos não oferece uma resposta que exponha o estado do diário. O executor pode confirmar a ação solicitada, mas não deve devolver IDs de eventos, números de sequência, anotações de revisores, classificações de risco ou uma confirmação de que determinado registro se tornou permanente. Esses detalhes dão ao ator material para otimizar seu comportamento.

Isso não exige tratar todo agente como hostil. Um agente pode se tornar inseguro por motivos comuns: uma instrução injetada, um loop descontrolado, um bug de ferramenta, uma dependência desatualizada ou um operador que concede uma tarefa ampla demais. O projeto deve resistir a mais do que boas intenções.

Um log somente para acréscimos não resolve o problema sozinho

O armazenamento somente para acréscimos detecta alguns tipos de adulteração. Ele não prova que o gravador viu todas as ações relevantes nem impede que um agente organize registros enganosos antes do armazenamento. As equipes frequentemente compram armazenamento imutável e deixam credenciais de rede diretas no ambiente do agente. A lacuna central permanece.

Considere dois caminhos de implantação. No primeiro, o agente lê um token de API de uma variável de ambiente e chama diretamente o serviço de implantação. Uma biblioteca separada tenta registrar a solicitação. O agente pode contornar a biblioteca, criar outro processo ou usar um cliente HTTP diferente. O log pode continuar perfeitamente somente para acréscimos, enquanto a implantação nunca aparece nele.

No segundo, o agente pede ao executor que faça a implantação, mas nunca recebe o token. O executor é o único caminho que pode anexar a credencial. Ele registra a solicitação antes da transmissão e atualiza o evento depois da resposta. O diário só consegue descrever ações que passaram pelo executor, mas o agente não tem uma rota autorizada para contorná-lo.

A RFC 6962, especificação de Certificate Transparency, descreve uma árvore de hashes de Merkle que permite provar com eficiência que uma folha pertence a uma árvore e que uma árvore mais nova estende uma anterior. Esse é um padrão útil de integridade. Ele não afirma que a árvore prova a captura completa dos eventos do mundo real. Uma solicitação de implantação que nunca entrou na árvore não pode aparecer em uma prova de inclusão.

A mesma limitação vale para uma cadeia linear de hashes. Um registro pode incluir o resumo do registro anterior. Se alguém editar, remover ou reordenar registros armazenados, a verificação falhará no ponto afetado. Ainda assim, uma cadeia íntegra pode cobrir apenas um subconjunto cuidadosamente escolhido das ações. Coloque o gravador no caminho da ação antes de comemorar a cadeia.

Há uma segunda limitação: administradores também podem ameaçar o registro. Se um operador puder alterar o banco de dados de logs e redefinir a raiz da cadeia sem uma testemunha externa, o projeto protegerá principalmente contra mudanças casuais. A verificação offline, pontos de controle protegidos e a separação de acessos dão aos revisores uma base melhor para confiar. Nenhuma dessas medidas transforma um log em um relato completo de tudo o que aconteceu em uma máquina.

Coloque o gravador no caminho da execução

O gravador deve observar a ação no ponto em que as credenciais são anexadas e a solicitação externa deixa o sistema controlado. Registrar na camada do framework do agente é cedo demais. Registrar apenas no serviço remoto costuma ser tarde demais e pode omitir o contexto de autorização. O gateway de execução consegue ver tanto a solicitação aceita quanto o resultado recebido.

Para HTTP, esse gateway deve aceitar uma solicitação limitada, selecionar uma credencial armazenada, anexá-la por conta própria, enviar a solicitação e devolver uma parte permitida da resposta. O agente não deve enviar cabeçalhos Authorization brutos. Deve referenciar uma credencial por um nome interno que o gateway resolve.

Um formato de solicitação pode ser pequeno o bastante para ser inspecionado e registrado:

{
  "action": "http.request",
  "credential_ref": "deploy-api",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "headers": {"content-type": "application/json"},
  "body": {"revision": "a18f3c"}
}

O executor deve rejeitar cabeçalhos de credencial fornecidos pelo chamador nessa rota. Isso impede que um agente esconda outro token na solicitação enquanto deixa uma credential_ref enganosa no diário. Ele também deve normalizar a URL antes de registrá-la, pois uma URL bruta pode conter informações de usuário, truques de caminho codificados ou um segredo acidental em um parâmetro de consulta.

Para SSH, a mesma regra vale. O agente pede a execução de um comando em uma referência de host. O executor escolhe a identidade configurada, o comportamento de verificação do host e o método de conexão. Se o agente puder ler uma chave privada e chamar seu próprio cliente SSH, o sistema de auditoria não poderá mais afirmar que cobre suas ações remotas.

Não confunda um gateway com um proxy de uso geral. Um proxy tenta observar um tráfego amplo. Um gateway de ações oferece um conjunto definido de ações e mantém a autoridade para executá-las. Esse formato mais restrito facilita dizer o que o registro significa: este executor aceitou esta ação sob esta autorização e obteve este resultado.

Registre um evento antes que o mundo externo possa responder

Um registro confiável precisa de um evento de início antes de o executor enviar a ação e de um evento de conclusão depois que recebe um resultado. Se você só gravar um registro após o sucesso, um timeout, uma falha, o encerramento do processo ou uma interrupção da rede poderá fazer uma solicitação séria desaparecer do histórico.

Use um único identificador de ação gerado pelo executor, não pelo agente. O registro inicial deve conter o identificador da sessão, a identidade do processo executor, o tipo de ação, o destino normalizado, o resumo seguro da solicitação, a decisão de autorização e um horário gerado pelo gravador. Marque seu estado como started.

Depois que o executor receber uma resposta ou falha, ele grava um registro de conclusão que referencia o mesmo identificador de ação. Deve incluir uma categoria de resultado como succeeded, rejected, timed_out, transport_error ou executor_error, além de um resumo da resposta e metadados limitados. Assim, o revisor pode distinguir «o gateway rejeitou» de «o sistema remoto pode ter recebido, mas nenhuma resposta voltou».

Essa última distinção tem consequências operacionais. Imagine que um agente envie POST /releases e perca a conexão depois que o serviço remoto aceita a solicitação. Repetir cegamente pode produzir duas versões. Chamar a primeira tentativa de falha porque o cliente não viu uma resposta está errado. O diário deve mostrar que o executor tentou a chamada, que o transporte falhou depois do início da transmissão e que o estado remoto final continua desconhecido até que outra fonte o confirme.

Um par mínimo de registros pode ter esta aparência:

{"seq":481,"action_id":"01HV...","state":"started","session":"run-72","type":"http.request","target":"deploy.example.internal/releases","request_sha256":"...","authorized":true,"previous_sha256":"..."}
{"seq":482,"action_id":"01HV...","state":"completed","result":"transport_error","sent":true,"response_sha256":null,"previous_sha256":"..."}

Os campos acima ilustram uma estrutura, não um esquema universal. Mantenha o valor da sequência e o resumo sob controle do gravador. O agente pode fornecer um rótulo da tarefa, mas identifique-o como entrada não confiável e limite seu tamanho. Caso contrário, o agente poderá inserir segredos, instruções para revisores ou prosa enganosa em um campo que parece oficial.

Uma falha entre os dois registros deixa uma ação inacabada. Preserve-a. Um registro inacabado é uma evidência que precisa de investigação, não lixo para limpar durante a recuperação. Na reinicialização, o sistema pode marcá-lo como não resolvido se houver uma forma confiável de fazer isso, mas não deve reescrever o histórico para transformá-lo em um sucesso ou falha organizada.

O esquema deve preservar a intenção e o resultado

Um diário que armazena apenas «comando executado» responde a quase nada durante um incidente. Um diário que armazena cada byte de todas as solicitações e respostas cria um depósito de dados sensíveis. O meio-termo útil registra contexto estruturado suficiente para identificar a ação e avaliar a autorização, reduzindo segredos e cargas não controladas.

Registre a identidade do processo chamador em termos que o sistema operacional consiga estabelecer. No macOS, a autoridade de assinatura de código oferece uma âncora de sessão melhor do que um nome de agente autodeclarado. IDs de processos são reutilizados. Um nome de exibição pode mentir. Registre contexto suficiente para que um revisor saiba se um novo processo iniciou a execução e se a aprovação se aplicava a esse processo.

Para uma ação HTTP, preserve o método, a autoridade e o caminho normalizados, a referência da credencial selecionada, os cabeçalhos de solicitação permitidos, o resumo do corpo da solicitação, o resultado da decisão e o status da resposta quando disponível. Para uma ação SSH, preserve a referência do host, a referência da conta remota quando aplicável, o comando ou um resumo do comando conforme a sensibilidade, a referência da identidade selecionada, o resultado da verificação do host, o status de saída e o resumo da saída.

Não armazene credenciais brutas. Não deixe um token bearer aparecer em uma URL, cabeçalho personalizado, argumento de comando ou saída capturada. Redigir depois do armazenamento é mais fraco do que impedir a coleta, pois o segredo já terá entrado em backups, réplicas ou exportações para revisores.

Resumos exigem cuidado. Um resumo prova igualdade apenas em relação ao material que o revisor já possui. Ele não informa a uma pessoa o que aconteceu. Para uma carga de implantação, um resumo armazenado junto com uma revisão do repositório pode funcionar bem. Para um comando destrutivo de banco de dados, uma representação normalizada do comando pode ser necessária, pois a instrução exata é a evidência de que os revisores precisam.

Mantenha um campo separado para a decisão de política ou aprovação que permitiu a ação. Um revisor posterior deve conseguir responder: o executor permitiu isso porque a sessão tinha aprovação, porque o operador aprovou esse uso individual ou porque o cofre estava aberto? Não reduza tudo a um allowed: true vago se o modelo de controle humano depender dessa distinção.

A revisão precisa de acesso separado e verificação independente

Os revisores precisam de mais do que uma tabela pesquisável. Eles precisam estabelecer se a sequência de registros é internamente consistente e se o sistema preservou suas fronteiras. A pessoa que investiga uma execução não deve precisar que o agente primeiro resuma o próprio comportamento.

O encadeamento por hashes oferece uma verificação concreta. Cada registro inclui um resumo do registro armazenado anterior, e o gravador calcula um resumo do registro canônico atual. Um verificador lê a sequência na ordem, recalcula cada resumo e confere se cada referência ao predecessor corresponde. Alterar um destino antigo, remover uma falha constrangedora ou trocar dois registros quebra a cadeia posterior.

A canonicalização é importante. Se um componente aplicar hash ao texto JSON e outro analisar e serializar novamente, espaços ou ordem de campos inofensivos poderão causar uma falha de verificação. Defina a ordem exata dos campos, a codificação de caracteres, o tratamento de valores nulos, a precisão dos horários e o algoritmo de resumo. Depois, versione o formato do registro. Um verificador deve saber se consegue validar determinada versão, em vez de adivinhar.

A verificação deve funcionar longe do processo que criou os registros. Se verificar a integridade exigir o mesmo serviço em execução, um serviço comprometido poderá mentir sobre uma cadeia quebrada. Copie o fluxo de registros criptografado para uma máquina de revisão ou um arquivo protegido e execute o verificador nessa cópia.

O Sallyport projeta seus diários de Sessões e Atividades a partir de um único log de auditoria criptografado e encadeado por hashes, e sp audit verify pode verificar essa cadeia offline sobre o texto cifrado sem uma chave do cofre. Essa separação aponta na direção certa: a verificação das evidências não deve exigir a exposição dos segredos que permitiram a ação.

A verificação de integridade responde a uma pergunta limitada: esses registros formam a sequência esperada pelo verificador? Ela não estabelece que todas as respostas dos servidores eram verdadeiras, que o sistema de destino não tinha outro caminho de acesso ou que um administrador nunca substituiu o diário inteiro por uma cópia válida mais antiga. Mantenha pontos de controle protegidos ou envie raízes assinadas para um sistema de retenção independente se a reversão for relevante no seu ambiente.

Padrões de falha que arruínam o registro silenciosamente

Os projetos mais prejudiciais costumam parecer razoáveis em uma demonstração. Eles falham diante de uma nova tentativa, uma interrupção ou um agente que usa a mesma autoridade de forma inesperada.

A primeira falha é registrar a partir do SDK do agente. Isso é popular porque exige poucas linhas de código e oferece uma visualização de rastros familiar aos desenvolvedores. Não fornece um registro de execução quando o agente obtém credenciais, chama outro programa ou acessa um destino que o SDK não envolve. Trate os rastros do SDK como dados de depuração.

A segunda é usar um único registro de sucesso. Um registro escrito apenas depois de uma resposta limpa apaga a ambiguidade. Operações de rede têm resultados ambíguos, e comandos remotos podem alterar o estado antes de a conexão fechar. Registre início e conclusão separadamente e preserve os inícios inacabados.

A terceira é colocar segredos na carga de auditoria. Às vezes as equipes justificam isso dizendo que os revisores precisam reproduzir tudo. Raramente um revisor precisa de um token bearer para entender uma ação, e segredos copiados transformam o diário em um alvo valioso. Armazene referências de credenciais e resumos de solicitações.

A quarta é dar aos revisores um índice de pesquisa mutável e tratá-lo como fonte da verdade. Índices de pesquisa perdem campos, expiram documentos e permitem correções. Mantenha um fluxo durável de eventos como registro oficial. Crie uma visão de pesquisa a partir dele e permita que o revisor retorne ao registro original quando a visão parecer suspeita.

A quinta é permitir uma saída ampla. Um comando como «executar um shell arbitrário com o ambiente de produção» derrota o cuidado com credenciais e a modelagem de eventos. Às vezes um operador precisa de acesso excepcional. Transforme esse acesso em uma ação aprovada separadamente, com um registro explícito, em vez de escondê-lo na rota normal do agente.

A aprovação humana e a separação de leitura tratam riscos diferentes

A aprovação pode impedir uma ação insegura antes que ela aconteça. A separação de leitura preserva as evidências depois que uma solicitação de ação ocorre. As equipes precisam das duas quando um agente opera com credenciais de grande impacto.

A aprovação de uma sessão é adequada quando uma pessoa confia em um processo específico de agente para executar um trabalho limitado durante certo período. A aprovação por ação é adequada para uma credencial ou operação que merece atenção humana a cada uso. Nenhum tipo de aprovação substitui um registro de execução. Uma sessão aprovada ainda pode fazer uma chamada acidental, e um agente ainda pode descrever incorretamente o que fez.

A tela de aprovação deve identificar o processo chamador de uma forma que uma pessoa consiga avaliar. Um rótulo autodeclarado como «assistente de releases» é fraco. Uma autoridade de assinatura de código estabelecida oferece ao operador um sinal mais firme sobre qual programa solicitou o poder. A decisão de aprovação deve fazer parte do contexto do evento, mas o agente não deve controlar como o sistema descreve essa identidade.

Mantenha a barreira do cofre separada da aprovação. Um cofre bloqueado deve negar ações mesmo que exista uma aprovação anterior da sessão. Isso cria uma parada de emergência simples: bloqueie a autoridade e o executor deixará de usar as credenciais armazenadas. O diário também deve registrar as negativas. Uma sequência de solicitações negadas pode mostrar um agente em loop, sondando o sistema ou continuando depois que um operador revogou o acesso.

Não transforme isso em uma linguagem enorme de regras, a menos que realmente precise de uma. Regras que ninguém consegue inspecionar durante um incidente dão uma falsa sensação de segurança. Um conjunto pequeno de controles claros, uma interface de ações limitada e registros que o agente não consegue moldar muitas vezes são melhores do que uma pilha de exceções condicionais.

Construa a fronteira em torno da ação que pode causar dano

Comece pela ação externa cujo uso indevido exigiria a investigação mais desagradável. Pode ser um comando SSH de produção, uma chamada à API de releases, uma alteração de conta ou uma solicitação paga. Remova a credencial do ambiente do agente, force essa ação pelo executor e teste os caminhos de falha antes de conectar mais ferramentas.

Execute este teste curto no projeto:

1. Solicite uma ação e encerre o processo do agente enquanto a solicitação estiver em andamento. Confirme que o diário mantém um evento de início.
2. Faça o destino remoto retornar um erro e confirme que o registro de conclusão distingue rejeição, falha remota e falha de transporte.
3. Tente a mesma ação com um cabeçalho de credencial ou uma chave privada fornecida pelo chamador. Confirme que o executor rejeita a solicitação.
4. Dê ao agente suas interfaces normais e tente listar, alterar ou excluir registros de auditoria. Confirme que ele não tem como fazer isso.
5. Copie o diário armazenado para outro local e verifique sua cadeia sem depender do status ativo do executor.

Esses testes encontram lacunas que uma demonstração do caminho feliz esconde. Eles também obrigam a responder com precisão a uma pergunta desconfortável: quais ações o agente ainda consegue executar fora do gateway registrado? Se a resposta incluir autoridade de produção, o registro é incompleto por projeto. Diga isso claramente, feche a rota ou reduza as afirmações feitas sobre o registro de auditoria.

Um registro de auditoria útil começa antes de a solicitação sair, termina com o melhor resultado observado e permanece fora do controle do agente. Construa essa fronteira antes que o primeiro incidente peça que você confie na versão dos acontecimentos contada por um agente.