Como os Agentes de IA Revelam as Falhas Fundamentais na Arquitetura Tradicional de IAM

O Problema Central: Os Humanos Nem Sempre Estão Por Trás do Teclado

Os sistemas tradicionais de Gestão de Identidade e Acesso foram construídos com uma única suposição—alguém está realmente presente para autenticar. Um humano está numa tela de login, insere uma palavra-passe, recebe uma notificação MFA push, aprova-a. Este fluxo de trabalho definiu a segurança durante décadas.

Mas os agentes de IA destroem completamente essa suposição.

Quando um agente autónomo processa pedidos de API a alta velocidade durante horas não comerciais, não pode pausar para responder a desafios MFA. Quando um agente delegado lida com tarefas de calendário e email em nome de um utilizador, nunca deve herdar o conjunto completo de permissões desse utilizador. O sistema de autenticação não pode exigir interação humana para processos que funcionam 24/7 sem supervisão humana. Toda a arquitetura—telas de login, pedidos de palavra-passe, autenticação multifator verificada por humanos—torna-se uma dívida arquitetónica no momento em que os agentes assumem o controlo da execução do fluxo de trabalho.

A verdadeira questão: o IAM tradicional não consegue distinguir entre um pedido legítimo de um agente e um pedido comprometido que opera com credenciais válidas. Quando um principal não tem acesso a uma operação de API através dos canais normais de autorização, o sistema detecta. Mas quando as credenciais desse principal são sequestradas ou quando a intenção de um agente se torna maliciosa através de envenenamento de contexto, os sistemas tradicionais não têm salvaguardas. Esta lacuna entre validação técnica de identidade e a verdadeira fiabilidade define o desafio central da autenticação agentica.

Dois Modelos de Agentes Fundamentalmente Diferentes, Duas Exigências de Identidade Diferentes

Agentes Delegados por Humanos: O Problema do Escopo e do Privilégio Mínimo

Um agente delegado por humanos opera sob autoridade delegada—você autoriza um assistente de IA a gerir o seu calendário. Mas aqui está a parte perigosa: a maioria dos sistemas atuais concede ao agente o seu conjunto completo de permissões ou exige que defina manualmente restrições. Nenhuma das abordagens funciona.

O agente não precisa herdar toda a sua identidade. Precisa de permissões precisamente limitadas. Você entende intuitivamente que um serviço de pagamento de contas não deve transferir fundos para contas arbitrárias. Você preventivamente evita que a instrução financeira seja mal interpretada. Os sistemas de IA carecem desta capacidade de raciocínio contextual, razão pela qual o acesso de privilégio mínimo não é opcional—é obrigatório.

Como isto funciona tecnicamente:

O sistema implementa uma validação de identidade dupla. O agente opera sob duas identidades simultaneamente:

• A sua identidade (o humano delegante) com permissões completas
• A identidade restrita do agente com limites de escopo explícitos

Quando delega autorização, ocorre uma troca de token. Em vez de o agente receber as suas credenciais, recebe um token com escopo reduzido contendo:

• agent_id: O identificador único para esta instância específica do agente
• delegated_by: O seu ID de utilizador
• scope: Os limites de permissão (por exemplo, “bancário: pagar contas” mas explicitamente NÃO “bancário: transferir”)
• constraints: Restrições de política como listas de beneficiários aprovados, limites de valor de transação e carimbos de expiração

Assim é o fluxo: