Este é o quarto artigo de uma série de sete partes sobre a segurança da identidade como segurança com IA.
Resumindo: as cadeias de delegação estão se tornando alvos de alto impacto em sistemas autônomos. Cada transferência de agente multiplica o acesso e, como quase todas as identidades não humanas (97%) já possuem privilégios excessivos, o risco se agrava a cada salto. Em uma vulnerabilidade conhecida como contrabando de sessão de agente (novembro de 2025), um subagente incorpora uma negociação silenciosa de ações em uma resposta de rotina. O agente principal executa o comando em seguida, sem qualquer aviso ou visibilidade. Em outra vulnerabilidade conhecida como elevação de privilégios entre agentes (setembro de 2025), um agente reescreve a configuração de outro durante a execução de uma tarefa, o que pode desencadear um ciclo de controle de autorreforço. A delegação não é inerentemente arriscada, mas, sem permissões definidas e rastreabilidade criptográfica, pode se tornar um canal direto para movimentação lateral.
Contrabando de sessão de agente: quando a delegação se transforma em exploração
A delegação de agente para agente permite a escalabilidade desde a concepção: os agentes principais transferem tarefas complexas para subagentes especializados buscando execução direcionada.
Na teoria, cada etapa restringe as permissões e mantém o alinhamento com a intenção original. Na prática, porém, muitas vezes acontece o contrário.
Em uma prova de conceito (PoC) utilizada como parte do cenário de contrabando de sessão, um agente de assistência financeira solicitou informações de mercado a um agente de pesquisa. O subagente retornou um resumo limpo, além de um comando oculto para negociação de ações. Nenhum alerta foi disparado, e a transação foi executada de forma invisível.
Cada camada confiou na seguinte, sem que alguma delas verificasse o alinhamento. A Unit 42 descreveu como o caminho do exploit inteiro poderia funcionar:
- O assistente financeiro delega as notícias sobre o mercado ao assistente de pesquisa.
- O assistente de pesquisa é mal-intencionado e injeta instruções ocultas em sua resposta.
- O assistente financeiro realizou a negociação não autorizada de dez ações.
- O usuário viu apenas o resumo da notícia; a recomendação buy_stock estava invisível.
Conforme observado pela Unit 42:
"Um agente comprometido representa um adversário mais capaz. Movido por modelos de IA, um agente comprometido pode gerar estratégias adaptativas de forma autônoma, explorar o estado da sessão e ampliar sua influência sobre todos os agentes de clientes conectados.“
Em um exemplo que ilustra como o cenário de elevação de privilégios poderia se concretizar, um agente comprometido seria capaz de modificar o ambiente de execução de um agente irmão. Esse agente, agora desconfigurado, transfere tarefas de maneiras que podem expandir o alcance do invasor. Se a cadeia não for interrompida, ele poderá voltar e aprofundar uma intrusão.
Conforme o nível de integração dos agentes com as finanças, as operações e a infraestrutura se aprofunda, mais perigosa se torna a delegação descontrolada. Cada transferência de tarefa não verificada constitui uma violação em trânsito.
Três sistemas, o mesmo padrão de falha
Now Assist da ServiceNow (outubro de 2025)
A AppOmni revelou que agentes de baixo privilégio no Now Assist da ServiceNow poderiam ser usados para explorar a descoberta de agentes, visando recrutar pares com privilégios mais elevados e exfiltrar dados.
Elevação de privilégios entre agentes (setembro de 2025)
Johann Rehberger identificou a vulnerabilidade de elevação de privilégios entre agentes e explicou como um agente comprometido poderia reescrever suas configurações para reconfigurar outros. Em ambientes onde vários agentes (por exemplo, Copilot, Claude, Gemini) compartilham uma base de código, um Copilot injetado por prompt pode alterar o .mcp.json do Claude.
No próximo uso, o Claude executaria um código arbitrário e poderia reconfigurar o Copilot. Rehberger explica:
"Aquilo que começa como uma simples injeção de prompts indireta pode rapidamente se transformar em um comprometimento envolvendo vários agentes."
EchoLeak no Microsoft 365 Copilot (junho de 2025)
A Aim Security divulgou o "EchoLeak" (CVE-2025-32711, CVSS 9.3), um exploit sem necessidade de cliques em que prompts ocultos em e-mails disparavam uma exfiltração de dados silenciosa no SharePoint, no Teams e no OneDrive.
O mesmo padrão de vulnerabilidade aparece em estruturas de orquestração de LLM, onde cadeias de modelos e ferramentas normalmente carecem de aplicação automática de escopo, obrigando os desenvolvedores a cuidarem manualmente da atenuação.
Delegação recursiva: o problema da boneca russa
Os sistemas com vários agentes são criados para a decomposição de tarefas. Um agente principal divide solicitações complexas em subtarefas e as delega a especialistas. Esses subagentes podem delegar ainda mais. Cada salto cruza um limite de confiança e herda a autoridade original.
As diretrizes da OpenID Foundation sobre a IA agêntica apontam isso como a principal vantagem e o principal risco dos ecossistemas de agentes: "O verdadeiro poder de um ecossistema de agentes surge da delegação recursiva: a capacidade de um agente de decompor uma tarefa complexa delegando subtarefas a outros agentes mais especializados".
No entanto, esse poder vem acompanhado de um alerta: "os desafios se multiplicam exponencialmente com a delegação recursiva, a atenuação do escopo em cadeias de delegação, fluxos de usuário verdadeiramente 'em nome de' que mantêm a responsabilidade e o pesadelo da interoperabilidade de diferentes sistemas de identidade de agentes tentando se comunicar".
Em outras palavras, aquilo que dá poder à IA agêntica também a torna frágil, a menos que a arquitetura imponha controle em cada transferência.
Escopo, proveniência e contexto = três lacunas estruturais que criam riscos
1. Não há atenuação de escopo nos saltos de delegação. Cada agente em uma cadeia de delegação deve ter permissões mais restritas do que o agente anterior. Na prática, porém, esse princípio do menor privilégio muitas vezes falha. No cenário de contrabando de sessão de agente, um agente de pesquisa herdou o acesso à ferramenta buy_stock de um assistente financeiro, executando uma negociação oculta incorporada em um resumo de notícias. Os tokens OAuth tradicionais não podem ser restringidos após a emissão sem entrar em contato novamente com o servidor de autenticação, o que é incompatível com sistemas descentralizados. A delegação segura requer formatos de token compatíveis com a atenuação offline para que os agentes possam limitar o acesso de forma independente.
2. Não há prova criptográfica da linhagem de delegação. Os tokens OAuth validam a estrutura e o status, mas não oferecem rastreabilidade histórica. No terceiro salto de delegação, não existe vínculo criptográfico com o agente ou usuário iniciador. A Aembit informa: "sem provas criptográficas, agentes mal-intencionados podem falsificar declarações de delegação e acessar recursos aos quais não deveriam ter acesso".
3. Não há contextualização entre as sessões. As interações entre agentes em várias etapas exigem um alinhamento constante com a tarefa original. Sem ele, os agentes ficam à deriva, expandindo gradualmente seu comportamento para além da intenção. A Unit 42 recomenda a "contextualização": criar uma âncora de tarefa no início da sessão e validar o alinhamento semântico de forma contínua.
Limitação de escopo: as permissões devem ser reduzidas, não ampliadas
Os formatos de token emergentes, como Macaroons, Biscuits e Wafers, refletem a arquitetura que as cadeias de delegação exigem para serem seguras. Cada token é "recheado" com atributos essenciais: identidade, validade e uma raiz criptográfica. Os titulares podem adicionar camadas que apenas reduzem as permissões. Os tokens permanecem verificáveis offline, preservando a integridade e evitando a elevação de privilégios.
Embora a sintaxe varie conforme o formato, o padrão principal é consistente: os tokens podem ser atenuados localmente, nunca expandidos:
Cada subagente adiciona uma ressalva assinada, de acréscimo único, que restringe o escopo do token, formando uma cadeia verificável. Quando utilizada, o emissor pode rastrear todo o caminho da delegação. Se um agente de pesquisa tentar realizar a ação buy_stock, a solicitação falhará, de forma rastreável, com provas de quem restringiu o quê e onde.
Embora nenhum provedor de identidade importante ofereça suporte nativo a Macaroons ou Biscuits atualmente, os princípios fundamentais (atenuação offline, delegação criptográfica e restrições apenas de acréscimo) podem ser aplicados hoje usando a infraestrutura OAuth existente.
Como se proteger de ataques de delegação recursiva
Essas vulnerabilidades relacionadas à delegação de agentes de IA sugerem quatro requisitos de defesa:
1. Confirmação fora do canal: ações sensíveis exigem aprovação humana por meio de canais aos quais os agentes não têm acesso — notificações push ou interface do usuário separada, não chat.
2. Contextualização: ancore as sessões à tarefa original; sinalize desvios semânticos antes da execução.
3. Identidade e capacidades verificadas: os agentes devem apresentar credenciais assinadas (por exemplo, AgentCards criptográficos).
4. Visibilidade do usuário: instruções contrabandeadas têm sucesso quando ocultas. Revele as chamadas e registros de ferramentas.
Como a Okta e a Auth0 lidam com a delegação recursiva
A implementação desses controles de forma independente pode criar pontos cegos. A Okta e a Auth0 ajudam a resolver a delegação recursiva por meio de uma camada de identidade unificada:
Cross-App Access (XAA). O XAA, disponível na Okta e na Auth0, transfere o consentimento para o provedor de identidade, agora parte do MCP (desde novembro de 2025) em "Enterprise-Managed Authorization". Com base no ID-JAG, ele rastreia e revoga a linhagem de delegação, com isso, as ações do agente são registradas e podem ser revogadas.
Token Vault. O Auth0 Token Vault resolve o problema de “confused deputy” no acesso às credenciais dos agentes. APIs ingênuas permitem que os desenvolvedores passem parâmetros userId, expondo os sistemas a bugs ou injeções de prompts que podem obter as credenciais de outro usuário. Para eliminar isso, o Token Vault exige uma prova criptográfica da sessão atual do usuário, e nunca um identificador simples. Os agentes usam OAuth 2.0 Token Exchange (RFC 8693) para converter tokens de sessão em credenciais de curta duração e com escopo definido, obtendo uma atenuação precisa do escopo por meio de protocolos padrão.
Autorização assíncrona. O Auth0 Async Auth permite a aprovação fora do canal por meio de notificações push ou por e-mail, exigindo confirmação humana (por meio de canais que o LLM não pode manipular) para abordar diretamente a vulnerabilidade de contrabando de sessão do agente.
Autorização com granularidade fina. O Auth0 FGA, baseado no modelo Zanzibar do Google, impõe o acesso baseado em relacionamento em todas as chamadas. Os agentes validam e atualizam o estado da delegação a cada salto, restringindo as permissões progressivamente. Esse contexto stateful reside no FGA, não no token, permitindo a atenuação no estilo de capacidade sem exigir novos formatos de token.
Governança de identidade. O Okta Identity Governance estende o gerenciamento do ciclo de vida aos agentes, ajudando a garantir que as permissões delegadas sejam revisadas e revogadas à medida que as funções, os projetos ou os contextos de segurança evoluem. Aquilo que era apropriado no momento da implantação pode rapidamente se tornar excessivo. A governança permite o ajuste contínuo da autoridade dos agentes.
O caminho a seguir: delegação comprovada
Os sistemas com vários agentes oferecem capacidades que vão além do que os agentes individuais conseguem alcançar, mas também expõem lacunas que o IAM tradicional não cobre. Todas as vulnerabilidades mencionadas aqui compartilham o mesmo padrão: agentes ganhando mais autoridade do que o pretendido, operando sem visibilidade do usuário e sem deixar trilha de auditoria.
Para proteger a delegação, são necessários quatro fundamentos: atenuação do escopo em cada salto, verificação de linhagem em nível de token, alinhamento de contexto persistente e aprovação humana fora do canal para ações sensíveis.
Essas medidas não são mais opcionais. No âmbito da Lei de IA da União Europeia, a rastreabilidade e a supervisão são obrigações legais para sistemas de alto risco. O Artigo 14 exige que seres humanos compreendam e monitorem plenamente o funcionamento da IA.
Sem cadeias de delegação verificáveis, esse nível de supervisão entra em colapso. Sua infraestrutura deve permitir o controle auditável; do contrário, ela se torna um passivo de conformidade.
A seguir no artigo 5: o que acontece quando agentes de IA migram de fluxos de trabalho digitais para sistemas físicos onde um único passo em falso pode causar danos reais e a identidade se torna a última linha de defesa?
