Most production AI security failures aren't exotic adversarial attacks on neural networks. They're the same boring infrastructure mistakes — open access controls, flat networks, exposed secrets — that security teams supposedly fixed fifteen years ago. When researchers audited 50 real production ML deployments in 2024–2025, 78% had at least one critical security misconfiguration (BigGo, July 2026). The Ray distributed compute framework alone exposed thousands of clusters with no authentication by default, leading to active exploitation valued at over a billion dollars (SecurityWeek, May 2024).
The uncomfortable truth: when we moved machine learning into production, we changed everything about the stack — probabilistic behavior, shared multi-tenant GPUs, prompts as control flow — but kept the old security assumptions. The result is teams running 2008-era security on 2026-era AI systems. The fix isn't a novel adversarial-defense paper; it's locking down access, segmenting networks, protecting secrets, and climbing a maturity model on purpose. This guide breaks down exactly how.
Last verified: 2026-07-22 · Most AI breaches are misconfigurations, not novel attacks · Ray CVE-2023-48022 (CVSS 9.8) remains disputed by Anyscale · NIST AI RMF released January 2023 · OWASP LLM Top 10 (2025) ranks prompt injection #1 · Pricing/limits are volatile — re-check monthly
What Are the Real LLM Security Threats in 2026?
The real LLM security threats in 2026 are infrastructure misconfigurations — over-privileged accounts, flat networks, exposed secrets — not the adversarial perturbation attacks that dominate research papers. A study of 50 production ML deployments found three recurring failures: access controls left wide open, no separation between system components, and trained models plus credentials stored in publicly accessible locations.
Here's the pattern across every major ML breach:
| Threat Category | What It Looks Like | Real-World Impact |
|---|---|---|
| Misconfiguration | Auth disabled by default, admin rights for every account | Ray clusters exploited for cryptomining + data theft |
| Over-privileged access | Credentials that never expire, blanket API keys | Stolen tokens give attackers full system control |
| Flat networks | No isolation between services or workloads | One compromised service = total system compromise |
| Exposed secrets/models | Hardcoded passwords, model files in public buckets | Credentials and IP leaked without any "hack" required |
The Ray Framework Case Study: How Defaults Become Disasters
Ray, maintained by Anyscale, is one of the most popular frameworks for distributed ML workloads. Its Jobs API allowed unauthenticated remote code execution — tracked as CVE-2023-48022 with a CVSS score of 9.8 (NVD). Security firm Oligo discovered hundreds of compromised Ray clusters in a campaign dubbed "ShadowRay," with attackers stealing AI production data, database credentials, SSH keys, and cloud tokens (SecurityWeek, May 2024).
The root cause wasn't a sophisticated zero-day — it was that authentication was off by default. Anyscale disputed the CVE as intended behavior, pointing out their documentation says Ray clusters should run in controlled network environments (Anyscale blog, November 2023). As of November 2025, threat actors were still actively exploiting exposed Ray clusters in a campaign dubbed "ShadowRay 2.0" (SecurityWeek, November 2025).
The fix only arrived with Ray 2.52.0, which introduced opt-in token-based authentication via the environment variable RAY_AUTH_MODE=token (Ray security docs). But even then, token auth ships as opt-out, not on by default — meaning teams must explicitly enable it or remain exposed.
Why Do Defenses That Work in Research Fail in Production?
Every security control costs something, and in ML that cost is latency and throughput — the two metrics your SLAs are built on. The defenses that researchers love most (real-time adversarial input detection) can add 15–30% overhead to every request, making them a non-starter at scale. Meanwhile, the cheap basics (authentication, input validation, logging) cost under 8% overhead and should always be present.
The Security Overhead Tiers
| Tier | Controls | Overhead | When to Use |
|---|---|---|---|
| Green (basics) | Auth, input validation, rate limiting, logging | <8% | Always — no debate |
| Orange (isolation) | Workload isolation, network segmentation, mTLS | 10–20% | Selectively for sensitive/untrusted workloads |
| Purple (detection) | Real-time adversarial input detection, query analysis | 15–30% | Only for highest-risk systems where latency allows |
The key insight: the same security check can double your response time if implemented sloppily, or cost a fraction if built well. The question teams should ask isn't "should we do this?" but "how do we do it without slowing everything down?" Run the cheap controls everywhere. Save the expensive ones for the systems that genuinely need them.
Three Structural Gaps Preventing Production-Ready Security
The ecosystem isn't production-ready yet, and three gaps explain why:
Tooling gap: Security tooling for ML is years behind traditional software. Regular software teams solved automated scanning and password management decades ago. ML hasn't fully adopted these practices. Early warning systems for ML-specific threats are still emerging.
Expertise silos: Security teams don't speak ML. ML teams don't speak security. Operations teams don't know how the model behaves. The problems live in the gaps where nobody has a complete picture.
Research-reality gap: Academic research focuses on defending against tiny adversarial perturbations to single models in isolation. Real-world attacks exploit stolen passwords, misused legitimate access, and shared systems running dozens of models simultaneously.
How Do You Secure an LLM Stack Like Infrastructure?
Secure your LLM stack the same way you'd secure a 2008 database: lock down access, segment the network, protect data at rest, and verify identities between services. The approach uses a defense-in-depth model with four layers and a maturity framework to know where you stand.
The Four-Layer Defense-in-Depth Model
Layer 1 — Infrastructure Security (the foundation): Containers, networks, GPU virtualization, encryption. If this layer is weak, everything above it is decoration. A perfect access-control policy on a cluster with no network isolation is just a locked door on an open building.
Layer 2 — Access Control: Who is allowed to do what. This is where you enforce least privilege, scoped credentials, and service-to-service identity verification — not just network access.
Layer 3 — Runtime Security: Watching traffic while the system is live. Behavior analysis, anomaly detection, and response capabilities that feed back into infrastructure hardening.
Layer 4 — Practice & Compliance: How the team actually works day-to-day. Incident response plans, compliance documentation, and a culture that treats security as a shared responsibility.
Critical principle: Infrastructure is the foundation. A failure at Layer 1 cascades upward. Your access control policy is irrelevant if the cluster underneath it is wide open.
The Three Most Dangerous Misconfigurations (and How to Fix Them)
Misconfiguration 1: Every account has full admin rights.
In most audited production ML setups, default configurations grant every account full administrative privileges with credentials that never expire. Any account can do anything.
Fix: Apply least-privilege principles. Each account should do only what it needs. Credentials should expire quickly — use short-lived, scoped tokens rather than static API keys. Tools like OAuth 2.0 token exchange can issue scoped, time-bound credentials that become useless within seconds if intercepted.
Misconfiguration 2: Flat networks with no isolation.
Nothing separates different parts of the system. An attacker who gets into one component can reach everything.
Fix: Wall system components off from each other. Require verified identity between services — not just network access. Use separate, isolated clusters for workloads that require isolation. Ray's own documentation recommends using "separate, isolated Ray clusters" rather than relying on a single cluster's internal scheduling (Ray security docs).
Misconfiguration 3: Exposed secrets and models.
Passwords hardcoded in code. Model weights sitting in public storage buckets. Credentials readable by anyone.
Fix: Use a proper secrets manager. Encrypt data at rest. Run automated secret-scanning before every deploy. This is basic hygiene — the same practices that prevent conventional data breaches.
What Maturity Level Is Your ML Security At?
Most teams believe they're at Level 3 (advanced, regulated-industry-grade). In reality, most are at Level 1 or 2. The NIST AI Risk Management Framework, released January 26, 2023, provides the foundation for mapping your maturity (NIST AI RMF). It includes four implementation tiers from ad-hoc (Tier 1) to adaptive (Tier 4), covering Govern, Map, Measure, and Manage functions.
| Level | Overhead Budget | What It Means | Suitable For |
|---|---|---|---|
| Level 1 — Basics | <5% | Bare minimum, no real controls | Test environments only — NOT production |
| Level 2 — Baseline | 5–10% | Proper logins, encryption, network separation, basic monitoring | Minimum bar for production |
| Level 3 — Advanced | 10–15% | Adds controls for regulated industries (healthcare, finance) | Compliance-driven environments |
| Level 4 — Adaptive | 15%+ | Continuous improvement, threat modeling, automated response | High-risk or mission-critical deployments |
How to assess yourself: Audit three things immediately:
- Can any account do anything? List all service accounts and their permissions. If most accounts have admin or write-everywhere rights, you're at Level 1.
- Are components isolated? Try to access one service's credentials from another service. If you can, your network is flat — Level 1 or 2 at best.
- Are secrets in code or public storage? Search for hardcoded credentials in your repos. Check if model weights are in publicly readable buckets. If yes, Level 1.
If you honestly pass all three, you're likely at Level 2 — the minimum for production. Most teams who say "Level 3" are actually here.
What Are the Emerging LLM-Specific Security Risks?
Four emerging risks demand attention as LLM stacks evolve beyond simple chatbots into agentic systems that take actions on your behalf:
Prompt Injection (OWASP LLM Top 10 — #1 Risk)
Prompt injection is the #1 vulnerability in the OWASP Top 10 for LLM Applications 2025 (OWASP, 2025). The model can't reliably distinguish between your developer instructions and user input. A cleverly worded message can override system prompts, extract sensitive data, or hijack the entire system. For a deep dive on securing AI agents against prompt injection, see our guide on AI agent production access security. The OWASP framework treats this as a cross-cutting concern: input validation at every boundary, least-privilege access for all model capabilities, and verified supply chains.
RAG Poisoning
If your model pulls answers from a document store (retrieval-augmented generation), and that store is compromised, every answer downstream is poisoned. Nobody has to attack the model itself — they just plant malicious documents in the retrieval corpus. Securing your RAG pipeline is an extension of access control: who can write to the vector database, and is it the same account that runs inference?
GPU Side-Channel Attacks
When you pack multiple customers on one GPU to save money, information can leak between them. Published research demonstrates that NVIDIA's DGX multi-GPU machines are vulnerable to L2 cache contention attacks, achieving covert channel bandwidth of ~4 MB/s and enabling attackers to fingerprint workloads and extract ML hyperparameters across GPU boundaries (ISCA 2023, Dutta et al.). More recent work targets NVIDIA MIG (Multi-Instance GPU) cache partitioning, showing that cross-instance L2 cache interference persists despite hardware partitioning, allowing attackers to infer kernel launch patterns of co-located LLM inference (USENIX Security 2026, Gu et al.). Another study demonstrated extracting prompt tokens from co-located users with 96.2% accuracy via KV cache residency (SPACE 2025, Das & Vijayakumar).
This means shared GPU infrastructure needs the same network-isolation thinking as shared cloud infrastructure — not just for network traffic, but for compute isolation.
Model Supply Chain Risk
Downloading models and add-ons from public sources — like Hugging Face — without verifying their provenance introduces supply chain risk. The pickle serialization format, which is the default for PyTorch model weights, can execute arbitrary code when deserialized. In February 2025, researchers found malicious models on Hugging Face that embedded reverse-shell payloads in pickle files to evade the platform's scanner (The Hacker News, Feb 2025). Hugging Face's own documentation warns: "do not unpickle data from untrusted sources" and recommends using signed commits and the safetensors format instead (Hugging Face, security-pickle docs).
This is the AI equivalent of the npm/PyPI supply chain attacks that have plagued software development for years. The same defenses apply: verify provenance, use signed artifacts, prefer safe formats, and scan before loading.
How to Build a Production-Ready LLM Security Checklist
Here's the prioritized action sequence based on risk-impact ordering. Start with what causes the most damage and work down:
Immediate (This Week)
- Enable authentication on every API endpoint. If you're running Ray, set
RAY_AUTH_MODE=tokenon Ray 2.52.0+. Check every other ML framework's dashboard and job-submission API for auth settings. - Audit all service accounts. List every account that can access your model endpoints, inference APIs, or training infrastructure. Remove admin rights from accounts that don't need them. Set credential expiration.
- Search for exposed secrets. Run a secret scanner across your codebase and infrastructure-as-code. Check if model weights or credentials sit in public cloud buckets.
Short-Term (This Month)
- Segment your network. Isolate inference endpoints from training infrastructure from data stores. Require verified identity between services, not just network access. If you're running agents with production credentials, follow the 5-layer security architecture for agent access control.
- Implement tiered rate limiting. Apply rate limits at the API gateway layer. Different limits for different endpoints based on sensitivity.
- Enable inference logging with PII redaction. Log every inference request and response. Redact sensitive data before it hits your log pipeline.
Ongoing (Continuous)
- Map controls to compliance frameworks. The NIST AI RMF, OWASP LLM Top 10, and SOC 2 all overlap. Map once, satisfy multiple regulators. The NIST AI RMF's four functions (Govern, Map, Measure, Manage) structure this well.
- Establish continuous monitoring. Watch for configuration drift. Automated compliance scanning should verify that container configurations match hardened baselines, that JWT signing keys rotate on schedule, and that rate-limiting thresholds hold under load.
- Include AI-specific scenarios in incident response. Model weight compromise, prompt injection campaigns, and training data exposure need dedicated playbooks — they're not standard security incidents.
What This Means for You
If you're building or running AI in production, the most important security investment you can make isn't an adversarial-robustness paper or a fancy ML threat-detection tool — it's getting the basics right. Audit your access controls. Segment your network. Protect your secrets. Most teams think they're at Level 3 maturity and are actually at Level 1 or 2. The gap between where you think you are and where you actually are is where the next breach will come from.
If you're a small business deploying AI tools, the same principles apply at a smaller scale. If you're using a hosted API (OpenAI, Anthropic, Google), your main risks are prompt injection and API key exposure — use scoped keys with spending limits. If you're running open-source models locally or on your own cloud instances, the infrastructure security basics matter even more: never expose a model serving port without authentication, and store your model weights in access-controlled storage.
If you're a security professional moving into AI, bring your existing expertise. The OWASP LLM Top 10 is a direct extension of the OWASP API Security Top 10 you already know. The NIST AI RMF maps to SOC 2 controls you already maintain. The infrastructure mistakes are the ones you've been fixing for years. Your knowledge transfers — the context just changes.
FAQ
Q: What is the most common LLM security failure in production?
A: Misconfiguration — not adversarial attacks. In an audit of 50 production ML deployments, 78% had at least one critical security misconfiguration. The three most common were open access controls, flat networks with no isolation, and exposed secrets/models.
Q: What was the Ray framework security vulnerability?
A: CVE-2023-48022 (CVSS 9.8) — Ray's Jobs API allowed unauthenticated remote code execution because authentication was disabled by default. Security firm Oligo discovered hundreds of actively compromised clusters in the "ShadowRay" campaign, with attackers stealing credentials, AI models, and cloud tokens. Anyscale disputed the CVE but added opt-in token authentication in Ray 2.52.0.
Q: How much overhead do ML security controls add?
A: Basic controls (auth, input validation, logging) cost under 8% overhead and should always be present. Workload isolation costs 10–20%. Real-time adversarial input detection costs 15–30%, making it viable only for high-risk systems where latency budgets allow.
Q: What is the OWASP Top 10 for LLM Applications 2025?
A: The OWASP Top 10 for LLM Applications 2025 is the industry-standard framework for categorizing security risks specific to large language model systems. It ranks prompt injection as the #1 risk, followed by sensitive information disclosure and supply chain risks. It was developed by over 600 contributing experts and is maintained by the OWASP Gen AI Security Project.
Q: Are shared GPUs vulnerable to side-channel attacks?
A: Yes. Published research demonstrates L2 cache contention attacks across GPU instances on NVIDIA DGX machines and MIG partitions, enabling attackers to fingerprint workloads, extract ML hyperparameters, and even recover prompt tokens from co-located inference with 96.2% accuracy. Shared GPU infrastructure needs the same careful isolation as shared network infrastructure.
Q: How do I check if my LLM deployment is secure?
A: Start with three checks: (1) Can any account do anything? If most accounts have admin rights, you're at maturity Level 1. (2) Are components isolated? Try accessing one service's credentials from another — if you can, your network is flat. (3) Are secrets in code or public storage? Scan for hardcoded credentials. If you pass all three, you're likely at Level 2 — the minimum for production.
Discussion
0 comments