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.