Segurança de IA agêntica em 2026: os controles de IAM que funcionam

A gestão de identidade e acesso foi projetada em torno de uma coreografia específica: uma pessoa se senta diante de um navegador, comprova sua identidade via MFA ou SSO, e uma sessão recebe um escopo vinculado a essa comprovação. Um agente LLM quebra cada parte dessa coreografia ao mesmo tempo — não há uma pessoa no teclado para cada ação, a "sessão" pode rodar sem supervisão por horas ou dias, e a credencial que ele carrega muitas vezes foi definida uma única vez na configuração e nunca mais revisada.

Isso não é uma versão menor do mesmo problema. Um chatbot que responde perguntas não tem acesso permanente para alterar nada. Um agente que lê um ticket, grava um registro em banco de dados, chama três APIs internas e publica uma mudança de configuração está tomando uma decisão de autorização em cada uma dessas etapas — e ferramentas de IAM construídas para sessões humanas não têm nenhum conceito nativo de "essa decisão foi tomada por um modelo agindo sobre uma instrução de cinco minutos atrás, não por uma pessoa".

A consequência prática: o ritmo de revisão de acessos, a elevação de MFA em ações sensíveis e a trilha de auditoria de "quem fez isso", que os programas de IAM levaram uma década para construir para pessoas, na maior parte ainda não existem para os agentes que uma equipe de plataforma está implantando neste trimestre.

Cinco modos de falha explicam a maior parte da exposição real quando um agente ganha acesso de escrita. Eles se combinam — uma credencial com privilégios excessivos somada a uma trilha de auditoria ausente transforma um incidente contido em um incidente impossível de rastrear.

SSO e MFA são construídos para comprovar que uma pessoa está presente no momento do acesso — um agente autônomo nunca está presente nesse sentido, então todo o modelo de verificação não se aplica a ele. Um agente é uma identidade não humana (NHI): uma conta de serviço, uma identidade de carga de trabalho ou uma credencial de API que age de forma contínua em vez de se autenticar uma vez por sessão.

Identidades não humanas já superam amplamente o número de identidades humanas na maioria dos ambientes corporativos — um padrão amplamente relatado por fornecedores de segurança e pesquisas do setor, não um número específico que este artigo esteja citando, e a proporção varia por organização. O que se mantém consistente nesses relatos é a direção: o número de NHIs cresce mais rápido que o quadro de funcionários humanos há anos, impulsionado principalmente por contas de serviço e automação, e a IA agêntica é hoje a categoria de crescimento mais rápido dentro dessa tendência.

A maioria dos programas de IAM corporativos ainda encaminha o provisionamento de NHIs por um processo mais leve e menos revisado do que o onboarding de pessoas — um novo funcionário recebe uma revisão de acesso, aprovação de um gestor e recertificação programada; uma nova conta de serviço ou credencial de agente frequentemente não recebe nenhuma das três. Essa lacuna era tolerável quando as NHIs eram majoritariamente scripts estáticos de escopo restrito. Deixa de ser tolerável quando a NHI é um agente capaz de encadear chamadas de ferramentas, interpretar instruções ambíguas e executar ações que quem o provisionou não enumerou explicitamente com antecedência.

Avalie uma implantação de agente específica em cinco dimensões para obter um nível de raio de impacto e uma recomendação de privilégio mínimo correspondente. Isso roda inteiramente no seu navegador — nada é enviado a lugar nenhum.

Seis controles explicam a maior parte da redução real do raio de impacto de um agente. Nenhum é suficiente sozinho — eles se combinam da mesma forma que os modos de falha do modelo de ameaças.

Rodar o modelo de um agente em infraestrutura hospedada internamente elimina o risco de exfiltração para terceiros e mantém prompts e saídas dentro da rede da organização — isso não resolve o problema de identidade e acesso que é o tema deste artigo. Um leitor com conhecimento de segurança descontaria o restante deste guia se essa distinção ficasse borrada, então vale dizer isso com clareza.

Implantação local não corrige injeção de prompt. Injeção é um problema de camada de aplicação e arquitetura — como o agente distingue instruções confiáveis de conteúdo recuperado não confiável — e é idêntico esteja o modelo subjacente rodando em uma API de fornecedor ou em hardware próprio da organização. Trazer o modelo para dentro de casa não muda nada em como o agente processa uma página web ou um documento que foi solicitado a ler.

Implantação local não corrige credenciais com privilégios excessivos. Um modelo hospedado internamente chamando uma conta de serviço com privilégios excessivos é exatamente tão perigoso quanto um modelo hospedado por fornecedor chamando a mesma conta — o escopo da credencial é uma propriedade do desenho de acesso do agente, não de onde os pesos do modelo rodam.

Implantação local não corrige uma trilha de auditoria ausente. Se a inferência acontece em uma API alugada ou em uma GPU própria não tem relação com se uma ação é registrada com atribuição à pessoa que a autorizou. Essa é uma decisão de log e arquitetura de identidade, tomada separadamente.

Para o que a implantação local é genuinamente boa neste contexto: manter o conteúdo de prompts e saídas de ferramentas fora da infraestrutura de terceiros, o que importa para residência de dados e risco de terceiros. É um insumo para uma postura de segurança do agente, não um substituto dos controles de identidade e acesso acima.

Para uma empresa que opera na UE em serviços financeiros ou infraestrutura crítica, três marcos regulatórios podem se sobrepor em uma implantação de agentes. A NIS2 exige notificação de incidentes, segurança da cadeia de suprimentos e, para entidades dentro do seu escopo, responsabilidade pessoal da diretoria. A DORA se aplica especificamente a entidades financeiras e exige um registro de riscos de terceiros de TIC; um agente autônomo que chama APIs externas pode ser considerada uma dependência de TIC registrável sob a DORA, algo que a maioria das empresas ainda não considerou. O AI Act adiciona sua própria camada por cima, dependendo do nível de risco do agente.

Efeito prático: três marcos regulatórios sobrepostos que podem se aplicar simultaneamente criam, para implantações de agentes em setores regulados da UE, pressão real em direção a arquiteturas de hospedagem soberana ou local — não como obrigação legal em si, mas porque uma arquitetura local simplifica demonstrar conformidade sob os três marcos.

Se a NIS2 e a DORA se aplicam a uma empresa específica depende do setor e da classificação da entidade — esta seção é orientação geral, não aconselhamento jurídico. Confirme a aplicabilidade com assessoria especializada em NIS2/DORA/AI Act antes de finalizar uma arquitetura de acesso.