Auditar uma operação de IA: autorização, resultado e estado verificado

Um trilho de auditoria útil não responde apenas “o que o modelo disse?”. Ele responde quem solicitou a ação, o que o sistema autorizou, qual ferramenta foi usada, o que aconteceu no sistema de destino e qual estado permaneceu após a operação.

Essa distinção importa. Um prompt completo e a resposta podem ajudar na depuração, mas não substituem um registo operacional. Eles também podem conter dados que nunca deveriam ser copiados para um sistema de registo.

Comece com a pergunta de reconstrução de incidente

Suponha que um agente tenha alterado o orçamento de uma campanha ou a permissão de um utilizador há duas semanas. Hoje alguém pergunta:

• quem iniciou a alteração;
• se o operador estava autorizado a solicitá‑la;
• como a operação foi classificada;
• se era necessária aprovação humana;
• quem aprovou exatamente o quê;
• quais parâmetros relevantes foram passados para a ferramenta;
• o que o fornecedor externo devolveu;
• se o estado resultante foi verificado;
• qual a versão da política de segurança aplicada.

Se responder a essas perguntas exigir combinar manualmente histórico de chat, registos HTTP, base de dados e consola do fornecedor, temos registos. Ainda não temos um bom trilho de auditoria.

Registo mínimo de operação para um agente

Cada sistema será diferente. Para agentes que utilizam ferramentas, um núcleo útil inclui:

Campo	Por que registar
event_id	identificar unicamente o evento
timestamp	ordem e cronologia
operator_id	pessoa ou principal que solicitou a ação
agent_id / agent_version	identificar o agente/modelo envolvido
task_id / correlation_id	ligar múltiplas chamadas num mesmo fluxo de trabalho
tool	ferramenta ou método usado
operation_class	leitura / escrita / operação / destrutiva ou equivalente local
target_resource	conta, inquilino, projeto ou recurso afetado
authorization_decision	permitir / negar mais escopos/política usada
approval_id	evidência de aprovação quando exigida
request_fingerprint	impressão digital dos parâmetros normalizados quando os dados completos são desnecessários
provider_result	resultado controlado sem segredos
resulting_state	estado lido após a alteração, ou referência a evidência
policy_version	conjunto de regras que se aplicou no momento da execução

Nem todo valor precisa ser armazenado como texto no mesmo registo. Alguns podem referir artefactos de evidência separados. O importante é poder reconstruir a cadeia de forma coerente.

Registos de conversa e trilhos de auditoria resolvem problemas diferentes

Um registo de conversa fornece contexto

Ele pode mostrar o que o utilizador pediu, o que o modelo respondeu e que informação estava presente na sessão.

Um trilho de auditoria fornece evidência de execução

Deve mostrar:

operador
→ decisão de autorização
→ ferramenta
→ parâmetros materiais à ação
→ aprovação, se exigida
→ resultado do fornecedor
→ estado resultante

Se um modelo escreve “a campanha foi pausada” mas não há evento de ferramenta nem leitura de estado do sistema de destino, temos apenas uma alegação. Não temos evidência de execução.

O que normalmente pertence à lista de redação ou exclusão

Mais registo não significa automaticamente melhor auditabilidade. Pode significar uma superfície de fuga de dados maior.

No nosso Brillnet Ads MCP interno, credenciais, cabeçalhos de autorização e identificadores pessoais brutos são excluídos dos registos de auditoria. A mesma orientação é útil noutros contextos.

Não registe segredos

• chaves de API;
• tokens de acesso ou refresh;
• chaves privadas;
• palavras‑passe;
• cookies de sessão;
• cabeçalhos Authorization completos.

Se um registo de auditoria precisar mostrar que identidade ou conjunto de credenciais foi usado, guarde um identificador de referência seguro em vez do segredo propriamente dito.

Não copie automaticamente cada pedido e resposta

Uma resposta API bruta pode conter dados pessoais, campos confidenciais ou informação irrelevante para o propósito da auditoria. Selecione apenas os metadados necessários para a decisão e para o estado resultante.

Não torne os prompts completos parte obrigatória do registo de auditoria

Prompts podem ser úteis para diagnóstico. Também podem conter documentos de cliente, dados pessoais ou um segredo colado por engano. A retenção de prompts deve seguir uma política separada de retenção e acesso a dados, não a suposição de que “IA significa registar tudo”.

Redija antes de persistir

Se persistirmos primeiro uma carga completa e só depois aplicarmos mascaramento, o segredo já entrou no sistema de registo.

Um fluxo mais seguro é:

ferramenta devolve resultado
↓
normalização
↓
classificação de campos
↓
redação / pseudonimização
↓
persistência do registo de auditoria

Dados sensíveis podem permanecer no sistema de origem, que já possui os seus próprios controlos de acesso e retenção. O sistema de auditoria deve reter o mínimo necessário para reconstruir a decisão e o efeito.

Leitura‑após‑escrita fecha a lacuna entre “chamado” e “alterado”

Para operações de escrita, registamos não só o resultado da chamada mas — quando o fornecedor o permite — o estado do recurso lido após a alteração.

Exemplo:

14:02:11 pedido de escrita: status da campanha → PAUSED
14:02:12 fornecedor: sucesso
14:02:13 leitura‑após‑escrita: campaign.status = PAUSED

Isso permite distinguir:

• o agente solicitou a alteração;
• o fornecedor aceitou o pedido;
• o recurso apresentava o estado esperado quando foi verificado.

Não prova que o estado nunca mudou segundos depois. Ainda assim, é uma evidência muito mais forte do que uma mensagem do modelo a dizer “concluído”.

Aprovação deve ser um evento de auditoria independente

A aprovação humana deve ter o seu próprio identificador e estar vinculada a uma operação específica.

Um registo conceitual pode incluir:

approval_id: apr_...
approved_by: operator_...
approved_at: 2026-09-12T14:01:44+02:00
action_hash: sha256(...)
operation: ENABLE_CAMPAIGN
target: campaign_...
expires_at: ...

O executor pode então verificar que a aprovação existe para esta versão exata da operação, em vez de confiar numa mensagem de chat a dizer “o utilizador concordou”.

Leia: Quando um agente de IA deve exigir aprovação humana?

Integridade: registos apenas de acréscimo e encadeamento de hashes

Na nossa ferramenta interna Ads MCP, os registos de auditoria são apenas de acréscimo e encadeados por hash. O objetivo é tornar mais fácil a deteção de alterações silenciosas no histórico.

Conceitualmente:

record_1 + hash(record_1)
↓
record_2 contém hash(record_1)
↓
record_3 contém hash(record_2)

Se um registo antigo mudar, as ligações subsequentes deixam de corresponder.

Isto não confere imutabilidade mágica. Um administrador com acesso suficientemente amplo ainda pode destruir o sistema de registo ou todo o armazenamento. A integridade dos registos deve, portanto, ser combinada com:

• acesso restrito ao registo;
• definição de retenção;
• cópias de segurança/exportação quando justificadas;
• monitorização de lacunas ou falhas de cadeia;
• controle de tempo e identificadores.

Telemetria útil para ferramentas MCP

Para tools/call ou operação local equivalente, campos úteis costumam incluir:

• nome da ferramenta;
• categoria de risco;
• identificadores de recurso normalizados;
• escopos avaliados;
• resultado da autorização;
• se foi apresentado um pré‑visualização da ação;
• identificador de aprovação;
• hora de início e fim;
• estado do fornecedor;
• código de erro controlado;
• se ocorreu uma nova tentativa;
• chave de idempotência ou impressão digital segura dela;
• estado resultante após escrita;
• identificador do modelo/agente na medida necessária para diagnóstico.

Não é necessário armazenar todos os argumentos brutos da ferramenta.

E quanto ao “chain‑of‑thought”?

Não precisamos da cadeia de pensamento privada do modelo para criar um trilho de auditoria operacional útil. Precisamos de factos observáveis:

• entrada relevante para a decisão;
• operação selecionada;
• política aplicada;
• aprovação;
• resultado;
• estado resultante.

Quando a justificação for útil, o agente pode escrever um curto decision_reason explícito, concebido para revisão. Isso difere de tentar preservar o processo de raciocínio oculto do modelo.

Retenção: “para sempre” costuma ser um mau padrão

Para cada classe de evento, defina:

• finalidade de tratamento;
• período de retenção;
• quem pode aceder;
• se os dados podem ser agregados ou pseudonimizados;
• quando um registo é evidência de negócio versus telemetria de engenharia;
• como funciona a eliminação legal/operacional quando exigida.

Não mantenha telemetria de depuração e registos formais de decisão juntos indefinidamente sem uma razão.

Exemplo de reconstrução de incidente

Situação: uma campanha começou a gerar gastos embora se esperasse que permanecesse pausada.

Um trilho de auditoria útil deve permitir seguir:

1. task_id — de onde veio o pedido;
2. operator_id — quem o iniciou;
3. tool — qual ferramenta foi selecionada;
4. operation_class=operate — por que controlo adicional foi aplicado;
5. approval_id — se alguém realmente aprovou a ativação;
6. parâmetros — que status e orçamento foram cobertos pela aprovação;
7. provider_result — o que o Google Ads aceitou;
8. leitura‑após‑escrita — que estado foi observado após a execução;
9. eventos posteriores — se outro ator mudou o status novamente.

Sem essa cadeia, ficamos a ler o histórico de chat e a adivinhar.

Lista de verificação de trilho de auditoria de agente de IA

• Cada evento material tem um ID único e timestamp.
• Identidade do operador e do agente são distintas.
• Múltiplas chamadas podem ser unidas por um único ID de tarefa/correlação.
• Decisões de autorização são registadas, não apenas chamadas bem‑sucedidas.
• Aprovação é um evento verificável separado.
• Parâmetros materiais à consequência são armazenados ou têm impressão digital.
• Segredos e cabeçalhos de autorização são excluídos antes da persistência.
• Dados pessoais são minimizados/redigidos.
• Retries e idempotência são observáveis.
• Escritas têm resultado do fornecedor e, quando prático, evidência de leitura‑após‑escrita.
• Versão da política pode ser reconstruída.
• Acesso ao auditório é mais restrito que o acesso normal à aplicação.
• Retenção está definida, não é acidental.
• Integridade do trilho é monitorada.

Para quem é este guia

Responsáveis de processo e desenvolvedores precisam de evidência de execução. Ações de exemplo incluem mudar tickets de qualidade de produção, enviar avisos a proprietários de imóveis e gerir acessos de TI. Estes são cenários de design, não alegações de implementações existentes; o processo determina a evidência necessária.

Ads MCP é um exemplo de design interno para contas de propriedade Brillnet, e não um serviço ao cliente ou avaliação de produção independente.

Um resultado desconhecido deve permanecer visivelmente desconhecido

Um timeout não prova falha: o servidor pode ter concluído a escrita antes de perder a resposta. Distinga requested, accepted, verified e unknown. Não reporte incerteza como sucesso.

O proprietário da integração define a reconciliação usando o identificador de trabalho do fornecedor ou referência ao recurso. Envolva o operador antes de repetir ações de alto impacto não resolvidas. Adicione um evento de reconciliação ligado, em vez de reescrever a história.

Visibilidade tardia de escrita requer o mesmo cuidado. Um estado antigo pode refletir o modelo de consistência do fornecedor. Registe a hora da observação e a limitação. Retries precisam de um limite finito e de um estado final compreensível.

Decida o que acontece quando a entrega de auditoria falha

O registo pode perder conectividade, esgotar espaço em disco ou rejeitar registos. O OWASP recomenda testar falhas. Decida separadamente quais ações consequenciais podem continuar durante entrega atrasada e quais exigem evidência de decisão durável primeiro.

Isso não requer parar toda a empresa por uma mensagem diagnóstica em falta. Separe a telemetria rotineira da evidência de uma operação aprovada. Uma mudança de permissão pode exigir evidência de autorização durável antes da execução; ler um manual público pode permitir armazenamento temporário de metadados. Estes são exemplos de decisões de design, não requisitos universais do OWASP.

Um buffer precisa de limites de capacidade, controlos de acesso e monitorização de atrasos. Preserve os identificadores originais e os tempos de evento durante a recuperação. Registe eventos ausentes para distinguir inatividade de perda de visibilidade. Direcione um alerta a alguém que possa restaurar o registo ou suspender a classe de operações afetada.

Uma impressão digital não elimina automaticamente o risco de privacidade

Hash de um endereço de email ainda pode identificar uma pessoa ao comparar com uma lista curta de endereços conhecidos. Quando a identificação do operador importa, considere um identificador interno aleatório e um mapeamento protegido separadamente. Os leitores do auditório não precisam automaticamente desse mapeamento.

Um request_fingerprint também precisa de um método de normalização definido e de versão de esquema. Um hash é insuficiente se ninguém puder estabelecer o que foi coberto. Defina um local de evidência seguro, mas evite reter um documento inteiro apenas para recomputar o seu hash. O proprietário do processo especifica as necessidades de evidência; o responsável pela proteção de dados revê os dados retidos.

Reconstrua um evento sem o agente

Use um ticket de serviço fictício. Um operador aprova o envio de um aviso a um fornecedor especificado. O agente escolhe a ferramenta, o gateway verifica o escopo e o servidor regista o resultado e o identificador da mensagem. Numa segunda execução, altera‑se o destinatário após a aprovação. A execução deve ser rejeitada com um motivo registado. Use dados de teste em vez de documentos reais de clientes.

Forneça a um revisor não envolvido o pacote de evidência. Ele deve estabelecer o operador, o conteúdo aprovado, o destinatário, a política aplicada e o efeito real. Se precisar perguntar ao agente o que ele pretendia, o pacote está incompleto. Corrija a relação ausente em vez de registar automaticamente toda a conversa.

O proprietário do processo detém a aceitação. O desenvolvedor fornece exportações e erros controlados. O administrador de registo verifica acesso e integridade do pacote. Uma pequena empresa pode atribuir várias responsabilidades a uma única pessoa, mas as responsabilidades ainda precisam de proprietários explícitos.

O que fazer amanhã

Escolha uma ação com consequência e identifique cada sistema que a regista. Adicione um identificador de correlação comum. Liste os campos retidos e os excluídos. Execute uma tentativa permitida e uma rejeitada usando dados de teste, depois reconstrua ambas a partir de uma exportação.

Meça ações com trilhos completos, resultados não resolvidos e o atraso entre a ação e a evidência disponível. Defina limiares de processo. Volume de registo não prova utilidade: um passo em falta ainda requer investigação.

Recomendações técnicas não determinam retenção legal

O NIST SP 800‑92 trata da gestão de registos. A família de controlos AU no NIST SP 800‑53 ajuda a organizar requisitos de auditoria; nenhum dos documentos confere certificação nem define um período de retenção único para todas as empresas. O OWASP não é legislação. Identifique obrigações legais e contratuais separadamente, com o seu âmbito e base aplicáveis. Este guia não prescreve um período de retenção de dados estatutário.

Limite

Um trilho de auditoria não prova automaticamente que uma decisão foi correta. Ele prova o que o sistema registou sobre como a ação foi autorizada e executada. Processos regulados podem precisar de requisitos adicionais de integridade, retenção, privacidade e qualidade probatória.

Veja também Least privilege for AI agents e Brillnet Security.

Um ensaio sintético de operação financeira

Use um ambiente de demonstração dedicado com uma fatura fictícia. A operação de agente proposta altera o status de revisão interna da fatura; não movimenta dinheiro. Dê ao operador e ao agente identidades distintas, restrinja o escopo do registo e exija que a pessoa apropriada autorize a operação. Registre a versão e a decisão da política, sem armazenar credenciais ou uma transcrição confidencial completa.

Após a operação permitida, leia o status da fatura e o histórico de alterações relevantes. Compare-os com o resultado solicitado. Uma resposta técnica que diga aceita não é prova de que a mudança pretendida ocorreu. Retenha o identificador da solicitação, o resultado e a referência ao estado verificado para que outra pessoa possa reconstruir a sequência.

Então tente uma operação excluída pela política de manifestação. Inspecione a recusa e confirme se o estado relevante não mudou. Isso demonstra um limite específico na configuração ficcional. Não é prova de que todas as ferramentas de agente, sistema financeiro ou ambiente de cliente tenham o mesmo controle.

Use o Pulsar para registrar o requisito de controle, o proprietário, a ação do exercício e as evidências. O teste de 14 dias testa esse fluxo de trabalho de conformidade. Não inclui uma plataforma completa de auditoria de operação de agente, conexão bancária ou serviço de autorização de pagamento. Uma verdadeira integração ou piloto precisa de um escopo acordado separadamente. Revise a forma de pagamento exigida para o teste, o plano selecionado e os termos de cancelamento antes de começar.

Fontes

As fontes técnicas suportam os princípios declarados. Os cenários de implementação e o plano de ação são recomendações de design do autor.

• OWASP AI Agent Security Cheat Sheet — acedido: 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — acedido: 2026-10-02.
  Fontes verificadas: 2026-10-10.
• OWASP — Logging Cheat Sheet — Registros de eventos úteis e informações confidenciais excluídas.
• NIST SP 800-92 — Log Management — Gerenciamento de registros.
• NIST SP 800-53 Rev. 5 — Princípios de controle de acesso e controle de auditoria.
• MCP — security best practices — Segurança de integração e limites de autorização.
• Pulsar GRC — actual scope — Requisitos, controles, evidências e julgamento.
• Escopo do produto e termos de avaliação publicados — Escopo do produto e termos de avaliação publicados.

Revise os termos e inicie o teste de 14 dias

Privilégio mínimo para agentes de IA em um SaaS multilocatário

CAPA de produção de alimentos: da descoberta à avaliação da eficácia

Um POP farmacêutico alterado: verifique o formação e a versão fonte