Techstrong TV Tuesday, April 7, 2026

We're live. Okay. Hey, welcome back here to our...

It's actually day two. Some people may call it day one. It's Tuesday.

We're at RSAC Conference, continuing our coverage. My next guest is Greg Clark of OpenText. Greg, thanks for coming here up on Broadcast Alley with us at Tectron TV.

Well, I forgot to mention, Greg is with OpenText, but he's a, was it- Senior Director ... Senior Director. I was going to say- Product Management ...

I almost gave you a raise there. Well, hey, field promotions are- No, but I said- ... almost as good as the real thing.

Exactly. Senior Director of Product Management for cybersecurity at OpenText. Greg, we were talking off camera, and you said you've been around the carousel with OpenText now two or three times.

Yeah, exactly. Give people a little sense of your journey. So, again, I started my career at OpenText maybe 20-some odd years ago.

It's an information management company. So I started in content management. About halfway through my career, I pivoted into regulatory compliance, eDiscovery, which led me into data security.

And as we started to evolve our data security business and put together a portfolio that was cybersecurity centric at Micro Focus, we pulled together identity and access management, data security, SecOps, the intricate pieces that make a cybersecurity portfolio. And then three years ago, we were acquired by OpenText, and I'm back for a third- I'm back ... I'm back for a third time.

Just when you thought you were out, they pulled you back. Exactly. Good for you, man.

Exactly. Good for you. OpenText is such an umbrella of an organization.

" Right. Well, what do they do? Software, this, that, the other thing, but do they really know what they do?

Well, they may know some of the things. Right. Give the audience, if you don't mind, an idea of what do they really mean.

So, as I mentioned, Alan, we talked about information management. In today's environment, especially if we're doing the buzzword bingo around this place, around agentic and around AI- It's true ... the concept of secure information management is what our customers really entrust us on a daily basis to do.

Mm-hmm. So, what do I mean by secure information management? What we have is GenAI, agentic AI.

It's outpacing the governance models that our customers have. So, the bull is out of the barn, so to speak. So when we look at our capabilities to help organizations secure that information, to secure the identities that are accessing that information, but not just human and non-human, but agents.

They need to be on the same playing field as others because they're 20 to 1, 50 to 1 when they're deployed inside of customer environments. But you also need to monitor that behavior. So as agents are traversing data, as users are traversing data, look for unusual behavior, look for potential risks.

So when we bring all those pieces together, along with our information management background, we have a secure information management platform or capabilities that are built exactly for enterprise AI, or what I would consider safe AI. So the ability to manage the data, govern the identities, continually monitor behavior around the information. And also, on the application security side, we're ensuring that the code is secure, that agents, as they're onboarded, built, or bought, are legitimate, verified as well.

Got it. Greg, it's interesting that securing an API, let's say. Mm-hmm.

Look, the API was written to do this, and it does this every single time. Yep. So you can make rules around that- Yep ...

because you know this is what it does. Yep. It's deterministic.

Exactly. When we're talking about trying to create rules around agentic AI, the game changes a little bit. It's non-deterministic.

The agent learns. Its behavior patterns change. As a matter of fact, I've been playing with agents now for a month or so.

It doesn't do the same thing twice. I'm constantly like, "Hey, this is different than yesterday. " The model changes.

And it says, "Oh, you're right, Alan. " Yep. Exactly.

But it's hard to build models around that. It's hard to build the guardrails around that when this thing is zigging when you think it's zagging. Yeah.

And so how do you account for that kind of, I don't want to say randomness, but it's kind of random. Yeah. I think there's a couple foundational pieces, really, of note.

So if you look at one of the key concerns, so what's the attack surface? It's the data. The bad guys or insiders are trying to get at data.

So at OpenText, we have the ability to help understand and visualize risk around data. AndThat's one aspect. So when we are able to visualize that risk or surface that risk up into the identity layer as it sees unusual behavior into the SOC as it sees unusual behavior, we're able to heighten the signal, raise above the noise that, oh, okay, there is consumer data in this CRM system.

There is a SharePoint site that has sensitive data. How do we help see through the noise? So not only can we show the risk visibility, but when you talk about agentic and how it's scaling beyond the confines of what we would consider an API talking to an API, a person traversing the environment, our ability to protect the data at the source with encryption and format-preserving encryption enables us to essentially future-proof data- Okay ...

so that before it goes into the AI pipeline, it's de-identified. So Alan's sensitive data is scrubbed, but just like an analyst would use it in a cloud data warehouse or a BI tool, as an agent is accessing that data, it still has referential integrity. It can still do its task, right?

So the guardrails around data is one aspect. The other aspect is when we start looking at agents as an identity on the same plane as a service account, as a non-human and a human, we start putting up the abilities or capabilities around what is the intent of this agent? What can it do?

What data should it have access to? And what are essentially the policies for this agent? The moment we start to see drift, where an agent is talking to another agent, it's accessing data, not in this CRM system, but a layer down or in another application.

You detect that drift with this continual monitoring, you're able to, again, step up authentication even for the agent, just like you would a user. You could block the account. Sure.

You can suspend the- No, at that level, you can. Yeah. It's just another user.

Exactly. So those are foundational pieces that we can bring to the market for customers, so that they can adopt AI more reasonably, responsibly, and from an enterprise AI standpoint, those are the things that are absolutely critical- Mm-hmm ... for these things to scale.

Right. Love it. Yep.

Love it. Let's pivot a little bit. You guys announced, I think it was just yesterday- Mm-hmm ...

a study you did with the Ponemon Institute. Yep. Dr.

Larry Ponemon. Been dealing with his stuff for a long time. Yep.

Talk to us about that, Greg. Yeah. So it falls in line with a lot of the things that I just described, Alan, but a couple of things I think that are what we've seen.

So this was 1,900 respondents at the VP senior level with AI as a clear mandate for them in terms of their priorities. What we found was in that report that, look, about half of them had deployed gen AI, but really 20% of them saw any material success or value out of that. So it really laid out the foundation for what's next.

So when we start looking at autonomous behavior, even less of those respondents, 43%, were confident that AI was ready to be autonomous, ready to make decisions, ready to take on tasks. But the biggest thing I saw in terms of what I felt was surprising is about 60% of the respondents felt that regulatory pressures, privacy, compliance were impeding their ability to really gain some scale and some momentum, live up to the promises- Absolutely ... that agentic AI has.

And again, it's one of those things where what I described around governed identities, protected data, continuous monitoring, really understanding agents as they're built and bought and deployed, those are the kind of guardrails or those are the kind of capabilities that we believe are the main DNA behind what is successful and safe AI, enterprise AI. Absolutely. Let me ask you a question.

Anything in the report that you sort of didn't see coming? Or maybe, I think what we see with AI when we look at these reports is like I saw it was coming, but I didn't think it was that far along, right? Right.

Like I thought a lot of people were using it- Mm ... but not 88%, right? Right.

Anything like that? Yeah. I think the thing that stood out was 18 months ago, we were talking about this inflection point, and we felt that, look, people would learn from the gen AI journey, and they wouldn't let the floodgates open up.

So what stood out to me was actually how many organizations had, yes, deployed agentic AI, but also don't have enough risk-based approaches to monitor and guide the successful deployment- Yeah ... of these things. So we didn't learn from gen AI.

I think I said on stage maybe a year ago, while we certainly won't be making the same mistakes with agentic AI. I've been around long enough to know better than that. Yeah.

I've been around long enough. And so have you. I'm telling you.

I should. Right. Fooled you.

Yeah. Exactly. Got you that time.

Exactly. But the fact is, look, not saying AI is like things that have come before because it is very different. Yep.

Some of the patterns- Mm-hmm ... of adoption, and especially some of the patterns of security's response to it- Right ... are kind of the textbook things we've seen over and over- Right ...

again. Right. And it's like, I don't know what it'll take for us to learn those lessons.

Mm-hmm. But I just hope we learn them a little faster each time. But, you know.

Well, the scale of AI is probably- The scale and the time. The velocity of AI. Yeah.

Is the scarier part, right? Yeah. It won't be a chatbot that makes up a bereavement policy like in Air Canada, or you can trick a chatbot into selling you a Chevy Tahoe for a dollar.

It will be you're exposing your entire customer base, your CRM system, to an agent who has then shared it, or acted- Well, what I worry about is, are the agents hackable? Yes. Absolutely.

Absolutely. Every agent, every interaction. If you're not monitoring every agent, every interaction, every action, you put yourself and your data...

And let's be honest, it's a reputation risk. Risk. Yeah.

Right? All on the line. You're putting that all on the line.

And then the other thing is these agents, they spawn sub-agents. You don't know what those sub-agents- It's a complicated thing. Where can people get this report?

They can get it from our website. com. On front page, maybe.

And I believe it's right off the front page. But also, if you look at us in our socials, on LinkedIn, on X, the report will be front and center there for people to download. I love it.

Greg, anything else that we haven't covered? I think, Alan, you've got a great reputation. This is where I'm pumping your tires.

Yeah, yeah. Pump my tires. I love that.

In cybersecurity, this is a checkbox. Yeah, no, this is good. I'm glad.

Right? Don't be silly. I'm glad to have you here.

But let me ask, so it's only day two. I don't know how much you were here yesterday. We were busy.

Yeah. But what do you think? Certainly the story this year is agentic AI.

Yeah. Duh. Yeah.

But what else are you seeing under that surface? I think it's really around the importance of AI governance. Yeah.

I think that when you start to scratch a bit of the veneer off of it, the ability to discover agents, shadow AI, again, monitor them as they're coming on board, what their behavior is. Because look, there could be thousands of them. They could spin up for one workflow and then spin back down.

The AI governance side of this challenge that we're facing here is the next horizon. I think the whole governance of agents, of the code they spawn- Yep ... is really going to be the battleground, at least for the next year to two.

Yeah, I believe so. Until we figure how to... We need an equilibrium to develop.

Yeah. Right? Exactly.

Hey, Greg, thanks for coming on here, man. Oh, my pleasure. Good luck.

My pleasure. Look, you're out in the front lines on this one, man. Ready to go.

Greg Clark, OpenText here. Go check out that Ponemon Institute report on their website. Dr.

Larry Ponemon. We're going to take a break. We'll be back with more here at Techstrong.

We're live from RSAC at Moscone West. Hello, everybody. We're back in Amsterdam at the KubeCon + CloudNativeCon Europe Conference, and I'm talking to my friend Hong Wang here from Akuitie, and we're going to have a little chat about, well, Argo CD.

There's been a lot of momentum building around Argo CD now for several years, and it seems like it's finally coming to a tipping point in terms of adoption. And are people thinking differently about CI and CD these days? What are you seeing exactly?

Definitely. So the Argo CD has been on this like long run, and personally I have been the creator, and I have been working on Argo CD for about 10 years. And nowadays, I think last year, the CNCF published a survey talking about 67% of the people are already using the Argo CD in production.

That's nearly a majority. So I think the Argo CD is already the clear winner for the GitOps in the Kubernetes space. So what we are seeing, the trend here is, originally people are looking for, okay, I have a CI/CD system, like GitHub Action, GitHub CI to do everything.

But Argo CD proved out is actually you need something specialized for the CD. That's why people using, okay, GitLab or GitHub together with Argo CD. But we do think we have additional innovation on top.

That's why we introduced this new concept called continuous promotion. It's kind of doing the multi-environment promotion and making every environment to be the first-class citizen. So we actually introduced the Kargo about two years ago.

Right. So I think I saw at the show there's a new version of Kargo floating around. What's in there?

Yeah, we have the open source version for two years, but we keep adding new functionality on top. So last December, we announced our Kargo version actually supporting Terraform, VM, and serverless promotion now. And today, yesterday we announced that we are actually making the Kargo be able to run custom steps.

So the main usage for that is actually right now, security validation or maybe any custom scripts you want to run during the promotion. So we make it like catch all use cases, means you can customize your experience and do all the things you need during the promotion. Mm-hmmWhat was different about CI/CD and Kubernetes versus what we were doing in monolithic applications?

Because for so long, we tried to couple CI and CD together, but it feels like with Kubernetes, we've shifted more to this GitOps mindset. But what drives that at the end of the day? It's actually an excellent question, so I have a lot of saying about it.

So the traditional Jenkins or GitHub Action jobs, it's jobs. Means it's run to finish. It's kind of like, oh, it's successful or failed.

That's it. Basically, it doesn't like a continuous, like a getting the status of your application. It's kind of like, oh, I run successful, done.

So things could be changing even after the deployment was successful. So what it changed for the Argo CD and the Kargo is, we do the promotion during the deployment, but since then it stops there. We actually continuously monitoring your infrastructure, understanding what's going on, and that's kind of like where the people needs.

It's kind of like a, you don't need a job run to finish. You want to actually constantly understand what's going on about your application. Are they healthy?

Are they out of sync? Or someone actually change something behind the screen? So you want to know about it.

So that's give you the massive visibility. Have we also maybe started to see a little separation of concerns? Because maybe the CI part of that equation is really in the developer realm, and the CD part is more in the software engineering, DevOps platform engineering team's concern.

And is that also driving this? Yeah, I think exactly to the point. Totally agree.

So it's kind of like the CI is mostly for the, I would say, the development. Basically, okay, you got a new change, you want to build your binary, building a Docker image, running the function, running some testing. But for the CD side is more, I think, in the realm of the platform team, DevOps, SRE.

Because what is the ultimate goal for the CD is actually we want to release something to the production. It's a very high value, high risk, higher level activity. Means if something's broken or something released causing outage, we are talking about maybe millions of dollars.

I work at the Intuit for four years thinking about what's the time now? Okay, in another month, we have the tax due date, middle of April. So every ten minutes is about $10 million for Intuit.

So that's scary. That's why people are actually looking for a very customized experience for their deployment experience. They want to minimize the risk.

They want to have more visibility. They have better control of it. That's also all the reasons why we built Kargo, also solving that very practical usage and meet that needs.

One of the things too about Argo CD that I've heard is that people actually like the graphical experience for managing CD, and they don't necessarily want to do everything using programming tools. Yeah. Are people flipping in and out of graphical, the programming tools, depending on the use case, or are they all kind of just basically using the graphical tool?

I think people still using flip around here and there. However, having the graphic part is the totally the big advantage for everyone. So there is a reason why from the day one, we created this great UI experience.

Because at Intuit in 2018, that was a little bit ahead of the journey for everyone adopting the Kubernetes in a large scale. So Intuit basically asked us to say, "Hey, we want to adopting Kubernetes on AWS, and we have 4,000 developers. They don't know about Kubernetes at all.

" So our answer was Argo CD plus a nice user experience to be embedded. Then we don't need to tell the people, "Hey, what is a pod? What is a replica set?

" Okay, where you deployed, you see this tree view. Then you see, oh, I get it. So sure, I'm not the expert.

You don't need to be the expert, but roughly you get it. Oh, there is how the object are connected to each other. Additionally, we make the logs to be available, events to be available.

And once something is broken, we highlight it. Okay, this part is crashing. So that in the end is like we making the 4,000 developer to kind of self-educate themselves.

Rather than we are forcing a tutorial or we becoming the support team, we need to teaching them a lot of things. In the end, it's like, okay, the education just happened naturally. Mm-hmm.

It almost seems like Argo CD can be a higher level of abstraction above Kubernetes that makes the whole thing more accessible and maybe democratizes this so that I can have folks who are mere mortals running this back-end process. I do think so. No, definitely the Argo CD make the operate clusters in a larger scale way better, way better experience.

I do think the... Okay, we keep hear that, oh, someone is running one cluster, two cluster. They said, "Hey," they don't using Argo CD.

But I rarely, rarely see anyone, they are running more than five cluster, they said they don't using Argo CD at all. That's the trend, yeah. Mm-hmm.

So where do we go from here? You can't walk down any of the aisles at the show without somebody talking about AI, so how does AI get applied to Argo CD and Kargo and everything else that we're doing? That's an excellent question.

So as the Akuitie, we are actually providing the enterprise software delivery platform. So it's made of three capability. So Argo CD is powering our deployment, the Kargo is powering our promotion.

So we do have something on top called Akuitie Intelligence. So what does it do? It's actually a purpose-built AI agent, and for the software delivery operations.

So it actually observe your infrastructure in the real time, because as the Argo and the Kargo, we know what's going on with your infrastructure. We know the live logs, events, manifests, and deployment history, all the context we have. And then it actually interprets incidents according the people to the runbooks and operational context.

So we know when something bad happened, and then we can start to react to it. In the end, it actually taking corrective action autonomouslySo all those experience are actually built inside your Argo and Kargo control plane, which is the tool that people already trust. So we basically bring the AI experience directly into the Argo and Kargo, so people don't need to switch a different view or a different tool.

They can basically using Argo and Kargo, and they enjoy all the AI functionalities there. Mm-hmm. How will this all play out in your mind then?

Because as I look at it, each developer is going to have a bunch of AI agents, and they'll talk to each other- Right ... and other developers, and then the software engineering team and the platform folks will have their AI agents. How does all this get orchestrated at the end of the day?

What's going to be the thing that allows these AI agents to negotiate and kind of jointly accomplish a task and collaborate? I think it's, in the end is we feel the AI is a little bit mimicking about how human are collaborate with each other in the end. So everyone have their different mission and different goal there.

So means for the most of the developers, they are focused on doing the development. Means I'm writing the code, I'm reviewing the code, I'm getting something into build state. Then the platform team, the DevOps team, they are worried more about I want to deploy this successfully.

But also afterwards, because the applications are living creature now. Like something can be broken, crashing in a day later. Then how do you kind of like babysit those applications properly?

And also, security is a dynamic landscape, right? Yesterday, everything's fine. Today, okay, there is some security breach or CVE happening.

So there's a lot of the operational side about your application. That's why I think that there is a mimic about how people are working, is every side of the role, we are getting more efficient by leveraging more AIs and more agent, a purpose-built agent to make them more efficient in the end. A lot of people seem to be worried that the developers will now be generating such a high volume of code that it will overwhelm the CD systems that they have or whatever they're using to promote and deploy software.

Are we going to have to rethink this whole DevOps, GitOps- Yeah ... notion? It's a very accurate observation, actually.

So, we actually shared some data publicly last week. So last year, our customer did a 43 million deployment through our platform. I'm talking about our enterprise customers, not even just open source.

Open source will be billion for sure. Mm-hmm. We do see that was like 10x compared with 2024 because of the AI adoption.

So one of the observations really to the point is because of the AI, there is more development, more features, more fixes. There's more things getting deployed to the production, to your environment in the end. So I do think it does causing more like a problem in the deployment side.

That's why we need more automation, more guardrail. Mm-hmm. It's like, in the end is you want the AI actually also working for you in those contexts.

For example, you want to deploy something, normally it's a human review. You cannot review 1,000 deployment every day. But could you let AI to doing some risk assessment about, hey, this is what I'm going to deploy.

This is what is running already in your production. What is the diff? Then the diff is, okay, you just change the documentation, then auto approve.

Why bother, right? Just deploy it, that's fine. But are you adding five different new API?

That is lower risk, it's fine, because this is a new API, means not changing of the existing API, means the system should be still continue running even the new API has some glitch. It's fine. But okay, this is a massive refactoring.

You are changing some existing API. That is definitely a medium or high risk. " Maybe you need to babysit this for the next hour before you kind of sign off.

Mm. So that's where I see the AI can already help to do more automation together with all the automation tools we have. That's the exactly the reason why we added the intelligence on top of our deployment and promotion solutions here.

So what is the future of the role of the software engineer, and application developers for that matter? Because there's still a lot of conversation out there about AI replacing people, but doesn't seem like that's necessarily the case, but what's your take? I think it's still very dynamic and a fluid situation right now.

It's like I see the AI as being embedded everywhere, so people will find the right balance in the end. But I do think the AI, we are forcing the human to be more like a thinker, to be more like a leader, the leader of the agentic- Mm-hmm ... solutions, right?

So you are more like rather than you doing a lot of, I would say dirty job or low level thing, you are more like orchestrate the bigger picture. So what's your goal? How you breaking that bigger goal into 10 chewable steps to get there?

Then you are validate, okay, did the AI getting this done in the high quality or to your expectation? Then you are doing the checkbox of those thing. In the end, you reach your business goal properly or development goal properly.

I think that kind of forcing the human to doing more interesting job, to me, I would say, rather than, okay, what's the full loop? And how to reverse a linked list. It doesn't make sense to me, like why you spend time to writing those software?

And do you think also maybe that more organizations will build custom software because with Argo, we're making Kubernetes more accessible, and with AI, we're making it more accessible to do the coding. So maybe I don't have to be a Global 2000 to kind of build my own cloud native applications. I can be a mid-market company and succeed.

Yeah, I do think that the software could be more customized. There will be more customized built software... which I do think that will happen, but I don't take that as a bad thing for us, especially because we're thinking that Linux is a foundation for the operating system, Kubernetes is the foundation for the cloud operating system, and Argo CD is the deployment solution for all the Kubernetes, or for the foundation.

So what we are seeing that is, okay, sure, you're getting more customized software, but where they are running? So you still need to run on the Kubernetes, still running on the Linux, and you still need a deployment solution. Actually, you need the deployment solution more urgently because you have so many you need to deploy and manage.

So unless you basically are building a prototype you throw away, then you need to run it, you need to babysit it, you need to troubleshooting it. Mm-hmm. " I think the transition is already happening.

I talk with all my friends in Bay Area, Silicon Valley, so I do see their job responsibilities kind of being changing, I would say. " Spend three days on it and trying to get it done, right? Now, because AI is doing more heavy lifting on coding, so their job is more around coordination, about reviewing, validation, and having the bigger picture.

So I don't know exactly what will happen in the three months later, to be honest, even now three years later. I think things will keep changing. We are very excited.

My team is already adopting a cloud code in a massive scale. I see a day and night difference already regarding the productivity. Yes.

And I do know we be cautious about the quality, which I do think that can be addressed with more AI involved and a more experienced engineer kind of driving the process or driving the quality control on that. So it's exciting, but it's also changing, I would say. Mm-hmm.

So what is next for Argo CD and Kargo? As you look into the coming year, what's on your agenda? I think several things.

So we do think we want to still double down on the AI native side. I do think there are so many agentic, customized agent we can build for our customer to realize the value. Because I do think the platform team or the SRE team is on the relative conservative side for a good reason.

Because, for example, if a $5 billion business is running on your platform, so you do want to be very cautious about how you run it, how you control it, how you operate it. So I do think there is more deep dive, deep expertise agent should be built to getting more out of that AI experience to make more people more efficient in the AI and platform side. So on our side is also we want to making our Kargo solution to be very generic and universal.

Means we already kind of supporting the Terraform now, supporting custom stacks, supporting VM, but we also want to bring the nice developer experience to the VM user, to the Terraform user, to the serverless users, to make sure they're getting all the value out of the Kargo properly there. So definitely a lot of work to do still. All right.

Well, folks, you heard it here, Argo, Kubernetes, Linux, they're all joined at the hip. Hey, thanks for coming by. Thank you.

Have a happy means. Thank you. All right.

And we'll be back in a minute. Hey, everyone. We're back here continuing our live coverage from RSAC.

We are in Moscone West. We're facing out right into where people are walking, heading to sessions and keynotes, and so you get the live version of this. I'm going to continue speaking with Lakshmi Hansdal.

Lakshmi is the chief trust officer plus, plus at DigCert, and I think that's a great place where we're going to start. So I've heard of chief trust officers, but not the plus, plus. Tell us what's special about...

Well, what is a chief trust officer plus, plus? What is the role there? What are your responsibilities?

So within the industry, this is an up and coming role, right? And companies like DigCert have seen the need for such a role earlier than others. So just a bit, how do we consider the journey of trust?

And having been three decades in the industry, I've seen trust transform from a compliance checkbox to- Yes ... a competitive advantage. What excites me is when trust is treated as infrastructure.

Okay. It's the foundation on which everything else runs. So when we build it in every single layer, customers choose us, regulators respect us, and partners want to work with us.

And what that means from a role of chief trust officer is, I call it CSO plus, plus, and CTRO, so chief trust officer plus, plus, because the ability of the plus, plus is you have all the operational responsibilities. You clearly have the board mandate and the board responsibilities in terms of risk and protection, but you have two or three other responsibilities that are sort of unique. Because we are the voice of the practitioner.

If someone says, "Hey, we need to do this," and let's say it's one of the root programs, and that could be draconian. " The second is being a customer advocate. How do we enable our customers to be in the best trust posture possible?

Not just because they have access to a unified platform, but are they using it to the best of their abilities? And the third is in terms of influencing the industry thought leadership on how we need to be thinking about, we're going to be talking about quantum compute, we're going to be talking about AI. Some of these topics are scary for practitioners today.

They don't know where to start. How do we influence and give them some sort of mechanisms to start with? I feel this is a really good-- I was going to save it for the end, but as long as you brought it up already, let me mention it.

I mentioned it over at Techstrong Gang as we ended. We are debuting a new podcast that we're doing with Digicert called, The- "The Signal" ... "The Signal," excuse me.

From AI to Quantum. It starts, I think we're scheduled for April 16th is the first one. Lakshmi's going to be on it.

I'm going to be hosting it. If this is the kind of stuff that she just spoke about, this plus, plus, check it out. We're going to have it live.

Well, it'll be recorded, but it'll be on all your favorite podcast channels, whether you're an Apple or a Spotify or a YouTube person, or on Techstrong TV, or on our OTT channel, or on the Digicert websites as well. And we have a whole first season of runs that we're planning on right now, so I want to come back to that. Lakshmi, we spoke earlier about that "Harvard Business Review" article and you need to prepare for Quantum.

It was funny, in preparation for our interview today, I did a quick first Google search, and then, of course, an AI search of news here at RSAC 2026 regarding Quantum. And I was shocked by the lack of news. And I get the reason why.

The agentic AI is just suck- It's top of mind for- It's top of mind to bottom of feet. It's the whole thing. It's hard to get anything else in here.

But I know Digicert had some announcements, some things they're doing. Wanted to ask you about that, and then let's look beyond RSA and about what Digicert specifically is doing. Yeah.

So I want to say that there are a couple of changes coming at us in the next 18 months. Yeah. The cumulative of those changes outweighs what we've seen in the last 18 years- Years ...

Alan, and I've been in this industry for 30 plus years. So, I have not seen the volume of change and the compression of time, the shrinking- The velocity ... window.

Yeah. The velocity as well as the shrinking window in with these changes are coming our way. So a couple of things.

There are a lot of cryptographic agility changes coming our way. Certificate lifespans are shrinking. We need a better way to automate because this is no longer humans.

Organizations can no longer run on a spreadsheet and a prayer- No ... for lifecycle management. No.

The second is there are NIST standards. You mentioned quantum compute. We are finalizing NIST standards on being quantum safe readiness or readiness towards post quantum compute, and algorithms that help you get there, and adoption of those algorithms.

And the third is, of course, AI. Right. And agentic AI, identity at the core, assertion as enforcement, governance as foundation.

These three changes are coming at organizations all at once, so some of the messages are getting lost. The foundation for post quantum crypto or post quantum readiness, the way I see it, is cryptographic agility. And what does that mean?

It's not just to do it once, but the ability to do it again and again, but not rewriting your entire tech stack or redoing- Yeah ... your entire infra stack every time you need to make a change. Can't do this.

Yeah. Can you do it in a way that is more agile, but you help your business move with the velocity they want while preserving the faith of your customers? There's another issue here, though, and it's scale.

It's scale. We were talking earlier on the gang, and we had a fellow from Saviynt, and I had interviewed him before, and we mentioned some CrowdStrike data. I think- 160 million.

160 million. That's a drop in the bucket. That's true.

As sure as I'm sitting here, from what I've seen, and I'm like you. I play practitioner, do my thing with it. We are going to measure the amount of agentic AI agents that are in use within the next two years in the billions, if not tens of billions, right?

Because I think we're all going to have literally dozens of agents, sub-agents, identities that are doing our bidding. We saw this when we moved from human identity to the very first machine identities, right, with certificates. We saw a bigger explosion, IoT, the billions of the IoT devices that need-identity.

" Non-human identities, again. Right. And those are ephemeral because containers come and go in seconds.

That's right. We have been pressed to scale to that at each one of these points. Now we're at the next point, which is another scale issue of how do we identify, how do we manage the identities of billions of not only agents that are ephemeral, but they're intelligent, they're- They're learning ...

deterministic. Yeah. They're learning.

How are we going to do that? It's scary. Yeah.

How are we going to do this? So I think you said scale. Right.

There's sprawl. Yes. And it's scary.

Right. The three S's right there. Yeah.

Okay. This is another wave of technology, AI, agentic AI, generative AI, interactive AI, that is coming our way. It is going to be embraced.

It's our ally. It's going to be a year of efficiency for many organizations using AI as well. When we think about how do we get a handle around this while not being the office of no to the business.

No, you can't do it, because the business is going to continue, and our customers want to adopt it as well. I think a couple of things. One is don't wait for full visibility.

You can't protect what you can't see, but it doesn't mean you don't protect what you can see. Agreed. So start with what you know, start with what you have while trying to discover all the assets that are there, cryptographic assets, certificates, as well as your agentic workloads that are there.

And then the second aspect of this is prioritize it. Go after your crown jewels first, and then systematically go through the others. So it's a matter of rinse, repeat through every crown jewel asset that you have.

And the third is make sure that governance and oversight, what are these agents? How are they verifiable? Intelligent trust is about verifiable identities with agents, attributable assertions, as in what can they do?

Who you are, what can you do? How do I trust your output? That's the governance aspect of it.

If these three questions can be answered for every agent, ephemeral or not, then organizations can scale with AI within their enterprise. That's the hope. Let's hope it comes out like that.

Lakshmi, I have to apologize because we've got more people waiting to move in here. I want to thank you for coming. Thank you for being on the gang.

You were a lifesaver because we needed someone who brought what you brought to it. " Don't miss it here on Techstrong TV. We're going to continue with our coverage here live at RSAC.

We're in Moscone West. We'll be back in just a minute. Welcome to Security Boulevard, the cybersecurity podcast from the Futurum Group.

Each episode explores a variety of topics within cybersecurity and the technologies that drive it. com, the Security Boulevard YouTube channel, Techstrong TV, and all of your favorite podcast platforms. Let's meet today's panel before we jump into the episode, starting with Fernando.

Fernando, it's good to see you back from RSAC. Thank you very much. We're recording this shortly after the conference, and I think I have a little bit of con flu.

But it was so nice to see so many people in San Francisco last week, and I'm sorry for the ones we couldn't meet. But in this industry, we have tons of events, and there's always Black Hat starting to show up on our radars already. And before that, for the European crew, you have InfoSec Europe, which is also very nice of it.

And joining us for the first time on Security Boulevard is my good friend Jay Cutrill. Jay, tell everybody who you are. I am Jay Cutrill.

I'm the chief product officer at Nexus Tech. I deal with the product marketing and analyst relations part of the business. And last week, I had a chance to be in Raleigh Durham, North Carolina, for All Things AI.

So while everyone else was soaking up RSAC and Bsides and the wonders of security on the West Coast, I was holding down here on the East Coast. It actually turned a little chilly. But that was an amazing moment, seeing 500 people lined up outside the door trying to get into the Durham Convention Center and learn about All Things AI.

This was also, of course, during the, if you follow the stock market for the cybersecurity stocks, you may have noticed that little zip when someone said Claude or Anthropic or other Mythos model out loud, and the market did what the market does, sometimes overreact. So great to be here. Appreciate being in the invite list today.

Thank you so much. Market's overreacting? Surely not.

I've never seen that happen before. It's almost like numbers matter or something. Ooh.

Let's jump into today's episode because it came out of a conversation I was having with some people at RSAC, and it kind of cracked me up. So I'm just going to throw this out there, gentlemen. 76Does that number mean- You should have said 67.

6, 7 I could've said anything that wouldn't trigger my kids or any other combination of numbers. You're probably wondering to yourself, 76 what? 76 trombones is what you hear when you march down the street?

Big parade. Spirit of 1776? No, it's a score on my dashboard, and it says a thing, and that 76 is important, or maybe it's not.

" And I want to talk about the fact that all of these scores are hot garbage. They don't mean anything to anyone. " And I'm like, "Such as?

" So have you guys ever run into these things? I'm sure you have. It's a feature that everybody touts.

It's a big number. Oh my God, yes. And we run into these in many different ways, this quantification, gamification aspect of cybersecurity.

And there is a lot wrong with it, but there is also a lot that goes right with it. So I'm dying to get more into the topic. But I'll say this, yes, we've seen this forever.

Those of us who have been around risk management in any sort, we've been looking at those scores as a component of risk management decisions and with varying degrees of success. And there's so much to talk about. Jay, as we get to know each other, I won't monopolize the call too much, and I'll yield.

But I'm very excited about the topic. I just want to know what flavor of lifesaver that is. I'm used to the magic lollipops.

Sometimes you have the red lollipop, which I guess would be the cherry flavor, the yellow, which apparently is sugar plus yellow coloring, and green, maybe, I don't know, is that a light pine tar taste but ever so sweet? I think there's a false precision in math of saying, what is 76? Is 76 on a scale of one to 100, which I think we would all kind of assume, but I also have access to other tools that have a 200-point scale just to prevent someone from arbitrarily thinking 76 is a good number.

And you have to do math in your head to double that, and then there's 140, 150. Yeah, so you can tell I'm already bad at this. 152.

Is that good, bad, relative, indifferent? So that's the other part of this is, is it or isn't it good? Is it or isn't it bad?

Or is it or isn't it really telling us something that it's implied, but you really have to go into that second or third click? And if so, is the color misrepresenting? Is the number, by virtue of it being a number, effectively misrepresenting?

So I also am looking forward to a robust discussion around why each of us is right and wrong at the same time. And I think it's important to bring up, because you guys have already talked about some of the vagueness in this, you have to know the scale. As Fernando, my friend, the economist, would say, you have to label the axes on your graphs so you know what's important here.

But also, I love the stoplight system because to me, the stoplight system is one step beyond making it completely useless. Ooh, light red, bad. " And I feel like these stoplight systems or these risk score systems, at least initially, the idea was egalitarian, right?

There are so many inputs into all of these things that we have to figure out how to make it more digestible for the non-technical people. We have to find a way to take the various inputs, is this important, is this critical, is this something or other, and make it so that someone at a glance can go positive, negative, good, or bad. But I think that we've overstressed that system now that everything has to be boiled down to a number.

Well, is 76 good or bad? Well, that depends. Is 75 and below red?

Is 76 and above yellow? It's like when my kids get scored on tests because it used to be that 90 to 100 was an A, and 80 to 90 was a B, but now it's 93 to 100 is an A, and 85 to 92 is a B. And I need to know how they break down because a 92 could be both good and bad, depending on how I look at it.

And then the problem is that I know that as someone who deals with data all the time and as someone who loves to label the axes on the graphs, but I'm not the one answering those questions. " And so there's a lot that we can parse of this. I think let's take a many, not one, not two, but many steps back, right?

I think that fundamentally, we want to do these thingsAs a combination of we're doing decision support. Let's get this out of the way. We want a number, we want not even a number, we want the information because we want to make a decision.

Is this something that we need to act on? Is this something that we're not going to act on? What's our comfort level with acting on this particular thing?

And that is a perfectly valid need from anybody doing cybersecurity or IT or anything else. I joke that economics, here we go, is the study of scarcity. And the first rule of economics is that there's always scarcity.

You never have enough resources to do everything you want. How do you prioritize what you want? And then the joke is, so the first rule of economics, there's always scarcity.

First rule of politics, ignore first rule of economics, promise everything to everybody, and then you're good. Digression. But I think that the idea of having scoring, like I said, I see it as an element of decision support.

And I'm going to be optimistic in that I see this use of numerical risk scores as an attempt to elevate the conversation, which we need. We need to move the conversation at the board level, beyond red, yellow, and green. Beyond risk is high.

Now, my CISSP is back from many years ago, and I remember that we were doing calculations on risk score, like five plus three is eight, and that means it's a medium. That didn't make any sense. You don't calculate on ordinals.

And so I see this scoring as an attempt to do that. Now, there are two scenarios here. There are the scores that we see, there's a value to those scores as a progression over time.

I've dealt with many vendors who have, "Oh, okay, we have a risk score in your dashboard," and you can see the nice squiggly line, it's trending up or it's trending down. And that may be valuable or not, depending on what goes into that score. " I'm going to pick on the numbers.

Okay, fine. Does that mean it got worse? Why did it change to 67?

Did it change to 67 because the aggregate health of the devices dropped for some reason? So did the reason drop because the devices we have are weaker, are materially worse? Or did we add new devices to the environment that haven't yet been patched up to the level of controls that we have, and therefore they are weaker?

So again, meaningful intent, but the execution is kind of weird. But I'll say this, I remain positive in the use of more precise scoring. I'll yield the floor.

Jay, I'll come back later. Yeah. So I would say that there's things like a defense readiness kind of condition, the so-called DEFCONs.

And so you may be at DEFCON Cookie Monster, which is the five, blue, or you may be all the way up to DEFCON Elmo, DEFCON 1. And there was even a meme, if you remember back in the old Twitter days, where it was when maybe it was Department of Homeland Security or the TSA apparently had these different color levels of situational awareness for travelers. And it always seemed like we were constantly at a state of Elmo.

And if you're always at a state of Elmo, are you really at a state of Elmo, or are you just over Elmo'd out? And I'm not picking on Elmo specifically, but it's these conditional views that are entirely subjective at some points. " Well, how long can you sustain that effort?

Is that sustainable over a long period of time? And so I see some of these other interfaces, especially in security reporting, where you talk about if it's a numerical quantitative score, relative to what? If it is a quantitative score, relative to what?

If it is a qualitative score, do we all agree on the definition, what it implies? By the way, if we're culturally expanding beyond just, say, the United States or a specific country, is your sovereign country definition of how that color or story or iconography should be interpreted consistent globally and accepted? And one of the other things I was thinking through is, in the early days of the web, there was this common concern around the many dashboards that were being created because the web was moving so fast, you had infinite ways to think about visualization of data, and multivariate data, even more complex.

But a churn-off face is interesting. It's a provocative way to think about it. " Is the server happy?

And not a server in your restaurant, I mean a server probably in your data center. And if the server's not happy, should the front of the server have a churn-off face? And this was in the world of the physical kind of one-to-one, if you remember the pets versus cattle, this is a pet-type server.

" Is that enough? Or is it like, no, there's four or five of these that are really, really unhappy churn-off faces. How do you find those five and determine whether or not that's in the blast radius of whether you care or not?

Or is there an architecture that allows it or to permit it to run and then get remediated later? So I do see challenges both in the qualitative and in the quantitative that we spend a lot of time on. But I think even the qualitative measures are still challenging, like whether it's lollipop colors or what you think is the flavor of whatever is on...

Actually, you mentioned the traffic lights. I've never climbed up to a traffic light to try to lick the cherry red light. So maybe that's on my bucket list now.

But I do know that red, for me, means stop, but it might mean something else in a different culture. And I'm glad you brought up the fact that the scales that we've been using forever are always off, right? The DHS one that was released was comical because at no point were we ever lower than grade three, which was heightened readiness.

It's almost like the other things existed just to make people feel that- We were at Big Bird for a long time. Big Bird was a problem, right? Yeah.

Big Bird yellow. Yeah. And go ahead, Fernando.

No, I'm just going to say, I love to throw quotes at people, right? " Right? And Tom, I have a visceral reaction to you mentioning it never went down from something because the incentives in the system are misaligned in that it's easier for you as the creator of the risk score to report a higher risk, right, because it's safe, right?

And again, I go back to decision support, right? One of the best books I ever read on decision support is "Thinking Bets" by Annie Duke. I highly recommend it, right?

And one of the first things the book talks about is the notion of resulting. Humans are bad at conflating the result of an action. We conflate the quality of the decision with the quality of the outcome, right?

We don't control outcomes, we control decisions, right? And if you make a good enough decision, you maximize your chances of the outcome going your way, but you can't guarantee it, right? And she uses that famous example of the Super Bowl, where the, I think it was the Seahawks tried to throw at the one-yard line against the Patriots a few years ago, and the Patriots intercepted it and eventually won the Super Bowl.

And the outrage that people had against the coach. Well, but it turns out that that was actually the right decision given the circumstances. The outcome didn't turn out what they wanted, right?

But it's the same thing here. If people measure the outcome of a decision by the-- Sorry. Measure the outcome, tying that to the quality of decision, they're making a mistake.

And I'm sorry, I went off complete different tangent as usual. But Tom, you're right about the level. It never went below something because it didn't make sense for somebody.

Somebody would be safe reporting that it was a high enough level. And we deal with this all the time in a lot of things, right? One of the things that I remember when I first started working with these monitoring systems was the fact that we had to turn off memory monitoring.

" And it's always going to be red because, ooh, it's above 90%, therefore it has to be bad. No, I would rather it be 90% because then that means it's being used efficiently, or things like that. And one of the problems that we always run into when we're doing that is, again, we know context behind things.

Another way to look at this is, one of the original things that made me think about it was CVSS scores, right? 5? And you're like, "Oh my God, that is absolutely horrible.

" Wait, this only happens on a really random product that was sold in a lot of 100 to one company in Antarctica. But if they could get into it, it's really bad, therefore it's a 10. I'm like, it's a 10, but the likelihood of it happening is a two.

There's no context behind that. Likewise, oh, well, that's a six and a half. That's not a big problem, except it's a problem on every device that's been sold for the last 85 years.

You got to patch that. It's giving people this false sense of security when you publish a score and you're like... Because let's be fair, if you went to RSAC, you walked through the booth, I should have just taken a picture of every, like, "Uh, score says 74, you're okay.

" And just the usual, like Jay said, is that a scale on 100, 200, 1,000? Is it another mathematical calculation? Is that graph a logarithmic graph?

We have enough problems with people who don't understand math in a daily basis. Thank God none of them work in finance. They all seem to work in the executive, though.

And when you get to security scores, they really don't care. What they want to hear is, "Everything is fine, and we're not going to get hacked. " And if then that does happen, they're going to want to know why, and they're going to need details.

Which is why every one of those numbers, when you click on it, should produce a report that says, "You're not at 100 because your CEO's password is bad. " If you can't provide even just baseline context for people, then you're doing them a disservice, because again, number must be good because number green. God, yes.

And yes, and I go back to conversations I've had with vendors in the past. The composition of that score is absolutely essential, right? I remember being particularly peeved at the vendor whose score composition was the number of endpoints that had their product installed.

Yeah. Not the number of endpoints that had endpoint security installed, not the number of security, the number of endpoints that had endpoint configured. The number of modules of their offering was a component of that risk score.

Right? I'm sorry, that's a pre-sales thing at best. Right?

Mm-hmm. And so those scores are extremely confusing, right? And when I work with vendors, I go, "Look, we are trying to help this industry overall reach a higher level of maturity on these things.

That kind of score that you're doing does not work toward that. " Not only because it is the right thing to do, but because we are seeing people, there is a movement, there's an entire movement in this industry of getting better, right? And I would be remiss if I didn't call out the phenomenal work that SIRA, the Society for Information Risk Analysts, SIRA, does.

I was a volunteer at SIRA for a long time, and I absolutely love the organization. Right? And with that comes significant knowledge that is being shared in terms of what does good risk management look like, right?

So anyway, I'll refrain from- But that's a good point, is going back to what you said. These people deal in risk all day long, and so sometimes they have to quantify that risk. And that's- And they're being paid to work at it.

But what does the quantification mean? It means that they have plugged a bunch of information into an algorithm or to an equation, and the number at the end is effectively normalized. And that's important within their context.

So when you talk to one of those experts, they know the difference between an 85 and a 74 and can tell you what could cause that to happen, especially when they look at the other parts of the data and go, "Well, that's really interesting because this number is very out of sequence with what I would expect to see in a company that has a score associated with that," which would cause them to do investigation. My problem with all of this risk score stuff is that you have effectively dumbed it down to the point where nobody has any context for anything, and you like it that way because you need to sell training or professional services to help them understand why the number is the way that it is. " Okay.

You had mentioned earlier that we tend to be bad at math, and if risk is another way of saying that you can quantify or do the math, then it also means we're kind of bad at quantifying risk. Mm-hmm. And so even if you go back to the-- It's an acronym, FAIR?

Yes. Right? That means that there's some kind of a factor that you have done analysis on, and from that point of view, the information you're talking about, you've determined risk.

" But on the other hand, it's $10 million of risk. And I guarantee you that someone's going to understand the $10 million of risk. They won't care about the 100 whatever Linux things.

It just, p**f, goes right over their head, right past them. The question then becomes is, are the vendors supporting and driving towards something more like FAIR, or is a proprietary view and visualization within their product experience going to perpetuate a renewal? Are they really just thinking about like, "If I can get you to adopt this thing, I know you can't get off me now.

" And because everyone's learned what 76 means. 76 means exactly what it means to you in your company because you have used my product for so long. So is the 76 also kind of an entrenchment, digging in?

Or if you could get away from 76, going back to the 76 example at the beginning of it, does that mean that maybe that there's interoperability or shared understanding of how relative risk can be summarized amongst different disparate vendors that ultimately make up what might be that dashboard of doom for the CISO? And Tom, may I say that if I'm ever not available for economic commentary, Jay here just brought up switching costs, so thank you very much, Jay. That is spot on, right?

But I'll go back to something. I think that this is positive, like that the overall movement is positive to move us fromFrom a heat map, to move us from a color, into something more defensible from a statistics perspective. And I think that we are seeing more risk management practitioners get their word out there.

I'm going to do a shout-out to both Richard Syerson, who wrote the "Metrics Manifesto" back in 2022, I believe, as somebody who's been doing some phenomenal work on this. As well as Tony Martin Veigh, who has a new book called "From Heat Maps to Histograms" that should be coming out this week, actually. So I'm eagerly waiting to take a look.

And both Tony and Richard have done phenomenal work in the context of CERA, of doing precisely that, of helping to find common ground between environments. At least from where I stand right now, what I see as the best approach we've come up so far at that highest executive level is something that Richard has advocated, which is something similar to value at risk. Which is the notion that you build your security controls using FAIR or other mechanisms, or other methodologies.

And you come up not with the number 76, which I still think we should be using 67 as an example, but that's okay. And the number you come up with is that, look, given our current risk profile, there is a 5% chance that this organization will see a loss greater than $8 million in the next year. 5%, $8 million, there's the curve.

Is this number acceptable to you, dear board? " Okay. In order for us to bring this number down, what number is it?

Is it the $8 million or is it the 5% or is it both? Okay. We want you to bring this down to 2%.

Okay, if we're going to bring this down to 2%, here is the set of controls that I need to put in place, and not only the controls in place, but the operational practices that we have to have in order for this number to come down. But that is a much more sophisticated risk conversation than 76 or 67. Right?

When you mentioned that, it took me back to the '90s. There's a TV show, "Saturday Night Live," here in the US. Oh, wow.

And now there's an export of that, I guess, to the UK. They're going to do "Saturday Night Live UK" now. Yep.

" Pre-tapes are when you have a figurehead, speaker, whoever is the anchor, they're going to go on vacation. And if they're going to go on vacation, there might be some things that are very likely to happen where you want to have something in the can just in case, like key legislation passes- Yeah ... someone passes away that's on their deathbed.

Very morbid thing sometimes. But you do the pre-tape so it appears as though you're still there and available even if you're on vacation. So in the skit, when you go through that, you watch this, I'm going to give a spoiler alert, it's hilarious.

There's also some not safe for work things, so don't watch this at work if you're in a sensitive environment. But it does highlight that if you have these systems in place, what happens if you do have people that go on vacation? Is there only one person that really intuits or understands?

Or again, is this more organizational? If it's organizational and we have common understanding, I think that's great. But I also think as you go through different parts of the organization, you may have different levels of, this is very high risk from my perspective, but from my perspective in this other part of the organization, that might, for the same exact event or concern, might be very low risk by comparison.

And so that's another important context is, how are we surfacing these numbers? And I like 67 now that you've convinced me of that. Is 67 the same 67 awareness in different parts of the organization, in the topology, or is it really only ever going to make sense, is the 67 really only 67 just for the teams in security?

I think we could spend another half an hour just debating all of this stuff. I think what needs to happen is if you're out there and you're listening to this episode, go to the vendor and ask them where the number comes from and why the number is the way that it is. And if they can't justify the number, then they're probably just making it up out of thin air, and maybe it's time for you to do a little bit more investigative work.

I know that we just got back from RSAC. You're probably listening to this episode a couple weeks out from RSAC, but just know that we've been putting a lot out since then. Fernando, what are some things that you've got coming out that people should check out from maybe from RSAC or maybe more in general?

Yes. By the time this comes out, we'll have our main note out on the conference. I also use the conference to inform a lot of our research, of course.

And related to this topic, so the whole topic of cyber risk quantification, very close to this is third-party risk management. That is something I'm going to be digging into over the next few months. I love how we are maturing these disciplines.

One of the things, for example, that we're doing is we're starting to take, related to this course, we're not talking so much about what is my outside in view. " It's like, okay, what do your internals look like? The inside out view, and then start to put those together.

But sorry, I digress. I think that coming over the next little while is, Tom, you and I have a report out on secure access service edge that should be out momentarily or next few days, weeks. Outside of that, we have a refresh of our security operations signal report that's going to come out in the early summer.

And then, as I said, a few months from now, I'm diving deep into CRQ and third-party risk management and other areas. So I'm really looking forward to that. And Jay, I know you've been producing a lot of content as well.

If people want to check out some of the stuff you're doing, where can they go to learn that? Yeah. org.

org, my blog there. I also have newsletter content, as well as a podcast. I'm on my third episode of that.

I'll also be at the Click Connect for 2026. I'll be with Brian, Frederick, Gina, and others there again. This will be my third year.

This year's going to be exciting because the element of AI reproducibility, security, validation, trust in the actual AI experience will be top of mind. So we're well past the training wheels phase. People are producing this stuff now in a production environment.

So I'm looking forward to those stories as well. com because we have great videos that we've published regarding our Tech Field Day Extra at RSAC presentations from companies like Veem, Object First, and Commvault. com because we'll be highlighting all of the coverage from our delegates that were there.

They have some interesting thoughts. " If you enjoyed the conversation, do us a favor, subscribe on YouTube or in your favorite podcast application. We don't want you to miss any episodes.

Also, leave us a rating, and a review, and a comment. That always helps the show grow and reach new audiences. com and the Futurum Group.

com is the place to go. You can also head over to the Techstrong TV website or check us out in the Techstrong TV app that's available on Apple TV, Roku, and other smart devices. Follow Security Boulevard on X, Twitter, and LinkedIn.

They are @securityblvd on all those platforms. Lots more content for you to enjoy. Thank you very much for tuning in, and we'll see you all next week.

The modern world of networking relies so much on data that we need every available bit we can find. Telemetry is king, but where are we going to find more sources? In this episode of the "Tech Field Day" podcast, networking needs more telemetry.

Welcome to the "Tech Field Day" podcast, where we bring together a group of IT technical experts to discuss a single idea about key concepts in the industry. This podcast features a variety of perspectives from members of the Tech Field Day delegate community and is often associated with one of our events. Tech Field Day is part of the Futurum Group, and this podcast is also published on our sister company's website at Techstrong TV.

In this episode, as we head into the very jam-packed Networking Field Day, we're going to be discussing telemetry. But before we do that, I want everyone to introduce themselves before we get going, starting with Jason. Hey, thanks Tom.

I'm Jason Gennert, and I'm with the US Networking User Association, also a consultant with Bits in Flight. Longtime technology aficionado. Started in math and then discovered networking and coding and all sorts of other goodies.

Hi everyone, Scott Robohn. I'm a founder of a consulting company called Solutional and a co-founder of the Network Automation Forum. Internet plumber for a very long time.

Very excited to talk about the topic at hand today, Tom. Well, we're very glad to have you all. Of course, I'm Tom Hollingsworth, Event Lead for Networking here at Tech Field Day.

Let's get into the episode. There's no such thing as too much data, and when it comes to network monitoring and management, the more data you have the better off you are. But where are we going to find all of this data?

Because after all, we've been mining all of our networking equipment for a very long time. But as it turns out, networking equipment is not the only source of truth in your enterprise. The premise for this episode is that networking needs more telemetry.

So let's talk about why this is, because I can remember a time when it was very magical that I could extract NetFlow records from a device. " But anyway, what happened was is that we got a lot of really cool information about a lot of flows in the network. But one of the things we learned was it's kind of hard to ingest all of that.

Fast-forward to today in 2026, and I have collectors and things that can ingest massive amounts of data. I just have to find it. So where are we going to come up with all this extra data that we need, folks?

Can we start with the need? Let's push at the premise a little bit. Why does this even matter?

Well, a long time ago in a galaxy far, far away, we didn't really care about real-time response from the data network, right? And we were okay with RIP having 30-second update intervals and maybe not finding a route missing for three of those intervals or 90 seconds. And then we decided that link state protocols were really helpful to help identify those things very quickly.

And over time, we've moved much more to the data network, to the IP network. We've done some things, moving from just SNMP to NetFlow and now beyond, because I have much more mission-critical traffic and more traffic that's very sensitive to human interaction and meeting human expectations. Live voice is the easiest example, but we're doing much more than that on the IP network today.

Hence, we have to be able to measure and respond to things much more rapidly than we did 20 years ago, 30 years ago. I'd like to add a perspective to that, which is, I think networking people, we've learned to be sort of jacks of all trades. There's physical error.

There are all these things that go into networking, and it's not sort of pigeonholed. And what we're seeing now is we have to support networks that carry all sorts of critical data, real-time interaction and whatnot. And networking people are kind of, well, to some extent, security people as well, but we're the people that know about flows and about all these other applications and things that are going on, storage and Wi-Fi, and just across a whole set of technology boundaries.

And if we don't have visibility into them, then we get these strange trouble tickets that something isn't working right. And we have visibility on the network side, but without very broad telemetry, we have nothing telling us whether the storage array has gone bonky or something like that. And I think my opinion is now we have more capable devices that can get us this telemetry too.

If you think back to at least back when I started in my career, I could drop a router with overzealous SNMP polling. So I don't know if anybody else has-- Yeah, crash the CPU. I don't know if anyone else has had that experience, but I definitely have the bruises from those.

Nowadays, there's dedicated ASICs that can provide a lot more data, and the architectures of modern network equipment, and the horsepowers, the raw horsepower of a lot of the modern equipment can provide more data. So I think as we've seen cloud scalers adopt and need more of this data to run these gigundous architectures that they're responsible for, I think we've seen the needs for them to have more data and be able to ingest more telemetry, so all those capabilities have grown over time. So seeing that come down to the enterprise, and being able to ingest that data, normalize it, and have it be useful for the rest of us, because cloud scalers are, a lot of them are solving unique problems that the rest of us don't deal with typically.

Being able to adopt those, I think it's time, and we need more of that. You triggered a thought about massive amounts of data. Namely, I'm thinking of the company Kentik, which uses cloud storage because their customers are just storing amazing amounts of data across a whole lot of fields.

And their reason for existence is to allow monitoring of mission-critical, business-critical application performance, among other things. A lot of data to sort out, however. I think it's interesting that you bring this up because this is a conversation I was actually having with Andy Laptev over at the "Art of Network Engineering" podcast, who's actually going to be a presenter at Networking Field Day.

And one of the things that we talked about was this idea that we can do so much more with networking equipment. I remember taking the Novell TCP/IP exam, so I have now officially dated myself. But one of the ways that they were describing routing protocols in that very simple test was OSPF is a, quote unquote, "expensive routing protocol," meaning that it requires a significant amount of processing power in order to run.

Because back then, as I've jokingly said, routers had the CPU of a pocket calculator. And we were lucky to be able to install even a portion of the forwarding table in the CPU. And for a server that was already tasked with doing eight other things, RIP is stupid simple to run, and it doesn't incur a lot of overhead.

Now, today, thanks to the advent of things like ARM processing with DPU offload and DPDK programming and things like that, I have multi-core CPUs that are quite literally sitting around doing nothing at idle, which means I can collect and dispatch data a lot more efficiently than I used to before, which means that I'm now starting to think about the richness that I can provide from these devices to be actionable. And it's also because, like you said, of hyperscalers. One of the things that I learned many years ago is that Facebook had developed their own switching infrastructure running on Linux, partially because they had developed a telemetry system running on Linux, and they wanted to be able to integrate the data that they were getting from their network with the data that they were getting from their servers.

Because as we learned a few years ago when Facebook took a nosedive, they were using networking protocols to provide availability. They were using BGP basically to say, how's everything running? They didn't trust it as the sole source of external routes, but they were doing other things with it because they could, because they had built an infrastructure around that homogeneity from a processing system.

So as part of what we're able to do now with telemetry, because we stopped building purpose-driven devices that were running custom silicon, and we have effectively built everything on the same ARM processors from organizations like Broadcom, where everybody feels like they're doing the same thing. Well, don't forget that... And sorry, if you're implying this, let's tease it out a little bit.

Remember that that separation of control plane and forwarding plane has been a huge enabler here. Right? And we can keep the hot stuff hot and the cold stuff cold.

Right? Forwarding ASICs can do the one gig and the 10 gig and the 100 gig and the 400 gig forwarding, and the control plane just needs to worry about the right protocol packets to deal with. And that architectural separation has led to a really interesting talk from a Google researcher just a couple of months ago at NANOG in February, where he's basically putting an instance of the SDN controller on each router.

More information on how I should route stuff across my network, with lots of inputs, including this telemetry stuff that we're talking about. And it's important to realize that when you think about those kinds of routing protocols, we had to make massive adjustments to the way that they operate to get them to do the things we want it to do. Anybody who's ever taken a CCNP or CCIE level test knows that there are certain conditions that would cause routing protocols to not be able to run the SPF algorithm in enough time to do things.

That's why EIGRP has feasible successors that are ready to be installed in the routing table. It's why, according to my good friend Narvik, there are only a couple of things in the EIGRP equation that are turned on by default. It's because it costs so much resource to run those things that we couldn't do it.

But now, talk to anybody who works at Facebook, and they're like, "Why is the hello packet 512 bytes? " But now they're looking at the possibility of ingesting all this additional data to do so much more that's actionable. But at the same time, we have to remember that processing is not a free action.

This is not like a fighter's bonus action in D&D. You have to make the effort, which means you are adding overhead. And so is that adding of overhead a free action because we have so many spare CPU cycles now, or do we still have to plan for all of this telemetry and not integrate it into all of our decision-making processes?

I think overhead is a good word for it, but I'm thinking human overhead. You can get lots of data now, which is a good thing, but it can sit there and fill up your disk and create expense unless you have some way to monitor it. And I've sort of experienced this a couple times fiddling with an Elk Stack and fiddling with the Kentik product of, okay, there's all this data out there.

What do I care about? Who's going to tell me what statistic to apply to it? How do I munge this data into something that's meaningful in terms of reporting?

And that's kind of a challenge. Networking people are good at a lot of things, but I'm not sure many of us are data scientists. And enter AI, right?

I know Tom's probably- Yes. Oh, AI is not a- He'll probably wince it. Here we go.

minutes past the hour. We made it 20 minutes. Yeah.

No, but really, if you look at the promise of AI, and that's being able to sift through gobs and gobs of data, but at the same time, there's a consideration of context when it comes to AI. So you can have too much data and you can overload the LLM with... So you're going to have to somehow distill down all of this telemetry data into something useful, even for AI or whether you still have humans looking at things in the loop.

So you can have too much data. So to have a counterpoint, there is such thing as too much data, especially if it's not structured properly, it's not refined properly, it's not consolidated, and distilled down in a useful way. But there's an important distinction here that I think you're both moving toward.

I'm not storing all of this data on routers. I'm actually not storing the majority of this data on routers, whether it's Kentik or other emerging solutions like Selector AI. There are offline systems that are putting all this stuff in one place, whether it's streaming telemetry, SNMP, and other sources of info, so that LLMs and other AI tooling, and even good old statistical regression, can operate on the data in one place.

And so there's this necessary complement now of, you want more telemetry? That's great, and you can use it as a superpower, but I'm not going to be chunking through all the data on devices in the production network. There's a learning curve there.

I think you need somebody who has the time to experiment with pulling statistics on the telemetry, looking for anomalies and stuff like that, and then you can start looking at correlating anomalies and some of the other things that some of these companies are playing. Or you can bring in a company that has already been there and done that, although I get the impression one of the first questions some of them, like Selector asks, is, "What do you really care about? " Always a good place to start.

But that's been the problem for the longest time, is sampling. When you're dealing with gigabit links and 100 megabit management interfaces, I can't send every copy of the telemetry of every packet over that wire. I will clog it up.

Likewise, the collectors that were running on 7,200 RPM hard drives could not process the data fast enough, and so we resorted to sampling, like every 10th packet or whatever the sample size was. But today, we have the same problem with more zeros after them. Because we've seen with the rise of things like rail-optimized architectures, that when you're pushing terabits of data around with tail latency being a super critical statistic, you can't wait for that data to come back.

You can't make decisions based on things that are even three or four seconds old because that could cost you hundreds of thousands of dollars in GPU idle time. So can we even use these types of telemetry offerings to make better networking decisions knowing that we're still in the same boat where we can't get enough data fast enough to process it to be able to make these decisions in the hope that we're not going to get fired because that fancy GPU cluster is just sitting there spinning fans. And spinning disks, when they used to spin.

I think Pete has a great point from the data science perspective. Now, I think, Pete, what you're calling data science is really going to be data engineering, right? Where I don't need all the data science skills, but I do need to make sense of the piles and piles and piles of additional telemetry that I'm collecting in a way that might not be fundamentally going after the basic science of it, but the engineering principles around certain data sets, and how do I use them for actionable intelligence.

Javier Antich, who's leading at Cisco in some of the large-scale adoption of this, has written an interesting book, but he goes back, ties a lot of it back to, well, there's AI, but a lot of this we may need machine learning or other approaches. So don't just frame the data problem as being solved by AI. It's a whole slew of techniques where we try to apply the right tool as the data comes streaming in.

It's not going to be real-time, so maybe we're backseat driving, so to speak. But real-time is going to have to be handled on-chip and adjusted. What we're looking for is smoking guns saying we need more capacity, or we need to change something about how we built the network.

I hope that we can provide that, but I also know that we have reached a point in our society where there's an immediacy bias, right? I don't care what it is, I want it right now. The people that order everything from DoorDash because they can't be bothered to go out and get it, that want to know up to the minute, up to the second, what's going on in the news, or instant scores delivered to your mobile device via push notification, and now you're telling them it could take an hour for me to figure out how to do any analysis on this data?

No, I want to log into the dashboard right now, and I want to see where the problem areas are, and I want to fix them. It's that whack-a-mole problem that we've always dealt with, right? It's like, oh, well, we need to increase the bandwidth between these two cross connects, and then when you do that, you're going to surface more problems over here.

And then you're constantly going to be chasing that rabbit all the way through your network and constantly upgrading things that really honestly don't matter in the long run. Because I think what the value of having more telemetry data is, is that you are able to uncover the problem areas before you fix the wrong symptom. So, oh yeah, we're seeing slowdowns over here, but it's not because of the link between these two devices.

It's because the amount of data that's being pushed between these two servers is more than we should be pushing, so we should work on the algorithm that decides which data needs to be shared, not adding another colo link that's going to cost us an extra $10,000 a month to plug in two routers. People get so wound around the axle of got to solve this problem right now, got to fix this problem right now, got to keep these things humming, got to keep this going. Not every problem in networking is an F1 pit stop.

Some of them are things that we have to solve in the lab with computers and modeling and stuff like that, and we can't just throw things at the problem until it goes away because that's how you get a Franken car, right? Well, I see that as part of the virtue of getting a lot of data is if you can correlate stuff where you had spikes at some time or some phenomenon that occurred, then you have possible causes. And the more data you have, oh, okay, the application went slow, but here's what was happening at the same time the application went slow, the better you're going to be able to solve the problem quickly.

Right. I do think, and not to make any specific technology provider plug here, there are systems evolving that aren't just using LLMs, right? But if you look under the hood, they'll use machine learning for pieces of the problem.

They'll use on-chip processing for other pieces of the problem. They'll still use statistical regression for other pieces of the problem, and LLMs for not just finding the needle in the haystack, but the needle in the needle stack. And I think that's the problem with 10X-ing or 100X-ing the amount of telemetry we have to plow through.

It's beyond the limits of human cognition, right? We can use LLMs that are really good at pattern matching to be able to get to the relevant info fairly quickly. Yeah, and I've seen some interesting use cases for LLMs, like overnight processing.

So, when operators come in in the morning, they have this detailed report. Here's what happened last night while you were sleeping. I think that that's a great use case because it has all of that time to kind of crunch through all of that data.

And again, it comes to that distillation of taking all of it and turning it into small, useful nuggets that people can use. So I think of applications like that where LLMs are particularly useful. Another thing that's sort of outside that box that I'm thinking of from experience is when you are trying to scope out an application, be it for security, performance, or other purposes, quite often it was maybe developed outside by consultants and they threw it over the fence and people inside are trying to support it, but people don't know the flows.

And if AI can just tell us who's talking to who, where are the boxes, and piece together some of that basic information, that's not classic telemetry, but it's just kind of what's going on here. Obviously, the answer is yes, we do need more data, but we have to be selective about how we do it. We have to make sure that we're providing the systems with the right kinds of data.

Anyone who's ever deployed an intrusion detection system knows putting one on everything is not the answer, because you're either going to get completely overwhelmed that you won't be able to do anything, or you're going to get so annoyed you block all of them. So if you had to give advice to the networking team that's about to do this to increase the quality of the data that they're getting, what's one thing that you recommend that they look at in order to make things better overall? I'm going to use this to maybe reinterpret your question and say, I think you have to look at the system holistically.

And I'll go back to Pete's comment about the network engineers tend to be the jack of all trades, master of none, and we have to understand application behavior, right? Because that's what's impacting networking performance, right? If we didn't have any users, by the way, the networks would be great.

But I think if I boil it down to one thing to really answer the mail from Tom here, think about how all the pieces connect together, application performance, security, network performance, and any other adjacent information. And I think AI is bringing a set of tools that are going to help us bridge those silos and look at telemetry and performance information from those domains that have been necessarily treated separately for a very long time. That has implications for how people handle-- You need to make contacts at work that are outside the networking group.

IT, in most companies, is kind of stovepiped around specializations, and maybe that has to change. Or at least make contacts and be able to sort of cross the boundary and speak a little bit of the other guy's lingo. I would encourage one to make sure that the data they're getting from the telemetry they're using is clean, and you don't have things like duplication.

So I've actually been in situations where you're double counting things, so all your numbers are off because you're like, "Wait, this is not adding up to what I'm actually seeing on these interfaces. What's going on? " Really, trust but verify.

Make sure that the data that you're getting is really what you expect to and make sure that you're using it correctly. Been there and done that. I was helping a company try to analyze a mainframe-based major application.

They'd spent a million dollars on upgrading this application and wanted to demonstrate to management that it was worth it. And so I was working with people who weren't fully aware of all the flows, and we went to scale it up. We got some pretty good data on the flows at a certain test level, capturing packets and so on.

And then they went to 10 times, but the amount of traffic didn't increase, and it was kind of like something's caching or we're missing a flow here. So comprehensive view is always in the back of my head that people aren't necessarily aware of all the things that go into applications. And then, yeah, if they're not aware what could be making it slow, then sometimes troubleshooting can be a real hassle.

I will wrap this up by saying I think it's very important that people understand that while more data makes everything better, all the data doesn't make it the best. You have to be very selective about what you're looking at, and as you've all brought up, have a holistic view, be very careful about screening out duplicates and things like that. Because even the best system in the world can only operate on what it's been given, and if it makes the wrong decision because it has an error in the dataset, then you're going to be chasing a lot of ghosts through your system before you finally figure that out.

And the way things are going now, that could be something that has you creating a resume-generating event. I want to thank you all for joining us today on the "Tech Field Day" podcast. Before we go, where can people connect with you and continue the conversation, Jason?

Yeah. So LinkedIn is a great place. I typically engage there.

I'm most active there. com to read more, a bunch of blog posts and more about what I do there. I'm on LinkedIn.

Should be easy to find me there, and I stick with LinkedIn because it seems to have less noise than a lot of the other social media. com. All right.

Well, thank you all very much for listening to this episode of the "Tech Field Day" podcast. If you enjoyed this discussion, please subscribe on YouTube or your favorite podcast application so you don't miss an episode. And we would love it if you would give us a rating and a review and leave a comment because all of those things help us reach new audiences.

This podcast was brought to you by Tech Field Day, the home for IT experts across the enterprise, which is a part of the Futurum Group. com/podcast or find us on Techstrong TV. Thanks for listening, and we will see you all next week.

Cool. Hey, everyone. Yeah.

So this is the final segment of our session, and it goes around that wheel of understand, secure, resilience, and now unleash. I'm Michael Cade from Veeam. I'm a field CTO.

I've actually been here 11 years today. Yeah, I've just worked that out. Unleashing data.

So from a leveraging data point of view, we've been doing it, enabling our customers to spin up from backups for a number of years. Where we're going in the world of AI and understanding that data and contextualizing that data to be able to use it, either from a production point of view, so you've been more hygienic with that data, you know what it is, to being able to protect it. But then what about using backup data to leverage that againstAgents or being able to get insight out of that data, which has always been our premise, right?

Being able to leverage data that you've taken from a backup point of view. It sits there for a retention or for a bad thing to happen, and then it's used for a recovery. Actually, we should be able to use that data.

It sits on pretty good storage. We don't have that much bad storage out there today. So performance-wise, we should be able to use it.

We should be able to spin it up and use that data. So there's three areas that I touched on. One was that leveraging of data.

The second is how are we using AI to help enhance our users, our administrators' world from a backup point of view? How can we make their life easier? How can we make the backup is boring job a little bit more exciting or easier so they can spend time building out these sandbox environments with data?

And then the third one is around, well, okay, now that you've got the ability to understand that, how can we learn about AI systems that are being used across the business, across the environment, and make sure that we're putting some governance across that? So we all know these numbers. I think we've touched on them.

In terms of data growth, garage to garage, you'll only get that analogy if you're in the other session, so you'll have to go back and watch those. But the growth of data is expanding. We know that AI has a massive impact, and we need to have good, clean, understood data or hygienic data.

You've heard the term garbage in, garbage out. But equally, we've got a lot of our peers within businesses are just uploading files to any model. ChatGPT, they're dropping Excel spreadsheets, et cetera, sensitive information, and really there's no governance, there's no regulation around that.

There's no one really stopping that. I'm sure we're going to see a lot of RSAC suggesting that they're doing something similar. So the first point is how are we as Veeam enabling our users to take advantage of AI, and that started with a chatbot.

I think every software company in the world started with a chatbot, right? You interact with your help center or your documentation. Tell me how to do this, and it gives you that back.

It goes and gets the information from the help center and then gives you a natural language response to say, "This is what you should be doing," or, "Perfect," or whatever the response is. The evolution of that over the last nine months for us around Veeam Intelligence, we call it Veeam Intelligence, so it still is a natural language chatbot system. And it has access to that documentation.

But equally, it has access to your Veeam environment. So now you can query that, and instead of going and building out custom reports based on the backups that you have and the recovery and the access and all of this stuff, you can actually create your report inside of this Veeam Intelligence chatbot and get some immediate insight into that environment. Tell me all the backup jobs that went wrong last night.

Tell me if there were any malicious activity across my backups to everything that Emily was saying about those security integrations, versus having to visualize it or go into an observability tool such as VeeamOne or any of the other SIEM or SOAR tools that Emily touched on, being able to actually just you log in in the morning, just ask it some questions. How did everything work last night? Rather than having to go and create and see and visualize all of that stuff.

Equally, and I'm going to touch on a little bit around MCP as well. So there's many different MCP servers that we've built within Veeam. The one that I'm going to demonstrate is the ability to interact the Veeam Intelligence MCP, which is exactly what I was just talking about, being able to query in natural language the status of your Veeam environment.

But couple that with other MCP servers. Maybe it's a ServiceNow MCP, and now you put them together, and now you start to get a ticketing pipeline to that as well. So exactly that.

So using Claude Desktop as an interface and maybe MCP, and we'll see a lot more this week around MCP. As a protocol, it's definitely blown up in the last 12 to 18 months. But I feel like from an MCP perspective is that could this be how we interact with software over the next course...

And MCP is one protocol. There's also A2E, which is from Google. But is this a better way to encompass all of the ways in which we visualize and manage our environment?

So like I say, a very simple demo. We're using the MCP protocol to hook into our Veeam Intelligence, and we're also using the MCP to hook into our ServiceNow. And we're going to couple those together in the next demo to show how we're blending that together.

But you could bring heaps of MCP servers into this workflow. It could be bring a security MCP, and then suddenly this Claude Desktop and other MCP clients are available. But you can start to potentially see how this becomes the interaction, this becomes the UI of how we day-to-day manage our environments.

Does this play? Okay, so we've got a prompt here. Good morning.

What does my Veeam environment look like today? What do the backup jobs look like, their state, run duration, any warnings? Are there any given alarms?

Give me a nice HTML report. So this is me just interacting with the Veeam MCP. You see it's going along, it's got all of the information.

And suddenly over on the right-hand side, not-Everyone's seen an AI-generated report, but you can see that we've got an exec summary, a very nice coffee dashboard report just telling me what happened. I don't have to click ups through all of the Veeam stuff. You can see that I've got a good understanding, color-coded for those that can understand the traffic light system.

Recommendations about, okay, how can we go and fix? What are the first jobs that I need to do today? But then based on that, I've got a ServiceNow MCP also implemented here.

So I can take the issues that we found and start creating incident numbers and incident cases and tasks within ServiceNow. So none of this is necessary. Veeam has an integration into ServiceNow, but this is based on just bringing those two MCPs into one client.

So imagine we have that integration with ServiceNow, but I think this opens up the door to many of those other integrations that we might see, whether it's from a Veeam point of view with a security vendor that is doing something, but being able to interact this way with natural language and then leveraging APIs underneath to get an outcome. So you see that, and then he does a PowerPoint presentation to extract that out and go to the board later on that morning, which basically summarizes everything that we found for our coffee dashboard now into a presentation. We didn't even have to open PowerPoint for it.

And then what do we need to do? What should my team be doing today? Because based on this, we've already opened a ticket within ServiceNow.

We've got the information that we need to do and go and fix. This is what I'm going to be focused on. Equally, this enables us to start speaking in a different language to it and being able to provide that accessibility more than anything into our world.

So it's going to come back and provide that. And you see all it is based on three MCP add-ons that we use in the ServiceNow and the Veeam intelligence of VBR. And I think this next bit, so there's leveraging data.

Sorry. Sorry. Before you jump into the next bit, as you open up the Veeam environment to MCPs, what should people be concerned about?

Great question, right? I think MCP security is going to be another hot topic when we walk over the road later on this week. But everything that we're doing is from a role-based access control perspective.

You have to sign in. You have to provide credentials to get into that. So you're bringing that authentication authorization into that platform to be able to query what you've got access to within your Veeam environment.

If you're a viewer only, then you're only going to be able to view what you have access to. I don't know if that gives you the level. MCP security, me and you could probably talk for a while on the whole MCP security landscape, and I think that's probably where you were going, but.

Yes, but I also am concerned about what happens when you expose your backup environment to AI agents. What can an AI agent, what knowledge is it going to be able to extract out of there? And do you think that presents any sort of risk?

So just to level set what data is actually being sent where as well, is that only metadata leaves the customer site. Nothing sensitive will leave the site. That would be pretty bad of us when we've just spent an hour and a half talking about sensitive data and the likes.

Equally, there is no ability to impact the backups, like in terms of you can't tell it to delete backups. They're in an immutable state. If they've been designed and configured correctly, there's no way in which you can manipulate that.

" You can give it commands that way. So just conscious of time. The other area, so we talked about leveraging data.

How can we help customers use their data today? Forget about AI. Everyone wants AI, or the board wants AI, but actually people are still just trying to do their day jobs and trying to get on.

Leveraging that backup data for some insight and some use could be still useful for that. It could be the clean room. It could be the ability to get some insight out of that data.

Then how are we helping our administrators manage Veeam more proactively, more using natural language, and being able to hook that into the other tools that they're having to use on a daily basis? , there's some sort of AI model, there's some sort of LLM in the situation. Where are they sitting?

What are the applications that it has access to? Whether it's agents, assistants, chatbots, et cetera, but it's a new category of apps. But it becomes the same as a database in regards to if I can understand where it is, what it's doing, who has access to it, then I can start to protect and have a good understanding of what that data is.

So within the understand side of things, we're dynamically discovering those AWS Bedrock, the-Copilot agents that are across that estate. When you add those data systems in, it's picking up that context and being able to provide you the graph of that, the social network of that Copilot agent, who's the user, what data does it have access to, building out a map of that. Then equally, to the point that we touched on around Agent Commander, but this is a broader vision, is the ability to, if an agent does make a mistake or changes something, I agree with Tom.

So Tom's question in the last session was, if an AI agent just goes and runs wild, probably fix the agent, right? Great, want to recover the data 100%, and that might be a Veeam job to recover that data, but then you're not just going to let the agent go again and delete the database again. You're going to go and fix the agent and make sure that role-based access control is in place, and you're going to fix that.

But what this end-to-end does is gives you visibility of what it has access to, making sure that it doesn't have access to sensitive data, the ability to roll back if something bad happens. But that's the same as if we think about the three resilience trees that Rick and Emily touched on, the fire, flood, blood, or accidental deletion. That's the same scenario as an agent deleting something, right?

It's an accident. So being able to recover that. So what we're saying here is this can give us the ability to roll back and recover when those agents do make a mistake, because it might be that you can fix the agent, but the likelihood is that agents are going to just continue to keep making mistakes.

Not the same mistake, but the ability to change. Let me... And I think this is important, not only the understanding of the actual data, but what does it look like in terms of your AI agents?

What access of data do they have? What are the controls in place? How are we ensuring that they're not sharing sensitive information, and how do we block that?

And we have the concept of these LLM firewalls that are in there. What is the data that is being used? What LLM?

Is it a public LLM? Is it ChatGPT? Is it Copilot?

Who else can understand that data? There's lots of different LLM companies out there. Equally, being able to leverage that data to create a company's own SLM, so a small language model from that good data.

I can see Tom coming up. So firstly, is there any questions? But that was me, whistle stop tour of the Unleash Data.

So Skye Fugate, one quick question. I know when we get into giving AI the ability to go and interact via MCP, AD, whatever, with something, let's say backup schedules, what's it to stop from making a misinformed decision on... Maybe it doesn't understand what your RTO is, so instead you're like, "I want to save money," and it changes it to seven days instead of 24 hours.

What's to make sure that it has the right context before it makes those modifications? The oversight. Yeah.

There's a few different ways. So for internally here at Veeam from a product development standpoint, we're actually building additional AI agents to provide that context, like a backup admin agent, a security agent, et cetera, that can do deep analysis and be able to provide that information back. So that way, before you actually go and you try to take some action on it, essentially, it's going to red flag that and say, "Well, no, you have this one set from an SLA perspective," so this would kind of provide some guardrails.

So that is something that we are building internally in-house. We're still a little bit away from allowing customers to leverage something like MCP to take an action on it. But as we go to move to that direction, that is something 100% that we're trying to put those guardrails in place to actually surface, "This is the information.

This is the SLA that you set. Are you sure you want to do this? " So that way if they do try to change a policy, if they do try to delete the data, a secondary admin actually has to approve it.

So it can't just be done on behalf of an agent itself. There's a secondary overhead that can approve that action. So the MCP is not GA yet.

That's still in beta? It's a technical preview right now. Yeah.

There's several MCPs that are happening across Veeam. But yeah, the best way to put that is that they're all in a technical beta type situation. And then my second question.

For the agents, are those going to be house-kept where I have to interact with your AI, or can I take those and bring your own AI? Good question. Right.

So out of the box, they will use Microsoft OpenAI LLM, but you can bring your own model as well. So it's a configuration change to put it to your Ollama or whatever local model that you're using. All right.

Thank you. All right. That wraps our Unleash section for our Tech Field Day 2026.

Hey, everyone. I'm Michael Cade from Veeam. I'm a Field CTO, and I'm joined with Emily.

Hello, everybody. My name's Emily Tellez. I'm a Field CTO also with Veeam.

So in the previous segment, Rick touched on the four pillars and a bit more of the business outcomes of where we are, what we're doing at the moment from a Veeam point of view. So nowWant to go into those four pillars, right, as to why, and probably answer some of Tom's question there as well around like why are we getting into this space around helping our customers understand that data? So just to reiterate these, I put some text along these to make my simple British mind understand it.

But really about that understanding is helping our customers and to Tom's point, so Tom's question for the previous section was how are our customers relating to this? How are they using this? And the good thing about this, and I was going to come off mute and say, but didn't want to disrupt, but ultimately these are all modular.

A customer doesn't need to take all of these pillars. They might be just completely focused on the resilient and the secure side. They might be way down the line of unleashing that data.

They've got a good hygienic understanding of their data and they're going for it. But the story is how these interlink with each other as well, which is where that acquisition comes in from a security perspective, is being able to help our customers understand their data. Like who has access to it, where all the critical or sensitive data is within their estate, ultimately then so they can secure it better.

What does that flow look like? So you've got a mind map, a social network of where that data is being shared, OneDrive links being shared publicly, SharePoint links being shared publicly, ROT-based data, et cetera, redundant, obsolete, and trivial data. And then that leads into how can we be smarter when it comes to protecting that as well, right?

Just as a very big picture. Equally, I mentioned ROT, and we're going to touch on ROT a little bit later, but we're seeing that massively resonate with our customers. We're only 100 odd days into this acquisition, and we're already seeing a synergy of conversation around reducing that.

Not only is it reducing cost on enterprise storage in the data center, where they've got data that's been stored for X amount of years that could be sensitive, or even if it's not sensitive, it's still taking up expensive storage space. Let's tier that off into cheaper, deeper storage somewhere else. So it's reducing the cost, but also it's mitigating risk.

Reduce that attack surface so you've got a good lean understanding of that data so you can use it or at least just protect it a little bit better. So we're going to go through with the sections that we're doing, we're going to go through each of these, but this one is really focused on the understand. So knowing where all your critical data is and who and what uses it to protect it smarter.

So I want to spend a bit more time on this, is that, so you might have seen on Rick's original slide, it talks about the Data Command Graph. So it's a graph database, the social network of data. This is security as an acquisition or as a product, the Data Command Center, has the ability to inventory all of your data systems.

So where Veeam focuses on protecting the platform, like whether it's VMware, whether it's another hypervisor, whether it's M365, whether it's the cloud, whether it's Kubernetes, the platform that the data system lives on. So if it's a Postgres database or a Postgres cluster, security has a connector framework that enables them to go into that and build a map around who has access to it, what user, what kind of data is in that structured or unstructured data, and starts to build this map out, and you see just a snapshot of the connector framework down below. But there is around 350 plus connectors that plug into these databases, NAS-based services, data warehouses, data lakehouses, et cetera, like big data.

And it basically builds this map of everything that's going on in that space. Now, the outcomes of that could be, I need to know what's the sensitive data that we have in our estate, ROT analysis. You'll hear me say ROT quite a bit, redundant, obsolete, and trivial data, because I think that resonates with the backup admin, the IT staff that we generally speak to.

That's where we're seeing it fit from a story perspective. Equally, because now we've got an understanding of what that flow of data looks like, what the lineage of that data looks like, how it's moving from A to B to C, well, when bad things happen, like an exfiltration of data, for example, in a cyber event, if you've got a good timeframe and know when something's happened, we can work back and understand where that data has been and what data has been exfiltrated. Like we're not a data loss prevention tool because we don't have that capability.

We partner with a load of DLP type systems. But this is going to give you a mind map of where has that data been? What was the data that was exfiltrated?

Because many of the customers that we've spoken to, not just customers, but a broader survey is they don't know what data's been exfiltrated, and the cybercriminal, they're not writing down what they've taken, like they're holding you for ransom for a reason. What this will do is give you a lens into what that dataset was so that you can make an informed decision on, well, was it actually sensitive or was it just some old data that is irrelevant? The other thing is around compliance, especially from me, I've come over from the UK, GDPR, EU AI Act, many different regulations across our whole world actually.

So being able to build those frameworks into understanding that data, so not just understanding what your social security numbers and where they are and credit card details, but also aligning that to your regulatory requirements within your business. So out of the box, it can marry those up. Who has access to it?

I guarantee when you implement SecuriAI or the Data Command Center, and you add all your data systems, you're going to find some God mode privileges out there still in 2026. You're going to find something that you didn't know about your environment. So this gives you the ability to revoke some of that access, again, reducing that attack surface and the vulnerabilities of that.

And then AI governance. So I know we're here at RSA, we know that everything is going to be about AI, and AI resilience, as Rick touched on as well, is the next wave of resilience. None of the other things have gone away, like fire, flood, blood, and accidental deletion is still going to be high up there on people's minds, as well as cyber resilience.

AI resilience is now we're introducing new vectors into touching our data, using our data. So how do we get a good grasp on that data system? So we'll dynamically also discover those data systems, those models that are being used, AWS Bedrock, Microsoft Copilot, et cetera.

What's being put in there? What's being shared? Without getting too into the weeds, a concept of an LLM firewall.

Let's make sure that we're not sharing sensitive data up into a public model so that you've got control of that. There's three slides on this, but I'm going to just touch on one. So PII, just one variant of sensitive information.

And it also depends on where you are in the world, as well as to what regulation, what compliance, what governance you have to follow. " Equally, that could be PHI, it could be PCI, lots of different acronyms. But ultimately, it's got a good grasp on what that data is and gives a flag of what that data is so that you can see that in this, I keep calling it the social network of data.

But it gives you an idea of where that is, and I think... Yeah. So just to paint that into the data element.

So you've got all of these regulations. You as a company might also have a regulation that you've stipulated. It might be a bit of another regulation or a compliance rule that you want to bring into your company, as well as all the industry regulations.

But we have this concept of data elements. How do we pull those together and build this content profile? What does that look like from a business perspective?

So you can build a set of rules around that, because that might be the most sensitive data. That might be the gold data in your business that you need to protect, or you just need to have a good understanding of. So this could be Securiti before we acquired them.

We're obviously a standalone company, DSPM type tool that started off in the privacy, governance, and compliance space. So I've been calling it DSPM Plus. And that's a standalone tool that you can go and procure on your own.

Let's say you've got another backup system that is already backing up your data, you're happy with that, but you want to have a good understanding, you want to be more hygienic when it comes to data. This can come in and help you derive what that data set looks like from all of the different data systems that you have. So just one other thing we'll add on this, right?

The biggest portion of why did we do this acquisition. Yeah. Right?

So I think for a lot of our customers, it's number one, just making sure that they actually understand the data that actually exists out there, right? And that's probably one of the biggest things that being at Veeam for 12 years, I don't think I've ever went into a customer account or went into a POC with them and there wasn't something that we found that they didn't know about. Meaning we identified or we uncovered something, whether it was, hey, you have virtual machines that have orphan snapshots, or hey, you have virtual machines that should've been protected or data that should've been protected that wasn't.

And then going back to the earlier question as to, well, how are your customers reacting to this news? For me, especially someone that speaks to customers and speaks to partners on a day-to-day basis, the news is actually positive, right? If we think about how backup has existed prior to most recent years, it has been a black box.

It has been something that we're just told that we have to do, and hopefully when something goes wrong, we have something that we can go and we can recover, too. But now with cyber incidents, now with AI, it's shined a light on a lot of the ways that we go about handling risk and what is our current risk posture, right? And so you see a lot from cyber insurance company getting involved and validating with a customer, well, do you have backups?

Do you have a workflow? Do you know what your SLA is? Do you know what your regulation looks like in the time in which you have to go and actually report a breach?

So all of those items help us to feel that understanding of, well, how can we help you, Mr. and Mrs. Customer, be ready for an incident that can occur and feed that information early versus you having to do it post-process and having to juggle a lot of different hats.

So a lot of the understanding that Michael led up to, that's the biggest portion. How can we help you understand your data better so that way we can make better decisions in terms of overall protection? And some of those things we've already done from a Veeam standpoint, right?

So we've already protected data for a long time, and we've already added capabilities like being able to orchestrate the data set itself. I don't know why that keeps on moving forward. Yeah.

Do you need some help? No, it looks good. So essentially, when we think about how we helped organizations for a long period of time is let's think about how can we actually restore your data from backups or from replicas.

How can we help you to build those bigger workflows and essentially make sure that we are hitting your compliance minimum. So whatever your recovery time objective is, whatever your recovery point objective is, and that we have that fully aligned to the SLA standards. How do we make sure that this is documented?

That's probably one of the biggest issues that I see with a lot of organizations. They have a separate tool. Maybe they're using Word, maybe they're just using something to capture, like Notepad, their entire workflow strategy for how you go about restoring your most critical data.

But then how often does that get updated? Where is that being stored? Who has access to it?

What happens if the one person that is in charge of orchestrating those workflows for that particular incident is out, is not available, they can't be reached? Do you have somebody that's trained that could go through and can walk you step by step and know exactly that it is going to fail over to the right process that you have set up? So that dynamic documentation and compliance is really key, and this is something that Veeam we've been doing since 2018 and helping customers understand that overall orchestrated recovery.

And then we get to the other two. Clean recovery. I think this is probably one of the most overused terms that we've seen in the last three years.

What does it mean to have clean data? Well, technically from a security standpoint, your version of clean is very different than maybe an IT ops person's version of clean. We have data, we can restore it.

That's their version of clean. From a security perspective, it's, well, no. Has that data been messed with?

Is there any type of malicious or anomalous activity that has happened inside of it? Is there backdoors that maybe a threat actor had put, and now we are going and restoring into a separate environment, we are now reinfecting that new environment with this data that we are pulling from backups because it was malicious and we didn't do the right process to actually go through and validate to make sure that we removed anything before we do the restore. So with Veeam, we think about that and we add in some of those capabilities for malware analysis and being able to scan those.

And I'm going to show some of that. I have a quick question about- Sure ... the recovery process.

Is that something that has to be done before the data is restored in flight, or can it be done at rest? It can be done at rest. So effectively, I can store that data, and when I know, just say, for example, there was a zero-day that came out.

Once I've detected that, I can go back through my previous catalog and say, "Oh, yeah, we have a signature capability to remove that," and we can go ahead and disinfect. Absolutely. Yes.

Yeah. So there's actually a few different ways. You could do it during the recovery process.

We could also do it not before the recovery process. So just take our version of different backups. You could sit down with your security team.

They could provide you YAR rules, or they could provide you with that AV signature that you want to be able to go ahead and scan those backups with. And we could sit there, and we could scan multiple iterations of it before it actually goes into a recovery process. And that could all be done from backups leveraging our core technology, which was instant recovery, of just mounting and going through and scanning those workloads.

The other thing I'll add onto that, Tom, as well, is being able to provide a sandbox environment so that your security team can go and test what does that patch even look like before I even roll it out to production. So put it into an isolated environment, inject your update, whatever that may be, to fix the vulnerability, make sure everything works together in this isolated environment, and then tick, drop that down, and then go out and do it in production. So you're not infecting or you're not causing a problem in production straight off the bat.

Yeah. So I'll run through what this actually looks like, too. Because we didn't cover the cloud, Orchestrator covered the cloud, but I'll cover that off as well.

So you can see in here, let's say, for example, we need to create a recovery plan. And here, I could actually choose the plan type, depending on what it is I'd like to recover to, whether it's going to be cloud, recovering to a new hypervisor platform, or restoring from a replica. I could select my different backup types.

And then from there, I could actually go ahead and create a new plan. And so for this example, we're going to say this is our recovery plan. It's going to be for Techfield Day 2026.

And for my recovery objectives, I can actually set in here what my RPOs and what my RTOs are. And those are going to be something that'll get tested and validated for me. Now, I'm actually going to be recovering this to a Hyper-V environment, so I'm taking VMware backups and restoring these over into Microsoft Hyper-V.

And the great thing about that is when we start talking to customers that are going through the woes of Broadcom, or maybe they're just reimagining what their environment could look like from a migration strategy or from a migration process. The benefit here is now you actually get an opportunity to test your migration strategy at scale. I could select a whole bunch of hosts of different backups from here.

I can choose how I want to go ahead and have those be migrated over to this new hypervisor platform or even sending them over to Microsoft Azure. So you can see all of my virtual machines that I have associated, and I could pick and choose and select the areas in which I want to have these recover in what order. So you also have that opportunity to do so here.

Now, once I create this plan, the one beauty of this product is that, number one, I could just automatically do a readiness check, a lightweight check. It just operates in the background and actually tells me, is your plan actually ready for recovery? Meaning, do we see any warnings?

Are there any issues in here? Now, I did choose a workload in here to show you what do those warnings actually look like. So this is going to be the full set of documentation that a user will see just from creating that plan.

You get all of this documentation of showing these are the workloads. This is the area that we are going to be recovering to. And of course, we're seeing that you already have some warnings in here in terms of the actual recovery that possibly might not work or is already missing a recovery point objective, meaning I set my RTO or RPO for 24 hours, and so that backup job in particular is past that 24-hour period, so it's not going to make that RPO that I have set up.

Now, another way that you can leverage this is, again, recovering to a cloud. So we can leverage Microsoft Azure as a target, but going back to Tom's point, I can actually scan before I restore into Microsoft, leveraging YARA rules, leveraging AV signature scans, and I can plug those in here to do that scan before it actually restores up into Microsoft Azure. " So that way we could do additional tests.

I could have my security team go through and actually take a look at it. Can you do the scan as you're backing up the data so that you can then identify an infected machine, not waiting until it's recovery time? Yes.

So in the next session, we're going to cover all the different ways that we can scan the data. So with Veeam, we could do it before we actually started a backup so we can inform you of current risk behavior that is happening within the production environment. Then during the backup, we could scan inline, and we can check to see for any type of anomalous activity.

We could look for indicators of compromise. We can search for tools that threat actors use to perform exfiltrations of data, and then also scanning with our own AV signature-based detection. And then after the fact, we can go through those different iterations of AV signature plus YARA rule scanning.

So three different versions or variations of which we're scanning data. And then on top of that, we're here at RSAC, large ecosystem of providers and partners that are here. We integrate with over 60 of them.

So if CrowdStrike is finding something from an ADR perspective, they could send that information to us, and they can inform us of that potential information that's happening in production. We'll talk a little bit about some of the other capabilities as well. But yeah, from this standpoint, we could do multiple versions of those scanning capabilities before we actually perform a recovery.

So the last part of this is the why it matters. So for us, it's all about making smarter decisions with that data. So when we started this acquisition, it was for that specific use case.

How can we make sure that we are understanding the data that currently exists within the organization? How can we leverage that to make smarter decisions around our RTOs and our RPOs versus maybe somebody just guessing what it is? " So maybe you need to set expectations or maybe even do some investment opportunity, so that way you can maintain those standards.

And then on top of that, this gives us a capability of being able to precisely recover what is necessary, depending on whoever made the change, whether it was accidental deletion, disaster recovery initiatives, or even agentic. And then, of course, on top of this, this just helps us to validate SLAs and compliance more. All right.

Firstly, are there any questions on the understand, and then we'll move on to the secure side. I think we answered the questions as we were going. Okay.

So we'll wrap up there. That's the end of our session for the understand data. I'm Emily Tais.

I'm Michael Cade. Thank you.