O que mudou e o que não mudou em Autenticação e Identidade para aplicativos agênticos

Recentemente, revisei este artigo, e a autenticação de agentes foi mencionada:

Estamos vendo dicas de como isso poderia ser. A especificação mais recente do MCP, por exemplo, inclui uma estrutura de autorização baseada no OAuth 2.1, sinalizando uma possibilidade de avançar para fornecer aos agentes de IA tokens com escopo e revogáveis, em vez de segredos brutos. Podemos imaginar um cenário onde um agente de IA não obtém suas chaves reais da AWS, mas adquire uma credencial de curta duração ou um token de capacidade que lhe permite executar uma ação bem definida.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

Muitos amigos e pessoas fora do campo de segurança ou CIAM têm a impressão de que isso é algo novo, mas definitivamente não é. OAuth é um protocolo padrão de autorização baseado em tokens que envolve tokens com permissões escopadas (tokens de acesso). Estes são sensíveis ao tempo e possuem escopo limitado, o que garante segurança e controle de acesso adequado a recursos e serviços. No mercado global de SaaS (pré-IA), a maioria das soluções de identidade profissional já é construída com base nisso.

Quando você conecta sua conta do Google a um aplicativo de terceiros como Notion ou Zoom, ele usa 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 de sua conta do Google. Este padrão de acesso delegado é exatamente o que o OAuth foi projetado para e é a mesma base que está sendo estendida para aplicativos agênticos hoje.

O que não muda no mundo agêntico#

Autenticação não é nova, ainda baseada no OAuth 2.1#

Existem dois principais protocolos emergindo: MCP e A2A.

• MCP foca na interação entre LLMs e as ferramentas e contexto de seu aplicativo.
• A2A foca em permitir a troca de tarefas entre agentes.

Mas quando se trata de autenticação e autorização, ambos ainda dependem de padrões bem estabelecidos da indústria como o OAuth.

Servidores de autorização MCP DEVEM implementar OAuth 2.1 com medidas de segurança apropriadas para 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 de API, JWTs) através de processos externos ao próprio protocolo A2A. Isso pode envolver fluxos de OAuth (código de autorização, credenciais do cliente), distribuição segura de chaves, etc.

Como o Google diz:

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 melhores práticas amplamente adotadas.

Um agente precisa de uma identidade única?#

Muito hype e conteúdo de FOMO impulsionam a ideia de que, à medida que os agentes se tornam mais comuns, precisamos de um sistema para gerenciar identidades de agentes.

A resposta é: sim e não.

Sim, porque estamos introduzindo uma nova camada entre humanos e máquinas. Existem necessidades reais de:

• Gerenciar e identificar agentes
• Atribuir IDs únicos
• Acompanhar 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 de 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, a maioria dos agentes:

• Atua com base na autorização do usuário (por exemplo, tokens OAuth)
• Executa lógica ou faz uma chamada de API
• Realiza tarefas de curta duração, uma única vez (sem necessidade de rastreamento)

Nesse sentido, o agente é apenas uma função como 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.

Mesmo antes da IA, tínhamos o conceito de autenticação máquina-a-máquina (M2M).

M2M significa troca automatizada de dados entre serviços, sem um humano no meio.

Nesse contexto, a autenticação geralmente usa um aplicativo cliente ou conta de serviço.

Se você realmente quer que seu agente tenha uma identidade (para auditoria, etc.), você 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 ou não agentes, 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 agêntico voltado para o consumidor: Você precisará de métodos de login leves (email, telefone, login social) e um pool de usuários unificado para gerenciar 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 orientado por IA.

Cada usuário faz login com sua conta pessoal do Google. Seu sistema usa OAuth para obter permissão para acessar o calendário deles. O agente não tem 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 rastreamento de consentimento por usuário.

Se você está construindo uma plataforma agêntica B2B:

Você precisará suportar identidade ao nível da organização, não apenas usuários individuais. Isso inclui:

1. SSO para clientes empresariais
2. Separação de espaço de trabalho ou nível de locatário
3. Políticas de delegação de agentes ao nível da organização (por exemplo, controlar o que os agentes podem fazer em equipes)
4. Visibilidade ao nível de administrador e registros de todas as atividades do agente 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 registros e envia alertas, ou um assistente de vendas que redige e-mails a partir de dados de CRM.

Cada empresa que usa sua plataforma deseja:

1. Fazer login com seu SSO existente
2. Controlar a que os agentes podem acessar (por exemplo, ferramentas internas, sistemas de documentos)
3. Ver qual agente realizou qual tarefa, sob a autorização de qual funcionário

Nesse caso, sua arquitetura de identidade precisa suportar design multi-locatário, permissões de agente com escopo e políticas específicas da organização. Os agentes ainda agem em nome dos usuários, mas as permissões e limites de identidade são aplicados por locatário 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 a responsabilidade.

Use este guia para ajudar a planejar sua arquitetura de identidade e produto.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

Você ainda precisa de camadas de segurança para manter seus aplicativos baseados em agentes seguros#

Quer seja um aplicativo de agente ou não, essas camadas básicas de segurança são necessárias para proteger seus usuários e sistemas:

• Autenticação multi-fator (MFA)

  Previna acesso não autorizado mesmo que as credenciais sejam 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 loop e usar MFA para confirmar a ação antes de prosseguir.

• CAPTCHA

  Bloqueia abuso automatizado, como preenchimento de credenciais ou inscrições conduzidas por bots.

  Exemplo: Mostre CAPTCHA após 3 tentativas de login falhas para evitar ataques de força bruta.

• Controle de acesso baseado em papéis (RBAC)

  Garante que os usuários e agentes só acessem o que lhes é permitido.

  Exemplo: Um assistente de IA em um espaço de trabalho empresarial pode ler eventos de calendário, mas não pode acessar dados de faturamento a menos que explicitamente atribuído a um papel mais alto.

• Login sem senha

  Melhora a experiência do usuário e reduz o risco de senhas fracas.

  Exemplo: Permita que os usuários façam login usando um link mágico enviado para o e-mail deles ou um prompt biométrico como o Face ID.

Esses recursos se aplicam a aplicativos tradicionais e baseados em agentes, especialmente à medida que os agentes começam a operar em dados e sistemas sensíveis.

O que mudou no mundo agêntico#

Autenticação é mais importante do que nunca#

À medida que surgem agentes e fluxos de trabalho multi-agentes, estamos vendo novos casos de uso onde usuários, agentes, APIs e servidores MCP todos interagem. O número e a variedade desses cenários estão crescendo 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 gerenciadas entre os sistemas. É por isso que todos estão agora falando sobre manter um “humano no loop” assegurando que os usuários tenham controle e visibilidade suficientes sobre o que os agentes podem fazer e para que escopos estão autorizados.

Seu aplicativo de IA pode precisar se integrar a muitos serviços externos#

O ecossistema MCP está se expandindo, e isso significa que seu aplicativo não é mais apenas um serviço autônomo: é parte de uma rede maior e conectada.

Para fornecer um contexto rico e útil para LLMs, seus agentes podem precisar:

• Acessar múltiplos servidores MCP

  Exemplo: Imagine um gerente de projetos de IA que obtém atualizações de tarefas do Jira, disponibilidade de equipe do Google Calendar e dados de vendas do Salesforce, e cada um desses poderia ser alimentado por um servidor MCP diferente. Para gerar um resumo semanal, o agente deve interagir com segurança com várias fontes de dados. É aí que entram a autenticação e autorização, para proteger cada conexão e controlar a maneira como os dados são compartilhados.

• Conectar-se a APIs e ferramentas externas

  Exemplo: Um agente de suporte ao cliente pode precisar recuperar o histórico de pedidos do Shopify, atualizar tickets no Zendesk e acionar fluxos de trabalho no Slack. Sem integrações, o agente se torna 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 conta própria, mas sobre o que pode acessar, orquestrar e raciocinar em um ecossistema conectado. É por isso que construir para 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á crescendo. Isso torna OAuth 2.0 e OIDC mais importantes do que nunca.

Casos de uso principais incluem:

• Servidores MCP remotos: Permitir que agentes de terceiros acessem seu produto de forma segura usando tokens delegados.
• Integrações de terceiros: Permitir que outras ferramentas ou agentes se conectem ao seu aplicativo (por exemplo, uma plataforma de gerenciamento de projetos) sem precisar de credenciais brutas.
• Desenvolvimento de agentes: Construir agentes de IA que ajam de forma segura em nome de usuários em diversos serviços.
• Dispositivos inteligentes: Usar OAuth/OIDC para coisas como anotações de IA para autenticar usuários e conectar à nuvem — especialmente com interface mínima.

Esses protocolos oferecem acesso seguro, baseado em tokens, com consentimento do usuário.

Isso é crítico em um mundo de sistemas agênticos e conectados. Confira este artigo para ver por que OAuth e OIDC são importantes

Projetando para confiança e escala na era do software agêntico#

À medida que produtos agênticos evoluem, os princípios centrais de identidade e autorização permanecem os mesmos, mas o contexto está mudando. Agentes introduzem novas superfícies para delegação, consentimento e acesso. É por isso que aderir a padrões abertos como OAuth, construir uma arquitetura clara e aplicar práticas sólidas de segurança não são apenas melhores práticas, são fundamentais. Projetar com cuidado agora significa que seu sistema será escalável com confiança, flexibilidade e confiança em um futuro movido por IA.