Episode 123: Agentic Identity

Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to episode 123 and welcome to 2026. This week is myself, Michael, with Sarah and Mark, and our guest this week is Nick Reiter, and we're going to talk about agentic identity and probably a few other things too. But before we get stuck into talking to Nick, let's take a little lap around the news.

Sarah, why don't you kick things off? Okay, so just a quick one from me. The AI tour is starting again in various different parts of the world. It took its...

Christmas New Year break. We'll put the link to the website in the show notes. The AI tour is going all around the world. So come and see us.

And it's a one -day event. It's free. You have to apply to attend. Come and visit us if there's one near you.

It'll be going on for the next few months. I mean, it's a yearly thing now. I'm at a few of the stops. Come and say hello if you're at one of the stops I'm at.

And come see some cool AI stuff and mingle with good Microsoft people. So yeah, that's my piece of news. Sarah, on that AI tour, is there going to be AI security discussed as well? Yes, there is.

So there are security sessions at the AI tour. So you've got obviously building AI, blah, blah, blah, but there are some security specific sessions as well. So although it's not a pure security event, there is stuff for security people. So yeah, definitely worth popping along if there is one nearby to you.

And from my part of the world, the big thing I just want to make sure to draw people's attention to is the security roles and glossary standard that we published. I'll throw a link in the show notes there. But this really covers how to think about. security accountabilities all the way from the fiduciary duty of board members into the accountabilities of business leaders and tech people and into the responsibilities of security specializations and professionals and managers and whatnot.

So really kind of getting into those standards and why it's important for everybody to do their different security jobs. So very much looking for feedback on that. So we'll pop in. Okay, I've got a few product announcements.

The first one is public preview. Azure Cosmos DB database mirroring is now available with private endpoint support. Said this a billion times, going to say it again. It's always good to see private endpoint support being added to products for various scenarios because that way it keeps data off the internet.

Next, in public preview for Azure NetApp files, there is now advanced ransomware protection. Very cool to see this. Every file system should have that kind of capability built into it. So it's great to see this being added to Azure NetApps too.

This next one kind of took me by surprise, actually. You may have heard that we were going to block implicit outbound connections from VMs in Azure. That was going to take effect, I believe, was originally the end of September or October in 2025. that has now been extended to March the 31st, 2026.

So basically there's a whole bunch of stuff that you must do if you want outbound connections from a VM. And the whole point of it is to prevent egress of sensitive data. It's well worth reading that particular document in the show notes. Next one is in general availability is FIPS compliant mode for app gateway version two.

And this is essentially the ability to enforce FIPS 140 -2 validated algorithms for TLS. Not everyone needs this, but it's really important, especially if you have FedRAMP requirements. Next is in general availability is a Azure MCP server support for Azure Confidential Ledger. So now basically you can write immutable logging information or immutable data to confidential ledgers through an MCP server, which is great to see.

And last, for me, in general availability, my old stomping ground of Azure Data, there is now a cred check extension in Azure Database for PostgreSQL Flexible Server. So this will allow you to enforce password and credential validation policies directly within PostgreSQL. Not that I'm a big fan of passwords, because I'm not, but at least there's something in there that's going to help you at least have a... decent policy put in place and actually enforce that at the database level.

All right, now we've got the news out of the way, let's switch our attention to our guest. As I mentioned, our guest is Nick Reiter, who's here to talk to us about agentic identity. So Nick, welcome back to the podcast. We'd like to take a quick moment and introduce yourself to our listeners.

Thank you, Michael. Yeah, my name is Nick Reiter. I'm a principal product manager. I get to work with lots of customers learning how they're building agents.

But my primary job today, I think from last time when I used to look after multi -cloud access governance, is focusing on how to secure access to AI agents. So first and foremost, so what... is an agent? How would you go about describing what an agent is?

Why are they all of a sudden literally appeared overnight? And give some examples of agents. Let's just start with the notion of an agent at runtime, right? I think a lot of people understand what an LLM is and what an LLM does.

But an agent is basically an LLM that has short -term memory, long -term memory, and has some tools and some skills that it can basically use. And all that combined together at runtime with some orchestration functionality, things like their profile, their goals, instructions, and their model -based reasoning is what an agent actually consists of. And what can they do? Well, agents today can be used for lots and lots of different actions and tasks, right?

So in our world in security or just online, agents can help do things like assist you with certain type of tasks Things like interactions. You can interact with the agent in a way that it can assist you to do certain types of actions and act on demand using delegated permissions. You know, it's ideal for tasks like summarizing emails or responding to queries without ever needing, you know, your own access. That's one type of an agent.

And then there's the notion of an autonomous agent, which basically has his own roles and permissions. And the agent is enabled. to then perform complex goal -oriented work independently. Things like monitoring logs, auditing activities, or acts on behalf of itself, or things like coordinating actions on behalf of the user and the user's schedule.

That's an autonomous agent. But now, more and more, what we're seeing is this whole new type of agents who basically are working with others, right? And this is a fully provisioned agent with user -like credentials, right? They can join team meetings or Slack.

They can create and edit documents, interact in conversations, and even collaborate with other agents through a registry. These agents combine human -like interactions with things like superhuman capabilities, things like API calls, language translation. Those are typical examples. They can collaborate with other agents and tools or people.

And it preventions its own access and resources basically to help achieve goals on their own behalf and schedule. It's pretty cool technology that's out there today. Yeah, that's a great introduction to agents. The way that I sort of think about them, I'm interested in your thoughts on this, is I look at it as kind of breaking it down as component parts.

Agents have an LLM involved, right? And so there's that dynamic code and whatnot that you get from a large language model for generative AI. But most of the time, it's not just a raw model. There's like some sort of deterministic code, kind of classic code to make it do certain things, make it not say certain things, make it cover certain topics or not touch other topics.

And then just tell it what to call and whatnot to do things. The one that I always focus on is the access, right? So that agent has permission to do things. And, you know, the more I think about like agents is they're just like the software already know, right?

Which is they're things that run in my context as a user, right? And they're doing things on my behalf, you know, which introduces a security problem of. Was it me that did it or was it the agent that did it on my behalf, right? So that's sort of the question you have to answer with logs and the controls that you have to put in place to separate, right?

And then there's the software that runs all on its own. And whether that's in the context of a Teams meeting or whether it's doing some back -end maintenance tasks or whatever. But it's just autonomous code. We've had services.

We've had OT technology. We've had IT technology. We've had all that for a long time. It's just we're now doing it with LLMs in the mix.

And the interesting combination for me is when you have one of these things that's doing that, that's sort of separate from the user identity, it has to have its own identity and the lifecycle and the governance and all that kind of stuff. But the way I think about the agents, those sort of independent agents that kind of do their own things is, you know, you have to govern them. You have to monitor them. And one of the best things you can do is least privilege because AI is non -deterministic, right?

It's going to do stuff within a range of similar tasks. It's not going to do the exact same code path every time. I really think about least privilege as being a very, very key thing. And of course, monitoring, et cetera.

That's just how I look at it from a security perspective. I'm curious if that jives with what you're seeing, Nick. Yeah, Mark, I think that's 100 % what we're seeing, right? Agents belong in the same identity conversation as users, applications, and devices, because obviously they take actions and they require access to.

resources, right? The difference is agents basically do not fit neatly into that old bucket of, oh, let's just give it a non -human identity. Because sometimes an agent acts on behalf of a user. Sometimes it behaves more like an application.

And unlike traditional applications, agents are not static because they can acquire new skills like LLM capabilities. And as the LLM capabilities evolve, which changes what they can do over time. And that's the biggest change. And that is exactly why they need to be treated as a first -class identity within anybody's environment and bring all those security controls that we know for users to agents.

To your point, Mark, was it the agent that did it or was it me who did it? So if I have an agent running on my behalf, Was it me who did it or the agent? I mean, that's a classic example of the confused deputy problem, right? Who actually did it?

Me or someone acting on my behalf? So yeah, it opens up all those kinds of issues we need to be aware of. Yeah, including everybody's favorite obscure security word in the threat model of repudiation, which I like to think of as the shaggy, it wasn't me problem. Exactly.

So the next question is, I mean, so how do people build these things? uh i mean is it a i mean i know about a windows service we know about like mobile apps and that sort of stuff so what is it i mean how how would i build and deploy one of these things yeah building agents i mean there's lots of platforms out there i think all the major cloud service providers all have their own agent building factory so for example within microsoft we have platforms like microsoft foundry and microsoft co -pilot studio as an example right and within you know Amazon, there's Bedrock, and Google has Vertex.

They have lots of different ways you can go. And most of these cloud service providers... basically help you provision these agents. And what I mean by provision is they give you the orchestration, they put all the memory, they add all the skills and tools for you.

And all you have to do is basically choose an LLM that you'd like. And then boom, you're up and running with this agent and you can just keep adding skills to it. But building an agent really takes understanding how an agent, all the components of agents come together, right? And so But building one is not super hard.

Obviously, you just need to start with your large language model, figure out what kind of tools and scaling and knowledge that you want for the agent, add some memory to it, long -term and short -term, and then basically have an orchestration layer where you can add instructions, specific goals to their profile, and then add some model -based reasoning to it, and boom, you got an agent. Hey, so does this thing run inside of Azure, for example? I mean, is it always some standalone code that I run somewhere else?

And also when you say, you know, choose a model, what have you, is there programming involved as well? Or is it all declarative? There's definitely some code in there. And, you know, platforms, and maybe I'll speak to Microsoft's builders and factories, because that's what I'm very well versed with.

And, you know, I play with, you know, other models and other agents. other factories but um for example within copilot studio as an example it's a very pro no code solution meaning they don't want you to put any code running anywhere they basically compile all the different components for you and all you do is you know ask a few questions they pre -provision that agent for you and you're up and running but for example microsoft foundry you create a resource within Azure and then you start adding the different components to them, right?

So as I mentioned, all those components can be, you know, pro code. So you can write specific code to specific skills, specific memory items and specific instructions that you want for the agent, et cetera. So all up, yeah, you can basically write the pro code or no code or use less code to build your agent. And one of the things that I find that's really interesting about really anything generative AI is when you think about building software, we're so used to having to literally build it brick by brick.

Either you write the code or you include a module or you call something else, and then you add your own piece to it. You're essentially building a brick wall or brick building, right? Whether you're using your own bricks or somebody else's. But when you think about the LLMs and generative AI, it comes with a whole bunch of capabilities, some of which you don't need, right?

And so it's almost like having a really smart but inexperienced intern and you have to kind of tell it what not to do almost as much as you're telling it what to do. And so that's one of the things that I kind of find fascinating about it is it sort of inverts the problem of how do you make this thing do what it's supposed to do and only that. And we kind of forget the second half of it because we've had to... build everything we do is we're not going to build a bunch of code modules we're not going to use in classic software but when an llm comes along it can do a lot more and it's a matter of making sure it does only the things you want it to do mark you're spot on you are spot on it's so true because i think traditional development does not understand oh you have all of this knowledge that an llm has versus like traditional building an app right and so what When you're building agent and you can actually add new skills to it and add memory to it, it becomes a very, very big monster to secure and make sure all those items are protected pretty well.

A couple of things I want to get out of the way. So the first one, when we're talking about memory, we're not talking about RAM right here. We're talking about maintaining context across conversations and that sort of stuff. Correct.

This is just the agent's memory, right? Yeah. Okay. Next thing is, So to your point, Mark, about the LLM can do, you expect to do A, B, and C, but it knows all about X, Y, Z, 1, 2, 3, 4, 5, and 6.

Could part of that be mitigated by using a small language model that's designed to take on a certain type of task? Yeah, if the small language model meets the need. And it only knows about bridge engineering or whatever the heck the topic is. And it doesn't know about how to play chess or how to build a bomb or what are the best tourist spots in Rome in 2024, right?

That's one way of doing it, right? Now, of course, that SLM has to have sufficient language functionality and all the other things that you need to accomplish the app. But if you've got an SLM that's focused and does what you need, don't bring the overhead you don't need. But again, it really depends on which models are available.

So there's a lot of model selection sort of challenges at play, at least in my experience. Yeah, it's like, you know, I like to use language models when I talk about Rust, right? It knows I'm not talking about ferric oxide, iron oxide. I'm not talking about the movie called Rust.

I'm not talking about the video game Rust. I'm talking about the programming language Rust. So that's important to me. Next question.

This is where I think we kind of touched on some of this stuff implicitly when we talk about least privilege. But where does identity come to play and how do we control it? How can we control what a potentially runaway agent could actually do? Yeah, right.

So, I mean, as I was talking about why we need to treat agents' access to resources and look at the identity, if an agent is compromised, right, it can operate at speed and at scale. Treating it as an identity is how you get an attribution, enforce protections consistently, and investigate quickly when something goes wrong. What does this really mean? If you look at an application today, how does an application get access to a resource?

It's through its client credentials. For an agent, it's not necessarily that because it has access to tools and skills and knowledge that it just knows. And so, you know, agents need an identity so that access can be granted and reviewed consistently and activity can be tracked and traced back to a specific agent itself. So without that, without an identity, you cannot reliably answer who the agent is and what it can access or what it did.

Right. And I think Mark covered it a little bit of that earlier. But Mark, what do you think about that? Yeah, I mean, it's I view it like any other.

like any other identity like you need the whole life cycle right from cradle to grave as it were And you need to have all the security fun on it in terms of preventing bad things from happening and monitoring if you can't prevent that, or if you can, or if that control failed, if it went off the rails. And I just think of it as like an entire lifecycle. And you have to apply, you know, all the security things to each point in that agent lifecycle. And of course, absolutely make sure that the lifecycle closes so that...

if you no longer need that agent or it got deprecated or replaced or whatever, that the identity doesn't hang around like some domain admins that are no longer with the company or no longer of this earth. I recognize that this is probably very, very early and we're constantly evolving this stuff. So, you know, what do we do? How can we make sure that, you know, an agent runs at least privilege?

What sort of tooling do we have? What sort of monitoring do we have? Anything we can do to actually identify that this was the agent. Yeah, I mean, Lots of companies, lots of customers are building lots and lots of agents and they're building really fast, right?

Because everybody just wants to be at the cutting edge of technology. Microsoft's approach is, well, you can build an agent either with a service principle or you can build an agent with what we like to call an agent identity. And if you go the service principle route, you're basically choosing that your agent will use tokens on behalf of a particular user. or use some kind of client credential that an agent actually can be given, right?

And this is very much tied to what I talked about if the agent is an interactive agent or like an assistive type of agent or an autonomous agent, right? Those things are very, very good. You can go through the path of using service principles, but... This new notion of an agent identity basically gives you that first class citizen.

And that's the approach that Microsoft is building for all of our factory, right? Our agent factory buildings. So for example, today, when you build an agent within Microsoft Foundry, it gets an agent identity. So why is Microsoft doing this?

Or why are we doing this? We believe when an agent is given an agent identity, That's when you start that life cycle that Mark was talking about, right? You're going to be able to apply protections to it. You're going to be able to apply network security, governance, all the identity things like authentication and authorization.

So we start with how can that agent be authenticated, one, and then two, how can you provide an authorization to that protective resource that the agent is trying to get to? And then we also help you discover and register that agent in a centralized place, in a centralized manner, so that you can start that lifecycle process. So that's the approach that Microsoft has taken, right? So we start with agent identity.

We want you to be able to register and manage your AI agent. be able to govern it so that agent identities and life cycles, you're governing just the access, right? So when I talk about governance, sometimes some people think about the data governance. I'm speaking specifically about governance and who gets access to that agent, how you can involve sponsors and owners of agents and be able to request permissions for that agent, whether it's graph permissions, et cetera.

And then lastly, to be able to protect that agent access to resource, being able to block the agent, disable the agent, get some signals, some risk signals. So if that agent becomes risky, you'll be able to do those things with agent identity today. So if you can run an agent as a service principal, is there something in the service principal that identifies it as an agent? It depends on the platform that you're using.

So for Microsoft Copilot Studio platform, you can opt in to basically building agents with agent identities or building agents with service principles. When you go through that path, we still tag that service principle as an agent so that we can help you in your security teams. But again, the approach that we're sharing with customers today is to adopt the agent identity because it gives you that robust security based upon being able to register it, govern and protect AI agents all up.

And then if it's got its unique identity, then I can obviously authorize access to certain objects and files and all this. Okay. You got it. Yep.

So really, at the end of the day, there's really not a heck of a lot of difference between like a normal user or an app and an agent, right? It's just an identity that's just on the agent process. That's it. Well, remember what I mentioned earlier, agents have this thing called, you know, skills and they have these instructions and these profiles that's tied to their orchestration that kind of make them a little bit different than a human, right?

So you, you'll have to, you as a human have to go research knowledge to become smarter. An agent does it, right? They're basically fed these things. And if they need access to a resource, a human basically has to be granted, access from an authorization system.

Just like when they authenticate, they have to actually authenticate to, you know, an identity provider somewhere. Well, agents usually, there's no concept of an identity provider for agents as an example, right? But we do want to make sure when that agent has been created. They actually, when they try to get access to a resource, we are able to actually say, okay, let's grant them access to their resource based upon maybe a token that's given to them through, you know, our token service with agent identity and entra.

Or if they're using the service principle, what kind of service, you know, client credential are they using? And will that protective resource actually take that client credential? That's the question that I think most customers should ask themselves when they're building these agents and trying to bring identity into it. Yeah, but at the end of the day though, right?

I mean, if an agent decides to do something really, really funky, let's just say decides he's going to send an email, that's not going to happen unless the agent has got the right to do that, right? Yeah, that's tied to its role. So remember - Yeah, exactly. Yeah, and that has to be done to that type of agent, right?

So an autonomous agent or an assistive agent, technically cannot do those kind of behaviors. They can't send an email as an example. We've said that identity is very similar. You know, agent identities are basically also very similar to service principle or a human identity.

But are there any specific risks or concerns that we want to think about when thinking about? agent identity specifically? Risks. The sky's the limit when it comes to agent building and how things are evolving.

So risks, obviously there's risk to almost any approach anyone takes when it comes into the world of building agents or agent identity. What I'll say today is adopting agent identity helps organizations, again, start that. agent lifecycle. And it brings the same security controls that we have for humans and user objects to that agent and basically extend it.

One of the things that I usually share with a lot of my customers is when you have an agent that was built somewhere, how does it get access to that particular protected resource? If you don't have a way for that agent to acquire a token or for that agent to be able to do some downstream calls to APIs, then your agent won't be able to actually continuously perform specific actions and tasks that it actually is capable of doing. And so risks, I would say the risk is pretty minimum because it's just adopting just a new mechanism that actually will make your security a little bit more robust.

I think the biggest risk is if you don't use... least privilege, which is something that Mark touched on at the beginning. I mean, you can't just go running an agent with global admin abilities. I mean, that's just terrifying.

So I would say least privilege. I mean, we've always known that least privilege was a big deal, but I would argue that in the case of an agent that is non -deterministic, least privilege is absolutely paramount now. I mean, 100%. I mean, what do we see today?

I think the agents sprawl. are actually growing at a substantial amount that it outnumbers user objects in a lot of customers' tenants today. So there is a risk to least privilege. Got to get a handle on that agent sprawl too.

Yeah, because if the only thing this thing is supposed to do is read over a database and come up with a summary report, it shouldn't have right to that database. It shouldn't be able to touch other databases. It shouldn't be able to send email. So you just have to kind of bring that rigor.

I almost think of some of the stuff that we let, get a little sloppy in the deterministic era, which is document your code. What is it actually supposed to do? And do least privilege. Those things kind of sometimes go by the wayside because the deterministic code does the exact same thing every time and everybody kind of wings it a little bit.

So until an attacker takes it over, it kind of doesn't matter. It really matters when they do. I feel like because of the dynamic nature of these things, because they're not deterministic and they do something a little different each time, that's where your least privilege and you're documenting what it's supposed to do so that someone in six months, eight months, a year, two years, five years knows what this thing is even supposed to do or someone right away knows how to threat model it and what it is supposed to do, what it's not supposed to do or to build a SOC detection or whatever.

That kind of rigor, ironically, gets more important because the easier it is to code the more important is to know what the heck you're actually trying to do i don't think you need to document what it shouldn't do because that list is infinite oh yeah yeah i mean implicit but like essentially this is supposed to do this and nothing else right yeah exactly like you know like you say read a database and this database and in fact only these tables in this database that kind of stuff yeah And if you say only good to go.

Yeah. Yep. A hundred percent. I mean, I would like to add something even that I've seen in a lot of customers environment.

So with the creation and build the building of agents out there, there's so many unpublished agents out there and some of them are published. How about the unpublished ones? Right. It goes back to the problem we had for, you know, some service accounts that people just use just, just for certain things.

Right. It's the same notion. There's a huge risk there because a bad actor could basically come in there and say, oh, let me just only take a look at the unpublished ones because nobody's actually paying attention to those. They only care about the ones that are published.

However, most of those code could just be exposed just as easily, right? Yeah, if you look at some of the work that we did as part of the Secure Future Initiative, a big part of that was removing apps that had essentially been abandoned because no one was maintaining them. And we basically said, if you haven't used an app within N months or whatever it was, we'll give you a warning. And then after that, it's deleted.

I mean, it's gone. Because the attackers don't care, right? The attackers don't care if it's being actively managed or not. If it's there and it's got a bug in it, then they can possibly take it over.

I like what you said before as well, Mark, about... the LLM does the same thing over and over and over again. And in my head I was thinking, yeah, until it doesn't. The deterministic code does the exact same thing every time.

The LLM, not so much. Not so much, yeah. I think what strikes me that I've been talking with folks about is that essentially, and I've been having this conversation now for what, at least a year, 18 months, is that people are worried about AI, of course. worried and think oh there's new security stuff but then you know when we're looking at these agents we're like hey exactly the same things are the problem as in an agent that's over permissioned is going to do some weird stuff and we've been talking about over permissioning and least privilege since the beginning of time so it's i know it just strikes me as amusing that actually the main problems are I say amusing, amusing, maybe not the right word.

It just strikes me as interesting that we're actually same technology, different technology, same problem. Yeah. I mean, there are obviously AI specific security issues that are very concerning, like prompt injection and so on and so forth. But yeah, at the end of the day, a lot of it boils down to just the classics.

I mean, least privilege, you know, was documented. It was known about for a long time, but, you know, kind of the major documentation that was. Salter and Schroeder in the mid -70s. It's been around forever.

Don't lose track of the basics. It's the same today as it was 50 years ago. It's a hard problem, Michael. I think that's why a lot of organizations are trying to figure out, okay, what are some standards?

I really do like the agent factory and the new world everyone's trying to build. based upon like a standards -based approach and trying to get and work together. I mean, that's the approach that we're taking. We're trying to figure out, okay, what is everybody else doing when it comes to their agent building?

And how can we actually get to the portion of least privilege for customers and do what's right to the customer, right? And so we're taking a lot of standards -based approaches, right? And that's a very intricate thing that our team is actually focused on. And one of the standards that I mentioned in the news when we started is the roles and glossary standard, because at the end of the day, the accountability for anything that goes wrong needs to be with a person that actually made the decision, whether it's the developer, the IT person, the business person that says, go push this out there and skip the security.

You know, the outcome of it has to accrue to the person that actually makes the decision. And they need to feel that when they make the decision, not just, oh, I can blame security for this later. So that's why we put that in the standards. So got to plug that one.

Yeah, I mean, that's such a powerful thing. One other plug is obviously when you adopt with agent identity, we have a concept of owner and sponsor. Why do we do that? It's exactly that.

We want to make sure least privilege gets into the person that's creating the agent, the person that's using the agent, and the person that is going to now come in there and secure that agent, right? So making sure. There's accountability for the owner and the sponsors of those agents. So basically you want to know who to yell at.

We want to know who should make a good decision so we can educate them on the policy. That's the ideal state, but afterwards, yeah. All right, let's start to bring this episode to an end. So Nick, actually I think one thing, we didn't have this when we first had you on the podcast, but one question we like to ask our guests is what does a day in the life of Nick look like?

What a great question. A day in the life of Nick looks like meeting with customers, researching what's going on in the world of AI so that I can keep up with all the million different signals that the world is going crazy with with agents. And lastly, just talking and collaborating across Microsoft. Microsoft is a one Microsoft team, so I get to collaborate with a lot of different teams across Microsoft, whether it's internal Microsoft, security teams, red teams.

data scientists, researchers, and other product groups. That's what I get to do every day. So Nick, we always ask this and we warned you, so hopefully you've thought about it. We always ask, if you wanted to leave our listeners with a final thought, what would it be?

I have a couple thoughts here. One, in order to get all your agents under control, it always begins with limiting who can create those agents to begin with. So that's my first thought for the listeners. And I'll say, please adopt agent identity because it gives you a way to register, govern and protect your AI agents and help you secure access to your AI agents so they can get access to protective resources for your organization.

Well, Nick, thanks again for joining us this week. I know you're a really busy guy and you always learn something on these episodes and I certainly did as well. And to all our listeners out there, again, welcome to 2026. We hope you found this episode useful.

Stay safe, and we'll see you next time. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website, azsecuritypodcast .net.

If you have any questions, please find us on Twitter at AzureSecPod. Background music is from ccmixter .com and licensed under the Creative Commons license.