Pesquisa da Unit 42 sobre Identidades em Nuvem Expõe os Limites da Segurança Baseada em Permissões

A Unit 42 analisou mais de 40.000 identidades em nuvem, revelando um conflito que revisões de permissões, por si só, não conseguem resolver. A pesquisa da Unit 42 sobre identidades em nuvem defende que as equipes de segurança precisam entender o que uma identidade realmente faz, e não apenas o que ela pode fazer.

Publicada em 14 de setembro de 2026, a pesquisa mapeia atividades de 125 ambientes de nuvem durante um período de observação de dois meses. Seu modelo agrupa identidades pelas operações registradas no AWS CloudTrail. Esses grupos correspondem a funções reconhecíveis, incluindo administradores, agentes de backup, ferramentas de segurança, usuários de DevOps e sistemas de entrega contínua.

A disputa central é entre a inferência de funções comportamentais e rótulos estáticos de identidade. Um nome confiável, uma política conhecida ou uma credencial legítima podem permanecer após um invasor alterar a finalidade da identidade. A Unit 42 propõe transformar o comportamento observado em contexto de função e, em seguida, usar desvios desse contexto para aprimorar a detecção automatizada.

A Unit 42 Mapeou Identidades por Ações, Não por Nomes

A pesquisa transforma a análise de identidades ao tratar a atividade de API como evidência da função operacional de uma identidade.

A pesquisa sobre identidade comportamental parte de um problema prático. Os ambientes de nuvem agora incluem funcionários, aplicações, pipelines de implantação, produtos de segurança e agentes autônomos. Seus nomes e permissões atribuídas frequentemente revelam pouco sobre sua função atual.

Uma identidade chamada “backup” pode, de forma legítima, ler um bucket de armazenamento todas as noites. Mais tarde, essa mesma identidade poderia enumerar usuários, inspecionar políticas ou criar recursos de computação. Essas ações seriam relevantes mesmo que seu nome e suas permissões permanecessem inalterados.

A Unit 42 representou cada identidade por meio das operações AWS que ela invocou durante o período do estudo. Os pesquisadores então compararam esses perfis comportamentais entre os ambientes participantes. Combinações semelhantes de operações reuniram identidades em grupos distintos.

O mapa resultante incluiu 30 grandes clusters que representam aproximadamente 20.000 identidades. Os pesquisadores associaram esses clusters a funções recorrentes, como administração, automação de infraestrutura, rede, segurança, backup, FinOps e serviços de dados.

O cluster administrativo ofereceu o exemplo mais claro. Ele continha cerca de 5.000 identidades em mais de 100 projetos de nuvem. Aproximadamente 94% de suas identidades geraram eventos ConsoleLogin, em comparação com menos de 1% nos demais clusters.

Cerca de 60% também invocaram operações associadas à atividade normal do console, incluindo GetCostAndUsage e GetCostForecast. Essas operações ajudaram a diferenciar administradores interativos de identidades de máquina que usam um conjunto mais restrito de APIs.

Essa evidência é importante porque nenhum evento isolado estabelece intenção. ConsoleLogin indica um login interativo, mas não comprova que o usuário seja administrador. Solicitações de gestão de custos podem ocorrer automaticamente quando o console é carregado.

A Unit 42 combinou quatro formas de análise para evitar depender de um único sinal conveniente. Ela examinou frequência de operações, operações distintivas, atributos de identidade e padrões recorrentes de nomenclatura dentro de cada cluster.

Um padrão de nomenclatura foi especialmente revelador. O AWS IAM Identity Center cria um prefixo reconhecível quando AdministratorAccess é atribuído por meio de seu conjunto padrão de permissões. O prefixo apareceu com frequência no cluster administrativo, reforçando a interpretação comportamental.

Os nomes eram evidência de apoio, não a base do modelo. Essa distinção impede que o método simplesmente redescubra rótulos já atribuídos às identidades. Também torna a abordagem mais útil quando os nomes são vagos, desatualizados ou deliberadamente enganosos.

A pesquisa não anuncia uma violação ou vulnerabilidade recém-observada. Ela apresenta um desenho de detecção baseado em telemetria operacional real. Seu valor noticioso vem de tornar a classificação de identidades em nuvem mais escalável e explicável.

A maioria dos inventários de identidade responde quem possui uma credencial e quais ações sua política permite. A Unit 42 acrescenta uma terceira pergunta: qual função operacional a atividade da identidade revela? Essa camada adicional cria a tensão que impulsiona todo o estudo.

Permissões Estáticas Deixam a Pergunta Mais Importante em Aberto

Uma permissão informa aos defensores o que é possível, enquanto o comportamento revela quais capacidades uma identidade está exercendo agora.

As políticas de gerenciamento de identidade e acesso continuam essenciais. Elas determinam se uma entidade pode ler um segredo, iniciar uma instância, modificar registros ou assumir outra função. O princípio do menor privilégio reduz o dano que uma credencial comprometida pode causar.

No entanto, a análise de políticas não consegue descrever plenamente a realidade operacional. As organizações frequentemente concedem acesso amplo para evitar bloquear implantações ou trabalhos de emergência. Funções antigas também acumulam permissões à medida que projetos, equipes e responsabilidades mudam.

Algumas identidades com privilégios excessivos operam sem causar danos por anos. Outras se tornam pontos de entrada valiosos após o roubo de credenciais. O documento de permissões parece arriscado em ambos os casos, mas não pode mostrar qual identidade começou a agir fora de sua função estabelecida.

O contexto comportamental fornece essa distinção ausente. Um processo de backup que acessa repetidamente um único destino protegido cria uma linha de base restrita. Enumeração de recursos, descoberta de identidades ou alterações administrativas representariam um desvio significativo dessa linha de base.

A mesma chamada de API pode apresentar riscos diferentes em outro contexto. ListBuckets pode ser esperado em um produto de inventário de segurança. Mereceria atenção mais detalhada se viesse de uma carga de trabalho que, historicamente, grava logs de aplicação em um único bucket.

É por isso que a pesquisa da Unit 42 sobre identidades em nuvem pressiona programas de segurança baseados apenas em postura. A gestão da postura de segurança em nuvem identifica permissões excessivas e problemas de configuração. Ela não explica automaticamente se as ações observadas correspondem ao trabalho real de uma identidade.

Os invasores se beneficiam dessa lacuna. Eles podem usar credenciais existentes, políticas herdadas e nomes de recursos aparentemente benignos. Sua atividade então aparece sob uma identidade que as equipes de segurança já reconhecem.

A dissimulação não exige alterar o nome da conta. Um invasor só precisa executar operações maliciosas por meio de uma identidade que os defensores consideram confiável. Inventários estáticos podem preservar essa confiança após o comportamento ter mudado.

A AWS já aplica análise comportamental em seu serviço gerenciado de detecção de ameaças. De acordo com sua documentação de detecção de anomalias, o GuardDuty cria perfis de campos de eventos do CloudTrail para identificar atividade anômala ou não autorizada.

O GuardDuty também considera fatores como a identidade solicitante, a API e a localização. Suas descobertas podem identificar atividades associadas a acesso a credenciais, descoberta, persistência, escalonamento de privilégios, exfiltração e impacto.

Essa capacidade existente valida a direção mais ampla, mas não elimina a contribuição da Unit 42. Detecções gerenciadas normalmente apresentam descobertas após os modelos e regras de um provedor identificarem atividade suspeita. Os clientes têm visibilidade limitada sobre a linha de base exata ou o processo de classificação.

A Unit 42 se concentra em atribuir uma função operacional que os defensores possam compreender e reutilizar. O modelo pergunta se uma identidade se comporta como administrador, sistema de implantação, scanner ou serviço de backup. Essa função pode enriquecer detecções subsequentes.

A distinção também muda a triagem. Uma chamada de API desconhecida não é automaticamente maliciosa, e uma chamada de API comum não é automaticamente inofensiva. Os analistas precisam comparar a ação com a função esperada da identidade.

Isso aumenta a pressão sobre fornecedores de segurança em nuvem, equipes internas de detecção e plataformas de governança de identidade. Cada um precisa conectar dados de direitos de acesso com atividade em tempo de execução. Um produto que expõe apenas um dos lados deixa os analistas reconstruírem manualmente o outro.

A pressão cresce à medida que identidades não humanas se multiplicam. Cargas de trabalho, sistemas CI/CD, contas de serviço, ferramentas de automação e agentes de IA podem atuar continuamente. Seu volume comportamental torna a classificação manual impraticável.

A resposta da Unit 42 não é descartar permissões. É combinar capacidades permitidas com operações observadas. As duas visões respondem a perguntas diferentes e se tornam mais úteis quando avaliadas em conjunto.

Como Funciona o Agrupamento de Identidades em Nuvem da Unit 42

A Unit 42 usa agrupamento não supervisionado para descobrir funções comportamentais e, em seguida, transforma essas descobertas em classificadores mais simples.

A primeira etapa começa com logs de auditoria em nuvem. O AWS CloudTrail registra eventos gerados por usuários, funções e serviços, incluindo a identidade e a API envolvida. A AWS explica esses campos em sua referência de eventos do CloudTrail.

A Unit 42 converte cada identidade em um vetor Booleano. Cada posição representa uma operação disponível, enquanto verdadeiro ou falso registra se a identidade invocou essa operação durante a janela de observação.

Isso produz um conjunto de dados desafiador. Segundo a pesquisa, a AWS disponibiliza mais de 15.000 operações possíveis em cerca de 240 serviços. A maioria das identidades invoca apenas um pequeno subconjunto, criando vetores grandes e, em sua maior parte, vazios.

O pipeline usa Uniform Manifold Approximation and Projection, ou UMAP, para reduzir esses vetores. O UMAP converte observações de alta dimensionalidade em representações menores, enquanto tenta preservar uma estrutura significativa de vizinhança.

Os pesquisadores usaram similaridade de cosseno como medida de distância. Essa medida compara a direção de dois vetores, em vez de seu tamanho absoluto. Ela enfatiza quais operações as identidades compartilham, em vez de favorecer a identidade que gerou mais atividade.

Uma execução do UMAP criou representações densas contendo 32 valores contínuos. Uma execução separada projetou as identidades em duas dimensões para visualização. Essas duas saídas têm finalidades diferentes e não devem ser tratadas como intercambiáveis.

A representação densa então entra no HDBSCAN, um método de agrupamento que identifica regiões com alta densidade de pontos. Ao contrário de algoritmos que exigem um número fixo de grupos, o HDBSCAN pode descobrir clusters e marcar pontos incomuns como ruído.

Ambos os métodos possuem fundamentos de pesquisa consolidados. O artigo original sobre UMAP descreve a técnica de redução de dimensionalidade, enquanto o artigo sobre HDBSCAN aborda o agrupamento hierárquico baseado em densidade.

Depois que as identidades recebem atribuições de cluster, os analistas ainda precisam interpretar cada grupo. Um identificador de cluster não vem acompanhado de um rótulo como “administrador” ou “serviço de backup”. Por isso, a pesquisa aplica vários testes para inferir sua função.

A frequência de operações mostra quais APIs aparecem em todo um cluster. Um método de pontuação baseado em classes identifica operações que ocorrem com frequência dentro de um grupo, mas permanecem incomuns em outros lugares. Isso separa APIs meramente populares de sinais genuinamente distintivos.

O mapeamento de atributos acrescenta outra perspectiva. Os pesquisadores podem destacar identidades que usam serviços específicos, invocam operações determinadas ou contêm strings recorrentes. A concentração de atributos fornece evidências para um rótulo funcional proposto.

Por fim, a mineração de substrings identifica fragmentos repetidos entre nomes de identidades. Isso pode revelar convenções criadas por sistemas de implantação ou produtos de gerenciamento de identidades. É mais seguro do que declarar uma função a partir do nome de uma única identidade.

Juntos, esses métodos transformam um padrão visual em uma categoria comportamental interpretável. Essa interpretação continua sendo um julgamento analítico, mas se apoia em várias formas de evidência.

A abordagem de agrupamento de identidades em nuvem da Unit 42 não é, portanto, um decodificador mágico de identidades. Trata-se de um pipeline estruturado para encontrar padrões operacionais recorrentes. A análise humana ainda conecta esses padrões a funções organizacionais reais.

Essa limitação também é uma força. As equipes de segurança podem examinar por que um cluster recebeu determinado rótulo. Elas podem testar se as operações distintivas correspondem ao próprio ambiente antes de usar a classificação em produção.

O processo se assemelha à cartografia exploratória. O aprendizado não supervisionado desenha o mapa sem receber uma lista predefinida de funções. Depois, os analistas identificam quais regiões correspondem a comportamentos operacionais conhecidos.

No entanto, executar repetidamente todo o pipeline de mapeamento introduziria custos computacionais e operacionais. Também poderia produzir identificadores de cluster instáveis à medida que conjuntos de dados e parâmetros mudam. A Unit 42 aborda esse problema na próxima etapa.

O Verdadeiro Avanço É o Caminho dos Modelos ao SQL

A etapa operacionalmente mais importante é destilar os clusters descobertos em regras pequenas e interpretáveis que os sistemas de dados existentes possam executar.

Depois de identificar um cluster útil, a Unit 42 treina um classificador de regressão logística com base nos vetores booleanos originais de operações. A regressão logística calcula como características individuais alteram a probabilidade de uma observação pertencer a uma classe escolhida.

Uma equipe poderia treinar um classificador para comportamento de administradores e outro para ferramentas de segurança. Novas identidades seriam então avaliadas pelos modelos relevantes sem reconstruir o mapa comportamental completo.

A Unit 42 também aplica regularização L1. Essa penalidade empurra os coeficientes de características pouco úteis em direção a zero. As operações restantes formam um conjunto muito menor de indicadores positivos e negativos.

Essa esparsidade é importante para as operações de segurança. Um modelo com milhares de características interagindo seria difícil de inspecionar, explicar ou reproduzir. Um classificador baseado em algumas dezenas de operações ponderadas é muito mais fácil de operacionalizar.

Os analistas podem ver quais chamadas de API aproximam uma identidade de uma classificação de administrador. Também podem ver quais operações a afastam dela. Essa visibilidade permite revisão antes que a lógica afete os alertas.

Os pesquisadores afirmam que essa lógica ponderada pode ser expressa por meio de consultas SQL padrão. A maioria das organizações de segurança já centraliza logs de nuvem em data warehouses, lagos de dados de segurança ou plataformas analíticas. O SQL reduz a barreira de implantação.

Isso não significa que todo o fluxo de trabalho de aprendizado de máquina desapareça. A etapa original de agrupamento ainda descobre grupos significativos e fornece rótulos de treinamento. O classificador leve é uma aproximação local dessa análise anterior.

Essa distinção protege o artigo de uma conclusão enganosa. A Unit 42 não reduziu todos os problemas de segurança em nuvem a uma instrução SQL. Ela mostrou como um limite de classificação aprendido pode se tornar uma lógica de consulta transparente.

Esse desenho apresenta um compromisso prático entre aprendizado de máquina sob medida e regras rígidas escritas manualmente. Detecções totalmente manuais dependem de analistas preverem combinações relevantes antecipadamente. Modelos complexos podem ser caros e difíceis de explicar.

O agrupamento comportamental descobre padrões candidatos a partir de dados observados. Classificadores esparsos então preservam padrões selecionados em um formato inspecionável. As equipes de detecção obtêm contexto reutilizável sem manter continuamente o pipeline exploratório.

Considere o exemplo do serviço de backup. Um classificador pode reconhecer operações associadas à atividade regular de backup e atribuir uma função funcional. A lógica de detecção pode então tratar descobertas administrativas ou alterações de política como comportamentos que entram em conflito com essa função.

O alerta é mais forte porque descreve uma incompatibilidade, não apenas um evento raro. “Identidade de backup realizou comportamento de administrador” dá a um analista mais contexto do que “API incomum observada”. Isso conecta a linha de base do ator à ação suspeita.

A mesma abordagem poderia oferecer suporte a sistemas de CI/CD. Identidades de implantação frequentemente executam operações recorrentes de infraestrutura em serviços previsíveis. O abuso de credenciais pode introduzir atividade de console, descoberta ampla ou acesso a dados não relacionados.

Produtos de segurança representam outra categoria útil. Eles enumeram recursos e inspecionam configurações regularmente. Sem contexto de função, essas ações podem se assemelhar ao reconhecimento realizado por invasores e gerar ruído evitável.

A classificação funcional pode, portanto, reduzir dois erros diferentes. Ela pode diminuir falsos positivos quando um acesso amplo corresponde a um scanner conhecido. Pode aumentar a suspeita quando uma automação de finalidade restrita começa a se comportar como um administrador.

É aqui que a inferência de função comportamental compete mais diretamente com a rotulagem estática. Um nome como “security-scanner” pede que os analistas confiem na configuração. Um padrão observado lhes dá evidência de que a identidade continua desempenhando essa função.

O método também complementa a análise de permissões. Um scanner de segurança pode se comportar normalmente enquanto mantém privilégios excessivos. Ferramentas de postura ainda devem reportar essa exposição, mesmo quando as detecções em tempo de execução não encontram nada suspeito.

Por outro lado, uma identidade com permissões estritamente limitadas ainda pode se comportar de forma inesperada dentro de seu escopo permitido. O monitoramento comportamental deve sinalizar essa mudança, mesmo quando uma revisão de política não encontra violação.

O modelo cria, portanto, uma camada adicional de dados, e não um controle substituto. Permissões definem limites. O agrupamento infere funções. A lógica de detecção identifica desvios que merecem investigação.

A Unit 42 afirma que a metodologia pode se estender além do AWS CloudTrail para outros provedores de nuvem, Kubernetes e serviços de software. Essa extensão é plausível porque esses sistemas também produzem eventos de auditoria vinculados a identidades.

No entanto, a portabilidade exige nova validação. Azure, Google Cloud, Kubernetes e plataformas SaaS expõem vocabulários de eventos e estruturas de identidade diferentes. Um classificador treinado com operações AWS não pode simplesmente ser transferido sem alterações.

O Que a Pesquisa Ainda Não Comprova

O conjunto de dados demonstra clusters comportamentais coerentes, mas não estabelece precisão de detecção universal entre organizações, provedores ou cargas de trabalho em constante mudança.

A Unit 42 relata uma escala substancial, incluindo mais de 40.000 identidades e 125 ambientes. Essa abrangência sustenta a afirmação de que funções comportamentais recorrentes aparecem em vários ambientes de nuvem. Ela não responde a todas as questões de produção.

A publicação não fornece um benchmark completo com precisão, revocação, taxas de falsos positivos e desempenho em todas as funções identificadas. Ela afirma que a regressão logística pode identificar com precisão clusters selecionados, mas leitores públicos não podem reproduzir cada resultado de forma independente.

O estudo também se concentra em uma janela de observação de dois meses. Esse período captura operações recorrentes, mas algumas identidades legítimas agem apenas durante testes trimestrais de recuperação, migrações ou resposta a incidentes. Linhas de base curtas podem classificar incorretamente trabalhos raros, porém autorizados.

Vetores booleanos introduzem outro compromisso. Eles preservam se uma operação ocorreu, mas omitem com que frequência ela aconteceu. Uma identidade que chama uma API uma vez parece idêntica nessa característica a outra que a chama milhares de vezes.

Essa simplificação ajuda a controlar a dimensionalidade e favorece a interpretabilidade. Ela também pode eliminar sinais de volume que distinguem trabalho rotineiro de abuso. Frequência, horário, geografia, parâmetros de solicitação e recursos-alvo podem ser importantes durante uma investigação.

A deriva de conceito apresenta outro problema. O comportamento funcional muda quando as equipes adotam novos serviços, revisam pipelines ou migram arquiteturas. Um classificador treinado com as operações de ontem pode tratar mudanças legítimas de implantação como suspeitas.

Os invasores também podem se adaptar. Se compreenderem a função comportamental esperada, podem escolher operações que se pareçam com sua atividade normal. A classificação comportamental aumenta o custo da dissimulação, mas não elimina a evasão.

A abordagem depende de telemetria confiável. Cobertura ausente do CloudTrail, registro desativado, retenção inconsistente ou coleta incompleta entre contas distorcerão os vetores de identidade. Um modelo limpo não pode recuperar eventos que nunca foram registrados.

Os limites de identidade também podem se tornar ambíguos. Funções assumidas, sessões federadas, credenciais de cargas de trabalho e caminhos de automação compartilhados podem agrupar vários atores em um único principal aparente. A inferência de função é apenas tão precisa quanto os identificadores nos logs de origem.

Dados entre organizações acrescentam outra incerteza. O comportamento compartilhado pode revelar padrões estáveis do setor, mas cada empresa configura contas de modo diferente. Operações fortemente associadas a administradores em um ambiente podem surgir automaticamente em outro.

O cluster administrativo ilustra esse risco. ConsoleLogin é altamente distintivo no conjunto de dados relatado. Ainda assim, solicitações automáticas ao console, arquiteturas de acesso federado e mudanças na interface do provedor podem alterar quais operações acompanham uma sessão interativa.

Até a expressão “função funcional” pode transmitir mais certeza do que as evidências sustentam. Um cluster descreve similaridade comportamental durante um período de observação. Ele não comprova propriedade organizacional, autorização ou finalidade de negócios.

As equipes de segurança devem, portanto, tratar funções atribuídas como metadados contextuais. Devem combiná-las com dados de permissões, escopo de recursos, indicadores de rede, sinais de autenticação e inteligência de ameaças. Nenhuma dimensão isolada estabelece intenção maliciosa.

O contexto comercial também merece escrutínio. A Unit 42 é a organização de pesquisa de ameaças da Palo Alto Networks, e a publicação conecta a metodologia ao Cortex Cloud e produtos relacionados. Suas conclusões técnicas continuam valiosas, mas as alegações sobre produtos exigem validação do lado do cliente.

As organizações devem perguntar se as classificações permanecem estáveis entre contas e ao longo do tempo. Devem medir a qualidade dos alertas antes de permitir que incompatibilidades de função acionem contenções automatizadas. Uma resposta equivocada poderia interromper backups, implantações ou monitoramento de segurança.

A avaliação em modo de simulação oferece um caminho de adoção mais seguro. As equipes podem calcular funções inferidas, compará-las com a propriedade conhecida dos ativos e observar desvios sem alterar o acesso de produção. Depois, os analistas podem refinar limites e exceções.

O melhor teste não é se a visualização parece convincente. É se o contexto de função encurta as investigações enquanto preserva detecções significativas. Esse resultado exige evidências operacionais além da publicação de pesquisa.

Três Sinais Mostrarão Se a Detecção de Identidades Comportamentais se Sustenta

O próximo teste é saber se a inferência de função comportamental permanece precisa, portátil e útil depois de deixar o ambiente de pesquisa.

O primeiro sinal é o desempenho mensurável de detecção. A Unit 42 ou seus clientes precisam publicar resultados de precisão, revocação e falsos positivos para diversas funções. A classificação de administradores, por si só, não pode estabelecer desempenho para agentes de backup, sistemas de implantação ou agentes autônomos.

Os resultados devem incluir ambientes inéditos, em vez de identidades amostradas da mesma população organizacional. Um desempenho forte em ambientes externos apoiaria a afirmação de que padrões funcionais se generalizam. Quedas acentuadas exporiam premissas específicas de cada ambiente.

O segundo sinal é a validação entre plataformas. Os pesquisadores afirmam que sua metodologia pode se estender ao Kubernetes, a aplicações SaaS e a outros provedores de nuvem. Uma implementação documentada fora da AWS testaria essa afirmação.

Portabilidade deve significar mais do que processar um formato de log diferente. O método precisa descobrir funções reconhecíveis, produzir classificadores estáveis e melhorar decisões reais de detecção. Caso contrário, as convenções de API da AWS podem estar fazendo mais trabalho do que a estrutura geral.

O terceiro sinal é a adoção operacional por meio de fluxos de detecção transparentes. As equipes de segurança devem observar integrações que exponham, dentro de um alerta, a função inferida, as operações que contribuem para ela, a confiança e o comportamento conflitante.

Uma pontuação de risco simples ocultaria a principal vantagem da pesquisa. O valor está em explicar que uma identidade de backup conhecida começou a agir como um administrador. Os analistas precisam dessa relação para avaliar a urgência e escolher uma resposta.

As implementações mais robustas também acompanharão as mudanças de função ao longo do tempo. Uma conta de implantação pode legitimamente expandir para novos serviços. Os sistemas precisam de cronogramas de retreinamento, monitoramento de deriva, classificadores versionados e processos de revisão para comportamentos alterados.

As equipes devem evitar tratar cada incompatibilidade como um incidente. Alguns desvios refletirão manutenção, migrações ou novos lançamentos de produtos. O sinal de função deve priorizar a investigação, enquanto outras evidências determinam se a contenção é justificada.

Identidades humanas e de máquina também devem ser avaliadas separadamente. Administradores interativos, serviços agendados e agentes autônomos geram atividade em ritmos diferentes. Eles podem exigir janelas de observação e limites distintos.

Os agentes autônomos tornam essa questão especialmente urgente. Um agente pode executar sequências variáveis em muitos serviços enquanto busca um único objetivo aprovado. Rótulos estáticos de tarefas descreverão mal esse comportamento.

No entanto, o comportamento variável também torna o agrupamento mais difícil. O espaço de ações legítimas de um agente pode se sobrepor ao reconhecimento, às alterações de configuração e ao acesso a dados. Os defensores precisarão de contexto sobre objetivos, aprovações, recursos e históricos de execução.

A proposta de identidades em nuvem da Unit 42 fornece uma parte desse contexto. Ela cria uma descrição empírica de como uma identidade se comporta entre seus pares. Não determina se o objetivo subjacente foi autorizado.

Para desenvolvedores, a questão imediata é se as identidades de implantação e de serviço têm padrões claros e observáveis. As equipes devem avaliar se os eventos de auditoria podem ser conectados de forma consistente entre funções assumidas e sessões de automação.

Compradores corporativos devem perguntar aos fornecedores como as funções funcionais são inferidas. Também devem solicitar evidências que expliquem quais eventos orientam cada classificação. “Detecção de anomalias com IA” não é informação suficiente para uma decisão de segurança de alto impacto.

Líderes de segurança devem comparar descobertas comportamentais com revisões de acesso. Uma identidade que parece operacionalmente limitada, mas mantém permissões amplas, representa uma exposição evitável. Uma identidade que muda subitamente de função representa uma possível ameaça ativa.

Trabalhadores do conhecimento e usuários de produtos de IA têm um interesse relacionado. Aplicações empresariais conectam cada vez mais assistentes e agentes aos dados corporativos. Cada conexão cria uma identidade cujo comportamento efetivo pode ir além de um simples rótulo de usuário.

Os próximos um a três meses devem revelar se a Palo Alto Networks publica mais validações, amplia a cobertura de funções ou expõe a lógica mais diretamente nos fluxos de trabalho dos clientes. Testes independentes fortaleceriam ainda mais o caso.

Os leitores devem acompanhar três perguntas concretas: os classificadores funcionam em ambientes inéditos, são transferíveis além da AWS e melhoram as decisões dos analistas? Essas respostas determinarão se os mapas comportamentais de identidade se tornarão contexto rotineiro de segurança.

A avaliação central do estudo já se sustenta: documentos de permissões são necessários, mas não constituem um retrato completo do risco de identidade. Os defensores também precisam de evidências sobre o que credenciais, cargas de trabalho e agentes realmente fazem.

Revise seu próprio inventário em nuvem por essa perspectiva. Quais identidades têm nomes e permissões, mas nenhuma função comportamental verificada? As lacunas nessa resposta identificam onde a pesquisa de identidades em nuvem da Unit 42 é mais relevante.