Techstrong TV October 28, 2025

Hey folks, are we paying an AI tax without realizing you're watching Textron? Hey, folks, welcome to the latest text drawing gang edition. We have our, some of our usual lineup for Tuesday, JP Morgenthal, Steven fst, and Mitch Ashley.

Alan, of course, is out and licking his wounds from those pit star Steelers lost to the Packers. And well, you know, times are tough. Anyway, let's jump right in.

Apparently, memory prices for DRAM and all kinds of other memory are stirring the skyrocket because, well, all the chip fab people switched gears and started building higher end chips for ai, and now suddenly we have a shortage for all the stuff that we do every day, and it's getting much more expensive, and it looks like it will stay that way for quite a while. Mitch, what's your take on all of this? How do I handle this if I'm an IT person trying to figure out what my costs are gonna be, because well, suddenly we're all paying the freight for ai.

Well, you mentioned, uh, the Steelers in football, so this is like student body, left student body, right? You know, statue of Liberty play. What are we doing here?

We're, we're, we're chasing the AI chip football, if you will. So certainly that's what's happening. I mean, the manufacturers are going where they think the micro the market is going, where the demand is going.

And that definitely can create shortages on chips. Now, if you're a hardware manufacturer, you know, integrator, um, uh, doing your own, uh, doing your own assembly or creating your own products out of other people's chips, then you have a supply chain issue. If you're the manufacturer of these chips, then you also have, uh, where do you put your bets?

Where do you put your markers for the next three to six to 12 months? So it, it, it's a challenge, but it's not one we haven't seen before. You know, there've been shortages on hard, remember memory shortages because of tsunami in Japan.

I mean, there's all, there are situations where we run into this, we tend to survive 'em just fine. Mm-hmm. Jp, do you have any tricks to use for this?

I noticed that in this article some folks are double ordering, which can't really help the situation. 'cause now they're basically increasing demand artificially. Well, I mean, that was mentioned in the article that the, there's some oversubscribing going on, which forces a, uh, pressure on the market, looks like it's an artificial supply, uh, di you know, limit, right?

That it looks like the market is, isn't able to fully suppli the demand. It's, uh, and, uh, and so there, there's this, uh, vacuum and, and of course the manufacturers then go and, and produce to fill that. But what happens is that these, uh, the vendors that are, uh, oversubscribing are gonna store these in their warehouse.

And so now you end up basically with, uh, you know, the effect that all the all buying, all demand dries up after that because, um, they're, they, they have the stuff at the warehouse and the inventory. And so until that's consumed, it really affects the manufacturers in a bad way. Um, and it, it affects their ability to plan and in, you know, the delivery and manufacturing of these components in a very timely and consistent manner.

And, uh, it, it, it, but, but if you look at it from the perspective of a Adele or an Oracle or even a, a, you know, AWS, right? Who's pulling these, who re rely on these memory chips, right? They, um, well, I, I liken it to the way I treat toilet paper.

I, I'm one of these guys that need to go to Costco. I'll always have the backup toilet paper pack once I open that one. Next one's gotta be bought.

It's just, it's comfort, right? I am not going to see, I'm not gonna allow my manufacturing to be impacted, right? So, uh, it, it, it's not good for the manufacturers.

It, it, it presents an artificial, uh, demand, demand curve. And then, uh, it, it changes the whole dynamics of the market when that dries up. And on top of that, we have the, what if there's a hiccup in the AI market, and, uh, and people aren't using the services as much, and it's not being consumed at the rate that the, uh, LLM providers, the hyperscale of providers that are delivering that infrastructure, consuming at the rate that they believe that they will be, then what happens, right?

That they're just gonna, there's no return on these things. They're just gonna sit in inventory even longer. Mm-hmm.

Steven, do you think there might be a little price gouging going on Here? I dunno about price gouging. Um, everything I'm hearing is that the, uh, the margins are actually fairly slim.

Um, I, I would say that this is, uh, almost on an automatic, uh, effect of the supply and demand that happens in our industry that companies are gonna chase, uh, wherever demand is. And if, uh, you know, the, the, we know, we certainly see it with the big, uh, OEMs. We're seeing it with the chip makers.

No surprise that we would see it with the chip suppliers as well. If there is a lot of, if there are a lot of customers coming in with, uh, AI related orders, uh, they're gonna pivot toward in that direction. And frankly, uh, that unfortunately leaves the rest of the industry.

Uh, I don't wanna say high and dry, but a little bit off on the sidelines, because frankly, they're not as compelling. I, I do know that, um, I, I, I'm familiar with some folks who are working on various non-AI, uh, projects and they've had trouble getting orders filled for, um, you know, memory, uh, support ships and so on, because it's just hard to get a lot of these things right now because so much of the industry is focused on ai. But, you know, I don't really blame anybody for that.

I feel like, um, you know, that's where the orders are. I, I, I, I see that's where the, the suppliers are gonna go. I, I was watch, I, well, I was watching Micron from a stock perspective in the past three months.

'cause they actually just recently had an earnings announcement. And that was a big part of the, the Micron story, uh, among investors, is that there is gonna be this, uh, re as AI becomes more popular, there's gonna be a pressure on the market to require more and more physical memory in order to, uh, to support the, the needs of, uh, larger and larger models. And Micron stock, uh, shot up significantly over the past couple of months, I would say.

You know, I, I'm, I'm thinking it's close to a hundred points that, that, that move now it's reached the saturation point. So the market's kind of saying, okay, this is fair market value, 200 and some odd dollars for Micron stock right now. Right?

And, and it's actually down a little, but it hasn't jumped since I, I, it's just, it's just an a, a another indicator of where Wall Street sees what is fair market value based upon what's happening in the demand. Um, and just another point for us to kind of bring back into, you know, is this real, is, is the supply chain issue going to affect the market or not? Mm-hmm.

Steven, is there an opportunity for some other suppliers to jump into this? Or is it just take too long to kind of ramp up that kind of memory production? But, you know, yeah, maybe Intel's got something to do here.

Yeah, that's the challenge, right? Um, it's takes a huge amount of time, resources, and money, and with every, uh, advance in process node, it takes, um, more, I don't wanna say exponentially more because that's probably not mathematically correct, but it is, um, a significant multiplier more for every advanced process node, which it, it does increase the, the time, the money, the effort, uh, required to compete in these spaces. Um, but that being said, uh, the native, uh, Chinese, uh, chip making industry has been advancing rapidly, especially due to the fact that the, uh, US embargo makes their products more attractive to other, uh, domestic Chinese chip makers.

And so I suspect that there is increased capacity that can take up some of these orders if people will allow it, if they'll allow themselves to buy products that are, uh, manufactured, uh, solely, uh, within China as opposed to the standard global supply chain. You know, where Mike, we were just talking about the chips part of it too, and what, what Steven's hinting at is sort of the OEM and beyond, right? It's, there's a ripple effect of shortages in, in the supply.

Also, there's a ripple effect on sort of the Colette that happens at the end of this. And people are oversubscribing over buying or over ordering and actually don't need that amount. So there's a bit of a whiplash that goes with this until things settle out.

The bull whip, Mitch, speaking of that whiplash, right? So when I was a kid, I could always tell the state of the economy, 'cause I would notice that my father would start yelling at me about turning out the lights. The stock work equivalent of that is they start yelling at you to be more efficient with the CPUs and the processors, and suddenly they look at developers and say, stop being so wasteful.

So is that what we're gonna see? This too shall pass, just like your dad yelling at you about the lights. I mean, yeah.

Are you gonna student body left, tell all your developers write more efficient code? Probably not. I mean, yes, there may be some optimization if you really have some heavy duty applications that you have to just squeeze out a little bit better use of the memory.

But I doubt that's gonna affect a lot of people changing how they develop software. There will be more memory soon. Uh, so Steven, you, you, uh, track also the storage market and a big part of storage is moved towards, um, ram, uh, you know, versus physical disc, right?

Flash. Yeah. Yep.

So flash ram, right? Um, are they affected by this? Uh, are, are they the, I know they're different types of chips, but are they lumped in with the overall production of memory chips and, and, uh, for, for the flash round?

That, that's actually a really, uh, in insightful question, I think. Um, and, and yeah, the, the, there's nuance there, as you said in that, um, the production of SSD production of RAM and production of, um, sort of C-P-U-G-P-U do use different, uh, process, different processes. It's not like, uh, you know, Tuesday is flash day and Wednesday is RAM day.

That that's not how these things work at all. They're basically different factories. Um, but that being said, uh, I think whether it is RAM or flash or standard, you know, CPU kind of style chips, uh, they're all affected by this same pattern.

Um, certainly most of the storage companies are focused on delivering, uh, all flash arrays into the AI training market, just like all of the GPU and CPU and ram and everything is getting poured in there as well. So the answer is no, necessarily, but yes, in reality that storage is just as affected by this as the rest of the industry. Mm-hmm.

Steven, are there, I don't know, advances in memory technologies that you're looking forward to down the road that might help mitigate some of this? Or are we stuck? Um, anything that's gonna advance in memory technology is probably gonna get sucked up into the AI world.

And so I feel like, um, pretty much anything that's gonna happen is gonna get stuck. Um, you know, the good thing about memory is for a long time memory was able to be manufactured on sort of older repurposed, uh, processes. Uh, that's not the case as much anymore.

Um, and so I do worry that basically anything else that we invent is gonna get in the, into the same cycle. So from my perspective, I don't think so. Yeah, jp, does that mean that people are gonna be, you know, recycling memory out of their existing systems and kind of hoarding that and there'll be a whole secondary market?

Seems to be good. I, I think the, you know, there, I, from what I understand, there is a, been a major shift, uh, technologically in memory. So memory has speed, and I don't think that the newer equipment can use the lower speed memory.

So they really are on the hook to get more modern chips to support the, the, uh, the new physical, you know, uh, infrastructure that, that they're running. The, the, the RAM chips have to operate at a higher speed. Um, what do they call 'em?

V they're six and five and six, now they use DD RAM four, and now they're five and six, right? So you can't stick a a four in a machine that requires a a five or a six. It just won't operate.

It's too slow. You know, that, that's, there's another interesting angle to that though, jp. Um, again, thanks for, thanks for bringing that up.

Um, one of the coolest technologies out there that I've seen has been the arrival of CXL based memory expansion that uses older memory in newer systems. To Mike's point, it is possible to use older DDR memory in modern systems over the CXL bus. And this has, uh, been a, a really intriguing possibility.

Essentially, you could, um, kit bash the RAM out of your old last generation server, slap it into one of these CXL expansion, um, bays, and put that in your latest and greatest server, and have tiered memory. Uh, a lot of companies are working on that. You know, I haven't seen it happen in practice.

I haven't seen a lot of, um, a lot of, of, uh, people talking about it. But if you go to supercomputing or if you go to any of the other HPC shows, uh, there certainly is a lot of interest in that. And, and I wonder if, if maybe that might finally take hold.

Maybe. I think it will. And then, jp, let me ask you another question.

Will CFOs look at this and say, well, the price of PCs and servers and infrastructure and everything's gonna go up, so we're just gonna sweat the existing assets longer. And they'll say, you know, I don't wanna lay out that kind of cash, so we'll just make everybody kind of work with what they got as long as we can. Well, you know, there's always been a, in my opinion, a discrepancy between, um, the, uh, buyers and the technologists, right?

And in many cases, and not the derogatorily, but CIOs just really aren't technologists. They, uh, they tend to be more technology, uh, licensing, like they manage the use of technology within an organization versus truly understanding the nuances of memory. So what did it mean?

That means they gotta go to somebody in the organization for answer. And the answer of the engineering team is always more, better, faster, right? I, I, I, we need it, we need it, we need it.

Um, we've seen that on the software side, and we've seen it on the hardware side. And so you get to a point where if, if, you know, if the CFO is really questioning, uh, costs, I think they're gonna have to go to outside resources and bring them in to do an analysis in order to get a fair and accurate understanding of, of their spend versus relying on their people inside to tell them whether they need it or donated. Mitch, JP just said, your people are gluttons.

Can you confirm that More? More? Tell me more.

Give me more. Yes. Yes.

We, Hey, we're never gonna refuse it, right? Well, well, no, I mean, my experience comes from like the whole area where, you know, we went through with, uh, and we're still going through right now the distributed computing infrastructure, right? And rise of things like Kubernetes.

And, you know, uh, we had something years ago that was Cloud Foundry. It was phenomenal for 99% of organizations to build scalable apps, made it really easy, um, um, reduced the requirement overhead of, of the engineering team and have to have to, uh, bit twiddle in order to get things working. It was really very much equivalent to like, uh, the, the, the v the V block type architectures on the infrastructure side, right?

The, the rack mounted complete. You, you get your, your copper rack switch, your, uh, your compute and your storage all in one complete device. That was the equivalent of Cloud Foundry.

And then, but engineers decided, no, I want to go with this other thing that's cost more to operate, harder to operate, very fragile to operate, because that, that's better for my career, right? And who can argue with them? Who in the organization has the pushback to say, whoa, whoa, what's this costing me?

Because they don't look at the cost, they don't look at the costs of the organization long term. When they make these decisions, they do what's best for them. And typically over, over history, nobody's ever pushed back from the executive office to say, what's this gonna cost me long term?

Um, and that piece is still missing any organization in my opinion. And this, this isn't just another example of that, right? If you, you know, Thesys cloud, just cloud, cloud, okay, but which cloud can I go?

Is there a better cloud or should I, is everything just gonna be AWS 'cause you never got fired for, you know, buying IBM and now you don't get fired for buying AWS, right? Um, but is there, is is for what I do, digital ocean good, right? You know, those questions, they don't do the analyses.

Steven's gonna answer that question shortly, but I'm gonna give Steven one last question here, and then we'll wrap this up. Are we in danger or maybe we having a, I don't know, ration memory? I, I, I wouldn't worry about that as much as I would worry about.

Um, as JP said, what happens if there's a hiccup in this, uh, purchasing, uh, Congo line of, uh, basically anything that's being produced immediately gets sucked up into the AI machine. Um, you know, what if the technology changes slightly? What if somebody develops something that doesn't need quite as much memory?

What if it turns out that, um, you know, production AI applications can run on a different type of, uh, of compute? What if we don't end up keeping accelerating this mon, this machine, I almost said monster, um, that is, uh, eating up all of the world's production. Um, you know, one of the things that you learn after you've been in the semi world for a long time is that these things tend to have cycles.

And these cycles tend to be incredibly damaging. Um, because when the, uh, demand falls, and this happens more in ram and flash than it does in processing, because historically in processing, there's always been somebody who wants, you know, A-A-C-P-U made on the latest process nodes or whatever. But, um, in, in, in flash and in ram, historically, there's been cycles of boom and bust, and the bust cycles hurt, and they hurt a lot.

And if those bus cycle was to hit everything, well, that's probably gonna hurt the economy quite a lot. Well, and, and haven't we seen this already starting to happen where video is well deep seek, we've seen, take large models and produce them as quantized, and yet very effective. Uh, and now I believe open AI open sourced one of their mainstream models in a quantized version seven D it runs on, you know, 16 gigabits of, uh, of ram.

So we are seeing the, uh, effective and high quality inference engines being released, uh, on lower memory requirements. That is a, a clearly a basis for potential hiccup in this whole memory production scheme. All right, folks, I'm gonna leave in here.

But the cost of it is rising, at least in the short term, and you should plan accordingly. We'll be back in a minute. You've earned it.

The spotlight, the responsibility, the weight of teams, companies, and entire industries fall on your shoulders, lives depend on your decisions, your home life included that work. You are protected physically and digitally. Nothing gets through your team without a fight.

But in a globally connected world, everyone sees you, including those who mean to cause you and your organization harm. And now home your sanctuary attackers see an opportunity. Your digital front door is wide open.

And what compromises your home can breach your boardroom. Because the devil's greatest trick isn't targeting your workplace firewall. It's convincing you that your personal life isn't at risk.

Black cloak, digital executive protection, defending the new attack surface your personal life. Hey, folks, we're back and we're gonna have a little chat about the cloud because Steven and his crew at the tech field day had a, an event around the cloud last week. And I, I just wanna put to bed a rumor, though.

So the whole AWS outage, Steven had nothing to do with it. He did not deliberately make that outage happen, just to have a lot of people pay more attention to his tech field day. I know that rumor's going around, but Steven, walk us through what you guys were talking about, and it was very timely.

Well, you know, I'm a believer that you should deny, deny, deny everything, and, um, try to promote your own worldview as an alternative. So, no, we had nothing to do with the A AWS outage promised, I promise it. Um, uh, it was actually Tom Hollingsworth that caused the AWS outage.

Don't tell anyone. Yeah. So this was Cloud Field Day.

And, you know, we have a joke going on inside the Tech Field Day organization, um, that, uh, every event is actually just, you add AI in front of the name. So you got networking, field day, ai, networking, field day, security field day, ai, security Field day, um, you know, infrastructure. We did actually rename it AI infrastructure and frankly, cloud field, a AI cloud field, a well happily, wasn't all about ai.

Um, a lot of the conversation did have to do with, remember the, um, the olden days when we talked about running applications that were, you know, sort of standard deterministic webscale applications that did things instead of, you know, AI models. Well, there's still a lot of that happening. I know it comes as a surprise to folks, but that's actually where all the revenue in the industry is as well.

Uh, so there are a lot of companies that are working on building better cloud infrastructure. And from Cloud Field Day, um, we did get a couple of key takeaways. Alistair Cook, who led that event for the tech Field Day crew, uh, says that basically his big three takeaways, number one was keep your data close and keep your cloud closer.

In other words, companies are very much looking at, uh, bringing data, bringing cloud infrastructure, bringing cloud platforms back into the fold, trying to make sure that even if they are, uh, outsourced, even if they are as a service, that it's treated as, you know, their own infrastructure. Uh, the second thing that he noticed, uh, from a lot of the presentations was talking about, uh, how scale can change risks. In other words, if you, it's easy to take a risk, uh, at, at small, uh, at a small scale with a small application.

But when you're bidding the whole company on something, you really wanna make sure that those risks are going to be, uh, met with the proper level of management. And number three, that there is constant innovation happening, and that is causing new areas of exposure. Specifically, there was a lot of talk, I'm sorry, I know ai, there was a lot of talk about the impact of ai, and specifically the impact of what's called model context protocol, MCP, which is the standard way to expose, uh, services, to expose tools to agents, AI agents that are running out there.

Now, I will say that I feel like MCP could actually be extremely useful beyond the world of AI agents, because it's a standard specification for services, for capabilities, for data, and a standard way for these things to plug in together. So I actually think that it's not all gonna be ai, but that being said, um, it, it does, uh, open the door to new areas of exposure. Because if you're, if you're saying, Hey, you know, agents, you know, here's some corporate data, here's the things we can do, here's the services we can provide, um, who's to say that those AI agents aren't gonna do something unexpected with that?

So these three takeaways, uh, I think are really insightful. And it's the kind of thing that happens, frankly, behind the scenes. Uh, at field day when the cameras are off and the companies aren't presenting.

Uh, there's a lot of brainstorming that happens. What does all this mean? What does it mean for the industry and what does it mean for us?

And I think we can all see that, uh, well, there, there's a lot of change coming, even outside the AI space. Mm-hmm. Jp, what is the current state of the cloud in your mind?

Because I'm having a hard time figuring out where it begins and ends. It used to be like it was in the cloud, was on these other data centers, managed services, hosting, wherever. Now it seems like just about everything we refer to now is managed as a cloud.

So everything's a cloud. Is there a cloud or is it just kind of the new style of computing? And that's what we do.

It, it is a very much a, become a style. The term encompasses style of computing, in my opinion. I think that's a, an accurate statement.

I, I also believe that, uh, the, you know, there, the cloud indicates more of a opex versus CapEx approach to, uh, computing, uh, the, uh, the ability, the pay for what you consume versus, um, long-term, uh, depreciated assets on your books. Uh, you know, these are all indicative of cloud. Now, can you really do that?

If it's your stuff? Are you, and you're running it as a shared service for your organization? No, you're a shared service.

You're still an IT organization. You're, you can run it in the style of cloud, but you're not a cloud. And then we have this other term that I, I don't know when it was introduced, and it caught me off guard the first time I heard it hyperscaler.

And that is the term that they now use for Amazon and Google and Microsoft. They're hyperscalers. We used to call them the cloud, remember?

And now we talk, call them hyperscale is, and I think the reason why was exactly the point you made, is to differentiate style of cloud from actual cloud service provider. Mm-hmm. Steven, was anybody talking about repatriation and workloads in the cloud and know what to run where, and, and why?

Um, absolutely. And that is one of those things where people are increasingly concerned, uh, that there's exposure, frankly, uh, if they're not, uh, careful about what data that they place outside the data center. You know, it's funny, it, this is a, a story that we've been hearing for a long, long time.

I mean, those of us who've been in it for a long time, been following the cloud for a long time, uh, you know, this sounds very, very familiar, but, you know, I think that people are really facing this challenge, especially now that there are so many compelling on-prem, uh, cloud capabilities. Um, you know, one of the companies that presented at Field Day, for example, uh, was, uh, oxide, which is always a crowd favorite because they make a big honk in private cloud software and hardware that you can set up inside your own, um, premises and own and, and literally have your own, not just, um, scalable platform, but really hyperscale platform with all the bells and whistles and all the services that that implies. When do you use that?

What do you use that for? And that is, I think, one of the key questions that people are facing. And, and similarly, you know, we heard a lot of the same kind of con conversation from, uh, pure Storage, which offers storage from on-prem as well as native cloud storage.

And their customers are asking the same question, do I want this out there? Do I want this in here? And, and ultimately, you know, I think that what happens is there's a lot of conservatism in it, and a lot of people saying, you know what?

I'm a little nervous. I'm a little nervous that maybe I will be a small fish in a big pond if my stuff is running in one of the hyperscalers. Uh, I'm a little nervous, uh, that there could be an outage caused by, oh, I don't know, let's say DNS that causes the me to, you know, my whole infrastructure to fall over.

Uh, maybe it's better if I have some of this stuff on-prem. And, um, you know, and then of course, there's the AI factor. You know, if, uh, if companies are looking to spend a ton of money on AI infrastructure and new AI applications, maybe they're gonna think about, you know, repatriating to save costs, not because they want to in intrinsically save costs, but because they wanna reallocate budget.

And in that case, they may be indeed looking to bring stuff on prem rather than continuing to run it on these, um, you know, blue chip clouds. Minch. What should developers be thinking about here?

Because, um, a lot of times they write stuff and they get pretty deep into the weeds of an API, and then we can do what Steven just said, and we wanna do. I think there's a couple of factors to consider. One is, if you look at the data of what the mix of cloud on-prem and hybrid, it's about 46% of what organizations say they run is in the cloud.

22% or so is, is on, on, on-prem, and in a mix of hybrid across that. So a lot of times applications can live in one oth, one environment or the other. And though we are trying to make the private data center look like a cloud just for efficiency, and same, same standard operating procedures that we use in the cloud, we're not quite there yet.

So I think it's all about where you deploy it, where you're planning on, uh, putting it, if you're going to be putting it in the cloud, then how closely do you align with the services that are available in that particular cloud? Or do you run your own database? So do you use Dynamo DB or some of the, so services tied to the provider, or do you say, no, we're an Oracle shop, so we're gonna put an instance of Oracle up there, or maybe we're running some other database that we'll, we'll manage.

So it, it kind of has layers sort of like this onion of, yes, it's location's one part of the decision, but oftentimes it's what you're gonna be running will drive where you're gonna put this as well as availability and, and the access for your end users and customers. Jp, how much of this is now just driven by, where's the data in the first place? Uh, it's a good question.

Uh, data gravity is a real issue. Uh, you know, I think it is, uh, a big part of how the, how people are thinking architecturally about what services to consume and not to consume. Uh, and also, you know, where do I wanna consume those services?

I, I think that that plays a, a cons, a considerable role. However, um, seemingly less and less, uh, I see a lot of redundancy. I see people being less concerned, uh, about data, uh, being or or com parts of their data sets being moved to where processing is, uh, is, is happening, right?

So especially around ai, sorry to say, but it's true. Um, there is a, a lot of, uh, people or businesses that are now, um, starting to leverage data, uh, lakes, data lakes, uh, things like Databricks and Snowflake and things like that, that have, uh, built in, uh, AI capabilities and, and functionality, and they're not moving all their data there. They're moving a subset of data there relative to the analytics that they wanna perform.

Um, so, you know, I think those are two key indicators or or t key, uh, metrics that need to be evaluated as to where, you know, where do you wanna run this? And, uh, you know, and what do you need there? Just wanna jump in a little bit too.

There's just kinda back up. What you're saying is that we, our data shows that it's a big influence of where the data is located. It's not the only thing, but, um, you know, some of our data shows that organizations say half of them say that most of our data's on-prem versus what's in the cloud.

So I think it's gonna make a big difference. What's, what is located where, from the data standpoint, just, just as it is, which services that you're going to use. And some for some people, you can't put that data in the cloud.

So that really dictates where things are run. Well, it, so you raise this really, I mean, this is an architecture that I've now dealt with with a few different clients. And I, it's really interesting because we had the conversation, I've had the conversation with my clients small language model deployed locally or a large language model, uh, up in the cloud.

And, you know, a big part of using the large language model is that they have to provide the data in some way, shape or form to the LLM. And that need that could be done as, you know, uh, a, a, a tool, you know, like something like MCP or you can provide it as part of the prompt, but regardless of how you look at it, data is moving to the l to the, to the LLM in order to do that processing, right? And they like the idea of keeping it on-prem and taking advantage of local network speeds in order to, you know, but then they're like, well, then I need people who are skilled at, uh, managing, deploying, and operating this small language model in my, in my organization.

And that's not a skill that you can just go out there and readily find on the market right now. Yeah, that's actually interesting because that's the where, uh, HPE came in with, uh, at Cloud Field Day. They brought in kaza as a partner who we've talked about here on the gang in the past.

And, and it's exactly that same question, jp, that, you know, these, these, these companies realize that, um, many enterprises need help in how to run AI applications, where to run ai, AI applications. They want something that is more of a platform, uh, you know, more of a, I don't know, VMware for AI than what they've been able to have previously. And frankly, that's where companies like, you know, this partnership with HPE and ZA are, are coming in, I think, to help to answer that question and to make these things a little bit more practical.

And then on the, on the security side as well, we also saw Fortinet coming in there. Um, we've talked a little bit here about, uh, prompt engineering and, uh, jailbreaking AI and so on. Well, Fortinet is trying to attack that as well.

Uh, they're trying to figure out how to, uh, remember spy versus Spy in MAD Magazine. Well, they're, it's AI versus AI now. And, um, and they're very much, uh, cognizant of the fact that their primary competitor in the security space is no longer, um, the proverbial hacker, but an LLM.

Mm-hmm. Well, I find the whole thing ironic. I think when we were all much younger, the mantra was always bring the compute to the data.

And then we spent 10 years moving all the data into the cloud, and now we wanna process and analyze data at the point where it's being created and consumed, and now we're processing more at the edge. And hey, guess what? We're back to on premise.

So I think maybe we're gonna land in the middle somewhere, finally, but it's kind of just kind of silly to watch. And it's a joy to be in this industry. We'll be back in a minute.

Discover Techron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us.

You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients. Let's revolutionize your tech journey.

Contact us today and tell your story to the world in the most powerful way with Textron Group. Hey, folks, we're back in. Well, sometimes truth is stranger than fiction.

And if you've been watching this whole or following the NBA scandal, it comes in two flavors. One is, uh, feels like traditional shaving points kind of thing. And the other one involved having players entice high stake gamblers to games that were offsite, that were rigged because somebody was using technology to, um, maybe use X-rays to see what carts players had or, and all kinds of fun stuff was going on.

But jp um, I was kind of impressed with the technological prowess that went into this whole thing. What's your take? I found the entire, um, scenario extremely, uh, interesting from so many, many factors.

One, um, I I think the most interesting is the article mentioned the Cosa Nostra. I, I mean, in all honesty, I I have heard them come up anywhere in years. I, I, exactly.

I, I actually thought the Russian mob took care of all of them. I thought they were rubbed out. Russian mob owned everything.

So the fact that they're still out there, uh, playing in their old tricks and I, and making headway, it's great. I mean, uh, Lord knows I'm, I'm re actually rewatching the Sopranos right now, right? It's funny pumping down schemes and, you know, uh, rigged machines that this is, this is, this is old school.

Um, and yet new school, so it's old school, meet new meets new school, right? Uh, I, I, I think it's, I mean, we, we laugh because we're not the victims. I think what they did was awful.

I mean, just, first of all, I, I, I, I do go, you know, I, when I'm in Vegas, I'll go to the casino and when I'm on a ship, I'll go to the casino. And I don't like those shuffler. I have never trusted them.

And I know that they claim, you know, the legitimate ones that, hey, we had the machines checked out. But the truth of the matter is, every one of those machines, whether used for I improper purposes or not, has the ability to read every card in that shuffler and know where it is, and knows where it will end up on the table. Um, and that, that's why they have those little panels off to the left, and everybody gets registered, um, because there's a computer that's computing every outcome.

Now, you know, a legitimate casino hopefully isn't using that information to hinder or change in outcome. But, you know, when Royal Flush comes up, they know immediately. Yep.

You know, they know who had it. You know, they play their games, they do their camera stuff, every, show me all the cards that there's no hokey put, guess what? You, they, that's just, that's I eye candy.

They knew, they knew before that hand was even finished, that who had the royal flush. Um, because that ca that shuffler is feeding the data, okay? And so turn somebody turning it on.

And then you, if you watch poker tournaments, right? These in these cameras that tell, you know that no, they need those, right? That's how they do the TV presentation.

They can show everybody's hand and what their down card is relative to what the, you know, playing the community, right? So these, these, this, this is technology that's been in use for a while, they, but to employ it without letting, you know, without anyone knowing. Um, but I think the bigger part of it is that, uh, under the hood is still this, uh, uh, subtle, you know, um, Paul Newman and Robert Redford sting operation where, you know, like, oh, you know, playing with the chips, you know, okay.

And, and sending signals to one another by, uh, you know, physical si, you know, physical a attributes. Uh, I, I, the mix of it all is just bewildering. Um, but it's awful.

I mean, it, it's, it's, it's, it's a fundamental breach of trust at the worst levels. And to see that people in the NBA were involved in this. I mean, for years there's been big money games in big cities and sports players and actors, and they love to get involved.

Ben Affleck is known actor who plays in and does this. And, you know, uh, I, there were a couple of well-known baseball players who've been about legit games, so to speak. Um, no rake, right?

We learned that from Molly's game. If you don't take a rake, it's not illegal. It's just a bunch of people having fun.

It's when the house takes a rake without it being legitimate, uh, casino, that, that's illegal. And the person who's taken the rake is the one who's breaking the law. So as a player, you, you know, you did nothing wrong.

Very, very interesting. So many attributes should be a movie, you know, I definitely would love to see the, uh, ocean's 14 or 22, you know, this is, this is, this is how they play. But yeah, it's, uh, they, it's not ai.

So very interesting, right? The next, the next version of this will be, you know, AI determining, you know, how to read the cards. Oh, we forgot about the glasses with the mark cards.

That's another, that was another grand scheme, right? Somebody actually, you know, that's another thing you think about in the casino. They're always opening new decks and the decks are coming right from the manufacturer, right?

These guys are using mark decks. So really, really, uh, e everything old school meets new school. Uh, I think it makes for a great script.

Somebody's probably out there writing it. Yeah. Hopefully Michael Lewis is writing the next book about this thing, right?

Like the Moneyball guy. Um, I would really like to read that, that novel. Um, but you're, you know, you're right, jp, the thing that kills me about this story is that it is, it is the same as it ever was.

And high tech, you know what I mean? We've got in the same sentence, we've got the Cosa Nostra and marked cards and private gambling cheats and, uh, USB Dongles and Raspberry Pie and, um, you know, apps, you know, smartphone apps and everything. It's wild what's going on here.

But, um, you know, I think that the, you're right too, that the thing that that that kills me about this story is that so many of the people that are being charged are actually probably somewhat victims in themselves. You know, a lot of these, it seems like a lot of these sports guys, uh, they got pulled into gambling, they raked up, you know, huge gambling debts. And the way that they thought that they could get out of it was to, um, become, you know, basically part of the scheme.

And I think that that's probably why they were targeted to start with. Um, you know, maybe these guys were, were pulled into gambling, um, you know, poker and so on, uh, intentionally to try to help, you know, basically have them be the bait to get people to these high stakes private poker games. Um, you know, I don't wanna absolve them of responsibility 'cause it sounds pretty crazy.

Some of the things that they're saying, these guys did, you know, active NBA coach, you know, texting someone, you know, Hey, it looks like LeBron's gonna sit like pretty soon. He is, he looks pretty tired, you know, bet against the team, you know, that kind of thing. That's, that's, that's some wild stuff right there, because it's just so, just, he knew it was wrong.

He knew what he was doing is wrong, you know? And, and, and the same with some of the players. You know, Hey, I was just in the, in the locker room and, um, and boy, these guys look tired, or, you know, hey, I, I hear this team's gonna tank.

So if they get a better position in the draft, you know, the, the coaches said that they were gonna do that. So, you know, I mean, that's like Black Sox scandal stuff, right? You know, incredible.

The, the bookies. The bookmakers, even the legit ones in Vegas have always had their inside people in on the team, uh, you know, an equipment person or somebody that they call, how's the team looking today? Uh, you know, what do you hear in the, in the clubhouse?

Because, you know, without that inside information, you know, you, you're, you're at risk, right? You have to minimize your risk as a bookmaker. But I re my, one of my favorite recent episodes, you know, of the, of the Sopranos was Robert Patrick, Terminator guy, the liquid Terminator guy, right?

In, in one of the rare roles you ever see him in, especially if you watch Peacemaker now, but he, uh, friend of Tony's from school, owned a sporting store, you know, does one of these big games and, and loses, you know, he is in for like 80, 80 grand. Um, so they basically, you know, take his store and they're liquidating everything. They're using it, they're just abusing every, all, all the store.

They're taking loans, they're getting their money back however they can. And he looks at 'em and he's crying, and Tony is like, why'd you let me play? And Tony's like, scorpion, scorpion and the Frog, You know, Mike, Mike, I have a, I have a little different view on this, and what, what surprises me about this particular situation is how surprised everybody is.

Shocking. There's gambling going on that never happens in sport. Let, let's, if you'll cheat at Monopoly, you'll cheat, you'll cheat at real money type games, whether it's Pete Rose, or you can name, you can name dozens of instances in just in the last 10 years when there's a lot of money involved in a support in sports or in other areas too.

And for every measure there are countermeasures. So you put a gaming commission in place, right? To, to try to make it fair, to make sure that the people, the casinos are not cheating customers.

Well, then one of the commissioners is on the take for something, right? It just, it's, it's humans. And we're also dealing with something is that's an addiction.

So that even drives it further because you can take advantage of people. So I Why are you surprised? I think it's, it's, you, you have to have a way of being able to report when there are issues and investigate those and, you know, and try to, try to rein it in.

But it is, you, you can't squeeze that balloon and not have it come out other places. I throw What I'm trying to figure out, trying to figure out if Lata now has made members who have degrees in computer science, or did they just outsource this one? No, they can hire those two.

They've had this three come on, this goes back to the Sopranos. They had got, they, first of all, they had, uh, uh, Chris, he take, take his serious, he had to go take, well, he didn't take the Siri, they paid somebody to take the series seven exam from him so he could be, he could be running a, uh, a boiler room with the, uh, with the stocks, right? So he had to have his, his legit, yes, they've been hiring people for hacking for years.

This is not new. But, uh, again, from a gambling perspective and somebody who, you know, does gamble, I, I think one of the biggest concerns that this raises is those shuffler. 'cause every gambler I know, anytime I've ever sat on a table, we always have the conversation.

They don't, and especially when things aren't going out, they, I don't trust those shuffler, right? They, they, we don't know if they're legit. And so this just raises the whole spectrum on the whole industry.

Are they, uh, are these machines legitimate? Right? I think it has rippling effect.

It's gonna have a wide rippling effect through the gambling industry. I think there's, I think it's gonna be just as much going on, if not more. I don't think this is gonna curb it at all.

Yeah. Because there they Disrespect jp. But this is, this Is not No, no, no.

I'm just, I, I, I, I, again, the people who do gamble are, and, you know, be very, they're already suspicious. I think that the, like you're, like you said, the, the gambling commissions will have to step it up and make a very public appearance that we're doing more. And we, as you said, you know, how legit are those people?

We don't know. I agree. I would, I'm gonna end this here, but I would say, you know, on the next poker game I play is gonna be in a Faraday cage.

That's how it's gonna play With a, with a, with cards, cards, cards, Walmart. It doesn't help when the server and the wireless router are in the room with you. There you go.

You go See, there's always a countermeasure. Hey guys, I wanna thank everybody for sharing their knowledge and their insights, especially jp who shared some of his, uh, personal pastimes. So that was great to get that level of insight.

And I wanna thank you all for watching the latest Textron TV series, and also stay tuned for what's coming up next behind us, because, well, it's gonna be another awesome week of content. And this is just the first day of the week. Well, actually, it's Tuesday, so second day in the week, but Well, and, and that's if I can jump in there tomorrow and, and, and, and, and, and Thursday we've got, uh, AI Field Day.

So, you know, I mean, it's, uh, gonna be live streaming here on Textron TV right after the show. So, uh, ta stay tuned for a busy couple of days of, of AI presentations. And also next Tuesday we'll be talking about what happened at Textron AI Field Day.

So please join us then for that as well. Hey, thanks everybody. See you soon.

Hey everyone, welcome back here to Tech Trunk tv. We've got another good interview here for you to learn a little bit about. Um, I want to introduce you to Ryan cva.

Ryan is the SVP and field CTO for jellyfish. And let's welcome Ryan to Tech Trunk tv. Hey, Ryan, how you doing, man?

Hey, Alan, I'm doing great. Thanks so much for having us today. We really appreciate it.

It's a pleasure to have you on here with us. Um, Ryan, you know, let's start with you before we even jump into jellyfish, right? Give us kind of an idea of your journey, where you've been.

Yeah. Um, my background is a 50 50 split between operating and consulting roles, but all things around r and d. Um, I love tech, I love innovation.

I love the process of building something software oriented. So I cut my teeth technically doing things like bike code instrumentation for performance diagnostics. And then prior to joining jellyfish, about four and a half years ago, um, I was working in the private equity ecosystem serving as the advisor, private equity, both on value creation as well as software due diligence type initiatives.

Excellent. And then, so you've been at jellyfish about four, four and a half years. Mm-hmm.

It's a long time already. Yeah. I'm loving it here.

Good for you. For people maybe out here who are not familiar with jellyfish, how would you describe it to them? Yeah, uh, the jellyfish, uh, we've been around since 2017.

Uh, we consider ourselves what's considered a software engineering intelligence platform. Uh, so essentially we're sitting alongside the tools that engineers use day in, day out. And the idea is to surface the key insights or actions that help your engineers, whether you're a platform engineer or you're A CTO, up and down the stack, understand how you can do your job a bit more effectively, servicing key insights that help you do your day-to-day job.

Love it. Mm-hmm. Love it.

And people who maybe want to get more information about jellyfish, where do they go? co. You can learn a bit more about our use cases, what we do, um, and where we're driving value across our customer base.

Very good. All right, Ryan, if it's okay with you, I want to pivot now and talk about it, uh, recent announcement outta jellyfish about, uh, new, new product offering. What do we got?

Yeah, we, uh, just recently announced, um, our AI impact module, um, an extension of that, uh, to cover a few more capabilities. Um, I can go into detail, but maybe first down, does it make sense to maybe just talk a little bit about what our AI impact module is before talking about the most recent announcement? Sure, Of course.

Um, so our AI impact module as a whole is essentially looking at your r and d ecosystem, your full SDLC, and looking at where is AI actually injecting across the SDLC, um, and what changes is that making, right? And so I think we're all seeing this high pace of innovation today where, you know, every three weeks it feels like something new is coming out, a new product, a new offering, and it's, it's driving a lot of change. Um, throughout your SDLC engineers are being asked to use more tools, there's pressure to drive more efficiency, but it's really tough to actually understand what's happening across your SDLC and how are engineers actually behaving at what new bottlenecks are being created.

So the AI impact module is designed to help r and d leaders, engineering managers themselves fly less blind in this new ecosystem. Fair. The new release here extends that a bit, right?

So before we were measuring a little bit more around what is the gen, uh, gen AI impact, right? So how much do tools like copilot or cursor cloud code impact your pure productivity, right? As we think about this broader ecosystem, we're actually now extending that to have multi-tool comparison.

So you compare tool A versus tool B, and in what scenarios is a certain tool actually driving more productivity or more effectiveness, or, you know, maintaining quality across your organization. Um, the second thing we're doing is we're extending from the code generation phase of your SDLC into the broader code review area, right? So now we're looking at code review agents, right?

These are tools like code Rabbit, uh, graphite graph tile, things of that nature that are actually assessing your code in real time and helping with your code review process, which removing that next bottleneck that people are finding. If you're writing code faster, how do you keep up with the reviews and ensure that you're able to maintain what's happening as more code is being generated? And then lastly, we're actually starting to track AI spend.

So you can start understanding cost modules are changing right before it was by user seat. Now you're starting to have some variable pricing based on, I'll call a little bit of amorphous token pricing. And so how do you understand where is actual token spend coming?

Let's not get surprised by a bill. Are we using it most effectively? And questions like that, Dude, help me.

How you doing that? Yeah. Um, what's really cool is, you know, with Jelly Officials, our broader SEI platform is doing is we're already sitting above all the tools engineers are working in day to day, right?

So that's your, your GI platforms, your issue tracking, your production monitoring solutions, even your CICD solutions. And then there we're understanding how engineers are operating day to day for the AI tools. We're actually plugging in directly with the tools themselves to surface the things that do come outta their APIs, right?

You get things like usage, sometimes things like spend, um, but you're not getting enough to actually understand the impact your r and d. So we're actually fusing all of that together with an intelligence layer on the backend that's helping you understand, hey, cursor was used for this particular pr and here's what it actually looked like, right? That piece of code was actually, uh, a new feature request versus support, right?

And what did that do to your broader SDLC, right? Did it cause a bottleneck? Did it go faster?

Right? What was the quality? Did it cause an incident?

So being able to give you that full 360 view, what's happening by blending the two systems together and then surfacing that in a way that helps you action them as a leader. Very cool. Very cool.

Um, is this this available now? This is available now, yes. Uh, getting great feedback thus far from the market, which has been super exciting for us.

But, uh, really we want to, are we plugging in and understanding what's happening in their organization? Because this is a fast moving space, right? Mm-hmm.

And we're quickly expanding what we're covering. Um, some really cool things, hopefully back on with you soon now, and to share some of those. Um, but this is a space that's moving fast and leaning into driving that adoption today and understanding the impact and unlocking and becoming an AI first software development company, um, is what we wanna help people with that helps them succeed into the future.

Wanna make sure I got this right? Jellyfish AI impact is sort of a module that goes on to the intelligence platform. That Is correct.

The jellyfish software intelligence platform? That is correct. It is a standalone module as well.

Um, but it, Oh, so you don't need the, the whole platform. You could just grab the module if you want it. That is 100% correct.

You can buy AI impact module on its own. Um, and we're looking forward to having more people sign up for that too. What about, as we see more agentic AI being used, how will that kinda change the equation here?

Yeah, that's a, it's a great point. So where this is all heading, right? Um, with the AI is actually gonna be injected across the SDLC.

You're already seeing that today with tools like lovable on the prototyping side, right? And today you're seeing code generation, code review, and some production monitoring stuff. Um, what you're starting to see now is the next wave is you're starting to see now more agentic come across the SDLC, right?

So we're actually plugging in with tools and have new term versions out, um, or early versions out of agentic, um, development tools. You know, for example, tools like Devon that are out in the marketplace today and today, even Claude code that has an agentic mode. But we're seeing that agent workflow, or agents of agents even, um, accelerate both, um, the design, the development, and the release of, of code into production.

Um, and we're seeing that becoming just an additional challenge to this existing thing where you still have to have a human in the loop. You still have to have somebody to call when things go wrong. So how do you understand what's happening and where the cost cost goes?

The number one question that might come up with that, Alan, is both, I guess two questions there. One is likely the quality. How do you maintain that quality and control?

Um, but then second is how do you maintain that spend? It's very quick to, you know, have a, have a bill run up on you if you were to have multiple agents running, um, and accidentally spend too much on an individual feature support ticket if you just deploy an agent without the controls or visibility in place. Sure.

Um, let me ask you rubber meets the road question. What percentage of Jelly fish's clients are using AI in their SDLC? Great question.

Uh, we are seeing over 90% of our customers using AI today in their SDLC. The vast majority of them are using more than one tool today. Um, that can be more, more than one code generation tool and or tool type.

So starting to see more of that PR review agents, more agent to code development, as well as more prototyping tools like the lovable of the world. Huh? 90% crazy, huh?

It's wild. We actually saw a leap I think early in 2025. We were coming off, uh, some 20, 24 reports that were putting us closer at 60%, and we saw a leap heading into Q2.

Um, that jumped it to about 90%. And, and what we're seeing as the big change there was blowing the stepwise change in the models, but also the release of additional tooling, um, and the capabilities of those that were already in the marketplace, they coincided together. But we've seen a demonstrative change into Q2.

Um, and then Q3 of this year saw an acceleration of that. It wasn't just getting it deployed, it was moving from the state of adoption into actually driving productivity. And then we expect it heading more into actually driving greater business outcomes in Q4 here.

Yeah, I mean, these things follow sort of a typical thing. You know, it, it's, it gets adopted by individuals, teams, divisions, enterprise-wise, right? And, and, um, and not necessarily that linear, right?

You'll get a team over here doing it, and they're a little bit ahead of a couple of guys over here doing it. And, you know, all of a sudden the CIO says we're going to standardize on doing it. And so it, it's a little helter skelter, but it does kind of follow that pattern.

And I, and I think ultimately, you know, because doing anything in enterprise scale is, you know, it, it's not something you snap your fingers to really do enterprise scale. It, it, it takes some time. Um, but we're, we're, I agree with you.

We're on our way. I think these numbers prove it out. This sounds like a great useful, uh, module here for jellyfish or standalone.

It's, you know, even a standalone. So good. Good for you guys, Ryan.

Um, you'll come back on and tell us as this continues to develop, I assume, Oh, we definitely will. We'd love the opportunity to hop back on and yeah, maybe I'll leave with a parting thought a little bit here. Uh, and one of those is, you know, what we're learning in the market today, and we published an AI impact framework around this, um, in terms of how to drive the greatest impact with AI, is essentially, first you have to focus on that adoption to your point, right?

Some people are more skeptical, you know, others are leaning in. But it really is a change management exercise. Then you have to build the trust with folks.

We're seeing a take over a quarter between, from the time someone gets a tool to when they're actually starting to see productivity gains. So lean in, expect some time and focus on change management. The second thing there is to understand where the bottlenecks are happening.

If you're accelerating code, right? Where's that next bottleneck unlocking? Is it more enablement and when to use what, right?

Is it getting more PR review agents or focusing more on that pr review process of quality, but make sure you're seeing the right results, um, that continue to build that success. And then at that point, focus on the business outcomes, right? Are you actually releasing more features into production?

Are you getting a better return on that ROI of the AI spend? And it helps you both communicate to your teams, but also communicate to the pre external pressures outside of RD. Um, Very cool.

Hey Ryan, thanks for coming on. Good luck to you and all the folks at Jellyfish. co That is correct.

co. Yep. 'cause I'd made that mistake.

Um, hey, we're gonna take a break here on Text Drunk Gang on, excuse me, on Text Drunk tv. We'll be back in a moment. Hi, thanks for having us.

A Hey everyone. Welcome back here to another Tech Drunk TV interview. I, I've got some big news on a company called Mind Guard that we're gonna discuss right now.

Let me introduce you to my two guests. First of all, I want to introduce you to Dr. Peter Garrigan.

Uh, Dr. Garrigan is the, well, he's I guess current CEO and CTO at Minding Guard, but about to assume a new position, a really exciting position. And I want to introduce you to the incoming CEO of Minding Guard.

And that's James Breer. Gentlemen, welcome to Textron tv. It's great to have you on here.

Thank you. Nice to Be here. Thank You very much.

Thank you. James. If it's okay, I'm gonna start with you, right?

It, 'cause you're kind of coming in, you know, pinch hitting here. We're calling up a new batter into the box. Um, give us, you know, your impression here, incoming CEO of minding guard.

Why? Sure. Well, again, thank you for having me.

Um, you know, my background, I've been lucky enough to work in startups for the last 25 years and have been, I think, successful in identifying new emerging markets and technologies. And through that, my last role as CEO of Swimlane, which was a security automation company, I'm very familiar, It was very clear to me that, obviously very obvious for most people that automation's gonna be, have a, a huge impact in, in the world. And so I was a part of that, and we had a lot of good success as I was, uh, working at Swim Lane.

It became, again, very apparent to me that the impact AI is gonna have on security. And, uh, I was introduced to Peter and very quickly realized what he had built and the company's building was gonna be very unique in its approach in dealing with securing ai. And I said, I need to be a part of that.

It was that simple. Absolutely. Absolutely.

Um, James, if it's okay, I'm gonna, I want to focus in on Peter A. Little bit here. Please, Peter.

You know what, let's, let's first talk about your background. Obviously your PhD obviously, I'm assuming on the technical side of things, but you know, I hate to assume share with our audience a little. Sure.

So I have a PhD. Um, I'm also a chair professor in computer science at Lancaster University in the uk. Uh, Lancaster is one of the leading universities in Europe in cyber security.

So I be doing this role for about eight or nine years, I would say. I had a great opportunity to work with lots of big tech companies as well. So I kind of blend both the academic rigor of looking at security of systems and ai, but also working very closely with some of the big tech companies that solve problems they have.

And if you wouldn't mind, and I'll, I'll throw it to either of you who would like, give us a little bit of the history of mind guard. I'll hand that to Peter. Thanks.

So I run one of the largest research labs in the world for system security. And about 11 years ago now, I remember thinking AI, almost specifically deep neural networks. They're pretty interesting, but I'm not sure of current security tools and techniques actually work against it because it actually unravel a deep neur network, which underpins all modern ai.

It is very, very black box and very, very random. These things aren't good for security. Spend the next years of my scientist and engineers at University Lab trying to unravel some of the secrets and find a, it was really, really hard.

And, uh, b actually doing this quickly was really problematic. And come to 20,017, a very famous paper came out called Attention's All You Need, and this was the architecture that underpins all modern v language models and agents realize that we need to make a company in this space, but the tech we have built, because if we don't do this, I, I'm seriously worried people deploying AI at scale back in 2017 cause a huge set of problems faster today. We hear lots of stories about air being deployed and things going wrong.

So I took half my scientists from a lab, went to London, raised capital and position us and, you know, became the founder C and CT of Mangar at the time, actually thousand 22. I love it. That's a great, great journey.

You know, Peter, I, I've, uh, I've been in startups myself for 30 plus years. Done three or four, five venture backed ones. Be, you know, tech Strong was not a venture backed, it was actually my blog is how it started.

But I've been in security also for 25 plus years, right? We didn't call it cyber, we called it InfoSec. And, um, so I'm, I'm, I'm familiar with the, the whole journey.

It is a rare individual who's willing to kind of maybe set aside their ego and say, you know what? I'm probably not the best person for the job of CEO if we're going to take this where we want to take it. Um, my talents lie elsewhere.

But, but generally coming to that conclusion is a journey, right? It's not something you wake up in the middle of the night and say, Eureka, right? I'm doing this.

It's, it's a, it's a realization journey. Tell us, if you wouldn't mind, tell us a little bit about your realization journey to this point. Sure.

So when you're trained to be a scientist, you get better at identifying biases and flaws and thinking. So that's kind of one element. The second one is even from the company started, I remember saying to my first staff and my investors, I am the CEO and C two and a professor.

I have three roles here. Eventually those roles become decoupled. It makes perfect sense to do so as the company scales.

So the question was when and not if, and back 2022, yes, I had the vision and drive to pushing forward, and that's still the case. But as the company's now bigger and we know we have traction of customers, we have a more people more, more, more sales. Everything about this, I could do it, but it's not much.

Ty. What I really care about is building positive change, social, good research, vision, execution on research technology. But people will look to me in terms of, Hey, you have the vision executes.

Now the company is bigger solutions, more mature, and the customer are aware, it makes sense to get people who are specialist of what they do. So as we're now growing to the next stage, getting someone who's been there before, someone who's grown the companies to become, you know, the rocket ship makes perfect sense. And I'm sure Jim will talk about this, which is, this is seen as a great partnership, which is I can bring the vision, the kid, the, you know, the, the experience in my space and the drive to make things better with Jim's experience to also make things better for customers.

But more importantly, he's seen the things in pipeline sales, GTM and even things like, you know, um, people, people and resources, these things. This is Jim expertise in terms of group building, great companies. My expertise is at the heart of building great technology and great research to solve these popups.

I love it. Jim, let me come to you. A lot of times these kinds of, uh, you know, uh, executive board level kind of things are, are accompanied by, uh, a money raise.

Was there a money raise or additional capital raise with you coming on board? Not yet. I think we are currently had completed a, a seed round financing a little less than a year ago.

Okay. I think it's our plan to start to entertain, uh, a round financing here in the next six to 12 months. Good.

Um, Peter, I I just one more question for you and then I want to really jump into Mind Guard. You are shifting to the role of Chief Science Officer. Talk to us a little bit about what that mission is.

What, what do you see that as your, you know, what, what's your, what's your job as Chief Science Officer? So my job in the company, so as founder, is to make a company successful. Sure.

So it's not a case of I'm still talking to customers, I'm still doing marketing. All that thing doesn't go away. You know, alter founder, always a founder.

But my core reit now, it's very common in AI startups that the chief science officer is, you know, one of the key focus points of the solution. 'cause a lot of the space stuff in AI is not solved from a reasonable technical background. So I'm moving into a role to refocus on two or three things.

One is that my strength is looking for a vision for the future and making a reality as a scientist, I can bring that type of skillset and my background and ability into the company and keep driving forward the solution. So have a very differentiated and great product. The second one is what makes our company a little bit different is there is a very large AI lab at the University of Lancaster, which operates, there is a partnership that we have with them, which we'll be, um, talked about, I'm sure soon in order to actually, you know, train the next generation of AI security researchers, I'll be faking my time with them as well.

So there's a whole untapped market of research in this space that needs time. So our, my job is gonna be ensuring that my pushing the future of AI security, and we do this by actually having, getting at the heart of the problem of AI that we talk about is really the science behind it. And how do you take that science.

I've done it in technology, so a lot of my job is to focus on that. But of course I'll still be doing everything else in the company as well. But that's gonna be my core focus.

And obviously Joe Jim will be coming in then too. Um, excellent. Thank you, Peter.

Thank you. James, let me turn back to you now. Talk to me about Mind Guard's mission going forward.

Yeah, Sure. I mean, so again, I think what we're trying to build is the leading AI security company in the world. Full stop.

I mean, that's our objective. And it's really trying to help enterprises, I would say, kinda secure their models, uh, their agents systems. 'cause it's going to be ubiquitous here very shortly across the entire life cycle.

That is our mission. Yep. So, I, I would say it's already ubiquitous, right?

Yeah. 90% of developers are using ai accurate. 30% of Google and Microsoft say 30% of their codes AI generated.

Uh, the, and, and that's just in the, in the software delivery space. Right? Right, Right.

Jim, when I look at AI and security though, there, there's two, there's almost like two separate missions here. One is I'm leveraging AI to provide better security, right? Yeah.

Two is, I am actually, there's three missions. Two is I am defending against bad guys, let's call them. Yeah.

Bad, bad people who are using ai Yeah. To, to from, you know, malware and, and for bad things. Yeah.

And then number three, knowing that every organization is building a, a, a new AI infrastructure, a new AI stack, if we could call it that, right? How do I protect the AI stack from AI and conventional threats? Yeah.

Right. Whether I use AI or not. Yeah.

Talk to me about the three of them. I'll tee that, that's a very good question. I'll let Peter answer it.

But I think first and foremost, as you brought up right now, the, we're at a stage in the, in the market where you, if you saw kind of AppSec and how that grew and now you look at today there is, I, as I am, I'm expecting massive tsunami of challenges with securing ai. Meaning you don't see a ton of breaches announced yet, but they're coming. And if you fo track kind of AppSec in its history, we're at the very bottom.

And you also brought up kind of defense, well, first and foremost, most importantly is can, can companies get assurance and comfort and confidence that they have the right defense? And it starts with kind of an offensive strategy. And I think what we're trying to do is take kind of what Peter's built with the, the kind of the, the, uh, academic rigor of AI research and we're combining it with offensive skills.

So we're building the best kind of AI hacking infrastructure in the world. We brought in probably some of the best. And we're gonna train the models so that we can help give confidence to, to enterprises when we go kind of on a red teaming and using AI to red team to test and validate, you know, through attacks that their, their infrastructures protected.

Now we will also be doing protection is what you kind of got, we're talking to there. But it starts with getting kind of visibility and then attack and then we'll defend. And I dunno, Peter, if you want to add to that, I think there's two things.

AI's been around for decades. It's not new technology, non new concept. People are talking about airlines and agents as the this generation.

And it's got huge adoption, as you mentioned, Alan. You know, it's, it's pervasive, it's ubiquitous, it's come very quickly to market. So this introduces a new attack surface.

'cause the AI is still software, but conceptually, but how you do things like attacking and defense is actually quite different because there's no code. It's a bunch of mathematics probability in AI models. It's very, very difficult.

Yes. And what we're looking at is co enterprise companies have three problems in ai. First one is the visibility of risk.

Where is my ai? What is it doing? If I can't find it and I don't know what it's doing, how enough I'm gonna defend it.

So that's Always question one. Exactly. Number two, how do I assess my risk and how do I measure it reliably in ai?

That's very, very difficult from a skills perspective, but also just fundamentally it's a random black box. How do you actually have some validity on my assessments that I do compliance, but also make sure I secure. The third one is if I can find it and I can test it, I can assess it, how do I defend it?

And again, the solutions are moving very quickly. So these are the three problems that we see day in, day out, essentially companies deploying and building ai. And we'll talk about my, I'm sure shortly, but Margo's built to look at those three problems.

Excellent. Thank you Peter. Jim gonna come back to you.

So is minding guard more of a red team sort of service provider or is there actually building product around this? Yeah, no, this is a product company and I'd say we're gonna take advantage of our heritage, which is a lot around red teaming. But again, we're gonna expand on that because red teaming is just one element.

One of the things we haven't talked about is kind of the psychometric impact or behavioral impact AI has and how people can manipulate AI psychologically. That's another element that hasn't really been thought through deeply in the market. And I think we're gonna approach that as well.

So yeah, heritage is, is red teaming, but we're looking at it much broader. Yeah, I mean certainly, uh, if you wanna call it AI poisoning, inducing hallucination, we call it a hallucination. But if it was induced, well still a hallucination if someone induced it purposely, right?

Yeah. Poisoned the, the LLM, she's right. Um, and, and that is the kind of, you know, Peter, to your point, that is the kind of attack surface we're talking about, right?

Um, you, you, you have LLMs and it's not just LLMs. The, the future is a lot of companies will be creating their own small language modules and their own rags and their own vector that's right. Basis.

You know, that that will supplement, let's say a large frontier model running behind it or something like that. Um, are you utilizing AI to fight the, to fight the ai, to defend the ai? And if so, how?

Peter, do you wanna take that one? Uh, the answer, like all things, it depends on the context. The answer is yes, but AI is a tool, like all tools, you use it where it's fit for purpose.

So in mind guard, there are instances yes, that if you are attacking AI or trying to assess as risks, you can use ai. But that's, there are other techniques that exist as well though. Rule based systems is also AI decision making, even just having coding and doing, doing some technical stuff.

So yes, you can use AI to augment things, make it automated. But there are also other techniques as well, I should leverage comes back to my original point, which is the AI is still software, therefore a lot of those concepts apply. But as Jen mentioned with this, the problem with AI is that it's not human by the way, even though it tricks people a lot, it's still software, but it's being trained on human language and human information.

So as human-like characteristics in terms of people interact with it. And because the modern AI and l LMS and agents using natural language, I can ask the same question a thousand different ways. And that makes it very, very difficult on security.

So the, the example I give people is we're about manipulation. If I called up a call center, could I find the right words and tone to make them upset or angry to do something I don't want to do? Yes, probably in the infinite universe, I probably could do, it's the same as ai.

You've seen loads of cases of people basically gaslighting AI to make or do things it wasn't built to do. And that's the, and this is not a new concept for humans, but with the power of ai but also the ability for it to un to understand natural language, it makes a entirely new attack surface that you exploit if you're an attacker. Excellent.

Guys, just a little housekeeping. A couple things I wanted to make sure we mention was you recently, recently also announced the addition of, uh, rich Smith, whom I, I think I know Rich, um, rich Smith to the team as well as Aaron Portnoy. Two pretty well-known, uh, offensive security folks, US headquarters, moved over to Boston.

Great town. My my son's up there, he just passed the bar, he just got results. He passed the bar exam there now.

So if you need a lawyer up in Boston Gym, alright, reach out to me. Thank you. Um, so good, good stuff there.

What's the website guys? The URLI mean? Yep.

Um, it's mind guard without the u ai. That's M-I-N-D-G-A-R-D Ai, correct? That's correct.

Yep. Wanna make sure we get that out there. So guys, first of all, I wish you, both of you a lot of luck in your new positions.

Peter, it sounds like you are a duck in water, right? Getting into this chief scientist role and I'm sure you're gonna en enjoy that a lot more than looking over the, the spreadsheets and the sales numbers and managing all of that good stuff that goes into being a CEO that I, I know all too well, unfortunately. Um, Jim, I'm, I'm glad to see you back in the game.

You know, my, uh, swim Lane was a great company. We, we worked with Swim Lane here at Techstrong over, you know, either Security Boulevard or DevOps one, one of the seven sites we worked. But, um, I'm sure you'll do great things here.

I'm looking forward to hearing more from both of you very soon. Great, Thank you Alrightyy, pleasure meeting you. Thanks Alan.

Pleasure meeting both of you. James Breer, Dr. ai.

Check it out. We're gonna take a break here on Text Trunk tv. We'll be back in a little bit.

Hey guys, thanks to the throw, we're here with Danny Allen as the CTO for Sneak and we're talking about vibe coding and the security implications thereof because, well, we've seen this play before and it didn't end well, so maybe it'll get better this time. Danny, welcome to the show. Ah, thank you Mike.

Always a pleasure to be on with you and speaking with you. Alright, so back in the day we had low code and no code tools and people used those to build applications, so-called citizen developers and a lot of those things, well, they weren't exactly pretty and they were very rarely scaled and they certainly contained a lot of vulnerabilities. So now we have vibe coding tools that appear to be the next generation of these things and we're gonna use AI technologies to rapidly iterate applications and what else could go wrong, but is there a way we should be thinking about vibe coding and security maybe beforehand and not chasing in after the fact?

One more time. Well, vibe coding is here and my belief is that it's here to stay. It gives a lot of productivity to developers, especially when they're building applications that are CRUD type applications, create, you know, review, edit, delete type applications.

I, I don't think it's going away, however, because it's trained vibe coding because the LMS behind them are trained of course on open source code. There are, as you say, lots of vulnerabilities. And I think there's an opportunity, uh, to build security in at the very beginning.

We call this security from inception. Um, we're not doing it right now to be clear, but there is clearly an opportunity this time to do things different than back when we had no code, low code. We've been talking about shifting left for some time.

So is this just a continuation of that? And how far left do we need to go? I would argue that this is further left than the previous iterations that we had.

So when we said shift left before, most of the time it was, I want the developer back when they're writing code to be doing security testing within the IDE and sny obviously did that with all of our, our customer base. And that was kind of considered shift left going back the developer's desktop and testing from there and of course through the pipelines. But when you're vibe coding, there's no actual code at that point.

Literally you're interacting in natural language with your cursor or your windsurf or whatever the coding assistant is. And you're saying, I would like an application that does X. So you actually haven't written code, you're actually generating code.

And the opportunity here is to inject security into that process. And so I, my way of thinking about it is, this is security from inception, this is even further left than we had in the past. And that's a good thing.

To that point, therefore, am I gonna build some sort of AI agent into the vibe coding tool that will monitor the security of the code as it's created? And I'm assuming that I don't necessarily want that AI agent to be based on the same LLM that's being used to write the code. 'cause otherwise it'll just confirm the mistake that was made in the first place.

Maybe I think there's two phases that we're gonna go through. Um, the first phase is that there's gonna be generation of code and then the code will be tested. And we're already doing that right now, by the way.

So if you're using one of these generative coding assistance, it's generating code and at this point there's a fork. You can either tell the LLM, which was what you just indicated, you can say make it secure. And some interesting stats there.

com where they test this and g PT five, when you say just generate the code, uh, 54% of the code that is generated is both what you want and secure. When you prompt it to do security, it actually drops from 54% accurate and secure to 44% accurate and secure. And my belief is that it is because, um, the LLM in the model has been pret tuned for security.

And so when you give it instruction, it overrides, however, that is one fork in the road as you're generating code, you give it a second prompt to say, make it secure. Another way of doing it is to send it over to an alternative tool. And I think this is the better approach.

Um, I quite honestly, because you want to use Belt and Suspenders, if, if the LM already generated insecure code, you probably want a secondary model to validate it. And you can do that. Again, snyk already is doing this, um, V-R-M-C-P server to, you know, exposing it to any of these coding assistant.

However, my belief is is that that is really phase one because what you're doing is you're iterating, you're generating code, then you're testing it, securing it, you know, generating it again, testing it, securing it. I think ultimately we're gonna go to the point where the LLM itself that is generating the code actually generates secure code. So rather than being trained on a data set of all the open source code, which has all the vulnerabilities that LLM or the, the open source code will be curated into secure code only so that what is generated is actually secure.

But I do think that that is several years out. I don't think that is logistically likely in, in the next few years. What makes that so challenging?

'cause in theory you would just kinda go find the examples you were looking for and, uh, hire a bunch of people to show the LLM, this is good code over and over again. But what makes that more challenging than we think? Well, if I ask you, Mike, to go through all the open source code over the next month and, and secure it all, you'll probably realize what makes it so challenging.

The good thing about open source is there is so much code, the bad thing about open source is that there is so much code out there. Um, it does, it takes, it takes time intelligence to go through and verify it and make sure that there's not any false positives and false negatives. That is actually a very, very time consuming thing that I do think will happen over time.

But it's going, it will take time and it will take people that are security aware. Um, most developers, they know about the common vulnerabilities like, you know, cross site scripting, SQL injection. But when you get into these complex authentication authorization, cross file, you know, access type scenarios, it, it really does require someone who understands security at its heart to make sure that it's done properly and correctly.

Mm-hmm. What are the bad guys doing about all this? I'm sure they're watching closely and they're probably elbowing each other a little bit going, can you believe what they're up to now?

But, um, you know, can we secure all this stuff from them because they'll go after this stuff in a heartbeat, right? Yeah. Well, the bad guys are not unaware of AI and they're using AI often call this the perfect storm because you have, uh, more code than ever because of ai.

You have more complex code than ever because there's an increased attack surface. But then, uh, there is also attackers that are using ai and we're seeing this in some of the recent NPM supply chain attacks where they're actually fy, I don't know if that's a word, but they're, they're creating some of these supply chain things and, and putting in code that propagates itself. And it's very clearly using AI techniques to do this.

Um, so, you know, on one hand it's easy to be frustrated and, and propagate fear, uncertainty and doubt. But my belief is that actually on the, on the plus side of this and the white hat side of this, we have the tools that are disposal to actually make things more secure and more secured inception. And that's a good thing.

Mm-hmm. Are we taking this seriously enough now or is this one of these circumstances where we're about to go build and deploy a bunch of software and then there'll be some cataclysmic event that everybody will wake up and say, oh wait, we gotta go do this smarter. Well, I would love to believe that this time will be different, that we will do security.

The, the market, the industry will think of security from inception and do things the right way. So far in the last 12 months, it has not proven to be the case. Security tends to be an afterthought.

And I think that's just human nature, Mike. We, we, um, like to build things and so we get excited by using AI to generate code or do new types of software that you could never do before when it's backed by LLMs and security tends to be an afterthought in that environment. So I think we have the possibility to do things right.

It doesn't seem to be trending in that way at the moment. Now there are areas where that is the case. If I talk about our financial services organizations, our financial services customers or technology, they do tend to think at this at the very beginning.

But one of the things that AI is doing is it's lowering the bar of entry. And so everyone is becoming a developer. The, you know, the the mechanic shop down the street is now writing software and doing things, and of course they have no knowledge or awareness of security.

And so the best thing that we can do is actually to build security into the underlying foundations. I always said how did we eliminate buffer overflows? It wasn't by educating everyone on how buffer overflows worked, we went to memory managed languages like Java.

And so if we can build security into these coding assistance and into the AI itself, we will come out far further ahead than if we were just trying to educate and pressure people to do the right thing. Mm-hmm. And isn't that ultimately gonna have to be the end goal?

Because expecting developers, nevermind citizen developers to know about what it takes to secure their code is just, well, it's nice if they do, but it may be just too big an ask. Yes, I, I do agree with that. I think it is too big enough to try to turn everyone into security people and we shouldn't expect that their goal is to build software to, you know, make their beer taste better, is what, uh, uh, Jeff Bezos used to say.

That's what you need to focus on, do what your business does really well. But what we can do in the security industry and what we're very focused on here at snyk obviously is building security in, in a way that it adds no cognitive load, that it's just part of the process. So if you are vibe coding to use that term, security guardrails are just built into that process as it goes into the pipelines, it's part of that process.

As it gets deployed, the security controls are, are put in place. And so while I do think education is important, I also think we can do so much more to embed it functionally within the foundations of, of this new era. Mm-hmm.

What's your best advice then to the security folks who are probably looking at all this and they can see that there's clearly a tsunami building, it hasn't quite arrived yet, but, um, what do they need to do to get prepared for this? Because, well, the first wave of this stuff at least is almost guaranteed to be insecure. Well, the first thing is embrace it.

Don't resist it. When you begin to resist these technologies, all you're doing is creating shadow it. If you say you can't use this or you can't do vibe coding, what is going to happen is developers are going to find a way around it.

So you should not resist it. You should embrace it, understand it, learn it. The other thing, um, that I think that they can do is collaborate with the business.

Recognize that security is not a, a department of no. It's how do I collaborate and put in the guardrails and the checks and balances to ensure that we can actually trust the ai. The exciting thing is AI does unlock a huge amount of opportunity, and when we can trust that the software coming out the other end is secure, then you know, we can do so much more.

And yet, when we talked to CISOs, we did a survey earlier this year, 96% of CISOs said that AI was one of their top security concerns and 70% of them actually had said that they had an AI related attack within the last year. And so my point is this, that we need to collaborate with the business to help them embrace it, but doing it in a way that we can ensure trust to the, to our executives or to the board of directors. Mm-hmm.

Aren't we just moving too fast? And I asked the question because, well, nobody got out of bed this morning and said, yep, I know what I want to do. Let's go build some insecure software.

Mm-hmm. But they seem to do it anyway. And I think part of that issue is that there is this sense of, you know, we gotta complete this thing now and not take the minute or the day or even a couple of days that might be required to think about the security aspect of it.

But, um, is there just something wrong with our culture? I think there's two answers to this. If you're in a well-established technology space that has been building software for a very long time, sometimes it actually makes sense to slow down before you go fast to make sure that you get things the right way and do things the right way.

However, I don't wanna ignore the other part of the industry. We have all these companies that are, that are being built right now with billion dollar valuations on top of ai. And their moat really is speed.

The, the reason they get to the size that they are, the reason that Cursor has gotten to the size that they are is because of the incredible speed that they've used on top of ai. And another way of saying this is there's not technology differentiation. There is only speed differentiation.

And so it's really hard to go to a company like that and say, oh, you need to slow down because they'll get passed by three other people who are, you know, fighting to get to the top of the mountain. So I I, I think of the industry in two different ways. The AI native companies that are moving fast and pretty much have to move fast.

Um, and then you have your well established companies with, with a lot of intellectual property. And for them, sometimes I think you do need to slow down before you go fast. Mm-hmm.

Do you think that the regulators and the auditors are starting to figure all this out and looking at this and going, well, on the one hand they're probably freaking out 'cause they're like, how much stuff that we gotta review now And the second part of it is, well, there's just gonna be more things for them to find. So, um, are they gonna start, you know, aggressively analyzing more and more of these projects? Or is that still, in your opinion, I don't know, maybe a year or two away before they wrap their heads around it?

I think we're a year away, a year or two away from regulators getting their hands around it. I mean, I'm in the technology industry and it's hard for me to keep on top of what happened in the last month. And I live and breathe this every single day.

Um, regulators historically have always been slow to the market because they don't live and breathe it. They're regulating and legislating and doing all the things that regulators do, and they don't even necessarily understand it. So I think the, the regulatory part of this is not going to drive the industry.

I think it is up to the technology companies, up to people who are on the cutting edge of this, the financial services, the insurance industries to really step up and be the leaders on how do we adopt AI but do it in a secure, trustworthy way that doesn't put us in a, in a worse place. Mm-hmm. And who should be in charge of all of this?

Because we have the people building software, we have the security teams, we also have a bunch of AI teams in a lot of organizations. And then, um, but I feel like, you know, as we kinda get the village together to build the application, nobody's in charge of security so nothing gets done. I am a big believer in small tight consortiums of leaders that get together.

You never want a single company owning it. It's a bit like a fox in the head house because it's likely if it was a single company to be one of these model-based companies. And so consortiums actually do very well and SNY is a member of one of these, um, cos I is the ones the consortium for security ai.

But, but I'm a big believer that these types of organizations with a limited number of members who have the best interests of the, of the industry and the public in mind are probably the most effective way to drafting the initial models and architectures for security. And actually to this end, we're participating in this conference that is happening in October called the AI Security Summit out on the West Coast. And that's exactly what it's about.

It's not a single company sponsored. It's about bringing together industry leaders from everyone from coding assistance to security companies, to data companies, to, to develop and draft kind of a thought and a proposal for how the industry is shaped going forward. Mm-hmm.

Do we also need to be a little more cognizant, maybe even careful of how we're going about building all this software using these vibe coding tools? And I asked the question 'cause twofold. One is, um, it seems to me it's ripe for building a lot of duplicate applications within an organization.

And as such, every time I do that, I increase the attack surface. But also the amount of code being generated by these tools is, shall we say, verbose and debugging that and understanding where the dependencies are is that much more complicated. And so therefore the attack surface also got deeper and wider.

Is that fair? Absolutely. It's something that I've actually been speaking about for the last few months or so because it's deeply concerning and, and it hasn't been raised a lot for the last, I don't know, I'm gonna say five, 10 years.

What people have been doing is going to open source to, to use open source components. And the good thing about that, if there was a vulnerability in the React framework, you know, and it was discovered it would get patched and people would be secured. 'cause everyone is using the same component to do that similar function with Vibe coding, there is a real danger that we fragment the code that is being created because rather than going and looking for an open source component, what the vibe coding tool will do is generate its own code based on the open source.

And so now you end up with 20 companies because they're using a non-deterministic model that have slightly different code for the implementation of this particular function or feature or capability. And 20 different code bases means that you could end up with 20 different vulnerabil vulnerabilities implemented in 20 different places for which there is no future patch. And so I actually worry a lot about this, that when Vibe coding we end up with a greater amount of code that quite honestly would've been much better to have been consolidated on an open source component that is more easily managed downstream.

All right. Hey folks, you heard in here Vibe coding, it's not going away. It's gonna be everywhere soon.

The issue is of course that all that code is also gonna be everywhere soon and you, we may not know even where it's running or how it got deployed until it's too late. Hey Danny, thanks for being on the show. Ah, thank you.

Pleasure to join you. All right, and back to you guys in the studio. Hello and good day to you, wherever you are in the world.

My name is Stady Sanhica and I am governing board chair of the Continuous Delivery Foundation. When we talk about DevOps today, we speak with certainty about what it is and what we're doing. It's not an experiment anymore, it's not a passing trend.

DevOps is the bedrock of modern software delivery. It's how we build, deploy and secure applications every single day. But let's remember that it wasn't always this way.

15 years ago, DevOps was just an idea, a whisper between developers and operators who were tired of living in silos, tired of endless cycles of throw over the wall, tire friction between building fast and running stable. I stand here today as someone who's lived through that history with you. The late nights chasing down deployment issues, the manual handoffs and configuration nightmares, the finger pointing when something broke.

If you know, you know, we all remember it. We were there together. I remember the frustration of watching dedicated engineers spending their weekends, not building new features, not solving customer problems, but troubleshooting a deployment issue only to find that the staging environment didn't match the production.

Why the deployment that worked Tuesday morning failed Thursday night. Why? The same configurations that worked for one team somehow broke everything for another other.

We've all lived in the world where expertise meant knowing that mystical incantation that you type at 2:00 AM that makes the system cooperate. And something shifted. We began to practice the principles that became the DevOp movement, collaboration and shared responsibility.

Automation everywhere, continuous improvement. These principles weren't just theory, they they were survival. And because we practiced them, something remarkable happened.

CICD was born continuous integration. And continuous delivery became not just buzzwords, but the standards on how we built and shipped software every day. Measurements and feedback loops became our compass metrics, monitoring observability and blameless postmortems.

We learned to trust the data, not assumptions. We learned to treat failures as learning opportunities, not blame opportunities. And what followed was growth tool after tool, framework after framework, innovation after innovation, all in service to automating more, measuring better, delivering faster.

The promise was intoxicating, automate everything, measure everything, optimize everything. And for a while it felt like we were building towards a utopian future where software deployment was as reliable as flipping a light switch. But with that success came a new kind of paint tools, multiply integration work piled up.

What was once liberation? Finally, we can automate everything became to feel like a burden. So many moving parts, so much manual stitching to make them work together.

We automated our deployments, but we still manually configured our automation tools. We standardized our pipelines, but every team had their own way of defining standardization. We embraced infrastructure as code, but our tools remained frustratingly and analog and how they communicated with each other.

And so here we are again, together again facing the next frontier of DevOps. Here's what we see at the Continuous Delivery Foundation. The tools we use to enable DevOps have grown very powerful, but they're also, they've grown fragmented too often.

They trap us and they lock us in. They demand that we bend our workflows to their shape rather than adapting to ours. Think about your own daily work.

How many tools or dashboards do you switch between? How many scripts do you maintain just to connect to one tool or another? How many times have you had to re-explain to your team why the data in one system doesn't match the data in another?

How many times have you watched a new team member spend their first week not learning your product or your customers, but figuring out which Slack channel to monitor which dashboard to check and which tool actually has the definitive information, uh, about where things are deployed? How many times has a simple change like switching from Jenkins to getup actions or from Argo to Spinnaker to into a month long project? Because every team needed to rewrite all of their integrations.

And let's talk about that yearly ritual that every organization knows too well. The annual SDLC integration project teams huddle up to update their pipelines for the latest compliance requirements, adapt new security standards like salsa, generate SBOs for software compositions, and replace old aged tools with a successor every year. It's the same pattern.

Each team does it alone. Every product team, every service team, uh, every visit is unit. They duplicate the work, reinvent fragile scripts.

They struggle to connect their pipelines to security frameworks and security leaders demand compliance, but they can only enforce by asking every team to make the same integration effort over and over again. This is redundancy at scale and expensive demoralizing antipater. And it's the exact opposite of what DevOps taught us about eliminating toil.

Now imagine the alternative. A completely interoperable SDLC workflow orchestration framework. 100% tool agnostic.

Instead of dozens or hundreds of teams each integrating the same tool slightly differently. You integrate the tool once into your system. The framework handles the interoperability, the communication is standardized, your workflow intent is known.

Suddenly the security team only needs to oversee one integration. They validate the tools implementation into the framework and immediately every team in the organization benefits. Product teams don't waste months duplicating efforts.

They just plug in and inherit the security and compliance automation that's already there. That's the promise of events as language instead of each team struggling to translate it into their own dialect. The framework utilizes CD events to create a shared organizational language.

Once the tool speaks it, every team can understand it. Once a process is encoded, every workflow benefits, the annual integration grind disappears. What used to be a season of pain becomes a moment of opportunity because interoperability has been handled at the framework level.

This isn't just efficiency, it's a cultural transformation. It's the difference between an organization weighed down by repetitive toil and one that is free to focus on innovation. The irony is that DevOps was supposed to reduce toil, but in too many places we recreated the toil at a meta level.

So now instead of running manual deployments, we're now stitching together automated systems. Instead of manually configuring servers, we manually configured the tools that automatically configure our servers. The abstraction level has changed, but the fundamental problem systems don't naturally cooperate remains.

And the harder truth. DevOps is supposed to be inclusive and it should be able to get out of our way and still enable our success. But right now, too often the tooling makes itself the center of attention.

Your pipelines shouldn't require a PhD in tool specific configuration languages. To understand them, your monitoring should need a Rosetta Stone to translate between different systems interpretations of the exact same event. Your governance shouldn't break every time someone wants to try a new tool that might actually improve your process.

In the early days of DevOps, the breakthrough was simple but profound. Treat physical infrastructure as code store configuration data in a file represent hardware as a virtual concept, encapsulate reality and text that move encapsulation. That was revolutionary.

It gave us infrastructure as code, which gave us modern pipelines, which gave us the modern cloud, native world. And here's what we realized. We can do it again.

Think about music for a moment. Sheet mode, music like gives structure, but jazz takes it further. And jazz sheet music isn't a script, it's a framework.

It defines the chord, changes the time signature and the key. It sets the boundaries of harmony. But within those boundaries, the musician is free.

Free to improvise, to respond, to take risks. That's why strangers can walk into a room, pick up their instruments, agree on a key, and within minutes they're not just playing, they're creating something alive. They don't need to rehearse every note.

They don't need a script for every phrase. They rely on the shared language of jazz. They and language that sets the rules of communication, sets the rules of communicating intent.

And then trust the players to bring their voice. That's what CD events and conduit are doing for DevOps. Not a rigid script, but a prescriptive pipeline.

But a, a shared language of events. The entire concept of build becomes recognizable, actionable. A deployment started event is just an expected portion of the deployment concept.

Security scans are more than success and failure. Simple, clear, universally understood. The specification sets the key, the tempo, and the harmony within that tool.

So tools can improvise. Your pipeline can respond, your organization can innovate without fear that the instruments won't play together. Just as jazz musicians rely on chord progressions to stay in sync for creating something new.

DevOps practitioners need interoperability to stay aligned while innovating. Without shared language, it's noise. With it, it's freedom.

If we can encapsulate servers and configuration, why not encapsulate the intent of our SDLC workflows in the events themselves? Why not agree on the markers, the virtual object boundaries for the data we pass between tools. That's what we're doing with CD events.

That's, that's what specification the specification work is all about. We're currently, we're, we're, we're currently doing this right now, but here's where it truly gets powerful name spacing. Think about it this way.

We've created a common language for SDLC events, but we also recognize that every organization, every team, every tool has its own context, its own needs. Names facing is how we balance standardization with customization. The core events, the common information that everyone needs, that stays consistent.

That's our shared foundation. But through name spacing, your, your Jenkins can add Jenkins specific context. Your security team can add compliance flags.

Your organization can embed its own governance data, all without breaking the contract for anyone else. This is DevOps thought leadership. The next progression, and here's the thing, it's not just theory, it's action.

Building towards a working implementation of conduit is not just a a GitHub issue. It's standardizing the way we encapsulate our work so that we can move through it asynchronously freely without translation pain. Let's see if I can change the way.

Uh, you think about the entire delivery pipeline. We talk about events, but events alone, don't tell the full story. We need what we need.

Our patterns, structures, recognizable shapes and signals. What type of work is actually happening. Think about written language for a moment.

You can recognize the structure of a sentence, even if you don't know all the words. You can see the boundaries where one begins, another ends. This is what we call workflow segments.

The more themes of software delivery, A build segment has a recognizable pattern. It starts, it processes source code, it produces an artifact. It ends.

The pattern is consistent. Whether you're using Jenkins getup actions or any other build system, a deployment segment has a different pattern entirely. It takes those artifacts.

It configures environments, it manages traffic. It validates help build objects and deploy objects are structurally as different as curly braces and square brackets. They serve different purposes.

They have different contracts. They produce different outcomes, but it doesn't stop there. Test segments, security, sand segments, approval segments, rollback segments.

Each one has a recognizable pattern. Each one encapsulating a different type of intent. Think about your own experience reviewing deployment logs.

You can usually tell whether you're looking at a build failure or a deployment failure at a glance, right? Even if you don't know the specific tool involved, the pattern is recognizable. A build failure talks about compilation errors, missing dependencies, test failures.

A deployment failure talks about network timeouts, health check failures, capacity issues. Your brain already has these different categories of problems requiring different types of solutions, workflow segments. That this, it's just like intuitively understanding the explicit and actual right.

That's all it does. It just makes it intuitive. And here's what made it truly revolutionary.

These patterns are extensible. Your community can define new segments. Your industry can standardize on domain patterns.

Your organization can create segments that match your unique process. Imagine a security stand segment that's understood the same way, whether you're using SNCC or Veracode or an internal tool. Imagine a compliance check segment that the, uh, compliance check segment that financial service companies can standardize on regardless of which regulatory framework they're implementing.

Imagine a machine learning training segment that data scientists teams can use to integrate their model development workflows with traditional software delivery, the possibility is only limited by imagination. This is how we create the grammar for software delivery, not just events flying around, hoping someone is subscribed to the right one, but structured meaning that any system can interpret. This is how we connect the pieces.

CD events provides the vocabulary, the standardized way that our tools speak with each other. Names. Spacing provides the flexibility the way that each tool, each team, each organization can add context without breaking the convention.

Workflow segments provide the grammar, the structural pattern that gives meaning to the sequence of events. With these three concepts combined and working together, something magical happens. Your build system emits standard build events, but it also includes your organization's compliance context through name facing the conduit framework recognizes the build segment pattern and knows exactly what to expect.

Next, conduit actively monitors the next step and can if there is a misstep, move to correct it. When the build completes successfully, conduit recognized the actions, then actively monitors the next segment, which might be handled by a completely different tool. And should any issue along the way happen.

Conduit's active monitoring ensures that it will take the appropriate pre-approved action that you define the test Tools don't need to know anything about your build tools. The deploy tools don't need to understand your test framework. Each segment operates independently, but they're connected by the shared understanding of the pattern and the events.

And when you wanna replace Jenkins with GitHub actions or swap out your deployment tool, as long as the new tool implements the same segment pattern, produces the same structural output, everything just continues to work. Even if the new segments don't have the same internal steps, the segment specification standard will assure that the segment ends with the same expected data format. Teams to spend their time building features, not rewriting integrations.

Lemme put this in concrete terms that your CFO will care about right now. When your team wants to evaluate a new tool, how much time do you spend on the evaluation itself versus figuring out how to integrate it with everything else that you already use? When you finally decide to adopt that new tool, how much of your implementation timeline actually is configuring the tool versus building connectors to make it work with your existing ecosystem?

When that tool gets upgraded, how much of your engineering capacity goes towards integration versus taking advantage of new features? Conduit changes that equation. Fundamentally, integration becomes a configuration concern, not an engineering project.

Tool evaluation can focus on capabilities, not compatibility. Your team can invest in their enterprise and solving customer problems, not maintaining plumbing between systems. The challenge we face aren't the ones that I use sleepover.

The trouble is what's coming. Just think about how many tools and processes we've added to the SDLC workflow in the past five years. New ideas, new risk, new opportunities.

If we fail to establish a shared language for our SDLC, the future of DevOps will be one of increasing fragmentation and lock-in Right now. It may feel like an inconvenience. Extra glue scripts duplicated effort, brutal integrations that break at the worst possible time, but look a few years ahead and the risk becomes existential.

Imagine it's 2028. Your organization adopts an AI driven security tool. It's powerful.

It promises to find vulnerabilities faster than anything you ever use, but it doesn't speak the same event language as your pipelines. Suddenly you're, you're forced to build custom adapters. Your deployment tool doesn't recognize its alerts.

Your monitoring system can interpret this output. And because integration is so costly, leadership decides, let's just buy the whole vendor suite. Now you're locked in.

Innovation slows because every new tool must either conform to that vendor's proprietary event structure or, or be excluded. The ecosystem shrinks. Freedom of choice evaporates.

We've seen this before in tech, the walled garden that stifles creativity until standards break them open. Think back to the early two thousands when, uh, every phone had its own charger. Nokia, Motorola, Blackberry.

Each one forced you to buy new adapters, new cables, new everything. Switching devices was painful, and innovation in the mobile ecosystem slowed because users were chained to the proprietary accessories. Then came USB and later USBC, a shared standard that didn't just make life easier.

It accelerated adoption across the entire I industry. Suddenly manufacturers could focus on quality of their devices instead of locking people into their ecosystems. The crossroads we face now in DevOps, without a shared language vendor, lockin becomes the path of least resistance without a shared language interoperability.

I mean, with a shared language, interoperability becomes the default, and freedom becomes sustainable. Events as a language is not just a technical nuance, it's a strategic defense against a very real future lock in. And the key to unlocking our collective innovation and my tenure is governing board chair.

I've seen organizations where 40% of their DevOps engineering time is spent not optimizing their delivery process, but on keeping existing integrations from breaking. I've seen cus companies delay adopting better tools for months because their integration effort would consume their entire engineering capacity for a quarter. I've seen team choose inferior solutions simply because the, they integrate it more easily into their existing hodgepodge system where there's a different path available to us.

Imagine a world where adding a new tool to your pipeline takes days, not months, where your compliance requirements can be embedded once and enforced everywhere, where your teams can choose the best tool for each job without worrying about how it will integrate, where innovation happens at the speed of ideas, not the speed of integration projects. The Continuous Delivery Foundation exists to meet that future before it arrives to build pathways, the specifications, the shared infrastructures that let us move faster and freer together. This work that we're talking about, this isn't work that I can do alone.

This isn't work that the CEF can do alone. This is community work. Our work as DevOps practitioners.

The only way interoperability becomes real is if the community, our community cleans it. If you demand it from your tools, if you contribute to shaping the specification, if you recognize that the same principles that gave birth to DevOps must now be applied at a higher level of traction, you're claiming it too. So I'll ask you the same question I ask myself, how can we do this better?

That's not a rhetorical question. It's an invitation to every engineer, every vendor, every practitioner who is ever cursed at a broken integration or stared at a dashboard that, that didn't quite add up. Your voice belongs here in the CDF helping us solve this problem.

Your organization's unique requirements. They help us understand what name spacing needs to support the team's workflow patterns. They help us define new segments that benefit everyone.

Your integration pain points. They guide our priorities with the conduit framework. This is how standards actually get built, not in an ivory tower, but in the daily reality of the teams trying to deliver better software.

The CD events specification isn't written by academics. It's written by practitioners who felt the same frustrations you have. The conduit framework isn't being designed by people who've never managed a production deployment.

It's being designed by the engineers who've been woken up at 3:00 AM because they've had a broken pipeline issue. The workflows segments aren't theoretical constructs. They're, they're patterns extracted from real team solving real problems.

We need your use cases. We, we need your edge cases. We need your requirements that don't quite fit geely into anyone else's milk to models, because the goal isn't to build something that works for some organizations.

The goal is to build something that works for all organizations all the time, while still giving each organization the flexibility to excel in their own unique way. CD events provides the language name facing, provides the flexibility. Workflow segments provide the structure, conduit ties them all together.

But the larger truth is this, the pain you feel today, we will ease it. The trouble that you don't see, we're, we're already working on to solve it. The time your team spends on integrations, we're working to give that back to you.

You should spend your time solving interesting problems. Your engineers should get to focus on the code that makes your customer's lives better. Your innovations should be limited by imagination, not the integration complexity.

This, this, this isn't theory. This isn't wishful thinking. This is real, this is happening And we're building it together.

Thank you. Hey, as always, you know, we're floating in the clouds, you know, looking for more AI, bots, robots, whatever we think we need. Welcome to Security Boulevard, the cybersecurity podcast from the Futureum Group.

Every episode explores a variety of topics within cybersecurity and the technologies that drive it. com, security boulevard's, YouTube channel, Textron tv, and all of your favorite podcast platforms. Let's meet the panel for today's episode.

It is my two favorite co-hosts. Mitch, how are things going today? Hey, as always, you know, we're floating in the clouds, you know, looking for more AI, bots, robots, whatever we think we need, that's gonna happen now.

We're doing really good. It is, it is conference season. Fernando and I are on the road, if not every week, pretty much other week.

I think we fly by each other. They go into different things or attending virtual events. So it, it's, it's actually Christmas.

It's come early. We get lots of presents right now, so it's a lot of fun. Absolutely.

Speaking of, so yeah, the, uh, we're, we're recording this in, um, in late October. And, um, as I, as I speak to you from, uh, from Toronto, the, the, the Blue Jays are the World Series and whatnot, right? So, uh, and tying this to event, uh, last week I attended a local event and, um, uh, and, and I'll get to that.

I'll get back to this. Then. There, there, there's, there's a relevance to the topic.

But I attended the local event and, uh, I, I was fortunate enough to win an official Blue Jays jersey on, uh, the, the, we ran that cahoots game like a, and I was, I was the fastest with the, with the things that was fun to, to, to win an official jersey. So I, I had that. So, yes.

Uh, so Christmas came early. Yes, and yes, Mitch, we are all, uh, we are traveling a lot. Uh, this week I happened to be home, but then I think I travel five of the next six weeks or something like that.

That that's our life, right? Is once we get into the fall, it's time to go out and do stuff. If only we had something that could take care of all of that for us, some kind of magical solution that would think for us and do all the things.

Oh, wait, that's right. I forgot that that's ai, that that's the promise, right? Like, I, I keep seeing all of the things online about how it's, it's gonna make my life easier.

And, and then I think about all the security that that has to deal with ai. And, and we've actually seen that a lot recently. Uh, if you look in the news, there's a lot of companies that are making moves to kind of shore up some of their AI things and, and some companies flat out need to add capabilities to get ready for that.

And so I, I think maybe, you know, we, we've kind of danced around it in a few episodes already, talking about how AI is changing the landscape of security. And, you know, uh, last year LLMs were the hot thing. Um, you know, or as I like to refer to it, uh, slightly advanced in schizophrenic autocomplete.

Um, and now we're into the agent, uh, realm, you know, uh, trench coats and glasses and, and tri, uh, walking around and trying to look all cool and swab when in fact they're, they're probably more like the bumbling keystone cops agents right now. Um, I'm not biased or anything, but I, I wanna open this up to, to you guys because, you know, you, you kind of see this from the forefront of the research side of, of the future and group. How, how is a AI kind of leading this charge to redefine security as we know it?

Well, security is your area. You just need to go first there, Fernando. So let me start by saying that I absolutely love the conversations we're all having as an industry around this, and I think that we should continue having them.

And I am, uh, I'm surprised and, and heartened by how well we've, we've dove into the topic. But I think that one of the things that, and and tied back to conference season, like when, when I, when I speak with, with executives and vendors at events and, and, uh, was it George Bernard Shaw that said that the, the, the greatest thing or the, the folly of, of communication is thinking it happened or something like that? I forget what the exact quote is.

And I mentioned this because when we are talking about this, I always find that we need to, to, to ground things, right? Uh, depend on ground truth and anyway, but, uh, the, the way I like to frame this is that we are talking, we, we should, we should make, there are at least three major topics that we need to talk about. One is AI for security.

We are applying all the artificial intelligence and machine learning we've been developing since the 1950s. Two address security needs, right? This is the, the let's review code.

This is the, let's use agen to, uh, to, to investigate events. This is the, uh, let's use, uh, uh, entity recognition and whatnot to recognize, to do data classification like AI for security. The flip side, of course, is security for ai.

Your organizations are, uh, doing their, their AI initiatives and it come in multiple shapes and sizes, and they all need security. And we're seeing some very clear patterns there around how do you secure your agent workflows? How do you secure the data that's going be used for ai?

How do you secure the identities that are going be used in the, in the context of AI context? That's so security for ai. The third one, people don't talk as often is this notion of, I, I call it security from ai, right?

And not here to, to Christopher Hoff who did, uh, a similar framing like years ago about cloud, right? Security for cloud from cloud, et cetera. But the security from AI piece is, listen, if you do nothing else, if you think that AI is a fact, if you think that, uh, we're just gonna keep doing what we're doing, sadly, I have news for you.

Your adversaries are using ai, and we're seeing this rise in multiple shapes. We can talk about those in a bit. But that's the third major lag, which is security from ai.

If you'll, how do you change your defensive using AI or not in light of adversaries that are using ai? So those are the major three pillars. One other distinction I want to make is, we always talk about, I think, I think it's helpful to talk about the distinction between what I call workforce AI versus workload ai.

Workforce AI is all of us as individuals, how we are using AI in our day-to-day, within our workflows, within the tasks that we're doing. We're using, uh, LLM of choice to help us with editing. We are using, uh, uh, whatever service we want to, oh, give me a, a summary of this particular topic or, but how AI is affecting user level workflows, right?

That's one. And the, the workload AI is the one more associated with, okay, we are building ai, we are using AI within our organization to, within an application we're building, we have a chat bot in our, in our portal, we have a, um, we're using predictive AI within something like we're building it into the software that we're deploying. That is a different proposition, right?

And organizations need to address, frankly, both. So I, uh, getting off my soapbox for a second, but it's basically let's, let's keep all of these in mind. Security, uh, AI for security, security for ai, security from ai, and then workload, workload ai, and workforce ai.

So after that, we can have, we can continue the conversation. How do I think it's, you provide nuance and subtlety in a topic. I was just told that I had to go buy AI and all my problems will be solved.

Yeah. Uh, Yeah. You know, you know what I think I, I've come to the, the realization that every product segment goes through its own AI evolution, its own AI lifecycle, and it just at different starts, at different times, it moves at different speeds.

And you can see security, the security market largely at the, let's use natural languages and interface. Let's use AI for particular, generate AI to reduce some of the toil writing, uh, incident reports for you, writing your strategy for you, um, pulling, writing other content for you that normally a person would have to put together. Um, we also see it, there's already been machine learning algorithms used in correlation of events and things like that, and we see more of that even with generative ai.

Um, but what we haven't seen a lot of yet that we're starting to see in other segments is creating, having AI do for us AI agents doing work for us, moving eventually to agentic. And I think, you know, security folks are, are cautious bunch, right? They're skeptical bunch.

And they're, that's just how we're wired. And that's okay, because if, if they're gonna deploy it, uh, it's gonna be secure. They're not gonna be you like the software guys who wait to, you know, forget, forget about security until we've already built it, and then we go add security in.

So they're naturally gonna be, I think, more thorough and cautious of it. So I, I'm waiting to see, or looking for, let's put it that way. So what's the breakthrough, uh, moment in AI in security products and either moving to something more like agent based or agentic or, you know, uh, Cisco had their Cisco data fabric, right?

They're solving their own data problem that they need to contextualized to be able to use AI across not only the security products, but other others. So it's interesting. I'm, it's, I'm not pessimistic.

I'm optimistic about it, but I think it'll have its own curation rate and, uh, how it, how it goes into market. Part of the wonders will it, will it ever get to that point though? Like, because everyone looks at this and says, oh, this is the next cloud revolution.

And, and I agree that there's gonna be a huge impact on it, but I also think back about a lot of the other things that I've seen that we're gonna completely revolutionize and upend the market that didn't. And, and I have a bigger pile of those things over here. And part of it is that, and we see this all the time in the, the hype cycle is there is a magical revolutionary thing that doesn't have a really good use case right now, which means we're gonna apply it to every use case, and then we're gonna hit a point when we realize that no, it's really only good for a few things, and it does those things really well.

And, and if we apply it that narrowly, it's a success. But the people who are trying to convince me, or you or anybody else out there, that it is the panacea for every problem that you could possibly have are the ones who wind up walking away disappointed. Conversely, they're usually the ones that walk away to a different technology and go, no, no, no, no, this is the one, this right here.

I know I said that last week, but this is the one that's gonna change everything because, and then they trot out the same arguments that they trotted out again and again and again and again, because they're, they're trying to imagine a future that has something that, that, that they need or they want, and they're not finding it, but rather than creating it, they're latching onto the next thing that they can sell to people to do that. Again, you know, I say, Mitch, I am the pessimist on here. Well, I have one, I'll be the pessimist for a moment.

I have one word for you, blockchain. That was the, the savior of the, the, uh, security world. That was the next big thing.

It was gonna transform everything that we, that we do in security. And at the time, I was very skeptical. I'm like, I get what it does, and I see the uses of it in, in crypto and some logging kind of applications.

But it took a while for it to shake out and say, okay, here's some really good uses of, of blockchain. We have some great implementations and we have some startups that made it a lot of money, but it didn't, it hasn't revolutionized, revolutionized the industry. Now, will AI revolutionize it more so, or, or is this the next 3D tv, right?

We all get 3D tv and like, never have you ever watched 3D TV on a 3D tv? No, probably not. I doubt it have, but, but Hold On.

I don't think it's that. But, But, but I, you, you hit on something important there, and I think that people need to understand this. We, we bag on 3D tv, right?

Like, that was, that was a weird thing. Uh, thank you avatar for doing that. But one of the side effects of 3D TV is that by forcing people to make them, they got better at making TVs.

Because I don't know if the people who are listening to this podcast, remember, but before 3D TVs came out, the low end of the market was kind of crap. Like, like you really could go out and find like a seven 20 p panel that was kind of middling LCD performance for what we thought at the time was a reasonable price point. Now, that same price point is like a 4K tv.

And the reason why is because in the race to make 3D technology more affordable for people, they figured out how to cut costs on that. And I think that that is one of the benefits of AI is that we're putting it in there to add feature sets and do things that will enhance productivity overall. So maybe things with AI and security don't fall out quite like we want them to.

But kind of to Fernando's point, let's say on that first thing where we're doing, um, you know, AI for security, maybe by having those agents running in there that are summarizing systems and giving us recommended actions, and, you know, doing something su as simple as looking up the end of life, uh, information from vendors to make sure that there's a supported firmware release or something like that. Like, those are things that would enhance the product overall, even if AI doesn't solve all of those problems. So this is where I like to take a step back and, and I a tagline post something on LinkedIn, whatnot.

I I often put a tagline, never adult day in this industry, right? And I, I strongly believe that, and this is where I love how we can tie back all that's going on, right? We can tie back the, we were, we were chatting about nation states the other day, right?

We're talking about software supply chain. We're talking about like everything is coming together. And if I have one message, like i I, for security practitioners, uh, throughout their careers, whether you're, whether you're a junior just starting, whether you're somebody wanting to get into cybersecurity, whether you are, uh, uh, uh, an executive who's been around for a while, where wherever you're, the message that I would love to give, I, I want people to take from this, is that cybersecurity is now across the board, cybersecurity is now, uh, embedded everywhere in society.

And I'm sorry for the, for the cataclysmic, uh, wording, but the thing I wanna bring up here is what Tom just mentioned about the evolving panels, right? I urge people to look up two, uh, frameworks of concepts, right? One is, uh, Simon Wardley is, uh, widely maps for those who are not familiar, like Wardley, WAR DL EY.

So Simon Wardley is a, is a, uh, researcher. Uh, he's been involved in technology for the longest time, and he writes more around, I, I'm, I'm simplifying it too much, but he writes more about technology evolution itself, right? And, uh, he has a, a framework where you think about is the technology that we're working with absolutely brand novel, nobody have ever done this before, is this technology that, uh, is around, it's brand new, but you can now customize it a little bit.

Is this technology that you can buy commercial off the shelf? Or is this technology that has now been commoditized? And the dynamics of, of, of this evolution is that as technology becomes more commoditized, one of the things that is really interesting is that the moment that it's a commodity, you can then base newer technology on top of it, right?

So, uh, why are we now why are we discussing, uh, I mean, the simple example is electricity, right? Electricity is commoditized and the world runs on electricity. We, we may argue AI is, parts of AI are moving towards that commoditization, but so that's framework number one.

The other framework I think it's interesting for people to be aware of is, uh, David Snowdens Cent framework. Kinesin, I believe is a word in Welsh that's similar for habitat. And what it talks about is the relationship, again, it's not a centric thing, but it's the relationship between cause and effect.

You can look at problem, they call it a fence making framework. And you can look at problems in the relationship between, uh, what's the relationship between cause and effect on any given thing, right? Can nothing spell the C-Y-N-E-F-I-N, right?

And what's interesting about the Kinin framework is that it breaks the world into four major, five major areas, but four, four, there are problems that are very clear, right? It's a C for clear. Uh, there's a direct simple relationship between cough and effect.

If I drop a glass, it's going to break. How do I clean the glass that breaks? Well, I, I, I clean the glass, right?

There are things that are complicated, which is, there is a relationship between cause and effect, but it takes a few more steps. It takes, uh, it takes some sort of expert knowledge along the lines to investigate it, right? Okay.

How do you troubleshoot, uh, flapping, uh, L two connections, right? Uh, okay. You, you're not, you're not just going, oh, it's just this, you, you, you'll usually go through a series of troubleshooting steps.

There are problems that are complex, complex problems are those that you don't really know what's causing them. So you run a series of experiments. Okay, let's try this, you know, work, let's try that work.

So it's a mindset of complexity, right? And then the fourth one is what they call chaotic, which is our, there is no direct relationship between cause and effect, and you're just trying to, uh, staunch the bleeding, if you will. And you're just trying to move to a different type of problem.

These two frameworks, the connecting framework to understand what kind of problem you're in. And the, the worldly mapping ideas of how technology evolves, I think should be required reading for anybody looking at AI and star, whether that's cybersecurity or development or networking or whatnot. Because those things come together where ai, where, where these things come together in a really nice way is where do agents fit in?

Well, if you look at the, if you look at the, the, the fin framework, you can derive that. Look, agents may be particularly good at the clear problems because it's relatively easy for them to understand what needs to be done. They can be good for the complicated problems because they can reason to a series of steps, or we can infer we can teach them to reason to a series of steps, right?

They may, they may even be good for the complex problems because those are the problems where we're going to run multiple experiments, try different things, and then you have a human at the top to orchestrate, okay, this, this work or not, they may not be as good for the chaotic problems because that's where the human capability of intuition and creativity and, uh, communications and whatnot may take up. And I know I'm, I'm monopolizing the, the, the mic, again, I do apologize, but I think that it's really interesting to observe the AI evolution in cybersecurity, not only from the perspective of the, the specific areas we're touching, but how technology itself is evolving, right? So I'll, I'll, I'll stop here and summarize widely maps and the, the connection framework should be required reading.

I feel like every time I do a podcast with Fernando, I come away with like a required reading list that's gonna take me till the next episode to get caught up on. I'm waiting for him to say there's a quiz on Friday. Oh, crap.

Now I gotta study. But, but can, yeah. Don't, don't use AI to summarize.

No, But, but that's a, a good point though, is that we're in a world now where people really would do that. In fact, I almost cracked the joke, uh, for now to just gimme the website and I'll have, you know, notebook lm gimme some flashcards on it. But like, that's the problem that we're running into, is that a lot of the knowledge that we use to troubleshoot these systems is institutional knowledge that is accrued over failure after failure after failure.

And we've seen this through systems throughout time. We're trying to shortcut through that right now. We're hoping that if we load all of that institutional knowledge into a giant database and make it easily searchable by not us, um, that it'll somehow be better.

And I, I'm toying around with this idea of AI is really useful for people who have people who do things for them. Like, like when you think about everything that AI is being positioned to do right now, it's all about making us into the kinds of people who say, Mitch, take care of that for me, like the, the, the idea of doing research on something is gone. Like, I don't want to do research anymore.

I want this thing to tell me what I should know about something. And I get the value of that. Like, if, if I'm about to jump on a phone call with Fernando and, and I suddenly need to know everything there is to know about kind and economics, give me a one pager.

But don't assume that makes me an economist. And I think that, that people are starting to rely on AI to do that, right? And we've seen this a lot when people are like, oh yeah, it's like a security analyst in a box, or it's like an army of security analysts in a box.

Yeah. It is until it hits a problem that it doesn't understand. You know, Mitch, to your point, like I was thinking about something I'm dealing with with my car right now where there's a light that comes on.

So I've done the thing, well, that didn't fix it. Well, I did the next thing and that didn't fix it. I'm literally going down the checklist trying to fix all of the things that could cause that light to come on, and none of them are fixing it.

So now I'm deep down in that list of, it shouldn't be this, but it can't be anything above that list. 'cause I've already fixed those. And that's where AI falls over.

And, and we've seen this over and over again. Like, it does not know how to create a novel solution to a security problem. And what happens when someone is using something new or different in an oblique way.

And, and we go back to the F five hack, right? That that happened and people got access to unreleased vulnerabilities that, that the public doesn't know anything about. So if I get hit with one of those and my AI system pops up and goes, wow, this shouldn't have been a problem because this isn't exploitable.

Well, it is. You just don't know about it because the information that you're dealing with is not out there. And so it might take somebody thinking outside the box to turn the phrase, to come up with that idea.

That's, in my mind, that's a complex problem as defined by Fernando a problem with no immediate easy solution. And, and I think what we're gonna run into is that the more we have AI solving the mundane problems, the faster it's gonna fall over when it hits the problems that it doesn't know how to solve. Well, I think, I think part of what you're describing too, Tom, is that AI can do a succession of things for you.

Um, but it starts to fall down when you really need a specific context around it. Like I can say, write me a report on the sta the state of AI and cyber, right? And it'll write me a report just like I could ask anybody else to do one.

Uh, it just has immediate resources. Well, no, that's not actually what I want. What I want to, your earlier discussion, Fernando, I wanna know about securing a AI models and I wanna know who's doing what and what the techniques are, and if there are any emerging trends and if there are any kind leaders in this area, right?

So I have to give it the things that I want. It's not just ask it to do something. You can ask it to do something.

Um, so there's a lot of, and you can say that's prompt engineering or whatever, but even with doing that, it doesn't mean you get what you asked for. I can't tell you how many times I've said I want a solution that doesn't involve writing code. Pretty soon it's recommending code, writing code for it.

I'm like, I don't want that, you know, for everyone. It just, it's a, it's like, um, you know, kind of that teenager you need to remind, uh, you know, turn off the lights and shut the, shut the door when you come in the house, right? It's not gonna do it every time.

You're gonna have to make sure that, that it actually gets done. Sorry, teenagers, we all did it. So, um, it, it's, it's not there yet.

So I, it, it is not ag agent. It could just turn it all over and it's gonna run security for us. But I think it, I think it's not only things you would ask somebody else to do for you, for what I find is training myself to take the things that I'm doing and ask it to do for me.

I don't wanna do that. That takes a long time. That's a lot of effort, not a lot of busy work for me to do that task.

I want you to do it, but, and you get into, you know, automation candy, I think is what you called it, Fernando, trying to get AI to do the work for you. But, but I think you bring up a good point, Mitch and I, I wanna pick up on something that you said prompt engineering, right? Like I, I've heard that term for a while now, you know, there, there's people that are actually teaching classes on it.

You know what I hear when I, I hear prompt engineering Google searches, because that's basically a form of prompt engineering when you type in, because there, there's the very generic, you know, why does this like, come on? And then there's the kind of things that we do, right, where we type in a very specific error message and we exclude these sites and we wanna look for PDFs that have that, that loaded in there like that. We, it took a long time for us to learn how to efficiently search through the cruft, for lack of a better term, to find things that are important.

And how do you impart that to a, to an ai? Like one, one of my favorite things is to see all of these, uh, you know, systems online that are teaching LLMs how to write like certain people and like, yeah, you can teach it to write like Hemingway because Hemingway has a lot of information out there about who he is, but how do you teach it to write like, I don't know, a a security analyst? How do you teach it to write a report that sounds professional, but also with the right tone, but also not saying, here's the deal, or it's not x it's y or sound like a marketing bot.

Because that's one of the things that we're running into, like think about, you know, I I, I'm a grammar person, like the EM dash problem, right? Like, oh, it has em dashes in it, so it must be an ai, no, legal people use em dashes all the time, and Fernando does too, but like, the reason why it uses them is because that's what it was trained on. And so like, we're, we're running into these problems where we want AI to think like us, but we're not telling AI how to think like us, and it's trying to extrapolate and it's doing a terrible job.

So when we teach AI agents to be security people, how do we teach them to be properly paranoid about making sure my VP n is up when I go to black hat and other things like that? Or do we just say, you know, version one's never gonna be what we want it to be, so we'll move on to version two or something like that. So this is where I would love, I I, I, my my another rallying cry for security practitioners worldwide, right?

It's, these problems are affecting us in the way that we are not going to, they're not going to stop, right? They're not gonna stop because AI is too interesting across the board, like the, it's been, it's been dangled, right? Uh, sorry for the video it's been, but it's been dangled in front of people.

Look, we can, and, and we have to address this. So what practical advice do we have for practitioners on, okay, how do you deal with this? Well, step one I would say is you need to learn this stuff, how this works.

I absolutely adore the way you, you summarize like prompt engineering of, of advanced Google searches because, uh, first of all, I think that that, that, that tracks, but the other thing is why are we doing those? Why did we, why do we have to do prompt engineering? Well, we do prompt engineering, just like we did more custom Google searches because the tool that we were using did not learn, right?

No matter how well, uh, I mean, of course Google learned profiles and, and whatnot, the, the, the web searches learned profiles, but you always had to give it context, right? You always have to say, like I said, don't search for like search only for PDFs or, or only from this site, from, from this period and whatnot with prompt engineering and context engineering, right? What we're doing now is we are trying to teach the, the, the lms, right?

Look, this is, uh, all that I can tell you about this problem that we're trying to solve. And, uh, please do your best, right? And I think that there's two motions here for practitioners.

One of those motions is you need to understand that this is the current state of the art as it relates to agentic systems and enterprise environments, and you need to play this game. So, okay, so you work with, what are the specific kinds of problems in my workflow where having a, an agentic capability that I have to coach all the time about what it needs to be told, like about a context, what are the problems that it can help me with, right? That's it, right?

So you as a security practitioner, as a network professional, uh, of a developer, you need to understand your own work processes. Like Mitch alluded to that help me do the stuff that I do. You find the, the steps in that work process where AI with context can help you and you take a position of, let me as a security practitioner within my organization work with you dear business developer, whatnot, on how to address this, right?

So that is step number one. Like understand the constraints of AI LLMs, understand why we have those constraints and work with those constraints. And step number two is to the extent that you can stay on top of how this is how this is evolving.

I'm not saying that you have to go and archive and start reading LLM papers, those you have the time, that's wonderful, right? But it's stay on top of what the, develop what the, the, the, the, the software the AI vendors are doing. So one of the things I'm excited about is, uh, philanthropic just announced the Claude skills, right?

Maybe that's an area we can touch. Um, we have the, the, the, I mean, Tom, you brought up notebook. It's, it's wonderful for, for some things, right?

So my message to to practitioners is understand those constraints so that you effective securing AI and using AI for security and securing from AI within your organization and stay on top of where that, that evolution is coming because it is coming all the time. Like never day in this industry. I think, oh, go ahead, Tom.

Just gonna add that the, the Google comparison works, but it also is bigger than that. Mm-hmm. There are times when a, a kind of a single shot prompt, you know what, what's this, right?

Find this, tell me this. Um, and you can give it a sentence, right? A short one sometimes, and it'll do what you want it to do.

Most of what prompt engineering or context engineering is really laying out that description. It's more like a one page product description if you'll of what you want with instructions, right? And, and that's when you're most likely gonna get what you're looking for.

And the problem is you may not know all what you need, and so you'll evolve that over time. Um, and there's also a way to ask it to write the prompt for you saying, here's, here's what, here's what I want you to write a prompt about, and I'm looking for these things and have it write a structured prompt for you. So there's, you know, in a security context, they, do you want every security engineer to be writing a random prompt to answer a standard type of question?

Probably not. I mean, if it's an important one, if you're looking for a particular kind of output with certain kind of constraints, et cetera. So we're, we're dealing with the where state of the art of what the technology is today.

In some ways we're kind of training the model of it, and we're training ourselves how to, to use it, because you have to be in so instructive of what you need to have. Um, and I was gonna mention skills, cloud skills also, because that's a great addition innovation step forward that adds context and retains that context as a skill or information that the model can use to respond to whatever prompt you it's working on. Um, which is another problem is memory and keeping, you know, it's, it's body of knowledge to enhance it with what you want it to know about.

So it's, it's, it's evolving and it's evolving quickly, but in some ways not fast enough to live up down the hype at all because it doesn't do what the hype says it'll do in many cases. Alright, I think we're gonna have to wrap this episode. I mean, we really probably could go on for another couple of hours.

The good news is, is that we have more episodes, so we'll have another episode on this. Uh, but we hope that we've given you some things to think about in terms of how AI is transforming security and why it's not as easy as it might sound on the surface. But one of the other things that has wonderful hidden depths, of course, is the work that we do here at the Futurum group.

I know, Mitch, you and Fernando are both working on some great things. Mitch, what, what are something you've got on your plate right now that people wanna tune in for Trends for late 2025 going into 2026 around agents and software development and the evolution of where it's moving next? Um, some of them are big trends.

Some of them are kind of natural evolutions of where we are trying to point out, like how do we, how do we make the right decisions in how we adopt these things? The other is, um, as I mentioned this is, this is a lot of gifts on the tree, presents under the tree. This is Christmas season.

So in a way, Fernando and I and everybody else, all of our listeners are gonna be inundated with the next announcement this week. It's GitHub universe next week. It's you pick your, pick your poison, whatever the conference is.

And some of those are announcements, some of 'em are product announcements. It's a feature, right? So Microsoft comes out with a planning capability and, and co-pilot.

Yeah, it's a feature. But what it is, if you, in a bigger context, which is what I look at, is that's one of the steps of broadening beyond co-generation into the work that's performed, the tasks that are performed in development with bigger context and bigger intent that you're driving it. So a lot of what I'm looking at is, yes, there's 50,000 announcements that happen, you know, between now and Christmas.

There's a handful that are really important to pay attention to. And then there's a handful of things that, that, that is telling us where we are and where we're going. Yeah, I'll be brief.

Yeah. Uh, I'll try to be brief. So there's a, there's a couple of things.

I've, of course, AI is, is, it's, is front and center. I just wanna comment that, uh, I mentioned an event that was here in Toronto, uh, last week. Uh, this was, uh, an event by Veeam, who last week also announced that they acquired, they, they're, they're acquiring security ai, right?

So this interplay between data protection, which cyber resilience and, and AI is really interesting. It's one of the areas we're, we're, we're tracking. We wrote, we wrote up about the the acquisition.

We'll be following stuff like that. The other thing that, that we're working on is I'm working on, on security operations platform, right? This, how does the evolution of, let's call it the evolution of the sim XDR and others, right?

Uh, with ai. So that's coming in the, in the not too distant future. And the other piece I'm, I'm, I'm working on is almost going back to the earlier point where we talked the other day about nation states and whatnot.

What does the, the, the landscape look like for a security organization nowadays in terms of what has to be global, what has to be local and, and, um, uh, data residency and, and, and concerns around those areas? Of course, AI plays a part too. So, um, that's what I have in, in, in the, uh, in the draft board right now.

And, and it's working its way towards, Well, if you're very interested in ai, maybe in general, not specifically about security, uh, AI Field Day is happening this week. com, you can see a lot of companies that are working on these very problems and learn a little bit about how they're trying to solve them. But don't forget that we have a lot of video about this from a lot of different, uh, events throughout this year.

com/tech field day. I also wanna thank each and every one of you for listening to this episode of the Security Boulevard podcast. If you enjoyed this conversation and you want to get more reading homework from my friend, Fernando, please subscribe on the YouTube channel or your favorite podcast application.

We don't want you to miss an episode. We also appreciate you leaving us a review that helps the show grow. com and Futurum Group.

com, the tech TV website, or check us out on the Techstrong TV app that's available on Apple tv, Roku, and other smart devices. Follow Security Boulevard on X, Twitter and LinkedIn. Just look for security BLVD and you get lots more content besides just this podcast.

Thank you all for tuning in and we'll see you.