The reason we're here is because it seems like AI has been taking over our lives in the last three years or so.
But as much as it's fun to, you know, get poems out of chat GPT or, or pictures, AI also has a pretty important role in the future of business applications and the way that organizations, handle their customers, their data, and provide, a, user experience, for the people that use their software.
It's probably not gonna go away. Right?
We're we're gonna see that many of the applications that we use today are gonna be enabled with AI in some way, shape, or form, either on the back end or the front end.
We are also seeing that, containerization is the bedrock of everything that has to do with AI.
It's gonna be a big part of the conversation that we're gonna have in the next forty five minutes or so.
And, it's no surprise that organizations are actively looking to, incorporate AI, AI capabilities, Gen AI into their applications, into their user experience.
And, and I think that we're gonna find ourselves probably within in the year or so where the applications that we use today are gonna have natural language interfaces.
And a lot of the clicking and, and selecting that we do today is just going to be done with, voice or text.
Customer is actually using applications the way they do they would use maybe a a human in a customer, service capacity.
Now before we go into all that and before we go into how that happens, it's important to understand really what are the use cases for applications in in a business setting.
Now we all know that there are those chatbots out there. Right?
So ChatGPT, Gemini, Copilot, or Grok, they're all available for us to use.
Many companies want some control over how their users use those AI chatbots and what information they put into those chatbot.
And this is one aspect of AI that I think is getting a lot of attentions now because it's new because AI kinda started from the consumer side, and now we're we're at the point where AI is kinda starting to encroach into business.
So the first use case that everybody is kinda looking to get control of from security point of view is what happens when, a an employee goes into a chatbot and then that chatbot goes into an external, AI model.
This is not something that we're gonna talk about today, because what we're focusing on is incorporating AI into business application.
But it's important to understand that if you have a need for AI security in your organization, understanding how people use AI, Gen AI, is gonna be very, very important to get a handle on.
What we are talking about are are the two use cases that have to do with applications.
One is when the application on its own, needs to have some AI calls.
So think about, you know, you're uploading a bunch of, documents to a anything from, you know, claims or expenses or, some kind of request.
Those documents usually would be read by humans, but now they're gonna be read by an AI engine, which is gonna talk to a model that might have been trained or augmented in order to do the things that it needs to do with that with that data.
But the user really doesn't have any idea that this is happening. Right? This is happening beyond behind the scenes.
The third use case is when the user does know that it's happening and actually is conversing with the application like it was a chatbot.
And we're seeing a lot of movements in the industry today to start to incorporate those, natural language interfaces into the applications.
Now the way that this works in a in a business setting is very different than the way that, you know, everybody here is talking to JetGPT about our private stuff, you know, recipe or advice.
Right? Because what we think is that we have a client that that is the chatbot, and then we send a request.
There is a server that is, managing the interaction between the user request and the back end model, that has all the weights and the figures that eventually traverse our request through the AI engine and come back with a with a with a plausible answer.
But this transaction where the client sends a message to a server and then the server gets the tokens of the reply back, is something that we can all understand, right, really with our, you know, two year old ex experience with, things like Chargept and, an AI transaction.
The problem is that model, you know, the thing that we that we talk to is really not very aware of any individual company's datasets.
Right?
Those have been trained on publicly available data, and those are even though they have a lot of, knowledge about the world around them, they really don't have a lot of knowledge about a specific business context.
Right? So I call this a brain in a jar. Right?
The brain has knowledge of everything that it's been trained on, but it really doesn't know the here and now.
And to test that as an example, and that's something that that you can do for yourself, if you ask CheggGPT, for instance, to disregard the fact that it that is that is a chatbot.
Right? That only rely on stuff that it has in the model.
And then you ask something like, I'd like to transfer any funds over a thousand dollars in my checking to my savings account.
You're gonna get a response pretty much like this. Right?
It's gonna be a very generic response, but it understands what you're trying to do, but it really doesn't have the tools in order to execute that request.
So when we talk to a, an AI model that is doesn't have a specific purpose, right, a general purpose, generative AI model, this is actually a pretty plausible response.
It's gonna say, well, if you wanna do that, here are some things that you can do with your bank in order to achieve what you wanted to do, which is to transfer funds over a thousand dollars from checking to savings.
But if I saw this interface in my banking application and I got this response, I'm gonna have a pretty miserable customer experience.
Right? Because I didn't wanna get generic instructions on what to do in case, you know, I wanted to make that transfer.
I actually wanted the application to make that transfer.
And that is the real difference between using a general purpose external, not business, context aware AI engine, and an AI engine that needs to have everything that it needs in order to execute my request, which is to transfer money in my account.
In order to do that, the model needs to know a lot more than just my, you know, eight word input.
It needs to know who I am as a user. Right?
I don't want anybody just to go into my banking application and transfer money out of my account or anybody else's account.
It also needs to know technically, right, what is the account number? What is the balance? Right?
Is there a balance over a thousand dollars?
So a lot of the context of AI that is done in a business setting is there to bridge this very generic but not very useful, way in which the trained AI models, the public trained AI models are looking at the world, and we need to give it context that has to do with with our particular transaction.
In that case, a transaction that was really going to transfer money from from checking to savings should have a lot more prompt in it than just the user prompt.
Right? It needs to be told what it is. It needs to be told what its permissions are.
The model needs to be told who I am as the user.
It needs to know what are the tools and the functions that it can use in order to gather more information or execute actions outside of the, AI transaction flow.
It needs to get data from external databases like account numbers so that it knows which account numbers to query.
And it needs to have some context about what the user mindset is and so that we can even if the user doesn't really articulate the request properly, that it will have some semantic feel of what the request is so that it can, process the request properly.
And then at the very, very tail end, we actually give it the request from the user.
So all of that is providing context to the AI engine. Right?
It's not it's no longer now just aware of just how to banking works in general.
It is now aware of me as a user.
It's aware of me as my, account numbers and the balances in those accounts, and it actually is able to affect change in the banking systems because it has access to those functions.
So in order to use AI in a business setting that makes sense, we need to provide the AI engine with a lot of context around it.
It has to do with the user data, even the session. Right?
I may be able to affect change in certain times of days and and maybe not, you know, maybe from certain geographies.
It needs to know what the permissions are.
It needs to know what the user intent is so that it can, not make assumptions about what the user wants, but can actually provide the user with good service.
It needs to have, some system prompts that tell it the parameters of the session, and it needs to have access to related facts, to available actions, to permitted actions that will, help it facilitate that request and actually gets to, to something that the user wants to execute.
And in order to do all that, we need to have several components. Right?
So if you've touched any AI, infrastructure in place, you're gonna recognize some of those the these concepts in in a more expanded view of the AI transaction.
One of it has to do with, the gateway, which is a generic name for a component that does validation, authorization, basically understand who the user is, provides access to the functions that the user can have at this particular moment when the transaction is executed, and provide, context to eventually to the model about what the user can and can't do and what is the the scope of the things that they can affect.
There's also, a way to get more context into the service. So you might have heard the acronym MCPs.
That's the model, context protocol or an MCP server. That's another name for for the context server.
And what the MCP is doing is it's providing the model with external data.
So it's basically a database client that, is reading some of the input from the user.
It can get requests from the model. Right?
The transaction can go kind of back and forth a little bit until, until it reaches what it needs.
And then, once it gets the data that is relevant to the transaction, then the contact server then provides it to the inference server as part of the of the model.
And then we have the finalized prompt, which has all the data that we need.
The infra server can, then call on some tools execution, and, then eventually, we'll ask the model really get all this big prompt into the model, and then the model will have a response that the user can then see.
And the response flows backwards, through all these stages.
And then as you see on the lower right, the thing that kinda drives all that is access to a GPU. Right?
Because GPUs now are the primary way in which, inference servers work versus the models.
And it's very compute intensive, so we need to manage the access to this to this transaction. Right?
So we have all these these components in place.
And for the most part, the further right you are, or the further to the right you are in this diagram, you may not have all those components on prem.
Right?
The model can still be something that you get from an external model if you get a Hugging Face model or you get a, a resident, model from or something like that, that sits in your environment, but it could also be, you know, a dedicated slice of, you know, chat GPT or a dedicated slice of, of, Copilot or Bedrock or any other of the AI services.
The more you go to the left of the diagram with the client, the gateway, and specifically the MCP, this is where we're seeing a lot of those components actually hosted on prem.
And when I say on prem, it doesn't have to be under the desk.
It could be in the cloud environment, but it's cloud environment that you can control. Right?
These are these are services that are gonna be under your responsibility because they need to interface with your internal systems in order to, get a complete AI transaction that can make sense for the user.
And this is where we start to connect what, the AI concepts require with the infrastructure and the deployments that we need to have in order to make sure that all these are going to be, in place.
And they do translate almost one to one to quite a lot of deployments. This is an example of deployment in Kubernetes.
Right? So there could be, your actual app. Right? This is gonna be the client layer.
And then all of these things, the API gateway, session management, the MCP, the tools availability, data ingestion for augmenting data, databases for retrieving that data, All of these things can live in Kubernetes deployments and a lot of times they do live in Kubernetes deployments in your environment.
And, we have, the responsibility now to make sure that this environment is secure.
First of all, because it is a containerized environment that lives, in your, in your cloud instance or on prem, and therefore, it just needs to be managed as an application.
But we also need to manage the specific things that AI can do because AI being nondeterministic and the fact that the prompt can be free form.
We wanna make sure that, this environment is resilient in case the AI, service is asked to do something or arrives at the conclusion that it needs to do something that is really not ideal for the security of the environment.
And, and if you wanna get examples of how AI prompts can be fooled to do all kinds of really, unsavory things.
There are a lot of examples, around that.
So how do we take this environment that is applications that run-in containers, mostly in Kubernetes, and make sure that they are not, being attacked, first of all, as an environment, but also as an environment that carries AI.
And, the dangers are actually not far fetched. Right? We are seeing, a lot of, attacks against AI infrastructure.
That's really kind of where the money is. That's where the disruption can be.
But even things like prompt injections, asking the AI model to do something that it's not supposed to do, getting information out of a model that is not, contained to the user.
The model might divulge the, let's say, account number if it's if it, if it's not careful, or, you could trick the model to maybe go outside of its scope.
We also, as a as a kind of matter of policy, always need to know what applications are using AI services.
There are some regulations in place for that, and, and we just need to know what are the inventory of the components that, that we have access to in our application.
And then, anything that has to do with unsafe outputs, anything that has to do, you know, in a in a in a private, GPT setting, you wanna make sure that, it's not, causing harm or is or it's not depicting images that are outside the terms of service.
In a business setting, it really has to do with protecting your data, protecting your other customer data, making sure that there's no leakage of data between customers that use AI transactions.
Right?
So all of these things are relevant for both your kind of private experience with JGPT and also in a business experience.
And we really need to manage it. Right?
We really need to understand what are the transactions that are taking place in our in our environment and also what are the things that we can do in order to defend against it.
So when we look at, how security really needs to respond to those things, We need to ask ourselves really what are the gaps.
Right? What are the things that that we can't do today, if we have an AI enabled infrastructure?
So the first thing is that there's really no good way to tell which AI components are used and what they do at run time.
Right? Because sometimes you can discern it by the image name.
Maybe you get, you know, an MCP from Anthropic or maybe you get a, a server from, from OpenAI.
But a lot of times, those are just SDKs. Right?
You can embed the SDK of chat g p t inside of your application, and then there's there's really no way to know if that application is running with or without AI.
There's also no way to understand where AI is sourced from.
If you look at the components that are being used inside of AI stacks, even on prem, a lot of them are just sourced externally.
They're they're coming from the different maintainers of the, AI stacks.
It could be open source or it could be closed source, but, you are basically putting your trust in somebody else's component.
So the same way that you would do it with base images or commercial applications, We have to make sure that we understand where AI software is coming from.
We really don't have you know, with our normal intrusion detection and, and firewalling, we really don't have a way to look into the content of an AI transaction.
Right?
The idea of, the prompt being a set of instructions that is that is unpredictable, that's something that we need to account for.
And, and we've gotta make sure that we have visibility into what prompts are being inserted from our side of the infrastructure into into the model.
And also, there is a lot of resistance from those who develop applications because there's so much pressure to, come up with applications that are AI enabled.
Then if we start to do a lot of testing, if we start to embed a lot of security, or have a SDK on top of SDK, right, the SDK of the of the AI service and then an SDK for security, it's gonna be too too cumbersome, and, and it's very, very error prone.
And if something goes wrong, you know, we will have a kind of mutual blame of, of the security versus AI. Right?
So we wanna avoid having, anything that is gonna encroach on the way that the developers work.
But, you know, the gaps are still the gaps, and we still need to have some good answers to questions that are gonna be presented.
If not now, they're gonna be presented a month from now, three months from now, or six months from now.
But at some point, everybody, I think, who attends this, this session is gonna have to answer, you know, what AI is being used, where is it being used, what's what's deployed, how do we know that what's deployed is what we intended to deploy, is there an audit trail of what's deployed, Just the normal, you know, questions around visibility and governance of every new technology.
We also need to understand where the software is coming from, what about vulnerabilities in the software, how do we manage the risk, How do we manage the configuration of the things that we need to do in the configuration of, the images and the workloads that can support, but also maybe help with some of the risks that we have around, AI.
And then at run time, right, once you once those applications are there, we need, first of all, to understand what they're doing.
And then if they're doing something that they shouldn't, like trying to circumvent the, AI model to divulge information or cause it to do things that it that are not permitted, we need to know what those are, and we also wanna have limits.
Right? We wanna have, limits on the on the prompt itself.
As I said, the use of GPU is fairly expensive, so we want to make sure that we are not, overriding, the, the the GPU and, and have either to slow down the entire stack or, you know, have to buy more and more capacity that is just gonna be costly.
And then there are questions of segregation of data. And if there's an incidence, how do we even manage it? Right?
How do we retain the data so that so that we can take it to a level that we can actually do some investigation and, root cause analysis.
So these are the questions that that we need to answer, and there are some capabilities that can help that can help us.
And these are capabilities that organizations should arrive at either internally or through, the use of tools.
But the idea is that whenever you go into a situation where you starting to think about protecting your AI infrastructure, these are some of the things that that you need to demonstrate.
Right? You need to demonstrate that you have an idea of which models you're using.
Again, a lot of the out of the box implementations of, AI models that you use, on prem could have several model selections.
Right? There's several versions of the models. The models get updated all the time.
So keeping track of the model inventory and which model you're working against is very, very important.
We have to make sure that we understand what the usage of the different models, the different applications, and the physical resources, right, the GPUs that, that they're using.
We wanna understand if there are things that the AI system can do that is outside of just providing a response. Right?
If there's tools, agents, we're talking about, AI agents as the replacement for human action that can interface with even existing applications just from the front end.
These are all things that, are very convenient if we use them properly, but can have really severe security implications if they, go, outside of the, the swim lanes and out and and paint outside the lines that we've, that we've established for them.
We need to know, you know, what we need to know about the prompt and the response. So just gaining visibility. Right?
If you if you could could gain visibility in your on prem environment as to which application is using a model, which model they're using, what tools they're using, get some ideas of the prompts that are being sent, this is all going to do a great deal of good for, visibility and governance, which is kind of the prerequisites for having an in any kind of security.
So this is this is really the number one thing that we need to do is we need to make sure that we have the visibility into what's actually running.
The second thing is because we have things that are running, then the question is, okay. Where are they coming from? Right?
So how do we, do governance around sourcing, minimize the image bloat, make sure again that we're selecting the right models?
If you're under regulation, you might have the need to produce an s bomb for those images even if they come remotely, you know, from external sources.
You still need to account for what's in them. Those images need to be secured free of vulnerability. Right?
This is still software that you're gonna run-in your own in infrastructure.
And so the way that you would run, you know, all the way from a simple NGINX server to an inference server needs to be done in the same way with regards to vulnerabilities configuration and the selection of components that are allowed in your, environment.
Right?
Just because it's AI, that doesn't mean that we need to throw out the rule book as for the way that we source and manage software.
And then the third thing is once you have those applications running, we need to make sure that they are operating smoothly.
So, are they should be accepted? Right? Are the images good enough for us to run?
This can be something that we can look at vulnerabilities.
We can look at configuration to make sure that the images, is, of good security quality for us to run.
We can control its runtime.
The access to GPUs, we can control at runtime, what, prompts are being, handed over through the AI stack right from the MCP to the inference server and eventually to the model.
We need to make sure that, if there are, needs to isolate the AI infrastructure that it's done through the network. Right?
If we give some toolings in place to an infrastructure that it's done through the network, right, if we give some toolings in place to an AI engine that can maybe execute some commands or some of them can write Python programs and then execute them, we wanna make sure that those are actually isolated from the rest of the environment.
And on top of all that, we need to have some behavioral detections that will inform us on whether or not those components are behaving in such a way that is adding to the risk.
Right? All the way from remote code execution to, you know, loading stuff in memory.
Everything that we don't wanna have in a normal containerized environment, we definitely don't wanna have in a containerized environment that runs AI.
Right? So this is all predicated, of course, on the fact that we, first of all, have good container security in place.
Right? So, what I call the image BVC. Right? The load vulnerability configuration of the image, these are table stakes. Right?
You really cannot run an AI components on-site, without understanding what the makeup of the images are.
We need to have scans and acceptance of the image like any other image, throughout the software development life cycle, and we wanna make sure that those images are least privileges, that they don't run as root, that they can run as isolated workloads.
The reason is that, you know, with all due respect to the makers of those components in Anthropic and OpenAI and, and x and all of them, I wouldn't trust them to actually have good configured images, right, because that's not their day to day job.
Right? And we've seen we've seen vulnerabilities that have been associated with, let's say, the anthropic MCP.
We've seen vulnerabilities in other MCPs.
So, it stands to reason that, you know, as the environment and the the know how of how to do things on prem securely is slowly take taking shift, we're gonna be in a period of time for the next few months, probably a year, where we're still gonna have a lot of, security problems in the images that we get.
And that's why we need to have really good supply chain security governance.
This is something, again, table stakes for any other application should be for AI.
So inventory of the base images, component outsourcing, policies for some risk acceptance around, we know which models, which components we wanna have in our environment.
And then, how do we secure the pipelines if you're gonna do any content ingestion. Right?
The, the MCP server sometimes are served as a as a rack server so that is augmenting the data that the AI model have has access to.
And, there are unfortunately ways to poison that data.
There are ways to make, to upload documents, for instance, into a document store that the model can then use.
These are all things that, that are gonna, require some attention because, unlike the kind of, very deterministic way in which software usually works in, in business settings.
Once you start to put AI in place, it becomes a lot more murky, and we don't wanna have any opening for, the AI engine to use information that, might have been uploaded from from an untrustworthy sources.
Right? It cuts back on hallucinations.
It also cuts back on, the ability to, upload, any document that has nefarious instructions in it.
And then when we look in into run time, this is where, right, everything runs in containers. Right?
So we need to monitor those containers, monitor the system calls, monitor the outputs, detect any, attempt to jailbreak both on the prompt side and on the on the container isolation side, and then some just put some guardrails specifically around, the resource constraints.
You can specify in Kubernetes, you know, how much how many slices of GPU you can access.
And these are all policies that that we wanna have in place so that, our workloads, even if things go wrong, are not gonna take down the entire environment.
And, again, we have to accompany all that with a lot of visibility. Right?
So the question then becomes, how do we actually achieve all that? Right? We had a big ask. Right?
The ask is that we need to answer, a bunch of questions around everything that have happens in AI.
We need to have a bunch of capabilities. We know that everything runs in containers.
So in order to answer that question, we need to have some capabilities in place.
We need to have, scanning for every component that goes into our environment. Right?
So if it's a SDK to a complete image, everything that comes into the environment has to be tested for not just vulnerabilities, but the fact that it is going to do what it says it's going to do.
And Aqua can provide things like dynamic threat analysis to, put, you can put through, dynamic threat analysis the images that you get from third parties just to make sure that they're not, uploaded or have been hijacked to do, to do, any sort of internal attack.
So we gotta understand where where things are coming from.
We gotta have some security gates in place around the selection of components, but also the selection of models so we can identify which models are embedded, either as stand alone images or inside of your images and then, make sure that those are the ones that you intended.
We need to have, intelligent runtime that can identify what is a AI transaction versus non AI transactions. Right?
One of the things that we've added into the Aqua platform is the ability to, put the Aqua enforcer in place.
And then with the same enforcer, you'll be able to identify both AI and non AI transactions and hand handle them a little bit differently.
Right?
In one of them, you really have to watch for remote code execution and, and how, vulnerabilities might be exploited in order to, affect the underlying container.
With AI, it's a little bit bigger than that. Right? Because there could be tools, there could be agents.
There could be other ways for the response in the model to maybe have effect outside of its immediate, container. Right?
So we really gotta expand the use of runtime, in order to understand what's going on with, with the AI, components.
And then everything really has to work together. Right?
We really can't have a situation where, you know, we scan the model in one end and then do the runtime in another end because, the runtime capabilities need to bring into account what we found in the scanning.
And also runtime, as you know, can actually influence the prioritization of some of the things that we do in scanning. Right?
If we see a vulnerability, but that vulnerability is not used in any of the running containers, we can actually deprioritize it or maybe, postpone the fixing of that vulnerability or prioritize other vulnerabilities on top of it, because we have information at run time that can minimize, the risk.
So the way that that Aqua does all that, and we're getting into the you know, we've we've pointed out the problem.
We pointed out the required solution, and now we're gonna tell you really how that solution takes place. Right?
So when you deploy Aqua in your, in your environment, Aqua, if it's enabled with the AI capabilities, is immediately going to start to look at the transactions that all your containers are doing.
And it will discover whether or not they're referring to AI models, AI platforms, which versions.
We can monitor them accessing models even outside of your environment, right, because the point of interception is in the application. Right?
The left side of, this diagram is where, we are finding, all of the transactions initiated.
So if you put, our detection on the left side here, right, between the application or maybe even on the MCP server, we'll be able to grab all these these transactions and see them.
And then you can you can track the usage of the, of the applications and how they do they do their their transactions.
We are copying the prompts, but we're scraping off, any sensitive information. Right?
So you'll get a copy of the prompt, but you're not gonna get things like, you know, account numbers, Social Security numbers, or basically anything that is, privately identified information, because those are being stripped down from the logs, and you really kinda get the the gist of the transaction versus the, the the AI engine.
We also want to enforce that policy without developer friction. So everything is done with the Aqua Enforcer. Right?
We're not in the in the business of giving you just another SDK to use in your in your images.
We don't wanna overwhelm the development with more components.
This is all done via the Aqua Enforcer and the, ability of Aqua to integrate with supply chain and also the registries.
And the eBPF based enforcer, which, again, a lightweight implementation of the Aqua enforcer, is able to see everything that the AI component is doing.
It could be, the transaction itself. It could be access to tooling. It could be access to agents.
So everything that the component is doing is gonna be, visible to the Aqua platform, and that's how we can start we can start to exact some, some security around that, get the prompts and get the analysis of the prompt of whether or not that's something that, the the prompt might cause, a security issue.
Talking about the prompt themselves. Right? The problem with prompt is that, again, they're not deterministic. Right? You can write anything.
You can write anything in a way that is very convincing. Right? AI engines, are very susceptible to emotional manipulation. Right?
If you ask it to do something and it says no, try to say that your, you know, departed grandma asked you to do it as her dying wish, and it might actually do it.
Right? Because sometimes those prompts can be filled with with, some emotional baggage. You wanna know all that. Right?
You wanna know if some of your users are trying to do jailbreak or model misuse.
These are all things that are gonna be detected with the AQUA platform, and, and we can wrap all your container your container's application with the process that will identify prompting and will alert you when a a prompt is seen as something that might wanna compromise the system.
So that's one thing that you will get.
You will get not just visibility into what models are being used, but you're gonna get actually a, copy of the stripped down prompt that is gonna tell you whether or not those, components are being attacked or not.
And then, again, because everything needs to work together, in the Aqua platform, we have the ability to show you, the entire end to end life cycle of your application, right, all the way from supply chain.
If you have that module in place, it can go against, your Git repos, identify those AI components, the SDK components that are that are gonna be in use.
It can then look at the container image.
It can then look at the runtime environment and connect all of that so that you'll have a good, very straight line for the root cause analysis of, any incident that happens in the environment.
So what is really, really important to understand is that when you have AQA in place, you really already have access to, all these capabilities, because we don't need any extra components.
Right?
If you look at the way that Aqua kind of established itself over the last ten years, we started with container security back in two thousand fifteen.
This is kind of the first version of the enforcer.
The enforcer was then extended to, look at Kubernetes and other cloud native resources, and now we are looking at AI workload again with the same infrastructure.
So the same components that you have, in your Aqua environment today or if you're considering the Aqua environment, you you will have, the, those components in place.
We are able to, give you the AI infrastructure. Right? So you can get full visibility into the AI usage.
You can, have protection from AI threats, either prompts, jailbreaks, use of tools, and you can enforce all these policies, just on the runtime side, right, without having to force your development teams to introduce a lot of other components into the environment.
And this is kinda in details what the Aqua platform can do. Right?
So if you know Aqua runtime security, you already know that we can monitor all the containers using our eBPF based enforcer.
We've now added, the ability to extract prompts and analyze those prompts. We've added AI detection policies for behavioral controls.
So on top of all the other behavioral controls that Aqua can do, we've added those, those that are specific to LLM, protecting secrets, alerts, and enforce policy violations.
Again, these are all things that Aqua can do today.
And with a little bit of addition, we're able to, execute that on AI. Same thing happens on the Kubernetes side. Right?
If Kubernetes is not well protected and not well configured, an AI tool, can actually go outside, paint outside the lines, and might add risk to that cluster.
It could do of you know, GPU overruns cost you a lot of money.
So all these things are important to configure on the Kubernetes side, and Aqua can do that because we have the Kube Enforcer and Kube Hunter and, and all the other tools in place to get the configuration of Kubernetes.
Same thing happens on the supply chain. A lot of the capabilities in Aqua supply chain are very relevant to AI application.
Actually, we'll address the compliance of AI application.
So it could be all the way from generating s bombs to understanding where components are coming from, reachability, and the dependencies between them.
And then because everything happens on the same platform, you have, the ability to, look at this end to end to see how AI transactions are being traced, not just in the runtime environment, but also, what are the components that were added to that and, and all the way to the initial commit by a developer that might have added an SDK, you know, an AI SDK into your, native, client application.
So to summarize, Aqua is a full life cycle protection for containerized applications and also containerized AI application, you know, from code all the way from supply chain to cloud all the way to run time and with real time enforcement.
And you really don't have to change anything. Right? You don't have to add SDKs. You don't have to do anything.
If you have Aqua in place, it, it really just needs an update of the enforcer with the new AI capabilities.
And then, in a little while, we're also gonna open up the server side, which is going to be available to you to see all the dashboards and all the rules around AIs and the policy.
So, you know, we're we're gonna wrap up, in the next, couple of minutes.
I just wanna make sure that, if you haven't seen it, there is a handout section, that, can give you a lot more information, and you can go to aquasec dot com slash ai and get an understanding of what we do in the, AI space.
So I think we have maybe a few more minutes for questions if we have any of on the chat here. Yeah.
There are actually quite a few questions that came in.
Let's start with the first one is how do you control drift from an actual expectation?
So what happens is that, you start to get a an idea of what the prompts are that, users are sending.
And those prompts can then be analyzed, again, by another AI model. Right?
We actually do send our, the there's an AI engine as part of the Aqua platform that we added in order to analyze the prompt, and that can start to see if we are doing things that are not in line with what a business application might expect.
Now at this point, we're not taking into account your exact application, but we can discover a lot of verbiage in prompts that is pointing us to the fact that the prompt might cause a jailbreak or another unsafe, situation.
So while it's not directly against unexpected behavior for your application, it is unexpected behavior in a business setting, and then that's how we discern whether or not the the prompt is going beyond what what it what it's supposed to do.
Alright.
And does, does it exist for any are are there any free tools of yours to implement some kind of security on AI apps?
So I'm not aware of any free tools that can do what Aqua does as far as the ability to look at prompts and, and look at all the, the security around them.
We are going to start to see, you know, even Trivy. Right?
The open source, vulnerability scanner is going to start to identify AI vulnerabilities as they become part of the CV system.
But I'm not aware of a an open source or free component that can actually trace AI transactions on prem. Okay.
And what are some of the best, practices to control drift from actual expectations?
So at this point, right, part of the problem is that with prompting, we really don't have a lot of ways to prevent stuff from happening.
Right?
Because once when once the prompt is sent, we have to we have to, kind of let it pass so that that it becomes part of the the transaction, and then and then we can check it.
But all the other security, things that Aqua can do, like drift prevention inside of the container, like controlling the use of executables, like, controlling, which networks the container has access to.
Right?
So even if worst come to worst, then you can convince via prompting the AI transaction to do something, to maybe launch a particular, executable or maybe use wget to download something into the environment and then run it.
All of these are gonna be caught by the normal, very powerful runtime controls that Aqua has. Right?
So drift prevention in a container will, deny the use of any added executables to that container. Right?
So if the model is able to use a tool to, to download something, it, it will not be able to run it.
And even if it if it uses something to let's say, you know, the model runs a Python program, and then and then executes it.
You do have control using Aqua to decide whether or not you wanna run Python and in which containers you wanna run that Python, program.
And all of that is kind of your backstop to the fact that you really can't control, what the user is gonna do with the prompt, and users are pretty ingenious.
So these are the things that, that you can do.
You can you can trace the prompt on the front end, identify the dangerous situations that the that the prompt might cause.
But then as a standing backstop, you have all the Aqua capabilities that are giving you, all the security benefits of stopping a transaction that that might cause damage.
So it's not it's not so much a question. Just looking to get a little more input from you.
Someone said there are types of models drifts and their underlying causes.
To evaluate model drift, narrow down a root cause, we must understand different types of model drift.
Generally, there are two types of model drifts to consider.
So I guess my question is to you, what do you think of these two models, and how would you agree, change, or, you know, what's what's your perspective on this?
You've got model decay, the relationship between the models, predications and the label and labels that have changed and the prediction shift.
The model's predictions have changed. Yeah. That is a that is a concern.
We, you know, you do see examples in the wild of models that are, you know, starting off making sense and then stops making sense.
To be honest, this is really outside of what Aqua is doing in this setting. Right?
We treat the model as a black box. Right?
We look at the transactions coming in and out of the model, but we haven't put ourselves, a goal to manage the risk of the models themselves except the, except for the for the model selection.
Right? So when we talk about, you know, what can Aqua do and not do in this setting?
And, again, the concept of AI is gets kinda murky a little bit because, there is still a lot of change in the industry, and we're still looking, to learn a lot about what this set of services is giving us.
But if you look at what Aqua is really interested in, we are absolutely interested in the transaction that is gonna flow into the model.
Right? Looking at the, you know, left side of this, of this diagram here.
What you're talking about, the model drift actually happens kind of inside of the model on the far right side or maybe between the model and the inference server.
And this is this is where ACWA has, at this point, limited capabilities because we didn't choose to go into that.
I'm I'm sure there's gonna be a lot of other players that will take care of the the inference and model side.
What we found is that there is a really big gap on the business transaction side, right, even before it gets to the model, and all these components need to be managed.
Right? So this is why, you know, I wanted to be very clear about what problems Aqua actually solves.
And the problem that we solves are the problems that have to do with managing the infrastructure, and not necessarily the behavior of the model and not even the behavior of the model.
If anyone has any more questions, feel free to put them in.
But see, if you have any more final remarks or anything else that you would like to add, we can begin closing.
Yeah. Absolutely.
I would say that, you know, we are at a point now where AI is more than a science experiment, but less than a full, you know, production ready methodology.
Right?
We're at the point where it's almost useful, and I think it's important for us to identify when it's it kinda goes from a science experiment to a production system, Because I've seen, you know, firsthand, several occasions where, companies were experimenting with AI, and then they got to something that works, and they didn't wanna break it, and they didn't didn't wanna kinda rattle the cages.
And then they basically flipped that over to production, but without thinking about all the security implications along the way. Right?
So if you're if you find yourself in a situation where you're starting to think about AI, maybe start to think about AI in the context of a business application, be very mindful that at some point, what is the test environment might become production.
And when that happens, you really have to demand that some security will be added to it, because otherwise, you're gonna be exposed.
And, and, there's really no way to know what a an unprotected, unmonitored, on prem, AI infrastructure might do because all these prompts and the capabilities of the AI components are somewhat unpredicted.
Thank you again for joining us, Svi.
It's been a pleasure having you, and we appreciate you taking the time out of your day.
And we'll see everyone on the next Tech Strong Learning program.