Quem autorizou a IA? Identidade, permissões e responsabilidade em Agentes IA

Durante muito tempo, sistemas automatizados executaram tarefas relativamente previsíveis. Uma integração recebia uma informação, aplicava uma regra definida pelo desenvolvedor e enviava o resultado para outro sistema. Mesmo quando o fluxo era complexo, suas ações continuavam delimitadas pelo código.

Os Agentes IA mudam essa dinâmica. Eles interpretam solicitações, consultam dados, selecionam ferramentas e decidem qual ação solicitar. Um Agente conectado ao CRM pode atualizar oportunidades e criar tarefas. Outro, integrado ao financeiro, pode consultar pagamentos, emitir cobranças ou preparar um reembolso.

Essa capacidade de usar ferramentas para executar tarefas é o que torna um Agente útil. Também é o que transforma identidade e controle de acesso em questões centrais.

Quando um Agente modifica informações dentro da empresa, não basta saber qual funcionário iniciou a conversa. A organização precisa descobrir qual Agente executou a ação, com quais permissões, em nome de quem, por qual motivo e com qual resultado.

Por que a identidade dos Agentes virou um problema empresarial

Em fevereiro de 2026, o National Institute of Standards and Technology, o NIST, publicou um documento conceitual sobre identidade e autorização de Agentes de software e IA. O texto reúne questões sobre identificação, autenticação, autorização, delegação, auditoria, não repúdio e mitigação de prompt injection.

O documento ainda não é uma norma final. A página do projeto informa que o NCCoE está revisando os comentários recebidos. O valor da iniciativa está em mostrar que a identidade de Agentes deixou de ser apenas uma decisão interna de arquitetura.

No mesmo período, o NIST lançou a AI Agent Standards Initiative, com segurança, identidade e interoperabilidade entre seus pilares. A discussão aparece agora porque Agentes estão saindo da camada de resposta e entrando na camada de ação.

O problema de deixar o Agente usar a conta de um funcionário

Imagine que uma empresa conecte seu Agente comercial ao CRM usando o login de um gerente.

Ao longo do dia, essa conta altera estágios de oportunidades, registra descontos, atualiza dados de clientes e marca vendas como aprovadas. Parte das ações foi realizada pelo gerente. Outra parte foi executada pelo Agente.

Quando surge uma alteração incorreta, o histórico mostra apenas o nome do funcionário.

A empresa não consegue responder com segurança:

* A ação foi humana ou automatizada?

* Qual versão do Agente estava em operação?

* Qual conversa originou a alteração?

* O Agente tinha permissão para executar aquela ação?

* Houve aprovação humana?

* A credencial foi usada por outro sistema?

* A ação surgiu de uma solicitação legítima ou de uma instrução maliciosa?

O compartilhamento de identidade elimina uma informação básica para qualquer investigação: quem realmente agiu.

O mesmo problema ocorre quando vários Agentes usam uma única chave de API. Uma automação de suporte, um Agente comercial e um processo financeiro aparecem nos registros como o mesmo ator. A empresa sabe que uma credencial foi usada, mas não consegue atribuir a ação ao sistema correto.

O projeto do NIST explora justamente a separação entre identidades humanas e não humanas, além da associação entre ações, dados acessados e resultados produzidos por cada Agente.

Identificação, autenticação e autorização são controles diferentes

Os três conceitos aparecem juntos, mas respondem a perguntas distintas.

Identificação responde: quem ou o que está tentando agir?

Autenticação responde: como o sistema comprova que aquele ator é realmente quem afirma ser?

Autorização responde: o que esse ator pode fazer depois de autenticado?

Um Agente pode ser identificado e autenticado corretamente, mas ainda possuir permissões inadequadas. O sistema reconhece o Agente comercial, valida sua credencial e, mesmo assim, permite que ele exclua clientes, altere contratos ou aprove pagamentos.

Autenticar não significa liberar acesso irrestrito. A identidade é o ponto de partida para aplicar uma política de acesso.

Cada Agente precisa de uma identidade operacional própria

Uma identidade de Agente deve representar uma entidade não humana específica dentro da organização. Ela não pode existir apenas como um nome colocado no prompt, como “assistente comercial” ou “Agente financeiro”. Precisa existir também na infraestrutura que controla acesso aos sistemas.

Essa identidade pode reunir:

* Um identificador único;

* A empresa, unidade ou cliente ao qual o Agente pertence;

* Sua finalidade operacional;

* O ambiente em que está sendo executado;

* A versão da aplicação ou configuração;

* O responsável interno;

* Os sistemas e ferramentas autorizados;

* O nível de autonomia;

* A política de aprovação humana;

* O status da identidade, como ativa, suspensa ou revogada.

Esses dados impedem que a organização trate todos os processos automatizados como uma categoria genérica chamada “IA”.

Um Agente que consulta pedidos tem uma função diferente de outro que cancela compras. Um Agente que prepara propostas não precisa ter autoridade para aprová-las. A identidade deve refletir essa separação.

Como o Agente comprova sua identidade

Depois de criar a identidade, a empresa precisa definir como o Agente será autenticado.

Em uma implementação adequada, ele usa uma credencial própria, protegida e administrada de acordo com seu ciclo de vida. Isso pode envolver tokens de acesso, certificados, chaves criptográficas ou identidades de workload fornecidas pela infraestrutura.

Uma identidade de workload é uma forma de reconhecer a aplicação que está sendo executada, sem fingir que ela é uma pessoa. O sistema autentica aquele serviço, container, função ou processo e vincula a credencial à sua execução.

O material publicado pelo CSRC considera tecnologias e padrões já usados em identidade digital. Entre eles estão OAuth, OpenID Connect, SPIFFE e SPIRE. O documento também cita o SCIM como uma possibilidade para criar, atualizar e revogar identidades em diferentes sistemas.

A escolha depende da arquitetura. O princípio é mais simples: a credencial deve estar vinculada ao Agente e ser administrada separadamente das contas humanas.

Na prática, isso exige evitar senhas compartilhadas e credenciais permanentes incorporadas diretamente ao código. Também exige mecanismos para emissão, rotação e revogação.

Quando um Agente é desativado, sua identidade deve ser desativada. Quando deixa de precisar de um sistema, a permissão deve ser removida. Se uma credencial for comprometida, a empresa precisa revogá-la sem interromper todos os outros Agentes.

O Agente não precisa de acesso a tudo

Uma falha comum na implantação é conceder acesso amplo para facilitar o desenvolvimento.

O Agente precisa consultar uma informação e recebe acesso a todo o banco de dados. Precisa atualizar uma oportunidade e recebe uma conta administrativa no CRM. Precisa enviar um documento e recebe acesso completo ao armazenamento da empresa.

Isso reduz o trabalho inicial da equipe, mas aumenta o impacto de qualquer erro posterior.

O princípio do menor privilégio determina que cada identidade receba apenas os acessos necessários para cumprir sua função. No documento conceitual, o NIST trata essa questão como um desafio específico: como limitar um Agente quando todas as ações necessárias talvez não sejam previsíveis antes da implantação?

Para um Agente comercial, as permissões podem ser separadas entre:

* Consultar contatos;

* Criar oportunidades;

* Atualizar o estágio de uma oportunidade;

* Gerar propostas;

* Aplicar descontos;

* Aprovar condições comerciais;

* Excluir registros;

* Exportar a base de clientes.

O fato de o Agente precisar das três primeiras permissões não significa que precise das demais.

Também podem existir limites adicionais. O Agente pode alterar apenas oportunidades de determinada operação, aplicar descontos até um percentual definido ou iniciar transações somente abaixo de certo valor.

Quanto maior o impacto da ação, menor deve ser a autonomia concedida.

A autorização deve considerar o contexto da ação

Políticas simples avaliam apenas o papel do ator. Se ele pertence ao grupo “comercial”, recebe todas as permissões daquele grupo.

Para Agentes, isso costuma ser insuficiente.

A autorização pode considerar:

* Qual Agente está solicitando a ação;

* Em nome de qual usuário ou cliente está atuando;

* Qual recurso será acessado;

* A sensibilidade do dado;

* A ferramenta usada;

* O ambiente de execução;

* A finalidade declarada;

* O valor ou impacto da transação;

* A existência de uma aprovação humana válida;

* O padrão recente de comportamento.

Com esse controle, o mesmo Agente pode consultar o status de um pagamento, mas não alterar seus dados. Pode preparar um reembolso, mas depender de aprovação para executá-lo. Pode agendar uma reunião, mas não cancelar compromissos classificados como críticos.

A permissão deixa de ser ampla e passa a ser uma decisão específica para cada ação.

Agir em nome de alguém não significa assumir sua identidade

Alguns Agentes precisam atuar em nome de um usuário. Um assistente de agenda acessa o calendário da pessoa que solicitou a tarefa. Um Agente comercial registra uma atividade para um vendedor. Um Agente de atendimento consulta um pedido pertencente a um cliente.

Isso é delegação de autoridade.

A delegação não deve apagar a identidade do Agente. O registro precisa preservar pelo menos dois atores:

1. O Agente que executou a ação;

2. A pessoa ou organização em nome de quem ele estava agindo.

Considere um Agente que aplicou um desconto depois da aprovação de um gerente. Um registro adequado não mostra somente “desconto aprovado pelo gerente” nem apenas “desconto aplicado pelo Agente”.

Ele mostra que o Agente executou a alteração, em nome de determinada operação, após uma autorização específica concedida por uma pessoa identificada.

Essa separação permite reconstruir a cadeia de responsabilidade.

Algumas ações ainda precisam de aprovação humana

Identidade e autenticação não eliminam a necessidade de supervisão. Elas tornam a supervisão verificável.

Um Agente pode executar tarefas frequentes, reversíveis e de baixo impacto. Ações críticas devem seguir outra política. Entre elas podem estar exclusão de informações, alteração de dados financeiros, descontos elevados, cancelamento de contratos, liberação de pagamentos, exportação de bases e mudanças em produção.

Nesses casos, o sistema pode dividir a ação em duas etapas. O Agente prepara a operação e uma pessoa autorizada confirma.

A aprovação precisa estar vinculada à ação concreta. “Resolva o problema do cliente” é uma autorização ampla demais. “Aprove o reembolso de R$ 280 para o pedido 1234” estabelece um limite verificável.

Depois da confirmação, o Agente recebe autoridade para executar aquela operação nas condições aprovadas. Ele não recebe acesso irrestrito ao sistema.

Esse desenho complementa uma política de supervisão humana em Agentes IA. O objetivo não é colocar uma pessoa para revisar tudo, mas concentrar a aprovação nas decisões em que um erro teria maior impacto.

Logs precisam mostrar mais do que uma chamada de API

Muitas aplicações registram que uma requisição aconteceu. Para investigar um Agente, isso pode não ser suficiente.

Um registro útil deveria permitir descobrir:

* Qual Agente realizou a ação;

* Qual usuário ou processo iniciou a solicitação;

* Em nome de quem o Agente estava atuando;

* Qual ferramenta foi utilizada;

* Qual recurso foi consultado ou alterado;

* Qual ação foi solicitada;

* Qual política de autorização foi aplicada;

* Qual foi a decisão do sistema;

* Se houve aprovação humana;

* Qual foi o resultado;

* Quando a ação aconteceu;

* Qual versão do Agente estava em execução.

Dependendo do risco, também pode ser necessário preservar a origem dos dados e o contexto operacional que levou à decisão. O documento do NCCoE inclui rastreamento de procedência de prompts e fontes de dados, além da vinculação entre ações e a identidade da entidade não humana.

Isso não exige armazenar indiscriminadamente todo o raciocínio interno do modelo. O objetivo é manter informações suficientes para reconstruir a operação sem criar um novo problema de privacidade.

A mesma preocupação aparece quando se discute Agente IA e CRM. Registrar apenas o resultado final empobrece a investigação. A empresa precisa preservar a relação entre solicitação, autorização, execução e resultado.

Auditoria e não repúdio

Auditoria é a capacidade de revisar o que aconteceu. Não repúdio é a capacidade de demonstrar que determinada entidade realizou ou autorizou uma ação, reduzindo a possibilidade de negar posteriormente sua participação.

Em um sistema de Agentes, isso exige mais do que logs soltos em aplicações diferentes. Os registros precisam manter uma relação confiável entre identidade, solicitação, permissão, aprovação e resultado.

Se um Agente altera um contrato, a organização deve conseguir demonstrar:

* Qual identidade foi autenticada;

* Quais permissões estavam ativas;

* Qual solicitação originou a mudança;

* Quem autorizou a operação;

* Qual informação foi modificada;

* Qual foi o resultado;

* Se o registro permaneceu protegido contra alterações.

A auditoria também serve antes de um incidente. Ela ajuda a localizar permissões excessivas, ações incomuns, tentativas repetidas e comportamentos fora do padrão.

Permissões limitadas reduzem o impacto de prompt injection

Uma política de identidade não impede que um Agente interprete uma instrução maliciosa. Ela pode limitar o que essa instrução consegue causar.

O NIST relaciona identidade e autorização à prevenção e mitigação de prompt injection. Em uma consulta sobre segurança de sistemas de Agentes IA, o instituto também destacou a necessidade de restringir e monitorar o alcance do acesso concedido ao Agente no ambiente de implantação.

Se um Agente de atendimento possui somente permissão de leitura sobre os pedidos daquele cliente, uma tentativa de fazê-lo excluir registros deve ser bloqueada pela camada de autorização, independentemente do que o modelo decidiu solicitar.

Essa separação é importante. O prompt orienta o comportamento, mas não deve ser a única barreira de segurança.

O modelo pode solicitar uma ação. O sistema de autorização decide se ela pode acontecer.

Esse controle reduz o impacto do risco de prompt injection no atendimento, porque uma instrução maliciosa não herda automaticamente todas as capacidades disponíveis na infraestrutura.

Um exemplo de arquitetura mais segura

Considere um Agente responsável por atender clientes e consultar pedidos.

Ao receber uma mensagem, o sistema identifica o cliente e cria um contexto de atendimento. O Agente possui identidade própria e se autentica diante de uma camada intermediária de ferramentas.

Quando precisa consultar um pedido, ele não acessa diretamente o banco de dados. Em vez disso, chama uma operação específica, como `consultar_pedido`.

A camada de autorização verifica:

* A identidade do Agente;

* A identidade do cliente;

* Se o pedido pertence àquele cliente;

* Se o Agente possui permissão de leitura;

* Se a operação está dentro do contexto da conversa.

Somente depois dessas verificações a consulta é executada.

Caso o cliente peça um cancelamento, o Agente pode preparar a solicitação sem necessariamente concluí-la. A política pode exigir uma confirmação adicional, aprovação humana ou uma ferramenta separada com permissões mais restritas.

Todas as etapas recebem o mesmo identificador de operação. Assim, a empresa consegue reconstruir a sequência posteriormente.

Esse desenho também facilita testes. Antes de colocar o sistema em produção, a equipe pode validar se cada ferramenta recusa ações fora do escopo, como parte do processo de testar um Agente IA antes do go-live.

Como diagnosticar a situação atual da empresa

Antes de adicionar novas ferramentas ao Agente, a empresa pode fazer um diagnóstico simples:

* O Agente possui uma identidade própria em cada sistema importante?

* É possível distinguir suas ações das ações realizadas por funcionários?

* Agentes diferentes usam credenciais diferentes?

* As permissões estão separadas por ação, recurso e nível de risco?

* O Agente possui acesso administrativo apenas porque era mais fácil configurá-lo assim?

* É possível revogar seu acesso sem afetar outros sistemas?

* A delegação preserva tanto a identidade humana quanto a identidade do Agente?

* Operações críticas exigem uma aprovação específica?

* Os registros mostram solicitação, autorização, execução e resultado?

* A empresa conseguiria reconstruir uma ação incorreta ocorrida há três meses?

Quanto mais respostas negativas, maior a dificuldade de responsabilizar o Agente e limitar um incidente.

Um caminho prático para implementar identidade e permissões

A empresa não precisa começar pela arquitetura mais sofisticada. Pode organizar primeiro os controles fundamentais.

1. Faça um inventário dos Agentes

Liste os Agentes e automações capazes de executar ações. Registre a finalidade, o responsável, o ambiente, os sistemas acessados e o nível de autonomia.

2. Substitua contas compartilhadas

Crie identidades próprias para cada Agente. Separe também as credenciais de sistemas diferentes, mesmo quando pertencem ao mesmo departamento.

3. Mapeie as ações disponíveis

Diferencie leitura, criação, atualização, aprovação, exclusão, exportação e administração. Uma integração não deveria ser tratada como uma permissão única.

4. Reduza os acessos

Conceda apenas o necessário para a função atual. Não libere permissões para capacidades que talvez sejam usadas no futuro.

5. Defina aprovações por risco

Estabeleça quais ações são autônomas, quais exigem confirmação do cliente e quais dependem de autorização interna.

6. Centralize os registros

Vincule solicitação, identidade, política aplicada, aprovação, execução e resultado ao mesmo identificador de operação.

7. Teste rotação e revogação

A empresa precisa conseguir trocar uma credencial ou desativar um Agente sem interromper toda a operação.

Depois dessa base, a arquitetura pode evoluir para tokens de curta duração, autorização baseada em contexto, identidades de workload, políticas dinâmicas e mecanismos criptográficos de comprovação.

O primeiro avanço é deixar de tratar o Agente como uma extensão invisível da conta de alguém.

A responsabilidade começa pela capacidade de identificar quem agiu

Um Agente IA não precisa ser considerado uma pessoa para possuir uma identidade operacional.

A identidade permite que os sistemas reconheçam aquela entidade, apliquem permissões específicas, registrem suas ações e preservem a relação com as pessoas que solicitaram ou aprovaram cada operação.

Sem isso, a empresa pode ganhar automação e perder visibilidade. Quanto mais o Agente age, mais difícil se torna distinguir erro humano, falha de integração, decisão do modelo e acesso indevido.

A pergunta deixa de ser apenas “o Agente consegue executar essa tarefa?” e passa a incluir outras três:

Ele deveria executar? Em nome de quem? Como a empresa provará o que aconteceu depois?

Se o Agente pode agir em um sistema, ele também precisa ser identificado e responsabilizado dentro desse sistema.