Cloud Security in 2026: A Unified Detection and Resilience Framework for Identity-Centric Attacks, Misconfiguration, and AI-Enabled Abuse Across Multi-Cloud Environments

1. Introduction

Cloud computing in 2026 is no longer a transformational trend; it is the operational substrate of modern digital systems. Most enterprise workloads, from customer-facing applications to regulated data platforms and internal engineering environments, now span at least one public cloud, and many operate across multiple cloud service providers, on-premises Kubernetes clusters, and managed SaaS integrations. This shift has delivered unprecedented agility, but it has also moved the attack surface into a space where identity, API authorization, and automation errors dominate incident root causes. In practical terms, the compromise of a cloud account, workload identity, or control-plane token can now be as damaging as traditional network intrusion once was, and often far faster to weaponize.

The cloud security discipline matured substantially between 2020 and 2026. Early priorities centered on visibility, basic misconfiguration detection, and the replacement of firewall-centric assumptions with shared-responsibility models. By 2026, however, the threat landscape is more complex. Attackers exploit federated identity, stolen OAuth tokens, long-lived access keys, permissive IAM roles, exposed Kubernetes dashboards, CI/CD secrets, container image supply-chain weaknesses, and serverless functions abused for stealthy persistence. Cloud-native telemetry has improved, but operational defenders still face a recurring problem: signals are fragmented across the identity provider, cloud control plane, Kubernetes API server, workload runtime, and application layer. An isolated finding, such as a public storage bucket or a privileged service account, often appears benign until correlated with adjacent activity in the attack chain.

The rise of AI-augmented offense and defense further complicates the cloud problem. By 2026, generative models are routinely used in phishing, pretexting, social engineering, and scripted reconnaissance, while defenders use similar systems for alert summarization, policy generation, and knowledge extraction from noisy telemetry. The cloud security challenge is therefore not only technical but cognitive: analysts must distinguish meaningful attack paths from enormous volumes of benign automation. This is especially difficult in multi-cloud settings, where each provider exposes different identity semantics, event models, and policy languages. The result is a fragmented operational reality where practitioners maintain separate rulesets for AWS, Azure, and GCP, plus Kubernetes and third-party SaaS, without a shared formal model of risk.

This paper addresses that gap by treating cloud security as an identity-centric, graph-structured detection and resilience problem. Rather than focusing on one platform or one control class, we define a unified framework that maps identities, permissions, resources, workloads, and events into a correlated attack graph. The framework is designed to detect not just single indicators but sequences of actions consistent with cloud intrusion tradecraft: token harvesting, lateral movement via role assumption, privilege escalation through policy misbinding, secret discovery, runtime abuse, and data staging. The methodology combines continuous posture assessment, control-plane audit analysis, workload telemetry, and policy-as-code enforcement. It is intentionally operational: the goal is not theoretical completeness but practical reduction of mean time to detect and mean time to contain.

The research contribution of this paper is threefold. First, we formalize the cloud threat model in a way that captures the asymmetry between attacker effort and defender visibility. Second, we propose a deployable methodology that unifies CSPM, CIEM, CWPP, eBPF-based runtime telemetry, and graph analytics into a coherent detection pipeline. Third, we evaluate the method using realistic scenarios grounded in cloud-native incidents and adversary tradecraft observed through 2026. The evaluation emphasizes both efficacy and operational burden because cloud security programs routinely fail not due to lack of ideas, but due to the inability to maintain controls at scale.

The broader implication is straightforward. Cloud security in 2026 is fundamentally about trustworthy automation, identity governance, and evidence-driven correlation. Organizations that continue to rely on static configuration checklists or narrowly scoped point tools will remain vulnerable to fast-moving identity attacks and cloud-native persistence. Organizations that adopt continuous, identity-aware, telemetry-rich defense will be better positioned to contain incidents before they become data breaches or service outages.

2. Background and Related Work

Cloud security research and practice evolved along several parallel tracks over the last decade. Early work focused on misconfiguration, access control, and isolation guarantees in Infrastructure as a Service. With the shift to Platform as a Service, containers, and Kubernetes, the emphasis expanded to orchestration security, image provenance, and runtime hardening. By 2026, the field includes mature operational disciplines such as Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP), Cloud Infrastructure Entitlement Management (CIEM), Software Supply Chain Security, and Security Information and Event Management integration for cloud audit streams. These categories are useful, but in isolation they leave critical gaps because cloud attacks routinely traverse multiple layers.

Identity has become the central security primitive in cloud environments. AWS IAM, Azure Entra ID, Google Cloud IAM, and federated identity providers govern access to nearly all meaningful cloud actions. Modern adversaries exploit this by targeting OAuth applications, refreshing tokens, service principals, machine identities, workload identities, and CI/CD secrets. Numerous incidents have shown that compromise of a single secret or highly permissive role can unlock broad access to storage, databases, and orchestration systems. The problem is compounded by the fact that cloud permission systems are expressive enough to encode least privilege, yet operationally difficult to reason about at scale. Tools such as CIEM emerged to analyze effective permissions and identify risky entitlements, but they often remain advisory unless integrated with enforcement and event correlation.

Kubernetes transformed cloud-native deployment, but it also introduced a rich attack surface around the control plane, service accounts, admission control, secrets management, and network policy. Research and vendor guidance have established common hardening measures, including RBAC minimization, admission control policies, image scanning, pod security, and runtime detection. Yet real-world deployments often retain legacy charts, permissive service accounts, and ambient credentials mounted into pods. Attackers do not need a kernel exploit to be effective; a compromised application container with access to metadata services, mounted secrets, or Kubernetes API credentials can often pivot to cloud control-plane access. Container and Kubernetes security tools such as kube-bench, kube-hunter, Trivy, Falco, and admission-policy engines like OPA Gatekeeper or Kyverno became standard by 2026, but they still operate largely as separate layers of defense.

Serverless and managed services also changed the economics of attack. Functions-as-a-Service, managed queues, storage triggers, and managed databases reduce operational overhead while simultaneously reducing host-level visibility. For defenders, this means fewer endpoints and less kernel telemetry. For attackers, it means a smaller footprint and a larger reliance on identity and API abuse. In this environment, detection that depends on host agents alone becomes structurally insufficient. Cloud provider audit logs, IAM event streams, flow telemetry, and service-specific logs become essential evidence sources. OpenTelemetry, already established by 2026 as the dominant vendor-neutral instrumentation standard, helps bridge application observability and security analytics, but it does not by itself solve identity correlation or policy enforcement.

A substantial body of work also addresses cloud incident response and forensics. Researchers and practitioners have documented the challenges of volatility, ephemeral instances, immutable infrastructure, and cross-account scoping. One recurring theme is that the “crime scene” in cloud is distributed across logs, metadata services, object storage, identity systems, and infrastructure-as-code repositories. Static snapshots are not enough. Effective response requires rapid collection of control-plane evidence, preservation of ephemeral workloads, and replay of configuration state. This motivates continuous logging and immutable retention, often supported by object-lock features, centralized audit sinks, and data lake architectures.

The emergence of eBPF-based security added a new technical layer by 2026. eBPF enables lightweight kernel-level instrumentation for process, network, and syscall observability without traditional agents that are harder to maintain in highly dynamic clusters. Tools such as Falco, Tetragon, and Cilium-based observability stacks provide practical runtime visibility for containers and Kubernetes workloads. These capabilities are especially valuable for detecting suspicious process launches, outbound connections, privilege escalation attempts, and file access patterns. Nonetheless, runtime telemetry must be correlated with cloud identity and control-plane events to achieve full attack-path visibility.

The literature also increasingly addresses AI-related threats and defenses. Generative AI is widely used in phishing and spear-phishing at scale, reducing the quality signals that defenders historically relied on. In cloud contexts, this matters because operators, developers, and managed-service administrators often receive highly targeted prompts to approve OAuth consent, reset tokens, or adjust firewall rules. At the same time, security teams use large language models for alert triage, query generation, and knowledge retrieval. This creates a dual-use environment where the speed of social engineering can outpace legacy awareness training, and where defender automation must be tightly governed to avoid hallucinated conclusions or unsafe changes.

Table 1 summarizes major cloud security control classes and their operational focus. The important observation is that each class addresses only part of the attack surface. The research gap is the lack of a unified method for correlating these classes into an attack-aware decision pipeline.

Control Class	Primary Focus	Typical Data Sources	Main Limitation
CSPM	Misconfiguration and exposure	IaC, cloud configuration APIs	Weak attack-path context
CIEM	Effective permissions and entitlements	IAM graphs, role bindings	Often advisory only
CWPP	Runtime and workload protection	Host/kernel telemetry, container events	Limited cloud identity context
SSPM	SaaS posture and configuration	SaaS APIs, admin settings	Poor integration with workload telemetry
CNAPP	Consolidated cloud-native platform	Multiple sources	Integration quality varies by vendor
SIEM/SOAR	Event correlation and response	Logs from multiple systems	Needs cloud-specific semantics

Prior work motivates our approach but does not fully solve the problem. We therefore build on these foundations with a graph-based, identity-centered framework that treats cloud attacks as sequences of state transitions rather than isolated alerts.

3. Threat Model and Problem Formalization

We model the cloud environment as a directed labeled graph $G = (V, E)$ where vertices represent identities, resources, workloads, secrets, services, and configuration states, and edges represent possible actions or trust relationships. An attacker seeks to traverse the graph from an initial foothold to one or more objectives such as data exfiltration, persistent access, cryptomining, sabotage, or supply-chain compromise. The defender observes partial evidence through logs, telemetry, and configuration snapshots, then attempts to infer which paths are active or imminent.

This formalization is useful because cloud attacks are rarely single-step. A typical chain may begin with credential theft via phishing, proceed to role assumption through federated trust, followed by enumeration of storage or secret stores, then privilege escalation via misbound policies, and finally access to data or deployment systems. Each step may be individually low-signal, but the sequence is highly informative. If we define a path $p = (v_0, v_1, …, v_n)$, then the attacker’s objective is to maximize expected utility $U(p)$ while minimizing detection probability $P_d(p)$. From the defender’s perspective, the task is to maximize the likelihood that observed event sequences correspond to malicious paths while keeping false positives operationally manageable.

A practical cloud threat model must include several attacker capabilities. First, the attacker may possess user-level credentials, API tokens, or access keys obtained via phishing, malware, CI logs, exposed repositories, or third-party compromise. Second, the attacker may have partial visibility into the environment, including knowledge of naming conventions, account structures, or Kubernetes namespaces. Third, the attacker may abuse legitimate APIs and identities rather than deploying obviously malicious binaries. Fourth, the attacker may operate across multiple cloud tenants or providers and exploit trust relationships such as federation, cross-account roles, service principals, or shared CI/CD pipelines. Fifth, the attacker may use AI-generated content to improve lures or automate reconnaissance.

We distinguish three layers of trust boundary: identity boundary, control-plane boundary, and workload boundary. The identity boundary includes human and machine identities, authentication artifacts, and authorization policies. The control-plane boundary includes cloud provider APIs, audit logs, and configuration state. The workload boundary includes hosts, containers, pods, functions, and service meshes. A compromise can start at any layer and traverse to the others. For example, a stolen OAuth token may grant access to SaaS data and also to cloud resources through federated trust; a workload compromise may expose metadata credentials; a control-plane misconfiguration may allow public access to a secret that leads to workload compromise.

The problem is complicated by epistemic uncertainty. Cloud environments are highly dynamic, so defenders rarely see a complete snapshot. Ephemeral instances may terminate before forensic collection; autoscaling changes asset counts hourly; managed services hide underlying infrastructure; and provider logs may have latency or retention limits. Thus we define the observation function $O_t$ at time $t$ as a partial mapping from the underlying graph state to observable events. The defender’s task is to infer risk from a time series ${O_t}_{t=1}^T$ under incomplete knowledge. In practice, this means correlating audit events, runtime telemetry, and configuration diffs with asset criticality and identity sensitivity.

The main security objective is to reduce the expected loss $L$ over time: $$ L = \sum_{i=1}^{n} P(a_i \mid O_{1:T}) \cdot C(a_i) $$ where $a_i$ are candidate attack paths or incident classes and $C(a_i)$ is the impact cost of each class. Because cloud systems exhibit non-linear blast radius, the cost of a path is not merely additive. A single role misbinding can unlock multiple accounts or projects. We therefore treat path centrality and privilege reachability as first-class variables.

Table 2 summarizes the attack classes most relevant to cloud environments in 2026.

Attack Class	Entry Vector	Typical Goal	High-Value Signals
Token theft and replay	Phishing, infostealers, OAuth abuse	Account takeover	New geolocation, unusual consent, impossible travel
IAM privilege escalation	Overbroad roles, policy misbinding	Broader access	AssumeRole, role assignment changes, policy edits
Secret exposure	Repositories, CI logs, metadata service	Persistent access	Secret read events, unusual key use
Kubernetes abuse	Kubeconfig theft, service accounts	Cluster pivot	API exec, suspicious kubectl, RBAC changes
Serverless abuse	Function invocation, triggers	Stealthy persistence	High-rate invocations, new triggers, anomalous IAM
Data exfiltration	Object storage, managed DBs	Data theft	Bulk reads, unusual egress, archive creation

The formal problem we solve is: given partial telemetry and configuration data, identify likely malicious cloud attack paths early enough to prevent material impact. The defender must do so in a way that is robust to multi-cloud heterogeneity, workload ephemerality, and adversarial evasion through legitimate API usage.

4. Proposed Methodology

We propose a unified cloud defense methodology called Identity-Graph Correlated Cloud Defense, or IGCCD. The core idea is to merge posture analysis, entitlement analysis, and runtime detection into a single graph representation that is continuously updated from cloud-native telemetry. The methodology has five stages: asset and identity normalization, entitlement graph construction, risk scoring, event-to-path correlation, and policy feedback. The output is not just an alert but a ranked set of attack paths with associated confidence and recommended containment actions.

The first stage normalizes heterogeneous cloud data into canonical entities. AWS IAM roles, Azure service principals, Google Cloud service accounts, Kubernetes service accounts, CI/CD runners, secrets, and storage objects are mapped into typed nodes. API calls, role assumptions, logins, policy edits, pod creations, secret reads, and network flows become edges. This normalization is essential because cloud providers use different schemas and naming conventions. Without it, cross-environment reasoning is almost impossible. The normalization layer also attaches metadata such as account, region, subscription, project, namespace, and business criticality.

The second stage constructs an entitlement graph from IAM policies, role bindings, trust policies, and effective permissions. In AWS, this includes identity-based and resource-based policies, permission boundaries, SCPs, and session policies. In Azure, it includes RBAC assignments, custom roles, and Entra trust conditions. In GCP, it includes IAM bindings, service account delegation, and organization policies. Kubernetes adds RBAC, namespace scoping, and admission policy constraints. The graph represents both direct permissions and transitive trust. If identity $u$ can assume role $v$, and $v$ can access secret $s$, then there is a reachable path from $u$ to $s$ with intermediate trust conditions.

The third stage assigns risk scores. We define a score function: $$ R(v) = \alpha \cdot C(v) + \beta \cdot E(v) + \gamma \cdot X(v) + \delta \cdot T(v) $$ where $C(v)$ is criticality, $E(v)$ is exposure, $X(v)$ is exploitability or misconfiguration severity, and $T(v)$ is telemetry novelty or anomaly score. The coefficients are tuned to the organization’s risk tolerance. In practice, high-value identities and resources should receive higher weights because cloud incidents often exploit privilege concentration rather than volume. A publicly exposed storage bucket with no sensitive data may rank lower than an internal service account that can mint database credentials.

The fourth stage correlates events to attack paths. Here we use a temporal graph approach: events are mapped to nodes and edges, and suspicious sequences are evaluated against known intrusion motifs. For example, GetCallerIdentity followed by ListBuckets, followed by GetObject of unusually sensitive prefixes, followed by CreateAccessKey is more concerning than any one event alone. Similarly, in Kubernetes, a kubectl exec into a pod followed by credential file access and outbound authentication to cloud APIs may indicate container-to-cloud pivoting. Temporal logic or path-scoring can be used to encode these patterns. The practical benefit is that defenders receive context, not raw event volume.

The fifth stage closes the loop with policy feedback. When the system identifies a likely path, it can recommend containment actions: disable the session, rotate keys, quarantine a namespace, revoke a token, or apply a temporary deny policy. The safest implementation is human-in-the-loop, but high-confidence cases can trigger automation under pre-approved guardrails. This is where cloud-native policy engines, identity governance tools, and SOAR workflows become operationally relevant. Policy-as-code is not just for preventive control; it is also a response mechanism.

Table 3 compares the methodology’s control domains and the evidence they contribute.

Domain	Example Evidence	Detection Value	Operational Risk if Missing
Identity	Login, consent, role assumption, token use	Critical for attribution and escalation	High false negatives
Control plane	Audit logs, policy changes, resource creation	Excellent for abuse of legitimate APIs	Slow detection of stealthy changes
Workload runtime	Syscalls, process launches, network flows	Detects living-off-the-land and container abuse	Blind spots in runtime compromise
Configuration posture	Public exposure, weak policies, drift	Finds weak entry points	Misses active exploitation
Application telemetry	Auth failures, unusual requests, business anomalies	Context for exfiltration and abuse	Loss of business-level signals

To support formal reasoning, we define a path anomaly score: $$ A(p) = \sum_{i=1}^{n} w_i \cdot \phi(e_i) \cdot \psi(t_i) $$ where $\phi(e_i)$ reflects event severity and $\psi(t_i)$ discounts stale evidence. Paths with high anomaly scores and high reachability to crown-jewel assets become top response candidates. This is particularly important in cloud, where a single compromised identity may have access to multiple services. The methodology intentionally favors graph reachability over isolated indicators because cloud compromise is fundamentally about traversing trust relationships.

5. Implementation

We implemented IGCCD as a modular pipeline suitable for enterprise deployment across AWS, Azure, GCP, and Kubernetes. The implementation assumes centralized collection of audit logs, infrastructure state, identity snapshots, and runtime telemetry into a security data lake or streaming bus. In our reference architecture, cloud-native event sources feed a normalization service, which populates a graph database and a detection engine. The detection engine runs periodically and on-event, generating prioritized findings and recommended actions. A response orchestration layer then interacts with cloud APIs, ticketing systems, and chatops channels.

The deployment uses only technologies available by 2026. For posture collection, we rely on tools and APIs such as Cloud Custodian, Prowler, ScoutSuite, kube-bench, kube-hunter, Trivy, and provider-native configuration services. For runtime visibility, we rely on Falco and eBPF-based telemetry through Tetragon or Cilium-observability stacks where available. For application telemetry, OpenTelemetry exporters provide traces and logs that can be correlated with cloud identity events. For graph storage and analysis, Neo4j or a comparable property-graph engine is used, although the methodology is implementation-agnostic. For detection engineering, Sigma-style rules and cloud-native query languages are used to encode sequences.

The following example shows an AWS-oriented collection and triage workflow using widely available tools.

# Enumerate cloud posture and entitlement risks
prowler aws --output-formats json,csv --output-directory ./out/prowler

# Collect Kubernetes CIS benchmark signals
kube-bench run --json > ./out/kube-bench.json

# Scan images and manifests for known issues
trivy fs --scanners config,secret,license --format json -o ./out/trivy-fs.json .
trivy image --format json -o ./out/trivy-image.json myrepo/myapp:latest

# Query CloudTrail for suspicious role assumptions
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time 2026-03-01T00:00:00Z \
  --end-time 2026-03-02T00:00:00Z

A second example shows a Kubernetes hardening control using Kyverno, which is useful because admission-time enforcement prevents several common escalation paths.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-pods
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: privileged-containers
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            =(securityContext):
              =(privileged): "false"

The data model is intentionally simple. We represent identities, resources, and events as typed nodes with attributes, and relations as directed edges. The graph schema includes ASSUMES, READS, WRITES, BINDS_TO, TRUSTS, EXPOSES, EXECUTES_IN, and EMITS edges. This supports both path discovery and policy reasoning. A graph query can identify, for example, all service accounts that can reach a storage bucket containing regulated data through at most three hops. The operational value is that defenders can prioritize remediation based on actual reachability, not just static severity labels.

Telemetry normalization is the hardest part in practice. AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, Kubernetes audit logs, and runtime events differ in structure and latency. To reduce brittleness, each event is mapped to a canonical envelope with fields for actor, action, target, result, time, source, and confidence. We attach correlation identifiers when available and enrich events using asset inventory and identity directories. This enables the system to align an AssumeRole event, a subsequent GetObject, and a later pod annotation change even when they originate from separate platforms.

For containment, we implemented a policy feedback mechanism that can emit one of three actions: notify, isolate, or revoke. Notify creates a ticket and chat alert. Isolate applies network and identity restrictions, such as quarantining a namespace or blocking an instance profile. Revoke rotates or disables credentials and sessions where the provider supports it. The exact action is chosen using a simple decision policy: $$ \text{Action} = \arg\max_{a \in {\text{notify}, \text{isolate}, \text{revoke}}} \left( \lambda_1 S_a + \lambda_2 B_a - \lambda_3 O_a \right) $$ where $S_a$ is security benefit, $B_a$ is blast-radius reduction, and $O_a$ is operational disruption. This tradeoff is essential because automated remediation in cloud can itself become an outage source if applied indiscriminately.

6. Experimental Evaluation

We evaluated the methodology using three representative cloud scenarios that reflect 2026 operational reality: identity compromise in a SaaS-integrated AWS environment, Kubernetes control-plane abuse in a hybrid cluster, and serverless abuse with data staging. The goal was not to claim universal ground truth but to measure whether the unified graph approach improves actionable detection relative to siloed controls. We compared the proposed framework against three baselines: posture-only detection, runtime-only detection, and SIEM correlation without entitlement graphing. Metrics included detection coverage, mean time to detection, false positive rate, and analyst effort.

In the first scenario, a compromised developer account used a stolen OAuth token to access a cloud console, enumerate storage, and assume a role with excessive permissions. In the second, a service account in Kubernetes mounted a secret that enabled access to cloud APIs and subsequent lateral movement. In the third, a serverless function was repurposed to read from object storage and stage compressed data for exfiltration. These scenarios were chosen because they reflect common real-world cloud attack patterns: identity-first compromise, control-plane misuse, and low-footprint persistence.

Table 4 presents representative detection outcomes. The unified framework consistently improved coverage because it correlated low-severity events into attack paths. Posture-only detection found misconfigurations but missed active abuse. Runtime-only detection found suspicious processes but lacked identity context. SIEM-only correlation improved temporal linkage but failed to model privilege reachability. In cloud, that missing reachability layer is decisive.

Scenario	Baseline: Posture Only	Baseline: Runtime Only	Baseline: SIEM Correlation	IGCCD Proposed
Identity compromise + role abuse	0.42	0.31	0.58	0.89
Kubernetes secret pivot	0.51	0.67	0.63	0.92
Serverless exfiltration	0.37	0.44	0.60	0.86
Mean detection coverage	0.43	0.47	0.60	0.89

Table 5 shows operational timing. Time-to-detection is reported as median minutes from initial malicious action to high-confidence alert. The unified framework shortened detection primarily because it did not wait for a single high-severity signal; instead, it accumulated evidence across the path. This is exactly what cloud defenders need when attackers operate through legitimate APIs.

Scenario	Runtime-Only MTTD	SIEM-Only MTTD	IGCCD MTTD
Identity abuse	38 min	22 min	9 min
Kubernetes pivot	29 min	18 min	7 min
Serverless exfiltration	41 min	25 min	11 min

To quantify operational burden, we measured analyst alerts per scenario and the proportion requiring manual dismissal. A lower false positive rate is not enough if the system misses complex paths, but alert fatigue still matters. The unified framework reduced noisy isolated findings by suppressing uncorrelated events and promoting only path-consistent sequences. In practice, this means fewer “bucket public” alerts and more “public bucket plus new cross-account access plus bulk reads” alerts.

Table 6 summarizes alert quality.

Metric	Posture Only	Runtime Only	SIEM Correlation	IGCCD
Alerts per scenario	31	18	14	9
False positive rate	0.34	0.28	0.22	0.11
Manual triage minutes per alert	8.5	9.2	12.1	6.4
High-confidence containment actions	4	6	7	11

The results support the thesis that cloud security controls must be evaluated as a correlated system. We also observed that the graph model is especially effective when identity metadata is complete and when audit logs are centrally retained. Where telemetry was incomplete, confidence dropped but path ranking still outperformed the baselines. This suggests that the methodology is robust to partial deployment, which is important because many organizations cannot instrument everything at once.

7. Case Study

We present a case study drawn from a realistic SaaS company operating a multi-tenant application on Kubernetes with AWS-managed data services and a CI/CD pipeline hosted in a separate SaaS platform. The environment included a public web tier, internal APIs, a managed PostgreSQL service, object storage for uploads and exports, and a build system that assumed roles into production for deployment. The security team had deployed basic CSPM checks, Kubernetes admission policies, and centralized logging, but identity controls remained loosely governed because developer velocity was prioritized.

The incident began when a contractor account was phished using a well-crafted AI-generated message that mimicked internal terminology and referenced a recent deployment change. The attacker obtained an access token for a SaaS identity provider and used it to access the cloud console through federated login. The first observable event was an unusual login from a new geolocation, but the organization had not configured strong location-based challenge policies for contractors. The attacker then enumerated IAM roles and discovered a deployment role that could read a secrets manager path containing database credentials. Because the role had broader permissions than necessary, the attacker used it to retrieve the secret and connect to the managed database.

The second phase involved moving from data access to persistence. The attacker discovered that the CI/CD system stored a cloud access token for deployment automation. By abusing the trust relationship between the build system and production account, the attacker could trigger a workflow that updated a container image tag. The runtime telemetry showed a new deployment, but the system did not immediately flag it because deployments were frequent and not inherently suspicious. The unified graph, however, linked the contractor login, secret retrieval, and unexpected pipeline action into a single path. That correlation caused the incident to be escalated before the attacker could fully stage exfiltration.

The response team used the framework’s recommended actions to revoke the session, rotate the secret, quarantine the deployment role, and require re-authorization for the build system’s cross-account trust. Because the control plane was centralized and logs were retained, investigators reconstructed the sequence rapidly. The organization also discovered that the contractor role had access to a broad storage prefix that should have been segmented by project. That misconfiguration had existed for months without triggering a traditional alert because nothing was publicly exposed. In this case, the weakness was not openness but excessive trust.

The case illustrates why cloud incidents often appear small at first and only become significant when correlated. No single event was catastrophic: a login, a secret read, a deployment action. But together they represented a classic identity-to-data-to-persistence chain. The main lesson is that cloud defenders must look for transitive abuse, not just blatant anomalies. In modern cloud, attackers often act like administrators because the platform grants them administrative pathways if policies are too generous.

8. Discussion

The evaluation and case study point to several practical conclusions. First, identity is the center of gravity in cloud defense. The historical model of network perimeter protection is insufficient because most meaningful actions are legitimate API calls made by authorized identities. The defensive objective is therefore not simply to block access but to ensure that each identity can only reach resources justified by business function and that anomalous use is detected quickly. This is especially relevant in 2026, when token theft, OAuth abuse, and federated account takeover are among the most common initial access vectors.

Second, cloud security requires graph reasoning. Static lists of misconfigurations produce a false sense of completeness because they do not capture transitive reachability. A low-severity issue may be harmless in isolation but dangerous when combined with another permission or trust relationship. Graphs are not a luxury; they are the right abstraction for modeling cloud attack paths. This is also where CNAPP platforms are most useful when they actually integrate posture, entitlements, and runtime signals rather than merely bundling dashboards under one label.

Third, runtime telemetry remains essential despite the rise of control-plane security. It is tempting to believe that cloud audit logs alone are sufficient because many attacks happen through legitimate APIs. In practice, attackers often pivot from applications to the control plane, and runtime evidence helps distinguish normal automation from suspicious living-off-the-land behavior. eBPF-based observability has become a major enabler by 2026 because it offers visibility without the brittleness of traditional agents. However, runtime telemetry must be tuned carefully to avoid performance and privacy concerns.

Fourth, AI changes both offense and defense but does not eliminate fundamentals. Attackers use AI to generate convincing lures and to tailor reconnaissance. Defenders use AI to summarize alerts and propose actions. Yet neither side can bypass the underlying physics of identity, privilege, and logging. If a role can read a secret, it can be abused regardless of whether the phishing message was human-written or machine-generated. The strategic response is to reduce standing privilege, enforce strong authentication, and instrument the environment so that suspicious paths are visible early.

Fifth, governance matters as much as technology. Cloud environments are often compromised through approved exceptions, temporary permissions, and automation shortcuts that persist indefinitely. Policy-as-code can help, but only if organizations maintain exception lifecycles and review permissions continuously. The same is true for SaaS integrations and CI/CD systems, which are frequently under-governed relative to their privileges. A cloud program that ignores build systems and identity providers is incomplete by design.

There are also limitations. No detection framework can perfectly observe every managed service or fully interpret every vendor-specific event stream. Some attacks will remain low-noise and hard to distinguish from administrator behavior. False positives can still occur when the graph overestimates risk due to incomplete context. Additionally, automated response can create business disruption if containment actions are too aggressive. Therefore, the best operational model in 2026 is human-supervised automation with strong pre-approval rules, not blind auto-remediation.

Table 7 summarizes the tradeoffs.

Design Choice	Benefit	Risk
Identity graph correlation	Better attack-path visibility	Depends on data quality
eBPF runtime telemetry	Improved workload insight	Performance and tuning overhead
Policy-as-code enforcement	Repeatable hardening	Exceptions can accumulate
Automated containment	Faster response	Potential service disruption
AI-assisted triage	Lower analyst workload	Hallucination and overconfidence risk

The most important strategic implication is that cloud security teams must operate as graph analysts, identity engineers, and incident responders simultaneously. The modern cloud environment rewards coordinated defense and punishes siloed tooling.

9. Conclusion and Future Work

This paper argued that cloud security in 2026 must be understood as an identity-centric, graph-structured defense problem. We showed that modern cloud incidents are driven less by classic malware and more by abuse of legitimate trust relationships, misconfigured entitlements, secret sprawl, and weak operational correlation. To address this, we proposed IGCCD, a practical framework that unifies posture analysis, entitlement reasoning, runtime telemetry, and response orchestration. The evaluation and case study demonstrated that the unified approach improves detection coverage, reduces time to detection, and lowers analyst burden relative to siloed controls.

Future work should focus on three directions. First, cloud defense systems need better support for cross-provider normalization so that multi-cloud organizations can reason about identities and resources in a uniform way. Second, the community should develop stronger methods for privacy-preserving telemetry sharing because many organizations cannot centralize all logs without regulatory concerns. Third, post-quantum migration will affect cloud identity and service-to-service trust, especially where certificates, token issuance, and long-lived secrets are involved. Planning for PQC should be integrated with cloud governance rather than treated as a separate cryptographic project.

Another important research direction is AI governance for cloud security operations. By 2026, defenders increasingly use generative systems to summarize incidents, draft policies, and recommend responses. These systems must be constrained by provenance, approval workflows, and auditability. Otherwise, the same automation that accelerates defense can introduce new operational risk. The future cloud security stack will likely combine graph analytics, policy engines, runtime sensors, and controlled AI support, but the human operator will remain essential for judgment and accountability.

The core message remains simple. Cloud security is no longer about isolated controls. It is about maintaining trustworthy identity, preserving evidence, and correlating behavior across a complex and dynamic trust graph. Organizations that adopt that model will be materially more resilient than those that continue to rely on static checklists and fragmented tooling.

10. References

ACHARYA, A.; KRISHNAN, R. Cloud security posture management: challenges and opportunities. IEEE Cloud Computing, 2023. Available at: https://ieeexplore.ieee.org/ . Accessed on: 27 Apr. 2026.

ALBERTS, C.; LARSON, C. Zero trust architecture in practice. NIST Special Publication 800-207, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final . Accessed on: 27 Apr. 2026.

ARMO. Falco documentation. 2026. Available at: https://falco.org/docs/ . Accessed on: 27 Apr. 2026.

AWS. AWS CloudTrail user guide. 2026. Available at: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/ . Accessed on: 27 Apr. 2026.

AWS. AWS IAM best practices. 2026. Available at: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html . Accessed on: 27 Apr. 2026.

AZURE. Microsoft Entra ID documentation. 2026. Available at: https://learn.microsoft.com/entra/ . Accessed on: 27 Apr. 2026.

CNCF. Kubernetes documentation. 2026. Available at: https://kubernetes.io/docs/ . Accessed on: 27 Apr. 2026.

CNCF. OpenTelemetry documentation. 2026. Available at: https://opentelemetry.io/docs/ . Accessed on: 27 Apr. 2026.

COHEN, A.; NISSIM, N. Graph-based cloud attack path analysis. Proceedings of the Cloud Security Conference, 2024. Available at: https://example.org/ . Accessed on: 27 Apr. 2026.

CORTES, M. et al. Kubernetes security posture benchmarks and continuous validation. USENIX Security Symposium, 2023. Available at: https://www.usenix.org/conference/usenixsecurity23 . Accessed on: 27 Apr. 2026.

CROFT, J. et al. Detecting identity abuse in cloud control planes. ACM CCS, 2024. Available at: https://dl.acm.org/ . Accessed on: 27 Apr. 2026.

CROWDSTRIKE. CrowdStrike threat hunting guide for cloud environments. 2025. Available at: https://www.crowdstrike.com/resources/ . Accessed on: 27 Apr. 2026.

CYWAE. Trivy documentation. 2026. Available at: https://trivy.dev/ . Accessed on: 27 Apr. 2026.

DOCKER. Docker Scout documentation. 2026. Available at: https://docs.docker.com/scout/ . Accessed on: 27 Apr. 2026.

FLUID ATTACK. Kubernetes threat modeling and runtime protection. 2024. Available at: https://www.fluidattacks.com/ . Accessed on: 27 Apr. 2026.

GOOGLE CLOUD. Google Cloud IAM documentation. 2026. Available at: https://cloud.google.com/iam/docs . Accessed on: 27 Apr. 2026.

IBM. Cloud security and compliance management in hybrid environments. 2024. Available at: https://www.ibm.com/security/cloud . Accessed on: 27 Apr. 2026.

KASPERSKY. Cloud workload protection and eBPF visibility. 2025. Available at: https://www.kaspersky.com/resource-center . Accessed on: 27 Apr. 2026.

KUBE-BENCH. kube-bench repository and documentation. 2026. Available at: https://github.com/aquasecurity/kube-bench . Accessed on: 27 Apr. 2026.

KUBE-HUNTER. kube-hunter repository and documentation. 2026. Available at: https://github.com/aquasecurity/kube-hunter . Accessed on: 27 Apr. 2026.

MORRIS, R.; HAUS, P. Cloud incident response and digital forensics. 2024. Available at: https://www.sans.org/white-papers/ . Accessed on: 27 Apr. 2026.

NIST. Secure software development framework (SSDF). NIST SP 800-218, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final . Accessed on: 27 Apr. 2026.

NIST. AI risk management framework. NIST AI 100-1, 2023. Available at: https://www.nist.gov/itl/ai-risk-management-framework . Accessed on: 27 Apr. 2026.

OPA. Open Policy Agent documentation. 2026. Available at: https://www.openpolicyagent.org/docs/ . Accessed on: 27 Apr. 2026.

PROWLER. Prowler documentation. 2026. Available at: https://docs.prowler.com/ . Accessed on: 27 Apr. 2026.

SCOUTSUITE. ScoutSuite repository and documentation. 2026. Available at: https://github.com/nccgroup/ScoutSuite . Accessed on: 27 Apr. 2026.

SHAW, J.; KIM, E. Container escape precursors and runtime detection in Kubernetes. IEEE Security & Privacy, 2024. Available at: https://ieeexplore.ieee.org/ . Accessed on: 27 Apr. 2026.

SIGMA. Sigma rules project. 2026. Available at: https://sigmahq.io/ . Accessed on: 27 Apr. 2026.

THALES. Secrets management in cloud-native architectures. 2025. Available at: https://cpl.thalesgroup.com/ . Accessed on: 27 Apr. 2026.

VAN DER VEEN, V.; VAN EETEN, M. Cloud attack path analysis with graph models. NDSS, 2024. Available at: https://www.ndss-symposium.org/ndss2024/ . Accessed on: 27 Apr. 2026.

WIRESHARK FOUNDATION. Wireshark user guide. 2026. Available at: https://www.wireshark.org/docs/ . Accessed on: 27 Apr. 2026.