Identidades e privilégios de agentes de IA e os desafios de governança Sua empresa está preparada para governá-los Agentes de IA podem…
Identidades e privilégios de agentes de IA e os desafios de governança
Sua empresa está preparada para governá-los
Agentes de IA podem responder perguntas, 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, os agentes de IA precisam se autenticar e receber permissões. É nesse ponto que a Governança de IA encontra um tema já conhecido pelas áreas de segurança: identidade e acesso.
Existe, porém, uma diferença importante. Uma aplicação tradicional costuma executar funções previamente programadas. Um agente interpreta o contexto, define etapas e escolhe ferramentas para alcançar um objetivo. Mesmo quando usa credenciais válidas, seu comportamento pode resultar em uma ação inadequada, excessiva ou diferente da esperada.
Por isso, a pergunta deixou de ser apenas se o agente está autorizado a entrar. Também precisamos entender o que ele pode fazer depois que o acesso é concedido e quem responde por suas ações.
Por que uma credencial legítima não garante uma 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 poderá levá-lo a consultar informações indevidas ou iniciar um reembolso fora dos critérios definidos.
Para os sistemas envolvidos, a requisição poderá parecer legítima, pois 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 mostra por que os modelos tradicionais de controle de acesso precisam evoluir. Autenticar o agente é necessário, mas não é suficiente. A organização também precisa avaliar a relação entre identidade, privilégios, nível de autonomia e 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 os agentes sejam tratados separadamente de outras entidades e recebam apenas as permissões necessárias para cumprir sua função.
Como os agentes de IA usam identidades
Um dos primeiros pontos da governança de identidades de agentes de IA é entender como cada agente se apresenta aos sistemas com os quais interage.
O agente pode atuar com identidade própria, usar uma identidade técnica compartilhada ou receber acesso delegado por um usuário. Cada modelo gera riscos diferentes e exige controles específicos.
Quando vários agentes usam a mesma conta, torna-se mais difícil identificar qual deles executou uma ação. Se o agente herdar todas as permissões de um usuário, poderá acessar recursos desnecessários para sua finalidade. Quando as credenciais permanecem ativas por tempo indeterminado, o risco continua existindo mesmo depois que o agente deixa de ser utilizado.
Uma identidade própria e claramente atribuída melhora a visibilidade, mas não resolve o problema sozinha. A organização ainda precisa definir quem é responsável pelo agente, quais ações estão autorizadas e como seu acesso será revisado durante todo o ciclo de vida.
Como avaliar riscos de acesso com base em autonomia e impacto
Dois agentes conectados ao mesmo sistema podem representar níveis de risco completamente diferentes.
Um agente pode apenas consultar informações e apresentar recomendações para uma pessoa. Outro pode alterar dados, aprovar solicitações ou executar transações sem validação humana. Embora ambos utilizem IA, eles não devem receber os mesmos privilégios nem ficar sujeitos aos mesmos controles.
A classificação de risco deve 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 maiores forem a autonomia e o impacto potencial, mais restritos devem ser os privilégios e mais forte deve ser a supervisão.
O princípio do menor privilégio aplicado aos agentes
O princípio do menor privilégio também se aplica aos agentes de IA. Cada agente deve receber somente os acessos necessários para cumprir uma finalidade definida.
Na prática, conceder acesso apenas ao sistema correto pode não ser suficiente. Também é necessário limitar as ações permitidas dentro desse sistema.
Um agente responsável por consultar pedidos não precisa 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.
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.
Proteção de credenciais e segredos
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, poderão 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;
- usar 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 em caso de mudança, incidente ou desativação;
- impedir que informações sensíveis sejam expostas em logs, memórias ou respostas.
O objetivo não é somente proteger a credencial contra roubo. Também é reduzir o que pode ser feito com ela caso algo saia do esperado.
Rastreabilidade e responsabilidade pelas ações dos agentes
Quando um agente executa uma ação, a organização precisa conseguir reconstruir o que aconteceu. Essa reconstrução depende de uma identidade clara associada à ação.
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 para uma conta genérica, e não para o agente que realmente agiu. Mesmo com os registros técnicos em ordem, a empresa não consegue responder a uma pergunta básica: qual agente tomou a decisão e com base em qual contexto?
Por isso, a rastreabilidade não depende somente de logs bem estruturados. Ela também exige identidades bem definidas. Sem uma identidade própria e atribuída a cada agente, a cadeia de evidências se rompe, pois não é possível separar quem fez o quê quando diferentes agentes usam a mesma credencial.
Investir em identidade permite que os esforços de auditoria, resposta a incidentes e revisão de acessos funcionem. Um sistema pode registrar cada chamada de API, cada decisão e cada resultado gerado. Porém, se essas informações não estiverem associadas a uma identidade específica, a empresa terá dados, mas não conseguirá atribuir responsabilidades.
Rastreabilidade não significa coletar informações indiscriminadamente. Os registros devem ser planejados para apoiar segurança, auditoria e resposta a incidentes, respeitando os requisitos de privacidade e retenção da organização.
Ciclo de vida do acesso dos agentes
Todo agente de IA deve ter um ciclo de vida governado. Isso inclui aprovação antes da entrada em operação, identidade definida, responsável formalmente nomeado, permissões documentadas, revisões periódicas e critérios claros para suspensão ou desativação.
Algumas perguntas ajudam a identificar 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?
- As 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.
Governança de identidades sem bloquear a inovação
A segurança não precisa participar do processo somente 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 conhecidas de IAM, IGA, PAM e Zero Trust oferecem uma base importante. Elas, porém, 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, a organização precisa 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.
Quando os agentes passam a agir em nome da empresa, governar suas identidades e seus privilégios deixa de ser uma preocupação futura e passa a fazer parte da segurança do presente.
