DOP 358: Just-in-Time Access for AI Agents

Speaker A: A burst pipe, a dead water heater, the AC calling it quits. Who do you call? HomeServe is an easy way to handle unexpected home repairs with plans covering stuff basic homeowners insurance usually won't. Instead of scrambling for a contractor, you make one call to get the repair process started. Join the millions of customers who trust HomeServe right now. Go to HomeServe.com podcast for 50% less your first year. That's HomeServe.com podcast savings compared to renewal

Speaker B: price void In Florida we took full AWS environment. We installed multiple OpenCloud agents that's going to manage this AWS environment as a company. We had the CEO, we had the support, the builder and we took all of that, we put it together and we opened Discord channel saying everyone that want to try to trick them, just go ahead, try to trick them, right? They know how to improve themselves. And this experiment was very interesting because what we saw is that is never mind how they protect themselves and they really great in doing that. You can still trick them. You just need to find a way and it's a problem from security perspective.

Speaker C: This is DevOps Paradox, episode number 358 just in time access for AI agents.

Speaker D: Welcome to DevOps Paradox. This is a podcast about random stuff in which we, Darren and Victor pretend we know what we're talking about. Most of the time we mask our ignorance by putting the word DevOps everywhere we can and mix it with random buzzwords like kubernetes, serverless, cicd, team productivity, islands of happiness and other fancy expressions that uh, make us sound like we know what we're doing. Occasionally we invite guests who do know something, but we do not do that often since they might make us look incompetent. The truth is out there and there is no way we are going to find it. Yes, it's Darren reading this text and feeling embarrassed that Victor, uh, made me do m it. Here are your hosts, Darren Pope and Victor Farsek. Victor, I'm going to lay out a

Speaker C: story and tell me if it sounds familiar to you, if it's ever happened to you in your career. Are you ready?

Speaker E: Go for it.

Speaker C: Alright, you've got something going on, production's on fire. You need access to a table that you've never touched before. You need some access. You file an access request. You then make a phone call over to the desk telling them that you filed an access request. You, uh, send a slack saying that you left a message saying that you created an access request and then you walk over telling them that you left a slack that you phone called to get an access request processed. Does that sound even familiar to you?

Speaker E: Fortunately for me, it sounds like a distant, uh, memory, meaning that, uh, I'm not working for a while in companies where you need to, you know, do all those things.

Speaker C: But wait, it gets better. So this whole process that you just went through took 25, 30 minutes. And of course the incidents are weak and. But of course the incidents resolved itself in the meantime. Customers left during that time. Now imagine this happening every day of the week. What we want to do today is talk about what would it take to make that experience. Maybe not suck or suck way less without giving everybody the keys to the kingdom. On today's show, we have Ophir Stane on from Opono. Ophir, how are you doing?

Speaker B: Great. Thank you for having me.

Speaker C: Does that story sound familiar to you?

Speaker B: Oh, it is, yeah. It's some story for me. And today in Apono is something we help companies with, but going back, it's actually something I noticed as being an, uh, engineer leader and feel that pain from the engineering side every day in my walk.

Speaker C: It's amazing that that story I told actually happened to me multiple times at a company I worked at. I could never get around that. It's like, again, I get to the end and it's like everything's already solved. Whereas if I, if I wasn't the one doing it or somebody else could have done, you know, there's lots of different reasons why that can happen, but now that we're in a world, I'm going to go ahead and just jump into it. Now that we're in a world of humans and non human AI, it seems like access controls and quick access when we need it is more important than ever. What do you think?

Speaker B: I totally agree. And I think there is kind of like, uh, that kind of paradox. We can say that take productivity and security risk and put access management in the middle. And you see organizations struggling to find the balance between those two. And it was always true in the past. When we think about human access, when you need to understand how the engineer going to do their work without getting access to and keys to all of the kingdom, right? You can't expect what they will need tomorrow. So you need to kind of prepare that beforehand with that. We see security risk coming to this area and we see identities and access as the main point of security leveraging to go around and take data or do something in the environment. So this balance is very tough to find in the human world. Now when you Put it on agents, it's even greater. And this paradox of agent are really really powerful when they get a lot of access. We know that about humans. But for agents it is even better if you get agents that have access to all of your production environment, to the databases, to the kubernetes, to the cloud and they have data from the log analytics and they take all of that together. They're really powerful. But with that they create a huge risk. And we see that kind of like struggling is actually involving with those agents.

Speaker E: They're also getting better. I uh, feel that we are already getting to the point where actually they're better at respecting rules than we are. Lately I have constant, let's call it struggle with cloud where I say do this, do that, push to git and it stops kind of uh, you told me I cannot push to git. I reject your request. While uh, me as a person would, assuming that I have access, I would push it sooner than AI itself these days.

Speaker B: You're right. And I think AI is really really great and do what we told them to do, right. And I think it's part of the mechanism of LLM that we trained to kind of like help us in this sense. And they are adjustable. This is part of their power. They are non deterministic. We cannot predict how they're going to act. And this what give us a lot of kind of like uh, vision on the future of what we can do with them and how they can help us in the organization. But with that they are non deterministic so they can be manipulated. And we know this. In the security space there is a huge topic about social engineering. How we're going to trick the human to do something he didn't expect. Machines never been in that threat. We never thought about uh, my application, my computer cannot decide to do something else than what it programmed. It's a deterministic software and non deterministic software and agents and LLMs actually can be tweaked. And we did this very uh, interesting research. We took full AWS environment. We installed multiple OpenCloud agents that's going to manage this AWS environment as a company. We had the CEO, we had the support, the builder and we took all of that, we put it together and we opened discord channel saying everyone that want to try to tweak them, just go ahead, try to trick them, right? They know to improve themselves. And this experiment was very interesting because what we saw is that never mind how they protect themselves and they really great in doing that. You can still trick them. You just need to find a way and it's a problem.

Speaker E: From security perspective, a better experiment would be if you did the same thing to both AI and humans. What I'd like to say is that the question is of course you can trick them, right? They're not this deterministic. We are non deterministic. The question I have is who is easier to trick these days?

Speaker B: So I think probably agent to trick human. It's easier. And I think the way that we protect ourselves from that and it's really interesting when we think about agent and what's going to be the future of that is different methods of accountability and ownership. Because the employees in my company as an attack vector, as an internal threat have all the legal obligations that protect me from them and their experience, et cetera. And I think today we are in this revolution about how it's going to work for agents. And definitely maybe we will see some legal terms for agents in some way or training for agents in some way that's going to duplicate the same method. And it's definitely something we see in companies. But a lot of the companies today, as far as I'm talking with them, are really in the transition that they don't know how to leverage agentic in a safe way. It's kind of like they are seeing this trade off that we saw on access management is do I going to move slower? And with agent slower it's very, very slow. If you don't leverage agent, you don't leverage AI if you keep doing things as we used to without the innovation of what is provided. Or are you going to be secure and stay secured and be slower or move fast but take the risk and just go forward, provide access to anything, ah, use agent to anything and do that. I think it's a real struggle and I don't see one path that beat the other one.

Speaker E: So it's a kind of it's impossible question. Nobody wants to be insecure and nor anybody wants to be slower.

Speaker B: From what I excited about. The space that we exploring is this paradox because it's true no one want to be in risk and no one want to move slow. So it's kind of like the impossible question and I think there is no straight answer on that but exploring how to make organization work in efficient way on that it's really going back to what we all know about. What we start with is the human that need access and way to this access. And we say it can take 20 minutes, it can take an hour, it can take A week and how you streamline processes and understand that the non deterministic humans with the non deterministic AI create a very dynamic environment. For this dynamic environment, the dynamic company we need to build these dynamic processes. And I think this is a lot of what we will see in the future is more dynamic processes that are linked with the technology and the new human nature into stay safe and move fast into the environment. And it's really the DevOps mentality if I think about it, automation and streamline and dynamic chain things. It's really a lot of what DevOps about.

Speaker C: When you said non deterministic humans, non deterministic AI but wanting deterministic results, to me that's like two wrongs don't make a right. I don't think it's a solvable problem.

Speaker E: You cannot have deterministic results for unknowns. Right. I cannot deterministically deduce what will be my code before I write it.

Speaker B: You're right. But when I write it, it's become deterministic. And I think this is what we see in our life today in the digital space.

Speaker E: In that case, everything AI does is deterministic.

Speaker B: In the end, yes it is. And I think it's not predictable. They are non deterministic by their thinking, but the result are deterministic. Their output is deterministic. And the way I'm saying that is this is a lot of how we actually thinking about protecting this and implement that in space. It's how I understand that the reality that I live in is non deterministic. Everything can change, everything needs to reevaluate in the output. So if I think about agent and AIs and I do that for humans as well, I just used to do that because I jump between the human space to the digital space. But agents are already living the digital space and we cannot skip that. But let's take an example. I have a developer, I cannot predict what he's going to do. I, I put the processes of CI, CD and developer lifecycle in a way that's going to make the non deterministic deterministic and predictable. And I know that my production environment doesn't going to have a huge risk, leak or vulnerability because I have the security check in the cicd. I'm doing the two pair of eyes to validate my code. I do all these checks to make sure that the outcome, deterministic outcome going to be something that I can live with. And I think today in agents we need to think about about it in the same way.

Speaker E: So what you're saying is essentially you don't have bugs in production, you don't have outages in production is what you just said. I don't believe you.

Speaker B: Yeah, my production have a lot of bugs. So it's definitely not what I'm saying.

Speaker E: Basically you just said hey yeah what we do is not deterministic but then at the end of the process, at the end we have deterministic process so that we ensure what's or not and yet we don't.

Speaker B: Mhm, you are right. But the code that written in my production is already have all the vulnerabilities and all the bugs that he can have. Sometimes I don't know about them. Sometimes there is a zero day attack that's been created to a library by some uh, governance out there. And it was in my code before I deployed. Right. Like it's a deterministic bug. It's not something that non deterministic that created. I didn't know about it. So I think we can differentiate between deterministic and non deterministic and unknown. I always try to be in the place that I know most of the thing but the reality is that I never going to have the ability to know everything. But it's still and again it's a philosophy conversation, it's still kind of like deterministic because it's already out there. And and I think the illusion that we have from LLMs or the nature of human brain is that is really unpredictable and you can challenge that and say it's predictable because it's a neural network that have that kind of like weights or a brain that have a kind of outcome. But uh, if going to my production environment in that case I want to feel safe, I want to have the control and the guidelines that going to help me to be in the better side. It doesn't mean it's going to be perfect.

Speaker E: Yeah. So essentially what you just described is Schrodinger's cat. It's maybe deterministic, maybe non deterministic. We won't know until it happens.

Speaker B: Yeah, it's actually exactly Schrodinger cat. Because when I open the box it is live or dead and it's not in between. But until I open the box, until I have this known vulnerability, it's an unknown. But I want to search for it. I want to search and open the boxes of my code, open the boxes of what the agent are doing in my environment and try to look at it to understand if they okay or not. It's really about jumping from what we used to work with deterministic software that we write that it's kind of like the bugs and security risk that we know combined with the unknown that we're going to discover. Because I'm saying in an honest way, I don't have the answers in the future of how agent going to operate and how security vulnerabilities of those agents going to work. I do know that we need to build the processes and the controls that we build for deterministic software, for non deterministic software as we see today.

Speaker C: I think those guardrails that you're calling out should have been there for humans. Those same human guardrails apply just as much to agents, if not obviously more. But then agents will have their own set as well.

Speaker E: If everything is the same and you change the speed, then you have a problem.

Speaker C: Well, okay, yes, I agree with that. What I'm saying is I think the human guardrails are the foundation to where I mean some may get pulled out. But to say that we don't allow cluster destroy through these credentials or through whatever as a human, that makes sense even much more so for agents, right?

Speaker B: It definitely is. And I think this is why it's so confusing when you think about agent in the environment. We have that debate with customers and this is a good debate because each customer come with their philosophy about agent and it's create a lot of good conversations about that about is agent is a non human identity or a human identity? This debate about is it a human identity that they need to kind of like onboard my agents with their goal and their roles and their responsibility in the environment or they are non human and they are just another machine. Right? It's another application, it's another a server that I have or a lambda that I need to manage. In the same way when we think about guardrails it's really challenging because they a little bit of both. They move in a machine speed. They definitely move in a machine speed. And this speed, it's too fast for us for uh, our current access reviews and controls that we have for humans to implement it. But they are non deterministic and by that they really fit very well to a known guardrails that we do for humans, but it's again too slow. So I think if we have an agent and if we have a human, we can think about the guardrails in the same way. But the implementation of those guardrails going to be a challenge to the machine speed that the agent going to operate in.

Speaker C: You could pull out a DevOps phrase that everybody loves. Pets versus cattle. If you've named your agent, it's human. If you haven't named your agent, it's a machine.

Speaker B: We see a lot of both. There is humans with the machine name as well. But I saw that as well. But yeah, I think this illusion and I am saying illusion because in the end when I think about agents, what I see is the wild true loop of calling an LLM again and again and again and act based on the response. When I see any agent framework that do that, do the same. But the outcome of that, the output of that, it's really a thinking machine. It's really, it's illusion of a beam. And I think when we think about it, we as humans we need to understand and decide how to react to that. And a lot of the users that use these agents and LLM already today, they get feeling to this bin and they have connected to it. And this is where the name comes from, right? Like so if we provided the name, we provided the goal, we think about it, it's great. But it's a mirror reflection that what we searching for from the computer. And I think this is a lot of what affect our ability to think about that and work with that. And uh, the truth is in between we're going to see names for agents definitely. I think it's already there. I know myself, I can share. I have agents that I work with that they help me on my, my day to day, they help me with research and calendar and that kind of things. The autonomous agent, they run by themselves. They wake up and send me messages and I talk with them and when I talk with them with my main agent, she speak with me and she say I am a girl, right? Like I am a girl agent. And I talk with her as a girl. I know it's a machine, right. I know it's. In the end it's a loop of LLM. But this interaction are uh, really, really powerful.

Speaker C: Until they turn on you.

Speaker B: Yeah, we will see.

Speaker C: You have a bad breakup, that's what could happen. I uh, want to spin this a little differently. I'm going to propose that developers don't hate security. What we hate is bad security user experience. Like my story at the very beginning to where it took a day, weeks, whatever to get access to do something. Is there any way to truly solve that? Don't pitch a pono right now. That's fine, we can talk about that later. But what is the correct way of sort of managing that? It's like my Way was the standard way 20 years ago unfortunately may still be the standard way today. For many people that whole space turned around because there are other people like of course Cyberark just got bought by Palo Alto. There's numbers of other things out there. What is the sort of the standard today?

Speaker B: So I think it's really interesting we explored the IAM space of security in the last six years and it's changed a lot in the last six years. And before that I can say that I come from engineering side and I didn't aid security but I aided to being blocked in the end. I want to be able to create and move fast and when I've been blocked by something it doesn't matter if it's access management or vulnerability scanner. Uh, it's going to be very annoying to me as a developer, as an engineer and I going to hate that. So I'm not hating security at all. I'm great with security but it's not my focus. My focus is create and when it's blocked me I feel very bad and I, I've been part of a company in this company I led the engineering group as part of what we needed to do. We needed to go into the servers and went inside and walk with them. One day I'm trying to log in, I get blocked, I cannot get into the server and uh, go around ask what's going on. No one in my team can go into the servers anymore. Oh yeah, we have an audit, we have a SOC 2 audit. So we needed to remove all the access for everyone. But it's okay for three months after that we will get it back. So I said what do you want me to do? You want to go back and stop working for three months and say no, let's find a workaround that's going to work for you but doesn't going to reflect it in the audit. So this example is demonstrate we don't hate security but we want to be able to go forward the business want to go forward. If security is a blocker it doesn't going to work. And I think this is what changed in the last six years. I spoke with many CISOs that see security right now. Their job isn't to be enabler for organization and not a block of organization. It wasn't like that six years ago and it start changing also a lot

Speaker E: changed since back then. Uh, the time of your story is that in the past we were very much pushing changes. Now the systems are pulling changes which means that if you're editing as remotely up to date you don't need write access anymore to your system. Your write access is indirect through git and what's not. And you do have read access to your metrics, your stats, your whatever. So there, there was also that indirect security switch that you're not logging into your servers with write access these days anyways.

Speaker B: Yeah, I think the maturity of this kind of like a uh concept like software development life cycle and those methodologies really help us to be more efficient from an access perspective. And I think there is different companies in different maturity level that act differently. In my story it's less about just the access, I think it's more about the regulation that really affects security. So security is really about protecting the risk of the organization from data loss from um, attacker that going to steal data or harm the business and also the ability to comply the regulation to enable the business. Right. And there is regulation come from the regulator, there is regulation come from customers. There is more regulated industries like financial and healthcare that have more concerns on their data even about read. So it's like the standard of everyone can read everything is not true in all the industries and we need to comply to that in the end. Every business have their own crown jewels, their own most risky thing in the environment and every company have their security exploring what they need to protect the most. The idea is how I do that, how I protect those crown jewelry in my organization. And I think this is where the mindset is changing because the mindset was I just going to block them, I put them in a safe, I drop it into the sea. No one get anything to that. Not access and not changes.

Speaker D: Right.

Speaker B: Don't touch it, uh, it's too dangerous. This mindset is changed because if with also the DevOps mentality and all of that is that everything is changing in a short iterations. Agility is important for business continuity. So this kind of uh, uh, uh mindset was first in developer and engineering groups but it wasn't in security groups. And this is what we see today. Security understand that they need to be business enabler. Definitely with what's happening with AI uh and agents right now that the business is kind of like leading saying we, we need to use that right now because we're going to stay in bed, we don't care after that we're going to ask ourselves how to protect that, how to secure that. But we need to go fast. So security really acknowledged that. And I definitely see the change in security departments and security culture that are looking about being enabler in the organization and Not a blocker.

Speaker C: Is it really that they're becoming enablers or they're just throwing their hands up in the air saying well okay, let's see what happens.

Speaker B: I see both. Not, not because they want to. I think because it's one thing to say that and the other thing to really be there. And it's a big challenge. And the most sophisticated organization as I see, are the ones that create a very good communication channels between the different departments. The ones that succeeded to create shared goal between the engineering and ops organization to the security side and the business side. They're the one that find the way to implement that very good. The one that have bad communication and doesn't see the other side are uh, the one that's still putting those guardrails and blocks without involving the day to day of their employment organization.

Speaker E: When you say communication you mean communication as in communication we need to design the system or communication we need to operate it?

Speaker B: It's both. Right, but it starts from the design the system. So uh, a uh, security department that doesn't understand the critical of the system or how people uh, operate with the system, they're going to struggle to be able to find good solutions. The ones that are act together in designing the system in a way that fit to that, in a secure way, in a scalable way, in a productive way and then operate that also together are the ones that they see that succeeded more. And when we think about the context, the business context that live in the organization that's speaking about that. Because every business have their own context about what we are selling, what there is uh, accelerating channel, uh, how our systems serve our customers and all of that. The business context is shared because it's lead. Both of the organizations security are moving based on the business context and engineering moving based on the organization, the business context. The one that have this conversation on the business context and do the work together are uh, the one that most successful.

Speaker C: It seems like we as engineers have already solved that. I'm going to air quote solved that. With operations that's always been good. The hard part has been getting business to align with both. Like business will align with engineering sort of business typically doesn't talk to operations at all unless the world's on fire. How do we get all three to truly. I mean you set up the scenario, but I'm trying to think unless you've set up basically small companies within the big company to where they have no choice but to talk to each other, I don't see how you pull it off in A especially in an enterprise,

Speaker B: I don't think it's an easy, easy task. And a lot of the times we joined very large enterprises and we sat in a room and we brought the operation and the security and they say oh, it's the first time we see each other in the company. Right. Like it's an enterprise company, Fortune 500. We sat in the room calling both of them. This is the first time they sat together in the same room. So I think it started with that and kind of like understand that the project are shared responsibility. I know engineering organization and operation. Organization doesn't like to operate with other organizations because they slow them and they annoying and they don't understand what we're talking about. But it's also the responsibility of operation organization to speak with the business people and understand what they care about, what they are looking to do and why. Yes. A lot of the good ideas come from that brainstorming that connect those two sides in the organization.

Speaker C: It's interesting that security had never talked to operations but in reality. Yeah, that sort of makes sense the more I think about it.

Speaker E: And security always talks with everybody. Just you need the direction.

Speaker C: It's a one way conversation.

Speaker E: Yes.

Speaker D: Yeah.

Speaker E: Uh, no, I.

Speaker C: It's.

Speaker E: It's a beautiful job. Kind of like your whole job is to say no.

Speaker B: This exactly what need to change. This exactly what need to change is a culture problem. Because if security job is saying no. So no one want people just come and say no. Right. And exactly. We trying to move forward, we're trying to push the business. What do you mean by saying no? It doesn't make sense. And this is exactly the culture we need to change.

Speaker E: But I feel that that's also kind of wrong. The question is not how do we get to the place where after I ask something you say yes, but how do we get to the place that I don't have to ask you.

Speaker B: Mhm.

Speaker E: Right. I mean ideal world is a world in which the system works in a very time productive. And I never ever speak with a single person outside my team. Yeah, everybody's kind of break down the silos. I'm actually suggesting yeah bring the silos back but make them in a way that actually I can do my job without ever speaking with you.

Speaker C: Let me rephrase that just a minute. The phrase I'm thinking is that's just in time access. Speaking specifically about security, I do it just in time for the time I need it until I don't need it anymore. How long can that time realistically be? Can it be 30 seconds?

Speaker B: Yeah, it can be 30 seconds. But in reality a human and for maybe for an agent, it definitely makes sense. But for a human, 30 seconds, it's not enough for anything. Right. So it needs to be to the time that you need to finish your job to the time that you need to finish what you want to do. This is the idea. Uh, when I think about it, I always think about going to the mall and there is these doors that open automatically when I come and then when I leave, they close. I don't think about those doors. I don't need to open the door or to close the door. It's just happened for me. So in future, kind of like a topic reality, I always can go to where I need to go to justify my kind of like role or what I want to do in the business. But I never leave myself with all these blessed reduce from a security perspective on me. Right. In this reality we can create this kind of a topic situation.

Speaker E: You said earlier the time depends on how long does it take for you to do a job. Is it a job or is it a specific operation? We are moving to the world where actually 247 infinite number of tasks are ongoing.

Speaker B: Yes.

Speaker E: Right. So if, if it's to do the job, it's actually I can tell you right now it's a permanent access.

Speaker B: I totally agree with you and I think this nuance is very important because it's add another dimension to the conversation. The one dimension that we spoke about is the time. The second dimension is the amount of privileges that you need. This really change everything because in ideal world, if you can be very, very specific about the privileges that the privileges are the different permissions that needed to make the action work. There is systems that it's really complicated to understand this match, right? There is system that it's really straightforward and there is a system that is very changed. But when you walk, you call for some actions and APIs that they need to permission folders. If you can be specific as a specific API call and say that only those API calls that I need to do as part of what I am doing right now, the task. So if you can be very specific about that, it's going to be more secure. If you're going to be broad about it and say, oh, I need access to all of the AWS environment as an admin and I'm going to be okay with that. So it's more productive because you don't need to know all these different privileges, but it's create more risk so this is exactly the place that you play with to try to find the balance that I spoke about in the beginning.

Speaker E: But if it's access per operation, not per uh, task, then every operation is an API call and every API call is specific. There is nothing for me to be specific. I'm literally executing this right now.

Speaker D: Mhm.

Speaker E: And this needs access. And that's something through the shared fact that is going through an API is specific by the nature of it.

Speaker B: Yeah. So the idea, and again if we think about this uh, topic world is that you don't need to think about it. And I think this is what we looking at in our vision, how access need to be in the environment. Access need. And it's really, it's actually pretty funny because if you think about DevOps is about making everything automated, making everything dynamic, servers are going up and down. Our system is a pipeline system that change things. But when we think about access it's a static policy that never change, just provide these roles and stop thinking about it. And it's kind of like the half percent of everything else you do in this space. And what we believe is that access in some way need to be dynamic exactly like everything else. And you need to change based on need, based on changes that happen in the environment, based on the context that change business context and environment. The change, the access need to change with that. And in a topic world you don't need to think about it. Like I don't think about the pipeline vulnerability, scanning or mostly I don't think about it when I'm changing code in my environment.

Speaker E: Yeah, but that's very different. Like CI, you can define, hey, CI can do this, CI can do that. I cannot do some other things because it's defined in advance. We know what the workflow is. Now if I'm asking you literally I need access for this specific command, give it to me and the next second I might do nothing or execute a different command and ask you for another access. Basically. Are we now talking about me sending massive amount of requests per minute access requests and then being approved or disapproved. And my question is, if that's what we're doing, what's the criteria?

Speaker B: Amazing. I think in the future it's what we're going to see because you are always living in a space that you don't know what the next thing that you will need to do or you have a high level idea. But if we go to a specific action, you don't know that when I walk my command that I going to Run in two minutes. It's unknown. It's a non deterministic decision. I didn't decided that yet. So I going to be decided when I going to decide to run this command. Now I need to evaluate if this command is valid or not based on the business context and intent. So if I am trying to do something I want to ask. You always can do this kind of like simulation. Of course it's not scalable, so it's a different problem. But this simulation, think about the next command that you're going to run before you click into Enter. Take the most senior engineers, the most senior people, the guy that you know in the organization. Ask them does it needed. How is kids create? Let's explore that right? Like in thinking. Okay. So it's going to touch this environment. This environment have that kind of capability. And this is what is going to change or just do this is the where it's harm the like where the business is. I'm right now running that, right? Like I can evaluate this command and form that to understand kind of like the risk characteristic of that based on the intent of who and what you're trying to do. In a perfect world, this evaluation take nanosecond after you click the enter and it's dynamically evaluated. And this is exactly what's not happening today. Today everything is static. The decision of this command to be executed already done two weeks ago when someone in security sat with your manager and said of course this engineer needs all of this and this and this and this in their work. And they didn't thought about where you running it, right? It's not really you that run that. Like all of this evaluation of risk need to happen in a dynamic way.

Speaker E: But that means that if you now talk about agents, we are talking about evaluation of risk that will result in acceptance or denial of permissions to perform something will be done by. Is done by AI now, not by people. Right?

Speaker B: Yeah. So the execution is done by AI right now.

Speaker E: No, no, no. I'm now asking about whether that operation can or cannot be performed.

Speaker B: Okay, so it's a great question and I think as I mentioned on our uh, research we definitely see AI can help in that. But it's not going to be a bulletproof and this is part of the problem.

Speaker E: So going back to what I said earlier, right. I'm going to be performing thousands of operations. We don't know what those operations are. I'm going to be performing thousands of operations per minute. You're going to give me yes or no for each of those operations individually because of the dynamic nature of that. Correct. You're not going to give me blank permissions to do something. So you're evaluating every single operation to decide whether it can be performed or no. And the huge quantity of operations is happening at the same time. So human is out of the loop. Kind of like there is no people saying yes or no. And then the only two options left for you is to either give blank permissions, say yes, whatever you ask, it's yes, or to give me some mixed permissions that will not work because you don't know what is needed in advance, or to have a uh, different AI evaluating AI. I mean, correct me if I'm wrong, what's the alternative to one of those?

Speaker B: No, definitely. I think it's not an alternative. It's a mix of everything. You mentioned with a dynamic guardrail that you're going to create. So you can create guardrails that going to take in consideration real time attributes when you run the command. Right. And uh, of course it's a combination. I definitely see AI taking in place on that action and everything and evaluate if it's okay or not to do that with the guardrails of your organization that is pre made based on the context that's going to be evaluated in the real time.

Speaker E: Yeah, but guardrails are static. Right?

Speaker B: Let's take an example and I think it's the example that come from engineering side. It makes a lot of sense and it's kind of like a simple one. Let's say that I need to do some operations in production as part of me troubleshoot or need to do something critical that is out of the ordinary. Right. And I need to do that most of the time or all the time. When I do that, I am on call and in my on call shift I have an open incident that is open from the system or from whatever this context is not being evaluated. When I am saying Ophir have admin access to the environment because he need to do that. Right. But when I evaluated the action, I can ask does Ophir's uncle right now, does he have an open incident? And if he have I going to approve that in real time. Right. These guardrails are predefined, but they are taking in consideration a real time attribute.

Speaker E: But when you say I'm going to approve or not, who is you? You as carbon or you as silicon?

Speaker B: Oh yeah, sorry. So me as the one that put the guardrails beforehand that are dynamic guardrails. In this example, the taking in consideration the Attributes in real time for the operation.

Speaker E: Yeah, but how will you. Okay, guardrails as if you're going to analyze the context and make a decision or guardrails as if Joe can do this, Joe cannot do that.

Speaker B: I'm providing the guardrails for the engine that's going to do the decision in real time. So the engine that doing the decision in real time is not human, it's silicone. We cannot put a human over there because we had this example in the beginning when human is part of the decision and we know how slow it is. So it must be silicon. But it doesn't need to be only AI or something that we cannot kind of like follow up and understand the decision. Right. It can be a mix of policies with those kind of like uh, attributes and guardrails that are going to be evaluated in real time. That going to help us to achieve that, to be honest. And again we are planning kind of like to the best future that we can think. And there is a lot of challenges to be there. No one is there yet. People are choosing different tiers of access and doing those kind of like decision making in a real time for them. So it's different tiers. For example, I don't going to evaluate every action that you're going to do in production while an incident and that and that and that. I probably going to evaluate a set of admin permission even. Right. And so there is a bubble that I am evaluating and inside this bubble I give you more an automatic approach. These bubbles of how many privileges for how long is change based on conflict the intent and the needs of the organization.

Speaker E: Yeah, but my doubt is you mentioned quite a few times intent and context, not as in LLM context, but you know, context of the organization and stuff like that. But that is now changing by a minute.

Speaker B: Yeah, right.

Speaker E: Kind of. It's true if uh. Right. Kind of literally there is the change of the company context, the change of the business context is order of magnitude different.

Speaker A: Right.

Speaker E: So you cannot anymore keep up by defining those guardrails in advance.

Speaker B: So uh, you take part of the consideration of what is evaluated in the past and you add to that layers. And this is why it's a mixed of what is can evaluated in real time using AI and using other methods to be able to evaluate those changes that change very fast. But also for human perspective. And this is what we do for years for human perspective, this kind of like a life cycle of getting access, this access bubble for everything I need with the guardrails. It's kind of like it's a much more slower process. Sometimes I need to, I start my walk, I open my computer and now I need to do something. Right. It's a slow process for agents. It's really a challenge for the core controls that exist there out there for keep up with the agent. Because the agent is as we say, is an endless loop that get decisions and execution, decision and execution. And we have a lot of agents doing those very, very fast. So what we do with that is a little bit changing the mindset. And this runtime enforcement that I'm kind of like describing. It's definitely something that need to be implemented. And we don't implement that for humans that are running on the computer. Right. But we can do it for a machine, we can do it for an agent, because the agent in an endless loop of decisions and execution. So why not putting inside this endless loop access decision and guardrails. When we keep doing that evaluation on the fly, of course silicon taking in consideration predefined guardrails with current context and AI, we can now evaluate in the speed of the agent. Without that, we kind of need to decide beforehand do we approve it to do anything or do we block it. Right. And I think this is where I see most of the companies today. If you ask how do you protect your or uh, approve your execution of agent privileges? What, how do you, how do you do that? They say, um, I give it everything or I block it from doing anything. The in between is really tough. And definitely when we talk about more than read operation and read operation, we see more. But when we think about delete, update, insert operations, it's become more tricky.

Speaker C: So everything that you were just explaining to us is that what Apono does and that for example, so it's combination

Speaker B: of what Apollo do today. Then the vision that we seeing in the industry that we need to be able to change to adapt this technology in a way that doesn't going to slow us. It doesn't going to make more people to say no. It's really about where we believe that we need to go. Where I believe we need to go as an industry that going to leverage all of this very, very unique and powerful technology in a way that doesn't going to make us make it slower than it should.

Speaker C: So we're trying to put ourselves out of a job yet again. Great.

Speaker B: Yeah, I think we always have that kind of like a fear, right?

Speaker E: You put ourselves out of the job, but be able to do more interesting things.

Speaker B: I love the framing.

Speaker C: So you can find out more about Apono at Apono IO that's a P o N o IO and all of Ofer's contact information will be down in the episode description. Ophir, thanks for being with us today.

Speaker B: Thank you very much for inviting me.

Speaker C: Uh, we hope this episode was helpful to you.

Speaker D: If you want to discuss it or ask a question question, please reach out to us. Our contact information and a link to the Slack workspace are@devopsparadox.com contact if you subscribe through Apple Podcast, be sure to leave us a review there that helps other people discover this podcast. Go sign up right now@devopsparadox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.

Speaker C: Mhm.