← All AI Engineer talks

AI Engineer World's Fair 2026

Your LLM Stack Is a 2008 Database With Better Marketing

About this talk

NVIDIA infrastructure engineer Lovina Dmello argues that production ML and LLM breaches usually arise from familiar infrastructure misconfigurations rather than exotic model attacks. Using exposed Ray clusters as an example, she maps threats across model, data, supply-chain, and infrastructure layers; examines the latency and throughput costs of security controls; and recommends authenticated access, least privilege, short-lived credentials, container isolation, network segmentation, and protection of stored data.

Chapters

  1. 0:00Introduction: ML security failures are infrastructure failures
  2. 1:02Exposed Ray clusters and unauthenticated job APIs
  3. 3:20LLM infrastructure attack surfaces and shared GPUs
  4. 6:51Threat categories, supply chains, access controls, and segmentation
  5. 9:54Production security overhead and organizational silos
  6. 15:56Short-lived credentials and the database-security conclusion

Talk transcript

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

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

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

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

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

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

  7. 1:53

    So I'm a little bit short, you know. [laughing] [laughing]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  32. 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,

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

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

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

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

  37. 10:14

    So the protection is right there in the platform. It just sometimes get switched off by some configurations.

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

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

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

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

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

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

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

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

  46. 12:32

    So here is the next slide. The ecosystem isn't production-ready yet. So what I meant is, um...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  63. 17:10

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

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

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

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

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

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

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

  70. 18:51

    And the defenses are immature right now because, uh, the threats keep evolving.

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

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

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

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

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

  76. 20:14

    That's all. So thank you. [audience applauding] [outro jingle]