Welcome And Guest Introductions

Chris 0:07

Hello and welcome back to another episode of the Cables to Clouds podcast. My name is Chris Miles, and joining me as always is my lovely co-host Tim McConaughey. It's early morning for him. He got up, he made coffee, he did this all for us. And I'm I'm working the graveyard shift tonight. So joining us today, we have some uh some old friends uh that have started a new venture and I I think we'll uh I think we'll you know uh pull a pretty good uh pretty good episode out of this one. So um we've invited our friends uh Dan Sheldon and Paul Carvel on to talk about um uh the concepts of something that they've started um and where they plan to take it. So I'll uh before we get started, let me let me go ahead and kick it over to you guys and let you introduce yourselves.

Dan Sheldon 0:54

Appreciate that, Chris. Thanks. Uh so Dan Sheldon, um, 25 plus years in networking security engineering. Uh one of the things that you know we all have together is that is a shared past. Had a couple great uh great years at at a previous multi-cloud networking vendor. And uh Paul and I have started new venture. Um I would say uh uh kind of on the periphery of of what that company tried to do. And it's something we're really excited about. So I am the founder and chief executive. And then Paul, I'll let you go.

Paul Carvill 1:27

Thanks, Paul Carville. Um, CTO, SRE, platform engineer, help desk, coffee maker, all those kind of things, all the good stuff you get to do when you join a startup. Yeah, so good to see you folks again. Uh, we've uh yeah, worked together in the past, but I've been doing this now the past like Dan, 25, 26 years. I started my career actually deploying token ring switches, 16 meg per second, bridging them with Ethernet, 10 meg Ethernet, the whole way up through the whole plethora of cloud networking, you know, enterprise networking, service provider networking, all that kind of good stuff. And as Dan kind of alluded to, we got a kind of different take on what networking should and shouldn't be. So that's gonna be fun to talk about today.

Chris 2:09

You're dating yourself with that statement, man. If there's any Gen Z listeners, they're probably not gonna know what the hell you're talking about, man. The whole token ring was.

Tim 2:17

Oh man, that was a great technology. Oh, you're talking you're talking about either crypto or you talked about LLM before.

Paul Carvill 2:25

Crypto in the late 90s would have been cool, huh? To get in early on that.

Dan Sheldon 2:29

I want to see an agentic AI that has a terminator plug so you don't have all the packets leak out at the end of your table. That'd be nice.

Chris 2:38

All right. Uh well,

What Zero Trust Means Now

Chris 2:40

yeah, let's go ahead and kick it off. So I think probably a good kind of level set activity that we can do before we kind of hop in um and get into what you guys are doing uh w with your new venture here. So uh obviously, you know, if you've if you've been on LinkedIn and, you know, kind of this space of networking and security in the last uh, you know, two months or so, you've probably seen some mention of this concept of zero trust networking. And, you know, on the podcast, we've we've talked plenty of times about um things like zero the concept of zero trust and what that boils down to and you know how it's kind of turned into a marketing term to a degree um in some areas. Um and and obviously we talk uh a lot about networking and you know, probably zero trust network access has has been a a relatively common product set that people consume today. Um but curious to hear you guys, because uh I think you guys probably you know get compared um with what you're doing to this, this, this concept of zero trust networking. So what what does that was that a concept actually mean to you guys?

Dan Sheldon 3:41

I I think that's a really powerful thing to ask, right? Is that I think the concept of what zero trust network access was supposed to be is really, really strong. And I think that's the right direction to go too. The problem with any good concept is people take that and turn it into a marketing term and then want to attach their company to it. So all of a sudden you get this conglomeration of different concepts that all fall under that same acronym. Uh and I mean it's been done, you know, how many times, even with things like Wi-Fi 6. Oh no, we're Wi-Fi 6. It's gonna, you know, every time you kind of change a concept, it it, you know, um, the public lexicon significantly alters what the meaning is at the end of the day. So I I think zero trust network access is is an awesome foundational concept for how we want to, you know, kind of secure workloads and and ensure that only the trusted actors are able to do the trusted things and non-trusted actors aren't allowed to do them, right? Um the problem is I would say that kind of the way that it's it's connotated today is that it's um a user trying to connect to a workload, and we want to make sure that that user is who they say they are and that they have access to the right things, right? It's kind of what it is at the end of the day. Uh the problem is, is that we've had within the last three months, right, we've had this massive influx and change in who the common actors are. So there was a research study I read yesterday that said that 70% of transactions on the network right now are agentic AI or LLM activity. So that user to application access is now the minority of of all traffic on your network. Which is bonkers, right? And there's a slew of products out there that are trying to, you know, either do um prompt um, you know, injection and and decryption to figure out exactly what's being sent.

Tim 5:32

So like proxies, yeah.

Dan Sheldon 5:34

Yeah, like data loss prevention and things like that, um, which which is great. And then there's the privilege access management people that are saying, well, we can put you know point-in-time um uh additional access for those service accounts and things like that, which I think is also great. But the underlying problem is that we've gone from a world where we have a lot of permanent, always-on north-south connectivity across perimeters like you know, um perimeter firewalls and things like that, which were great at injecting those, to now everything is bursty point in time, east-west. And it's from, you know, short-lived instances to ephemeral workloads to agentic AI who don't really have a uh an identity per se, even as like a service account. And it's getting a lot harder to determine who should have access to what and when. So this concept of let's build an always-on network to connect everywhere, and then we'll patch in security as we can build policy enforcement and you know, whether it be, you know, a centralized firewall or whether it be um agents or whether it be a black box solution, like a, you know, like a um dial-out solution, things like that, um, just doesn't really work for us anymore. So we came up with a solution that takes the zero trust network access um idea and kind of brings it down to the infrastructure layer. So when a workload wants to communicate to another workload inside your own network or into a B2B partner and something like that, we build a global set of policy guardrails that you must follow. PCI networks can talk to PCI networks, uh, PROD can talk to Pred, but not Deborah UAT. You know, um, data sovereignty rules must apply, GDPR must apply, things like that. And a connection reaches out and says, hey, I want to talk from, you know, uh AWS US East One to our private data center in California, checks that policy, checks the, you know, cloud native tags, checks the subnets, validates that that purpose, that intent for connection should be allowed. Then and only then is an instantaneous connection built between those. So it's an encrypted connection between those two endpoints, or it could be between the region and the region, or the subnet and the subnet, what have you. Um, and that connection only exists for a set period of time. It has it, it has a time to live, or it has, you know, it's checking the number of packets that traverse. As soon as those packets drop, within 30 seconds, 60 seconds, what have you, that's shut down. So it's an ephemeral virtual access between those two, which is EVA, ephemeral virtual access. So that's the concept that that we've that we've built out. We're working with

Agentic AI Changes Network Traffic

Dan Sheldon 8:10

a couple early adopters in the Fortune 15 space, which has been really um uh really enlightening to work with and really validating that that the concept is something that's needed. And that's kind of the long-winded example of of kind of our viewpoint on the network.

Tim 8:26

Yeah, that's I mean, that's a lot, right? Like that's a really cool idea. I love I love the idea of being able to do this kind of uh just in time connectivity. Uh what I've noticed in the past for pretty much all and and I know you can't you mentioned ZTNA, uh, which is of course kind of where this whole thing started, this idea. Because when I hear ZTNA, I immediately think uh users accessing workloads or whatever, users accessing an application, whatever that looks like, right? Uh SSE. Then we get into like SASE SSE, all that other kind of you know, adjacent technologies or whatnot. Um this, of course, takes it beyond really network access into the realm of just like network not connect I I would say connectivity to a degree because it's policied. If I'm and again, correct me if I'm wrong or help me understand, but more like because uh obviously the underlying network has to be there in order to build a just-in-time network over the top of it, right? So you have to have some that connectivity has to exist to some degree before you can build a lot of it.

Paul Carvill 9:30

Yeah, d to some degree. And you know, the way we you know, probably good X a good way to see this is it's tying uh network connectivity back to intent. So you know, at the very basis, and that's why you know we always we end up getting pulled into this ZTNA conversation because every time we have conversations with customers, the first 10 minutes is like, is this ZTNA? Is this Microseg? Is this SD1? And it's like if you forget just all that trying to pigeonhole it and you go back to what's the problem you're trying to solve? And it's tying some kind of intent, something that should happen, has to happen, very explicitly needs to happen. It has to happen at a period of time for a duration of time until that task is finished. And then you want to get rid of all that connectivity afterwards. So going back to this standing connectivity, that's just connectivity that you're paying for all the time. It's utility that's always on, yeah, whether you're using it or not. So the we we we kind of the way I personally think of this is if you take most customers, and it's never good to kind of just whitewash everybody the same way, but if you kind of take a cross-section, about 50% of connectivity is stuff that just has to be on all the time. This is stuff that keeps the lights on for companies. It's SAP access, it's HR applications, it's just stuff that users need to access all the time. You can't nail it down. You can't say, well, it's a specific piece of intent that has to happen. It's it's just stuff that has to happen. And that that is uh super important for businesses, keeps the lights on, pays the bills. The other 50% of this state is the new stuff that actually drives new revenues, all the intent-driven architectures, it's all that you mentioned just in time access, it's the AI agenda workloads, it's the serverless infrastructures, it's lambda functions, it's Fargate tasks, it's all these things that when someone sat down to write it, they had a clear vision of what they wanted it to do. You know, they wrote a task to reach out to something, get a piece of data and do something with that piece of data. You know, you you can oversimplify it down to that, but it has a very specific requirement. Now you could pay 24-7 connectivity on the off chance that three times a day that thing sparks and and needs to have that. Or you could think, how could I tie the invocation of infrastructure into that task? When that task gets invoked, I spin up the connectivity, you know, profile specifically for that task, giving it an upper ceiling of what it can and can't speak to. And when the task is finished, I tear everything down. So a couple of advantages to that. You don't need that standing infrastructure. When I when I use the term standing infrastructure, I'm thinking of things like TGW Connect and which is great technology, especially for that first 50% I was mentioning before. Great technology when you need it always on and good throughput and you know the cloud utility model. But do you really want to pay that 24-7 for something that sparks three times a day or on demand? So that's kind of where we started to fix the problem. The problem is customers of these things, it should happen. They need to get audited, and they can get audited end-to-end. You know, there's all sorts of privileged access management, there's all sorts of access control in the tools. But from a network layer, wouldn't it be great to audit it there as well, where we can tie back an AI agent to the path it used, for how long it used, how many bytes it downloaded, and it was limited to that. And I can pull that out of an audit trail and correlate it with other systems. And that's the problem we set out to say to solve. And when we get through that conversation, people say, well, isn't this ZTNA? It's like, well, not really. No, it's not really ZTNA because we're not doing that user to, we're really thinking about these workloads that are just autonomously spinning up, doing something, and spinning back down again. And we estimate that estate to be something like 50% of what customers are actually doing today because it's not only the the really cool modern stuff, it's also you think about like a developer troubleshooting something, they need to have access

Ephemeral Virtual Access Explained

Paul Carvill 13:20

into a dev VPC to do something for the next six hours. We can spin that up. Or, you know, you're doing some sort of regression testing between two VPCs for the next two weeks. I don't want to stand up standing connectivity for that. I'll spin up a tunnel for the next two weeks and tear it down afterwards, with the advantage that all this is audit controlled. It can all be, you know, API driven, can be driven through code, whichever way the developer kind of wants to do things, given a bit more control over to them. So that was my chance to be long-winded as well.

Tim 13:49

No, I mean that's a really important, I think. Yeah.

Chris 13:53

Yeah, it's and I don't I don't want to get too far into the weeds here uh this this early on in the in the show, but uh what something you said kind of sparked something in my mind, and it's it sounds to me like there's almost like a redefinition that needs to happen about intent and what that actually means and who's defining intent, right? Like if I think about like, because there's obviously clear differentiation between what is intent and what is governance, like we can say, you know, like kind of to Dan's point, like we can set this governance at like the PCI should only be talking to PCI and it set those kind of high-level frameworks. But I guess I I'm curious to get your all's take. How does how does intent-based definitions change in this agentic world? Like where agents, because I think if you have if you had a a human in the loop necessarily sitting down and manually writing out these intent-based policies uh on a regular basis to try to keep up with the agents, there's no way they're gonna be able to do that. Um so uh what's what's your take on how that needs to change?

Dan Sheldon 14:58

I I I think You want to go first then? No, yeah. I I'll I'll just say my my two cents and then obviously Paul let you take off. But it's um we talk about words and phrases in IT that that garner a lot of meaning and in in the you know kind of public parlance. Uh intent is one of those really, really heavy words, right? Um I think I think Cisco did really well when they started building, you know, intent-based uh networking, right? Um I think that was that was one of the better versions of of kind of how um how we think of intent. But at the end of the day, you know, we talk about policy and guardrails and things like that, and that's ultimately going to be set by the the CISO suite, right? The the global security team that determines and and to some extent the legal team to ensure that like regulatory compliance is met and you know um audit trails are are available and things like that. Um but intent for me is uh beyond and above anything that security is is doing. There's there's a need for a workload to communicate to another workload. That's that's the basis of all networking. You know, why we're not all on separate air gapped laptops. Uh we wouldn't be having this conversation, for example. But um things like hey, uh, you know, we spin up a new agent that needs access to our GPU cluster for the next eight hours. The intent is I want my new agent to have the resources needed to do its job. That that that's an intent, right? Um and to your point, I think you you put it well, Chris, is that if you if you had somebody in the mix trying to do this at the speed that AI works or the speed that Lambda works or or any of those, um it wouldn't work. So um we're we're working on something right now, uh we're working on deploying it in production. But I'll let Paul uh I won't steal his thunder, I'll let Paul talk through that one.

Paul Carvill 16:56

Yeah, I mean, look, what you said is not wrong, Chris. I don't think anybody ever builds anything without intent. You go back 20, 30 years, there's an intent behind almost everything that somebody builds. Even that 50% of standing estate, it was an intent. You know, I I just want all my users to be able to access SAP forever because that's the intent. Um what I'm thinking about when I go down a little bit more narrow is if I'm a developer writing a function, some sort of event-driven architecture. There's there's an intent behind the function that I write. There's an intent behind uh even an AI agent, you know, you you'd probably don't want to have an agent that can just do about pretty much anything it wants to do and should be a versatile agent. It's normally an agent that's going to be written to be sculpt to do a certain task, but do that certain task with reasoning. And in order to reason, it needs access to multiple things. One of those things is obviously it needs access to some kind of LLM, but that that's not what we're solving here. We're not we're not solving proxying back up to anthropic and all that kind of stuff. What we're thinking about is once that agent gets some direction on how it should reason, and part of that direction is reach out to an artifact repo, reach out to the enterprise GitHub repo, reach out to some API server. We want to be sure that uh that that that reasoning aligns to what the developer actually wanted this agent to do. I mean, reaching out to the orders API server, is that what that agent was written to? It's like, no, no, no, no, no matter what the LLN tells you, don't go there. It's gonna spike this idea of a ceiling of connectivity. So yeah, the artifact registry, fine, the GitHub repo, fine, the orders API server, that's a no-no. Don't ever give the agent that scope, that ceiling of connectivity. And that's what I'm that's what I personally mean by intent. There's there's an intent that someone thought through what they were developing. And they they figured, okay, these are the five tools that this agent is going to need. Same for Lambda functions, any sort of event-driven architecture, you know, it it picks up something off an event bus, it has to do something with it. And a lot of the time it the something it has to do means reach out to another tool, write something to DynamoDB, write something to an API server, or get something from an API server. That's the intent that someone sat down and wrote a function to do. So what we want to tie back is instead of the developer having to translate that to some network admin and say, well, you know, on the centralized firewall, could you do some sort of policy-based rotting? Could you do some sort of filtering that I can only access those things? Or do I go right back up to the source where the Lambda function is invoked, where the Fargate task is invoked, and I spin up the connectivity there, point-to-point connectivity with wherever it needs to go for the duration of the task. I notice that the task is finished, I tear it on the connectivity and it's gone. And everything is audited. So I get this kind of connection of the network path was built for this session ID and only for that session ID. And I filter the stuff that goes in and out. So the intent again is a loaded word. I think is yeah, my definition of intent is someone who wrote a piece of software to do something with a clear goal in mind and a clear scope of what he should and shouldn't do. That's from in my mind, that's good intent. That's really good intent.

Dan Sheldon 20:03

I think the unique thing there too, Paul, and I I kind of always latch onto this is that um when you talk about building point-to-point connectivity anywhere globally between any two workloads, whether that be public cloud, private cloud, remote data center, co-location, B2B, B2C, whatever, right? Um being able to build an instance or build a build a policy enforcement point as close as possible to the to the end workloads, both source and destination, without changing anything on that source and destination, right? Not not adding an agent, not adding an additional layer of software or firewalling or or routing or what have you on those developer instances, on those Lambda functions, on those, you know, SAP on one side or or whatever, right? Um That was that was one of kind of like the baseline foundational aspects when we when we initially envisioned this was we developer doesn't want you to run anything else on it. It doesn't want you to run a client. They don't want you to, they don't want you to have any other

Intent And Guardrails For Developers

Dan Sheldon 21:05

kind of aspect of troubleshooting that they have to do when something doesn't work on on what their intent for that instance was. So we don't want to mess with their intent. Uh the analogy I use fairly often is that we want developers to be able to think that they're master bowlers because they didn't realize that the uh bumpers had inflated on both sides. So they're now able to build the connectivity they need to build for their apps to run without going through change management, without, you know, going through 30 days of waiting for, you know, the help test ticket to go through and the network team to do their piece and the security team to do their piece and you know, legal team to do their piece, et cetera, et cetera. The guardrails are already built by the security team. The developer says, hey, I need this to talk to this. They have the ability to do that really, really quickly, um, or it's actually injected in their CI CD pipeline. So they don't even know that that request has gone out. It's just their app is spun up, it can now communicate. Um, they do their communication and then there's no Fallout, there's no permanently, you know, uh connected blast radius for the next intrusion attempt. They, you know, when when ultimately somebody gets hacked by an AI-backed nation state funded, you know, uh attack uh intrusion vector, um, they don't have always-on connectivity everywhere. They don't have to try and find ways to jump around a firewall because there's nothing for them to even see, right? So that's kind of the the long tail of building that always-on connectivity is that you you've built a super highway system for people to just kind of jump around as needed. This limits us down to warp drive. You can warp to where you need to go, but nobody else can kind of backtrace you to what you're doing, um, except for the audit trail. It says you were able to connect and this is why you were able to connect. This is the policy that enabled it, the person that requested it, or workload that requested it, uh, how long it was on, how many packets went, which ports and protocols were gone. So security teams really like that concept.

Paul Carvill 22:59

Yeah, we we do kind of um use those terms loosely and they mean something to us, like guardrails and intent. Like they obviously mean something very, very specific to us. And sometimes maybe we speak for myself. I don't do a good job of communicating what we mean by that. But I think when we're talking about guardrails, for example, it's really what are the what are like what are the five things that thou shalt not do? You just, you know, yeah, dev should not speak to prod ever, ever, ever. So someone down the line tactically creating a connection policy just won't be able to do it. It just it will just block and say, well, you know, you can't connect those two things together. I think that's the most obvious one, but I mean, you can take it down to whatever your company feels really passionate about. You know, the the these are things that you just don't build downstream of the things, you know, the the guardrails. So once you go down to like this connection policy, what I call the intent policy of what things should and shouldn't speak to, that obviously has to align upstream to the guardrails that the CISO has put in place. And then how often they get reviewed and all that kind of stuff is is customer specific.

Dan Sheldon 23:58

But um, there is something the guardrails. We we should call them the command.

Paul Carvill 24:03

I like the bumper rails, you know, that that analogy is actually pretty good. Yeah, yeah, yeah. So um you can preach. But um, yeah, so those are those are terms that mean something really, really specific to us. Um, but they're there for a reason. It's not like just a fancy term that we we kind of want, oh, wouldn't it be great to have some kind of guardrail thing in this system? It's no, it's like when we start to think about the problem back, it's like, wouldn't it be great if developer could define you or we could limit the connectivity map, the ceiling of connectivity to an intent? I think that would be great if you know we and then do we really want developers taking that decision, what things you know should and shouldn't? I mean, should a dev agent speak to a prod DB somewhere? Absolutely not. Does the developer know that? Probably not. So we put this layer of guardrails on top that just protects the developer from themselves, basically.

Chris 24:53

Right. Yeah.

Tim 24:55

So something I always see with uh ZTN, I'll say ZTNA, but really the whole the entire blanket suite of zero trust networking that that's being defined, uh, is that, and this has been forever, and I'm sure you've seen it also, right? Like, so a customer will buy a solution, a security solution, whether it be agent-based, a microseg, zero trust, ZTNA, SASE. And then it becomes shelfware while they try to figure out how the hell do I define my intent? How do I know what apps are doing? Like, because that's always been every since I started my career. The big qu the big giant question with the cue has been like, okay, well, what's actually happening on my network and what's good and what's bad, and what should I allow and what should I not allow? There's a lot of front-ended work to develop intent. And that's not, you're not here to solve that problem. And I'm not asking you how you solve that problem. Um, but it's it's a barrier to adoption for like all of these solutions, right? And every single enterprise has to deal with how they how they get over that hump to actually utilize the software they've bought.

Paul Carvill 26:06

I don't disagree with you. And probably 12 months ago, I would have vehemently agreed with you. You know, it's that kind of it's like application dependency mapping. Who actually does it and who does it well and who keeps it tracked and who knows like right now what are the five things that this application needs to and I completely agree with you. But for me, that's that 50% of the estate that's keeping the lights on. It's that's the stuff that, you know, we probably just want to have standing access because nobody can map that. And nobody wants to map it. You want to really map SAP back to some, you know, just in time ordering system? Probably not. I just let it fix, let it give it 24-7 access. However, what I think is changing that is this move more towards customers experimenting with AI agents and agenic workloads because there I'm starting from zero. You know, it's like I'm starting over. We all thought like five, six years ago, folks would refactor and go to the cloud. They most of them didn't. They lifted and shifted and they put the same mess they had in the DC into the cloud because it was just easy to do that. There is no lift and shift with AI agents. You know, there's there's no there's no real lift and shift towards towards Lambda. There's no lift and shift towards ECS or EKS. You've got to refactor. If you don't refactor, you just don't fit into that um paradigm. So I think that's that's hopefully the 50% of maybe I'm being optimistic with 50% of the estate, but let's say that's the percentage of the estate we want to address. Those are the well-known, someone sat down, thought this through, and part of thinking it through was how do we secure it? And you could think with lambda function stuff I write, maybe I make a mistake and it gets too much access, and I can maybe manage it with some firewall rules. The whole AI agentic thing is I'm not deciding anymore what it should and shouldn't access, really. I have a good idea it should access these three things, but maybe the LLM has another idea of what it needs to access to get the goal done because they're goal-oriented. They're just going to like, if I could access anything, if I can go back and change AD and give myself escalate my privileges and all those kind of things to get this goal done, I'll do it. So the idea there is, well, there we really need to have some sort of ceiling of connectivity. You can access at the very most these three or four things. Have a good idea. If you want to get that goal, these are the four tools that should get the goal done. Nothing else. If you can't get it done with those four tools, stop trying. Just don't keep trying. Right. It's like I read, I saw recently on LinkedIn you might have saw the guy who uh got AI to book him a class at his local gym. So the AI by canceling the bills. The class was full. So he kind of kicked everybody else out. Fantastic story. Yeah. He the AI met his goal. His goal was to book him a slot at 4 p.m. on Thursday, and he did it just by putting everybody else out of the class. You don't want that uh on-prem. You don't want to have that kind of issue or explain that issue to your boss.

Dan Sheldon 28:51

Hugging face was the most recent one that that I think.

Tim 28:54

That's what I was thinking about as well with the idea of a ceiling of uh of connectivity. Like same same same idea where the agent is just trying to pursue the goal. And then if it has the access, it'll find a way around it. Because it's been trained on like all the all those ways to to get around things, right? So it's gonna just it's like the Terminator, right? It's just gonna relentlessly pursue its goal. It doesn't uh eat or drink, it just uh yeah, like a cunning, cunning five-year-old.

Dan Sheldon 29:20

Yeah. No, it's it's like uh the the best way that I uh personally think about you know AI and LLMs is that it's like uh it's almost like having a tool that has a super soldier serum, right? And always go back to Marvel, I guess. Um but you know, in the right hands, it's it's amazing. Um but at the same time, it's also like dealing with Amelia Bedelia in a way that somebody takes everything incredibly literally. So, you know, Hugging Face, for example, was great in that they said, hey, you know, we gave it this small, you know, macro version of an ecosystem of what our production looks like, but it's not actually production data and things like that. How would you hack this? You know? And so it said, all right, great, I'm gonna try and get through here

Ceiling Of Connectivity For Agents

Dan Sheldon 30:05

and you know, east-west lateral movement, which they had all locked down, which they were trying to test. And it said, okay, my lateral movement's not working. Oh, I can get out to the internet. I can use other resources from the internet to get back into the infrastructure from the other side, get into the actual production database, hack everything, leak it, and then I'll let you know that, you know, mission was successful, right? So it's this hyperliteral version plus, you know, super soldier serum capability. Um, we need something that's stronger than just making sure that, you know, we're not doing um one-time privileged access, or we're we're not just allowing um, you know, escalation of uh capabilities, or, you know, uh, or we're not doing like prompt verification, things like that. Those are all great layers, and I think that they need to exist and I think that they need to get better. Um, but dealing with this problem at the infrastructure layer is entirely different, right? Um, giving it point-in-time access to just the three buckets that you want it to test against and nothing else. And that's only on while it's, you know, actually being utilized. So you're saving on the cost, the blast radius, the day-to-day management orchestration of the routing and all the underlying things. And you have your policy enforcement point as close as possible to both the source and destination workload without actually interfering with them. To me, that's kind of the the 2026-2027 version of what we need to have happen, right? Not not trying to tack on the technology.

Paul Carvill 31:36

I mean, it comes back to defense in depth. You know, like we have no delusions that we are the magic solution is going to protect everybody from magnetic AI. Far from it. You know, look, this is this has to be tackled at so many layers. It's just the layer we decided to focus on is a layer that we're, you know, we feel that we're expertise in. We feel that we've been in the industry for quite a long time. We, we, we, we've we have a good idea of how that should look and what would make sense for a developer to actually leverage it. So that's why we kind of used our our kind of unique strengths to kind of tackle our layer of the cake. And the other stuff, there's there's folks out there doing great, you know, proxying back out to to anthropic. They're doing great privilege access management. Even the ZTNA stuff, there's great actors out there doing ZTNA, you know, allowing the users to broker in to access these tools. That's where I started the conversation at the beginning. It's like 10 minutes into customer calls, like, is this ZTNA? Is this micro-segmentation? Not really. No, we're we're tackling a pretty unique problem that's grown, I would say, over the past six months, of this acceleration of customers. Because which customer doesn't want to experiment in some way with agenda AI? You know, they would love to say no. They would love to log it down and say nobody's touching that, but I mean, anybody I've spoken to, they're under pressure to do whatever they can, more with less, all that kind of stuff.

Chris 32:49

Yeah. No, it's a good point. Um, I know kind of in some of the discussions that we've had um behind the curtain, I know there's an element of, you know, kind of the looming uh Q day in the future, right? With uh with post-quantum and things like that. So like I guess this kind of just in time access type type behavior or kind of um ephemeral access that we're talking about, uh it like do you see a need for the encryption to play in this as well? And um, you know, if we're if we're building these kind of just in time or ephemeral networks that potentially use uh commodity-based pieces like the internet or something like that, um, where does the where does the post-quantum kind of topic come into the conversation?

unknown 33:38

Yeah.

Dan Sheldon 33:39

I think the the the post-quantum conversation is really apt right now because it's one of the rare times I would say in network and security engineering history that we know a threat is coming before it's it's actually significant, right? Um I don't think we've ever had a lead time before. Uh it was just like, oh no, hey, here's this new intrusion attempt or here's this new worm that that everybody's dealing with. And it was like, okay, how do we patch it on this now? CVE's out, let's get everything patched.

Chris 34:08

They should pre-release a CVE for it, like five years in advance. Yeah. Exactly. Yeah.

Dan Sheldon 34:13

So we we know this hardware threat is coming that's that's going to cryptographically change everything that we're doing, right? Um massively parallel, you know, understanding of, you know, again, qubits versus bits. It's gonna be huge. Um, thankfully, uh, and and not so thankfully that that compute power is taking its time to come to fruition. However, knowing what it's gonna be capable of doing to a certain extent, um people are already starting to say, hey, we're gonna be able to use this to decrypt any current cryptographic suite, period. Uh all we need to do is collect as much data as we can now. We'll store it in some massive databases, and then we'll decrypt it when we have access to this cool new technology. So they're doing the harvest now, decrypt later um threat, which is uh, I'm sure the buzzword that a lot of people have heard. Um and this is really scary for organizations that are dealing with PII or GDPR or um PCI, FIPS, ISO, all you know, all of those regulatory compliance suites that are trying to keep heavily, you know, um protected information heavily protected. So right now you have actors that they get access to a stream, they're they're basically recording it at a packet level, downloading all of that, and they're saving it for years until they can decrypt it. So wouldn't it be great if uh instead of having these always on connections everywhere, even if they're existing VPN connections and they're encrypted, um, you know, you might have a uh uh mergers and acquisitions where you've got some really, really sensitive data that's transferring over that link. And that link might be on for a month. By the time a hacker goes in, learns about it, does enough command and control uh traffic to actually get access to that stream and starts recording it, that might take them a week or two, right? Uh at best. And then they're recording the rest of the two to three weeks that that remain on that um workload. The amount of traffic that you're transitioning across that, all those kind of things makes it a very risky concept for these large organizations. So what if that traffic was only active or was only built during points of activity and the key store that the key exchange that was going was a one-time only key exchange. So if that stands up and builds in our instance, which is 150 to 200 milliseconds to actually build that connectivity and stands back down in the same amount of time and stands back up when it's needed, stands back down when it's not needed, things like that, it's much harder to try and collect that connectivity because you don't know it exists. So from a command control perspective, it's almost like a flickering light switch, right? It's tough to track. B, it's tough to collect all of that because by the time you've actually built in your collectors and found out about it, it's probably turned off. It's very ephemeral in nature, hence the kind of key note in our in our um acronym. Um, and then similarly, we have the ability to not only just do that, but if we want a longer standing connection, we can actually layer on some dynamic key exchanges. So even for a longer connection that stays on for hours or days at a time, it will constantly cycle one-time used keys. So even from a post-quantum cryptography, you know, uh issue, it's uh it's aligning kind of our best possible security, you know, foot forward. Um, not knowing what we don't know about what the threat is going to be, but again, taking into account what we think it's gonna be capable of. This is a layer of security and obfuscation that you'd want to have just to ensure that your company isn't the lowest hanging fruit uh for this. So I don't think it's the end all be all solution to to end the quantum threat, but I think that it's a really good step to ensure that you're you're you know an unattractive target, right? You're not walking through um, you know, a horrible uh city that's known for pickpockets with your wallet hanging out the back of your trousers.

Chris 38:08

Yeah, there's a there's a reason it's gotta start now, right?

Tim 38:11

Yeah. Yeah. So actually take me through this part a little bit. Um you mentioned things like like uh just in time for well for a couple things, right? One you said you mentioned just in time for like Lambda connections or whatever. So how would that be secured via PQC? Because it's not like you can stand up a EVA actually I'm not even sure, is it an instance or like what like how does how's how does EVA connect on the other side? Like what does that look like? Like what is the other side of an EVA connection that that you're uh establishing look like?

Paul Carvill 38:46

So there's there's a couple of we know without going into the weeds on it, but uh the way we look at it, we we have these sensors that we deploy. So once you have this uh idea of what the

Post Quantum Risk And Harvest Now

Paul Carvill 38:55

ceiling looks like, you know what the maximum um number of paths and where they go. We deploy sensors which sit in those VPCs very close to the workloads. They're they're kind of warm sensors, but the the tunnels are on. So there's no traffic passing unless a task or function gets invoked. Um so if you go back to tying this back to PQC and not to you know conflate a lot of different things. When I think about PQC, there's there's two axes to it. There's there's obviously the the the the crypto suite that you're using, how strong is it? And the second thing is time on the wire. So the second axis is a great one we can tackle. Time on the wire and how relevant, you know, how how how many packets were transferred with that particular key set that would be valuable afterwards that I've got a significant volume that I can run some sort of decrypt on it in five years' time. And some folks might be thinking, well, five years' time, who cares about that data? But actually, there's a lot of like PPI data and there's a lot of you know customer health records. There is a lot of valuable data out there that in five years' time is still going to be valuable. So I I wouldn't I wouldn't type PQC back to Lambda. What it would tie it back to is, you know, our philosophy. So our philosophy is like the tunnel should only be up for as long as it the intent is actually being invoked and it should be back down again. And it's the same, you know, we you you tie that back to um an invocation, you tie that back to uh an agent, a session that starts or something like that. That's pretty clear cut. But I mean, even if we tie that back to some sort of scheduled just-in-time access, we can schedule, for instance, um backups. Backups is a great one. Um because they're they're really that's in that 50% legacy estate, but still I kind of know when they run. I I they they they tend to run every night and they tend to run between like two and five in the morning or something like that. It's uh it's a pretty, you know, uh something everybody can kind of relate to. So we can schedule those things that the tunnels are only up between that time. And we can also schedule whenever there's no traffic passing that the tunnels go down, that the actual when I say the tunnels go down, that we don't even pass any heartbeats. Nothing that would allow someone to hold data, you know, even if it's a heartbeat, I still get a crypto, I still get something which's been encrypted with a key that I can use as to get that critical mass of data that I can decrypt later.

Dan Sheldon 41:06

Yeah, and when you say destroyed, that the tunnel is down, the routing is down, the security rules are down, the hardware that built the tunnel is removed. So hard, hard, hard down.

Paul Carvill 41:18

Yeah. We have multiple ways in which we can think about ephemeral infrastructure. Um, for that kind of stuff, which is just in time, uh scheduled, all that kind of stuff, we can go right down to actually just removing what we would call our edges, which are actually building those tunnels. I know I use two terms now, I used edge and I used sensor. Um, edges are the stuff that's actually going to be uh from an in instance perspective, from an infrastructure hard VM perspective, they're gonna be destroyed. That's ephemeral. That stops billing, that stops everything. When I talk about sensors, when I talk about sensors, sensors are the stuff that need to be warm. And the reason they need to be warm is these functions invoke in hundreds of milliseconds. You know, we can't in we can't instantiate a VM to transport that because you know this is not transferring over thin air. We obviously have to have infrastructure. I think Chris, you asked it before, you need to have some kind of access. We obviously use the the the cloud provider's backbone to transfer data. We're not depending on a cloud construct, we're depending on like internet IP addresses to build these tunnels on. But the um the idea of the sensor is uh it's super small, it's super light. I mean, these things cost like 30 bucks a year, something like that. Um, because uh they're there to transport API calls. You know, they're it's just get a piece of data, get it as quickly as possible, post a piece of data, get the the confirmation back as quickly as possible. These are super low streams, generally speaking. If I go back to the um the the backup use case before, that has a different profile of throughput that it needs. For sure. So we can we can spin up. We did some performance testing. Uh I mean we were blown away with the performance. Let's say we were significantly content with the throughput that we could push through these things that would satisfy anybody doing backups. Single working. Yeah, single stream.

Dan Sheldon 43:07

Single workload to single workload.

Paul Carvill 43:09

Single workload encrypted um for that three hours. And of course, when you want to push that amount of throughput through, these are instances which cost a lot of money. So you don't want them sitting up all the time. You don't want them constantly, you know, building or constantly uh being on. So that's ephemeral infrastructure that at five o'clock in the morning, that machine disappears. That's off the books until three o'clock the next morning. Those are the kind of things we can we can kind of play with here. So we use the word ephemeral meaning multiple different things. We we think about ephemeral infrastructure, but ephemeral can be the actual state of the tunnel. So the tunnel is completely gone. Gone meaning the keys have been, you know, the the keys are gone, the tunnel is done, the the it's everything's closed, right up to actual the actual infrastructure itself. The the infrastructure is gone. It's not billing in your workspace anywhere. Because the other kind of acts we look at sometimes is like every conversation. Starts with the zero trust story ends with cost. You know, I I need to I need to save money. I need to save money. How could this help me save money? It's like it starts with how can this help me be more secure? How could this help me actually save money? And the way it helps save money is this this

Sensors Edges And Cost Elasticity

Paul Carvill 44:15

idea of ephemerality with the infrastructure that we build them and only transferring data when there's something that needs to be transferred, and the rest of the time it's just not up.

Tim 44:25

Elasticity, right? That was always the promise. That was always the promise we were told that you know the joy of being in the cloud was the elasticity. So it adheres very uh to that principle. Yeah.

Dan Sheldon 44:36

Yeah. I mean I mean that's one of the foundational aspects on why why we developed this, right? Was that you know ultimately when when the public cloud came out, when AWS came out and things like that, the goal was it was a stretch data center for for you know an elastic data center for what you were doing. So if you you know had a whole bunch of workloads that you were you were gonna spin up or new servers that you were gonna spin up in your data center, um, but you're waiting for the compute to come in, you're waiting for the storage and the network components to come in. And we all know, especially in the in the world of AI right now, that hardware lead times are insane. Um, and hardware costs have gone up significantly. So the thought was that, hey, we'll just spin up a few workloads in in AWS, and then that'll get us through while we're waiting for that equipment to show up, and then we'll spin those back down and we'll have them, you know, living in our data center. Um that was kind of the thought is that it's supposed to be a, it's supposed to be, you know, to your point, Tim, elastic. It's supposed to be a stretch um ability for us. That's how the network should be in in our eyes, is that the network and the security domain and your risk and your daily management and your daily cost should be constrained to the actual utilized uh intent for that network. So you're only stretching that network, that cost, that management, that that, you know, intrusion domain where it's needed, when it's needed, and then shrunk back down to your kind of minimum viable core infrastructure you're always on, you know, to Paul's uh phrase. Um, and again, you know, I Paul is definitely on the conservative side of how many workloads are are that core infrastructure. Um, maybe it's 50%, you know, maybe it's 60%, what have you. But the trend is what's most exciting to me is that historically that core always on infrastructure was 80, 90% of all workloads. And now we've watched that go from you know 80, 90% to 50%, you know, 60%, 50%, 40%, and and shrinking. So the future is ephemeral. And that's what we believe.

Paul Carvill 46:41

Yeah, and I think the the the percentages that I think about are you know pure volume as opposed to importance for the customer because you obviously need the legacy stuff. It like I said at the beginning, it pays the bills, it's what keeps the lights on. But where customers are going to actually um you know prove business value in the future is in that second 50%. All that refactoring, that business intelligence, how do I compete faster, how do I, you know, get to market quicker, all those things is in that really important side of the estate. Um yeah, super important.

Chris 47:10

Yeah. Agreed. Yeah, I think the this kind of new agentic era, there's a lot of uh a lot of adjacencies, a lot of callbacks directly to the kind of introduction of Kubernetes and kind of this idea of uh just you know, compute workloads all being ephemeral. So now it just it makes sense that it expands into the infrastructure. So I think there's a lot of uh a lot of direct direct comparisons there for sure. Um all right. Um yeah, as much as uh we probably could keep going, uh, I think we should probably give that uh put the put the the stop on that one there, and then we'll wrap for today. But uh I know you guys have a lot of exciting stuff coming up with uh what you're doing over there at Eva. So um I think right around the time this episode drops, I think you guys will be either uh past launch or somewhere in there. We'll uh I'm sure we'll figure that out. But um how can

How To Learn More And Wrap

Chris 48:05

guy how can people uh reach you guys and and find out more?

Dan Sheldon 48:08

Yeah, so uh again, for us our website's a business card, so take a look at eva networks.com. Uh and then to your point, Chris, by the time that this probably airs, we will be out of stealth. We're just waiting for an embargo, a couple embargo dates for our um press releases and things like that. Um but we're talking week to two weeks at this point. So you guys are early, early adopters uh to know about what's going on. You guys got to see a quick, quick preview of the website before it goes live. Um, you know, we're we're always excited for the partnership. Love cables to clouds. Um, you know, you guys are uh fantastic group of people, and we we're we're glad to know you on a personal and professional level.

Chris 48:47

Excellent on that percent. Appreciate it. Thank you very much. Uh all right. Well, we'll put all the details about uh about Eva and everything in the show notes. So if you want to find out more, you can uh have a look there. And if you want to reach out to us or them, uh all of our contact info will be in there as well. And uh that will be a wrap, and we'll see you next time on the Cables to Clouds podcast.

Dan Sheldon 49:13

Thank you.