Agentes de IA também têm identidades e privilégios. Sua empresa está preparada para governá-los?

Agentes de IA, além de responder perguntas, podem consultar bases de dados, acessar sistemas internos, acionar APIs, criar registros, enviar mensagens, aprovar etapas de um processo e executar tarefas em nome do negócio.

Para realizar essas ações, precisam se autenticar e receber permissões. É nesse ponto que a discussão sobre Governança de IA confronta um tema conhecido pelas áreas de segurança: identidade e acesso.

Mas existe uma diferença importante. Uma aplicação tradicional costuma executar funções previamente programadas. Um agente interpreta contexto, define etapas e escolhe ferramentas para alcançar um objetivo. Mesmo quando utiliza credenciais válidas, seu comportamento pode produzir uma ação inadequada, excessiva ou diferente da esperada.

Por isso, a pergunta já não é apenas “o agente está autorizado a entrar?”. Também precisamos perguntar:

O que ele pode fazer depois que o acesso é concedido, e quem responde por suas ações?

Credencial legítima não significa ação legítima

Imagine um agente criado para apoiar o atendimento ao cliente. Ele consulta pedidos, acessa dados cadastrais e solicita reembolsos por meio de uma API.

Se esse agente operar com uma conta compartilhada e permissões amplas, uma instrução mal interpretada, uma manipulação de contexto ou uma falha nos controles pode levá-lo a consultar informações que não deveria ou a iniciar um reembolso fora dos critérios definidos.

Para os sistemas envolvidos, a requisição poderá parecer legítima. A credencial é válida e a permissão existe. O problema está na ação realizada e no contexto em que ela foi autorizada.

Esse cenário ajuda a entender por que os modelos tradicionais de controle de acesso precisam evoluir. Autenticar o agente é necessário, mas não suficiente. É preciso avaliar a relação entre sua identidade, seus privilégios, seu nível de autonomia e o impacto potencial de cada ação.

A OWASP classifica o abuso de identidade e privilégios entre os principais riscos das aplicações agênticas. Em uma proposta de perfil de cibersegurança para IA, o NIST orienta que agentes sejam tratados separadamente de outras entidades e recebam apenas as permissões necessárias para cumprir sua função.

De quem é a identidade usada pelo agente?

Um dos primeiros pontos de governança é identificar como o agente se apresenta aos sistemas com os quais interage.

Ele pode atuar com uma identidade própria, utilizar uma identidade técnica compartilhada ou receber acesso delegado por um usuário. Cada modelo produz riscos e necessidades de controle diferentes.

Quando vários agentes usam a mesma conta, por exemplo, torna-se mais difícil descobrir qual deles executou determinada ação. Quando o agente herda todas as permissões de um usuário, pode acessar recursos que não são necessários para sua finalidade. Quando credenciais permanecem ativas por tempo indeterminado, o risco continua existindo mesmo que o agente deixe de ser utilizado.

Uma identidade própria e claramente atribuída melhora a visibilidade, mas não resolve tudo sozinha. A organização ainda precisa definir quem é responsável por esse agente, quais ações estão autorizadas e como seu acesso será revisto durante todo o ciclo de vida.

O risco está na combinação entre acesso, autonomia e impacto

Dois agentes conectados ao mesmo sistema podem representar riscos completamente diferentes.

Um deles apenas consulta informações e apresenta recomendações para uma pessoa. O outro pode alterar dados, aprovar solicitações ou executar transações sem validação humana. Embora ambos utilizem IA, não deveriam receber os mesmos privilégios nem estar sujeitos aos mesmos controles.

A classificação de risco precisa considerar, pelo menos:

• quais dados o agente pode consultar ou modificar;
• quais sistemas, ferramentas, APIs e servidores MCP pode acionar;
• se atua com identidade própria, compartilhada ou delegada;
• quais decisões pode tomar sem aprovação humana;
• se suas ações podem ser revertidas;
• qual seria o impacto financeiro, operacional, regulatório ou reputacional de um erro;
• se outro agente ou usuário pode influenciar seu comportamento.

Quanto maior a autonomia e o impacto potencial, mais restritos devem ser os privilégios e mais forte deve ser a supervisão.

Menor privilégio também se aplica aos agentes

O princípio do menor privilégio continua válido: cada agente deve receber somente os acessos necessários para cumprir uma finalidade definida.

Na prática, porém, conceder acesso apenas ao sistema correto pode não ser suficiente. Também é preciso limitar as ações permitidas dentro dele.

Um agente responsável por consultar pedidos não precisa necessariamente alterar cadastros. Um agente que prepara um pagamento não precisa aprová-lo. Um agente que agenda uma reunião não precisa acessar todas as caixas de e-mail da organização.

Sempre que possível, as permissões devem ser específicas quanto ao recurso, à ação, ao contexto e ao período de uso. Operações críticas podem exigir aprovação humana, autenticação adicional, limites de valor ou validações externas ao próprio modelo.

Esse último ponto é essencial: o agente não deve decidir sozinho se está autorizado a executar uma ação sensível. A autorização precisa ser aplicada por controles confiáveis fora do modelo.

Credenciais e segredos exigem proteção própria

Tokens, chaves de API, senhas e outros segredos permitem que o agente se conecte às ferramentas necessárias para executar suas tarefas. Se forem expostos, reutilizados de forma indevida ou armazenados sem proteção, podem ampliar o alcance de um incidente.

Algumas práticas precisam fazer parte da arquitetura:

• evitar credenciais embutidas em prompts, códigos ou arquivos de configuração desprotegidos;
• utilizar cofres e mecanismos adequados para armazenar segredos;
• priorizar credenciais temporárias e de curta duração;
• rotacionar chaves e tokens de forma controlada;
• separar credenciais por agente, ambiente e finalidade;
• revogar rapidamente o acesso quando houver mudança, incidente ou desativação;
• impedir que informações sensíveis sejam expostas em logs, memórias ou respostas.

O objetivo não é apenas proteger a credencial contra roubo. É reduzir o que pode ser feito com ela caso algo saia do esperado.

Rastreabilidade é o que transforma acesso em responsabilidade

Quando um agente executa uma ação, a organização precisa conseguir reconstruir o que aconteceu. Mas essa reconstrução só é possível quando existe uma identidade clara por trás da ação.

Pensa assim: se vários agentes compartilham a mesma conta, ou se um agente herda a identidade de um usuário humano, cada evento registrado no log aponta pra essa conta genérica, não para o agente que de fato agiu. Nesse cenário, mesmo com todos os registros técnicos em ordem, a empresa não consegue responder à pergunta mais simples: qual agente tomou essa decisão, com base em qual contexto?

É por isso que rastreabilidade não é só uma questão de log bem-feito. É uma questão de identidade bem definida. Sem uma identidade própria e atribuída a cada agente, a cadeia de evidência quebra antes mesmo de começar, porque não tem como separar quem fez o quê quando todos os “quem” se confundem numa credencial só.

Na prática, isso significa que investir em identidade não é uma etapa isolada de segurança. É o que permite que qualquer esforço de auditoria, resposta a incidente ou revisão de acesso realmente funcione depois. Um sistema pode até registrar cada chamada de API, cada decisão, cada resultado gerado, mas se essas informações não puderem ser amarradas a uma identidade específica, a empresa tem dados, não tem responsabilidade.

Rastreabilidade também não deve significar coletar tudo indiscriminadamente. Os registros precisam ser planejados para apoiar segurança, auditoria e resposta a incidentes, respeitando os requisitos de privacidade e retenção da organização.

O acesso do agente precisa ter começo, revisão e fim

Todo agente deveria possuir um ciclo de vida governado. Isso inclui aprovação antes da entrada em operação, identidade definida, responsável nomeado formalmente, permissões documentadas, revisões periódicas e critérios claros para suspensão ou desativação.

Algumas perguntas ajudam a revelar lacunas:

• Existe um inventário dos agentes ativos e das identidades utilizadas por eles?
• Cada agente possui uma finalidade e um responsável claramente definidos?
• É possível saber quais dados, sistemas, APIs e ferramentas cada agente acessa?
• As permissões correspondem à finalidade atual ou foram acumuladas ao longo do tempo?
• Ações sensíveis exigem validação adicional?
• Credenciais podem ser rotacionadas ou revogadas rapidamente?
• A organização consegue atribuir e reconstruir cada ação executada?
• O acesso é removido quando o agente é substituído ou desativado?

Se essas respostas não estiverem claras, a organização pode ter agentes funcionando com acessos legítimos, mas sem governança suficiente sobre o que realizam.

Governar identidades de agentes não é impedir a inovação

A segurança não precisa entrar no processo apenas para bloquear acessos. Seu papel é criar condições para que a adoção avance sem gerar privilégios invisíveis, responsabilidades indefinidas ou ações impossíveis de auditar.

Práticas já conhecidas de IAM, IGA, PAM e Zero Trust oferecem uma base importante. Mas precisam ser adaptadas à autonomia, ao contexto dinâmico e às conexões entre agentes, usuários, ferramentas e sistemas.

Essa adaptação começa pela compreensão do ambiente. Antes de escolher uma tecnologia, é necessário descobrir quais agentes existem, entender como se autenticam, mapear seus privilégios e classificar o impacto das ações que podem executar.

A Afrika apoia as organizações nessa jornada, desde a avaliação de maturidade e o mapeamento de identidades e acessos até a priorização de riscos, a definição de controles, os testes de segurança e o desenho de uma arquitetura de governança adequada ao negócio.

Porque, quando agentes passam a agir em nome da empresa, governar suas identidades e privilégios deixa de ser uma preocupação futura. Torna-se parte da segurança do presente.

Referências técnicas

• OWASP Top 10 for Agentic Applications 2026
• NIST Cybersecurity Framework Profile for Artificial Intelligence
• NIST AI Risk Management Framework
• NIST Zero Trust Architecture