Vulnerabilities In Enterprise AI Workflows With Nicolas Dupont

Speaker A: Vector embeddings are just math, right? They are representations of context, of semantic meaning, right? And so it makes sense, both theoretically and in practice, that these dense representations can be inverted back to the text in the original modality or whatever that is. The problem there is that there's a common misconception that they are like one way hashes or just you don't really think about it because they're not humanly, you know, they're not intelligible to humans.

Speaker B: It's numbers.

Speaker A: Numbers, exactly. Like, how bad could it be? But they need to be treated with the same level of sensitivity as the original data they represent. And furthermore, they are being centralized into these places. And so you're compounding the risk without addressing the foundational problems.

Speaker C: You are listening to the Secure Developer, where we speak to industry leaders and experts about the past, present and future of DevSecOps and AI security. We aim to help you bring developers and security together to build secure applications while moving fast and having fun. This podcast is brought to you by Snyk. Snyk's developer security platform helps developers build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open source dependencies, containers and infrastructure as code, all while providing actionable security insights and administration capabilities. To learn more, visit Snyk IO tsd.

Speaker B: Hello and welcome back to another episode of the Secure Developer. I'm Danny Allen, CTO@Snyk, and I'm super excited to be with you today because I have a very special guest that I have known, I'm going to say almost a decade now, going back through several companies, and that is Nicholas Dupont from Cyborg. Nicholas, maybe you can just introduce yourself to the audience what you do and what Cyborg is all about.

Speaker A: Yeah. Hey, Danny, really good to see you again. Thanks for, thanks for having me. I'm, uh, Nicholas Dupont, the CEO and founder of, uh, Cyborg. You may know me as Nicholas Nick Nico, depending on where and when you met me. And I've been working in the, uh, in the technology industry both as a software engineer and an entrepreneur for about a decade. The first four years working on lossless data compression, and the ensuing, you know, five, six years working in privacy enhancing technologies and applied cryptography, namely encrypted vector search, which is what we're currently working on at Cyborg to be able to address some of the lesser known security vulnerabilities with, uh, agentic AI applications.

Speaker B: I love the fact, Nicholas, that you've been in security for so long. I always tell people that I started in security doing homomorphic encryption and kind of things, uh, things around that, and I, I drifted off into cloud and back up in other areas. And here I am back full bore in security. But I love that you've been security all along. And in fact, I think when I first met you, you were doing sharded encryption across clouds of data storage. Isn't that right?

Speaker A: That's right. That's right. Distributed encrypted search. So similar technology to what we're working on today, but we were, you know, still finding our footing as to where the real value was in the market. And I think we're, we're in a better place now, I hope, than we were when we were working on the distributed stuff.

Speaker B: Well, the interesting thing about security is there's always application of security to everything we're doing. In fact, I think about here at snyk, where I work, we're always looking at security for AI is the big thing right now. How do we take AI actually and use it within our platform for better security? And so AI for security in that case. But you tend to work on security for AI at Cyborg. So rather than using AI within your platform, you're, how do we secure the implementation of AI? Am I understanding that correctly?

Speaker A: Yeah, yeah, that's exactly right. And maybe it would be helpful for me to zoom out, lay the landscape a little bit as to what, what we're trying to solve to set the conversation. So over the past, you know, call, uh, IT three years, the center of gravity in the world of AI was largely around training, you know, who had the GPU clusters, who was able to train the biggest models, frontier capabilities, etc. Today we're kind of in an inflection point where all the stakeholders involved, namely customers and investors, are asking to see ROI from their massive AI investments, both in hardware and in software. And the way that you get ROI from AI is through inference, by not building the model, but by letting it run and do what it was built to do at scale and in the context of the enterprise. In enterprise AI, in order to drive value, a model, uh, needs to have access to proprietary data to be able to glean insights from that proprietary data in order to take action off of that data. And that creates a whole host of vulnerabilities in that enterprise AI context. Namely, you're centralizing data that was traditionally siloed across different sections of the organization, from finance and hr, CRM and marketing, engineering, engineering, so on and so Forth into a centralized vector database or a vector store or set of those that makes the attack surface smaller, but makes the blast radius of a breach there significantly larger. You add in the context of agents to the flow that need access to that data and need to be able to make autonomous decisions off of that data. But typically you're over provisioned in the access that they have to the data. Um, that creates another vulnerability. This vector store typically also is used, or can be used not only as a knowledge base, but also as the memory of the agentic AI system. And that opens up the threat vector of prompt injection. Uh, the list goes on and I think I'm hinting at what we're focusing on here, which is the vector store, the common denominator across all of these things. Um, vector databases centralize all this data. They, they store the, these dense semantic representations of the original data as vector embeddings, which can be inverted back into the original modality of, you know, text, images, audio, et cetera, relatively trivially. And they are comically under equipped to be able to deal with the security risk that they pose today. So that's what we solve.

Speaker B: And so the, in an LLM world or an AI world rather than structured database, you have a vector database. And, and uh, what I'm hearing is that people assume that it can't be reverse engineered to extract the data, but the reality is it can be reverse engineered to extract the original data from the vector database. Is that.

Speaker A: Yeah, that's right. I mean it's, it's really a vector embeddings are just math.

Speaker C: Right.

Speaker A: They are representations of context, of semantic meaning. Right. And so it makes sense both theoretically and in practice that these dense representations can be inverted back to the text in the original modality or whatever that is. The, the problem there is that there's a common misconception that they are like one way hashes or just you don't really think about it because they're not humanly, you know, they're not intelligible to humans.

Speaker B: It's numbers.

Speaker A: Numbers, exactly. Like how bad could it be? But uh, they need to be treated with the same level of sensitivity as the original data they represent. And furthermore they are being centralized into these places. And so you're compounding the risk without addressing the foundational problem. So you can address maybe the prompt injection risk by having guardrails of whatever input is coming in, including the context added in a rag scenario, but then you're still leaving all of the gaps, the other gaps, unaddressed by Leaving these, you know, vector embeddings in plaintext and easily accessible and leaking everywhere.

Speaker B: So let's start with that. Then, the breach of a traditional structured database. You know, I tend to think of SQL injection. Someone inserts a command, extracts the data and dumps it out. And so obviously we, we encrypt, you know, our structured databases. How does a breach take place in a vector database? How do you get in to the data within that database? And what is the specific attack model that that malicious individual or a, uh, malicious actor would, would take?

Speaker A: To answer that question, I'll caveat it first by saying that we're still in the infancy of production rollout of AI in enterprise, so we haven't seen any of these attacks in the wild, but we've seen them, you know, in controlled environments as, you know, exploit demonstrations. Um, so the, the vectors through which you can attack a vector database, uh, no pun intended, are pretty similar to the way that you would attack a standard database. So you've got the injection attacks, you've got any type of infrastructure compromise, you know, leaked SSH keys, having, you know, open ports, et cetera, unsecured infrastructure. And you also have the fact that most vector databases have only one way of securing access to the data for both injecting data into it and extracting from it, which is an API key. Now, API keys are notoriously leaked all the time. You know, whether you're a startup and you commit something to git or even Microsoft has this happening, you know, on a weekly basis. And so it's not a good factor for this security of this, you know, centralized knowledge base. And then furthermore, once you get in compared to a standard relational database that has the past 50 years of learn experience in terms of securing access with various levels of encryption at rest and times in use, vector databases rarely have any type of encryption at all. Those that do have encryption at rest and in transit, but not in use. And that's both as a factor of the infancy of the technology and also an architectural decision. Because vector databases, compared to relational databases and key value stores, NoSQL databases, need the vectors to be in plaintext in order to do the similarity search, right? So when you're doing a query on a vector database, you're not doing a where clause with SQL and scanning through or just looking at an index. You are providing a query vector embedding and you're trying to find all of the items that are, you know, the closest to that for top K. And in order to do that, you need to literally Compute the Euclidean distance or the cosine angle between that query vector embedding and all the candidate embeddings. There are ways to accelerate it through approximate nearest neighbor search ANN algorithms. And all the vector databases do this, but the common denominator here is that they're all doing this in plain text. So if you want a fast, low latency access, which is typically what you care about in a rag scenario, in agentic AI, et cetera, you want high throughput, low latency applications with no patching, you, you run into this problem where if you, if you have to read from disk from encrypted, and each time you encrypt it, you get significant performance hits. And so none of them are doing that. And you know, they're kind of throwing away security and that granular data control for performance.

Speaker B: And so is your TLDR on this that they should be encrypted knowing that there's a performance hit when you're trying to query and find the nearest neighbors on the vector, um, embeddings.

Speaker A: No, I mean, I fundamentally, if you're trying to, you know, pick between functionality and security, unfortunately, as you and I both know, functionality almost always wins out. And that's not what we want to hear. But that's, that's just the truth. It's, it's like the laws of physics. What we believe is that there needs to be innovation in this space that can address the performance hits from encryption to be able to meet to mitigate those to a point where it's an acceptable trade off. And so that's exactly what we've been working on, on, on being able to do that similarity search while keeping the vectors encrypted, so not add the overhead of decrypting everything in order to be able to do the similarity search, but actually do the similarity search over ciphertext using standard cryptography such that the overhead is significantly mitigated. Instead of being several orders of magnitude slower, you're talking about, you know, a 10 to 15% performance hike.

Speaker B: Yeah. In many ways this brings me back to homomorphic encryption because the thesis there always was I'll deal with the data while it's still encrypted and be able to do the analysis that I need to do. This is doing the same thing, but for vector databases, which of course are behind AI. Uh, talk to me a little bit then about prompt injection on this. So you have these vector databases, they're storing all the numerical values of the text embeddings and all the content that you're querying on how does prompt injection work against a vector database and what should we be thinking about there for security?

Speaker A: Great question. I mean it's not something that architects typically think about when building out their, their AI applications as the vector database being a threat vector for prompt injection. But it really is for two main reasons. I mean really for one reason and multiple vectors that can uh, that, that can inject that. That is the vector database is there in order to be able to supply context to the LLM, to be able to answer a question or to be able to take an action in an agentic AI workflow. And so that context is fed in typically in the original modality or in some sort of pre processed, you know, text image, whatever the modality of the LLM M to be able to take that action. And so that's a vector to be able to do a prompt injection attack that does not, that can bypass the user prompt. And so if you've got guardrails at the user prompt but not at the context phase, if the context can carry a malicious payload, then the prompt injection can happen through that. That means. And so without proper access controls around your vector database, you not only have to worry about exfiltration of the data and getting a nice cross section of the organization centralized knowledge base, but also injection of malicious data that then can poison further downstream applications.

Speaker B: Uh, so that is impacting at some level the integrity of the model itself. Future queries.

Speaker A: Exactly. It's like adding a system prompt that is subverting the intent of the user at every query.

Speaker B: And are you, is this all theoretical at this point for developers? Is this something that we've hit in the, in the real world? I'll say in practical areas that uh, attackers have gone in and tried to do this uh, exact thing against vector databases.

Speaker A: The prompt injection one we haven't seen, the leaked API keys we've seen everywhere. And so it's not to connect. Unfortunately the prompt injection attack is one that we've seen in academia. It's one that we've done demos of, uh, you know, uh, on stage, at conferences, live demos. And it's one that, because it's relatively trivial to do, you know, using one of these entry points, it's only a matter of time until we see it, especially as enterprises start to ramp out, you know, ramp up and out these, these enterprise AI applications into production in consumer customer facing environments.

Speaker B: And what do you, what is the right compensating control? When I think of injection on a, on a relational database, I think of well, if I go back 20 years it was prepared statements or stored procedures or whatever. What are the compensating controls against that type of attack uh, on a vector database?

Speaker A: Well it's really control of who and what has access to has the ability to add data to the database. Right. And so you get into, it gets very hairy when you get into agentic workflows where the agents are over provisioned with writes and especially if you're using the vector database not only as a knowledge base that may be relatively static in the organization, but also as a memory store for further chats or for further workflows that need to be to be run. And so in that case you now have the complexity of controlling everything that's added to the vector database not only during index building time and the pre processing of knowledge base, but at uh, inference time at all times. Right. So that requires in my opinion, two things. Firstly, limiting the authorization scopes of who has, who and what has access to be able to add data to the database. And then secondly, uh, ensuring that there is a robust foundational layer of security at the vector store basis such that if an API key is leaked, if you know an agent is over provisioned, you still have a cryptographic backstop that essentially provides you with mathematical guarantee guarantees that data uh, could not be added to it without proper access, without having access to the encryption keys or data cannot be read from it. Such that. And in this rapidly evolving world, I think that again trying to address each one of the gaps, you know, with point solutions as opposed to addressing kind of the security basis of the vector store is mhm playing a game of whack a mole and we're going to keep seeing new vulnerabilities pop up as this area changes so rapidly and it's going to be impossible to keep up with it.

Speaker B: One of the things that we've been struggling with is the security of humans in an AI world versus security of agents. Do you think that compensating controls are different? In other words, you have humans going in and you know, accessing the vector database and doing the queries on the alarms and that you also have agents as you mentioned, you think it's the exact same controls between them and it's just a matter of type or. No, there are actually distinct controls that you'd want to implement?

Speaker A: Um, I think the latter, I think, I mean it's every layer of the stack, right? So m looking at the vector store fundamentally what you should be looking for is encryption and use is granular encryption. To where each vector is encrypted, all of its associated metadata, um, IDs contents stored within the vector store uniquely for each vector.

Speaker B: Like a unique cryptographic key for each vector.

Speaker A: Either that or on a per index per namespace. That really depends on the application and what the threat vector and the threat model specifically is. And if you want to also have cryptographic role based access control such that each vector has its own entity and access control list that then can, can, can be reclassified without needing to uh, re. Encrypt the vectors themselves.

Speaker B: Mhm.

Speaker A: But having that basis then allows you to build up the stack to use those primitives to ensure that the security is robust all the way upstream. And so I think once you get to the you know, the uh, agentic workflows and having at that application layer where you're building and tying in, you know, authentication and authorization workflows for those agents, then I think it does diverge. And I think some of your previous episodes on this podcast will do a much better job than I will talking about that distinction. But I think it really depends on the, the application whether the agent is, you know, treated as a service role that has access to data, whether there's a human in the loop to be able to provide authorization based on, you know, certain, you know, break the glass scenarios. That, that largely depends. But I think fundamentally at a. From the, the vector store in the data plane, it, it's all the same. What matters is.

Speaker B: Mhm.

Speaker A: Granular cryptography that allows you to be able to enable that flexibility while maintaining the common security throughout the applications.

Speaker B: It's definitely interesting. I see a lot of applications that are built such that there's just in time encryption keys for individuals and humans and they're doing generally the right things. But when it comes to agents, the agents are wide open. They can do everything from delete files to drop tables in a database, do whatever they want.

Speaker A: Because we saw it happen in production, right. With Replay.

Speaker B: Yes. Yeah, there was something to just recently a CEO was playing around and he lost a database, right?

Speaker A: Yeah, yeah. It was like something like a couple thousand of CISO entries in their, in their production database. It's crazy stuff.

Speaker B: Yeah. And it's because agents are assumed to have more, I don't know, controls or they're trusted more for some strange reason, which in my mind they shouldn't be. It's just another mechanism service account that is no more trusted than an individual. In fact maybe less trusted because especially when they become autonomous.

Speaker A: Yeah, absolutely. And we're seeing some concerning trends, I think it might have been sneak that had a developer survey recently that showed that developers believe that AI generated code was more secure than human code. Right. So this mis, I mean it's just with any uh, anecdotal evidence I can attest that that's not the case at all. And you know, you will tell claude code, hey, are you sure this is secure? Oh, you're absolutely right, this is not. And without that initial pass, how can you trust that giving it access to everything within your organization with this over provisioned role, but nothing will go wrong. I think it's a ticking time bomb.

Speaker B: Well, it's very clear we need security for AI, uh, and specifically security for vector databases behind it. This is all a security conversation though. And one of the things that I think we often miss or forget about is privacy and delegating access. We have an entire legislation around this over in the EU GDPR about delegating access to data. Is there implications in vector databases and LLMs that also matter when it comes to privacy and the right to access and the right to be forgotten? Are uh, there ways to address that in these vector databases?

Speaker A: 100%. I'm glad you bring that up because I often like to say you can have security without privacy. We see it all the time. You can't have privacy without security. Right. And so within that context, cryptography is one of privacy's best friends here because a, it allows you to have robust controls around what can be accessed when and how through you know, these mathematical guarantees of the confidentiality of the data in its encrypted state. And additionally it makes the job of compliance with these regulatory frameworks significantly easier by reducing the burden by ensuring that your data is encrypted at all times and that you don't have to rebuild, you know, re engineer the wheel each time that you're building an application. And the same thing is true in enterprise AI scenarios. So you know, whether it be with GDPR or in applications in regular, in you know, traditional regulated industries like healthcare under HIPAA, uh, you know, financial services under FINRA and PCI DSS federal applications under FedRAMP, you have you know, robust security and privacy, uh, requirements that need to be met already owners to be able to meet today. And you're adding in, you know, a centralized vector store that contains all of the data and where you're doing access control just based on metadata filtering, where a developer changing you know, a single equal sign within a uh, you know, a MongoDB query expression can completely change their Access control is not robust. Right. And that in terms of scrutiny for, for, for auditing, in terms of the risk exposure, it's pretty large. Now these regulated sectors are lagging in terms of, on the AI adoption curve, especially when it comes to production applications that use, you know, touch, say protect the health information. But the risk is coming there. And so our, our message to companies operating in this space is that, uh, you know, start from security, it will be significantly easier to reach your compliance status by starting from, you know, technically secure architecture than it is to try to, you know, check the legal checkboxes as you're building it and not really focus on the uh, the technical architecture as a whole.

Speaker B: Which of the vector databases do you see? And maybe you can't answer this and maybe I shouldn't be asking the question, which is the vector databases do you see as being the most progressive in terms of offering security controls and privacy controls within their platforms?

Speaker A: It's a difficult question to answer because I don't have visibility obviously on the um, on their roadmaps and with their work on the enterprises, but they're all moving towards enterprise, right? So they're all going to face these challenges. I would say the ones that are the furthest along the curve are actually the open source databases primarily because they provide that level of control for, you know, seasoned DevOps and infrastructure folks to be able to come in and deploy in, you know, a more secure manner than a fully hosted application, you know, fully hosted vector database, you know, whether it be, you know, Pinecone, Quadrant, Cloud, whoever, you know, insert here, where your only security is an API key which as you and I both know, is not secure, uh, and you're trusting that their infrastructure upstream is secure as well. But even then you're still facing the same thing, right? You take Chroma, which is one of the most popular open source vector databases out there, right? It uses SQLite as its backend. You can connect to the back end without a problem. If you have access to the same infrastructure, you're on the same vm, you can access the backend without any credentials, you can extract the embeddings, you can invert them. I did it live on stage a couple months ago. It's pretty trivial. And so the problem is even there, if you know how to secure your infrastructure, you still have this application layer hole in your security posture that without any type of encryption and use, you have no stopgap to prevent, you know, a catastrophic breach.

Speaker B: And this is your whole point, that if someone gets in via uh, you know, an RDP vulnerability or SSH tunnels into the environment, they get access to the environment. You need that protection of the vector database because it can be reverse engineered. You can extract the data that went into it and you lose all security, you lose all privacy.

Speaker A: Exactly, exactly. There is no more perimeter. Your data is, is everywhere today. And even, you know, wherever, wherever your vector store is running, whatever that is, you really should seek out the most granular form of security, start there, which is granular cryptography, and then layer on everything on top of that. But if you start from that point, it is significantly easier to guarantee a secure infrastructure than it is to try to go the opposite way and address the vulnerabilities as they come. When you have a big architecture hole in your, uh, design.

Speaker B: So you just mentioned granular encryption. I guess if you bring this back to the developers, so developers writing an application and it's backed by an LLM, uh, and it has vector data storage, vector databases behind it. What are your pragmatic suggestions for developers to ensure they have the security and controls in place that they need to protect the customers and users of the platform?

Speaker A: Yeah, I mean, great question. I think it's. Look at the tools that you're planning to use, right? A vector database, a graph database, whatever your store is, whatever, whether you're doing rag, graph, rag, whatever your flavor is at, uh, the end of the day, the threat model is all largely the same, right? You're acting context into a prompt, into a system prompt, whatever that is, in order to be able to augment the LLMs knowledge or context at that point in time to be able to produce a desired output or desired action. And so that central point of the vector store, of the GraphDB that you're using, look at their security docs, look at their posture, see whether they've invested time and really thought about this problem. Look for terms like encryption and use, anything like that. I would advise most engineers to not try to, you know, roll your own crypto, as they say, to implement it yourself.

Speaker C: Yep.

Speaker A: You know, it's a difficult thing to do securely. And I, I would just say, you know, pick the tool that's going to provide that security from the ground up. Because at the end of the day we are moving towards commoditization on a lot of these applications, which is good. You know, at the end of the day, one day an LLM is going to be LLM, A um, vector database is going to be a vector database. And so the tool that you use matters less as long as it breaches the table states requirements that you have, but security right now is something that very few address. So look for those terms and make that decision early on as opposed to later when you're actually facing the risk. Because it's much, much harder secure after the fact.

Speaker B: Do you think it's going to take a major breach and compromise to wake the industry up to this or do you think that people will become aware of this without that major breach taking place? The reason I ask is one of the things that worries me is that we don't seem to learn about things until you know, someone drives a car off a cliff. Do you think that's the case here or do you think that this is similar enough to relational databases that people will understand this and begin implementing even before we have that reverse engineering of a, of a vector store?

Speaker A: My optimistic hope is the, is the latter. My realistic fear is, is that uh, you know, the fact that people are uh, know how to secure, you know, relational databases can actually cut against this by thinking, oh well my, my standard, you know, I, my postgres installation is secure. You know, I've got a firewall around it, I'm good to go. You know, I, I haven't heard on this. Right. And so that standard cyber hygiene is good to have and it's, it's, but it's table stakes and it does not necessarily apply one to one in these enterprise AI workflows. So I think that can actually hurt the, the cause. And unfortunately, you know, we're in a, we're in a weird position where we don't want these breaches to happen, but it's going to be good for business at the end of the day. And that's not so we, we want people to wake up to the risk and address it because it's much easier to do so now than it is in the future when you're still, you know, pre production with your enterprise AI applications. But we've seen this with basically every attack vector until it happens in the wild and there are dollars assigned to fix it. It's usually pretty low on the list of CISOs that are swamped with many other risks to address.

Speaker B: Yeah, and what I really hope is not the case is that where organizations wait until there's regulations because to your point earlier, they often lag by, you know, a year or more sometimes because legislators just, they're not aware of how all of this works. And so shining the light on it early and thinking about it early secured inception is what we call it, you know, is an important Part of this.

Speaker A: Right. It's the only way to build securely. I mean we still haven't regulated email today, so I'm not hopeful that we'll, we'll have uh, enterprise AI figured out soon.

Speaker B: We haven't figured out spam and it's been 30 years I've been getting spam in my inbox. Nicholas, I don't know. This world is crazy. What, what makes you most optimistic or excited about the future? You're obviously neck deep in all these security challenges and problems. Is there something that you are truly excited about that you think will change the trajectory of the industry?

Speaker A: Yeah, I mean I think the, the, I'm hugely optimistic about the AI for security that ah, is more in your neck of the woods. I think it's a, it will minimize the, it will shorten the cat and mouse game that is largely played by attackers and defenders, by red and blue teams and, and I'm, I'm really excited to see that and making it m. Making security more accessible to non security developers by having more of that data out there, by enabling these agents, by having the scanning, these scanning capabilities that uh, allow you to figure out, hey, this is vulnerable to prompt injection without knowing necessarily how to identify prompt injection. I think those make me really optimistic for the future of both the security industry and the technology industry and every industry that it serves as a result.

Speaker B: That is true. And uh, there's no one more excited than myself about that. Because we use AI for security, for discovery of vulnerabilities, for reachability of vulnerabilities, for breakability of updates that we generate and actually for generative AI generating fixes for these things. It makes it way more accessible. However, and this is my. But the attackers are starting to use AI now as well. I was at an event earlier this week put on by Google that has huge cyber research and they're seeing very sophisticated AI not only for security, but for malicious attackers as well. And so while we're building security in, we should be very aware of the fact that attackers are doing the same thing on the attack side which make way more complex breaches and attacks and threat vectors that we're facing.

Speaker A: Uh, that's a very good point. I mean it'll be at least the commonality across all this is that you and I will likely still have a job next year.

Speaker B: Security is not going to go away. Uh, that is what I always say. Well, this has been very fascinating, Nicholas, thank you for the insights on this. I have to confess this is an area that I haven't looked into, but I know it will be interesting for all of our developers. If people want to reach you, what's the best way to reach you? LinkedIn? Twitter? Where. Where do they find you? I'm, I'm on LinkedIn.

Speaker A: That's definitely the, the best way. Nicholas Dupont, Cyborg. We're at Cyborg Co as well. And yeah, if there's, if you have any questions around vector embedding vulnerabilities, look at the OWASP's top 10 LLM risks. We're number eight on there and come talk to us.

Speaker B: Yeah, and it's well worthwhile. I saw a demo of Nicholas reverse engineering some of these things and actually causing a breach. So if you're interested, you can look online and see some of those videos. But Nicholas, thank you for joining us today on the Security Developer. And to our audience, I just say thanks for joining and we'll, uh, see you next time on the next episode of the Secure Developer.

Speaker A: Thank you, Danny.

Speaker C: Thanks for tuning in to the Secure Developer, brought to you by sneak. We hope this episode gave you new insights and strategies to help you champion security in your organization. If you like these conversations, please leave us a review on itunes, Spotify or wherever you get your podcasts and share the episode with fellow security leaders who might benefit from our discussions. We'd love to hear your recommendations for future guests topics or any feedback you

Speaker B: might have to help us get better.

Speaker C: Please contact us by connecting with us on LinkedIn under our SNYK account or by emailing us at the SecureDevnic IO. That's it for now. I hope you join us for the next one.