Estamos a testemunhar uma incompatibilidade fundamental entre a forma como os sistemas de identidade foram concebidos e como os agentes de IA realmente operam. A Gestão de Identidade e Acesso tradicional (IAM) assumia uma verdade central: os humanos estão sempre envolvidos. Um utilizador faz login, é desafiado com MFA, pensa sobre o que está a fazer, e depois age.
Os agentes de IA demoliram essa suposição de um dia para o outro.
Quando um bot de atendimento ao cliente processa 10.000 pedidos por minuto às 3 da manhã, não pode pausar para que um humano aprove uma notificação push de MFA. Quando um fluxo de trabalho autónomo executa tarefas delegadas contra APIs, necessita de uma gestão de credenciais que aconteça sem que ninguém clique em nada. A infraestrutura atual—prompt de senha, desafios MFA, fluxos de verificação humana—torna-se um gargalo que trava tudo.
Isto não é um problema menor de UX. É uma crise arquitetural.
Onde os Sistemas Tradicionais Fracassam
As soluções existentes de autenticação máquina-a-máquina também não resolvem isto. Foram construídas para comunicação simples entre serviços, não para ciclos de vida complexos de agentes com requisitos dinâmicos de permissão e cadeias de delegação sofisticadas.
A questão central: O IAM tradicional concede permissões ao nível do utilizador. Quando autoriza um assistente de IA a gerir o seu email, os sistemas atuais ou dão-lhe acesso total a tudo o que pode fazer—ou falham completamente porque não suportam restrições granulares de escopo.
Considere o cenário bancário: Um humano consegue raciocinar sobre instruções. Instintivamente sabe que um pedido para “transferir 100.000$ para uma conta desconhecida” é provavelmente suspeito, mesmo que tecnicamente permitido. Um sistema de IA não possui esse julgamento. Precisa de limites explícitos: este agente pode pagar apenas fornecedores aprovados, máximo de 5.000$ por transação, data de expiração 31 de dezembro de 2025.
Por isso, precisamos de acesso de menor privilégio por padrão para agentes delegados—um conceito que o IAM tradicional nunca precisou implementar porque os humanos forneciam a camada de raciocínio.
Dois Modelos de Agentes Fundamentalmente Diferentes Exigem Abordagens de Identidade Diferentes
Agentes Semi-Autónomos: O Problema da Delegação
Quando um humano delega tarefas a um agente de IA (pense: assistente executivo a gerir calendário e relatórios de despesas), o sistema precisa implementar autenticação de dupla identidade:
Identidade primária: O humano que autorizou o agente Identidade secundária: A instância do agente com restrições explícitas
Em termos de OAuth 2.1/OIDC, isto significa uma troca de tokens que gera tokens de acesso restritos:
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Como os Agentes de IA Quebram os Sistemas Tradicionais de Controlo de Acesso
A Crise de IAM que Ninguém Previu
Estamos a testemunhar uma incompatibilidade fundamental entre a forma como os sistemas de identidade foram concebidos e como os agentes de IA realmente operam. A Gestão de Identidade e Acesso tradicional (IAM) assumia uma verdade central: os humanos estão sempre envolvidos. Um utilizador faz login, é desafiado com MFA, pensa sobre o que está a fazer, e depois age.
Os agentes de IA demoliram essa suposição de um dia para o outro.
Quando um bot de atendimento ao cliente processa 10.000 pedidos por minuto às 3 da manhã, não pode pausar para que um humano aprove uma notificação push de MFA. Quando um fluxo de trabalho autónomo executa tarefas delegadas contra APIs, necessita de uma gestão de credenciais que aconteça sem que ninguém clique em nada. A infraestrutura atual—prompt de senha, desafios MFA, fluxos de verificação humana—torna-se um gargalo que trava tudo.
Isto não é um problema menor de UX. É uma crise arquitetural.
Onde os Sistemas Tradicionais Fracassam
As soluções existentes de autenticação máquina-a-máquina também não resolvem isto. Foram construídas para comunicação simples entre serviços, não para ciclos de vida complexos de agentes com requisitos dinâmicos de permissão e cadeias de delegação sofisticadas.
A questão central: O IAM tradicional concede permissões ao nível do utilizador. Quando autoriza um assistente de IA a gerir o seu email, os sistemas atuais ou dão-lhe acesso total a tudo o que pode fazer—ou falham completamente porque não suportam restrições granulares de escopo.
Considere o cenário bancário: Um humano consegue raciocinar sobre instruções. Instintivamente sabe que um pedido para “transferir 100.000$ para uma conta desconhecida” é provavelmente suspeito, mesmo que tecnicamente permitido. Um sistema de IA não possui esse julgamento. Precisa de limites explícitos: este agente pode pagar apenas fornecedores aprovados, máximo de 5.000$ por transação, data de expiração 31 de dezembro de 2025.
Por isso, precisamos de acesso de menor privilégio por padrão para agentes delegados—um conceito que o IAM tradicional nunca precisou implementar porque os humanos forneciam a camada de raciocínio.
Dois Modelos de Agentes Fundamentalmente Diferentes Exigem Abordagens de Identidade Diferentes
Agentes Semi-Autónomos: O Problema da Delegação
Quando um humano delega tarefas a um agente de IA (pense: assistente executivo a gerir calendário e relatórios de despesas), o sistema precisa implementar autenticação de dupla identidade:
Identidade primária: O humano que autorizou o agente
Identidade secundária: A instância do agente com restrições explícitas
Em termos de OAuth 2.1/OIDC, isto significa uma troca de tokens que gera tokens de acesso restritos: