Talk by Lovina Dmello (NVIDIA) arguing that production ML/LLM security failures are dominated by misconfiguration rather than missing features. Drawing on a review of 139 peer-reviewed papers on production ML security, the talk highlights recurring causes such as the 2023 exposure of thousands of Ray clusters (exposed dashboards and job APIs due to authentication being off by default) and an audit of 50 real systems in which 78% contained a critical mistake, typically overprivileged accounts, flat networks, or publicly readable secrets and model weights. It also notes that heavyweight defenses often fail in production due to 15-30% inference overhead, and proposes treating ML systems as infrastructure to secure, rather than securing the model itself. # Channel Presentation Observations — Lovina Dmello, NVIDIA ## Explicit Self-Description Evidence - The speaker identifies herself directly at the open: > "my name is Lavina D'Mello and I'm a senior software developer at Nvidia and I work on the deep learning infrastructure team." - She frames the talk's purpose explicitly: > "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." - She flags a portion as opinion rather than established fact: > "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." ## Claimed Scope of the Talk - **Topic scope**: Production ML/LLM security treated as an infrastructure problem, not a novel-AI-attack problem. - **Structural claims**: She promises "five things stand out… I have tried to boil them down into three core ideas" — (1) misconfigurations, not missing features; (2) defenses that don't survive production; (3) secure ML like infrastructure. - **Framework claims**: She presents a "four pillars" defense-in-depth map, a six-category threat map, a maturity model mapped to the **NIST AI risk management framework**, and overhead-cost tiers (e.g., "green tier… costs under about 8%", isolation "10 to 20%", real-time detection "15 to 30%"). - **Research citation pattern (described, not named)**: She references studies without naming sources — e.g., a 2023 Ray cluster exposure ("over billion dollars"), and "researchers audited 50 real production setups… In 78% of them… at least one critical security mistake." ## Observable Presentation Style - **Provocative framing**: The title ("Your LLM Stack Is a 2008 Database With Better Marketing") is acknowledged as deliberate: "the title here is a bit of provocation," and revisited in the close: "your LLM stack really is a 2008 database with better marketing." - **Conference-talk format**: Applause and laughter markers, time-boxed ("15 minutes"), and direct audience address ("if you forget everything I said today, here are the three takeaways"). - **Practitioner orientation**: Emphasis on actionable takeaways — "the guidance teams actually need isn't should I do this, it's like how do I do it without slowing everything down." - **Epistemic hedging**: She caveats uncertain areas — "we treat it as a direction, not a gospel, and the defenses are immature right now because uh the threats keep evolving." ## Intended Audience (Demonstrated) - **ML/platform engineers and engineering leadership** in production environments, evidenced by: - "which is a good news for a room full of engineers" - Discussion of SLAs, latency/throughput budgets, CI/CD, RBAC, network segmentation, GPU virtualization - Explicit framing of the closing problem as "an engineering problem" - Audience assumed to span **ML teams, security teams, and operations**, mirroring her expertise-silos point: "security team don't speak ML, ML teams don't speak security." ## Demonstrated vs. Claimed — Distinction Notes - **Demonstrated**: Deep familiarity with production ML infrastructure (containers, multi-tenant GPUs, Ray clusters, model signing/provenance) and the ability to synthesize research into frameworks. - **Claimed but unverified in-source**: Specific research figures (78%, cost tiers, billion-dollar exposure) are asserted without named citations in the transcript; no curated metadata was provided to corroborate. - **No channel-wide statements**: The talk contains no explicit description of the channel itself; all identity evidence pertains to the speaker's employer role and the talk's scope. # Delivery Observation — Lovina Dmello, "Your LLM Stack Is a 2008 Database With Better Marketing" ## Tone & Register - **Provocative but grounded**: opens by flagging the title as deliberate provocation, then immediately reframes it: *"the title here is a bit of provocation. What I really mean and what I want you to leave with is… for the next 15 minutes, I'm going to make one uncomfortable argument."* - **Conversational, filler-heavy delivery**: frequent *"So,"* sentence starters and *"uh"*/"um" fillers throughout — e.g., *"So, let me walk you through one of the research."* - **Spoken, informal phrasing** rather than polished script: *"it's it was just like somebody forgot to flip."* ## Teaching Habits - **Signposting core takeaways repeatedly**: - *"if you forget everything about this talk, I want you to remember these three points"* - Closing echo: *"If you forget everything I said today, here are the three takeaways."* - **Story-first structure**: opens the technical argument with a concrete case — the 2023 Ray cluster exposure: *"Let me start with a story. So, into in 2023, security researchers went looking at Ray clusters."* - **Numbered framing**: organizes content into *"three core ideas"*, a *"four pillars"* defense map, and *"six categories"* of threats. - **Contrast as a rhetorical device**: repeatedly pairs old vs. new — *"we are running a 2028 playbook on a 2026 system"*; *"research is busy defending against tiny invisible tweets… while the real world, we are fighting against the stolen password."* - **Callback to the title**: closes by resolving the provocation — *"your LLM stack really is a 2008 database with better marketing. So, secure it like a database."* ## Recurring Phrases & Vocabulary - **"Somebody forgot"** as a recurring motif for misconfiguration: - *"somebody just forgot to turn it on"* - *"somebody just forgot to turn the default setting on"* - *"somebody forgot to flip"* - **Repetition of "core idea"** as a structural anchor: *"core idea number one, which is misconfiguration"*, *"core idea two"*, *"core idea number three."* - Domain vocabulary consistently deployed: *misconfiguration, over-privileged, flat network, supply chain, provenance, RBAC ("R back"), segmentation, SLA, latency/throughput*. ## Concrete-Numbers Teaching - Cites specific figures to ground claims: *"researchers audited 50 real production setups… In 78% of them… at least one critical security mistake"*; overhead tiers of *"under about 8%"*, *"10 to 20%"*, *"15 to 30%"*. - Uses cost framing for engineering tradeoffs: *"Every control costs us something. And in ML that something is latency and throughput."* ## Honesty & Uncertainty Markers - **Explicit epistemic hedging**: *"it can cost like I don't know, 15 to 30%"*; *"this is the part that's least settled."* - **Frames predictions as provisional**: *"we treat it as a direction, not a gospel."* ## Audience Awareness - **Tailors the close to the room**: *"that's the engineering problem, which is a good news for a room full of engineers."* - Acknowledges live audience feedback: *"So, I'm a little bit short, you know. >> [laughter] >> So, I need this."* ## Stability vs. Isolated Moments - **Stable patterns**: "So,"-initial sentences, three-part structure, "forgot to" motif, takeaway repetition — all occur repeatedly across the talk. - **Isolated/uncertain**: the transcript contains garbled passages (likely ASR errors), e.g., *"defending against tiny invisible tweets"* and *"we are running a 2028 playbook on a 2026 system"* — these may be transcription artifacts rather than the speaker's exact words, so delivery judgments on those phrases are low-confidence. # Position Record: "Your LLM Stack Is a 2008 Database With Better Marketing" — Lovina Dmello, NVIDIA ## Speaker - **Lovina Dmello**, self-identified senior software developer at NVIDIA, deep learning infrastructure team. Sole substantive speaker. ## Central Thesis - Most production ML security failures are **not exotic AI attacks** but "the same boring infrastructure mistakes we supposedly fixed years ago." - Closing claim: > "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." - Speaker framed the title as "a bit of provocation" and characterized her argument as deliberately "uncomfortable." - Notable inconsistency preserved: she stated "we are running a **2028 playbook** on a **2026** system" — apparently misspoken, intended presumably as an old playbook on a new system. ## Evidence and Claims ### Opening Case Study (Ray clusters, 2023) - Security researchers found **thousands of Ray clusters open on the internet** — open dashboards and job APIs — because **authentication was off by default** and someone "forgot to turn it on" in production. - Exposure estimated at **over a billion dollars** (speaker's figure, no source cited). - Speaker's interpretation: not a zero-day or novel neural-network attack; a default-configuration failure. - Observed breach pattern (speaker: "not a rule, it's not an exception"): exposed API keys, over-privileged accounts, model weights in public buckets — rarely "fancy adversarial attacks." ### Research Audit Cited - Researchers audited **50 real production ML setups**; **78%** had at least one critical security mistake. (Study not named in transcript.) - Three recurring problems: 1. **Access controls wide open** — almost any account could do almost anything. 2. **No separation** — compromise of one component compromised the whole system. 3. **Passwords and trained models in publicly reachable storage.** - Causal explanation offered: production protections are built by security experts for security experts, then handed to ML teams whose responsibility is model accuracy, not infrastructure configuration. ### Historical Framing - Classic 2008 applications: deterministic, fixed parameters, single tenant — security teams had a clear mental model. - ML production broke all three assumptions: behavior became **probabilistic**, weights are copyable, leaks occur through the serving API, shared multi-tenant GPUs add risk, prompts became control flow, retrieval corpora supply answers, agents take actions. - Claim: "We changed everything about the stack when we moved to machine learning, but we forgot to change the security assumptions." ## Core Ideas (speaker's three takeaways) 1. **Securing ML is an infrastructure problem, not a model problem** — spend budget where breaches actually happen. 2. **The field has enough defenses; it needs deployable ones** — the frontier is running existing controls with acceptable production overhead, an engineering problem. 3. **Fix misconfigurations** (over-privileged access, flat networks, exposed secrets) and climb the maturity model deliberately. ## Defense Frameworks Presented ### Four Pillars (defense in depth) - **Infrastructure security** (foundation): containers, networks, GPU virtualization, encryption. - **Access control**: who is allowed to do what. - **Runtime security**: watching live traffic. - **Practice layer**: team process, compliance, incident response, culture. - Claim: "If we have a perfect access control policy, it's just a decoration if the cluster underneath is wide open." ### Six Threat Categories - Model: adversarial inputs, model extraction → input validation, adversarial detection, rate limiting, API auth, query analysis. - Data/integrity: poisoning, supply chain, privacy → CI/CD security, model signing, provenance, access control, encryption. - Infrastructure: compromise, insiders → container isolation, network segmentation, RBAC, behavior analysis. - Speaker's observation: infrastructure compromise and insiders (green categories) are "exactly where the real breaches keep landing" and cheapest to get wrong by accident. ### Defense Cost Tiers (speaker's figures, sources not cited) - **Green (basics: logins, input checking):** under ~8% overhead — always on, "no debate." - **Orange (heavier isolation):** 10–20% — use selectively for sensitive/untrusted workloads. - **Purple (real-time malicious-input detection):** 15–30% — most expensive; "researchers love the most" but slowing every request is "a non-starter." - Qualification: cost "depends almost entirely on how well we build it" — same check done sloppily can double response time. Teams need guidance on *how* to implement, not *whether*. ### Maturity Model (mapped to NIST AI RMF) - Level 1 (<5% overhead): bare basics — fine for test, not production. - Level 2 (5–10%): production minimum — proper logins, encryption, network separation, basic monitoring. - Level 3+: advanced controls for regulated industries (healthcare, finance). - Speaker's assessment: most teams **believe** they are at level 3 but are actually at level 1 or 2. ### Three Misconfigurations and Fixes 1. **Default full admin rights / non-expiring credentials** → least-privilege accounts, short-lived credentials. 2. **Flat networks** (any component reaches any other) → segmentation, verified service identity beyond network access. 3. **Exposed secrets and models** (hardcoded passwords, open model storage) → secret managers, encryption, pre-ship automated scanning. - Framing: "basic hygiene" that prevents the breaches that make headlines. ## Ecosystem Gaps - **Tooling:** ML security tooling "years behind" regular software, which solved automated scanning and password management decades ago. - **Expertise silos:** security teams don't speak ML, ML teams don't speak security, ops teams don't know model behavior; "the problem lives in the gaps." - **Research–reality mismatch:** research defends against "tiny invisible tweaks to an image" while real-world attacks use stolen passwords and misused legitimate access; research studies single models while production runs dozens on shared systems. ## Personal Predictions (explicitly flagged as unsettled) Speaker labeled these "a couple of personal takes" and "the least settled" part of the talk: - **Prompt injection:** models can't reliably distinguish instructions from untrusted input. - **RAG poisoning:** poisoned document stores poison outputs. - **GPU side channels:** multi-tenant GPU packing can leak information between customers. - **Supply chain:** models and add-ons downloaded from public sources without provenance checks. **Caveat stated:** "All of this moves very fast… we treat it as a direction, not a gospel, and the defenses are immature right now." ## Source Notes - Statistics and studies cited in the talk (Ray exposure figure, 50-setup audit, 78% figure, overhead percentages) are attributed to the speaker without named sources in the transcript. - Audience laughter and applause noted; one interruption for podium adjustment. # Speaker Attribution & Provenance Record ## Video - **Title:** Your LLM Stack Is a 2008 Database With Better Marketing — Lovina Dmello, NVIDIA - **ID:** `01a15ca8-6faa-7c99-aa37-3802736b7aea` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Lavina D'Mello (transcribed as "Lovina Dmello" in title) | **Creator / Presenter** — self-identified: *"my name is Lavina D'Mello and I'm a senior software developer at Nvidia and I work on the deep learning infrastructure team"* | Single continuous talk | | Audience | Unidentified crowd — **[laughter]** and **[applause]** markers only | No speaking lines | - **No** narrator, guests, or other identified speakers. - No speaker metadata beyond the transcript was supplied. ## Referenced Sources & Third-Party Claims - **2023 security research on Ray clusters:** researchers found thousands of clusters exposed online (authentication off by default); exposure "over billion dollars." *Researchers not named.* - **Audit of 50 production ML setups:** 78% contained at least one critical security mistake. *Study not named.* - **NIST AI Risk Management Framework:** maturity model mapped to it. - Repeated appeals to unnamed **"research"** / "research studies" — no specific citations given. ## Promotional Segments - **None detected.** No product, service, or company promotion beyond the speaker's employer affiliation. ## Availability & Limits - **Comment availability:** not indicated (no metadata supplied). - **Uncertainty:** unnamed studies, unverifiable figures; speaker explicitly flags personal takes as "least settled" and advises treating them "as a direction, not a gospel." \>\> Hi everyone. So, my name is Lavina D'Mello 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, into in 2023, security researchers went looking at Ray clusters. And Ray is one of the most popular framework 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 them ML in them uh in production. So, I'm a little bit short, you know. \>\> \[laughter\] \>\> So, I need this. Thank you. Okay. So, uh the exposure at that time was a lot. Like, it was over 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 over-privileged. Maybe some more 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 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 this 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 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 risk 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 what the whole talk is about. So few things, five things stand out across all of these and I have tried to boil them down into three core ideas. Uh and here they are. So first one is misconfigurations. So 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 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 life. 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 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, our classic infrastructure, where we take care of um basically container isolation, network segmentation, uh R back, 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 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 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. 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 protections are built by security experts for security experts and then they get handed to the ML teams. And the responsibility of ML team is um basically making the model accurate, not configuring the infrastructure. So, the protection is right there in the platform. It just sometimes get 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 SLA is made up of. Let's watch the colors. So, the green tier over here, the basics like logins, input checking, costs do 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 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 check, it can be done sloppily and it can double our response time. But, if it is done 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 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 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, security 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 leaves in the gaps. So, between those gaps where nobody has a full picture. So, there's a little bit of mismatch over here. And underneath both is a gap between the research and reality. So, research is busy defending against tiny invisible tweets. But 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 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 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 a 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 health care and finance needs. So, on this part, most of 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, on 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, 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 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 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 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. Uh 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 mind right 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 uh 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 immature right now because uh the threats keep evolving. Okay. So, three 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 over-privileged accesses, flat networks, and exposed secrets. So, then climb the maturity model on purpose. And to close the loop 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. \>\> \[applause\]