A inteligência artificial está deixando de apenas responder perguntas para executar tarefas, tomar decisões e interagir com sistemas corporativos. Mas existe uma questão que muitas organizações ainda não conseguiram responder: quem governa as identidades e os acessos desses agentes?
A identidade está mudando. O IAM também precisa mudar.
Durante décadas, os programas de Identity and Access Management (IAM) foram estruturados em torno de um conceito relativamente previsível: pessoas precisam acessar sistemas para realizar suas atividades profissionais.
Um colaborador é contratado, recebe uma identidade digital, ganha permissões de acordo com sua função e, eventualmente, tem seus acessos removidos quando deixa a organização.
Esse modelo evoluiu para incorporar contas de serviço, integrações, workloads e outras identidades não humanas (Non-Human Identities — NHI).
Entretanto, a chegada dos agentes autônomos de inteligência artificial representa uma transformação muito mais profunda.
Diferentemente de uma integração tradicional, que normalmente executa operações previamente definidas, um agente de IA pode interpretar objetivos, selecionar ferramentas, consultar diferentes fontes de informação e executar uma sequência de ações sem intervenção humana em cada etapa.
Imagine um agente responsável por apoiar o departamento financeiro. Ele pode consultar informações no ERP, analisar contratos, interagir com APIs bancárias, gerar relatórios e solicitar aprovações.
Agora imagine centenas desses agentes operando simultaneamente em diferentes áreas da empresa.
Estamos criando uma nova força de trabalho digital, mas ainda tentando governá-la com mecanismos desenvolvidos principalmente para identidades humanas e aplicações tradicionais.
O desafio não é simplesmente autenticar agentes. É estabelecer confiança, responsabilidade, limites operacionais e mecanismos de controle sobre entidades capazes de agir autonomamente.
1. O agente de IA precisa ter uma identidade própria
Um dos maiores riscos da adoção corporativa de agentes de IA é a utilização de credenciais compartilhadas, contas técnicas genéricas ou identidades pertencentes aos próprios colaboradores.
Quando um agente executa uma operação utilizando a identidade de um funcionário, surgem problemas importantes.
Como distinguir uma ação humana de uma ação automatizada? Como identificar qual agente realizou determinada operação? Quem é responsável pelas permissões concedidas? Como revogar o acesso de um agente sem interromper o trabalho de outras aplicações?
A resposta começa com um princípio fundamental:
Todo agente de IA que interage com recursos corporativos deve possuir uma identidade identificável, governável e rastreável.
Isso significa que o IAM precisa reconhecer os agentes como entidades próprias dentro do ecossistema de identidades.
Uma identidade de agente deve possuir atributos como:
- Identificador único e verificável.
- Proprietário ou responsável de negócio.
- Finalidade e escopo operacional.
- Aplicações e recursos autorizados.
- Ambiente de execução.
- Classificação de risco.
- Data de criação e validade.
- Relação com outros agentes, serviços e identidades humanas.
Essa estrutura permite estabelecer um inventário confiável das identidades artificiais presentes na organização.
Mas existe uma diferença importante: registrar um agente não significa necessariamente confiar nele.
A confiança precisa ser construída e continuamente verificada.
2. O princípio do menor privilégio precisa acompanhar o contexto
O conceito de Least Privilege sempre foi um dos fundamentos do IAM.
Um usuário deve receber somente as permissões necessárias para executar suas atividades.
Entretanto, agentes de IA apresentam um comportamento diferente.
Um agente pode iniciar uma tarefa com uma necessidade limitada de acesso e, durante sua execução, identificar a necessidade de consultar outra aplicação ou solicitar uma operação adicional.
Isso não significa que o agente deva receber automaticamente novas permissões.
Significa que a arquitetura de autorização precisa ser capaz de avaliar solicitações dinamicamente.
Considere um agente responsável por analisar fornecedores.
Ele pode precisar consultar informações cadastrais no ERP, verificar documentos em um repositório corporativo e consultar indicadores financeiros.
Entretanto, nenhuma dessas atividades exige necessariamente autorização para modificar dados bancários ou aprovar pagamentos.
Em um modelo tradicional, seria relativamente simples conceder ao agente um perfil amplo para evitar problemas de integração.
Esse caminho, porém, cria riscos significativos.
O modelo mais adequado combina mecanismos como Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), políticas contextuais e privilégios temporários.
A autorização pode considerar não apenas quem é o agente, mas também:
- Qual tarefa está sendo executada.
- Qual recurso está sendo solicitado.
- Qual operação será realizada.
- Quem autorizou a execução.
- Qual é a classificação dos dados.
- Qual é o nível de risco da operação.
A identidade estabelece quem está solicitando o acesso. A autorização determina o que essa identidade pode fazer naquele contexto.
Essa distinção será cada vez mais importante em ambientes de inteligência artificial.
3. O ciclo de vida das identidades artificiais precisa ser governado
O Identity Governance and Administration (IGA) tradicional utiliza eventos de recursos humanos para controlar o ciclo de vida de colaboradores.
Admissões, movimentações internas e desligamentos funcionam como gatilhos para provisionamento e desprovisionamento.
Mas qual é o equivalente desses eventos para um agente de IA?
Um agente pode ser criado por um desenvolvedor, publicado por uma equipe de negócio, replicado automaticamente ou ativado temporariamente para executar um processo.
Também pode deixar de ser utilizado sem que ninguém perceba.
Isso cria um problema de governança semelhante ao das contas órfãs, mas potencialmente em escala muito maior.
A organização precisa estabelecer um ciclo de vida específico para identidades artificiais.
Criação e registro
Nenhum agente deve acessar recursos corporativos sem possuir um registro formal, uma finalidade conhecida e um responsável identificado.
Aprovação e provisionamento
As permissões devem ser concedidas com base no propósito do agente e no risco das operações que ele poderá executar.
Operação e monitoramento
As atividades devem ser acompanhadas para identificar alterações de comportamento, utilização indevida de privilégios e acessos incompatíveis com sua finalidade.
Revisão e certificação
As permissões precisam ser periodicamente reavaliadas. O responsável pelo agente deve confirmar sua necessidade, seu escopo e os recursos acessíveis.
Desativação e eliminação
Agentes descontinuados precisam ter credenciais, tokens, sessões e permissões revogados.
Um ponto adicional merece atenção: agentes capazes de criar outros agentes ou delegar tarefas precisam preservar a relação entre a identidade original e as identidades derivadas.
Sem essa rastreabilidade, uma organização pode perder rapidamente a capacidade de compreender quem está executando determinada operação.
4. A autenticação precisa evoluir além das credenciais estáticas
Durante muito tempo, contas de serviço e integrações corporativas dependeram de senhas, API keys e outros segredos de longa duração.
Embora essas tecnologias continuem presentes em muitos ambientes, sua utilização indiscriminada em arquiteturas de agentes amplia a superfície de ataque.
Uma credencial comprometida pode permitir que um invasor execute operações utilizando os mesmos privilégios concedidos ao agente legítimo.
Além disso, o compartilhamento de credenciais dificulta a atribuição de responsabilidade.
A evolução passa por mecanismos mais robustos de autenticação de workloads e identidades não humanas.
Entre as abordagens possíveis estão OAuth 2.0, credenciais de curta duração, identidades de workload, certificados e mecanismos de autenticação baseados em criptografia assimétrica.
Tecnologias como SPIFFE e SPIRE também podem contribuir para estabelecer identidades verificáveis entre componentes de infraestrutura.
Entretanto, autenticar corretamente um agente é apenas parte do problema.
Um agente autenticado ainda pode tentar executar uma operação não autorizada, receber instruções maliciosas ou utilizar indevidamente os privilégios disponíveis.
Por isso, autenticação e autorização precisam operar de forma complementar.
Um agente legítimo não deve possuir liberdade ilimitada simplesmente porque sua identidade foi autenticada.
5. O IAM precisa compreender o comportamento dos agentes
Os mecanismos tradicionais de monitoramento de identidade foram desenvolvidos principalmente para identificar comportamentos suspeitos associados a usuários e contas privilegiadas.
Tentativas de autenticação incomuns, acessos fora do horário habitual e mudanças inesperadas de localização são exemplos conhecidos.
Entretanto, esses indicadores nem sempre fazem sentido para agentes de IA.
Um agente pode operar continuamente, executar milhares de chamadas de API e acessar diferentes aplicações em poucos segundos.
Esse comportamento pode ser perfeitamente legítimo.
O desafio passa a ser identificar quando o agente está realizando algo incompatível com sua finalidade.
Imagine um agente criado para consultar pedidos de clientes.
Durante uma execução, ele começa a acessar informações de recursos humanos ou tenta exportar grandes volumes de dados financeiros.
Mesmo utilizando credenciais válidas, seu comportamento representa um potencial risco.
É nesse contexto que conceitos como Identity Threat Detection and Response (ITDR) precisam ser ampliados para identidades artificiais.
O monitoramento deve considerar o comportamento esperado de cada agente, suas permissões, as ferramentas utilizadas e a sequência de operações realizadas.
Também é necessário correlacionar eventos de identidade com registros de execução dos agentes, chamadas de ferramentas e decisões de autorização.
Essa abordagem permite identificar situações como uso indevido de credenciais, elevação inesperada de privilégios, movimentação lateral e tentativas de acesso fora do escopo autorizado.
6. MCP e agentes interconectados criam novos desafios de autorização
A adoção do Model Context Protocol (MCP) e de arquiteturas multiagentes acrescenta outra dimensão ao problema.
Agentes podem utilizar servidores MCP para acessar ferramentas, consultar informações e interagir com sistemas corporativos.
Isso facilita integrações, mas também cria novos pontos de exposição.
Imagine um agente de atendimento que utiliza um servidor MCP para consultar informações no CRM.
O agente possui uma identidade. O servidor MCP possui sua própria identidade técnica. O sistema CRM também exige autenticação e autorização.
Nesse cenário, uma pergunta importante surge:
A autorização deve considerar apenas a identidade técnica que acessa o CRM ou também o agente e o usuário que originaram a solicitação?
Se todos os agentes utilizarem uma única conta privilegiada no sistema de destino, os controles podem perder granularidade e rastreabilidade.
Uma arquitetura mais segura deve preservar, sempre que tecnicamente possível, o contexto da identidade solicitante, a finalidade da operação e os limites de delegação.
Também precisa evitar que um agente utilize a autoridade de outro para executar operações que originalmente não poderia realizar.
Esse problema é particularmente relevante em cenários de delegação de tarefas entre múltiplos agentes.
O crescimento dessas arquiteturas exigirá uma integração mais profunda entre IAM, API Security, governança de IA e mecanismos de autorização distribuída.
7. Governança também significa saber interromper um agente
Existe uma diferença importante entre desativar a conta de um colaborador e interromper um agente autônomo.
Um agente pode estar executando processos, mantendo sessões ativas, utilizando tokens temporários e coordenando operações em diferentes aplicações.
Desabilitar sua identidade no diretório central pode não interromper imediatamente todas essas atividades.
Por isso, a governança de agentes precisa contemplar mecanismos de contenção e resposta.
Em situações de risco, a organização deve conseguir suspender novas execuções, revogar credenciais e sessões quando suportado, bloquear operações privilegiadas e interromper tarefas em andamento.
Também precisa avaliar as consequências operacionais dessa interrupção.
Um agente responsável por atualizar registros financeiros, por exemplo, pode deixar transações incompletas caso seja interrompido sem mecanismos adequados de recuperação.
A segurança precisa trabalhar em conjunto com a resiliência operacional.
O objetivo não é apenas desligar agentes, mas garantir que sua interrupção ocorra de maneira controlada, auditável e segura.
8. A governança de agentes não pode ser responsabilidade exclusiva da equipe de IA
Um erro comum seria tratar a segurança de agentes como uma responsabilidade restrita aos profissionais que desenvolvem modelos e aplicações de inteligência artificial.
Na realidade, o desafio envolve diferentes disciplinas.
As equipes de IAM devem governar identidades, permissões e ciclos de vida.
As equipes de segurança precisam monitorar ameaças e responder a comportamentos suspeitos.
Os arquitetos de aplicações devem implementar autenticação, autorização e mecanismos seguros de delegação.
As áreas de negócio precisam assumir responsabilidade pelos agentes utilizados em seus processos.
E as equipes de governança devem estabelecer políticas, responsabilidades e critérios de conformidade.
Essa colaboração é fundamental porque os riscos não estão concentrados em uma única tecnologia.
Eles surgem da combinação entre autonomia, acesso a dados, integrações corporativas e capacidade de executar operações.
O futuro é o Agent Identity Governance
A evolução do IAM aponta para uma nova disciplina dentro da governança de identidades: Agent Identity Governance (AIG).
Não se trata simplesmente de adicionar agentes de IA ao inventário de contas de serviço.
Trata-se de construir uma estrutura capaz de responder continuamente a perguntas fundamentais:
Quem criou esse agente? Quem é responsável por ele? Qual é sua finalidade? Quais recursos ele pode acessar? Quem autorizou suas ações? Como identificar comportamentos anormais? Como interromper sua execução? Como demonstrar conformidade?
Essa estrutura deve integrar capacidades de IGA, Access Management, Privileged Access Management (PAM), ITDR e governança de identidades não humanas.
Também precisa incorporar mecanismos de autorização contextual e observabilidade específicos para arquiteturas de inteligência artificial.
O desafio não será apenas tecnológico.
Organizações precisarão rever processos, modelos de responsabilidade, políticas de segurança e critérios de avaliação de riscos.
Por onde começar?
Antes de investir em uma nova plataforma, as organizações podem iniciar com algumas ações práticas:
- Descobrir os agentes existentes: identificar agentes em produção, pilotos e integrações que utilizam inteligência artificial.
- Definir responsabilidades: atribuir um proprietário de negócio e um responsável técnico para cada agente.
- Classificar riscos: avaliar os dados, sistemas e operações acessíveis.
- Revisar privilégios: eliminar credenciais compartilhadas e permissões excessivas sempre que possível.
- Estabelecer controles de autorização: limitar operações conforme identidade, contexto e finalidade.
- Implementar rastreabilidade: correlacionar agentes, usuários, ferramentas e operações executadas.
- Preparar mecanismos de resposta: testar revogação, suspensão e interrupção segura de agentes.
Essas medidas permitem criar uma base de governança antes que o número de identidades artificiais se torne difícil de controlar.
Conclusão: a próxima grande transformação do IAM já começou
A inteligência artificial está modificando a maneira como as organizações utilizam tecnologia.
Durante anos, o IAM respondeu principalmente à pergunta: quem pode acessar o quê?
Com os agentes de IA, essa pergunta se torna mais complexa.
Agora precisamos compreender quem está agindo, em nome de quem, com qual finalidade, utilizando quais ferramentas e dentro de quais limites.
A autonomia dos agentes não elimina a necessidade de governança. Pelo contrário, torna essa governança ainda mais importante.
Organizações que conseguirem integrar identidade, autorização, observabilidade e controle estarão mais preparadas para aproveitar os benefícios da inteligência artificial sem comprometer a segurança.
Aquelas que continuarem tratando agentes autônomos como simples contas técnicas poderão descobrir que seus modelos de IAM já não oferecem a visibilidade necessária.
A próxima geração do IAM não será responsável apenas por controlar o acesso de pessoas e aplicações. Ela precisará governar também as decisões e ações de identidades artificiais.
E talvez essa seja a pergunta mais importante para os líderes de cibersegurança nos próximos anos:
Se um agente de IA pode tomar decisões e executar ações dentro da sua organização, quem garante que ele está fazendo apenas aquilo que deveria?
