EP 8 – Zero Trust, Zero Chill: Securing Machine Identity

David Puner:
You are listening to the Security Matters podcast. I’m David Puner, a senior editorial manager at CyberArk, the global leader in identity security.

Imagine this: you’re sitting in your office, catching up on the day. Things feel under control. Then your phone buzzes. Not a text. Not an email. It’s an alert. A certificate just expired. No big deal, right? Except that one little expired machine identity—just a tiny string of code—is the reason your system’s trust chain is unraveling.

You start to panic. Your web app won’t load. Customers are receiving « site can’t be trusted » messages. Your team’s already scrambling to identify what expired, where it expired, and who’s responsible for fixing it. Meanwhile, attackers—who never sleep, never blink—are watching. Because when identity breaks down, opportunity opens up.

This isn’t a hypothetical. It’s the everyday reality of modern infrastructure, where machine identities outnumber human identities by more than 80 to one. And the only way to stay resilient is to know what you’ve got, where it’s running, and how fast you can respond when—not if—something goes sideways.

Our guest today knows that world of machine identity better than most. Kevin Bocek, SVP of Innovation at CyberArk, has spent years sounding the alarm on machine identity. Today, he joins us to discuss why machine identities are the new frontline of cybersecurity and what every security leader should be doing to prepare.

Let’s dive in.

David Puner:
Kevin Bocek, senior vice president of innovation at CyberArk. Welcome to the podcast, Kevin.

Kevin Bocek:
Thanks so much for coming on, David. It’s cool to be here. Loving it.

David Puner:
Awesome. Really excited to talk with you. We’re going to talk about all things machine identity and machine identity security, and you are the guy to talk to and with about machine identity and machine identity security. So let’s start by setting the stage. What are machine identities and how do they differ from human identities? And what does scope and scale have to do with all of it?

Kevin Bocek:
Yeah, so you know what? Out there on the internet, cloud, enterprise networks, there are really two actors now that matter. There are humans like us, and there are machines—I mean, of all shapes, sizes, forms—everything from cloud instances to Kubernetes clusters, web applications, load balancers, IoT devices, and AI.

To us, I mean, we’re pretty boring. There are only so many customers, only so many members of the workforce that you can gather. But just since we’ve been talking, David, just think of the thousands of cloud instances that have been created at a data center not far from you or me. So you hit it right on the button, which is the volume, the velocity, and the variety of machine identities makes them so, so different.

Just in a matter of milliseconds—up, down—machines, cloud instances, virtual machines—they come and go. The variety—there’s not just one type. We have TLS certificates, we’ve got API keys, access tokens, SSH certificates, we’ve got code signing certificates, Spiffe IDs—more and more types are growing. So there’s that variety. And then again, the velocity, the volume—humans, we just can’t keep up.

That gives a perfect mix of, first of all, how they’re different. And second of all, machine identities—they live out with the applications, the cloud instances, the IoT devices. You don’t have one central directory or one central CyberArk identity to control all the machine identities in one place. They live out there. So all of that makes them different, unique. And we’ll get into some of the challenges. And of course, everyone here has gotten up close and personal with machine identities. You may not think you already know that, but you have. So we’ll dig into that.

David Puner:
So what would just a very common example of exposure to machine identity be?

Kevin Bocek:
Yeah, everyone every day sees it. And right now, if you’re watching through a web browser on your laptop, desktop, or even mobile device, it’s that padlock that glows in your web browser. Your web browser is a piece of software. It’s a machine. It’s connecting, of course, to a cloud, a web application, a load balancer. And when that padlock glows, it says, « Hey, I’m connecting to another machine. It’s presenting its identity. The identifier is its URL. And it’s been authenticated. »

We know that, yeah, that machine is—at least it’s coming from the same host that it says it’s coming from. And that’s where we get started with machine identities each and every day—whether we’re visiting our bank, a web shop, an insurer—any place we go on the web with our mobile device, laptops, desktops—we get up close and personal with machine identities. And again, there are many, many more that we’ll dig into, of course, too.

David Puner:
The big headline around here from our recently released 2025 Identity Security Landscape Study is that machine identities outnumber humans by now more than 80 to one. So this is a rapidly growing number, and it doesn’t seem like it’s going to stop growing anytime soon.

Kevin Bocek:
Precisely, David. Actually, it’s 82 times the number of machine identities to human identities. Of course, that’s up from a little over 40 just a couple of years ago. And already—if we were to sample that again—we’d probably see that number going up and up, as security teams start to get more and more visibility and awareness of some of the challenges that we’re going to dig into. Whether that’s the attacks that we’re seeing—the latest Verizon Data Breach Report is out too, we’ll talk about that—or the type of outages, the downtime that’s occurring from something like when a certificate expires. So all of this is causing us to have more awareness of the growth, the breadth, the scope of everywhere machine identities are being used in the business.

David Puner:
So you’ve been sounding the alarm on machine identity for years. Why is this moment right now so critical for getting it right?

Kevin Bocek:
Every organization—whether business or government—is heading into new territory. First of all, we’re headed to a point where every public TLS certificate that’s representing our business or government will have to have a lifetime of 47 days or less in the coming years. Starting next year—starting March 2026—the march will be ongoing down to 47 days.

Already we’re a little over a year in, and I know security teams, security ops teams, app teams—they’re struggling. Struggling to keep up, struggling to stop outages. That number going down to 47 days means six times or more the number of operations on TLS certificates—a machine identity—that we’re going to have to perform each and every year. Six times. And there are only more and more cloud instances, more and more web apps that are representing businesses or government organizations.

That’s number one: stopping certificate outages and getting those renewals in place. That’s why this is so important. Number one.

The second then is breaches. Recent research shows that it’s taking organizations on average over 100 days to detect an attack where the adversary has taken an API key or access token. Over 100 days to detect and remediate that. That’s 100 days. We’ve seen attacks—government organizations, modern cloud businesses—where API keys and access tokens are just kind of being hoovered up, vacuumed up by attackers.

And those two reasons—certificate outages and attackers getting the API keys and tokens—make this a critical moment.

David Puner:
Tell me if I’m getting this right or not, but TLS certificates are like digital ID cards for websites?

Kevin Bocek:
Yeah, machine identities of all types—especially TLS certificates—they’re just like passports. I mean, they’re passports for machines.

David Puner:
They’re currently valid for up to 398 days, and we’re going down to 47 days by March of 2026, as you’ve mentioned. So how do you see this change impacting organizations’ approach to certificate management? And what steps should security leaders take to prepare for the new standard?

Kevin Bocek:
What we find in the average business or government organization is that you have thousands of public TLS certificates. Those are the ones that are representing you out to the world—whether it’s on mobile apps, web browsers, or API clients.

Of course, internally you’ve got even more. But those are the ones externally. And I know some of you here in the audience have definitely been involved in requesting, downloading, validating a TLS certificate. On average, that takes four or more hours per certificate. Now you do that a thousand times. Now multiply that time six times or more per year. You can just imagine—there are many out there in the audience—I mean, the nightmares that this brings and conjures up.

I have to say, yes, I used to work—no more—but in data center ops. This is really a nightmare for teams.

David Puner:
Thank you for reminding us that we should get to know you a little bit here. You came over to CyberArk last year by way of the acquisition of Venafi, and you’ve been in the cybersecurity world for quite some time before your time with Venafi, of course. How has your philosophical approach to cybersecurity and identity security evolved throughout the years? And how might you be considering identity security differently now than you were just a year ago?

Kevin Bocek:
One thing that I’ve learned and really taken to heart is that we always have to remember: there’s an adversary. And they’re always there. They’re watching, and they are looking for the opportunity to attack.

And I think that’s the thing—no matter if it’s a good day, bad day, sunny day, cloudy day—we have to remember that they’re there. And I think that is the one thing that I’ve come to learn.

Why are we here in cybersecurity? We are here to protect our businesses, our organizations. And it can be tough. Again, when we’re down, trying to get something to work right at 2 a.m., or maybe we got a call. It is tough, I know. But that is why we’re here. And I think that’s what makes us so special in our roles.

That’s first. I have to say, I’ve learned that. I got started loving the technology and the complexity and details. But the thing I’ve learned, working with so many like you, that makes us special is—yeah, we’ve got the adversary always watching. And it’s down to us to keep us safe.

Second, when it comes to identity, it is the frontier. It is that first line, last line of defense. It’s that one layer of cyber which—when it fails—all the other layers of cybersecurity fall down.

So often, I’ve seen when an attacker—say, for example, like Stuxnet, one of the most infamous cyberattacks—what’s maybe not known very well is why was it so violent? Because a machine identity—in this case, code signing, something that authenticated the actual code—was stolen from Taiwan. It was used to sign the code that then made Stuxnet so viral. That’s how identity showed up as being completely authentic.

That’s the second thing: identity. And we just see that more and more every day. That makes our roles as identity security professionals so much more exciting and, I think, richer in terms of what we’re learning and how we’re keeping up with the adversaries and the new technologies.

David Puner:
Am I remembering correctly that you majored in chemistry in college?

Kevin Bocek:
I do. I do have a degree in chemistry from a great college—William & Mary in Williamsburg, Virginia. I have a specialty in analytical chemistry. So if anyone wants to know about a graphite furnace and what you can do with that, just contact me. We’ll chat it up.

David Puner:
So how is your focus now—in innovation, in cybersecurity and identity security—how is that an extension… I mean, it’s probably a bit of a pull, but how is it an extension of your background in chemistry? And then maybe even more importantly, your path through Colonial Williamsburg. How has that helped you evolve into the modern era?

Kevin Bocek:
Today, I get to have fun at CyberArk because, yes, my role and title is Innovation—which is all about exploring, bringing hypotheses, new ideas, and then bringing new capabilities back to help our customers.

So today, we’re exploring spaces like workload identity—how do I authenticate something like a virtual machine to a cloud instance? Agentic AI—how am I going to authenticate an agent as it talks to another agent but also make sure that we delegate correctly to human identities without doing things like impersonation?

Going back to chemistry—I loved it. Analytical chemistry was about finding, proving: was this true or not? Could we find ways, if we wanted to describe—was this, say for example, this artifact taken from this location or not? Could we find a way to prove it?

Yeah, that’s why I loved analytical chemistry. And I still bring those days of discovery and learning through to today, when we’re working on innovation in cyber and identity security.

I think the team knows I love being out there on the edges. You probably wouldn’t want me to be your project planner or project manager—that might be pretty dangerous. So, keep me working on what’s new, not keeping the lights on every day.

David Puner:
So then, from the sciences to nuance and language—we often hear the term “non-human identity” or NHI. Is that just a synonym or an umbrella term for machine identity, or is there a distinction between the two?

Kevin Bocek:
Hi—benkyo shimasu. As I said in Japanese—I studied Japanese in university. For those Japanese speakers, well, I probably said it very, very poorly. But language, of course, matters. Hopefully, as I just demonstrated.

And yeah, absolutely. You know what? As we started off earlier, there are humans, and of course, there are non-human entities. There are business entities—that’s a non-human entity. You might have a pet, a dog, a cat—that’s a non-human. Of course, machines of all shapes and sizes—workloads, devices—those are also non-human.

And, well, who knows? Maybe there are extraterrestrials—but again, separate topic.

All those could be non-human. But the non-humans that matter here are the machines.

So I think that’s why I said: the actors that matter on the internet, enterprise networks, and clouds are humans and machines. Those are the ones that matter.

And as I said, words matter. Language matters. That’s where we get precision. If I just talk about non-human, again—it could be everything from your cat to a business entity to your AWS Lambda function.

That’s why we talk in specific terms: humans—things like workforce, customers, developer or IT identities—and then machine identities—workloads and devices. We can even go into subcategories there.

So absolutely—humans and machines. It matters. And I encourage everyone to go through that exercise themselves and understand. And too—the experts have agreed with this. Gartner, Forrester—the two actors that matter are humans and machines. That will help you tell the story.

And that’s the one thing too that’s powerful. I will not tell a story in Japanese, I promise.

David Puner:
You’re welcome to—we’ve got nothing but tape here.

Kevin Bocek:
That could be dangerous. Or—“auf Deutsch” for the German speakers—that could be even worse. I lived in Karlsruhe, and my “Denglish”—my German-English—and my special Swabian dialect is even worse than my Japanese.

But you know, it allows us to tell a story—to the executive teams. Whether that be the CTO, the CIO, the auditors—it allows us to explain: just like we have a human identity for the workforce that allows us to say who is good or bad, friend or foe, who belongs and who doesn’t, we have things like machine identities—like TLS certificates or access tokens—so we know which workloads or cloud instances belong or not.

It’s really, really important—especially in storytelling. I encourage everyone to practice it too.

David Puner:
Yeah, as do I. We know how important that is, that’s for sure. So then, while still on the subject of precision—how does machine identity precision strengthen Zero Trust architectures? And what’s the risk if we get it wrong?

Kevin Bocek:
When it comes to Zero Trust—and I won’t be offended because I’m not there with you in the audience—so as you go along, you can Google this. When we think about Zero Trust and the early architects—Google—they put together two position pieces. One was called BeyondCorp, and the other BeyondProd.

So I now encourage you to Google “BeyondProd”—all one word. That sets forth Zero Trust.

BeyondCorp is the model we know—human to machine. Many of the teams in the audience are working on how to uniquely identify the workforce or developers when they come and authenticate to applications or services. That’s that human-to-machine Zero Trust model—BeyondCorp.

Now there’s the next model—BeyondProd. That’s machine to machine. How do I uniquely identify every machine-to-machine operation?

Just like the principles of Zero Trust, we’re always authenticating. We’re never just blindly trusting. And we do that with identity.

Just like in the human-to-machine model, the machine-to-machine model must be identity-based. Every TLS certificate, every API token, every SSH key must be unique and rotated—short-lived and constantly verified.

David Puner:
What kind of context do security teams need to truly secure machine identities?

Kevin Bocek:
Really important in understanding machine identities is getting, as you said David, the discovery and context right. We have to know where they live, because again, there is no one central directory, no one central repository. We have to go out across the enterprise, across different network segments, and discover them—not just one type, but all of them. We have to get the TLS certificates, the API keys, access tokens, SSH keys, code signing certificates.

We have to also do that out in the cloud and in and out of our CI/CD pipelines. And once we get all that data—wow—that could be like a tidal wave. And if we don’t have the right tools, it’s just like… you might as well just have a spreadsheet.

So we then need to get the right context, and this is something that CyberArk has really been innovating on—so that we can apply not only the identities coming in, but also which machines they’re working with, what workloads are using those machine identities, and—really importantly—who are the teams, who are the individuals responsible for those machine identities.

Because still, here in 2025, humans are still responsible and accountable for securing and maintaining those machine identities. So we need to have that full context. And then we can start to answer the what, where, why questions—plus the who questions—about machine identities.

Why are they being used? What are they giving access to? Where are they being used? When are they being used? It’s all the who, what, when, where, why questions you’ve probably already been asking and solving for in the human identity world. Now that’s just as important in the machine identity world—whether we’re getting ready to solve for that 47-day certificate lifetime, or trying to find out who owns the certificates we’ve discovered. We need to know if they’re on our F5 load balancers or Apache web servers or EC2 instances or NGINX boxes.

Same thing with access tokens. Where are they being used? When? How many? Are they being duplicated? What secrets manager or vault are they stored in—maybe a few?

Getting to answer all these questions gives us real intelligence. Then we can take action. Not to mention, David, all this is happening at machine speed. So it’s constantly changing. The idea that we just discover once and we’re done? That doesn’t apply. We have to be constantly monitoring and keeping up—because these machines are changing everywhere.

David Puner:
How does this approach change the way CISOs should think about visibility and inventory?

Kevin Bocek:
Right—so it’s not a one-and-done. It’s not a once-a-year inventory and then we apply some policy or show the auditors. We have to be keeping up each and every day.

A great example I love: we’ve seen a number of outages in Microsoft Azure due to expired TLS certificates. The Azure team has some really good automation for performing renewals—they built it themselves inside of Azure for Microsoft’s internal teams. But what happens is you get a virtual machine that gets rolled back, or a system that’s rolled back or updated, and then an old certificate gets put back in place—or a new one doesn’t get moved into production. Then what happens? You get an outage.

Which means you have to be constantly monitoring.

So from a CISO perspective—thinking about machine identities—it’s a continuous discovery and context loop. And the idea of inventory is something I tend to guide against. Because it’s a bit like retail: you take inventory at certain times, and it tends to give a static connotation. But this is always changing. You have to be able to discover and get context continuously.

David Puner:
You’ve spoken about the importance of cyber resilience. How does machine identity security contribute to building a more resilient infrastructure?

Kevin Bocek:
The ability to respond to any type of incident involving machine identities is, at the core level, just about keeping the business operating.

Think about it: if something like a TLS certificate expires—which I know everyone here has experienced—you go to a website and it says “This site cannot be trusted.” Or, actually, I know from our research—45% of organizations are having a certificate outage weekly. So almost half of the audience is having a certificate outage every single week.

So first of all, of course, you hope not to be having them. But then: how do you respond?

Or if you’re under attack—say, for example, it takes 100 days to discover and remediate an exposed access token in the cloud—being able to instead rotate those secrets automatically, being able to detect them early, that’s resilience.

Cyber resilience means your systems don’t collapse when something goes wrong. If one machine can’t authenticate with another, entire systems can go down. It’s so different from a human. If one employee can’t log in, okay—it’s a bad day for that person. But if a machine identity expires or an API key isn’t updated correctly, that can have a cascading effect on systems.

And I think that just gets to the core of resilience.

And one thing I’d say too—and we were just talking about discovery, context, and CISOs—this is something I’m doing each and every day. I’m checking: how are we doing? Are we finding more identities? Are we remediating more? Are we automating and securing more?

From a resilience perspective, that gives me confidence. If I’m discovering more and automating more—whether I’m rotating TLS certificates or rekeying API tokens more often—I know I’ve got a much better level of cyber resilience. Which, ultimately, is what the CISO is looking for.

So that’s something I’d recommend to teams: the type of reporting you give to your CISO and your leadership should show that progression over time. Not just “Are we doing our job?” or “Are we keeping it safer?”—but “Are we delivering a higher level of resilience to the business?”

David Puner:
To give a little nod to our 2025 State of Machine Identity Security Report—in that report, it found that in the last year, 72% of organizations experienced at least one certificate-related outage and 50% reported security incidents and breaches related to compromised machine identities. So just piggybacking on your earlier stats there and showing a little machine identity report love—folks should definitely check that out for more information.

How can CISOs embed resilience thinking into their identity programs from the start, rather than treating it as an afterthought?

Kevin Bocek:
Again, as we talked about—do we have the intelligence? Do we know and can we answer the what, where, who, how, why questions?

I suspect that security teams can answer many of those when it comes to, say, the workforce or customer identity. So first, it’s understanding.

I have to say, if you go into your CISO and say, “Hey, you know what? We just found 5,000 TLS certificates or 1,500 API keys and access tokens that we didn’t know about”—that’s pretty alarming. But we see that each and every day.

So first, having that intelligence. And second, of course: can I do something about it? Do we have the automation—whether it’s rekey, reissue, or renew?

So you put those together—the intelligence and the automation—and you’re having a huge, huge impact on cyber resilience.

I think those are great principles to bring in. And of course, they’re measurable. We can measure the intelligence we’re gathering. We can measure the percent of automation. The mean time to take down or respond. So all things that have great measurable results.

David Puner:
While we’re on the subject of resilience, I recently heard your notion of an AI kill switch. What does that mean?

Kevin Bocek:
Yeah. Well, if we think about AI today—whether large language models or the emergence of AI agents—they’re going to be doing work, performing transactions across our business. Some of them already are.

There’s no power switch. There’s no network plug that you can pull. So let’s just say, for example, if an AI agent starts to have a bad day or starts working outside its training—what are we going to do?

In the end, having a kill switch is something that… if you’re a manufacturer, you have a kill switch. If you go to a petrol forecourt—or as we say in America, a gas station—you’ve got a kill switch. You can turn off the flow of fuel.

And with AI, how do we have a kill switch?

It’s identity-based. That’s how.

David Puner:
Okay.

Kevin Bocek:
If we’re uniquely authenticating each AI agent, then we know what AI agents are out there. We can say, “You know what? That’s a good one. That’s a bad one.”

It’s all identity-based. So essentially, identity becomes the kill switch for AI.

I think that’s something important for security teams to bring forward as they look at and build architectures around AI agents.

And it’s pretty simple too. I mean, I can tell that story to a CEO, a CISO, a CTO—whatever your business is, they’ll get it.

David Puner:
So it is feasible?

Kevin Bocek:
Absolutely feasible. So long as we build it in now.

One of the things I’m always coaching security and identity teams on—we can learn from what we experienced with RPA, with bots.

With RPA and bots—if you remember back to, say, 2015, 2016, 2017—there was a rapid business-driven adoption of RPA. And I think as security professionals, identity professionals, what did we do?

We had essentially impersonation, to quickly give some type of identity to those bots. But it was impersonation—we were applying human identity to a machine.

Some security teams were actually giving those same bots the same human identities—or placing them into groups alongside other human identities.

And we need to learn from that impersonation mistake. That’s something we’d love to have a do-over on.

Now with AI agents coming along—we can. We can get that right.

We can give AI agents unique and universal identities so they can do their work. But again, applying Zero Trust principles: we’re always authenticating.

And then we’ve got that kill switch. We say, “Yup. You know what? I’m going to revoke that certificate. I’m not going to allow that agent to authenticate anymore.”

David Puner:
In one of your recent blogs, you describe agentic AI as “digital coworkers with admin rights and zero chill.” So what makes them such a singular challenge for identity and access management?

Kevin Bocek:
They’re machines. They’re working at machine speed. It’s different than a customer or a member of the workforce. Even when we see the adversary trying to do account takeovers—we’ve got great signals and we can usually understand.

But machines? They operate at a different speed and scale.

AI agents won’t just be one-off. There will be many of them—possibly performing the same tasks—and that introduces complexity.

Then you have variety. There will be many types of AI agents.

That will challenge us—as identity and security professionals—if we don’t start getting identity built in from the beginning.

The great news is—we can take the lessons we’re learning from workload identity and cloud-native identity. Those lessons are about creating unique and universal identities—particularly with things like SPIFFE, which is a cloud-native standard—and apply them to AI agents.

Because agents are workloads.

And we’ve got emerging protocols like MTP, which will allow us to authenticate those agents when they’re doing work with each other—or when they authenticate to application services or databases.

So we’ve got the lessons. And we’ve got the capabilities.

David Puner:
We’re talking about machine identities, obviously. And hearing you talk about it—it seems so clear. Maybe not simple, but at least easy to wrap your head around.

When you talk to Kevin Bocek about machine identities, is there any particular misconception regarding machine identity that you hear a lot these days?

Kevin Bocek:
Well, first of all—thank you, David. I’m a student. I’m still learning.

The one thing I always hear after an incident—like a certificate outage, or an API token being exposed in an S3 bucket—is, “Ah yeah, that was just one incident. Not a big deal.”

But the big myth is: it’s an isolated issue.

People think there aren’t that many machine identities out there—or that they can just apply a script—or that their cloud provider is taking care of the problem for them.

Those are myths.

A perfect example: cloud providers are offering more automation. But how do you know what API keys and access tokens are in all your AWS Secrets Managers? How do you know what TLS certificates are on all your EC2 instances? Even if you’re using Amazon Certificate Manager, how do you know across all regions?

How could you even help if there were an incident?

These are the types of myths we see popping up. And it’s no one’s fault—we’re still learning about the volume, velocity, and variety of machine identities.

Where are they being used? How are they being used? What’s their lifecycle?

We, as security and identity professionals, need to help educate CISOs, application teams, and platform teams. And bring together a cohesive identity security strategy.

This is what Gartner has been doing—helping CISOs learn what capabilities are required. Your secrets manager needs to work with your certificate manager. That needs to work with your enterprise PKI. That needs to integrate with your workload identity tooling.

We’re still learning. It takes experts to guide us—to educate the architects, the CISOs—on what to do about the problem, and how to solve it with the right architecture.

David Puner:
It’s a rapidly evolving landscape and story, that’s for sure. One of the things I think would be interesting to do here at the end is to look into the crystal ball a little bit with you, Kevin. As we move toward artificial general intelligence and quantum computing, what identity innovation should security leaders be prepared for?

Kevin Bocek:
Whoa. Well, we didn’t even get to a post-quantum world yet—which is a world where quantum computers are rapidly evolving. And there is almost certainly going to be a time when they’re able to break today’s encryption.

When that happens, everything we’ve come to know about the digital world—whether it’s paying online, authenticating on a mobile device, or trusting a communication—could break.

That’s the post-quantum world. And we need to be prepared for it.

The good news is—we can talk about it. We’ve got capabilities. All the things we’ve been talking about: discovery, intelligence, automation. We need those, and we’ll need to be even better at them.

When you think about a world that also drives more and more AGI, the speed of identity-based attacks is only going to increase. And I think, from a machine identity perspective—because AI is a machine, and it’s operating at machine speed—that’s why we’ve got to get machine identity right.

The front door won’t just be phishing or spam attacks anymore. AGI brings forward full-on, cloud-native, machine-driven attacks. That’s the future world.

David Puner:
Sounds like we’ve got many sequels to this story coming up. Really appreciate you coming on the podcast, Kevin. I know it’s getting late for you—am I right in assuming it’s close to bedtime over there in the UK?

Kevin Bocek:
As they used to say in the old advertisements: the city never sleeps. But yeah, I did my internship at Dell. And anyone who’s spent time in Austin in July or August knows—it’s like being a vampire. You just can’t sleep when it’s over 100 degrees Fahrenheit—or greater than 40 degrees Celsius.

So I’ve learned to love being up late. And our teams are all over the world—Australia, Singapore—and our colleagues in Palo Alto. This is fun. It’s great to be here with you.

David Puner:
Really appreciate you coming onto the podcast, Kevin. You bring a lot of insight into machine identity and everything else in this world, and we appreciate your time very much. Look forward to talking with you again down the road. See you next time.

Kevin Bocek:
Thanks, David.

David Puner:
Alright, there you have it. Thanks for listening to Security Matters. If you liked this episode, please follow us wherever you do your podcast thing so you can catch new episodes as they drop. And if you feel so inclined, please leave us a review—we’d appreciate it very much, and so will the algorithmic winds.

What else? Drop us a line with questions, comments. And if you’re a cybersecurity professional and you have an idea for an episode, drop us a line. Our email address is [email protected].

We hope to see you next time.