The State of AI in the Cloud 2026: Runtime Security, Attack Paths, and Cloud-Native Resilience

Executive Summary

Artificial intelligence now operates inside the enterprise cloud environment. Models run within managed services, Kubernetes clusters, serverless platforms, API ecosystems, data pipelines, and continuous delivery workflows. AI agents also interact with enterprise systems through machine identities capable of retrieving data, invoking tools, modifying workflows, and initiating business actions.

Enterprise AI introduces a different security challenge. Cloud security must demonstrate how an exposed service, compromised identity, vulnerable workload, or ungoverned data connection could provide a path to a model, privileged control plane, sensitive dataset, or automated business action. Visibility alone is insufficient; security teams need evidence showing how individual exposures combine into an exploitable attack path.

Recent research highlights that challenge. Palo Alto Networks reported that 99% of surveyed organizations experienced an attack targeting an AI application or service during the previous year. The same research found that 41% reported increased API attacks, while 53% identified permissive identity and access management as a leading contributor to data exfiltration risk. These findings do not suggest that AI has created an entirely separate threat landscape. They show that AI increases the operational value of weaknesses already present in cloud architectures, particularly where identities, APIs, workloads, and data remain loosely governed.¹

Operational readiness also remains inconsistent.

Palo Alto Networks found that 89% of organizations believe cloud and application security should operate alongside security operations, yet 30% of teams require more than one day to resolve a cloud incident.¹ For security leaders, this reflects an execution gap rather than a visibility gap. Security programs generate increasing volumes of telemetry, but many organizations still struggle to correlate findings, establish ownership, prioritize response, and authorize containment before business impact occurs.^[1]

A defensible AI cloud security strategy should connect cloud posture management, attack-path analysis, software supply chain security, machine identity governance, data protection, and runtime detection into one operating model. Enterprise resilience depends on how effectively these capabilities work together rather than on the number of alerts generated or security products deployed.

AI Is Becoming Part of the Cloud Control Plane

Enterprise AI is often discussed as an application capability. Operationally, it is becoming part of the cloud control plane.

A production AI service may depend on a public endpoint, gateway, container cluster, model registry, object store, vector database, orchestration service, and several non-human identities. It may retrieve internal information, call third-party models, or trigger actions in downstream business systems. Its risk cannot be understood by assessing each component in isolation.

This is where cloud security posture management reaches its analytical limit. CSPM remains necessary for identifying exposed storage, weak network controls, excessive permissions, and compliance drift. It does not, by itself, determine whether a weakness is reachable, active, or connected to a material business outcome.

Cloud attack path analysis provides the missing connective layer. It maps how external exposure, effective privilege, vulnerabilities, data sensitivity, and workload relationships combine into viable routes to critical assets. For platform and security leaders, that shift matters because it moves prioritization from isolated findings to credible impact scenarios.

From CNAPP Coverage to Buyer-Side Proof

Cloud-native application protection platforms have expanded significantly. A modern CNAPP platform may combine posture management, cloud infrastructure entitlement management, data security posture management, workload protection, infrastructure-as-code scanning, Kubernetes posture management, vulnerability analysis, and cloud detection.

Yet platform consolidation does not create an integrated operating model. Cloud engineering may own infrastructure policy. Product security may manage application defects. AI engineering may control model pipelines. Data governance may classify information. The security operations center may investigate runtime alerts. Unless these teams share asset context and escalation rules, a unified interface can still produce fragmented decisions.

Palo Alto Networks found that 97% of surveyed organizations were prioritizing consolidation of their cloud security footprint. The commercial implication is straightforward: buyers are no longer evaluating platforms only on feature breadth. They increasingly need evidence that a platform can identify which exposures form material attack paths, show which team must act first, and support remediation without creating another disconnected queue. ^[1]

For buyers, the investment question should shift from “Which platform has the broadest coverage?” to “Which platform can prove which exposures create material attack paths and which teams must act first?” This reframing ties CNAPP selection to operating efficiency, incident reduction, and roadmap discipline rather than module count.

Translate Platform Consolidation Into an Executive Security Case

CNAPP consolidation creates value only when it improves prioritization, accountability, and incident response across cloud, application, AI, and security operations. Security leaders therefore need a clear way to connect platform capabilities with material risk reduction, operating-model requirements, and executive investment priorities.

The Executive Whitepaper examines how enterprises can move beyond feature consolidation and build an AI cloud security strategy grounded in attack-path reduction, runtime evidence, ownership, and measurable resilience.

Access the Executive Whitepaper: Building the Business Case for Integrated AI Cloud Security.

Key Finding One: AI Breaches Are Often Access-Control Failures

Model-specific threats, including prompt injection, data poisoning, model theft, and unsafe tool execution, are important. Many AI incidents, however, still begin with familiar cloud weaknesses: exposed services, stolen credentials, excessive permissions, compromised dependencies, or weak application connectors.

IBM reported that 13% of organizations experienced a breach involving an AI model or application, while another 8% did not know whether such a compromise had occurred. Among organizations reporting an AI-related breach, 97% lacked appropriate AI access controls. The consequences included broad data compromise in 60% of incidents and operational disruption in 31%. ^[2]

The security requirement therefore extends beyond controlling who can access an AI application. Leaders must also control what the application, model service, or agent can access after authentication. This makes machine identity governance a budget and architecture priority, not a secondary identity and access management enhancement.

Key Finding Two: Attack Paths Cross Infrastructure, Data, and Model Boundaries

Cloud attack paths rarely depend on one severe weakness. They emerge when several moderate conditions intersect.

Orca Security found that 38% of organizations storing sensitive data in cloud databases had at least one such database exposed to the public internet. It also reported that 32% of cloud assets were in a neglected state, meaning they ran unsupported operating systems or had remained unpatched for more than 180 days. These conditions create a large pool of entry points and lateral movement opportunities. ^[3]

For budget holders, the implication is that remediation capacity should be directed toward connected risk. A critical vulnerability in an isolated development asset may present less immediate risk than a moderate weakness on a route to regulated data or a privileged AI service.

The same principle applies to identity. An excessive permission may appear manageable when reviewed on its own. If that permission belongs to an internet-reachable workload with access to a model registry, sensitive database, or cloud control service, its business significance changes.

Attack-path prioritization gives security and platform leaders a stronger basis for sequencing investment. It also reduces the likelihood that teams spend limited remediation capacity on high-severity findings with no credible route to material impact.

Key Finding Three: Runtime Evidence Is Becoming the Decision Layer

Posture data identifies potential exposure. Runtime evidence establishes which exposures are active, reachable, and relevant to business risk.

Cloud runtime security can determine whether a vulnerable library is executing, whether a workload is communicating with unexpected destinations, whether a service account is operating outside its established baseline, or whether a container has been modified after deployment.

Runtime evidence also improves operational prioritization. A vulnerable component supporting a public AI inference service presents a different level of risk than the same component residing in an inactive development image. Likewise, a permissive workload identity warrants higher priority when runtime telemetry confirms access to sensitive resources beyond its intended business function. By combining runtime behavior with cloud posture, identity context, and attack-path analysis, security teams can prioritize remediation based on observed risk rather than potential exposure alone.

Verizon analyzed 22,052 security incidents and 12,195 confirmed breaches in its 2025 Data Breach Investigations Report. Credential abuse accounted for 22% of known initial access, while vulnerability exploitation accounted for 20%, following a 34% year-over-year increase. For AI cloud environments, these patterns are directly relevant: machine credentials are widespread, while APIs, orchestration components, container images, and development tools create a rapidly changing vulnerability surface. ^[4]

The buyer-side implication is significant. Runtime capability should not be assessed as an additional detection feature. It should be evaluated as the decision layer that determines which posture findings represent active risk, which incidents require immediate containment, and which engineering teams must correct the source condition.

CyberTech Intelligence Perspective: Governance Must Become Enforceable Architecture

AI does not create a separate cloud that can be governed through a parallel security program. It changes the privilege structure, data concentration, application behavior, and operational dependencies of the cloud already in production.

The most consequential design error is separating AI governance from cloud engineering. Governance teams may document model accountability, testing requirements, acceptable use, or human oversight. Engineering teams may continue deploying AI services through established pipelines without translating those requirements into technical controls.

NIST’s Generative Artificial Intelligence Profile reinforces a lifecycle view of risk management. Applied to cloud security, that means governance should be expressed through deployment policy, access control, data restrictions, model and software provenance, logging, monitoring, incident procedures, and retained evidence. ^[5]

Governance maturity should therefore be measured through observable control outcomes. Leaders should be able to confirm who owns an AI workload, which data it can use, which models and dependencies it contains, which identities it operates under, and how its production behavior is monitored.

Without that evidence, governance remains an administrative layer rather than a security control.

Kubernetes and the AI Software Supply Chain Require Joint Control

Kubernetes is a common environment for model serving, retrieval systems, data processing, and GPU-intensive workloads. Its flexibility also creates multiple routes for privilege escalation and lateral movement.

Kubernetes security for AI workloads must address workload identity, network policy, admission controls, image integrity, secrets, and runtime behavior. Shared clusters require particular attention because a weakness in one namespace may create a route to higher-value workloads elsewhere.

The control model should connect source, build, admission, and runtime. Code, dependencies, infrastructure templates, and embedded secrets should be tested before the build. Build systems should be isolated, artifacts signed, and registry access restricted. Admission policies should block noncompliant images, configurations, and identities. Runtime monitoring should detect drift, unexpected execution, credential access, and abnormal network behavior.

DevSecOps security for AI applications therefore requires automated, enforceable controls. Manual review remains valuable for architecture and business logic, but it cannot be the only barrier between generated output and production infrastructure.

This changes the secure software development lifecycle investment. Budgets should move toward controls that can inspect infrastructure code, dependencies, images, model artifacts, and deployment policy at delivery speed, while preserving human review for architecture and high-consequence decisions.

Multi-Cloud Security Is an Operating-Model Decision

AI workloads often span several cloud and software platforms. One provider may host training, and another may support application delivery, while external services provide models, data, observability, or agent tools.

A multi-cloud AI security program should establish consistent outcomes while preserving provider-specific evidence. Every production workload should have an owner, a constrained identity, approved data access, a traceable artifact, and runtime coverage. The implementation can vary by provider; the assurance standard should not.

This distinction should inform roadmap planning. Attempting to force identical controls across providers can create expensive abstraction without equivalent risk reduction. A more practical model defines common assurance requirements, maps them to native services, and centralizes evidence where it improves governance and response.

For buyers, multi-cloud security value should be measured by control consistency and investigation quality. Central visibility matters, but it is insufficient if the platform cannot preserve the identity, network, logging, and service context needed by the teams responsible for remediation.

CyberTech Intelligence Executive Readiness Scorecard

Scoring: 1 = ad hoc, 3 = defined but inconsistent, 5 = integrated and measurable.

10–20: Reactive | 21–35: Developing | 36–43: Operational | 44–50: Resilient

Validate AI Cloud Security Readiness Across the Enterprise

A self-assessment can reveal visible maturity gaps, but executive planning also requires validation across architecture, operating ownership, runtime coverage, machine identity governance, incident response, and control measurement.

The AI Cloud Security Readiness Assessment helps security and technology leaders benchmark current capabilities, identify material control gaps, and establish a prioritized roadmap for improving enterprise resilience.

Request an AI Cloud Security Readiness Assessment

Move From AI Cloud Risk Assessment to a Structured Security Framework

The executive readiness scorecard identifies where AI cloud security capabilities remain fragmented across attack-path analysis, machine identity governance, runtime protection, secure delivery, and multi-cloud control. The next step is to organize these priorities into a repeatable framework that helps security and platform leaders sequence investment, assign ownership, and translate technical exposure into an enterprise security roadmap.

The Ebook expands on this approach by providing a structured framework for connecting AI workload risk, cloud control maturity, runtime evidence, and executive readiness.

Access The Cloud-Native AI Security Playbook: A Practical Guide to Runtime Protection, AI Governance, and Multi-Cloud Security.

An Enterprise AI Cloud Security Roadmap

Establish a Shared Asset and Identity Graph

Maintain a continuously updated relationship map covering models, workloads, APIs, data stores, repositories, pipelines, identities, owners, and downstream tools. Production deployment should not proceed without ownership and data-boundary information.

Prioritize Attack Paths, Not Finding Counts

Combine reachability, effective privilege, runtime use, data sensitivity, exploitability, and business criticality. Highly connected identities and services should receive priority because they can multiply the effect of several moderate weaknesses.

Govern AI Agents as Privileged Workloads

Assign each agent a unique identity. Restrict tools and data by task, use short-lived credentials, retain action logs, and require human approval for actions that can alter infrastructure, transfer sensitive information, or affect customer outcomes.

Make Runtime Detection a Production Requirement

Runtime threat detection should cover containers, Kubernetes, hosts, serverless workloads, APIs, and AI interfaces. Telemetry must support investigation of process activity, identity use, network connections, model interactions, and tool invocation.

Convert Production Findings Into Engineering Corrections

Containment should not end with workload isolation. Teams should trace the weakness to code, infrastructure templates, identity policy, image configuration, or deployment logic, then correct it through the delivery pipeline.

Measure Control Outcomes

Executive reporting should focus on critical attack paths removed, excessive privileges reduced, unowned workloads eliminated, runtime coverage achieved, exceptions closed, and containment time. These measures give budget owners a clearer view of risk reduction than aggregate vulnerability counts.

CyberTech Intelligence Research Desk Observation

The next maturity divide in enterprise cloud security will not be determined by whether an organization has purchased a CNAPP platform. It will be determined by whether shared cloud context is used to govern AI as a production system.

Platform capabilities are converging. Enterprise operating models often are not. A credible test of readiness is whether cloud security, product security, AI engineering, data governance, and security operations can jointly identify a material attack path, assign ownership, contain the exposure, remove its source from the delivery process, and verify that the correction persists.

That cycle provides stronger evidence of resilience than the number of alerts reviewed or findings closed.

Schedule an Executive Cloud Security Strategy Briefing

Bring security, cloud, AI, engineering, and governance priorities into one executive discussion. The strategy briefing helps leadership interpret readiness findings, define investment priorities, establish ownership, and develop a defensible AI cloud security roadmap.

Schedule an Executive Cloud Security Strategy Briefing

Conclusion

AI is changing the composition of cloud risk. It is increasing machine identities, accelerating software delivery, concentrating sensitive data, extending API dependencies, and giving workloads greater operational authority.

These conditions do not make established cloud controls obsolete. They make weakly integrated controls less defensible.

An effective AI cloud security program connects posture to attack paths, attack paths to runtime evidence, runtime evidence to response, and response to engineering correction. It also converts governance from a policy layer into enforceable technical and operational controls.

For US enterprises, the strategic priority is visibility with consequences. Security leaders must be able to see how code, identities, workloads, data, models, and business actions are connected—and determine where that chain can be interrupted before exposure becomes a compromise. Investment decisions should reinforce that capability across architecture, engineering, operations, governance, and incident response.

References

1. Palo Alto Networks (2025) The State of Cloud Security Report 2025. Available at: https://www.paloaltonetworks.com/state-of-cloud-native-security.
2. IBM (2025) Cost of a Data Breach Report 2025. Available at: https://www-api.ibm.com/adobe/assets/urn:aaid:aem:607b9590-38e0-4c91-b433-aa8a17f5b5e8/original/as/cost-of-a-data-breach-2025-full-report.pdf.
3. Orca Security (2025) 2025 State of Cloud Security Report. Available at: https://orca.security/wp-content/uploads/2025/06/2025-State-of-Cloud-Security-Report-v2.pdf.
4. Verizon (2025) 2025 Data Breach Investigations Report. Available at: https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf.
5. National Institute of Standards and Technology (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Available at: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf.