O que mudou e o que não mudou na Autenticação e Identidade para apps agenticos
À medida que os agentes de IA se tornam mais capazes e conectados, construir produtos agenticos seguros e escaláveis requer uma base sólida em autenticação e identidade. Este guia descreve o que mudou, o que não mudou e o que todo construtor precisa saber para navegar no novo cenário.
GuamianProduct & Design
Pare de perder semanas com autenticação de utilizadores
Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.
Recentemente, revi este artigo e foi mencionada a autenticação do agente:
Estamos a ver sinais do que isto pode parecer. A última especificação do MCP, por exemplo, inclui uma estrutura de autorização baseada no OAuth 2.1, sinalizando a possibilidade de avançar para dar aos agentes de IA tokens com escopo e revogáveis, em vez de segredos brutos. Podemos imaginar um cenário em que um agente de IA não obtém suas chaves reais da AWS, mas sim uma credencial de curta duração ou um token de capacidade que lhe permite executar uma ação estreitamente definida.
Muitos amigos e pessoas que não estão no campo da segurança ou CIAM têm a impressão de que isso é algo novo, mas definitivamente não é. OAuth é um protocolo de autorização baseado em token que envolve tokens com permissões delimitadas (tokens de acesso). Estes são sensíveis ao tempo e escopo, o que assegura a segurança e o controle adequado de acesso a recursos e serviços. No mercado global de SaaS (pré-IA), a maioria das soluções de identidade profissionais já são construídas sobre isto.
Quando você conecta sua conta do Google a um aplicativo de terceiros como o Notion ou o Zoom, ele usa o OAuth para solicitar apenas as permissões necessárias, como acesso ao seu calendário ou contatos, sem nunca expor sua senha do Google. Você pode revogar esse acesso a qualquer momento nas configurações da sua conta do Google. Esse padrão de acesso delegado é exatamente para o que o OAuth foi projetado e é a mesma base que está sendo expandida para aplicativos agenticos hoje.
Autenticação não é nova, ainda baseada no OAuth 2.1#
Existem dois grandes protocolos emergentes: MCP e A2A.
MCP foca na interação entre LLMs e as ferramentas e contexto de seu aplicativo.
A2A foca em habilitar a troca de tarefas entre agentes.
Mas quando se trata de autenticação e autorização, ambos ainda confiam em padrões de indústria bem estabelecidos como o OAuth.
Os servidores de autorização MCP DEVEM implementar OAuth 2.1 com medidas de segurança apropriadas para ambos, clientes confidenciais e públicos.
O Cliente A2A é responsável por obter os materiais de credencial necessários (por exemplo, tokens OAuth 2.0, chaves API, JWTs) através de processos externos ao próprio protocolo A2A. Isso pode envolver fluxos OAuth (código de autorização, credenciais do cliente), distribuição segura de chaves, etc.
Como o Google coloca:
Em vez de inventar novos padrões proprietários para segurança e operações, A2A visa integrar-se perfeitamente com a infraestrutura empresarial existente e práticas recomendadas amplamente adotadas.
Muita expectativa e conteúdo FOMO impulsionam a ideia de que, à medida que os agentes se tornam mais comuns, precisamos de um sistema para gerir identidades de agentes.
A resposta é: sim e não.
Sim, porque estamos introduzindo uma nova camada entre humanos e máquinas. Há necessidades reais de:
Gerir e identificar agentes
Atribuir IDs únicos
Rastrear registros
Auditar ações (para saber se uma tarefa foi realizada por um humano ou um agente)
No entanto, na maioria dos casos técnicos, não há necessidade de criar um conceito formal de “Identidade do Agente”.
Agente ≠ Usuário, ≠ Conta de Serviço.
Por trás de cada agente, há ainda um usuário e a identidade do usuário geralmente é suficiente.
Hoje em dia, a maioria dos agentes:
Age com base na autorização do usuário (por exemplo, tokens OAuth)
Executa lógica ou faz uma chamada de API
Executa tarefas únicas e de curta duração (sem necessidade de rastreamento)
Nesse sentido, o agente é apenas uma função-como-uma-ferramenta e não precisa de um ID globalmente único.
Por exemplo:
Um agente GPT chamando sua API de Calendário só precisa do acesso que você concedeu.
Um agente LangChain não precisa de uma identidade, desde que possa chamar as ferramentas certas, ele funciona.
M2M significa troca automatizada de dados entre serviços, sem humano no circuito.
Nesse contexto, a autenticação geralmente usa um aplicativo cliente ou conta de serviço.
Se você realmente quiser que seu agente tenha uma identidade (para auditoria, etc.), pode usar o ID do aplicativo e isso é suficiente.
Você ainda precisa definir a arquitetura do seu produto#
Isso não mudou. Quer seu produto envolva agentes ou não, a arquitetura do seu sistema de identidade depende de quem são seus usuários e como seu sistema interage com eles.
Se você está construindo um produto agentico voltado para o consumidor:
Você precisará de métodos leves de login (email, telefone, login social) e um pool de usuários unificado para gerir indivíduos que interagem com seu aplicativo e seus agentes. Os agentes agem em nome desses usuários usando tokens delegados (por exemplo, via OAuth).
Exemplo:
Imagine que você está construindo um assistente de agendamento de IA ou um bot de calendário impulsionado por IA.
Cada usuário faz login com sua conta pessoal do Google. Seu sistema usa OAuth para obter permissão para acessar seu calendário. O agente não possui sua própria identidade, ele usa o token do usuário para agendar reuniões, verificar disponibilidade ou enviar lembretes. A arquitetura de identidade é simples: um pool de usuários global, armazenamento de tokens e acompanhamento de consentimento por usuário.
Se você está construindo uma plataforma agentica B2B:
Você precisará suportar a identidade a nível organizacional, não apenas de usuários individuais. Isso inclui:
SSO para clientes empresariais
Separação a nível de workspace ou tenant
Políticas de delegação de agentes a nível organizacional (por exemplo, controlar o que os agentes podem fazer em várias equipes)
Visibilidade a nível de administrador e registros de todas as atividades dos agentes em nome dos funcionários
Exemplo:
Imagine que você está construindo uma plataforma que fornece agentes de IA para automatizar fluxos de trabalho internos - como um bot analista de segurança que monitora logs e envia alertas, ou um assistente de vendas que redige emails a partir de dados do CRM.
Cada empresa que utiliza sua plataforma deseja:
Fazer login com seu SSO existente
Controlar o que os agentes podem acessar (por exemplo, ferramentas internas, sistemas de documentos)
Ver qual agente realizou qual tarefa, sob a autorização de qual funcionário
Nesse caso, sua arquitetura de identidade precisa suportar um design multi-tenant, permissões de agentes com escopo e políticas específicas por organização. Os agentes ainda agem em nome dos usuários, mas as permissões e fronteiras de identidade são impostas por tenant de negócios.
Em ambos os casos, o modelo de identidade define como os agentes operam, o que podem acessar e como seu sistema garante responsabilidade.
Use este guia para ajudá-lo a planejar sua identidade e arquitetura de produto.
Previne acesso não autorizado mesmo se as credenciais forem comprometidas.
Exemplo: Se um agente ajudar você a executar uma ação de alto risco, como fazer uma transação ou alterar configurações de identidade, ele deve manter um humano no circuito e usar MFA para confirmar a ação antes de prosseguir.
Assegura que usuários e agentes apenas acessem o que têm permissão.
Exemplo: Um assistente de IA em um espaço de trabalho da empresa pode ler eventos de calendário, mas não pode acessar dados de cobrança, a menos que explicitamente atribuído um papel superior.
Exemplo: Permitir que os usuários façam login utilizando um link mágico enviado para o email deles ou um prompt biométrico como Face ID.
Esses recursos se aplicam tanto a aplicativos tradicionais quanto baseados em agentes, especialmente à medida que os agentes começam a operar em dados e sistemas sensíveis.
À medida que emergem agentes e fluxos de trabalho multi-agentes, estamos a ver novos casos de uso em que usuários, agentes, APIs e servidores MCP interagem. O número e variedade desses cenários estão a crescer rapidamente, muito mais do que no passado.
Sempre que essas conexões acontecem, a autorização se torna mais visível do que nunca. Os usuários devem dar consentimento claro, e as permissões precisam ser cuidadosamente geridas em vários sistemas. Por isso, todos agora falam sobre manter um “humano no circuito” garantindo que os usuários tenham controle e visibilidade adequados sobre o que os agentes podem fazer, e para quais escopos estão autorizados.
Seu aplicativo de IA pode precisar se integrar com muitos serviços externos#
O ecossistema MCP está a expandir-se, e isso significa que seu aplicativo não é mais apenas um serviço independente: é parte de uma rede maior e conectada.
Para fornecer contexto rico e útil para LLMs, seus agentes podem precisar de:
Acessar múltiplos servidores MCP
Exemplo: Imagine um gestor de projeto de IA que busca atualizações de tarefas do Jira, disponibilidade da equipe do Google Calendar e dados de vendas do Salesforce e cada um destes poderia ser alimentado por um servidor MCP diferente. Para gerar um resumo semanal, o agente deve interagir com múltiplas fontes de dados de forma segura. É aí que entram a autenticação e autorização, para proteger cada conexão e controlar como os dados são compartilhados.
Conectar-se com APIs e ferramentas externas
Exemplo: Um agente de suporte ao cliente pode precisar recuperar o histórico de pedidos do Shopify, atualizar tíquetes no Zendesk e acionar fluxos de trabalho no Slack. Sem integrações, o agente torna-se isolado e ineficaz.
À medida que os agentes assumem mais responsabilidades, a integração se torna a chave para a utilidade. Seu produto de IA não é apenas sobre o que ele pode fazer por si só, mas sobre o que ele pode acessar, orquestrar e raciocinar em um ecossistema conectado. Por isso, construir para a interoperabilidade, de forma segura e flexível, é mais importante do que nunca.
Você precisa abraçar padrões abertos: OAuth/OIDC são mais importantes do que nunca#
Na era da IA, a necessidade de integrações seguras e flexíveis está a crescer. Isso torna o OAuth 2.0 e o OIDC mais importantes do que nunca.
Os principais casos de uso incluem:
Servidores MCP remotos: Permita que agentes de terceiros acessem seu produto de forma segura usando tokens delegados.
Integrações de terceiros: Permita que outras ferramentas ou agentes se conectem ao seu aplicativo (por exemplo, uma plataforma de gestão de projetos) sem precisar de credenciais brutas.
Desenvolvimento de agentes: Construa agentes de IA que atuem de forma segura em nome dos usuários em múltiplos serviços.
Dispositivos inteligentes: Use OAuth/OIDC para coisas como tomadores de notas impulsionados por IA para autenticar usuários e conectar-se à nuvem — especialmente com UI mínima.
Esses protocolos fornecem acesso seguro, baseado em tokens e consentido pelo usuário.
Desenhando para confiança e escala na era dos softwares agenticos#
À medida que os produtos agenticos evoluem, os princípios centrais de identidade e autorização permanecem os mesmos, mas o contexto está mudando. Os agentes introduzem novas superfícies para delegação, consentimento e acesso. É por isso que aderir a padrões abertos como o OAuth, construir uma arquitetura clara e impor práticas sólidas de segurança não são apenas melhores práticas, mas são fundamentais. Desenhar com cuidado agora significa que seu sistema irá escalar com confiança, flexibilidade e confiança em um futuro impulsionado por IA.
