Your AI Stack Is Being Targeted — And Most Security Teams Aren't Ready for It

Here's a scenario worth sitting with.

A company spins up a cloud environment to train a recommendation model. It's not production. It's not customer-facing. The team treats it like a sandbox: no formal hardening, no security review, just engineers moving fast. Months later, that same environment is quietly found to have been exfiltrating data to an attacker's server. The entry point wasn't a phishing email. It wasn't a zero-day. It was an exposed API endpoint on a popular AI orchestration framework, one that had no authentication built into it by design.

This isn't a hypothetical. Variations of it have played out across real organizations, and they'll keep happening, because the security conversation around AI still hasn't caught up with where attackers are already operating.

Where the Real Attacks Are Landing

Ask anyone in your organization what "AI security" means, and you'll hear about hallucinations, bias, prompt injection, model safety. All legitimate concerns. None of them are where the most consequential attacks are landing right now.

The infrastructure powering your AI (the GPU clusters, training pipelines, model registries, and orchestration frameworks) is the actual battleground. And for most organizations, it's largely unguarded.

The ShadowRay case makes this concrete. In March 2024, Oligo Security researchers uncovered the first documented case of attackers actively exploiting AI workloads in the wild. The vulnerability, CVE-2023-48022, sits inside Ray, an open-source framework widely used to scale Python-based AI and machine learning applications. It's an unauthenticated remote code execution flaw carrying a CVSS score of 9.8.

Here's exactly how the attack unfolded:

1. Reconnaissance without noise: Attackers used out-of-band detection tools to identify vulnerable Ray dashboards at scale, without triggering a single intrusion detection alert. Victims effectively raised their hands and identified themselves.
2. Silent entry: Once they confirmed access, they submitted malicious jobs through Ray's unauthenticated Jobs API. No credential needed, no brute force required.
3. Living off the land: They spread laterally across entire clusters using Ray's own legitimate orchestration features. The same infrastructure your engineers used to schedule ML jobs was used to schedule malware.
4. Persistence and monetisation: Cryptominers were deployed, reverse shells established, and sensitive data exfiltrated, all while disguising malicious processes as legitimate Linux kernel workers.

By late 2025, this had evolved into ShadowRay 2.0. Exposed Ray servers grew tenfold, from a few thousand to over 230,000. The operation matured from simple cryptojacking into a multi-purpose botnet capable of DDoS attacks, data exfiltration, and autonomous global propagation. And the attack payloads themselves were likely AI-generated; attackers were using AI to write attack code targeting AI infrastructure.

The Model You Trust Is the Weapon

If exposed infrastructure is the obvious risk, the supply chain is the invisible one, and in some ways the more dangerous of the two.

When a developer pulls a pre-trained model from Hugging Face to jump-start a project, they rarely think of it as a software dependency carrying real risk. But that's exactly what it is.

How supply chain attacks on AI models work

• Namespace hijacking: Palo Alto Networks Unit 42 found that when Hugging Face model authors delete their accounts, those usernames become available for re-registration by anyone. Attackers register the deleted name, upload a poisoned model, and wait for organizations to pull it automatically through code references no one has questioned in months.
• Repository poisoning: A threat actor group called NullBulge compromised both GitHub and Hugging Face repositories, embedding malicious Python payloads that exfiltrated data via Discord webhooks and deployed customized ransomware, all through platforms developers trust by default.
• Serialization exploits: JFrog's monitoring found roughly 95% of malicious models on Hugging Face target PyTorch's Pickle serialization format. The malicious logic executes silently the moment a developer loads the model. No warning. No obvious failure.
• Contamination cascades: When a backdoored base model gets fine-tuned across dozens of derivative models across different teams and organizations, you're not dealing with one compromised artifact. You're dealing with a contamination event that's genuinely hard to trace back.

The exposure numbers that should concern you

Then Comes Agentic AI

If what's been described so far feels manageable (known attack patterns, identifiable fixes), the next phase changes the calculus entirely.

Agentic AI systems don't just respond to queries. They plan, take action, maintain context across sessions, and operate across multiple tools simultaneously. A standard chatbot has a limited blast radius. An agent with access to your email system, code repository, customer database, and internal APIs is something else entirely.

The three root causes OWASP flags for agentic AI risk

• Excessive functionality: Agents wired to tools and systems far beyond what their actual task requires
• Excessive permissions: Those tools operating with broader privileges than the task ever needed
• Excessive autonomy: High-impact actions that proceed without a human checkpoint or approval gate

OWASP recognized this shift and published a dedicated Top 10 for Agentic Applications 2026, a peer-reviewed framework for exactly these risks. It's worth reading before you deploy your first production agent, not after.

At RSAC 2026, Microsoft's security team put the trajectory plainly: the agent ecosystem is on track to become the most-targeted surface in the enterprise. The organizations that can't answer these three questions about their deployed agents are already behind:

Most organizations deploying agents today cannot answer any of them. Agents are moving into production faster than the security thinking around them is forming.

The Readiness Gap That's Making All of This Worse

The threat picture above exists, in part, because of a structural mismatch that most organizations haven't directly confronted.

AI & ML Teams	Security Teams
Move fast, ship fast, experiment freely	Built for deliberate, structured assessment
Pull dependencies from public hubs	Lack fluency in ML pipelines and GPU orchestration
Spin up environments without formal review	Don't know the right questions to ask until something fails
Treat AI as product, not infrastructure	Lack context to assess model serialization or supply chain risk

The result is predictable: AI environments get built without security input, and security teams don't know enough to intervene until something has already gone wrong.

What the numbers say

• +44% increase in attacks starting with public-facing application exploitation (largely missing authentication controls) (IBM X-Force 2026)
• +89% increase in attacks from AI-enabled adversaries (CrowdStrike 2026 Global Threat Report)
• 90+ organizations had legitimate AI tools weaponized against them to steal data or generate malicious commands (CrowdStrike)
• Security leaders often can't inventory what data flows through third-party AI vendors their own organization has adopted (Akamai, 2025)

Attackers are finding and exploiting gaps faster than teams are patching them, not because patches don't exist, but because the exposed systems often aren't on anyone's radar at all. That isn't just a technology gap. It's a governance gap masquerading as one.

Five Controls That Actually Matter Right Now

There's no single fix. But the following five controls will materially reduce exposure, and the distance between organizations that implement them and those that don't is already significant.

1. Build the inventory first. Know every AI workload you're running: where it lives, what data it touches, what network access it has, and who owns it. Explicitly include shadow AI environments that teams spun up without formal review. Those are often the ones with the widest exposure.
2. Treat model dependencies like software dependencies. Extend your Software Bill of Materials (SBOM) process to your model stack. Know where each model came from, verify its integrity, and pin versions rather than pulling dynamically from public hubs. An unverified model from a public registry carries the same supply chain risk as an unverified npm package.
3. Stop leaving AI framework dashboards exposed to the internet. Ray, Jupyter, and similar tools are explicitly designed for trusted internal networks; their own documentation says so. Firewall them. Add authentication layers where native auth doesn't exist. ShadowRay didn't require any novel exploit. It relied entirely on configurations that violated the tool's own documented requirements.
4. Apply least privilege to AI workloads and agents. Training pipelines don't need broad IAM permissions. Agents don't need access to every system they might conceivably use. Scope access to what the task requires, and require human approval gates for high-impact actions. The biggest risk with agentic systems isn't being hacked in the traditional sense. It's being manipulated into doing harmful things through access that was legitimately granted.
5. Build runtime visibility into AI environments. ShadowRay 2.0 attackers throttled CPU usage to ~60% and disguised processes as legitimate kernel workers specifically to dodge standard monitoring. That's only catchable with runtime visibility tuned for the AI environment, monitoring process spawning, GPU/CPU anomalies, network connections, and execution behavior in real time, not just the application layer above it.

---

The Clock Is Already Running

There's a comfortable assumption in security that AI-specific risks are a future problem, something to address once the AI strategy matures and proper frameworks arrive. That assumption is wrong, and the timeline for correcting it is shorter than most organizations realize.

AI infrastructure is cloud infrastructure. It carries the same fundamental security requirements as any high-value workload: visibility, access control, supply chain integrity, and runtime protection. What makes it different is that AI workloads tend to concentrate more data, more compute, and more privilege in a single environment than most traditional systems, yet they are routinely deployed with less security oversight than those systems ever received.

The World Economic Forum captured the strategic dimension of this in April 2026, noting that as economies integrate AI into everyday services and production, the resilience of large-scale compute infrastructure is becoming inseparable from economic continuity and national security. That same month, Iranian drones struck AWS facilities in the UAE and Bahrain, disrupting cloud services across the region and marking the first time commercial hyperscale data centers became explicit targets in kinetic conflict.

That's where AI infrastructure sits now: somewhere between enterprise technology risk and critical infrastructure exposure, with security practices that still treat it like an experimental side project.

The organizations that close this gap (not through elaborate programs, but by applying real controls to environments that currently have none) will be in a significantly different position from those still waiting for the right framework to materialize.

The attacks aren't waiting.