AI Without Exposure: Securing Claude and Agentic Workflows

Welcome everyone to today's webinar titled AI without exposure, securing Claude and Agentic workflows. My name is Michaela, and I'll be your host for today. We're glad that everyone is here as we look at how to control, secure, and safely guide the power of AI agents within your organizations. Before we get started, I do have a few housekeeping notes here for everyone. So today's session is being recorded, and we will be sending everyone a link to the recording after the webinar. As for your questions, feel free to drop them on our q and a box below, and we'll be addressing them during our q and a session at the end. Please stay with us until the end to learn more about our next steps and the resources that will be available to you after webinar. Now the rapid adoption of AI tools like Cloud, Codex, and Cursor is transforming how we operate. However, it also introduces a shift from user driven to agent driven risk, where AI can access critical systems and data with more privilege than intended. Today, we are going to share a practical framework to secure these workflows and protect your proprietary IP without slowing down your innovation. Let me introduce you guys to our speaker for today. I have here Nathanael Iversen. He's the Chief Evangelist at Zentera. He helps customers grasp agentic AI control and zero trust strategies through his deep expertise in networking, virtualization, and security. He brings over two decades of experience across systems, engineering, product management, and technical marketing. Nathanael here actually began his career designing large-scale data centers for the US Air Force, and he holds a degree in communication systems design from the Community College of the Air Force. Everyone, welcome to Nathanael. Nathanael, over to you. Wow. All that. Man, I guess I better be good. Well, it's a delight to meet everybody today and to spend a little bit of time with you. We're gonna have a great time together, and I'm pretty sure you're gonna get to hear some new concepts. I'll tell you in advance, that there's at least two slides that you're gonna want a screenshot because they have some actual architectural information on them, that I think will be useful to you as you look out at the vast, you know, number of things that are out there in the world and the kind of agentic things that are happening. And they'll be, I think, a good reference guide, you know, for you. So I'll try to call those out as we get there, and you and I can both look forward to getting there in just a moment or two. So I'm going to begin and just introduce Zentera to you as a company. I'm guessing that at least some of you have probably not had a direct conversation with us, and so I'll at least do you the courtesy of introducing us properly. We'll talk a little bit about the problem and the solution, kind of the parameters, if you will, that are needed to address some of the things that are starting to emerge from the agentic space. And we'll talk a little bit about our our products and, then finally, some q and a at the end. So as a company, Zentera is here to secure and control access to our customers' most important assets. Well, that's a noble kind of statement, but what does it actually mean? The truth is this. You are already using technology that Zentera is protecting, Guaranteed. We our technology is used by about two hundred and thirty of the largest chip design and fab houses in the world. And so that means that if you drive an automobile from Toyota or from Tesla, chips that were designed over channels that we protect, they're in those cars. If you have an Apple device anywhere in your house, guess what? The chips and some of the other internals of that device were actually designed on systems that Zentera is protecting. And so, ultimately, Zentera is a company that matters. We're protecting critical infrastructure, critical assets, and securing the communication for some of the most important intellectual property in the world. And I think the interesting thing is is that our customers have been very loyal. Our average customer has been with us for over five years. So when people use Zentera, they end up liking it. But let's put that to the side for the moment and talk a little bit about why we think we're here. Yes. To securing and controlling important assets. There are other companies that would probably claim to do that as well. But here's a little bit more specifics about our vision. We would like to see a world where data and systems are secure from untrusted access, where humans and agents can access what they need, but a world where transparent and invisible controls enforce organizational intent. And that word intent will come back to us just a little bit from now because it turns out that when you're dealing with an intelligent entity or agents that have some reasoning capability, being able to specify your intent and have that carried out in the face of some reasoning is tremendously important. And those controls obviously need to be outside the realm of where the agents themselves can reach. So probably the simplest way to state what the problem is is just this. It's the new sprawl. You know, I've got some gray hair. And at first, the sprawl was servers. Everybody filled up their data centers with lots and lots of racks, and then we switched to blades and all of those kind of things. And then we decided that wasn't dense enough, and so we'll just switch to the cloud where we can have as many things in a virtual space as we like. And now we're releasing agents. And the interesting thing about agents is this, an agent can write another agent. And so however many years it took us to, you know, staff our our data centers and stock up our clouds and our virtual hypervisors, it is likely to go faster with agents simply because the agents can actually replicate themselves. And, ultimately, being right about the timeline is not really that important for me or for you or for anybody at your organization. The reality is it's a wave that is coming. There was just something, I think, released just a couple weeks ago that said that forty percent of enterprise software manufacturers are planning to ship agents to their customers by year end. So this means that if you use Salesforce or you use Workday or you use NetSuite for your accounting, it is highly likely that some users inside your organization are going to get agents. Whether anybody is officially thinking about that from a security or an infrastructure perspective, they're probably going to show up in just a release and people can freely download them and start using them. So with that as a backdrop, if this is, like, present coming, but maybe not fully here yet, what should we start to be thinking about in terms of agentic workflows? Well, as I mentioned at the beginning, some of our customers are very large semiconductor design and manufacturing houses. And so running such high-tech data and compute intensive businesses, it would be no surprise that in many ways, they have been early adopters of Agentic AI technology. After all, if you can get thirty or forty or twenty percent more design out of your engineers or you can reduce the time to prototype a design and get it to a fab, this is a big, big economic difference for that type of business. And so they, of course, have been very active with this kind of technology. And we were kind of pulled aside into some meetings from our normal work of securing some of their IT resources and things like that. And they basically said, look. We've got a problem. We're using agents widely across our design spaces. Engineers are using them. Coders are using them. We want them to use them. It's a mandate from the board. We're seeing results from it, but we actually, in security, don't know how many agents are out there. We don't even know what they're using. Everyone's doing it on their own timeline, and we don't have controls in security. And so what do we do about that? And if an agent actually made a change, I have no audit trail. I have no way of knowing that an agent did it, if a human did it, or exactly how that change occurred inside the environment. And so you can imagine that when your business is intellectual property or it could be that your business is health care and it's actual human lives, it could be that your business is manufacturing things, it doesn't matter. If you're gonna have an agent and it has the possibility of changing something in your environment that would normally be changed by a human, it's gonna end up being important to have accountability and to be able to track these things. Well, as we started having deeper and deeper conversations with them, it emerged for us that there were a number of different conversations happening in the room, and we started to realize that it was important to try to think through how much control are they actually looking for. Like, what's the right level in order to actually reduce the risk? And it was apparent immediately that detection and monitoring won't be enough. Like, at some point, you you can inventory what's on a machine and decide that some of them are agents. You can monitor that the agents are going to certain LLMs or they're traversing your network in a certain way, and that's wonderful. It's necessary. We advise that you should have that. But that kind of generic control is not going to get you very far because it mostly is gonna tell you what's already happened, and then you're probably not gonna have the right kind of auditing and logs to actually even do a proper retrospective. Now there's obviously the companies that are making AI agents themselves, Claude and, you know, Anthropic and OpenAI and others, they all have some vendor constraints. You can actually set certain parameters around the agents. And at the same time, their documentation all says that you're going to have to have controls outside this because we don't have all the controls to sandbox these agents in the way that you might want. And so that's the next level of thing is can you isolate the agents? Can you put them into some kind of a sandbox? And this, you know, almost brings to mind some kind of idea like a Java virtual machine or something where it's like we've got a small box and we put the agent inside it, and then it can it can only get out in the way that we specify. And that's good. It's just that the thing inside the box is not an old piece of software that talks on three ports and communicates in very simple ways, you know, sending data to a database and retrieving it. We're actually talking about the thing inside the box has the ability to do its own discovery, to find limitations and barriers, to ask questions, to figure things out. And in other words, it has the capability to try to modify the box that it's in. And that turns out to have a whole lot of implications, and that is why we think that having declared intent enforcement ends up as kind of a destination that you'll end up at if you seriously think about controlling agentic AI behavior. You actually need to be able to control the behavior of the agent. It's not enough to put it in a box. It's not enough to have some, you know, some settings that you've done in Anthropic, and it's not enough to just say, hey. I've got a list of the agents, and my network flow show that, like, we have a lot of traffic going to Anthropic. That won't get you very far. But let's talk a little bit about this declared intent enforcement. And as we do, I'm gonna tell you this is slide number one that you probably wanna take a screenshot of this. I am not going to read all these words to you. That's merciful on my part. But what I wanna do is introduce you to the idea of declared intent enforcement. And that is is that an AI agent's actions, what it's allowed to do, actually has to be declared up front, and it's not inferred at runtime, and it is enforced at a layer the agent cannot bypass. So that's kind of three things there that actually are important in order to know that you actually have declared intent enforcement. In other words, you've said what's permitted ahead of time from a behavior perspective. It's not inferred at runtime. And third, it's enforced at a layer that the agent can't bypass. And we'll talk a little bit later about the specific places that you actually need to insert controls in order for this type of enforcement to be active. What I'll call your attention to on the slide is the boundary that the column that's over on the left of the screen. You'll notice that some of the things that you're gonna wanna be able to do is to specify what destinations are reachable, What kind of tool sets are exposed to this agent? Can it just go on the web and do whatever it wants, interact with any agent, with any LLM, public or private? Probably not. Probably not if it's gonna touch your manufacturing plant. Probably not if it's gonna touch your intellectual property. Probably not if it's going to have a matter of life and death, or a diagnostic or something else that is going to take significant action in your environment. Can you actually classify the data that's gonna be used by this agent in order to be able to say it gets this much but not that much? Can you control how much the agent can delegate to other agents? Can you have egress limits? In other words, can you determine how many tokens it can spend? Can you determine, you know, what kind of amount of data it should be expected to transmit? Because if it's all of a sudden transmitting a hundred times the amount of data that you authorized, maybe that's not the thing that you would actually like to have happen for this agent. And so these ideas are all things that have to do with what kind of actions do I want this agent to have. This is not really any different than, if you think about it, than some of the role based things that we've done in simpler fashion with humans inside of our environments to say it's normal for accountants to use the accounting package, but it's not normal for them to use chip design software. And this same idea is going to need to be applied to agents only perhaps even amped up a little bit more because they're gonna think in some nonhuman ways. And some things that a human would think is difficult, the agent is not gonna think it's difficult in order to try to get around particular security things. So let's just give some examples of some of these use cases that, might be that might fall under this idea of declared intent. One of them is simply just to inventory the agents by system. I mentioned that this is one of the simple things that you're going to need to do, and in fact, it's very useful. This is a screenshot from our product that just shows a list of host names, and you can actually see the agents that are running on the system and they're that are sandboxed. You know, these things are important to do. I said you need to do more than this. It's true, but you do need to do them. And if you have people using agents in your environment and you don't have an inventory of what they are, well, I can pretty much tell you that's going to be the first thing you're going to need to get is a good list of exactly what's running and where, and you may be surprised as some of our semiconductor customers have been about just how many things are out there. Our product today will scan, it's just north of twenty five hundreds, like twenty five seventy three or something like that today, and growing all the time, the number of agents that we will find. And so all of those are cataloged and then sorted back. Another one is to enforce token quotas. There's been quite a bit of this. I think just last week, there was something that ran across the the media that a company had not put any limits in their Anthropic instance, and their people had used five hundred million dollars worth of Claude tokens. Wow. That was an unexpected bill, I am sure. Whether it gets paid or not, I don't know. But it has raised the issue across the industry that it is one thing to tell everybody use AI, use the leverage, get, you know, more value out of every minute of your day. And it's another thing entirely to make sure that there are some limits, particularly if you're going to assign this to agents who may not care in the slightest about the cost of compute, the way a human might care about, you know, their own ownership of the company through stock options or something. So the ability to actually set quotas and determine whether they're going to be blocked or a warning only, these kind of things are important to do. Of course, we as we talk about actual behavior based controls or intent based controls, we would need to actually understand content. In other words, there would be types of content that maybe a particular agent should or should not be allowed to use. And you can see some of those things here from our user interface. What about, PII, for example, about names or email addresses, phone numbers, Social Security numbers? Well, what about IBAN and Swift codes that are used for banking and for wire transfers? What about government IDs or physical addresses, dates of birth, IP addresses? The list goes on and on, and this is only partial. And, of course, these end up being customized by industry as well. But this starts to show you that when you're dealing with agents, the idea of controlling the content that that agent is allowed to transmit, it forms an important floor of capability, if you will, or an important initial barrier that you just wanna make sure that even if the agent thinks it wants to send something, maybe that's allowed and maybe that's not allowed. One another one is to stop the exfiltration of critical data. This is kind of the action step of what the previous kind of policy step was. You know, we looked first at just noticing that, oh, yes. We can know what agents are running. And then we said, oh, look. We can actually set some limits based on that what they're trying to do. And, ultimately, you wanna make sure that you can actually stop that. And this is a part of an auditing detail, from a session log using Claude Code where it actually, tried to pass out whoops. Sorry. Let me go back. There we go. Tried to pass out some banking information, and you can see that the system actually responded and said, hey. You've tried to pass out some banking numbers, and that's not okay. You can't do that here. And so this idea of being able to not only specify your intent, but actually then take the action to stop it is obviously critical. And that brings us to the second of the slides that I think is although it looks very simple, it has some very profound ideas on it. And I think this one is one that you're going to wanna take to your organization and actually reflect on what it might mean to you. If you're going to monitor and control agentic behavior at the infrastructure level, what does that mean in practice? If you wanted those benefits that were on the slide of this declared intent enforcement, where would we actually need to have controls? Well, turns out we would need them in three places. The first place is you're going to need some control on endpoints. Who runs agents? Well, in the main right now, humans run agents. We're the ones that start them, that point them in a direction, that give them assignments, that probably take their output, combine it with other things. In some cases, agents may run other agents, but I would say that's probably in the minority right now. And so the reality is is that if you want control over what agents spawned and where they're running and what they're doing, you pretty much have to have some kind of agent aware presence on the endpoint. And this comes back to the example I gave of some of our customers coming to us and saying, look. We know engineering is using agents. We just have no idea how much or how many. And one of our customers, it turns out they had fifteen hundred agents running in the environment and did not know. And so it turns out that having endpoint control is important, first for that visibility piece, but then secondly, for the actual control of being able to say, okay. We've got fifteen hundred agents, but as of today, those agents are at least gonna run-in a sandbox, and I'm gonna start getting some telemetry and start monitoring what these things are actually doing and where they're going. And that leads to the second area that is going to be important, and that is the world of AI infrastructure controls. And what I mean by this is protocol aware controls that are part of the infrastructure. In other words, the agents can't bypass them. They're in line. They're, they're a process that the agent has to go through in order to get to LLMs, in order to get to MCP servers, whether those are internal or external on the public Internet. And what kinds of things would you need to do here? Well, again, we're dealing with agents that have an arbitrary ability to ask for whatever they want or whatever they're constrained to do. If we've got them in a sandbox and are doing some initial controls, how do we police and check the various messages that they're sending? If they're actually trying to do that example like we saw of sending banking information or requesting banking information or sending chip designs or something else, how are we going to catch that and stop that? How are we gonna make sure that we have a way to keep information that shouldn't be exfiltrated from actually going to a public, LLM instance or for a negotiation with an MCP server that is not on our organization's permitted list. So having some controls that are actual AI protocol aware are tremendously important to securing how this works because agents are going to invoke LLMs. The small brain of an agent running on an endpoint is going to use a larger brain inside of an LLM that either you own or is in a public cloud. And the third makes a lot of sense. If you have an agent that's gonna do useful work and it's perhaps gonna collaborate with other agents or LLMs to do useful work, it's going to need data. It's going to need information, the same as a human doing whatever task that was. And so that means there's going to need to be connectivity to the operational world of your business. And that may involve IT systems, almost certainly, whether that's databases or applications or APIs that are running inside of your cloud, that are running inside of your on premise data center. It's certainly if you're a manufacturer, it's going to also involve your OT systems. If you think about it, OT systems generate a lot of data from sensor networks. What's a good way to process that? Well, agents aren't gonna complain about the data load of processing all of the sensors in your plant. And how easy are the APIs for those OT systems for AI to understand? A lot of them are fairly simple. They're easy for AI to understand. If someone wanted to use Claude to write a little agent that could control something or on some boundary condition, puts in some safety effect or something else inside of your plant, that's probably something that somebody could write inside of a couple of days using Claude or something like that. And so, obviously, it's going to be important that the back end systems themselves actually have appropriate controls around them so that only the agents that are authorized to access them, only the LLMs doing things that the LLMs are authorized to do, have access to those back end systems or to those industrial or medical controls. So these will let you answer important questions kind of at each point along the way. At the endpoint, we get to know who can drive the agent and who can access the runtime. We can control what LLMs things can reach and what systems the agent can actually touch. And these, I think, are durable ideas that as you think about agents and how are we gonna secure them, you're gonna wanna think about, like, these three things. You may use one vendor for this. You may use multiple vendors for this, but I can guarantee you, you're gonna want to have technology at all three of these locations. Well, I'll tell you a little bit about how we do this here at Zentera. We have a platform that is designed around AI, around compute, around OT, and around, ZTNA and connecting things up in arbitrary ways, all tied together with an orchestrator, a central brain, if you will. And the idea is is that people pull out of these modules the functionality that they need in order to protect the things that they have. So for some people, they have a lot of intellectual property inside of compute. Others have a lot of manufacturing or status systems or health care, medical systems, critical infrastructure, so on and so forth, and they have a lot of OT things. And there's some need to get vendors into these things. And so what happens is people pull these things as they need to to get the job done. I'd like to introduce you to a powerful idea. Our AI product works off of a basic idea called enclaves. And this is something that we designed in conjunction with some of our semiconductor customers. The idea being that if you have design prod projects or important intellectual property, these things exist inside of projects, and you need some kind of container to put around a number of different things. And it's not just systems. It could also involve agents. It could involve LLMs. It could involve access to certain websites, that maybe represent a design assistance vendor, or it could be certain file types. And so this idea of an enclave, I mean, it would be familiar to network people. It's like the idea of a subnet of VLAN or a zone, but you'll notice that some of these things are not network addresses. So the idea of an enclave, it it is limited in the way that a VLAN might be, but the things that go in it are a lot more diverse, and they don't have to be geographically located in the same And what's obvious is is that when you're working with agents, you need to have a single policy boundary that you can place around a project or a work stream. And in that way, an agent that's supposed to stay on task can only stay on task. They can't go browse other projects and, you know, investigate other things or be told to go investigate other things that they don't have business doing. Well, the way that these enclaves work is the idea is is that if you have different parts of the business, there might be different types of, AI usage. This could range everything from, you know, traditional machine learning to, obviously, LLMs, MCP servers. It could involve a wide range of different things from, you know, things that are, you know, actually generating code for developers to things that are primarily doing some type of historical analysis perhaps inside of finance. And the idea is is that each of these enclaves would have the resources, the agents, the LLMs, the access, whether these are public or private or third party, doesn't matter. Whatever that access is, is controlled by an AI session controller. That's that in line infrastructure based control that actually determines how the users and how the agents are able to interact with LLMs, with MCP servers, and other agents. And that session controller can ensure that whatever the AI resources are are then accessed by whatever the correct servers are, databases. This could include OT devices. And in turn, each of those devices, the development servers, they could all actually be inside of a chamber. That's another word that'll be important for us here, enclaves and chambers. Enclaves take up the whole, you know, kind of everything related to an AI deployment, and chambers are actually a smaller construct that can sit around individual or groups of servers and OT systems. So you can see that this type of situation actually meets those architectural requirements that we mentioned a few slides ago, that you're going to need an endpoint sensor to be able to detect and fingerprint, the agents that are running on systems as well as to sandbox them. You will need to be able to specify some kind of an enclave to have a boundary inside of which a particular task or project operates, and you're going to need to have, some type of session controller, gateway, you call it what you will, but you're going to need that infrastructure component in order to deal with things as well as these chambers. And, of course, if you can get all that in one unified platform, so much the better. Now we've mentioned this idea of chambers to go around various bits of compute inside your environment, and this is something that Zentera has done for years. We actually have a part of our product that is specifically designed to secure virtual machines, physical servers, easy two instances, all of the things that people use for compute. And this is, agent-based visibility and control. And what that means, it's not in line to traffic, not a kernel modification, but it uses the firewall that's built into the operating system. And what happens is that it can then build these virtual chambers around the things that are important to you, whether those are actual Kubernetes containers, virtual machines, bare metal, on premise, in the cloud, doesn't matter. And what happens is that it will close all of the unused ports, so there's nothing there for agents to go poke around and find what else this thing can do. There is a zero trust policy for all the core services. You want your devices to only listen to DNS from your DNS servers and not from other places or from agents or anything else that gets a different idea that it'd be fun to redirect something somewhere. So we put in a zero trust policy for that, and then we put it all under continuous orchestration so that if agents are coming on and offline, if access is being added or removed, all of that can be kept constantly and continuously up to date. Now this same idea of making chambers to put around compute systems is also available for OT systems. And, certainly, this affects some of our manufacturers, whether it's in the semiconductor space or people that are that are making everything, plumbing valves. And it certainly is something that all of our medical customers and all of our critical infrastructure customers and water and electrical utilities and things like that appreciate. And that is if you've got devices, whether it's an elevator control or a door badge reader or your HVAC system in the corporate headquarters, there are things on which you cannot put an agent because they don't run Windows, Linux, or Mac OS. These are things that run embedded operating systems. And the only thing you have for a security stack is an Ethernet cable. Go. Well, if all you have is an Ethernet cable, we presume that you need a place to plug that Ethernet cable in and that that place needs to be able to do this chambering function. And so we manufacture a family of hardware devices ranging from two ports, some of which are industrially hardened, all the way up to rack mount data center type switches like the one you see here with SFPs and configurability and modularity and all of these kind of things. My point is not to go into any of the details of the hardware except to say that if you have OT things and if you have Agentic AI or expect to have Agentic AI, it's going to be very important to be able to have an in line capability that can act as the enforcement point for devices that are not intelligent enough and capable enough to accept software based controls the way that maybe your data center servers can. And so these devices that we've built are layer two transparent, and that's very important. That means they don't participate even in your spanning tree or your VLAN trunking protocols if you're a technical person on this call. These can be designed so that OT devices are plugged in one per port if you have very expensive, very sensitive machinery. If you have seventy five temperature sensors running down a quarter mile packaging line, you might choose to have all of those sensors packaged up into a subnet VLAN or zone, and you're not gonna burn, you know, seventy five ports on one of our appliances. We understand. That's all fine. The main thing is is that you want a control point that is able to place the things behind it into a protective chamber and then be able to participate if an agent says, I want this data, an agent says, I want to change this value, is that permissible? You need a point of enforcement just like you do for the servers, and so that's why we here at Zentera manufacture such a thing. Now the way that this all works together is in the real world, there's going to be a whole bunch of different kinds of technologies. There may be, you know, some type of cloud management system or an LLM. There could be remote users out there in the world. There certainly could be a variety of different systems, both data center systems as well as OT or industrial controls. Again, whether it's as simple as just your elevator and your HVAC controls or it's as sensitive as an entire manufacturing plant or churning out chips for Apple. In all cases, what we believe you're gonna wanna do is to be able to put a chamber around those important things so that they're isolated appropriately. And what that means is then we can set up the correct zero trust policies so that if this is the management device for this thing, then that's permitted and allowed, of course. That's the intent. That's the declared intent. We expect this thing to come in here and talk to this other thing. And what if you are not that thing? What if you are an agent that is not authorized or you're supposed to be an accounting agent? Well, if there's no policy that's permitting you to talk to this part of the environment, you just can't get there. That's the zero and zero trust. Zero connectivity for you if you are not a trusted person or, in our case for this webinar, a trusted agent with the right permissions. And the same thing is true even for things that may be as far away as the public cloud, whether that's a cloud based vendor management system, whether that's a cloud based LLM, whether that is an authorized remote user or an agent that is running on somebody's laptop while they type away inside of a Starbucks across your, you know, VPN. In all of these cases, you're going to want to be able to have the controls for exactly who can access what. And here at Zentera, we believe that these chambers are the appropriate way to protect things, whether they're OT or IT, and then have that work potentially even inside one of these enclaves so that you can control all of the AI and agentic behavior that may be trying to affect these IT and OT systems. Well, to pull, all of that together, we'll talk a little bit about the fourth component of the Zentera product family, and that is something that we call connect. And this is a simple universal ZTNA capability. It's universal encryption. It'll get you from anywhere to anywhere with or without encryption whether you are a user working remotely, whether you are a user or an agent inside of the corporate environment. It could tie things together from cloud to the OT environment. It could tie users or agents to OT. It could tie OT to IT or the cloud. You get the picture. And the whole idea is is that this is overlay encrypted technology. What that means is that it doesn't involve any changes to your existing routers, switches, firewall, subnets, VLANs, or zones. Your network team can rest easy. When Zentera is used to build these enclaves or to build these chambers, there are no network implications. And that's very important, because very often, when we need these kind of controls and security, there's somebody on the infrastructure side that says that is too expensive. I don't have enough people to create that policy, to administer that policy. And so it is important that when you look for solutions that can do enclaves, that can do chambers, that can get users in and out, or they can secure agents that may not have native encryption, or you're dealing with old OT systems that definitely don't have if you need to get that stuff secured, well, it just makes sense that you might want a module that's called connect in order to connect these various things. Well, as I conclude my portion, of the official presentation portion of the webinar, I think there's a couple of important takeaways that I'd like to leave you with. The first is that regardless of your personal perspective on AI and whether you like it or use ChatGPT or Copilot daily or not, agents are coming. Over forty percent of enterprise software vendors say they are going to ship agents to their customers. So if you use Salesforce, if you use Workday, if you use NetSuite, if you use, you know, big design packages or industry wide software that comes from a Fortune 500 company, you can pretty much bet that you're going to have some agents by year end. If you're using ten bits of software, four of them are going to give your users agents without telling you insecurity. So that's coming. What do we need to do about that? What we need to do is to frame our world in terms of declared intent. In other words, we need to say at the beginning what we want and make sure that that can actually be enforced inside the environment, especially when we're dealing with something that has the capability to go off and ask reasoning engines to help it function. And that means the boundaries have to be a little tighter. And so we observed that there is going to be control needed in three places, the endpoint, the infrastructure, and around the IT and OT controls themselves. We introduced this idea of enclaves in order to put all of the components of AI together with chambers, which are the things that go around individual servers and OT systems. And when you tie all of these things together, it becomes very possible to identify, to control, and to make sure that the agents stay within the bounds they are assigned. Whether those bounds are financial, whether they're security, whether they're regulatory, the governance, there's lots of different reasons that we would need to keep them in their boundaries. But whatever they are, if you implement these ideas, you will be able to control Agentic AI. So with that, I'm going to end the formal part of the, the presentation, and I think, Michaela, we'll be happy to take, some of the questions that have come up. Thank you. Thank you, Nathaniel. And, of course, thank you to your presentation and session just now. Now, for everyone, our we're now open for your questions. We have a q and a box below. If you have anything that you wanted to ask Nathanael, kindly drop them below. We have some questions coming in here, Nathanael. Maybe we can start with this one here. We have our prospect asking, how does Zentera enforce policy on AI agents in real time without causing latency or slowing down the AI's performance? Yeah. That's a that's a great question. Obviously, very important, particularly the more high performance the environment. The interesting thing is, I think if you were to go and actually measure the latency that you get out of most agent or agent LLM interactions, you're talking hundreds of milliseconds between responses or, you know, various bits of transmission. So, obviously, there's no such thing as a free lunch. If we're gonna process something, it's gonna take some amount of milliseconds to do it. I'll just observe that the amount of time that we take to process something in the low single digit milliseconds is a nothing burger compared to the hundreds of milliseconds that are normal for normal agentic transactions and things to occur. So, there's probably more detail that we would need to talk about in terms of your specific environment and what your concerns are. Because, obviously, like all things compute, compute can be scaled. If it can be scaled for agents, it can also be scaled for latency. So I I hopefully, that's enough of a summary answer, but definitely hit up Skyler if there's more that you wanna talk about there. And myself or one of our application engineers will be happy to get on the phone and go into the particulars with you. Very well said, Nathanael. Another question that we have here, how does identity-based access control work for an AI agent? Do they get it does the agent get its own identity, or does it inherit the credentials of the user who triggered it? The short answer is yes. You can you can imagine that, in the real world, there are organizations doing both. I think in our customer environment so far, people have defaulted at the beginning to the agent is running from a user laptop or it's called by a user, and so the user's permissions are being used as the initial basis for the task. And there's good and bad about that. Right? Like, in the world of it depends. The thing is a lot of users are pretty over permissioned for what an agent's actual responsibility are. And this is a concern that some of our customers have raised. It's like, look. We have a username. We know this users can spawn this agent, and certainly Zentera will tell you that too. We can put controls on the agent that are different than the user. That's important thing number one. So if the user has broad permissions, you want the agent to have limited permissions. No problem. But then it becomes it comes down to, well, then could I assign, you know, some kind of identity direct to the agent? And we think that that is the way that the world will eventually go. Obviously, through digital certificates and other things, we have lots of ways of identifying code, of identifying systems. And there's no reason conceptually why an agent shouldn't be able to have some identity, and then that identity would have super limited permissions that are inherited at runtime probably out of some runbook or other things that people from this part of the organization, when they spawn agents, they automatically inherit this whole set of policies and and procedures. Right? So I think this is an evolving space. You know, the answer is nuanced, but I suspect that at the beginning, things are going to depend on user permissions. And if you think about a lot of your users, the average user can go a lot of places. They can look at their payroll data. They can open their email. They can go to certain databases and HR systems and all kinds of things. And a lot of those are things that you wouldn't want an agent anywhere near. And so that's why we think that this, you know, intent or declared intent based enforcement is so important, especially if you're starting from a user perspective. Understood, Nathanael. We also have an interesting question here for you. They're asking, our organization is very concerned about runaway talking costs of AI agents or users running up big bill bills accidentally. Is that something that Zentera can address? It is. It's actually one of the first things that our early customers asked is, you know, on the one hand, they have a board mandate that engineers are supposed to use AI. Like, they want the engineers to be writing agents to be trying to speed up their design and their QA workflows. And so that's all lovely, but no one wants that five hundred million dollar bill from Anthropic if you don't have some controls in place. So how do you monitor that? How do you enforce that even at the infrastructure level if something on an endpoint is turned off, disabled, the engineer removes it? You know, we have a way to actually do that at the infrastructure level. So that's important. We think that's a table stakes capability. Perfect, then. Now they're also asking, Nathanael, what kind of granularity do you have into agent and LLM interactions? Can you support auditing requirements? We can. We actually have in the example that was shown in screenshot, there was actually a little flow there where you could see the AI and the agent interacting. And when it tried to pass, you know, material that it shouldn't in the form of some financial information, that was immediately blocked. And you could see the actual back and forth before the block. And so we actually can keep the sessions and, you know, be able to list for auditing purposes exactly what happened in a given session. So that's that's important. Obviously, data volumes and what you need for auditing and which systems you need it for, there's design constraints and all of those things. So, again, you know, if you've got more specific questions, reach out through Skyler, and we'll get on and and get that get that taken care of for you. And with that being said, Nathanael, I think this will be our last question for today. Earlier, you mentioned AI and OT. Aren't people going to keep AI away from manufacturing systems? Well, you would think so. I mean, at one point, you don't want the terminator. Right? Like, of of, like, the AI goes crazy and the the robot arm starts chasing you around the factory. But on a serious note, if you think about an OT environment, you've got two primary things that are happening. The first is that you typically have a large volume of sensor data. And anywhere there's a large pot of data, AI becomes very tempting because humans are not great at big volumes of tabular data, and computers are fabulous at it. And so if you've got a lot of sensor or other data that's coming out of a manufacturing environment, wouldn't everybody like to find five or ten or fifteen or twenty percent more efficiency in there? Is there a trend that when the temperature rises by, you know, half a degree, all of a sudden you lose one percent of output? Well, these are the kind of things that are hard for humans to notice, but are really easy for an AI to notice. So I think that anywhere where there's large data volumes, you're going to see a pull towards AI and the and the analysis that it can perform. So it's gonna come. And the second thing is this, and we mentioned this in passing, is that most industrial control systems are based on older technology, shall we say. The APIs that these systems are using are relatively simple compared to the API for Claude Code. And what that means is that any AI can easily ingest the complete API for your industrial and factory control systems and would be able to write useful code for you. If you don't like the software that Rockwell gave you, well, you could probably make your own inside two weeks at this point. And so I think that people will do that. I can tell you that we're talking to manufacturers every week that there are pilot projects using AI either to start trying to find efficiencies in the data volumes coming off or that are actually looking to to say, hey: Could it be useful as trigger for emergency safety stops and, you know, things like that? They may not be asking AI to run the assembly line just yet. I get it. But it doesn't mean that there's nothing going on. And I think the trend line is clear. The data's there, the use case is there, and with the right limits, I think people do it. Very well said, Nathanael. Now before we wrap up, do you have any final thoughts or key takeaways that you'd like to share with our audience for today? Probably just this. We've talked about a lot of different things. We've touched a lot of topics, and any one of them could be a forty minute conversation if it was tailored to your environment. And if that's the thing that you want or need, then please just reach out to Skyler. All of you have her email address because it's how you got the invite to find my smiling face this afternoon. So if you just hit reply to that thing, and tell her, you know, what you're interested in doing, we'll be able then on our end to make sure that we get the right humans and get you the help that you need. Thank you, Nathanael. And thank you to everyone for spending your time with us today. As Nathanael said, keep an eye on your inbox. As Skyler, we'll be reaching out to everyone, not just with the recording of our webinar, but also to invite everyone to a one-on-one discussion here with Nathanael and our team. Again, thank you for joining us, and have a great rest of your day. Bye, everyone.