Welcome to the Azure Security Podcast, where
we discuss topics relating to security, privacy,
reliability, and compliance on the Microsoft
Cloud Platform. Hey everyone, welcome to episode
112. This week it's just myself, Michael. Everyone
else is busy. And our guest this week is Ryan
Munch, who's here to talk to us about security
co -pilots and security co -pilot agents. But
before we get to our guest, I just want to take
a little lap around the news. I actually have
some pretty important items to talk about. The
first one, this is honestly just from my old
stomping ground in Azure Data, but this is actually
really important. I really want to stress this
one. There's a blog post written by one of my
old colleagues about why it's time to migrate
from system .data .sqlclient to microsoft .data
.sqlclient. It's not just about adding features.
It's also about the fact that Microsoft .data
.sqlclient will support more security capabilities
moving forward. So for example, things like TLS
being enabled by default, that's all enforced
in the client. So if you've got managed code
that is currently running on system .data .sqlclient,
you need to start moving across to Microsoft
.data .sqlclient. Next one is if you're using
Azure DevTest Labs, we now support Generation
2 VMs using Trusted Launch. So this will give
you much higher kind of robustness and basically
just more secure workloads because it will support
things like secure boot, virtual TPM, virtualization
-based security or VPS, as well as Microsoft
Defender for cloud integration. Next one is virtual
network tap. So we now support a virtual network
terminal access point or a tap that allows you
to continuously stream virtual machine network
traffic to a network packet collector or analysis
tool. Very, very cool. Very commonly used, but
now we support it in our VMs. Azure Front Door
Web Application Firewall, or the WAF, now supports
Capture. This is actually in preview, but it's
great that they've now added Capture support,
which is there to help block malicious automated
requests. Next item is in public preview. We
have inbound private endpoint support for standard
version 2 tier of API management. I mean, I've
talked about this many times, but there are certain
things that are happening across Microsoft, things
like customer managed key support versus system
managed keys, managed identities versus usernames
and passwords. Another big one is better support
for private endpoints. So it's great to see that
API management is now supporting that for standard
V2. Another one which is kind of a little bit
what we're going to talk about for the rest of
the day is Azure Firewall is now integrated with
Microsoft Security Copilot. I'm sure that Ryan
will explain this in a little bit more detail,
but this is something we're certainly seeing
across the board. I probably should add to the
list, managed identities, CMK, and private endpoints.
We're seeing more support for Copilot across
various security workloads. Next one is that
the April 2025 progress report for our Microsoft
Secure Future Initiative is now available. It's
not only available as a document, it's also available
as a recording as well. So you can listen to
it for those who, who have vision impairments
or prefer to listen to it, it's available for
you to listen to as well. And the last item,
before we finally get to Ryan, there's now versionless
customer managed key support in Azure Database
for PostgreSQL. There's a blog post written by
my old colleague and actually co -author as well,
Heinrich Gantenbein, that explains the rationale
why it was done and how that is supported in
Azure Database for PostgreSQL. So again, here's
another example of a product using customer managed
keys. All right, so that's the news out the way.
Now let's turn our attention to our guest. As
I mentioned at the top, our guest this week is
Ryan Munch. Ryan, we'd like to take a moment
and introduce yourself to our listeners. Thanks
for having me on, Michael. It's great to be back.
I'm part of the Microsoft Security Copilot product
team. So in the team, I'm focused on a few different
things. One, growing out our partner ecosystem,
specifically our MSSPs and how they think about
building agents. And then a myriad of different
functionalities, such as logging within Security
Copilot and agents. All right, so let's get stuck
into the agenda. Look, so I mean, you hear sort
of Security Copilot or the term Security Copilot
kind of thrown around almost with abandon. So
what is going on with security co -pilot and
agents, which is what we're here to talk about?
So what should our listeners know about? What's
the elevator pitch? If you were to walk out of
an elevator after talking to somebody, what would
they know about security co -pilot and agents?
We have moved fast in the past year and a half.
We were the first solution out to market. We
have learned a lot, and we have now evolved into
what I think you see typical across a lot of
different Microsoft AI solutions, and that is
we are now an agent -based AI platform. All right,
so a really, really dumb question. When would
people use this? Why would they use agents? There
are examples of where it's being used. I really
want to keep it super practical. What can people
walk away with understanding how it can actually
help them? Yeah, and we've seen an incredible
journey of our customers over the past year and
a half since our private preview and even our
launch. And it started with customers going in
and looking at things like scripts and email
headers and trying to see what AI could do for
them in a security context. We started off working
pretty broadly. And where it's evolved and what
we've seen from our customers is that they are
still workflow and very much task -oriented.
And where we can help the most and where agents
help the most is, we believe, with specific tasks
that are either mundane, repetitive in nature,
or take a lot of manual effort. Stuff that really
pairs well with a human and needs a... analysts
in the loop, but stuff that you don't necessarily
want to do. So a good example of this is user
-submitted phishing email triage. That's one
good case. Vulnerability analysis with whether
or not you patched a system or patched different
applications. That's another practical and pragmatic
use case. The other one that I really like as
well, it kind of gets into more of something
you don't always need, but something that a lot
of security practitioners maybe aren't necessarily
as familiar with as those that live it and breathe
it every day, which is threat intelligence. And
knowing what a threat actor is, how they operate,
or how they specifically would attack your organization
isn't something that everyone is always up to
date on. So that becomes something that can empower
people in a way that would otherwise take a lot
of time. I mean, there are lots of tools that
people use outside of the Microsoft. Are there
integrations with other services that people
may use on a daily basis? Yeah, and this is a
great question. And candidly, it's one of my
favorites because I think it represents a philosophical
shift of how people perceive what Microsoft is
doing, but also reflects a lot of what we passionately
believe that security should do and how it should
operate across any ecosystem. When we look at
what we're trying to achieve with Security Copilot,
we recognize that a workflow could exist in any
state. You could be starting it. You could be
beginning it. You could need to augment it anywhere
in between. And a workflow could persist across
any number of different systems, and it could
exist exclusively outside of a Microsoft system.
So what this means is that we have to build out
a solution, a platform that accounts for all
of that and provides for that possibility. Otherwise,
as a good steward of a solution provider in the
security community, if we're providing a solution
that doesn't allow that expansion, we're creating
another security gap. We're creating a blind
spot. So we are creating and working with agents
from the mindset that this could tie into any
solution in any workflow state. So this ties
into the exact philosophy that we're trying to
part. There's a lot of significant news we've
announced over the past few months, both at Securin
and as well as at RSA. But for me, I think ServiceNow
was a bit of the most significant bits because
it backs up exactly what we've been saying in
that we have to work with partners and we have
to meet users where they are and however they
work. So with ServiceNow, they released a plugin,
but more significantly, they also integrated
Security Co -Pilot into their security operations
center. And that's now something that their customers
in a private preview can go out and enable and
begin to work with. And what this reflects and
what you'll start to see across more and more
different platforms and Microsoft partners, is
you will see security co -pilot live in more
interfaces. You will see agents that are more
accessible. And you will see agents that then
are able to work with you in whatever workflow
you are tasked with. And so it becomes something
that's hands -on and right there for you. Now,
specifically for ServiceNow, what this allows
is kind of exactly what you'd think. Immediate
incident triage. and ability to then advance
it using the power of the security copilot platform.
So sort of keeping with that topic, I mean, why
is it better to use agents than what we've been
using before? And that sounds really silly. Can
you give us some examples of what we were using
before? I mean, what sort of things can using
agents improve over what people are currently
using? Great question that you raised there,
Michael, for a few different reasons. I think
it splits into two facets for me. One is like
the journey of AI, and two, it's the traditional
journey of how you solve solutions in a security
context. So if you think about the AI journey
and where Security Copilot started, we launched
a chat GPT -style interface. And we did so building
on top of what now everyone refers to as a compound
AI system before people even really knew what
that was. We built a stateful AI. We had session
memory. And we worked with multiple LLMs based
on what we decided was relevant for a particular
task that needed to be done. At the core of this,
we built what was called an orchestrator. In
a lot of ways, it was a precursor to what agents
are today. And agents effectively are a means
to decide what system to use against the task
at hand and to provide the end -to -end solutioning,
if you will, of whatever you're trying to achieve
or what the agent is designed to achieve. And
so with agents, in a lot of ways, it represents
an evolution of what we started with, with Security
Co -Pilot and the Orchestrator, to probably what
is something that is more robust, more evolved,
and has a greater industry support. Then if you
pair that with, well, should I build an agent?
And should I work with agents in a security context?
And I would say, and this is a cop -out, I get
it, I would say it depends. It depends on where
you can insert the value of either non -deterministic
solutions, meaning agents can work really well
in a way where it needs to consider different
inputs to provide the ultimate goal and ultimate
output. So if you are looking across, let's just
say, a phishing email triage scenario where you
maybe need to look at a handful of different
indicators, the indicator types are different,
and you need to consider, we'll call it N number
of different sources based on the type of indicator.
Well, if you were to build one standard agent
and you were to deploy that against 50 different
customers, or let's say you were a security provider
and you're working with all your different customer
environments, that could mean that you're working
with any number of different threat intelligence
sources, any number of different vulnerability
scanners, any number of different endpoint systems
that would need to perform the analysis of. does
this phishing email impact my environment? And
if so, how? And what an agent can do in that
case is provide the means in which it can decide
what is available in this deployment, what should
I use to solve and triage this phishing email,
and then provide an output for human review.
Now, if you contrast that to what you have currently
with email triage, You're going to have maybe
some type of script or a SOAR that's going to
go through, pull out those indicators, and enrich
them. But you're going to build that very specifically
for maybe one customer, or maybe you provide
enough branching logic where you cover all those
possibilities. The point is that it becomes something
that's static in nature and also is difficult
or more challenging to maintain over time. The
other part too is when I look at SOARs and when
I think about tips, they generally fall into
the category for me of automate it and forget
it. You're scripting it and you have an input
and output. Agents aren't really built like that.
They are built more from the consideration of
based on how we have gone to solve this particular
task, we want your input to validate the solution.
And that becomes... That becomes a means through
which it takes some of the mundane analysis,
like of a user -submitted phish, automates the
process, and allows for human input. The final
thing that I'd tack on to that scenario, I think
that is also different from a traditional automation
versus what agents can do. is at any point along
the way they can invoke LLMs in a meaningful
way to solve a solution. So the other reason
why an email is a really good articulation of
this emerging and evolution of agents in a security
context is that LLMs can look at the context
of an email and decide the semantics of the language
used. Is this business venture from Nigeria something
I should invest in? Can I really trust this prince?
Those are the things that it's really good at
pointing out and saying, you know what? This
is a phishing email, even though I don't have
any indicators that match. Based on the other
attributes that don't match any known indicators,
we can classify this email as a phishing email.
And then in that moment, what you have that what
you wouldn't have before in a traditional automation
scenario is validation of a phishing email with
net new indicators that you can then keep. store
for any other future analysis. And that becomes
something that's meaningful and impactful in
a security context. You mentioned before you
used the word compound. Does that mean you use
multiple LLMs? Is that the origin of the term?
Is that what's inferred by the word compound
or is it something different than that? Yeah,
great question. So there's a paper that was put
out by the Berkeley AI Research Center or BEAR.
And I probably just killed the acronym, but if
you Bing that, you'll get right there. So they
have this great paper that details a compound
AI system if you want to read the full academic
breakdown. But if you distill it down simply
to what it represents, when AI systems were first
built, they were monolithic in nature. Let's
train an LLM, let's set that loose on a particular
problem, and let's see what it can do. What they
found out is that in the edge cases, especially
in security or in things like healthcare or other
industries that have a lot of specialization
and a lot of unique language or context that's
used, LLMs don't really work. And they don't
work because they miss that information. So compound
AI systems started to address that problem by
integrating or starting to establish more traditional
paradigms of system architecture around the LLM.
So you have to find a way to either take an LLM
and source it with data. So that's what's called
retrieval augmented generation, where a data
store can be used to then infuse the result or
produce a better result for the LLM, where the
LLM can not only... rationalize the information
being retrieved, match it against the context,
and then provide an output. And so that's what,
for Security Copilot, that's why we created the
session. And for everyone's own edification,
that's also why Security Copilot does things
like includes all of Microsoft's threat intelligence
as part of the core product, because we believe
that that should be part of what's included in
any solution. The other thing that it refers
to is that... In a compound AI system, you're
right. You can use multiple LLMs, and you can
be specialized in how you invoke an LLM based
on the need, the context, or otherwise. It gives
some flexibilities in terms of the architecture
to use a smaller LLM in size and training data
or specialization, ultimately. Or in some cases
where you maybe need to process more data. have
a greater token limit, which can be computationally
more expensive and take longer to produce a result,
you can do so. Or if you just need to do a simple
task and you can use a base model and do that
faster and more efficiently. So it gives greater
flexibility for what you'd expect. And that is
addressing the task at hand in the most relevant
way and efficient way possible. Yeah, I'd seen
the term compound thrown around and I just wasn't
sure of the context. So, I mean, at Microsoft,
look, I'm going to be honest, I think at Microsoft
we have a lot of AI solutions right now. And
honestly, for me, it seems a little confusing
as to what does what and so on. So why are agents
different than, say, using Copilot Studio? I
mean, do I use Copilot Studio to create these?
I mean, I don't understand the relationship between
security agents or security Copilot agents. and
all the other sort of AI offerings that we have
at Microsoft. Can you spend just a few minutes
and just sort of compare and contrast? Yeah,
good news, Michael. You're not the only one that
has this same confusion. I was just at RSA, and
I was in a room full of CISOs from Spain, and
they all had similar questions in terms of what
is this agent thing from security co -pilot,
and how is it different than all these other
co -pilot solutions? And I get it. Microsoft
at this point probably has a... a full air show
squadron full of co -pilots. But we have a general
philosophy across Microsoft to learn, to innovate,
and report back across no matter what engineering
group we are to see what we can do to advance
AI solutions. And so what this means is that
in Microsoft, we have different solutions that
are... built for a specific purpose. So for example,
if you wanted to build an AI service yourself
or an AI solution yourself, you would work with
one of our AI services, whether it's Azure AI
Foundry, which deals in AI primitives, or Azure
Open AI Service if you just want to work maybe
with some off -the -shelf models. That's there
if you have the developer mindset and are looking
to build something on your own. If you look to
Copilot Studio, It's a way in which you have,
like, this sea of agents and all these different
business logic solutions that you can use. But
it's generally designed to operate in a business
context for office -related responsibilities.
Now, you can do things, and this is one of the
interesting things I like to point out. Like,
you can, in Copilot Studio, you can call back
to Security Copilot and invoke a prompt and retrieve
that prompt response. And for me, that's significant
because it underscores the point. The reason
why Security Copilot is its own platform is that
we have to build agents in a security context
that can operate across an enterprise in a way
that demands a high level of workload capability,
reliability, but also security. And that means
we have to build it a little bit differently
to handle all those specific use cases. Copilot
Studio, if you're going out to summarize a document
or summarize a Teams chat, you're usually operating
in a user context that's like one or a few. But
if you're looking at, for example, find me all
these user -submitted phishing emails and triage
them, well, you can be talking about anywhere
from one email to potentially a few hundred or
thousand. And that becomes a different way in
which we have to think about architecture. It's
interesting you should bring up that you're talking
to people at RSA. I see that at RSA we announced
a book of news that talked about partner agents
and so on. Could you sort of explain that in
a bit more detail, like what was announced? Yeah,
at RSA, we announced a few things. We followed
up on Microsoft Secure and highlighted the partner
agents across Microsoft that we've built. So,
for example, there's a conditional access agent
that exists for Microsoft Intra where you can
activate in the Intra portal. There's a threat
intel briefing agent, a vulnerability remediation
agent from Intune. And then I talked about a
little bit of the phishing use case. Well, sure
enough, the Defender team saw the value, too,
and they built out their agent. to do exactly
that. And there's also an alert triage agent
for Microsoft Purview. Now, on the other end,
we have a ton of stuff that was released by partners.
We have initial five that came out from both
across what we call our partner developers as
well as our MSSPs. We had seven agents announced
there, and we had a few different plugins as
well. In addition to ServiceNow, we had Splunk
and HP and Census all provide some plugins. And
I'm going to quickly differentiate or call out
plugins are what we used initially with Security
Copilot to connect to systems. Plugins are now
something that we can use in agents and use in
an agent runtime. So it's all complementary architecture
and complementary solutions. But the significance
of this news, in addition to what I talked about
earlier of ServiceNow, is that it shows the depth
of the ecosystem that's emerging and our desire
to continue to expand across solutions that are
most impactful and relevant for our customers
to solve real -world problems that they deal
with every day. Okay, let's just bring it back
to sort of my neck of the woods, which is development.
So if I want to use one of these security copilot
agents in my code, what do I need to do? Is this
something that developers would do? Or is there
like some drag and drop interface that a non
-developer can do? Like the current sort of coding
du jour, you know, vibe coding? I mean, is that
a possibility? Or is this really something from
a development, like from a producing something?
Is this something that a developer would have
to do writing, say, code in, say, C Sharp or
Python or something like that? Well, I think
vibe coding is generally something you could
do at any time in any interface. I think you
just need a beer and a lot of will to do whatever.
Now, for what we're going to do with Security
Copilot, this is where I got to be careful here
not to get ahead of some of our news that's coming
up at Build and other events. But what I'd stress
is that in our recognition that we are heading
down the direction of being a... agentic platform
for a security context, we need to provide different
ways for the Michaels of the world to go out
and develop agents effectively. So we've had
conversations against low code and no code and
we'll call it, I guess, hardcore coding experiences
and how you would go out and build agents and
build agents effectively. Today, what you'd see
is like at minimum, you could still work with
a manifest file like you do with plugins. But
we want to make some of that stuff more accessible
in ways that people would then extend the security
copilot and build and bring agent functionality
more readily in ways that empower them to work
with their preferred tools. All right, so Ryan,
I think it's probably time to start bringing
this episode to an end. One thing we ask all
our guests is what does a typical day in Ryan's
day look like? So day in the life of me, it's
just as chaotic as what you'd think. Working
in a product team that works on AI, launching
agents and expanding in the way that we are means
I'm pretty busy with a lot of different things.
First and foremost, there's a good amount of
time that I spend each day trying to stay up
with what is going on with AI, how I can stay
smart, remain smart, and anchor in both current
conversations as well as future ones and future
designs and how we continue to evolve our AI
solution and continue to meet the needs of our
partners and customers. The other thing I spend
a lot of time on in my day is talking to our
partners. what they want to build, how they want
to build it, how they can best service their
customers so that they can build agents and think
about how they want to deliver agents to their
customers to empower them in practical security
workflows. With agents, it's been something that
is net new to them, and it represents an exciting
opportunity. And so for me, as well as them,
we get to talk about a lot of just general AI
philosophy, and I love that. And then the final
bit I think that probably the non -work stuff
is a good way for me to relax and get out of
the AI headspace for a bit or maybe think a little
bit more clearly is I usually will end my day
with a swim at an outdoor pool for a good 3 ,000
yards to wrap it up. And once I do that, then
I'm usually ready for a bit more AI things before
I call it a day. It's funny you should mention
sort of staying on top of things and constantly
learning. I think that's so critically important
in this. not just today, but also in the area
of security and AI. And one thing that sort of
really hit me the other day, just how true this
is, I was in a call with a corporate VP, actually
a bunch of corporate VPs, and we were explaining
a vulnerability class. And this particular VP
in question didn't understand all the nuances
of it. It would have been very easy as a corporate
VP for that person to say, hey, I know about
this, but he didn't. and he ended up setting
up a meeting called Make John Smart. And it was
basically a 30 -minute meeting with a bunch of
us to go through this vulnerability class so
that he fully understood the vulnerability and
all the implications of it. That, to me, is a
really good example of someone who's incredibly
senior in the company recognizing they don't
know something, but also recognizing they kind
of need to know it, too, and doing whatever it
takes to make sure that they learn that thing.
My hat's off to people who want to continually
learn. I think that's just absolutely just so,
so, so critical, especially now with AI. So one
thing we always ask our guests is if you had
just one final thought to leave our listeners
with, what would it be? I think it's going to
be the approach for how everyone... rationalizes
agents and AI. Having walked the show floor of
RSA just over the past week, everyone is talking
about it. It's literally the talk of security
and the talk of, well, our industry, the broader
tech industry. So when you rationalize agents,
you should think about how you're going to adopt
them and what are your criteria to adopt them.
And at its core of that, I would say think about
agent transparency, how you can see what they
decide. how you can see how they handle data,
what outputs of data they provide, and probably
most importantly, what they're doing to show
you it's logging an activity. Through all of
that, and I believe fundamentally, you should
not implicitly trust a new system without getting
a good handle and understanding of it. When it
comes to AI, establishing a trust framework is
even more important. And so as you think about
adopting agents, make sure you have that trust
framework in mind. Work to achieve transparency
and through transparency, learn to understand
how agents operate and how you can trust them
or work to trust them inside of your environment.
Yeah, and on that topic, make sure if you're
listening, people listening to this and you're
not sure kind of what Ryan's alluding to, go
and listen to our previous episode on that very
topic about trusting agents, you know, because
the things that you do need to be aware of. All
right. So let's bring this episode to an end.
Orion, thank you so much for joining us this
week. I learned a ton. I learned a ton on all
the episodes, but this one very, very much so.
I think that the intersection of security and
agents is just mind -blowing. I think the possibilities,
especially when we're dealing with AI -based
attacks as well, we're putting up some sort of
defensive mechanisms, so that's huge as well.
So again, thank you for joining us. And to all
our listeners out there, we hope you found this
episode of use. Stay safe, and we'll see you
next time.