Agente de IA com identidade própria: o log precisa provar quem autorizou

Para monitorar um agente de IA com segurança, não basta registrar uma chamada de API. Cada ação precisa formar uma cadeia verificável entre a pessoa que delegou ou aprovou a tarefa, a identidade técnica do agente, a autoridade concedida, a decisão de política e o efeito produzido.

A arquitetura mínima combina identidade própria para o agente, autorização delegada e limitada, privilégios por ferramenta e recurso, sessões isoladas, memória controlada e eventos correlacionados. Se o histórico não responde quem autorizou, o que foi solicitado, qual regra liberou a operação e o que mudou, ele ajuda na depuração, mas não prova responsabilidade.

Separe quem delega, quem executa e cada execução

O agente não deve agir com a credencial permanente do usuário nem com uma conta genérica compartilhada. Ele precisa de uma identidade de carga de trabalho autenticável; o log, por sua vez, deve registrar separadamente a versão implantada, o ambiente e o responsável operacional.

A delegação preserva duas identidades: quem concedeu a autoridade e quem executou a ação. O rascunho conceitual do NIST e do NCCoE inclui entre suas áreas de interesse a distinção entre identidades humanas e não humanas, a vinculação da delegação ao usuário e o registro das ações e resultados do agente; o documento também pergunta como tornar intenção e logs verificáveis e vinculá-los à autorização humana. É uma proposta de escopo para um possível projeto, não uma norma ou arquitetura pronta.

No esquema operacional, mantenha campos distintos para human_subject_id, agent_id e execution_id. O primeiro aponta quem delegou; o segundo identifica o software que recebeu autoridade; o terceiro delimita a tarefa concreta. Acrescente delegation_id para localizar a concessão que sustentou a operação.

Conceda autoridade para a tarefa, não acesso irrestrito

A permissão efetiva deve ser a interseção entre o que o usuário pode fazer, o que aquele agente pode executar e o que a política permite naquele contexto. Ter um usuário poderoso na origem não deve transformar o agente em administrador.

Uma matriz inicial de privilégios pode separar:

• Leitura: apenas fontes necessárias, filtradas por locatário, projeto, classificação e finalidade.
• Criação: tipos de objeto, destinos e limites definidos; criar um rascunho pode ser permitido enquanto publicar exige aprovação.
• Alteração: somente campos autorizados, com controle de concorrência para não sobrescrever mudanças recentes.
• Exclusão e operações irreversíveis: negação por padrão ou aprovação humana vinculada à operação exata.
• Memória: permissões distintas para leitura e escrita, com poucos escritores no espaço compartilhado.
• Administração: fora do conjunto normal de ferramentas e disponível apenas em fluxos excepcionais.

A credencial da execução deve ter validade curta, audiência definida e escopos compatíveis com a tarefa. A decisão final pertence ao gateway da ferramenta ou do recurso: uma instrução em linguagem natural não substitui controle de acesso determinístico. A mesma lógica orienta os controles antes da produção, que reduzem o alcance de credenciais e ferramentas.

Registre intenção, política e efeito no mesmo fluxo

O evento de auditoria deve nascer antes da chamada à ferramenta e ser completado com a decisão e o resultado. Campos estruturados permitem reconstruir a operação sem depender de um texto livre ambíguo.

Um modelo mínimo contém:

• event_id, timestamp e trace_id: identificam o evento, sua ordem e a cadeia da solicitação.
• human_subject_id e delegation_id: indicam quem delegou e qual concessão autorizava a tarefa.
• agent_id, agent_version e execution_id: identificam o executor, a versão e a execução.
• session_id e tenant_id: delimitam o contexto e o domínio dos dados.
• intent: resume a finalidade declarada, como “criar rascunho de pedido”, sem copiar o raciocínio interno do modelo.
• tool, operation e resource: registram a ferramenta, o verbo solicitado e o alvo normalizado.
• requested_scopes e effective_scopes: mostram o que foi pedido e o subconjunto concedido.
• policy_id, policy_version e decision: identificam a regra e o resultado — permitir, negar ou exigir aprovação.
• approval_id: referencia a aprovação humana, sua validade e a operação coberta.
• result_status e effect: registram sucesso, falha ou bloqueio e a alteração observável.

Tokens, segredos e o conteúdo integral dos prompts não devem entrar automaticamente nesse evento. Quando o conteúdo for indispensável à investigação, guarde-o em repositório protegido e registre apenas referência, classificação, hash e regra de retenção. Enviar os eventos para um destino separado do runtime, com administração restrita e controles de integridade proporcionais ao risco, reduz a possibilidade de alteração silenciosa.

Trate memória e sessão como fronteiras de segurança

A orientação de arquitetura da AWS recomenda considerar a memória compartilhada parcialmente confiável, limitar escritores com privilégio mínimo ou acesso somente de leitura e intermediar as operações por uma ferramenta determinística que valide conteúdo e aplique políticas. A mesma página orienta separar contexto e estado por sessão para evitar interferência e vazamento entre usuários.

Implemente o gateway de memória com operações explícitas: leitura, proposta de escrita, validação, aprovação quando necessária e confirmação. Para cada alteração, registre o agente escritor, a sessão, a origem do dado, as versões anterior e posterior e a decisão do filtro. Na leitura, devolva somente registros permitidos para o locatário e a finalidade daquela execução.

Memória temporária da sessão, histórico privado do usuário e conhecimento compartilhado são domínios diferentes. O encerramento ou a expiração da sessão deve invalidar seus identificadores e liberar recursos temporários; uma sessão nova não deve herdar contexto apenas porque utiliza o mesmo agente.

Teste se a trilha reconstrói a autorização

Antes da produção, escolha operações representativas e tente reconstruí-las apenas com os registros. A equipe deve localizar a solicitação, a delegação, a versão do agente, a ferramenta, o recurso, a política, a eventual aprovação e o efeito final.

1. Execute uma operação permitida e confirme a correlação de ponta a ponta.
2. Tente acessar outro locatário ou finalidade e verifique se a negativa identifica a política aplicada.
3. Solicite uma operação irreversível sem aprovação e confirme que ela não chega ao recurso.
4. Revogue a delegação durante a execução e confira se as chamadas seguintes são rejeitadas.
5. Proponha uma escrita inválida na memória e confirme o bloqueio antes da propagação.
6. Abra sessões simultâneas de usuários diferentes e verifique se contexto, estado e resultados continuam separados.

Os mesmos campos sustentam alertas sobre aumento inesperado de escopos efetivos, negativas repetidas, ferramenta incompatível com a intenção, reutilização de aprovação, escrita incomum na memória ou acesso entre locatários. O objetivo não é guardar tudo: é conservar evidência suficiente para demonstrar a autorização, explicar o efeito e interromper novas ações quando a cadeia de confiança se rompe.

Leia também:

• Agente de IA com acesso demais: quatro controles antes da produção
• Claude mantém logs de segurança na nuvem do cliente com o EFS
• QueryStory sai do sigilo com IA que mostra como chegou à resposta