AI Engineer World's Fair 2026
Your LLM Stack Is a 2008 Database With Better Marketing
Read the talk
Your LLM Stack Is a 2008 Database With Better Marketing
Exposed Ray clusters reveal a familiar security problem: production ML needs enforceable access boundaries, protected artifacts, and controls that fit its performance budget.
From a talk by Lovina Dmello
Before you start: Familiarity with APIs, service credentials, containers, and basic ML deployment will help; no specialized security background is required.
An open job API is already a security problem
What happens when a distributed ML cluster exposes its dashboard and job API to the Internet? An attacker may not need to manipulate a model at all: the infrastructure already offers a way to submit work. Lovina Dmello, who introduces herself as a senior software developer on NVIDIA’s deep learning infrastructure team, opens with researchers finding thousands of exposed Ray clusters. The matching ShadowRay investigation was published in March 2024, with evidence of exploitation extending back to September 2023.
Dmello describes authentication as a default that operators forgot to enable. The historical distinction matters: Ray’s maintainers stated in November 2023 that open-source Ray lacked built-in authentication and depended on an external security boundary. The deployment failure was allowing untrusted network access, rather than overlooking an available authentication switch. Built-in token authentication arrived later, starting with Ray 2.52.0.
Dmello describes the exposure as over a billion dollars; the matching investigation estimated almost a billion dollars in potentially compromised machines and compute, using observed clusters and contemporary annualized GPU rental prices. That was an estimate of exposed resources, not measured losses. Her practical point does not depend on the valuation: this was an exposed infrastructure interface, not a clever attack on a neural network. The same class of failure includes leaked API keys, overprivileged accounts, and model weights left in public buckets. Security depends on the configuration that actually reaches production.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The stack changed its security assumptions
Dmello’s stylized 2008 application has three convenient properties: deterministic code, a fixed perimeter, and one tenant. A security team can reason about its branches, identify the boundary, and decide what belongs inside it. Production ML complicates each assumption. Correctness becomes a distribution rather than a single yes-or-no branch. Model weights are copyable assets, while the serving API itself can become a route for extracting information about the model.
Cost pressure then puts multiple tenants on shared GPUs, making isolation part of the security problem. The LLM stack extends the boundary again: prompts influence control flow, retrieval corpora supply answer content, and agents take actions. A document store is now part of the system’s behavioral input; a generated response may become a request to another service. Keeping the old security assumptions while adding these capabilities leaves a 2008 playbook governing a 2026 system.
Three priorities follow: fix configuration failures before assuming the platform lacks security features; make defenses survive production latency and throughput constraints; and secure the infrastructure surrounding the model. These priorities connect the model’s behavior to the systems that grant it data, compute, and authority.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the boundary from the infrastructure upward
Defense in depth starts with infrastructure security: containers, networks, GPU virtualization, and encryption. Above that sits access control, which determines who may perform which actions. Runtime security watches traffic while the system is live. Operational practice surrounds all three: team responsibilities, compliance, incident response, and the culture that determines whether controls stay enabled. These layers depend on one another. A carefully written access policy offers little protection if an attacker can reach the underlying cluster through an unprotected interface.
The threat map spans six categories, grouped here by the assets and boundaries they threaten:
| Threat categories | Corresponding controls |
|---|---|
| Adversarial inputs; model extraction | Input validation, adversarial detection, rate limits, API authentication, query analysis |
| Poisoning and supply chain; privacy breaches | Secure CI/CD, model signing, provenance, access control, encryption |
| Infrastructure compromise; insiders | Container isolation, network segmentation, RBAC, behavior analysis |
Model-focused defenses belong in this map, but they do not replace infrastructure controls. Dmello identifies infrastructure compromise and insider access as recurring practical breach paths that are particularly easy to expose through configuration mistakes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Available protection can disappear in configuration
Dmello reports an unnamed audit of 50 production ML setups in which 78% had at least one critical security mistake. The audit’s sampling method and severity definition are not supplied, so the figure describes the study she cites rather than an established prevalence across production ML. Its recurring failures are concrete enough to inspect in a deployment.
- Open access controls: Almost any account can do almost anything, making a compromised identity broadly useful to an attacker.
- Unseparated components: Access to one part of the system enables movement into the rest. The initial compromise has no effective containment boundary.
- Exposed storage: Passwords and trained models sit where unintended parties can reach them.
These failures widen what an attacker can do after obtaining access; none requires discovering a weakness in the model’s predictions.
The ownership problem helps explain why existing protections go unused. Security experts design controls for people who understand security configuration, then hand them to ML teams whose primary responsibility is model accuracy. A platform can contain the necessary protection while the deployed configuration disables it. The missing capability is often an operational one: making the secure configuration understandable, owned, and maintained by the team shipping the system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A defense must fit the request path
Every control consumes resources, and in ML those costs show up in latency and throughput—the quantities service-level agreements constrain. Dmello groups controls into three approximate cost tiers. She does not specify workloads, hardware, baselines, or whether each percentage measures latency or throughput, so these are her planning ranges, not transferable benchmark results.
| Tier | Control | Dmello’s approximate performance cost | Deployment guidance |
|---|---|---|---|
| Green | Logins and input checking | Under about 8% | Run everywhere |
| Orange | Heavier workload isolation | 10–20% | Prioritize sensitive or untrusted workloads |
| Purple | Real-time malicious-input detection | 15–30% | Reserve for higher-risk paths |
The distinction is about placement as well as expense. Basic authentication and input checking form a baseline. More expensive isolation or detection needs a deployment strategy that reflects the workload’s risk and available performance budget.
Implementation quality can change that tradeoff substantially. Dmello warns that a poorly implemented security check can double response time. A team therefore needs more than a recommendation to enable a defense: it needs guidance on implementing the defense efficiently. Run cheap controls broadly and spend the expensive checks where the risk justifies them. That turns security from a feature checklist into a request-path engineering problem.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The gaps between tools, teams, and research
Deployability is also an ecosystem problem. Dmello points to conventional software practices—automated security scanning and proper password management—that have not fully carried over to ML workflows. ML-specific early-warning systems are another part of the tooling question. Meanwhile, responsibility is split across teams: security specialists may not understand ML, ML specialists may not understand security, and operations teams may not understand model behavior. A failure can live in the space between those responsibilities without anyone holding the full picture.
The research environment introduces another gap. Defending against tiny image perturbations is different from defending a production service against stolen passwords or misuse of legitimate access. Studying one model in isolation also leaves out the operational conditions of dozens of models sharing infrastructure. The constructive requirement is a set of controls one team can actually deploy, supported by a maturity model that shows where the system stands and a short list of repairs to make first.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Assess the deployment, then repair its boundaries
Dmello proposes a maturity model intended to map onto the NIST AI Risk Management Framework. The levels and overhead budgets below are her proposal, not NIST-defined tiers. NIST’s AI RMF Playbook instead organizes guidance around Govern, Map, Measure, and Manage. She announces four maturity levels but describes only the first three.
| Level | Proposed overhead budget | Deployment context |
|---|---|---|
| 1 | Under 5% | Bare basics; test environments only |
| 2 | 5–10% | Production minimum: logins, encryption, network separation, monitoring |
| 3 | Not specified | Advanced controls for regulated industries |
These budgets likewise have no stated benchmark conditions. The useful assessment is whether the controls actually exist in the deployed environment. Dmello cautions that teams may consider themselves ready for regulated workloads while their configuration still places them at the basic or baseline level.
Start the repairs with least privilege and short-lived credentials. An account with full administrator rights and a credential that never expires combines broad authority with a long opportunity for misuse. Give each account only the operations its job requires, and shorten the lifetime of the credentials that exercise those permissions.
Next, separate the network and require verified service identity. In a flat network, compromise of one component can expose every reachable component. Segmentation limits that movement, while identity verification prevents network reachability from acting as authorization. A minimal TypeScript authorization check illustrates the second boundary: an authenticated inference service can read model artifacts without automatically gaining permission to publish them.
typescript
type Action = "model:read" | "model:publish";
type VerifiedService = {
id: string;
expiresAt: number;
};
const grants: ReadonlyMap<string, ReadonlySet<Action>> = new Map([
["inference-service", new Set<Action>(["model:read"])],
["release-service", new Set<Action>(["model:publish"])],
]);
function authorize(
service: VerifiedService,
action: Action,
now: number = Date.now(),
): boolean {
if (service.expiresAt <= now) return false;
return grants.get(service.id)?.has(action) ?? false;
}
The service identity and expiry must come from trusted authentication middleware, not request fields. This check enforces permissions; network policy separately determines which services can connect.
Finally, protect secrets and model artifacts. Remove hardcoded passwords, put secrets in a secrets manager, and keep model files out of publicly reachable storage. Add encryption and automatic scanning before shipping. The complete repair slide makes these boundaries concrete: least-privilege RBAC and short-lived credentials; default-deny policies, microsegmentation, and mTLS; then secret management, encryption at rest, and CI scanning. These are ordinary infrastructure controls applied to the assets an ML system depends on.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
New attack surfaces still need enforceable boundaries
The familiar repairs do not exhaust the threat model. Dmello closes with four areas she considers less settled:
- Prompt injection: A model cannot reliably separate trusted instructions from someone else’s input. Malicious text can redirect behavior when the system treats that text as instructions.
- RAG poisoning: Corrupting the document store can corrupt retrieved answer content without retraining the model. The retrieval corpus becomes a security-sensitive dependency.
- GPU side channels: Sharing a GPU across customers saves money but can introduce routes for information to leak between tenants.
- Model supply chains: Downloading models and add-ons from public sources without checking their provenance imports risk into the deployment.
These are directional concerns in a fast-moving field, with defenses that remain immature. They extend the boundaries that need protection: instructions versus input, trusted versus untrusted documents, one tenant versus another, and verified versus unknown artifacts.
The engineering agenda is to spend security effort where breaches occur and make existing controls work within production performance budgets. Another isolated attack–defense pair does not solve the deployment problem if teams cannot afford to keep the defense enabled. Repair overprivileged access, flat networks, and exposed secrets, then increase maturity deliberately. The database analogy ends with a concrete operational demand: lock down access, segment the network, and protect data at rest. The LLM stack adds new behavior, but it still needs those boundaries to hold.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The voluntary framework for managing AI risks throughout system design, development, deployment, and use.
Further reading
Oligo's investigation of compromised Ray servers, exposed credentials, compute abuse, and deployment mitigations.
The maintainers' 2023 explanation of Ray's external trust boundary and lack of built-in authentication.
Suggested actions and references organized around Govern, Map, Measure, and Manage.
Dmello's practical guide to combining self-hosted inference, request policies, CI security checks, human review, and operational metrics.
Updates since the talk
Configuration guidance for built-in authentication in Ray 2.52.0 and later, including token handling and transport protection.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hi, everyone. So my name is Lovina Dmello, and I'm a senior software developer at NVIDIA, and I work on the deep learning infrastructure team.
- 0:23
So the title here is a bit of provocation. What I really mean, and what I want you to leave with is, uh, for the next fifteen minutes, I am going to make one uncomfortable argument, which is almost everything that is breaking in the production ML security isn't some exotic AI attack.
- 0:45
It's the same boring infrastructure mistakes that we supposedly fixed years ago. So now, once, uh, you look across the research from the whole field, the pattern is very easy, like, it's very difficult to unsee.
- 1:02
Let me start with a story. So in two-- in twenty-twenty-three, security researchers went looking at Ray clusters, and Ray is one of the most popular framework for distributed ML.
- 1:17
So what they found out over there was there were thousands of clusters that were sitting open on the Internet. What that means is the dashboards were open, and there were job APIs that were open.
- 1:34
And why that happened? Because authentication was off by default, and somebody just forgot to turn it on while putting the ML in the, uh, in production.
- 1:53
So I'm a little bit short, you know. [laughing] [laughing]
- 1:57
So I need this. [laughing] Thank you. Okay. So, uh, the exposure at that time was a lot, like, it was over a billion dollars. So now let's sit with this part.
- 2:10
This was not a zero-day attack, and it was not a clever new attack, uh, on a neural network. So what happened was somebody just forgot to turn the default setting on while putting them into the production environment.
- 2:26
So it just depends upon what the configurations are on different deployment environments in the infrastructure. And when we look at the breaches that actually make the news, what we see, this is not a rule, it's not an exception, but it's almost never the fancy adversarial attack.
- 2:45
What is happening is it's maybe like s-somebody exposed an API key. What happened is maybe some account was just overprivileged. Maybe some mo-model weight was, uh, in a public bucket, and the whole breach, it's-- it was just like somebody forgot to flip.
- 3:07
So how did we get here? Let's rewind a little bit. So what used to happen is a classic two thousand and eight application was deterministic. So we could reason what the code w-would exactly do.
- 3:20
You know, it had a fixed perimeter, and it served one tenant. Security researchers or security team had a clear mental model. They knew, like, what they need to secure, and, like, great tools were built around that time.
- 3:38
So later, what happened is we put these machine learning models into production, and we quietly broke all of the three assumptions because behaviors became probabilistic. Correct is a distribution now.
- 3:52
It is not one branch, like we say yes or no. And then we are protecting the weights, which the weights are itself are copyable, and the leaks are straight through the API that we are trying to serve.
- 4:08
And to make it more affordable, we pack everything onto a shared multi-tenant GPU where other security risks come into picture. And now the LLM stack itself blows up wide open, and prompts become control flow, and answers come from retrieval corpora, and agents are going to take the actions for us.
- 4:32
So here is the thing: we changed everything about the stack when we moved to machine learning, but we forgot to change the security assumptions. So we are running a twenty-twenty-eight playbook on a twenty-twenty-six system.
- 4:47
That's all-- what the whole talk is about. So a few things, uh, five things stand out across all of this, and I have tried to boil them down into three core ideas.
- 4:57
Uh, and here they are. So first one is misconfigurations. So a lot of the times misconfigurations happen. It is not the missing features that are number one failure reason.
- 5:10
Second is the defenses that we are actually reading, they might not actually survive into production. And third one is we have to secure ML-like infrastructure, and it's not like securing just a model, you know?
- 5:25
And if we for-- if you forget everything about this talk, I want you to remember these three points over here. Uh, and I'll share a few couple of things at the end.
- 5:35
Uh, okay. So over here is a map I want you to carry with you. It's four pillars about the defenses in depth. So at the bottom, we can see the-- at the bottom in the black, we can see the infrastructure security.
- 5:52
Over here comes into picture the containers, the networks, the GPU virtualization, and encryption. On top-- So this infrastructure security is the foundation. And on top of it sits the access control, like who is allowed to do what, and then is the runtime security, which is checking, uh, and watching the
- 6:17
traffic while the system is live. So they feed each other and wrapping all of it, uh, to day-to-day practice, like, um, how the team works plus compliance, incident response, and honestly, the culture.
- 6:33
So one thing to remember over here is if, uh, infrastructure is the foundation and failures down there can cascade up. So if we have a perfect access control policy, it's just a decoration if the cluster underneath is wide open.
- 6:51
So yeah. So those are the four levels. And this is a quick map of what we are defending against. So there are six categories. The two are about the model itself, so where we have the adversarial inputs and we have the model extraction.
- 7:10
Over here, the primary defenses should be, uh, about how do we do the input validation, how we do the adversarial detection, how we do the rate limiting, API auth, and query analysis.
- 7:23
The next two are about the data and integrity. Over there comes the poisoning and supply chain and privacy breaches. So we should make sure that, um, over there we make sure to secure the CI/CD model signing and provenance, access control encryption, all of those comes into that picture.
- 7:43
And the last one are classic infrastructure, where, uh, we take care of, um, basically container isolation, network segmentation, uh, RBAC, and behavior analysis. So if we notice one thing over here, uh, the green ones, infrastructure compromise and insiders, those are exactly where the real breaches keep
- 8:08
landing, and they are the cheapest to get wrong by accident, which brings me to the core idea number one, which is mis- misconfiguration, not missing feature. So those-- That is one of the number one failure mode.
- 8:22
Um, okay. So let me walk you through one of the research. What happens is, researchers audited fifty real production setups running machine learning. In seventy-eight percent of them, what the researchers found out was at least one critical security mistake and w- And here's why that
- 8:47
mattered beyond engineering. So that was a misconfiguration and the difference between a normal Tuesday and something having a headline about our company in the news is this kind of incident where there could be like a critical misconfiguration mistake and,
- 9:07
and the same three problems kept showing up in this research study. First was access controls were left wide open. So what happens when an access controls are left wide open?
- 9:19
Almost any account can do almost anything. So that is one of the problem. Second is nothing sep-- nothing was separated. For example, different parts of the system. So once an attacker would get access to one part of the system, he could do anything in the whole system.
- 9:39
So there is the thing like separating different parts of the system. And the third one were the passwords and trained models. So themselves, they were sitting into a storage that anybody could reach.
- 9:54
So why does this keep happening? So because these productio-- uh, protections are built by security experts for security experts, and then they get handed to the ML teams, and, uh, the responsibility of ML team is, um, basically making the model accurate, not configuring the infrastructure.
- 10:14
So the protection is right there in the platform. It just sometimes get switched off by some configurations.
- 10:26
Okay, so now moving to the core idea two, which is defenses you read about don't survive into the production. So here is, here is the thing. Every control costs us something, and in ML, that something is latency and throughput.
- 10:45
The two things that LS-- SLA is made up of, let's watch the colors. So the green tier over here, the basics like logins, input checking, costs, tho- those cost under about eight percent, and that should always be there.
- 11:03
No debate over there. The second one is the orange tier. So this is like the heavier isolation that walls around that, uh, that walls workloads of each other. So here it runs ten to twenty percent.
- 11:19
So we can use it selectively. Like for sensitive and untrusted workloads, what we can do is we can decide if we want it or not. And the purple ones is catching malicious input in real-time.
- 11:32
So this is the most expensive one. Over here it can cost like, I don't know, fifteen to thirty percent, and it's one of the thing that researchers love the most.
- 11:42
But because we cannot slow every request down, so it's a non-starter. But what really matters is how much it costs depends almost entirely on how well we build it.
- 11:56
So the same security check, check, it can be done sloppily, and it can double our response time. But if it is done w- well, like considering all of these things, then it's fair, like the balance is fair.
- 12:11
So the guidance team actually need isn't should I do this? It's like, how do I do it without slowing everything down? And then we can run the cheap controls everywhere, and we can save the expensive ones for the heavier risk systems.
- 12:32
So here is the next slide. The ecosystem isn't production-ready yet. So what I meant is, um...
- 12:40
So there is the first gap that we will see. The security tooling for ML is years behind the rest of the software. So regular software teams, they solved a lot of this decades ago with automated security, scanning, proper passport-- uh, password management, and then we haven't cry, uh, carried it all over to ML yet.
- 13:04
Even today, there's a good share of early warning systems for ML-specific threats. So the second gap is in the expertise silos. So securities team don't speak ML, ML teams don't speak security, and the operation teams don't know how the model behaves.
- 13:22
So there is a gap over here, and the problem lives in the gaps. So between those gaps where nobody has the full picture, so there's a little bit of, uh, mismatch over here.
- 13:33
And underneath both is a gap between the research and reality. So recha-- research is busy defending against tiny, invisible tweets, but, uh, to an image that f- while the real world, we are fighting against the stolen password, and then people are misusing access that they already have, and it studies one model on
- 13:58
its own while we are running dozens of them, uh, on shared system. So what it lacks are one team can actually deploy everything. So there is this core idea number three, it's the constructive one.
- 14:13
So if the problem is infrastructure, we have to secure it like infrastructure, not like a model. And two practical tools for that are a maturity model to know where we stand and a short list of how to fix it first.
- 14:31
So here is, uh, the next slide. What we have to do is how to figure out where we actually stand. It's a maturity model that will help us map onto the NIST AI Risk Management Framework.
- 14:45
So there will be four levels, each tied to an overhead budget and the context. So on the level one, we can see that under five percent overhead is the bare basics.
- 14:58
Fine for test environment, not for production. So the level two, five to ten percent is a real baseline, like proper logins, encryptions, separating our networks, basic monitoring. This is the minimum bar for production.
- 15:12
And the level three adds more advanced controls that regulated industries like healthcare and finance needs. So on this part, most of the teams, uh, teams believe that they are at level three, but, uh, they are actually either at level one or two, like, it really depends how we have set up everything.
- 15:38
So on in this slide, I want to discuss about the three misconfiguration behind most of the risk. So the default setup often gives every account a full admin rights, so that is what have been observed in most of the research studies, with credentials that never expire.
- 15:56
So there are-- there have been credentials that do not have any expiry, and that can leak the key on its own. And, like, each account, like, should do only what it needs to do, and then the credentials to ex-- should expire very quickly.
- 16:17
Now, nothing stops one part of the system from reaching another part of the system. So if that can be tackled in a way, uh, then that can be solved.
- 16:27
Like attacker gets in one part of the system, and then they get it, can do everything. So that's, uh, like a flat network kind of issue. Then the fix.
- 16:38
So what we can do to fix this is we can wall the parts f-from each other, and we can require a verified identity between services, not just network access.
- 16:50
So there is an-another issue called the exposed secrets and models. So over there, passwords could be hardcoded in the code, model files sitting in the open storage. So the fix could be, like, a proper secret manager encryption and automatic scanning before sh- before all of this ships.
- 17:10
So this is nothing but like a basic hygiene, and this kind of hygiene can prevent breaches that actually make the news.
- 17:21
So, uh, here's the practical stuff. So now a couple of personal takes on where this is heading because the ground is moving very faster under us. So this is the part, uh, that least settled, and four things are on my mind right now.
- 17:37
So one is prompt injection. So the model can't reliably tell the difference between our instructions and someone else's input. So a cleverly worded message can quickly hijack the whole system.
- 17:54
So RAG poisoning, if our model pulls answers from a document store, and if the document store is poisoned by somebody or somehow, then what happens is it can poison, like, everything, and nobody has to retain anything, right?
- 18:11
So GPUs, so next is the GPU side channel. So where we can pack multiple customers on one GPU in order to save money. That time, information can leak from one customer to the other.
- 18:25
And another area is the supply chain. So what happens over there is we download models and add-ons from public sources without really checking where they come from. So that's another issue.
- 18:39
And the honest caveat over here is, uh, all of this moves very fast. Every week, something or the else comes up. So we treat it as a direction, not a gospel.
- 18:51
And the defenses are immature right now because, uh, the threats keep evolving.
- 18:59
Okay, so three t-- uh, so let's bring it together. If you forget everything I said today, here are the three takeaways. So one is securing ML is an infrastructural problem, not a model problem.
- 19:13
So we have to spend our budget where the breaches actually are happening. Second, the field has enough defenses. It just need deployable ones. The frontier isn't a new attack defense pair.
- 19:29
It's making the existing controls run with proper production overhead. And that's the engineering problem, which is a good news for a room full of engineers. And the third one is we have to fix the misconfigurations, like overprivileged accesses, flat networks, and exposed secrets.
- 19:48
So then climb the maturity model on purpose. Uh, and to close the loop, uh, on the title, your LLM stack really is a two thousand eight database with better marketing.
- 20:00
So secure it like a database, lock down accesses, segment the network, and protect the data at rest. So we already know how to do that. We just have to do it actually in a better way.
- 20:14
That's all. So thank you. [audience applauding] [outro jingle]