INTELIGÊNCIA ARTIFICIAL / IDENTIDADE E ACESSO
À medida que agentes de inteligência artificial deixam de apenas responder perguntas e passam a acessar sistemas, consultar dados, usar ferramentas e executar ações, a identidade digital deixa de ser um detalhe de implementação e se torna um controle central de segurança, governança e responsabilização.
Durante décadas, a gestão de identidades corporativas foi organizada em torno de dois grandes grupos: pessoas e cargas de trabalho. Usuários humanos recebem contas, funções e privilégios; aplicações, serviços e máquinas utilizam identidades técnicas. A expansão dos agentes de IA acrescenta um terceiro elemento com características próprias: software capaz de interpretar contexto, escolher ferramentas e iniciar ações em nome de uma pessoa ou processo. Essa autonomia muda a pergunta de segurança. Já não basta saber qual modelo de IA respondeu a uma solicitação. É necessário saber qual agente atuou, em nome de quem, com quais permissões, sobre quais recursos, durante quanto tempo e com qual evidência de auditoria. Sem essas respostas, uma organização pode ganhar automação enquanto perde rastreabilidade.
Um agente não deveria herdar silenciosamente toda a autoridade do usuário que o acionou. A identidade do humano, a identidade do agente e a autorização para uma ação específica são elementos relacionados, mas não equivalentes. Separá-los permite aplicar menor privilégio, limitar escopo, revogar acesso e reconstruir posteriormente o que aconteceu.
De ferramenta de IA a principal digital
O NIST colocou essa discussão no centro de uma iniciativa dedicada à identidade e autorização de agentes de software e IA. O projeto do National Cybersecurity Center of Excellence parte de um problema concreto: os sistemas atuais de identidade foram projetados principalmente para usuários humanos e aplicações relativamente previsíveis, enquanto agentes autônomos podem operar em múltiplos serviços e tomar decisões dinâmicas. Na prática, tratar um agente como um principal digital significa atribuir a ele uma identidade distinguível, credenciais apropriadas e políticas que determinem o que pode fazer. Isso não transforma o agente em uma pessoa. Significa apenas que sua atuação deixa de ficar escondida atrás de uma conta humana compartilhada, de uma chave de API genérica ou das permissões amplas da aplicação que o hospeda. A Microsoft vem adotando lógica semelhante em sua arquitetura de agentes corporativos: identidades específicas permitem aplicar controles de acesso, governança e ciclo de vida aos agentes, em vez de tratá-los apenas como extensões invisíveis de usuários ou aplicações. A consequência é importante para equipes de IAM: agentes passam a integrar o inventário de identidades não humanas que precisa ser descoberto, governado e monitorado.
Autenticar o agente não resolve o problema de autorização
Uma identidade única permite reconhecer o agente, mas segurança depende do que acontece depois da autenticação. Um agente autorizado a consultar um calendário não precisa necessariamente enviar mensagens; um agente que analisa contratos pode precisar ler documentos, mas não apagá-los; um agente de operações pode consultar telemetria sem receber autoridade permanente para modificar produção. Essa separação torna os princípios tradicionais de IAM ainda mais importantes. Menor privilégio, segregação de funções, escopo de recursos, credenciais de curta duração e autorização contextual precisam acompanhar a decisão do agente. Em ambientes mais sensíveis, ações de alto impacto podem exigir aprovação humana adicional, mesmo quando o agente está corretamente autenticado.
O desenho também reduz um risco recorrente em automações: credenciais permanentes incorporadas em código, arquivos de configuração ou cofres acessíveis por múltiplos processos. Sempre que a plataforma permitir, identidades federadas, tokens de curta duração e credenciais vinculadas à carga de trabalho reduzem a janela de abuso e tornam a revogação mais efetiva.
Delegação precisa preservar a cadeia de responsabilidade
Um dos desafios mais difíceis aparece quando um usuário pede algo legítimo a um agente e esse agente chama outros agentes, APIs ou ferramentas. A ação final pode atravessar diversas camadas. Se todas utilizarem a mesma identidade técnica, o log mostrará que um serviço executou a operação, mas não explicará adequadamente quem iniciou a cadeia nem qual agente tomou cada decisão intermediária. Uma arquitetura mais robusta preserva contexto de delegação. O sistema precisa conseguir diferenciar o usuário que originou a solicitação, o agente que a interpretou, a ferramenta acionada e o recurso afetado. Isso cria condições para investigar incidentes, contestar ações indevidas, demonstrar conformidade e aplicar políticas diferentes conforme o risco. Essa rastreabilidade também evita uma confusão perigosa: delegação não deveria significar transferência irrestrita de privilégios. O fato de um executivo possuir acesso a determinada informação não implica que todo agente usado por ele deva receber automaticamente o mesmo alcance. A autorização do agente pode — e em muitos casos deve — ser mais restrita que a do usuário.
Prompt injection transforma identidade em contenção de danos
A identidade própria ganha ainda mais relevância quando agentes consomem conteúdo externo. Uma página, documento ou mensagem maliciosa pode tentar manipular as instruções do agente por meio de prompt injection indireta. Se o agente operar com privilégios excessivos, uma falha na interpretação de conteúdo pode se transformar em acesso a dados, envio de mensagens ou execução de ferramentas. Nesse cenário, controles de identidade não impedem sozinhos a manipulação do modelo, mas limitam o impacto. Um agente comprometido continua restrito ao conjunto de ações que sua identidade está autorizada a realizar. A diferença é semelhante à observada em segurança tradicional: impedir toda exploração é difícil; impedir que uma exploração conceda autoridade ilimitada é um objetivo arquitetural alcançável.
Agentes também precisam nascer, mudar e morrer
Governança de identidade inclui ciclo de vida. Agentes são criados para projetos, recebem novas ferramentas, mudam de finalidade e eventualmente deixam de ser necessários. Sem processos de inventário e desativação, a organização corre o risco de acumular identidades esquecidas, tokens válidos e permissões que já não possuem justificativa operacional. Por isso, o inventário de agentes deveria responder perguntas semelhantes às aplicadas a contas privilegiadas e identidades de máquina: quem é o proprietário? Qual finalidade de negócio justifica sua existência? Quais sistemas acessa? Quem aprovou os privilégios? Quando houve a última utilização? Existe data de expiração? Como suas credenciais são rotacionadas e como a identidade é revogada?
Quando um agente não possui identidade e limites próprios, ações automatizadas podem aparecer nos registros como se tivessem sido executadas pelo usuário ou por uma conta técnica genérica. Isso dificulta investigação, responsabilização, revisão de privilégios e demonstração de controles, além de ampliar o impacto potencial de credenciais comprometidas ou decisões incorretas do agente.
O que as empresas podem fazer agora
Organizações não precisam esperar que todos os padrões estejam consolidados para começar. O primeiro passo é descobrir onde agentes já operam e quais credenciais utilizam. Em seguida, a arquitetura pode separar identidades humanas das identidades dos agentes, reduzir permissões ao mínimo necessário, preferir credenciais temporárias, estabelecer proprietários e registrar chamadas a ferramentas e recursos críticos. Também é recomendável classificar ações pelo impacto. Consultar uma base pública e transferir dinheiro não deveriam compartilhar a mesma política de autorização. Quanto maior a consequência de uma ação, maior deve ser a exigência de contexto, confirmação, autenticação reforçada ou intervenção humana. O objetivo não é impedir autonomia, mas torná-la proporcional ao risco. Por fim, logs precisam registrar mais do que o resultado. Uma trilha útil deve permitir correlacionar identidade humana, agente, sessão, ferramenta, autorização, recurso e resultado da ação. Sem essa correlação, a empresa pode possuir grande volume de telemetria e ainda assim não conseguir responder à pergunta fundamental de um incidente: quem — ou o quê — fez isso e com qual autoridade?
A identidade será parte da arquitetura dos agentes
Agentes de IA estão aproximando duas disciplinas que durante muito tempo evoluíram separadamente: segurança de inteligência artificial e gestão de identidades e acessos. Quanto mais autonomia um agente recebe, menos sustentável se torna tratá-lo como um processo invisível executando sob credenciais de terceiros.
A tendência é que identidade própria, autorização granular, delegação verificável e auditoria passem a fazer parte da arquitetura básica de agentes corporativos. O ganho não está apenas em bloquear ataques. Está em permitir que a organização use agentes com mais autonomia sem abrir mão de controle, responsabilização e capacidade de revogar essa autonomia quando necessário.
Be the first to comment