Como funciona a revisão das ações de agentes de IA sem armazenar prompts

Os registros de revisão de agentes autônomos devem explicar uma ação externa sem se tornar uma segunda cópia, mal protegida, de toda a memória de trabalho do agente. Isso significa registrar quem executou o agente, qual autoridade permitiu a execução, qual limite a ação atravessou e o que aconteceu. Não significa preservar para sempre cada prompt, mensagem de ferramenta, bloco de notas e payload de API.

As equipes costumam começar com transcrições de conversas porque são fáceis de capturar e parecem completas. Então chega um incidente, e a transcrição contém dados de clientes, código-fonte, tokens colados, instruções especulativas e páginas de material sem relação com a ação em análise. Enquanto isso, o revisor ainda não consegue responder à pergunta básica: qual executável enviou uma solicitação a qual serviço, sob qual autorização, usando qual escopo de credencial e com qual resultado?

Um registro de revisão deve acompanhar a ação, não a conversa. Essa escolha reduz a exposição e produz evidências que um operador realmente pode usar.

Um registro de ação responde a uma pergunta diferente da transcrição

Um registro de ação responde se um determinado processo atravessou um limite e o que o sistema externo fez em resposta. Uma transcrição responde qual texto passou pelo contexto de um agente. São artefatos diferentes, com necessidades de acesso, períodos de retenção e modos de falha diferentes.

Suponha que um agente leia uma longa discussão de uma tarefa, inspecione um repositório, redija uma nota de versão e chame uma API para criar uma implantação. Uma exportação da conversa pode conter milhares de linhas. O registro de revisão relevante pode ser muito menor:

• Identidade do processo e identificador da sessão.
• Decisão de autorização que cobriu a ação.
• Destino, método, categoria do recurso e referência da credencial.
• Resultado, incluindo o status e um resumo seguro.
• Horários e dados de integridade.

Esse registro permite reconstruir o evento operacional: um processo assinado começou em determinado horário, recebeu aprovação para uma sessão, enviou POST a um host de API e endpoint de implantação identificados, usou a credencial de implantação e recebeu um status de sucesso com um identificador de implantação. Se o evento justificar uma investigação mais profunda, o revisor pode pedir evidências adicionais ao responsável pelo serviço de destino.

A transcrição talvez explique por que o agente achou que deveria fazer a implantação. Raramente ela prova que isso aconteceu. O texto no contexto de um agente pode ser hipotético, desatualizado, inventado pelo modelo ou nunca ter sido executado. A ação externa tem uma trilha de evidências mais restrita e defensável.

Mantenha o material conversacional no ambiente de desenvolvimento apenas quando houver um motivo claro para retê-lo, como uma avaliação de qualidade ou um incidente específico. Não o coloque sorrateiramente em um sistema de auditoria sob o rótulo de responsabilização.

Prompts completos criam um armazenamento de dados que ninguém planejou proteger

Capturar prompts completos transforma um log de ações em um arquivo de conteúdo de alto risco. O risco não é teórico nem se limita a segredos óbvios.

Prompts costumam incluir fragmentos de código-fonte, tickets de clientes, resultados de bancos de dados, URLs internas, decisões de design, histórico do shell e mensagens de erro copiadas. Um modelo pode repetir contexto anterior em um argumento de ferramenta ou em uma explicação de erro. Uma API pode devolver em uma resposta de erro um cabeçalho ou corpo de solicitação enviado. Se o logger tratar todas as strings como diagnósticos inofensivos, mais cedo ou mais tarde ele armazenará informações que a equipe nunca pretendeu coletar.

A defesa comum é: «Vamos remover os segredos». Isso só funciona se o caminho de logging encontrar todos os formatos de segredo antes do armazenamento e entender todos os protocolos. Ele não identificará URLs assinadas de curta duração, cookies de sessão, formatos proprietários de tokens, segredos incorporados em strings JSON nem credenciais que um serviço devolva dentro de um erro. A remoção também não recupera a privacidade depois que um grupo amplo leu o registro original.

A OWASP Logging Cheat Sheet faz uma distinção útil: os logs devem apoiar o monitoramento e a investigação, mas os sistemas não devem registrar tokens de acesso, senhas, strings de conexão, chaves de criptografia ou dados cuja coleta crie uma exposição desnecessária de privacidade. Aplique essa orientação às revisões de agentes com mais disciplina, não menos. O contexto de um agente costuma ser muito amplo, então carrega mais material acidental que um log de solicitações convencional.

Aplique a minimização de dados no momento da captura. Armazene uma impressão digital da solicitação ou metadados aprovados, não o prompt bruto que a gerou. Se uma investigação precisar de contexto depois, recupere-o do sistema de origem, sob os controles adequados a esse sistema. Não transforme um diário de auditoria no lugar mais fácil para navegar por todas as conversas sensíveis.

Há uma exceção restrita: uma equipe pode precisar de uma captura temporária e rigorosamente limitada para diagnosticar uma integração com defeito. Faça disso um modo de diagnóstico explícito, com responsável definido, validade, restrição de acesso e data de exclusão. Se a captura de diagnóstico se tornar permanente porque ninguém a desligou, ela nunca foi realmente uma captura de diagnóstico.

A identidade do processo precisa sobreviver a um nome amigável

O nome de um processo não identifica um agente. agent, node, python e shell dizem muito pouco ao revisor, e um programa malicioso ou descuidado pode escolher qualquer um desses nomes.

Registre dados de identidade suficientes para distinguir o programa que iniciou a sessão:

• Caminho do executável e uma identidade de código estável, como uma autoridade de assinatura quando o sistema operacional fornecer uma.
• ID do processo, ID do processo pai, horário de inicialização e identificador da sessão.
• Conta de usuário e identificador do host local.
• Versão ou identificador de build do cliente do agente, quando fornecido pelo cliente.
• Transporte que alcançou o gateway de ações, como uma conexão MCP local via stdio.

O processo pai importa. Um editor assinado que inicia um agente de programação aprovado conta uma história de revisão diferente da de um processo de shell desconhecido que inicia um binário copiado com o mesmo nome de comando. A identidade do processo pai não prova boas intenções, mas dá aos investigadores um ponto de partida e ajuda a identificar imitações simples.

Não confunda identidade do processo com identidade humana. Um desenvolvedor pode iniciar um agente, mas o registro da ação deve indicar os dois fatos separadamente: qual conta local iniciou o processo e qual executável manteve a sessão. Estações de trabalho compartilhadas, shells remotos, contas de serviço e transferências entre ferramentas tornam essa separação necessária.

A autoridade de assinatura de código merece atenção especial quando disponível, porque o sistema operacional pode verificá-la no momento da inicialização. Ainda assim, ela não é um julgamento moral sobre o editor. Uma autoridade de assinatura confiável pode distribuir uma atualização defeituosa, e uma ferramenta interna sem assinatura pode ser legítima. O registro precisa conter esse fato para que o revisor possa compará-lo com a decisão de autorização e com o caminho de implantação esperado.

A autorização precisa de escopo, horário e aprovador

Uma aprovação sem escopo é uma lembrança vaga, não uma evidência de revisão. O registro precisa dizer o que foi aprovado, quando a aprovação começou e quando deixou de valer.

A autorização de sessão costuma ser o padrão adequado para uma execução de agente orientada por um desenvolvedor. Uma pessoa aprova uma vez um processo de agente conhecido, e o processo pode executar ações até sair. O diário de revisão deve vincular essa decisão à sessão do processo, em vez de fingir que cada chamada posterior recebeu um julgamento humano independente.

Para credenciais de maior risco, registre uma decisão separada por chamada. Esse registro precisa incluir a identidade do aprovador, horário, referência da credencial, categoria da ação, destino e o identificador exato da chamada liberada. Uma observação genérica como «usuário aprovou» deixa espaço demais para discussões depois de uma ação indevida.

Um objeto de autorização funcional pode ter esta forma:

{
  "authorization_id": "auth_7f3c",
  "kind": "session",
  "decision": "approved",
  "approved_at": "2025-03-08T14:22:31Z",
  "approver": "local-account:maya",
  "process_session": "sess_31a9",
  "process_identity": {
    "executable": "/Applications/Agent.app/Contents/agent",
    "signing_authority": "Example Development Team"
  },
  "scope": {
    "credential_refs": ["deploy-production"],
    "expires_when": "process exits"
  }
}

Os nomes e identificadores acima são exemplos, mas a estrutura importa. O aprovador é uma identidade de conta local, não uma afirmação de que uma pessoa identificada acompanhou cada linha da saída. A referência da credencial é um rótulo ou ID interno, nunca a própria credencial. O escopo informa se a decisão cobriu uma sessão ou uma chamada.

Não tente resolver isso com uma linguagem de políticas enorme, a menos que seu ambiente realmente exija uma. As equipes muitas vezes criam regras que ninguém consegue ler durante um incidente e depois tratam a existência dessas regras como um controle. Um pequeno número de escolhas de autorização claras pode ser mais fácil de revisar e mais difícil de configurar incorretamente.

Os metadados da solicitação devem descrever o limite atravessado

Um revisor precisa de metadados suficientes para entender o escopo da operação sem receber uma cópia bruta dela. Para HTTP, capture o host do serviço, a porta quando relevante, o método, o modelo de rota normalizado, a referência da credencial, o tamanho da solicitação, o ID de correlação e um resumo de uma representação canônica segura.

Um modelo de rota normalizado significa registrar /v1/projects/{project_id}/deployments em vez de uma URL literal que contenha um identificador de cliente ou um valor opaco parecido com um segredo. A rota bruta pode permanecer no serviço de destino, que já é responsável por esses dados e possui seus próprios controles de acesso.

Para SSH, o registro equivalente inclui o host de destino, a identidade verificada do host, a conta remota, o comando solicitado ou sua classificação, a referência da credencial e o resultado da execução. Evite registrar uma saída de comando sem restrições. Um comando pode imprimir variáveis de ambiente, conteúdo de repositórios privados ou credenciais de um script mal configurado.

HTTP Semantics, RFC 9110, diferencia semânticas de métodos de solicitação como métodos seguros, idempotentes e não seguros. Use essa distinção como sinal de revisão, não como atalho de autorização. Um GET pode divulgar dados sensíveis. Um PUT pode ser idempotente e ainda substituir uma configuração de produção. Um POST pode criar um efeito externo irreversível. O método ajuda o revisor a raciocinar sobre a ação, mas o destino e a rota determinam o risco real.

Use um esquema de metadados baseado em uma lista permitida. Não comece com o objeto de solicitação inteiro para remover campos depois. O caminho seguro é definir os campos que um registro de ação pode conter e rejeitar ou transformar todo o restante.

{
  "call_id": "call_c24e",
  "session_id": "sess_31a9",
  "channel": "https",
  "destination": "api.example.internal",
  "method": "POST",
  "route_template": "/v1/projects/{project_id}/deployments",
  "credential_ref": "deploy-production",
  "request_bytes": 842,
  "request_digest": "sha256:6d1d...",
  "started_at": "2025-03-08T14:24:09Z"
}

Um resumo criptográfico detecta uma alteração no registro canônico quando o revisor possui a representação original aprovada. Ele não torna o conteúdo original seguro para publicação. Trate com cuidado também os hashes de segredos com baixa entropia, porque um invasor pode adivinhá-los e compará-los. Não faça hash de um token curto e chame isso de anonimização.

Os resultados precisam de evidências operacionais, não de despejos de respostas

Um registro de resultado deve indicar o que o destino informou e se o gateway concluiu a operação solicitada. Ele não deve armazenar por padrão o corpo completo da resposta.

Para uma ação HTTP, registre a conclusão do transporte, o status HTTP, o tamanho da resposta, o ID da solicitação do serviço quando for seguro, o tempo decorrido e um campo de resultado escolhido deliberadamente. Por exemplo, uma API de implantação pode devolver um ID de implantação seguro para retenção, enquanto sua resposta JSON completa contém variáveis de ambiente e uma mensagem de commit de um repositório privado.

Para uma ação SSH, mantenha o código de saída, a duração, o resultado da verificação da identidade do host e um resumo escolhido pelo adaptador do comando. Se um comando precisar comprovar que o trabalho foi concluído, faça com que ele emita um resultado legível por máquina e limitado, como {\"release\":\"r42\",\"status\":\"published\"}. Não aceite uma transcrição de terminal arbitrária como resultado de auditoria.

Essa distinção importa durante as falhas. Imagine que uma chamada de implantação retorne HTTP 403 e inclua um objeto de diagnóstico que repita o cabeçalho de autorização do chamador. O agente vê o erro, tenta novamente duas vezes e cada tentativa produz uma entrada de log diferente. Um sistema de revisão descuidado agora contém três cópias de uma credencial exposta, todas indexadas em um incidente que mais pessoas abrirão.

Construa o caminho de erro antes do caminho de sucesso. O gateway de ações deve classificar o erro, remover campos inseguros e registrar um resumo limitado. Categorias úteis incluem falha de rede, autorização negada, solicitação rejeitada pelo destino, tempo limite do destino e falha de execução local. Combine a categoria com fatos seguros, como código de status ou código de saída, não com um bloco de texto livre vindo de um serviço remoto.

As tentativas de repetição merecem campos próprios. Registre attempt, max_attempts e um vínculo causal com a chamada original. Caso contrário, o revisor verá três solicitações destrutivas e não saberá se o agente as repetiu de propósito ou se uma nova tentativa do transporte produziu duplicatas. Para operações não seguras, uma nova tentativa pode exigir autorização atualizada ou um mecanismo de idempotência no destino. O logging não pode reparar uma ação que o destino aplicou duas vezes.

Um esquema de revisão deve tornar os campos proibidos impossíveis de ignorar

A revisão do esquema identifica erros de logging antes que registros de produção se acumulem. Trate o esquema como um limite de segurança, com campos permitidos explícitos e rejeição explícita de campos livres para prompts e payloads.

O exemplo a seguir reúne identidade, autorização, metadados da ação, resultado e informações de integridade. Ele deliberadamente não possui campos prompt, messages, headers, request_body, response_body ou stderr.

{
  "event_type": "external_action",
  "event_id": "evt_91bd",
  "occurred_at": "2025-03-08T14:24:10Z",
  "actor": {
    "local_account": "maya",
    "process_session": "sess_31a9",
    "pid": 4812,
    "parent_pid": 4601,
    "executable_digest": "sha256:2a84...",
    "signing_authority": "Example Development Team"
  },
  "authorization": {
    "authorization_id": "auth_7f3c",
    "mode": "session",
    "decision": "approved"
  },
  "action": {
    "channel": "https",
    "destination": "api.example.internal",
    "operation": "POST /v1/projects/{project_id}/deployments",
    "credential_ref": "deploy-production",
    "request_digest": "sha256:6d1d..."
  },
  "result": {
    "category": "completed",
    "status_code": 201,
    "destination_request_id": "req_18c7",
    "duration_ms": 614
  },
  "integrity": {
    "previous_event_digest": "sha256:8f50...",
    "event_digest": "sha256:bd7e..."
  }
}

Não coloque comentários como «removido» ao lado de campos que possam ter contido segredos. Omita o campo. Um request_body presente, mas vazio, convida o próximo desenvolvedor a preenchê-lo durante uma depuração. A validação do esquema deve rejeitar campos desconhecidos no nível superior e rejeitar blocos aninhados, exceto quando um adaptador revisado for responsável pelo formato.

Os revisores também precisam de uma visualização legível do evento. Gere essa visualização a partir do registro canônico, em vez de manter uma narrativa manuscrita separada. Uma entrada voltada para pessoas poderia dizer: «A sessão do processo aprovado usou deploy-production para criar uma implantação em api.example.internal. O serviço retornou 201 em 614 ms.» O diário mantém os identificadores necessários para inspecionar o evento sem expor material na visualização padrão.

A integridade prova alterações, não completude

Registros que evidenciam adulteração só ajudam quando a equipe entende seus limites. Uma cadeia de hashes pode revelar que alguém alterou, excluiu ou reordenou um evento depois que ele entrou na cadeia, desde que os revisores mantenham o material necessário para a verificação. Ela não prova que um logger comprometido registrou uma ação desde o início.

A NIST SP 800-92, Guide to Computer Security Log Management, recomenda que as organizações protejam a integridade dos logs, definam quais eventos merecem registro e revisem os logs com uma responsabilidade operacional clara. A parte útil está na combinação. Integridade sem um limite de eventos definido fornece registros confiáveis de uma história incompleta. Uma lista extensa de eventos sem integridade fornece uma história que alguém pode editar silenciosamente.

Use o gateway de ações como ponto de observação, porque ele vê o uso da credencial e a chamada externa. Se um agente puder ignorar esse gateway e fazer chamadas diretas com credenciais copiadas, a trilha de auditoria cobrirá apenas o caminho cooperativo. Corrija o problema de distribuição de credenciais em vez de afirmar que o diário vê tudo.

Mantenha a verificação independente da leitura normal dos logs. Um comando de verificação deve funcionar com registros criptografados armazenados e informar se a cadeia permanece válida. O Sallyport expõe essa verificação por meio de sp audit verify, que verifica seu log de auditoria criptografado e encadeado por hash sem exigir a chave do cofre. Isso importa porque um investigador deve conseguir testar a continuidade dos registros sem obter acesso às credenciais.

Os resultados da verificação precisam de um procedimento operacional. Se uma verificação da cadeia falhar, preserve o armazenamento afetado, pare de tratar o diário como evidência completa, identifique o primeiro ponto de sequência quebrado e compare os registros do lado do destino para o intervalo. Não simplesmente gere uma cadeia limpa e siga em frente. Isso transforma uma falha de integridade detectável em uma lacuna impossível de explicar.

O acesso e a retenção determinam se o diário se tornará outra violação

Um registro mínimo ainda pode causar dano se muitas pessoas puderem pesquisá-lo para sempre. O histórico de autorizações pode revelar a atividade de funcionários. Os nomes dos destinos podem revelar a infraestrutura. Os identificadores de projetos podem expor trabalhos comerciais. Limite o acesso de acordo com a função na investigação, não por curiosidade geral.

Separe as visualizações operacionais das visões forenses. A maioria dos engenheiros precisa de uma lista recente de ações, status, destinos e identidades de sessão para diagnosticar uma execução com falha. Um grupo menor pode precisar de resumos criptográficos de eventos, informações de assinatura, detalhes de aprovação e acesso a registros criptografados brutos durante um incidente. As pessoas que operam um agente não precisam automaticamente de acesso permanente ao histórico de todos os outros desenvolvedores.

Defina a retenção respondendo a duas perguntas: por quanto tempo a equipe consegue investigar de forma realista uma ação contestada e por quanto tempo o destino mantém seu próprio registro oficial? Se o destino mantém o histórico de implantações por pouco tempo, retenha os metadados da ação o suficiente para correlacioná-los. Se uma exigência legal ou contratual alterar esse período, documente a exigência e seu responsável. «Manter tudo» geralmente significa que nenhuma decisão foi tomada.

A exclusão também precisa de evidências. Registre a versão da política de retenção e o fato de que uma exclusão ou agregação programada ocorreu. Não retenha o conteúdo excluído apenas para provar que ele foi excluído. Para análises de tendências de longo prazo, agregue as contagens por categoria de operação e resultado depois que os registros detalhados expirarem.

Construa o registro no gateway e teste os caminhos ruins

A implementação mais segura captura os dados de revisão onde ocorre a ação que usa a credencial. Um agente deve solicitar uma ação por uma interface restrita, o gateway deve autenticar o processo local e aplicar a autorização, e o gateway deve executar a operação HTTP ou SSH. O agente recebe o resultado, enquanto o registro de revisão captura os fatos da ação.

O Sallyport segue esse formato para agentes compatíveis com MCP: o shim local sp mcp encaminha as ações HTTP e SSH pelo aplicativo, cujo cofre criptografado mantém as credenciais de API e SSH fora do contexto do agente. Seu diário de sessões e seu diário de atividades são projeções do mesmo log de auditoria criptografado e somente para gravação, de modo que a autorização da sessão e as chamadas individuais permanecem conectadas sem que o agente precise manter um segredo.

Teste o design com falhas que demonstrações comuns do caminho feliz costumam evitar:

1. Envie uma solicitação que falhe depois que o destino repetir um cabeçalho de autorização falso. Confirme que o registro armazena uma categoria de erro e o status, não o cabeçalho nem o corpo da resposta.
2. Inicie dois processos com o mesmo nome exibido, mas com identidades de executável diferentes. Confirme que a visualização de revisão separa as sessões.
3. Aprove uma sessão, encerre-a e depois inicie um novo processo. Confirme que a aprovação antiga não se aplica à nova execução.
4. Force um tempo limite e tente novamente. Confirme que os registros conectam as tentativas a uma chamada e preservam o fato de que o resultado é incerto.
5. Altere um evento de teste armazenado e execute a verificação de integridade. Confirme que o verificador informa a falha e que a equipe possui um procedimento de resposta documentado.

Faça isso antes de adicionar painéis, resumos ou explicações geradas por modelos. Um feed de atividades bem acabado não compensa um registro de evento que vaza um token ou não consegue distinguir um executável de outro.

Os registros de revisão conquistam confiança quando são restritos o suficiente para serem protegidos, específicos o bastante para permitir uma investigação e ancorados no lugar onde uma ação externa realmente ocorre. Se um registro não consegue dizer quem agiu, qual autoridade o cobriu, qual limite foi atravessado e qual resultado voltou, ele precisa de campos melhores. Se contém a conversa completa, contém informação demais.