Unit 42 Cloud Identities Research Exposes the Limits of Permission-Based Security

Unit 42 analyzed more than 40,000 cloud identities, revealing a conflict that permission reviews alone cannot resolve. The Unit 42 cloud identities research argues that security teams must understand what an identity actually does, not merely what it can do.

Published on September 14, 2026, the research maps activity from 125 cloud environments across a two-month observation period. Its model groups identities by the operations recorded in AWS CloudTrail. Those groups correspond to recognizable roles, including administrators, backup agents, security tools, DevOps users, and continuous delivery systems.

The important contest is behavioral role inference versus static identity labels. A trusted name, familiar policy, or legitimate credential can survive after an attacker changes the identity’s purpose. Unit 42 proposes turning observed behavior into role context, then using deviations from that context to improve automated detection.

Unit 42 Mapped Identities by Actions, Not Names

The research changes identity analysis by treating API activity as evidence of an identity’s working role.

The behavioral identity research starts from a practical problem. Cloud estates now contain employees, applications, deployment pipelines, security products, and autonomous agents. Their names and assigned permissions often reveal little about their current function.

An identity called “backup” might legitimately read one storage bucket every night. The same identity might later enumerate users, inspect policies, or create compute resources. Those actions would matter even if its name and permissions remained unchanged.

Unit 42 represented each identity through the AWS operations it invoked during the study period. The researchers then compared those behavioral profiles across participating environments. Similar combinations of operations pulled identities into distinct groups.

The resulting map included 30 large clusters representing approximately 20,000 identities. Researchers associated those clusters with recurring functions such as administration, infrastructure automation, networking, security, backup, FinOps, and data services.

The administrative cluster supplied the clearest example. It contained roughly 5,000 identities across more than 100 cloud projects. About 94 percent of its identities generated ConsoleLogin events, compared with fewer than 1 percent in other clusters.

Around 60 percent also invoked operations associated with normal console activity, including GetCostAndUsage and GetCostForecast. These operations helped distinguish interactive administrators from machine identities using a narrower set of APIs.

That evidence matters because no single event establishes intent. ConsoleLogin indicates an interactive sign-in, but it does not prove that the user is an administrator. Cost-management requests might occur automatically when the console loads.

Unit 42 combined four forms of analysis to avoid relying on one convenient signal. It examined operation frequency, distinguishing operations, identity attributes, and repeated naming patterns within each cluster.

One naming pattern was especially revealing. AWS IAM Identity Center creates a recognizable prefix when AdministratorAccess is assigned through its standard permission set. The prefix appeared frequently inside the administrative cluster, supporting the behavioral interpretation.

Names were supporting evidence, not the model’s foundation. That distinction prevents the method from simply rediscovering labels already attached to identities. It also makes the approach more useful when names are vague, outdated, or intentionally deceptive.

The research does not announce a newly observed breach or vulnerability. It presents a detection design built from real operational telemetry. Its news value comes from making cloud identity classification more scalable and explainable.

Most identity inventories answer who owns a credential and which actions its policy allows. Unit 42 adds a third question: what functional role does the identity’s activity reveal? That additional layer creates the tension driving the entire study.

Static Permissions Leave the Most Important Question Open

A permission tells defenders what is possible, while behavior reveals which capabilities an identity is exercising now.

Identity and access management policies remain essential. They determine whether a principal can read a secret, launch an instance, modify logging, or assume another role. Least privilege reduces the damage available to a compromised credential.

However, policy analysis cannot fully describe operational reality. Organizations frequently grant broad access to avoid blocking deployments or emergency work. Old roles also accumulate permissions as projects, teams, and responsibilities change.

Some overprivileged identities operate harmlessly for years. Others become valuable entry points after credential theft. The permission document looks risky in both cases, yet it cannot show which identity has begun acting outside its established function.

Behavioral context supplies that missing distinction. A backup process that repeatedly accesses one protected destination creates a narrow baseline. Resource enumeration, identity discovery, or administrative changes would represent a meaningful departure from that baseline.

The same API call can carry different risk in another context. ListBuckets might be expected from a security inventory product. It would deserve closer attention from a workload that has historically written application logs to one bucket.

This is why Unit 42 cloud identities research pressures posture-only security programs. Cloud security posture management identifies excessive permissions and configuration problems. It does not automatically explain whether observed actions match an identity’s real job.

Attackers benefit from that gap. They can use existing credentials, inherited policies, and benign-looking resource names. Their activity then appears under an identity that security teams already recognize.

Masquerading does not require changing the account name. An attacker only needs to perform malicious operations through an identity that defenders consider trusted. Static inventories can preserve that trust after the behavior has changed.

AWS already applies behavioral analysis in its managed threat-detection service. According to its anomaly detection documentation, GuardDuty profiles fields from CloudTrail events to identify anomalous or unauthorized activity.

GuardDuty also considers factors such as the requesting identity, API, and location. Its findings can identify activities associated with credential access, discovery, persistence, privilege escalation, exfiltration, and impact.

That existing capability validates the broader direction, but it does not eliminate Unit 42’s contribution. Managed detections usually present findings after a provider’s models and rules identify suspicious activity. Customers have limited visibility into the exact baseline or classification process.

Unit 42 focuses on assigning a functional role that defenders can understand and reuse. The model asks whether an identity behaves like an administrator, deployment system, scanner, or backup service. That role can enrich subsequent detections.

The distinction also changes triage. An unfamiliar API call is not automatically malicious, and a common API call is not automatically harmless. Analysts need to compare the action with the identity’s expected function.

This creates pressure for cloud-security vendors, internal detection teams, and identity-governance platforms. Each must connect entitlement data with runtime activity. A product that exposes only one side leaves analysts to reconstruct the other manually.

The pressure grows as nonhuman identities multiply. Workloads, CI/CD systems, service accounts, automation tools, and AI agents can act continuously. Their behavioral volume makes manual classification impractical.

Unit 42’s answer is not to discard permissions. It is to combine permitted capabilities with observed operations. The two views address different questions and become more useful when evaluated together.

How Unit 42 Cloud Identities Clustering Works

Unit 42 uses unsupervised clustering to discover behavioral roles, then distills those discoveries into simpler classifiers.

The first stage starts with cloud audit logs. AWS CloudTrail records events generated by users, roles, and services, including the identity and API involved. AWS explains these fields in its CloudTrail event reference.

Unit 42 converts each identity into a Boolean vector. Every position represents an available operation, while true or false records whether the identity invoked that operation during the observation window.

This produces a difficult dataset. AWS exposes more than 15,000 possible operations across roughly 240 services, according to the research. Most identities invoke only a small subset, creating vectors that are large and mostly empty.

The pipeline uses Uniform Manifold Approximation and Projection, or UMAP, to reduce those vectors. UMAP converts high-dimensional observations into smaller representations while attempting to preserve meaningful neighborhood structure.

The researchers used cosine similarity as the distance measure. This measure compares the direction of two vectors rather than their absolute size. It emphasizes which operations identities share instead of favoring whichever identity generated more activity.

One UMAP pass created dense representations containing 32 continuous values. A separate pass projected the identities into two dimensions for visualization. Those two outputs serve different purposes and should not be treated as interchangeable.

The dense representation then enters HDBSCAN, a clustering method that identifies regions with high point density. Unlike algorithms requiring a fixed number of groups, HDBSCAN can discover clusters and mark unusual points as noise.

Both methods have established research foundations. The original UMAP paper describes the dimensionality-reduction technique, while the HDBSCAN paper covers hierarchical density-based clustering.

Once identities receive cluster assignments, analysts still need to interpret each group. A cluster identifier does not arrive with a label saying “administrator” or “backup service.” The research therefore applies multiple tests to infer its role.

Operation frequency shows which APIs appear throughout a cluster. A class-based scoring method identifies operations that occur frequently inside one group but remain uncommon elsewhere. This separates merely popular APIs from genuinely distinctive signals.

Attribute mapping adds another perspective. Researchers can highlight identities using particular services, invoking specific operations, or containing recurring strings. Concentrated attributes provide evidence for a proposed functional label.

Finally, substring mining identifies repeated fragments across identity names. This can reveal conventions created by deployment systems or identity-management products. It is safer than declaring a role from one identity’s name alone.

Together, these methods turn a visual pattern into an interpretable behavioral category. That interpretation remains an analytical judgment, but it rests on several forms of evidence.

The Unit 42 cloud identities clustering approach is therefore not a magical identity decoder. It is a structured pipeline for finding repeated operational patterns. Human analysis still connects those patterns to real organizational functions.

That limitation is also a strength. Security teams can examine why a cluster received a label. They can test whether distinctive operations match their own environment before using the classification in production.

The process resembles exploratory cartography. Unsupervised learning draws the map without receiving a predefined list of roles. Analysts then identify which regions correspond to known operational behavior.

Yet repeatedly running the entire mapping pipeline would introduce computational and operational costs. It could also produce shifting cluster identifiers as datasets and parameters change. Unit 42 addresses that problem in the next stage.

The Real Advance Is the Path From Models to SQL

The most operationally important step is distilling discovered clusters into small, interpretable rules that existing data systems can execute.

After identifying a useful cluster, Unit 42 trains a logistic-regression classifier against the original Boolean operation vectors. Logistic regression calculates how individual features change the likelihood that an observation belongs to a chosen class.

A team could train one classifier for administrator behavior and another for security tooling. New identities would then be evaluated against the relevant models without rebuilding the complete behavioral map.

Unit 42 also applies L1 regularization. This penalty pushes coefficients for unhelpful features toward zero. The remaining operations form a much smaller set of positive and negative indicators.

That sparsity is important for security operations. A model with thousands of interacting features would be difficult to inspect, explain, or reproduce. A classifier based on several dozen weighted operations is far easier to operationalize.

Analysts can see which API calls move an identity toward an administrator classification. They can also see which operations move it away. That visibility supports review before the logic affects alerts.

The researchers say this weighted logic can be expressed through standard SQL queries. Most security organizations already centralize cloud logs in warehouses, security data lakes, or analytics platforms. SQL lowers the deployment barrier.

This does not mean the entire machine-learning workflow disappears. The original clustering stage still discovers meaningful groups and supplies training labels. The lightweight classifier is a local approximation of that earlier analysis.

The distinction protects the article from a misleading conclusion. Unit 42 did not reduce every cloud-security problem to a SQL statement. It showed how one learned classification boundary can become transparent query logic.

That design presents a practical compromise between bespoke machine learning and rigid handwritten rules. Fully manual detections depend on analysts predicting relevant combinations in advance. Complex models can be expensive and difficult to explain.

Behavioral clustering discovers candidate patterns from observed data. Sparse classifiers then preserve selected patterns in an inspectable format. Detection teams gain reusable context without maintaining the exploratory pipeline continuously.

Consider the backup-service example. A classifier might recognize operations associated with regular backup activity and assign a functional role. Detection logic can then treat administrative discovery or policy changes as behavior that conflicts with that role.

The alert is stronger because it describes a mismatch, not just a rare event. “Backup identity performed administrator behavior” gives an analyst more context than “unusual API observed.” It connects the actor’s baseline with the suspicious action.

The same approach could support CI/CD systems. Deployment identities often perform recurring infrastructure operations across predictable services. Credential abuse might introduce console activity, broad discovery, or unrelated data access.

Security products represent another useful category. They regularly enumerate resources and inspect configuration. Without role context, those actions can resemble attacker reconnaissance and generate avoidable noise.

Functional classification can therefore reduce two different errors. It can lower false positives when broad access matches a known scanner. It can raise suspicion when narrow-purpose automation begins behaving like an administrator.

This is where behavioral role inference competes most directly with static labeling. A name such as “security-scanner” asks analysts to trust configuration. An observed pattern gives them evidence that the identity continues performing that function.

The method also complements permission analysis. A security scanner might behave normally while retaining excessive rights. Posture tools should still report that exposure, even when runtime detections find nothing suspicious.

Conversely, a tightly permissioned identity can still behave unexpectedly within its allowed scope. Behavioral monitoring should flag that change, even when a policy review finds no violation.

The model therefore creates an additional data layer rather than a replacement control. Permissions define boundaries. Clustering infers roles. Detection logic identifies departures that deserve investigation.

Unit 42 says the methodology can extend beyond AWS CloudTrail to other cloud providers, Kubernetes, and software services. That extension is plausible because these systems also produce identity-linked audit events.

However, portability requires new validation. Azure, Google Cloud, Kubernetes, and SaaS platforms expose different event vocabularies and identity structures. A classifier trained on AWS operations cannot simply transfer unchanged.

What the Research Does Not Yet Prove

The dataset demonstrates coherent behavioral clusters, but it does not establish universal detection accuracy across organizations, providers, or changing workloads.

Unit 42 reports substantial scale, including more than 40,000 identities and 125 environments. That breadth supports the claim that repeated behavioral roles appear across multiple cloud estates. It does not answer every production question.

The publication does not provide a complete benchmark with precision, recall, false-positive rates, and performance across all identified roles. It says logistic regression can accurately identify selected clusters, but public readers cannot independently reproduce every result.

The study also focuses on a two-month observation window. That period captures recurring operations, but some legitimate identities act only during quarterly recovery tests, migrations, or incident response. Short baselines can misclassify rare yet authorized work.

Boolean vectors introduce another tradeoff. They preserve whether an operation occurred but omit how often it happened. An identity calling an API once looks identical on that feature to one calling it thousands of times.

That simplification helps control dimensionality and supports interpretability. It can also erase volume signals that distinguish routine work from abuse. Frequency, timing, geography, request parameters, and resource targets can all matter during investigation.

Concept drift presents a further problem. Functional behavior changes when teams adopt new services, revise pipelines, or migrate architectures. A classifier trained on yesterday’s operations can treat legitimate deployment changes as suspicious.

Attackers can also adapt. If they understand the expected behavioral role, they can choose operations that resemble its normal activity. Behavioral classification raises the cost of masquerading, but it does not eliminate evasion.

The approach depends on reliable telemetry. Missing CloudTrail coverage, disabled logging, inconsistent retention, or incomplete cross-account collection will distort the identity vectors. A clean model cannot recover events that were never recorded.

Identity boundaries can also become ambiguous. Assumed roles, federated sessions, workload credentials, and shared automation paths might collapse several actors into one apparent principal. Role inference is only as precise as the identifiers in the source logs.

Cross-organization data adds another uncertainty. Shared behavior can reveal stable industry patterns, but every company configures accounts differently. Operations strongly associated with administrators in one estate might arise automatically elsewhere.

The administrative cluster illustrates this risk. ConsoleLogin is highly distinctive in the reported dataset. Yet automatic console requests, federated access designs, and provider-interface changes can alter which operations accompany an interactive session.

Even the phrase “functional role” can imply more certainty than the evidence supports. A cluster describes behavioral similarity during an observation period. It does not prove organizational ownership, authorization, or business purpose.

Security teams should therefore treat assigned roles as contextual metadata. They should combine them with permission data, resource scope, network indicators, authentication signals, and threat intelligence. No single dimension establishes malicious intent.

The commercial context also deserves scrutiny. Unit 42 is Palo Alto Networks’ threat-research organization, and the publication connects the methodology with Cortex Cloud and related products. Its technical findings remain valuable, but product claims require customer-side validation.

Organizations should ask whether classifications remain stable across accounts and time. They should measure alert quality before allowing role mismatches to trigger automated containment. A mistaken response could interrupt backups, deployments, or security monitoring.

Dry-run evaluation offers a safer adoption path. Teams can calculate inferred roles, compare them with known asset ownership, and observe deviations without changing production access. Analysts can then refine thresholds and exceptions.

The best test is not whether the visualization looks convincing. It is whether role context shortens investigations while preserving meaningful detections. That outcome requires operational evidence beyond the research publication.

Three Signals Will Show Whether Behavioral Identity Detection Holds Up

The next test is whether behavioral role inference remains accurate, portable, and useful after it leaves the research environment.

The first signal is measurable detection performance. Unit 42 or customers need to publish precision, recall, and false-positive results for several roles. Administrator classification alone cannot establish performance for backup agents, deployment systems, or autonomous agents.

Results should include unseen environments rather than identities sampled from the same organizational population. Strong performance on external estates would support the claim that functional patterns generalize. Sharp declines would expose environment-specific assumptions.

The second signal is cross-platform validation. The researchers say their methodology can extend to Kubernetes, SaaS applications, and other cloud providers. A documented implementation outside AWS would test that assertion.

Portability should mean more than processing a different log format. The method must discover recognizable roles, produce stable classifiers, and improve real detection decisions. Otherwise, AWS API conventions might be doing more work than the general framework.

The third signal is operational adoption through transparent detection workflows. Security teams should watch for integrations that expose the inferred role, contributing operations, confidence, and conflicting behavior inside an alert.

A simple risk score would conceal the research’s main advantage. The value comes from explaining that a known backup identity has started acting like an administrator. Analysts need that relationship to judge urgency and choose a response.

The strongest implementations will also track role changes over time. A deployment account can legitimately expand into new services. Systems need retraining schedules, drift monitoring, versioned classifiers, and review processes for changed behavior.

Teams should resist treating every mismatch as an incident. Some deviations will reflect maintenance, migrations, or new product releases. The role signal should prioritize investigation while other evidence determines whether containment is justified.

Human and machine identities should also be evaluated separately. Interactive administrators, scheduled services, and autonomous agents generate activity at different speeds. They may require different observation windows and thresholds.

Autonomous agents make this question especially urgent. An agent might perform variable sequences across many services while pursuing one approved objective. Static job labels will describe that behavior poorly.

Yet variable behavior also makes clustering harder. An agent’s legitimate action space may overlap with reconnaissance, configuration changes, and data access. Defenders will need context about goals, approvals, resources, and execution histories.

The Unit 42 cloud identities proposal provides one part of that context. It creates an empirical description of how an identity behaves among its peers. It does not determine whether the underlying objective was authorized.

For developers, the immediate question is whether deployment and service identities have clear, observable patterns. Teams should review whether audit events can be connected consistently across assumed roles and automation sessions.

Enterprise buyers should ask vendors how functional roles are inferred. They should also request evidence explaining which events drive each classification. “AI-powered anomaly detection” is not enough information for a high-impact security decision.

Security leaders should compare behavioral findings with access reviews. An identity that looks operationally narrow but retains broad permissions represents preventable exposure. An identity that suddenly changes roles represents a potential active threat.

Knowledge workers and AI product users have a related stake. Business applications increasingly connect assistants and agents to company data. Each connection creates an identity whose effective behavior can extend beyond a simple user label.

The next one to three months should reveal whether Palo Alto Networks publishes more validation, expands role coverage, or exposes the logic more directly in customer workflows. Independent testing would strengthen the case further.

Readers should follow three concrete questions: Do the classifiers work on unseen estates, do they transfer beyond AWS, and do they improve analyst decisions? Those answers will determine whether behavioral identity maps become routine security context.

The study’s central judgment already stands: permission documents are necessary, but they are not a complete account of identity risk. Defenders also need evidence of what credentials, workloads, and agents actually do.

Review your own cloud inventory through that lens. Which identities have names and permissions, but no verified behavioral role? The gaps in that answer identify where Unit 42 cloud identities research matters most.