Identidade de agentes de IA: controle sem travar escala

Agentes de IA só escalam com identidade, limites e evidências de cada ação. Quando um agente lê dados, consulta sistemas, altera registros ou inicia fluxos, ele deixa de ser apenas uma interface de linguagem. Passa a operar como uma identidade não humana dentro da empresa.

Essa mudança exige revisar um pressuposto comum: permissões de aplicativo não bastam para governar autonomia. Um agente pode receber uma solicitação legítima e, durante a execução, encontrar instruções maliciosas em e-mails, documentos, páginas ou tickets. Também pode combinar dados de fontes distintas e produzir uma ação que nenhum dos sistemas isolados autorizaria de forma explícita.

O tema ganhou densidade técnica recente. Em fevereiro de 2026, o NIST abriu uma proposta específica sobre identificação, autenticação, autorização, delegação e não repúdio para agentes de software e IA. Em maio, o Google Cloud apresentou identidades de agente como um tipo distinto de principal, separado de usuários e contas de serviço. A OWASP também elevou abuso de identidade e privilégios entre os riscos mais críticos de aplicações agentivas. NIST, 2026 (nccoe.nist.gov) Google Cloud, 2026 (cloud.google.com) OWASP, 2026 (genai.owasp.org)

O que é identidade de agentes de IA e por que ela precisa ser separada?

Identidade de agentes de IA é o registro verificável que distingue um agente de pessoas, aplicações genéricas e outros agentes. Ela deve conter atributos técnicos e operacionais: proprietário, ambiente, finalidade, modelo usado, ferramentas permitidas, origem do código, nível de risco e ciclo de vida.

O erro recorrente é executar o agente com uma conta de serviço ampla ou, pior, com o token permanente de um usuário. Isso reduz o atrito inicial, mas elimina accountability. Depois de um incidente, a equipe sabe que uma credencial executou uma ação, mas não consegue responder questões básicas: qual agente a usou, sob qual objetivo, com qual contexto e a pedido de quem.

Uma identidade própria resolve a separação de responsabilidades. O usuário continua sendo quem solicita uma tarefa. O agente se torna quem a executa. A ferramenta ou API é o recurso protegido. Essa distinção permite aplicar políticas diferentes para cada relação.

O glossário ajuda a tornar o desenho objetivo:

• Identidade não humana: identidade de software, serviço, robô ou agente que acessa recursos sem ser uma pessoa.
• Delegação: autorização temporária para o agente agir em nome de um usuário ou processo.
• Atestação: prova criptográfica de que a carga de trabalho é quem afirma ser, executada no ambiente esperado.
• Não repúdio: capacidade de demonstrar, posteriormente, qual identidade tomou uma ação e com qual autorização.

A separação também impede que o agente seja tratado como um chat corporativo com acesso irrestrito. Um assistente que resume documentos tem um perfil de risco diferente de um agente que altera preços, aprova reembolsos ou abre chamados para fornecedores. A identidade deve expressar essa diferença desde o cadastro.

Quais decisões de acesso precisam ser tomadas a cada ação?

A autorização deve avaliar a ação específica, e não apenas a permissão concedida na instalação. Em sistemas tradicionais, uma aplicação recebe escopos e os usa de maneira relativamente previsível. Em agentes, o caminho de execução muda conforme a tarefa, o contexto recuperado e as ferramentas disponíveis.

Por isso, a decisão de acesso precisa considerar pelo menos sete sinais: identidade do agente, usuário ou processo delegante, recurso solicitado, ação pretendida, dados envolvidos, ambiente e risco transacional. Um agente de atendimento pode consultar o histórico de um cliente. Isso não significa que possa exportar toda a base de contatos ou alterar condições comerciais.

Esse modelo é conhecido como autorização contextual. Ele combina RBAC, ou controle baseado em papéis, com ABAC, ou controle baseado em atributos. RBAC determina uma base simples, como “agente de suporte”. ABAC adiciona condições: região do cliente, classificação do dado, horário, valor financeiro, canal de origem e nível de confiança da sessão.

A documentação recente da Microsoft recomenda preservar a autorização do usuário quando o agente acessa tickets, arquivos, e-mails ou registros de clientes. O padrão de acesso delegado é mais adequado quando há um usuário autenticado; acesso exclusivo da aplicação deve ficar restrito a tarefas de retaguarda, bem delimitadas e auditáveis. Microsoft Learn, 2026 (learn.microsoft.com)

Na prática, a pergunta da política não deve ser “o agente pode usar o CRM?”. Deve ser: “este agente, para este usuário, nesta tarefa, pode ler este registro e executar esta ação agora?”. A diferença parece semântica. É uma diferença de arquitetura.

Como aplicar privilégio mínimo quando o agente decide o próximo passo?

Privilégio mínimo para agentes significa conceder apenas o acesso necessário para a próxima etapa verificável. Não significa entregar um conjunto amplo de permissões porque o fluxo pode, em algum momento, precisar delas.

A forma mais segura de aplicar esse princípio é substituir credenciais permanentes por tokens curtos, específicos e revogáveis. Cada token deve ter escopo limitado por ferramenta, recurso, ação e duração. Um agente que precisa criar uma minuta de proposta pode receber acesso de leitura a dados aprovados do cliente e acesso de escrita apenas a um repositório de rascunhos. Ele não precisa de permissão para enviar o documento, aplicar desconto ou atualizar o cadastro mestre.

Também vale segmentar ferramentas por criticidade. Organize-as em quatro grupos:

1. Consulta de baixo impacto: buscar artigos, status de pedido e documentação pública.
2. Consulta sensível: acessar contratos, dados financeiros, informações de RH ou dados pessoais.
3. Ação reversível: criar rascunhos, abrir tickets, sugerir alterações e atualizar campos não críticos.
4. Ação material: enviar pagamentos, apagar dados, alterar preços, mudar permissões ou firmar compromissos externos.

Os grupos três e quatro exigem políticas adicionais. Para ações materiais, use aprovação just-in-time, ou JIT: a permissão é liberada apenas para aquela decisão, naquele momento, com escopo estrito. O usuário ou gestor não “dá acesso ao agente”; aprova uma ação declarada.

Isso reduz o impacto de dois riscos frequentes. O primeiro é a injeção indireta de prompt, quando conteúdo externo tenta desviar o agente. O segundo é o uso indevido de ferramenta, quando uma instrução aparentemente inofensiva induz uma ação fora da intenção original. A OWASP aponta que abuso de identidade e privilégio apresenta uma das maiores lacunas entre severidade do risco e preparo organizacional. (genai.owasp.org)

Onde deve ficar a política: no prompt, no agente ou na infraestrutura?

A política de autorização deve ser aplicada fora do prompt e validada antes da execução da ferramenta. Prompts orientam comportamento. Eles não são controles de acesso. Um modelo pode interpretar mal uma instrução, receber contexto conflitante ou ser manipulado por conteúdo externo. A decisão de permitir uma transação precisa estar em uma camada determinística.

Uma arquitetura madura tem cinco pontos de controle. O primeiro é o inventário: cada agente, ferramenta, servidor MCP, integração e credencial precisa ser conhecido. MCP, ou Model Context Protocol, é um protocolo usado para conectar modelos e agentes a ferramentas e fontes de contexto. Ele pode acelerar integrações, mas também multiplica a superfície de acesso.

O segundo ponto é o provedor de identidade. Ele emite e valida credenciais do usuário, do agente e das cargas de trabalho. O terceiro é o motor de políticas, que avalia atributos e produz uma decisão de permitir, negar ou pedir aprovação. O quarto é um gateway de ferramentas, que intercepta chamadas a APIs, bancos, sistemas SaaS e automações. O quinto é a camada de observabilidade, responsável por registrar intenção, contexto, decisão, execução e resultado.

O fluxo recomendado é simples:

1. O usuário ou processo inicia uma tarefa.
2. O agente recebe uma identidade própria e uma delegação limitada.
3. Antes de cada chamada de ferramenta, o gateway envia os atributos ao motor de políticas.
4. A política permite, nega ou exige aprovação adicional.
5. O evento é gravado com correlação entre usuário, agente, ferramenta e recurso.

O NIST destaca exatamente essas frentes: identificação, autenticação, autorização dinâmica, delegação, registro de ações e rastreabilidade da origem de dados e prompts. (nccoe.nist.gov) A consequência prática é clara: segurança precisa acompanhar a execução, não apenas o provisionamento inicial.

Que evidências são necessárias para auditar um agente em produção?

Uma trilha de auditoria útil deve reconstruir a cadeia completa de decisão, não apenas listar chamadas de API. Logs convencionais registram que um endpoint foi acionado. Para agentes, isso é insuficiente. É necessário saber por que a ação foi tomada e quais restrições existiam.

Cada evento relevante deve conter um identificador de correlação. Esse identificador vincula a solicitação inicial, o usuário delegante, a versão do agente, o modelo, os documentos recuperados, o plano de ação, as ferramentas chamadas, as decisões de política e a resposta final.

Registre também versões. Um agente pode mudar de comportamento quando há alteração no prompt de sistema, no modelo, na memória, na ferramenta ou na política. Sem versionamento, é difícil comparar incidentes e impossível atribuir uma falha a uma modificação específica.

Há uma distinção importante entre telemetria de execução e evidência de controle. Telemetria mostra latência, volume de chamadas, taxa de erros e custos. Evidência de controle demonstra que uma ação foi autorizada de acordo com a política vigente. Empresas precisam das duas coisas.

Defina indicadores que conectem governança à operação: percentual de agentes inventariados, quantidade de permissões ociosas, volume de ações negadas, aprovações por categoria de risco, tentativas de acesso fora de escopo, tempo para revogar credenciais e cobertura de logs por ferramenta. Esses indicadores revelam se a organização está controlando a autonomia ou apenas observando sua expansão.

Como implementar a identidade de agentes sem paralisar a operação?

A implementação deve começar pelos agentes que já acessam sistemas críticos, não por uma plataforma idealizada. O objetivo inicial é reduzir exposição real e criar padrões reutilizáveis.

Comece com um inventário de 30 dias. Liste agentes em produção, protótipos com acesso a dados reais, integrações de automação, contas de serviço usadas por agentes, ferramentas MCP e credenciais armazenadas em cofres ou variáveis de ambiente. Classifique cada item por autonomia, dados acessados e impacto de suas ações.

Em seguida, escolha um fluxo de alto valor e risco controlável. Bons candidatos são triagem de tickets, preparação de propostas, consolidação de indicadores ou atualização assistida de cadastros. Evite iniciar por pagamentos, exclusão de dados, permissões administrativas ou decisões regulatórias.

Crie para esse fluxo uma identidade exclusiva de agente, tokens curtos, escopos por ferramenta e aprovação JIT para ações materiais. Depois, implemente o registro de correlação e simule falhas: instrução maliciosa em documento, token expirado, tentativa de leitura fora do escopo, ferramenta indisponível e alteração de contexto durante a execução.

A expansão deve ocorrer por padrões, não por cópias improvisadas. Um catálogo interno de agentes, ferramentas aprovadas, políticas-modelo e requisitos mínimos de logging reduz divergências entre times. Plataformas de orquestração, como a Centriu, podem concentrar visibilidade operacional, desde que a autorização continue sendo aplicada por controles independentes e verificáveis.

O resultado esperado não é impedir agentes de agir. É fazer com que cada ação tenha uma identidade, uma autoridade explícita, um limite técnico e uma evidência recuperável. Essa é a base para transformar automação em capacidade operacional sustentável.