Este é o sexto artigo de uma série de sete partes sobre segurança de identidade como segurança de IA.
Resumindo:
Os agentes de IA recuperam dados usando as permissões de quem autenticam como (verificado), mas mostram seus resultados em espaços de trabalho compartilhados onde os destinatários têm permissões mistas (não verificado). Por exemplo, o agente de um CFO em um canal do Slack pode expor a remuneração de executivos para analistas juniores. Quatro vulnerabilidades críticas (CVSS 9.3-9.4) atingiram Anthropic, Microsoft, ServiceNow e Salesforce em 2025. Mesmo padrão: recuperação autorizada, destinatários não autorizados. A correção requer autorização refinada que calcula a interseção das permissões de todos os destinatários antes que os dados saiam da camada de recuperação, uma etapa que acontece depois que o trabalho do OAuth é concluído.
O Problema
O OAuth foi projetado para um mundo mais simples: um usuário, um aplicativo, um conjunto de permissões. Os agentes de IA rompem esse modelo. Eles operam em contextos compartilhados onde várias pessoas visualizam seus resultados. O protocolo nunca antecipou isso. Nem as plataformas criadas posteriormente.
O resultado: seu agente de IA herda o acesso de um executivo, mas transmite para todos na sala. De acordo com a McKinsey, 80% das organizações já encontraram comportamentos de risco de agentes de IA, incluindo exposição inadequada de dados e acesso a sistemas sem autorização. Eles estão certos em se preocupar.
Como isso se desenrola na prática? O whitepaper da OpenID Foundation sobre IA agêntica descreve este cenário:
Um CFO implementa um agente de IA em um canal do Slack. O agente se autentica com as credenciais do CFO e herda o acesso a dados de remuneração, materiais do conselho e sistemas de RH. Um analista júnior pergunta: "Qual é o nosso orçamento de remuneração do 3º trimestre?" O agente recupera planilhas de orçamento, planos de remuneração e tabelas de salários de executivos. Verificação de autorização: o CFO pode acessar esses arquivos? Sim. O agente responde ao canal. O analista júnior agora sabe o salário do CEO. Assim como todos os outros nesse canal.
O agente funcionou exatamente como projetado. O modelo de autorização falhou.
O Padrão: Quatro Plataformas, um Elo Comum
Entre junho e outubro de 2025, quatro vulnerabilidades de gravidade crítica revelaram um padrão. Essas vulnerabilidades não são idênticas, mas compartilham um elo comum: autorização verificada na recuperação, não na saída.
Anthropic Slack MCP Server, julho de 2025
Johann Rehberger descobriu a primeira vulnerabilidade crítica do MCP. Quando os agentes publicam no Slack, a plataforma "expande" os hiperlinks para gerar visualizações. Um invasor injeta um prompt, fazendo com que o agente, operando com permissões OAuth de administrador, leia arquivos confidenciais e incorpore esses dados em um URL. Os bots de visualização do Slack recuperam o URL, concluindo a exfiltração sem cliques. A Anthropic arquivou o servidor em vez de corrigi-lo. Recuperação: permissões de administrador (verificado). Destino de saída: servidor do invasor (não verificado).
Microsoft 365 Copilot (EchoLeak), junho de 2025
A Aim Security divulgou o primeiro ataque de zero clique contra um agente de IA de produção. Um invasor envia um e-mail com instruções ocultas; o destinatário nunca o abre. O mecanismo RAG do Copilot ingere o payload junto com arquivos do SharePoint e do OneDrive e, em seguida, codifica dados sensíveis em um URL de saída, ignorando a Política de Segurança de Conteúdo. Os pesquisadores chamaram isso de "Violação de Escopo do LLM": o agente simplificou a entrada não confiável com dados confiáveis sem isolar os limites de confiança. A Microsoft implantou uma correção, mas o padrão persiste. Recuperação: permissões do M365 da vítima (verificado). Destino da saída: URL do invasor (não verificado).
ServiceNow AI Platform (BodySnatcher), outubro de 2025
Aaron Costello da AppOmni descobriu que o Virtual Agent e o Now Assist confiavam em um segredo codificado e em um endereço de e-mail para vincular contas. Um invasor que conhece apenas o e-mail de um alvo pode se passar por qualquer usuário, incluindo administradores, ignorando completamente o MFA. Uma vez personificados, os invasores invocam agentes de IA com privilégios completos da vítima para acessar registros do ITSM ou acionar fluxos de trabalho privilegiados. Costello chamou isso de "a vulnerabilidade orientada por IA mais grave descoberta até o momento". Recuperação: permissões do usuário imitado (verificado). Identidade do solicitante: invasor (não verificado).
Salesforce Agentforce (ForcedLeak), setembro de 2025
A Noma Security identificou injeção de prompts por meio de formulários web-to-lead, possibilitando a exfiltração de dados do CRM. Um invasor envia um formulário com instruções ocultas; quando um funcionário consulta a IA sobre esse lead posteriormente, o agente executa ambas as solicitações. Pior: o domínio my-salesforce-cms.com permaneceu na lista de permissões, mesmo após expirar. Os invasores compraram por US$ 5 e estabeleceram um canal de exfiltração confiável. Recuperação: permissões de CRM do funcionário (verificado). Destino da saída: domínio do invasor (não verificado).
O ponto em comum: cada sistema verificava se o usuário invocador podia acessar os dados. Nenhum verificou se todos os destinatários da saída podiam.
O Que o OAuth Nunca Foi Solicitado a Fazer
Por duas décadas, o OAuth funcionou porque os aplicativos retornavam dados para o mesmo usuário que autorizava o acesso. Agentes de IA quebram essa premissa. Os agentes se autenticam de maneiras diferentes: com credenciais de usuário delegadas, com suas próprias identidades de serviço ou como automações criadas pelo usuário e compartilhadas com outras pessoas. O padrão varia, mas o problema é o mesmo: eles respondem em contextos compartilhados onde várias pessoas veem sua saída.
O resultado: a autorização acontece na recuperação, mas nenhuma verificação ocorre na saída. Contextos de múltiplos públicos exigem a extensão do OAuth com autorização sensível ao público. Nas especificações do OAuth, "público" se refere à API de destino. Aqui, queremos dizer algo diferente: as pessoas que veem o que o agente produz.
O OAuth fornece a base. Estendê-lo para autorização ciente do público é o que ajuda a tornar os agentes de IA seguros.
A Arquitetura que Resolve o Problema
Corrigir isso exige autorização ciente do público: a camada de autorização deve conhecer o público antes da recuperação e calcular a interseção de permissões em tempo real. O agente responde apenas com os dados que todos os membros do público estão autorizados a ver.
A arquitetura requer que três componentes trabalhem juntos:
Mecanismo de autorização granular. Modela permissões como relacionamentos, não funções estáticas. Calcula a interseção do que todos os membros do público podem acessar em milissegundos.
Camada de gerenciamento de credenciais. Armazena tokens OAuth de aplicativos conectados. Emite credenciais com escopo para agentes com base na interseção de permissões calculada.
Identity Governance. Mantém o gráfico de permissões preciso por meio de remediação e revisão contínuas. Sem permissões precisas, o cálculo da interseção produz respostas incorretas.
Fluxo de Interseção de Permissões
O principal insight: os dados salariais do CEO nunca são recuperados inicialmente. O token emitido para o agente não pode acessá-lo. Isso não é filtragem após a recuperação. Isso é definição do escopo antes da recuperação.
Por que não usar apenas o DLP? A Prevenção de Perda de Dados (Data Loss Prevention) detecta dados sensíveis após eles aparecerem na resposta. A autorização de granularidade fina impede a recuperação desde o início. DLP é o cinto de segurança. A recuperação com escopo não significa colidir com a parede.
Como a Okta e o Auth0 Possibilitam Isso
Autorização de granularidade fina (FGA)
O RBAC tradicional atribui funções estáticas. FGA modela as permissões como relacionamentos: "O VP de Vendas pode visualizar os dados do orçamento porque é membro do canal de finanças." Este gráfico de relacionamento possibilita a computação de interseção. Quando o agente precisa saber a quais dados todos os membros do canal podem acessar, a API batchCheck da FGA responde em milissegundos em bilhões de relacionamentos.
O Token Vault armazena tokens de atualização OAuth de qualquer aplicativo de SaaS e gerencia automaticamente o ciclo de vida do token. A camada de orquestração recupera tokens do cofre e emite credenciais com escopo para agentes com base na interseção de permissões calculada.
Quando os agentes abrangem vários aplicativos, a autorização deve abranger todos eles. O Cross-App Access estende o OAuth, movendo o consentimento e a aplicação de políticas para o provedor de identidade, dando ao TI empresarial controle centralizado sobre as conexões de agente para aplicativo.
Governança de identidade da Okta
A autorização em tempo real é tão precisa quanto os dados de permissão subjacentes. O Identity Governance ajuda a garantir que as permissões sejam revisadas e corrigidas continuamente. Quando as permissões se desviam ou contas órfãs se acumulam, a computação de interseção produz respostas erradas. A governança mantém o gráfico de permissões preciso.
A Exposição Regulatória
Artigo 32 e Artigo 5(1)(f) do GDPR. Artigo 32 exige "medidas técnicas e organizacionais apropriadas", incluindo proteção contra "divulgação não autorizada ou acesso a dados pessoais". Artigo 5(1)(f) exige o processamento "de forma a garantir a segurança adequada." Quando um agente de IA revela PII de funcionários a usuários internos não autorizados, ambos os artigos se aplicam. As multas podem chegar a €20 milhões ou 4% da receita anual global.
Seção 1798.150 da CCPA. O direito de ação privado da Califórnia permite que os consumidores processem quando informações pessoais "estão sujeitas a acesso e exfiltração, roubo ou divulgação não autorizados como resultado da violação do dever da empresa de implementar e manter procedimentos de segurança razoáveis". A superexposição interna por meio de agentes de IA pode atender a este padrão. Danos estatutários: US$ 100 a US$ 750 por consumidor por incidente.
Seção 404 da Sarbanes-Oxley. A Seção 404 exige que as empresas públicas "estabeleçam e mantenham uma estrutura de controle interno adequada". Quando agentes de IA com permissões executivas podem revelar informações não públicas relevantes para funcionários não autorizados, sua capacidade de demonstrar controles adequados é seriamente prejudicada. Os auditores podem sinalizar isso como uma fraqueza material.
Como a pesquisa da McKinsey confirma, 80% das organizações já encontraram comportamentos de risco de agentes de IA, incluindo exposição inadequada de dados. A FGA calcula as interseções de permissões antes da recuperação para ajudar a lidar diretamente com essas obrigações de conformidade.
A Pergunta para sua Próxima Avaliação de Segurança
Pergunte à sua equipe de segurança: "Para cada agente de IA implantado em um espaço de trabalho compartilhado, podemos demonstrar que o resultado do agente é restrito aos dados que todos os membros desse espaço de trabalho estão autorizados a ver?"
Se a resposta for não, você pode ter uma violação regulatória prestes a ser sinalizada.
A tecnologia para resolver isso já existe. Saiba como a Okta e a Auth0 protegem agentes de IA em okta.com/ai e auth0.com/ai. Baixe o whitepaper sobre Proteção de Agentes de IA ou entre em contato com seu representante da Okta para avaliar as lacunas de interseção de permissões em suas implantações de IA.
Próximo: O Blog 7 reúne todos os seis desafios de identidade em uma estrutura unificada.
