#370 How to Control AI Agents with Formal Methods and Ephemeral Access

Summary

Podcast Summary: Embracing Digital Transformation

Episode #370: How to Control AI Agents with Formal Methods and Ephemeral Access
Date: July 24, 2026
Host: Dr. Darren Pulsipher
Guest: Ev Kontsevoy

---

Brief Overview

This episode dives deep into controlling and governing AI agents in the context of modern, rapidly changing digital infrastructure. Dr. Darren Pulsipher and guest Ev Kontsevoy explore the evolution of AI from productivity tool to full-fledged operational actor, the security and scalability demands this brings, and why new approaches—like formal methods and ephemeral access—are necessary for effective governance in organizations that are increasingly run by AI agents.

---

Key Discussion Points & Insights

1. The Evolution and Governance Challenge of AI in Enterprises

• AI’s Dual Nature and Risk
  • AI agents can make frequent, high-speed mistakes (like deterministic code) but also severe, unpredictable ones (like human errors) ([00:30]).
  • Traditional methods of distinguishing “critical code paths” from non-critical no longer suffice.
  • “All software now must be treated with utmost urgency.” — Ev ([00:30], [24:35])
• AI as an Operational Actor
  • The shift from AI as a tool to an operational entity fundamentally raises risk and governance stakes ([00:58]).
  • Legacy systems of broad roles, static permissions, and manual review can't match AI’s speed and risk magnification.

2. Language for Interacting with AI and Formal Methods

• Historical Analogies & the Role of Precision
  • Like moving from horses to cars, we need new “human systems” (laws, processes, governance) to manage AI ([06:09]).
  • Communication with AI needs to become more precise. Legalese in contracts serves as an analogy—when stakes are high, natural language becomes insufficient ([12:17]).
• Programming Languages & Formal Specification
  • The very concept of programming languages is shifting since AI can now interpret English, but precision is crucial for safety and correctness ([09:04]).
  • “We need something more precise than just human language...we cannot bear the consequences of being misunderstood when you interact with AI.” — Ev ([13:10])
  • Formal methods—once considered too costly—are seeing a resurgence because only precise and verifiable instructions can govern AI actions at scale ([17:49], [18:09]).

3. Control, Identity, and Access: Rethinking Security Paradigms

• Changing Identity Concepts
  • AI agents’ identity is not fixed—memory, capabilities, and motivations can be swapped, complicating traditional access control ([27:04], [29:54]).
  • Existing models (RBAC, ABAC) assume identity as a fixed bundle, while AI agents can have attributes dynamically reassigned.
• Scale & Ephemeral Access
  • Traditional models break down at scale: companies often have more roles than employees, and AI only amplifies this exponential identity growth ([33:53]).
  • “We already have something that’s broken even for existing scale...and we’re all agreeing that we’re going to do 10x that in a year or two.” — Ev ([35:19])
• Moving from Identity-Based to Action-Based Access Control
  • Ev proposes that rather than connecting policy to identities, organizations should bind it to actions—a list that scales logarithmically, not exponentially ([38:32]).
  • “If you attach policy to actions...it’s a much more scalable concept.” — Ev ([38:33])

4. Practical Model: Ticket-Based, Ephemeral, Action-Centric Governance

• Tickets as the Foundation of Control
  • Each action (e.g., deployment) gets a digital ticket, which precisely enumerates all identities (humans, devices, agents) and their required privileges for that action ([41:57]–[43:01]).
  • Access is ephemeral: when the action is performed and the ticket is closed, permissions evaporate.
• Zero-Trust and Formal Verification
  • Combines ephemeral access with zero-trust principles and formal methods for verifying every step is correct, enforceable, and computer-verifiable ([43:45]).
  • “If you sprinkle it along the way with this formal verification step...you correctly pointed out is absolutely required to deal with fast and non-deterministic behavior.” — Ev ([43:56])

---

Notable Quotes & Memorable Moments

• On AI’s risk profile ([00:30]):
  “AI combines those two extremes. So...AI can make a mistake that is just as grave as the phishing attack mistake, but just as high-frequency algorithm, it can actually do it many, many, many, many times.”—Ev

• On why language matters ([13:10]):
  “We need something more precise than just human language that we interact with AI because we cannot bear the consequences of being misunderstood.”

• On formal methods returning ([18:09]):
  “If you want to give instructions to AI that you want to be...interpreted in just one way, not two, not three, no ambiguity, you have to communicate with AI essentially using mathematics.”

• On the inadequacy of existing access controls ([33:53]):
  “Pretty much every organization I looked at has more roles than they have employees...role-based access control is already broken at pretty much every sizable company.”

• On scaling policies by actions, not identities ([38:32]):
  “Instead of attaching policy to identities, attach it to actions instead...if you attach policy to actions...it’s a much more scalable concept.”

• On ephemeral, ticket-based access ([43:01]):
  “You create a ticket, and you assign all human or non-human identities, AI or not, agents, humans, laptops, databases...when I go do the deployment ... I close the ticket, it evaporates. The permissions evaporate, which means that if there is nothing for me to do, I have access to nothing.”

---

Important Timestamps

• AI’s magnified risk, need for urgency:
  [00:30]–[01:51], [24:35]–[25:58]
• Languages, programming, and the limits of English:
  [08:26]–[13:46]
• Formal methods re-emerging:
  [17:30]–[19:58]
• Identity redefined, access control’s shortcomings:
  [27:04]–[35:49]
• From ABAC to action-based policies:
  [36:00]–[39:35]
• Practical implementation: ephemeral access, tickets:
  [41:17]–[44:16]
• Executive summary & takeaways by Dr. Darren:
  [45:20]–[46:46]

---

Host’s Executive Takeaways ([45:20]):

• Governance must become action-based, not identity-based.
• Access should be temporary, contextual, and tightly bound to the work being performed.
• Precision (formal definitions and verifiable workflows) matters more than ever as systems act faster and more unpredictably.
• The competitive edge: not just more AI, but governable AI as a first-class force.

---

Flow & Tone

• Conversational but packed with incisive, practical insight.
• Vivid analogies (cars vs. horses, legalese vs. English, identity as memory/capabilities/motivation).
• Will appeal to architects, security leaders, and C-suite concerned about scaling AI safely.

---

Further Resources

• Ev’s company: Teleport
• Contact: [e-mail] or @conso on X/Twitter

---

This episode is a “must-listen” for anyone planning, governing, or deploying AI agents at scale—offering a paradigm shift towards formal, action-centric governance, and ephemeral, zero-trust access models as essential foundations for the AI-powered enterprise.

Transcript

[Dr. Darren]

Welcome to Embracing Digital Transformation. Before we dive in, I wanted to personally thank you for listening. Many of the ideas we discuss on this show inspired my new book, AI Augmented Teams. If you're looking for practical ways to combine human expertise and AI to achieve better outcomes, I think you'll find it valuable. Learn more at Paydar AI Books. That is P A I D A R AI Books. Now let's get started with the show.

[Ev]

AI combines those two extremes. So which means that AI can make a mistake that is just as grave as the phishing attack mistake, but just as high frequency algorithm, it can actually do it many, many, many, many times. Exactly. So which basically means that we have to stop thinking about, you know, like critical code path or not critical code path. We need to treat all software now with utmost kind of urgency.

[Dr. Darren]

Why this matters to you? AI is moving from a productivity tool to an operational actor inside enterprise systems. That changes the cost of mistakes, the pace of change, and the demands on governance. If your organization still relies on broad roles, static permissions and manual review, you may be underestimating how quickly AI can amplify both value and risk. The real challenge is not adopting AI, it is keeping control. As AI starts to act across your infrastructure, let's dig into what that means in practice. Welcome to Embracing Digital transformation. This is Dr. Darren on this episode, how to control AI agents with formal methods and ephemeral access with EV consovoi foreign.

[Podcast Host]

Welcome to the show.

[Ev]

Great to be here.

[Podcast Host]

Hey, I'm really looking forward to this. This is a big topic area. AI is changing everything, including infrastructure and agentic AI is even turning everyone's preconceived notions of what is AI into something completely different on infrastructure. So we got a lot to talk about today. But before we do, everyone knows that listens to my show that I only have superheroes on the show. So Ev, what's your background story? What's your superhero background story?

[Ev]

Well, my background story is that I'm a professional superhero, as you just said. But. But on a serious note, I am a computer programmer. I've been an engineer my whole life and. But an interesting thing too is that I love building products for other engineers. It's been my kind of passion my entire career. Like right after college I joined a company in Texas called National Instruments. Say the word instrument in the name, it means that I began my programming career building virtual instruments for other engineers and frankly, still loving it. It's hard for me to imagine building anything for non engineer because it's just easier to experience your own Product through someone else's eyes if you are that person, if you know what I mean. Right. So yeah, so like I'm building products for myself essentially or kind of different kind of version of myself, you know,

[Podcast Host]

that's how my career started too. I was, I was working in medical imaging and I have a background as a systems engineer or a system sysadmin. So it was always relegated to me to do the builds at night and then people go, hey Darren, I want to do this with the configuration management system. So I was building tools that all my other co workers were using to do work. Right. Their day to day work. And my career totally went that direction where I was building tools for software engineers to get their jobs done more effectively. So I feel exactly where you're coming from.

[Ev]

Yeah, in a way actually I would even say it's very lazy position because usually it takes time and effort to explain what you're doing to like a non engineer. And I just wasn't interested in that. If you build a new C compiler and you're showing it to a C programmers like here's a new compiler for you, like that person knows exactly what you built for them. So it's really nice.

[Podcast Host]

Yeah, yeah, no, I told, Yeah, I never thought of it as me being lazy, but it was totally me being lazy. Absolutely. I love that.

[Ev]

Okay, so both of us confessed.

[Podcast Host]

Yeah, we confess.

[Dr. Darren]

Right.

[Podcast Host]

All right, there we go. End of show, we're done.

[Ev]

All right, end recording.

[Podcast Host]

All right. But hey, no, on a serious note, how does that play into what we're talking about today, which is the infrastructure play for AI? I guess it plays the same way, right?

[Ev]

Yeah, absolutely. So, so there are like all these foundational labs and other organizations that build and train models or who use models in, in their production environments. But because it's a very different type of software and we can talk about the technology, but most people already, like, even I don't even think you need to be an engineer to understand. Just like if you follow the news a little bit that AI takes a heavy use of different type of hardware called GPUs as opposed to CPUs. So which means this is why Nvidia now is like the most valuable company in the world, that's the leading manufacturer of these GPUs and by the way, other hardware as well that is required to run AI. So the hardware is different. But also how do, like how does governance of computing changes? What I mean by that is like back in the day we invented a car and very quickly people realized It's a fantastic thing. But it's way more dangerous than a horse, right?

[Dr. Darren]

Yes.

[Ev]

Because if you like, if you drunk or if you're just a crazy person, you could just like go like 100 miles an hour into a crowd full of people. And so yeah, of course, you just cannot do that damage.

[Dr. Darren]

Yeah.

[Ev]

A horse have license plates, right? Yeah, yeah, yeah. So that we decided that because it's such a dangerous thing, but at the same time it's hugely beneficial. So we're gonna come up with the idea of license plates and to become a driver you need to pass an exam and you're gonna get a driver's license. So we've kind of adjusted our human systems to accommodate that technology. And the topic of safety here is an interesting one. I recently read somewhere a stat that if you lower a national speed limit by like five miles an hour, like every time you drop by five miles an hour, you're saving tens of thousands of lives. And yet we're keeping speed limits where they are simply because there is economic benefit. I think we would have to go through similar process of adjustment, reevaluation with regards to how we regulate computing. Because I actually believe that there's not. Generally speaking, I believe that all new software that will be created in the world is going to be AI software because there is no reason to have any other software. Right. So if software now is going through this kind of, it's turning from a horse into a car. Right. So which means that we need to update our human systems, how we regulate, how we manage, how we control and contain it. And that begins with some engineering work. So that is what I'm involved with. And yeah, so our customers are engineers as well. Engineers who are responsible for deploying and running AI workloads in data centers. They.

[Podcast Host]

So that's an interesting, that's an interesting thing. You said that software is going to completely change. It's all going to be AI driven software. I actually think there's still a huge new need for software architects or system architects, maybe they move up to system architects to still direct and guide AI. Cause right now AI just can't handle architecture very well. It handles code pretty well, but not architecture. It can't handle the trade off decisions that are typically made when you're doing big system architecture work.

[Ev]

It's a very interesting topic. Yeah, it's very easy to make a fool out of yourself trying to predict the future right now. I think very few brave people do. But the one thing that Musk says a lot that resonates with me simply because I've been kind of trying to do it in my spare time sometimes. Like if you ask yourself, why do we have programming languages?

[Podcast Host]

Oh, I already know the answer to that.

[Ev]

Right? Yeah. Like everyone kind of knows the answer. But it helps sometimes to remind ourselves out loud. We invented programming languages because computers couldn't understand English and because it was.

[Podcast Host]

Now computers can understand English, you see.

[Ev]

So you kind of one step ahead of me here. But there is another reason too. Because it was extremely tedious for us to speak computer language. We actually can. I can do it right now. 00011100.

[Podcast Host]

Yeah, yeah, yeah, yeah.

[Ev]

Really, really annoying. So we don't really have those limitations anymore. But we still have programming languages. And the way we use AI today is kind of interesting. That we speak English and then it converts English to a programming language. But programming language itself used to be the kind of old English that we used to communicate with computers.

[Podcast Host]

But it's not very.

[Ev]

Right.

[Podcast Host]

Yeah, exactly. In fact, one of my students at Vanderbilt is looking at moving into a PhD to actually evaluate that. Why, you know, is there an intermediate language that needs to be created that moves from English to machine code directly? Exactly. Do we need an intermediate language or not? And the, the answer to that is I'm not quite sure. The only reason we, we stick with intermediate languages today is because we don't fully trust the AI. We still want to see what machine, what we're telling the machine directly to do.

[Ev]

I'm very jealous of your student.

[Podcast Host]

Yeah, yeah, he's. He's going to have a blast.

[Ev]

Yeah, totally. I would even like. So if we were to compress what we just said, we need to ask ourselves which language we want to communicate with AI in. Is English always the best choice? That's the first question. And the second question, which language AI is going to use to tell computers what to do? Is it like, is Python or C the best language for it?

[Podcast Host]

Yeah, those are two.

[Ev]

Like, it's kind of two things in one. Like we need to determine which two different languages languages are going to be used for that use case. For those two use cases.

[Podcast Host]

Well, I actually think it's more than two.

[Ev]

What do you mean by that?

[Podcast Host]

Well, so what I mean, I think the language between AI and the computer or the machine, let's just call it the machine.

[Ev]

Right.

[Podcast Host]

I think that could be one language. But humans talking to AI, I think a lot of that will stick with the language on which you think in. So I, I speak multiple languages, I speak Portuguese, and I Speak English, Both of those. I speak pretty fluently. I know some other languages, like French and Spanish. I know those languages well enough where I can understand what's going on. I might not be able to converse, but I speak. But I think in English. That's the language that I think in. Now, if I'm. I. I think in Portuguese, if. If I'm living in a place that speaks Portuguese all the time. So I would want to get my thoughts down to AI in the language that I'm thinking in. That's what I. Yeah, go ahead.

[Ev]

So let me make an observation that we humans, we don't like human language. When we discuss something important, we don't use.

[Podcast Host]

Oh, it's hard.

[Dr. Darren]

Yeah.

[Ev]

No, we just don't do it like. So, for example, if you were to sell a house or acquire a company. So essentially, when it comes to something that really, really matters to us, suddenly we stop using English and we switch to legalese simply because English is imprecise. And I don't speak Portuguese. But I would imagine that the same problem there.

[Podcast Host]

Same problem, yeah. English is a horrible language.

[Ev]

Something really, really important. We suddenly get very unhappy with impreciseness and fuzziness of natural human language. And we started inventing things like legal. Like, look at the contract, it reads like English. But is it really.

[Podcast Host]

It's not really.

[Ev]

It's actually very similar to a computer program. I think a lot of people who are. Who kind of dabbled in both areas, they could draw the parallel between the language we use for all the contracts and agreements and programming. They're very, very similar. So I would argue that we need something more precise than just human language that we interact with AI because we cannot bear the consequences of being misunderstood. Right. You don't want to be misunderstood when you interact with AI.

[Podcast Host]

Yeah, I understand what you're saying. But at the same time, the reason why we have language that's so imprecise is because humans are imprecise.

[Ev]

But do you want your computing systems to be imprecise?

[Podcast Host]

Maybe I do.

[Ev]

So gradually shifting from technology to philosophy here.

[Podcast Host]

Well, a little bit, because the more I think about this, I use AI a lot for a lot of different things. One of the things I use it for is to take human language and to somehow understand that language to help me make decisions.

[Ev]

Right.

[Podcast Host]

And the human language that I have as the input to that is very imprecise. Right. And. But the results that I want coming out are helping me make a decision. I already kind of have it built in that the conditions are changing. So Quickly. That the decision I have to make is not necessarily a yes or no. It's a yes with risk or it's a no with risk. So I actually think that the large language models are thriving right now because they can handle an ambiguity.

[Ev]

Yeah, for that case, absolutely. But notice though that we kind of shifted the use case here because. Or maybe it's the design. But I still. I'm keeping the original question that we had in our heads.

[Podcast Host]

Yeah. Which was is there a better language? Right.

[Ev]

Yeah. How are we going? Like all new software is going to be AI software. And because software is a very generic concept, some of that software has to be incredibly precise. You know, there is this proverbial example of like autopilot on the plane. Like you want that thing to be precise.

[Podcast Host]

Correct.

[Ev]

Because the plane is flying at a very tight flight in the loop. So if it makes a mistake, you're going to stall and crash and all of that. But even like a basic example. So let's kind of bring it maybe down to my world. So if you are on kind of organization that makes software like a Google or Yahoo, any of these email providers, you obviously don't want your employees to have access to personal information of the customers. So essentially if you are head of Gmail at Google, you have to be able to say, hey, our employees must never have access to production data of our customers. So then you need to go and enforce that rule in your infrastructure. And this is where it becomes very, very difficult and complicated because infrastructure is enormous and there are many different doors and many different systems and that same data exists in many, many different forums in many, many different places. Now you need to have this precise mechanism of how you will actually enforce that. Very simple in English, it sounds very simple.

[Podcast Host]

It sounds simple in English, right? It does.

[Ev]

But it has to be translated into literally hundreds of thousands of very precise instructions for all kinds of role based access control systems. Because it's not like there is like one door through which every employee goes to get access to the data because data exists in databases and file systems and, and then there are backlogs. Yeah, yeah, yeah, yeah, yeah, yeah, yeah. So that's where you need that precision and at the same time you want that efficiency. So that's what I was kind of referring to when I was.

[Podcast Host]

Gotcha.

[Ev]

Now how we need to reformat the way we interact with infrastructure in order to accommodate all of this wonderful new possibilities that are coming.

[Podcast Host]

You know, this reminds me of in the 70s and 80s now, I wasn't working in the industry then. I was just a teenager, but when I did started working in the industries, I studied formal methods. Right, and this goes to formal methods is what you're talking about.

[Ev]

Absolutely.

[Podcast Host]

Which is really interesting that that's rearing its head again because we kind of exhausted that in the 80s. We said formal methods are great, but too costly.

[Ev]

Yes.

[Podcast Host]

And we kind of abandoned the languages like ADA was, was one of those languages. Right.

[Ev]

So you kind of bringing me basically directly to your conclusion that we made internally is that the future of programming is that you have to be interact like specifically if you want to give instructions to AI that you want to be con, you want these instructions to be interpreted in just one way, not two, not three, no ambiguity. You have communicate with AI essentially using mathematics. So that is a conclusion that our co founder, cto, his name is Sasha, that's what he believes in. So the language specifically for programming. So the future programmers, whatever the job will be called, will most likely like these people will have to rely on this formal methods to communicate to to machine what they need machine to do. But hold on, let me finish because there is another interesting component that you probably will appreciate as well. But then the second question, which language AI will use to interact with the machines? It's definitely not going to be general purpose programming language because no, no, it's not efficient.

[Podcast Host]

Right.

[Ev]

It has to be something that's formally verifiable, which kind of goes back to your kind of aha moment earlier. So then if AI can use a formally verifiable language, that then that gets converted to machine language, to machine instructions. That's the step where you can implement qa. So because if you're using a language that supports full formal verification, you then can use another machine to prove that these instructions, this code, is bug free. There are no vulnerabilities, it does exactly what you're supposed to do. So that is on a very, very kind of high level how we believe the kind of future of software creat is going to be.

[Podcast Host]

This is really fascinating because I never took it in that direction. I've always been thinking of it more on the fuzzy side. Right. But bringing formal methods back and injecting it in there, that can be really fascinating because I do have some cases where this is going to be extremely important, like repeatability, you know, data coming in, I get a repeatable output every single time. That's. Yes, that's important for control systems for sure. Like you mentioned the autopilot, but I'm also thinking autonomous vehicles, that would be extremely important. Any like spaceship control systems, even water treatment plants, right? Chemical, you know, chemical engineering systems, all these, these systems need those formal methods. Absolutely right. Because we want predictability in those cases. We want to say if this happens, we shut down the reactor. Right.

[Ev]

And this is what I meant, that all software will have to become AI software. It's just inevitable. So essentially you have to like all I'm saying is that now in the age of AI, any application, no matter how harmless it used to feel like in the past, is not becoming just as critical as on autopilot. Like I know it may be not intuitive on a high level when you hear it for the first time, but generally it comes. So if I were to step back, I would say like there is always cost of a mistake. So you might have a piece of code that's buggy. Okay, so you made a mistake as an engineer and now that code is running and that mistake might not manifest itself on day one. Maybe it's some, maybe you didn't handle time zones which properly in the running applications. So twice a year your application is going to malfunction. But also as humans, we make mistakes in our day to day basis when we interact with computing infrastructure. For example, like you could respond to a phishing email and someone will steal your password and then they're going to use that password to come back and pretend to be you and steal your company's data. That's also an accident, just different type of accident. So now if you look at these two different mistakes again, the first mistake is you built a piece of code that has a bug and you deployed it. And the second type of mistake, you are a victim of a phishing attack and your password got stolen. That's a different type of mistake. Both of them, they kind of sit on two opposite ends of a spectrum. In the first case, you have a really dumb application. The deterministic, it does exact same thing over and over again, over and over again. This is a bug. But that application is really fast. So if that mistake that you made in this case, it manifests itself twice a year when the time zone switch happens, right? But if you made a mistake in a high frequency trading algorithm, you could blow through billion dollars in a few seconds of your company's money. So that's the consequences of software being dumb, but also fast. So that's one end of the spectrum, right? But then the other end of the spectrum is where you make a mistake and someone steals your password. The consequences here are potentially much greater because someone can come in and basically get all of your data out of your data center, but it happens slowly because the second you click on that phishing email, it's not like you're going to lose all the data right away. The attackers, who are also human, they need time to actually get in. They need to infiltrate, they need to pivot, they need to orient themselves. So it's hours and hours and sometimes even days and weeks. But here's the change that's going to happen with AI that we have to respond to frequently, not frequently, very quickly. AI is both fast, fast and also non deterministic. So which means that AI combines those two extremes. So which means that AI can make a mistake that is just as grave as the phishing attack mistake, but just as high frequency algorithm, it can actually do it many, many times do it fast. Exactly. So which basically means that we have to stop thinking about like critical code path or not critical code path. We need to treat all software now with utmost kind of urgency. That we need to treat it as a kind of autopilot type software and protect it and govern it with much more scrutiny that we have ever done before.

[Podcast Host]

Yeah, I kind of, I agree with you, Ev, on this. This is really a major crossroads then in, in, in these systems. Because you're right, AI, it kind of, it magnifies its speed.

[Ev]

Yes.

[Podcast Host]

Which is, which is really kind of crazy. Right. And I, I actually talk about this in my book that I just released called AI Augmented Teams, where I talk about decisions in an organization are being made much faster and the failures are huge.

[Ev]

Yeah.

[Podcast Host]

Because, because it's non deterministic. I go back to that. It looks polished, it looks right. But did I cover all my bases and no one's checking because I'm moving so fast now that, you know, I'm not checking to see if all my assumptions were correct and my evidence was invalidated.

[Ev]

Yeah. Summarized. Yeah. Sounds like we're talking about these two things like fast, like speed and determinism. Those are kind of variables. And if you have something. So historically we had fast deterministic actors. That's traditional software. And then we had slow, non deterministic actors, that's humans. And now we're going to have actors.

[Podcast Host]

Then we have fast, non deterministic, non deterministic.

[Ev]

And none of our existing systems are geared to deal with that. So that is the mission that I'm on.

[Podcast Host]

Yeah, I understand that this is my question. Then there's one more variable I would say in there are a new dimension which is probabilistic because that's What AI is, they're probable probability models, not deterministic models. So that's major shift, right? Because with software, if I run this, the piece of software, the same every time. If I run the software, it runs the same every time. Right. It's deterministic. Right. But, but now I'm moving from deterministic not to just, just a, a crazy non deterministic. It's probabilistic non, non determinism, which is a weird, a weird thing, right, because there's a probability it'll get it right a certain percentage of the time. Does that make any sense, Ev?

[Ev]

Absolutely. I think that's basically. Yeah. So this is what. If you want to make it even crazier, I would also point your attention to the kind of definition of a word identity. And let's put cyber security aside for a second. I'm not talking about cyber security at all. So if you go back to like my original example that we went from horses to cars and we realized that the car is more dangerous, it needs to have a license plate. What is license plate? It's essentially an ID for a car.

[Podcast Host]

Yeah, yeah, an id.

[Ev]

So what is a driver's license? It's ID for you. So which means that the driver's license is attached to a car identity and your driver's license attached to your identity. But let me ask you, what is identity? Can we decompose it? And I think it's actually really, really important because I could make a proposition here. So I would say that your identity is combination of a, your memory, what you know, what you remember, all of your childhood memories, experiences, that's a big part of your identity. Second is your capabilities because I don't know, like a five year old there in versus 15 versus 50 at three. Very different, completely different. So which means that when I think about dealing with you, I will have a completely different protocol. Like a five year old person is just not dangerous, okay. Unless they have a gun or something.

[Podcast Host]

Which brings me to it can be dangerous.

[Ev]

That's a memory, then capabilities. And the final component of identity, I would say, and look, I'm not claiming to be right, it's just the way I think about it. And the final component I would say is motivation. Like what are you up to? What do you want to do? And you see historically all these things like horses, cars and humans, all three are bundled in the same physical object. So if you look at me and you say, oh, here is Ev, he's got his capabilities, his memory and his motivation. So I need to Treat ev in a certain way. Like I'm going to give him access to this room, but not access to that room. But what if you could swap my memory for someone else's? What if you can replace my motivations? You see where I'm going with this? I do, because with AI you can. So I would even argue that our traditional understanding of what we pack in the world of identity is now getting fuzzy. So if you have an agent in your organization, that agent is performing certain tasks, are you going to treat it as like, fast, like human? Right. But what if I swap motivation for that agent? What if I swap its capabilities again? I can give it more tools, I can swap its memory. So how, like, should we now attach identity to something else? So when we think about regulating, when we say it has access to that, but not this, what is it? Is it the agent itself? But if I can swap its memory and motivation, I can turn it into something completely else.

[Podcast Host]

It's different. Well, but I think you changed its identity then.

[Ev]

Exactly. But notice all of our existing customs, protocols and access control systems, they assume that those three things or three constants are bundled in one.

[Podcast Host]

Bundled, right? Yeah, but they're not. They can be pulled apart.

[Ev]

So what's the solution then? Are you going to have three identities? Shall we have like a memory that actually has its own unique identifier? And then if you give access to that memory to a new agent, you change identity of an agent?

[Podcast Host]

I would say you absolutely have to change the identity of an agent. I think to me your identity is built from those three. It's an aggregate. So if you change the identity of something or the motivation or its capabilities, you've changed its identity. But maybe we need another construct.

[Ev]

We don't really have systems that account for that though.

[Podcast Host]

No, we don't. We do have some systems that are starting to lean towards attribute, attribute, identity. So it's actually more, even more than three domain or three dimensions. It could be in number of dimensions. So now an entity, whatever it is, is now given access or authorization to perform certain things based off of its characteristics, its attributes, more than an individual identity or even a role that it plays. And in that case, now I've got more flexibility on identity, because now the identity is not tied to or the access. Right. Because when we talk about security and identity, we always throw in the three access, authorization and authentication.

[Ev]

Right.

[Podcast Host]

But what if I'm doing those based off of attributes of the entity instead of just off its id?

[Ev]

So we're getting now closer and closer to kind of what I do for a living. And this is where I think the concept of scale needs to be introduced. Because if you. I like. All of these conversations become interesting kind of thought exercises and it's almost fun to think about them. If you have kind of well defined situation like oh, you have an agent, you have a database with like a folder with files. Let's define how we're going to control access to that data for this particular agent. But things change rapidly when you actually look at like actual like a business, an organization or a government.

[Podcast Host]

Yeah, yeah, absolutely.

[Ev]

So now you have like things measured in thousands or maybe even millions and that actually changes a lot of things that make a lot of this thought experiments invalid if you don't account for scale, for example, in the access control theory. So we have these things like access control lists and role based access control and attribute based access control, which you were referring to earlier.

[Podcast Host]

Right, right.

[Ev]

And if you. I think most people actually familiar with a role based access control or basically

[Podcast Host]

that's the most popular one out there right now.

[Dr. Darren]

Yeah.

[Ev]

You don't have to be an engineer to understand like you join the company, like you show up for work, you have to log in through a single sign on system. It could be Microsoft Active Directory or like Okta, something like that. And based on who you are in organization, like if you're in marketing, you're given access to marketing systems. Right. If you're an engineer, you get access to things that only engineers need. So that's. Everyone intuitively understands that. But what everyone is shocked by when I share this story at a Christmas dinner or something is pretty much every organization I looked at has more roles than they have employees.

[Podcast Host]

Oh yes.

[Ev]

Why is that? Isn't that. That's not how it's supposed to be. Like we invented roles because we didn't want to configure every person's access individually. So that's the kind of unfortunate side effect of what scaling does for you. So because as organizations scale, they end up with these kind of silos of information. So they lose the single pane of glass so they can no longer reason about their security posture simply because of this enormous fragmentation. And that is where a lot of things again start. Like when you start transfer, begin transferring concepts from kind of theoretical to practical. This is where a lot of things stop working. So I'm actually saying that role based access control is already broken at pretty much every sizable company. And that's without AI. But what AI does, it drives the scale factor. Basically it's an order of magnitude increase. So in real world situations, when we meet with companies that have plans to deploy agents into production, the ratio that I'm frequently seeing is close to 1 to 10. So essentially we have this like team of thousand people. They do this like manual data entry jobs and we're going to replace them with 10,000 agents. And look, I know it sounds terrible that AI is replacing human jobs, but in reality, like these people have better things to do than just like typing in manually information to web form. Of course, yes. So now if we already have something that's broken even for existing scale, and we're all agreeing that we're going to do 10x that like in a year or two from now. Yeah, yeah. Some changes need to happen.

[Podcast Host]

Yeah, well, of course. So I think that's why people move to access or to attribute based access.

[Ev]

Yeah, that's why you remind me.

[Podcast Host]

Right. So what's beyond that? Because I'm guessing you're saying, well, even attribute based is not going to be able to cut it. So.

[Ev]

So let's zoom into attribute based. Like the reason why I'm a personally big fan of ABAC attribute based access control, simply because of its flexibility.

[Podcast Host]

Absolutely, yeah.

[Ev]

And so let me kind of make an observation. Like if you ask yourself, if you kind of visualize this, how many identities you have in your organization over time? So the obvious place to start is to count all the humans who work there. So we have a. Excuse me. So we have a company of 10 people. We have this like 10 identities. And these 10 people, they need 10 laptops. Laptops, they need identity too, because you want to track company owned laptop versus personal device. So like now we have 20. Okay, so then this company is going to build and run software on some servers and data centers. Like how many servers they need. Okay, like three servers for this like tiny company. And on these servers, so they need identities. Right, because they need to say you're a production and you're a staging and you're photo.

[Podcast Host]

Yeah, yeah, yeah, yeah, yeah.

[Ev]

So then you start adding software. It's like, oh, we're going to have a database running on the servers.

[Podcast Host]

It has identity as well.

[Ev]

So as you could see, identities. And then if you visualize that company growth in terms of revenue, how much money that company is generating, how much money they're making, and then you like do the number of identities over time versus revenue over time, you will see that identities are growing faster. Because they just compound. So you grow hardware, you grow software, you grow peopleware and they compound. So you, you you end up with a graph that looks almost like exponential in shape now. And today you are attaching your policy. Like who is allowed to do what? What identity has access to this information or that information. We attaching these policies to identities,

[Podcast Host]

which doesn't make sense.

[Ev]

The cost and overhead of like, that's why RBAC breaks. That's really fundamental reason. You are attaching a very, very expensive thing, which is policy enforcement, onto something that it grows exponentially over time. Meanwhile, your revenue is not growing exponentially. So which means that as you get bigger and bigger and bigger, there is going to be a reckoning moment. So I make a proposition here. Instead of attaching policy to identities, attach it to actions instead.

[Podcast Host]

Oh, I like that better.

[Ev]

If you make a list. Yeah, yeah. Because if you make a list of like a company of five employees, what do they do on a daily basis and you make a list of all the actions they perform, whatever is on that list, it's, I promise you it's not going to be very long. But then you bake a list for a company of 50 people or 500 and 5,000, and I would make a claim that the list is not going to grow as quickly. It's going to grow logarithmically because the companies, as they go bigger, they don't magically start doing more and more, they're doing more of the same.

[Podcast Host]

Yeah, yeah.

[Ev]

Which means that if you attach policy to actions as opposed to identities, it's going to be easier to manage. It's a much more scalable concept and you can do that using attributes. That's kind of why I'm connecting your attribute based access control suggestion. I think it's, that is the legit mechanism that allows us to escape these scaling challenges when we think about policy enforcement.

[Podcast Host]

Yeah, but you do, but you are tying it also to process or actions. Right. Because actions I could easily tie up into a process domain.

[Ev]

Right.

[Podcast Host]

Which means I have to really understand my organization. This is where, this is where I believe we need to go to. In order to really take advantage of AI in the future. We have to understand how our business operates. And so a lot of this tacit knowledge that's sitting out there we're going to have to capture in order to make, to truly become AI augmented. And that's the direction I like to head.

[Ev]

So are you sensing a loop in a conversation?

[Podcast Host]

Oh, absolutely, yeah.

[Ev]

Because I would, I would extend your suggestion almost a conclusion. To truly, truly understand your actions. What it means is that you have to make them formally verifiable.

[Podcast Host]

I agree. You do.

[Ev]

That's what you need. That's basically why we need completely different tools to interact with computers. By tools, I mean languages. Because all of your actions, they have to be determined. Like they have to be defined in a formally verifiable way, because there should be no ambiguity. Because if that's the case only then you have the hope of enforcing policy of how this action is going to be performed. If we were to maybe make it less theoretical and more practical. So here's the action that every company that builds software does on a regular basis, even daily basis, software deployment.

[Podcast Host]

Oh, yeah.

[Ev]

So you have to describe what your deployment actually is, that this data goes from here to there. Then we do like a database migration, then we do like a backup. Like whatever steps in the deployment, they have to be expressed in a way that is impossible to misinterpret. So now your deployment, let's say that you found a way to make your deployment formally verifiable. So then how do you start enforcing as a policy who or what is allowed to actually do deployments? So you begin by creating a digital artifact of that task. Let's call it a ticket. The nice thing is about, about that is that everyone already does that.

[Podcast Host]

Yeah, yeah, exactly.

[Ev]

Pretty much every company that, like, when they need to get something, there's a digital artifact, it's like, okay, let's call it like a ticket somewhere. So then you say, who's going to be responsible for executing this action? In other words, what identities are going to be involved? And it's really, really important. Again, to be very precise, you can't just say ev, you're responsible to do deployment. Okay, which laptop am I going to use? Am I going to use my laptop or someone else's laptop that has a virus or Trojan running on it? Oh, so basically it means that you have to assign identity of a laptop to that ticket as well, which means that Ev, the particular engineer using that particular laptop, can work on this ticket. But it doesn't end there. When I'm deploying, you also need to define identities within a data center that will be involved. I'm not going to manually, like, copy files. I'm going to use, I don't know, Jenkins, something like that. It's a system that people use for deployments. So you need to assign identity of Jenkins to that ticket because you don't want me to use some other tool.

[Podcast Host]

Right, right. Yeah, yeah, you want.

[Ev]

And also because Jenkins, because it's also an actor, it will also need permissions. It will Also need credentials. So then you essentially you create a ticket and you assign all human or non human identities, AI or not, agents, humans, laptops, databases. So you put all the tickets that can restrict. I would argue that you need to sprinkle privileges on top. What privileges do we all require to complete to execute this ticket? You attach privileges to that ticket. The nice thing about it is that when I go do the deployment and it's successful, I close the ticket, it evaporates, the permissions evaporate, which means that if there is nothing for me to do, I have access to nothing. That is a much more scalable way.

[Podcast Host]

Well, and also it's more zero trust. It's more zero trust.

[Ev]

Right, which is if you sprinkle it along the way with this formal verification step which you correctly pointed out is absolutely required to deal with fast and non deterministic behavior. So that I like now with discussing something similar to what I think future is going to look like.

[Podcast Host]

It's a fascinating future, Ev. I wish we could talk for hours and hours on this, but we're out of time. So Ev, if people want to learn more, if they want to find out more about what you're doing in this space, because I think you're right, we're headed in this direction. It'll be interesting to see how it all turns out. But if they want to find out more, how do they reach out to you?

[Ev]

So I run a company called Teleport, so go to goteleport.com that's our website and my personal email address. If you want to reach out to me directly, it's evoteleport.com or you can find me on X. My handle is conso. I don't tweet much, but I do get personal messages there.

[Podcast Host]

Awesome. Hey Ev, thanks for coming on the show. This was a great discussion. I had fun. I don't know if my audience is still listening or not, but I hope they had fun too.

[Ev]

If they're not listening, they missed out on a great conversation very much.

[Dr. Darren]

I agree.

[Podcast Host]

Thanks again, Ev.

[Ev]

Thank you.

[Dr. Darren]

Thank you Ev for the insightful interview. This is what I take away from this interview. The larger trend is that AI is collapsing the distance between software operations and decision making. Leaders can no longer assume that traditional access models, static roles or informal process knowledge will be enough once agents and automated systems begin to act at scale. The first lesson is that governance must become action based, not just identity based. The second is that access should be temporary, contextual and tightly bound to the work being performed. The third is that precision matters. Again, if a system can act quickly and unpredictably, then the organization needs formal definitions, verifiable workflows, and stronger controls before deployment, not after an incident. Executives should ask which of our business actions are truly defined well enough to automate which permissions exist longer than they should and where are we relying on human judgment to compensate for weak process design over the next several years? The winners will not be the companies that simply deploy more AI. They will be the ones that can govern AI as a first class operating force. That is the real shift. When speed and scale go up. Control has to become more precise, not less.

[Podcast Host]

Thanks for listening to Embracing Digital Transformation if you have enjoyed today's conversation, give us five stars on your favorite podcasting app or on YouTube. It really helps others discover the show. If you want to go deeper, join our exclusive [e-mail] embracingdigital where we share bonus content and you can always connect with other change makers like yourself. You can always find more [e-mail] until next time, keep embracing the Digital Transformation Transformation.