In 2025, the enterprise risk landscape experienced a paradigm shift: the adoption of AI and LLMs officially becoming the primary driver of cloud risk. Today, almost 88% of organizations now leverage AI in at least one business function. With this level of integration, the risk of AI is now outpacing traditional security guardrails, culminating in a highly complex and interconnected attack surface.

SentinelOne’s® new AI and Cloud Verified Exploit Paths and Secrets Scanning Report examines this evolving threatscape and draws on telemetry from over 11,000 anonymized customer environments to offer deeper visibility into how threat actors are actively exploiting modern cloud and AI infrastructures.

An Explosion of AI-Specific Secrets and Shadow AI

A primary finding of the 2026 report is the rising proliferation of AI-specific credentials. The data indicates that AI-related secrets — such as OpenAI API Keys, Azure OpenAI API Keys, and others — increased by approximately 140% in a span of one year. This growth correlates directly with the rapid embedding of AI technologies into customer support systems, internal tooling, financial platforms, and product experiences.

Ubiquitous deployment has generated a widespread organizational pattern known as “shadow AI” – the unsanctioned use of AI tools in an environment without formal IT approval or security oversight. In practice, this occurs when developers or internal teams utilize unmanaged or personal LLM keys to process corporate data outside of sanctioned IT or security channels. Since these AI integrations span numerous internal applications, the same API keys are frequently duplicated and stored within code repositories, SaaS configurations, and development scripts. Compounding this, these credentials are often implemented without proper access controls or routine rotation schedules.

The sprawl of these credentials renders them difficult to track via standard secrets management protocols, establishing a requirement for more centralized governance over how AI keys are issued and utilized.

Distinct Risk Vectors of Unmanaged AI Credentials

Unlike traditional cloud credentials that primarily facilitate resource manipulation, the compromise of AI keys introduces unique risk vectors. AI services frequently operate at the intersection of various enterprise systems, including CRM platforms, ticketing systems, and analytics tools, which means a single compromised LLM API key can provide an attacker with broad visibility into diverse datasets. The risks associated are categorized with exposed AI keys into two primary areas:

• Data exposure and leakage: Unauthorized access via AI keys can expose sensitive or proprietary datasets processed by the models, embedded business logic, and internal user prompts and outputs. This enables attackers to harvest sensitive corporate conversations at scale.
• Prompt injection and data poisoning: Unmanaged AI keys allow threat actors to actively manipulate AI models. Through prompt injection, an attacker can influence model behavior to exfiltrate data or bypass established security controls. Additionally, attackers can execute data poisoning by injecting misleading or malicious data into contextual corpora or fine-tuning datasets, which degrades the model’s integrity and reliability over time.

The Broadening Scope of Traditional Cloud Secrets

While AI credentials represent a novel attack surface, the traditional cloud secrets landscape has concurrently grown more complex. In 2025, organizations exposed approximately twice as many types of critical secrets as they did in 2024. This diversification spans AI platforms, cloud providers, SaaS services, and payment processors, pointing to how a single compromise can result in a broader blast radius across revenue-generating systems and infrastructure.

High-privilege cloud provider keys associated with AWS, Azure, and GCP remain the primary anchor of critical risk. The exposure of these keys can facilitate complete account takeover, infrastructure manipulation, and large-scale data exfiltration. As well, the exposure of payment gateway keys, such as those for Stripe and Razorpay, expands the potential damage by putting Personally Identifiable Information (PII) and financial data at risk, enabling the direct abuse of payment workflows.

Repository and CI/CD tokens also introduce supply chain risks, where high-severity credentials like a GITHUB_TOKEN can grant attackers direct access to deployment pipelines and source code, allowing a localized leak to escalate into a systemic infrastructure incident. From a collective standpoint, secrets exposure is exponentially spanning payments, coding, and software development workflows, making risk an interconnected and complex challenge.

Verified Exploit Paths: The Persistence of Legacy Vulnerabilities

To evaluate how these exposed secrets translate into practical risks, the SentinelOne researchers leveraged the Offensive Security Engine (OSE) to generate Verified Exploit Paths. This technology analyzes misconfigurations, vulnerabilities, and exposed secrets in context to determine realistic exploitability.

The telemetry demonstrates that attackers generally do not rely on highly complex, theoretical attack chains. Instead, threat actors consistently exploit recurring entry points, specifically targeting misconfigured external services and widely abused Common Vulnerabilities and Exposures (CVEs). Notably, legacy vulnerabilities remain highly prevalent across customer environments and serve as reliable initial access points. The top verified exploit paths continue to involve older, critical CVEs, including:

• Shellshock (CVE-2014-6271)
• FortiGate SSL VPN credential disclosure (CVE-2018-13379)
• Pulse Secure VPN arbitrary file read (CVE-2019-11510)
• Webmin RCE (CVE-2019-15107)
• Barracuda ESG zero-day backdoor (CVE-2023-1698)

Since these vulnerabilities are public and well-documented, threat actors possess proven techniques and automated tooling to exploit them whenever they persist in production environments. Once initial access is achieved through these legacy vulnerabilities, attackers routinely follow reachable secrets to pivot into additional services, such as utilizing an exposed key found in a cloud bucket to access an AI assistant, and subsequently, the customer data it processes.

Strategic Recommendations for Security Leaders

Addressing the interconnected risks of AI integration and cloud secrets requires a structured, objective approach to security architecture. The report outlines several concrete capabilities and practices including:

• Continuous Surface Monitoring: Organizations must regularly inventory internet-facing assets, databases, and key cloud services, ensuring any configuration changes are immediately reflected in security posture assessments.
• DevSecOps Automation: Security controls must be embedded directly into CI/CD pipelines and developer workflows. Organizations should automate the scanning of exposed secrets and trigger safe remediation actions, such as access revocation or key rotation.
• Governance of AI Credentials: AI keys must be classified and treated as high-value credentials. Organizations should mandate the use of centrally managed AI keys rather than personal credentials, enforce least-privilege access, implement regular rotation schedules, and continuously monitor for shadow AI usage or abnormal access patterns.

Conclusion

As AI systems are increasingly built atop existing cloud, payment, and CI/CD platforms, weaknesses in traditional credentials inevitably become weaknesses in the AI infrastructures that rely upon them. The full report provides complete datasets and comprehensive exploit path models allowing today’s security teams to align their internal security policies with the realities of current threat actor behaviors. Learn more about the objective metrics behind the latest wave of credential exposure and vulnerability exploitation to establish more resilient and fully-controlled infrastructure architectures.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

In 2026, the question for security leaders is not whether a supply chain attack is coming. Every serious organization should assume it is. The question is whether their defense architecture can stop a payload it has never seen before. It’s a question that takes on even more critical implications at a time where trusted agentic automation increasingly becomes the norm.

In three weeks this spring, three threat actors each ran a tier-1 supply chain attack against widely deployed software: LiteLLM, a core AI infrastructure package, Axios, the most downloaded HTTP client in the JavaScript ecosystem, and CPU-Z, a trusted system diagnostic tool. Different vectors, different actors, different techniques. SentinelOne® stopped all three on the same day each attack launched, with no prior knowledge of any payload.

The more important story is the how. Each attack arrived as a zero-day at the moment of execution. Each exploited a trusted delivery channel: an AI coding agent running with unrestricted permissions, a phantom dependency staged eighteen hours before detonation, a properly signed binary from an official vendor domain. No signature existed for any of them. No IOA matched.

SentinelOne stopped all three. That outcome is a direct answer to the question every security leader is now running against: What does your defense do when the attack arrives through a channel you explicitly trust, carrying a payload you have never seen before?

The AI Arms Race in Security is Underway

Adversaries are no longer running manual campaigns at human speed. In September 2025, Anthropic disclosed a Chinese state-sponsored group that jailbroke an AI coding assistant and ran a full espionage campaign against approximately 30 organizations. The AI handled 80–90% of tactical operations autonomously (i.e., reconnaissance, vulnerability discovery, exploit development, credential harvesting, lateral movement, exfiltration) with minimal human direction. Anthropic noted only 4–6 human decision points per campaign. The attack achieved limited success across those targets, but the trajectory is clear: AI is compressing the human bottleneck in offensive operations. Security programs designed around manual-speed adversaries are calibrating to a threat that is moving faster.

The LiteLLM attack is the clearest recent example of what this looks like inside an AI development workflow. On March 24, 2026, threat actor TeamPCP compromised the LiteLLM Python package by obtaining PyPI credentials through a prior supply chain compromise of Trivy, a widely-used open-source security scanner. Two malicious versions (1.82.7 and 1.82.8) were published. Any system with those versions during the exposure window executed the embedded credential theft payload automatically. In one confirmed detection, an AI coding agent running with unrestricted permissions (claude --dangerously-skip-permissions) auto-updated to the infected version without human review — no approval, no alert, no visible action before the payload ran. SentinelOne detected and blocked the malicious Python execution on the same day across multiple environments. Most organizations running AI development workflows didn’t know they were exposed until after the fact. The gap where human review processes don’t reach is wide, and it grows with every AI agent added to a pipeline.

Security programs were built for a different adversary. Vulnerability management, triage queues, patch cadences: all of it assumes an attacker who moves at a pace where human response can still close the window. This year’s SentinelOne Annual Threat Report documented what happens when that assumption breaks: adversaries are shifting left, embedding malicious logic in the build process before software ever reaches production. Likewise, the Verizon 2025 Data Breach Investigations Report found that edge device vulnerabilities are now being mass-exploited at or before the day of CVE publication, while organizations take a median of 32 days to patch them. The old model worked when it was designed. Attackers just weren’t running AI yet.

Three Attacks, One Common Failure Mode

Each attack ran through the same gap. Authorization was treated as a sufficient security boundary, and when authorization is automated, that assumption has no floor.

An AI agent with install permissions doesn’t stop to ask whether a package looks right. It installs. Trusted source, valid credentials, done. Supply chain attacks have always exploited trusted delivery channels, but a human at the keyboard introduces at least one friction point: Someone might notice something off, slow down, ask a question. Agents don’t do that. They execute at the speed of the next API call. When you give an agent install permissions, you’ve extended your trust model to cover everything it will ever run. Authorized agents execute exactly what their permissions allow. That’s the design. Treating permission as a proxy for safety is what turns a compromised supply chain hypersonic.

LiteLLM was compromised via credentials stolen through Trivy, a security scanner. The Axios attacker bypassed every npm security control the project had in place by exploiting a legacy access token the maintainers had forgotten to revoke. The CPUID attackers went after the vendor’s distribution infrastructure directly, so anyone who downloaded from the official website got a properly signed binary with a payload inside. In all three cases, the identity was legitimate. The intent wasn’t.

SentinelOne’s Annual Threat Report named the failure precisely: “The identity is verified, but the intent has been subverted, rendering traditional access controls ineffective against the resulting supply chain contamination.” Signature libraries, IOA rule sets, reputation lookups: All of them check authorization. None check intent. These attacks were designed to exploit exactly that. When the authorization model runs automatically, so does the exposure.

What Actually Stopped Them

In each incident, SentinelOne’s on-device behavioral AI flagged the execution pattern, not a known signature or hash for that specific attack.

The LiteLLM detection flagged a Python interpreter executing Base64-decoded code in a spawned subprocess. SentinelOne killed the process preemptively, terminating 424 related events in under 44 seconds, before any human was in a position to observe it. The Axios detection, via the Lunar behavioral engine, caught PowerShell executing under a renamed binary from a non-standard path. The engine flagged the technique regardless of what the payload contained. The first infection occurred 89 seconds after the malicious package went live; the behavioral detection fired on the same day of publication. The CPU-Z detection flagged cpuz_x64.exe building an anomalous process chain: spawning PowerShell, which spawned csc.exe, which spawned cvtres.exe. CPU-Z does not do that. The platform terminated the execution chain mid-attack during a 19-hour active distribution window.

This is the operational output of Autonomous Security Intelligence (ASI), the intelligence fabric built into the Singularity Platform. ASI runs on-device at the edge as part of the core architecture. It is already running when the attack starts, killing the process before the threat can escalate.

Where customers had SentinelOne fully deployed with the right policies enabled, they were covered. Where they did not, they were exposed, and with average ransomware recovery costs exceeding $4M per incident, that exposure has a real price. If you are not certain your deployment matches the configuration that stopped these three attacks, that certainty is worth getting.

AI to Fight AI

This is the product reality behind the thesis SentinelOne brought to RSAC: AI to fight AI. A machine-speed adversary requires a machine-speed defense. That is an architectural requirement, not a positioning statement. ASI monitors behavioral patterns at the point of execution and kills the process when something deviates, at machine speed, without waiting for a human to write a query or approve a kill.

According to an IDC study, organizations using SentinelOne’s AI platform identify threats 63% faster and remediate 55% faster than legacy solutions, neutralizing 99% of threats without a single manual step. For organizations in regulated industries (healthcare, financial services, manufacturing, critical infrastructure), the stakes compound beyond breach cost. An exposure window that stays open through manual investigation is a potential regulatory notification event, an audit finding, and a conversation the CISO has with the board under circumstances no one wants. The difference between a stopped attack and an active breach is whether the architecture acts before the attacker establishes persistence. By the time a human analyst approves the kill, redundant persistence mechanisms may already be installed. The CPU-Z attack deployed three of them specifically because partial cleanup leaves the payload operational.

Human-driven workflows, manual validation, and legacy tooling cannot keep pace with that attack cadence. When defense relies on investigation before action, the advantage shifts to the adversary. The gap is in the architecture. You cannot tune your way out of it.

Conclusion | The Only Question That Matters

SentinelOne’s latest Annual Threat Report documented the pattern these three attacks confirm: Adversaries are “shifting left” by integrating malicious logic into the build process itself, compromising software before it reaches production. It is the current operating model of advanced threat actors, and it is accelerating.

Three attacks. Three detections. Three outcomes, all in a matter of weeks. The architecture that survived them is real-time, AI-native, and built into the edge.

The question every security leader should be able to answer: Could your current solution have stopped LiteLLM, Axios, and CPU-Z autonomously, on the day of each attack, with no prior knowledge of any payload?

If the answer depends on a signature update, a cloud verdict, a manual investigation step, or a policy that wasn’t enabled, that is your answer.

Read the full technical breakdown of each incident:

• How SentinelOne Stopped the LiteLLM Supply Chain Attack
• Securing the Supply Chain: The Axios Attack
• How SentinelOne Blocked the CPU-Z Watering Hole Attack

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

As organizations rush to adopt AI, they are discovering that traditional, siloed security tools cannot keep pace. The data is too vast, the infrastructure is too interconnected, and runtime environments are too dynamic. Security leaders are confronting a hard reality: AI cannot be secured with point solutions — it is just too broad.

To scale AI with confidence, enterprises must move beyond check-the-box controls and adopt a holistic, machine-speed defense that secures the entire AI lifecycle. This means protecting the data that fuels and is accessed by models, the cloud infrastructure that runs them, and the workloads and AI systems operating at runtime as a single, unified, and immutable system.

As AI capabilities accelerate, a critical question is emerging in the market: Does AI reduce the need for cybersecurity, or fundamentally increase it?

The answer is clear. With current infrastructure architectures, AI is not a replacement for security. It is a multiplier for risk. Models ingest massive volumes of data and agents can sprawl uncontrollably. It depends on complex cloud infrastructure and operates continuously at machine speed. Each stage of the AI lifecycle introduces new attack paths and new failure modes.

Today, SentinelOne is announcing the expansion of its AI Security platform with new Data Security Posture Management (DSPM) capabilities, model red teaming, validation and guardrails (by Prompt Security), MCP Security (by Prompt Security), AI-SPM, AI Workload Protection, and AI end user protection. This milestone advances our broader vision, delivering a unified platform that secures AI end to end, from data accessed, all through runtime execution and model input and output. This is complete security, visibility, and governance over Al usage throughout its entire lifecycle.

The Foundation: Securing AI at the Data Layer

AI security starts with data, not because data is abundant, but because mistakes made at this stage are irreversible. AI models also don’t just process the data they ingest, they memorize it. If sensitive PII, credentials, or proprietary information enter a training pipeline, that data can become baked into a model’s weights, creating a permanent security liability that is nearly impossible to remediate later.

This risk is amplified by scale. Industry projections estimate that the global datasphere, the unstructured data stored in cloud object stores and increasingly fed into AI pipelines, will reach 10.5 zettabytes by 2028. This data is not just storage. It is the fuel that trains, fine-tunes, and powers AI systems. This is why data security is the first mile of AI security.

With the introduction of these new DSPM capabilities, SentinelOne enables organizations to establish a “safe-to-train” gate before data ever reaches an AI pipeline. These capabilities provide deep visibility into cloud-native databases and object stores, allowing teams to discover unmanaged or forgotten data sources, classify sensitive information with policy-driven precision, and prevent high-risk data from being used in training or inference workflows.

Singularity Cloud Security’s integrated DSPM discovers cloud object stores and databases and classifies sensitive data that could find its way into AI training pipelines. 

However, visibility alone is not enough. AI pipelines ingest data at massive scale, making them an attractive vehicle for malware delivery and pipeline poisoning. In addition to identifying and redacting sensitive data, SentinelOne actively scans cloud storage at machine speed to prevent malicious content from ever reaching AI models or applications. By securing data at ingestion all before training begins, organizations eliminate entire classes of AI risk that cannot be fixed downstream. This is the foundation for trusted AI adoption.

The Infrastructure Layer: Securing the Systems That Run AI

Securing AI data is necessary, but it is not sufficient. Data does not exist in isolation. Rather, it lives on cloud infrastructure and in AI environments where infrastructure becomes a critical failure point.

AI workloads introduce a uniquely high-risk combination of high-value data, high-privilege access, and high-performance compute. AI factories, training clusters, managed AI services, and inference endpoints often require broad permissions and continuous access to cloud object stores. Without strong infrastructure controls, attackers can pivot from exposed data into model logic, model weights, or downstream applications. This is where cloud infrastructure security becomes inseparable from AI security.

Traditional Cloud Security Posture Management (CSPM) provides essential hygiene across the cloud estate by identifying misconfigurations, excessive permissions, and policy drift. In AI environments, however, security teams also need visibility and control that is specific to how models are built, deployed, and accessed.

AI-Security Posture Management (AI-SPM) extends infrastructure security directly into the AI layer. By treating AI systems as first-class assets, AI-SPM provides a unified inventory of training jobs, development notebooks, managed AI services, and inference endpoints across the environment.

Together, CSPM and AI-SPM allow security teams to understand how data, infrastructure, and AI systems are connected. They can trace attack paths from misconfigured storage to over-privileged training containers, detect unmanaged AI assets, and prevent adversaries from moving laterally from the cloud foundation into model logic. This infrastructure layer is what connects secure data to secure runtime and it is essential for protecting AI at scale.

The Runtime Layer: Protecting AI In Production

AI security cannot stop when a model finishes training. The moment AI systems move into production, they begin interacting with real users, real data, and real business processes, making runtime protection a critical part of the AI security lifecycle.

At runtime, AI workloads operate continuously and at machine speed. Models and agents execute inside cloud workloads that must be protected against exploitation, unauthorized access, and lateral movement. Any compromise at this stage can immediately impact business operations, data integrity, and customer trust.

This is where runtime workload protection becomes essential. Cloud Workload Protection Platforms (CWPP) provide real-time visibility and enforcement across the compute environments running AI models, ensuring that workloads are monitored, hardened, and protected without degrading the performance required for high-velocity inference.

By extending protection into runtime, security teams ensure that AI systems remain secure not only during development and deployment, but throughout their operational life. This completes the AI security lifecycle from data ingestion, through infrastructure, to production execution.

Prompt Security and AI Red-Teaming: Continuously Validating Trust

Securing AI at runtime goes beyond protecting the workloads that execute models. It also requires validating how models behave when they are used (and misused) in the real world.

Prompts are the primary interface to AI systems and they represent a powerful new attack surface. Malicious or malformed prompts can be used to bypass controls, extract sensitive information, manipulate model behavior, or trigger unintended actions in downstream systems. These risks cannot be addressed solely through static controls or one-time reviews. This is where prompt security and AI red-teaming become essential.

By continuously testing AI systems with adversarial prompts and simulated attacks, organizations can identify behavioral weaknesses before they are exploited in production. AI red-teaming helps validate that models behave as intended under real-world conditions, exposing prompt-level vulnerabilities, unsafe outputs, and policy bypasses that would otherwise go undetected.

When combined with runtime protection, this approach ensures that AI systems are not only secure in how they are built and deployed, but also resilient in how they respond — even as models evolve, prompts change, and new attack techniques emerge.

This continuous validation loop is critical for maintaining trust in production AI systems and closing the final gap in the AI security lifecycle.

A Unified Fabric for AI Security

The transition to AI is ultimately a trust shift. Organizations will only move AI from experimentation to production if they can trust the data that trains models, the infrastructure that runs them, and the systems that govern how AI operates at runtime. Securing AI therefore cannot be fragmented. It requires a unified platform that treats data, infrastructure, and runtime as a single, connected system with shared context and continuous visibility across the entire AI lifecycle.

By integrating data security, cloud infrastructure posture management, AI-specific posture management, and runtime workload protection, SentinelOne delivers end-to-end AI security from data ingestion through runtime execution. This approach does more than reduce risk. It enables velocity. When security is built into the foundation, organizations can deploy AI faster, meet evolving regulatory requirements more easily, and innovate with confidence.

Secure the data.

Secure the infrastructure.

Secure the runtime.

This is how AI moves from risk to real-world impact. Contact us or book a demo to see how SentinelOne secures AI end to end — from data ingestion to runtime execution.