Your LLM Stack Is a 2008 Database With Better Marketing — Lovina Dmello, NVIDIA

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. 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 15 minutes I'm going to make one uncomfortable argument, which is: almost everything that is breaking in the production ML security isn't some exotic AI attack.

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. Let me start with a story.

So, in 2023, security researchers went looking at Ray clusters, and Ray is one of the most popular frameworks for distributed ML. 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. 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.

So I'm a little bit shot, you know. So I need this. 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. 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. 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.

What is happening is, it's maybe like 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.

So how did we get here? Let's rewind a little bit. So what used to happen is, a classic 2008 application was deterministic. So we could reason what the code wo- would exactly do, you know. It had a fixed parameter, 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. 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. 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.

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.

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 2028 playbook on a 2026 system. That's all what the whole talk is about.

So few things, uh, five things stand out across all of this, and I have tried to boil them down into three core ideas. 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. 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.

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. 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. 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 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. 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. 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. Over here, the primary defenses should be, uh, about how we do the input validation, how we do the adversarial detection, how we do the rate limiting, API auth, and query analysis.

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. 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 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. Um, okay. So let me walk you through one of the research.

What happens is, researchers audited 50 real production setups running machine learning. In 78% of them, what the researchers found out was, at least one critical security mistake. And, and here's why that 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, 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? Almost any account can do almost anything. So that is one of the problem. Second is, nothing se 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. 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. So why does this keep happening? So because this production, 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. So the protection isright there in the platform. It just sometimes gets switched off by some configurations.

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.

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, cost, tho-those cost under about 8%. And that should always be there. 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 10 to 20%. 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. So this is the most expensive one. Over here, it can cost like, I don't know, 15 to 30%. And it's one of the thing that researchers love the most.

But because we cannot slow every request down, so it's a non-starter. But what really matters is, how much it cost depends almost entirely on how well we build it. So the same security check, it can be done sloppily, and it can double our response time.

But if it is done wo-well, like considering all of these things, then it's fair. Like, the balance is fair. 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.

So here is the next slide. The ecosystem isn't production ready yet. So what I meant is, um, 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 password management. And then we haven't cri uh, carried it all over to ML yet. 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. 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. And underneath both is a gap between the research and reality. So reacher research is busy defending against tiny, invisible tweets.

But, uh, to an image that 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 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. 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. 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. 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 5% overhead is the bare basics, fine for test environment, not for production.

So the level two, 5 to 10% is the real baseline, like proper logins, encryptions, separating our networks, basic monitoring. This is the minimum bar for production. And the level three adds more advanced controls that regulated industries like healthcare and finance needs.

So honest part, most of the teams 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.

So 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 adminright. So that is what have been observed in most of the research studies, with credentials that never expire.

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.

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. 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. So what we can do to fix this is, we can wall the parts from each other. And we can require a verified identity between services, not just network access.

So there is an another issue called the exposed secrets and models. So over there, passwords could be hard-coded 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 before all of this ships.

So this is nothing but like a basic hygiene. And this kind of hygiene can prevent breaches that actually make the news.

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's least settled. And four things are on my mindright now.

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. 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? 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.

And another 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. 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. And the defenses are immatureright now because, uh, the threats keep evolving.

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. 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. 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. So then climb the maturity model on purpose. And, and to close the loop, uh, on the title, your LLM stack really is a 2008 database with better marketing.

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. That's all. So thank you.