Your AI Agents Are Orphaned- The Structural Shift to Agent ID

1
00:00:00,000 --> 00:00:02,320
Right now, somewhere in your tenant an AI agent

2
00:00:02,320 --> 00:00:04,120
has access to your most sensitive data.

3
00:00:04,120 --> 00:00:05,560
And nobody can tell you who owns it.

4
00:00:05,560 --> 00:00:07,400
That isn't a hypothetical scenario.

5
00:00:07,400 --> 00:00:09,520
It's the reality for most organizations today.

6
00:00:09,520 --> 00:00:10,680
But here's the problem.

7
00:00:10,680 --> 00:00:13,800
You're treating AI agents like simple apps or service accounts.

8
00:00:13,800 --> 00:00:14,840
That's a structural error.

9
00:00:14,840 --> 00:00:16,920
It's going to cost you control of your data,

10
00:00:16,920 --> 00:00:19,800
your identity fabric, and your compliance posture.

11
00:00:19,800 --> 00:00:21,880
The move from co-pilot to agent 365

12
00:00:21,880 --> 00:00:23,520
isn't just a feature update.

13
00:00:23,520 --> 00:00:25,080
It's a governance architecture change.

14
00:00:25,080 --> 00:00:27,280
By the end of this, you'll understand why agent ID

15
00:00:27,280 --> 00:00:29,360
is the only real path to scaling AI

16
00:00:29,360 --> 00:00:30,800
without losing accountability.

17
00:00:30,800 --> 00:00:33,680
Because the window to get this right is closing fast.

18
00:00:33,680 --> 00:00:35,440
The problem nobody's talking about.

19
00:00:35,440 --> 00:00:37,080
Let's start with what's actually happening

20
00:00:37,080 --> 00:00:38,440
in your tenant right now.

21
00:00:38,440 --> 00:00:39,720
Because it's probably not what you think.

22
00:00:39,720 --> 00:00:41,400
Shadow AI agents are multiplying.

23
00:00:41,400 --> 00:00:43,360
Someone in finance spun up a co-pilot studio

24
00:00:43,360 --> 00:00:46,160
bought last quarter, someone in IT built an automation script

25
00:00:46,160 --> 00:00:49,080
that calls into graph, and someone in HR connected

26
00:00:49,080 --> 00:00:50,520
a chatbot to SharePoint.

27
00:00:50,520 --> 00:00:52,480
None of it went through a formal review.

28
00:00:52,480 --> 00:00:54,520
None of it shows up in a clean inventory.

29
00:00:54,520 --> 00:00:56,000
And none of it was built with the assumption

30
00:00:56,000 --> 00:00:57,720
that it would need to be governed, audited,

31
00:00:57,720 --> 00:00:58,920
or retired someday.

32
00:00:58,920 --> 00:00:59,920
But here's why this happened.

33
00:00:59,920 --> 00:01:01,000
Service principles.

34
00:01:01,000 --> 00:01:03,400
The identity objects most of these agents rely on

35
00:01:03,400 --> 00:01:06,440
were never designed for autonomous tool using AI systems.

36
00:01:06,440 --> 00:01:08,560
They were built for a different job entirely.

37
00:01:08,560 --> 00:01:11,200
The container doesn't match what you're putting inside it.

38
00:01:11,200 --> 00:01:13,960
That mismatch shows up first as credential sprawl.

39
00:01:13,960 --> 00:01:16,680
Secrets get scattered across scripts, pipelines, and vaults.

40
00:01:16,680 --> 00:01:19,240
Sometimes they're hard-coded, and sometimes they're rotated

41
00:01:19,240 --> 00:01:20,400
on nobody's schedule.

42
00:01:20,400 --> 00:01:22,240
Every one of those secrets is a door.

43
00:01:22,240 --> 00:01:23,680
And when you've got hundreds of agents

44
00:01:23,680 --> 00:01:26,400
each holding their own credential, you've got hundreds of doors.

45
00:01:26,400 --> 00:01:27,800
Most of them are unlocked.

46
00:01:27,800 --> 00:01:29,080
Most of them are forgotten.

47
00:01:29,080 --> 00:01:30,240
Then there's the orphan problem.

48
00:01:30,240 --> 00:01:32,800
An agent gets built for a project, the project ships,

49
00:01:32,800 --> 00:01:35,360
and the person who built it moves teams or leaves the company.

50
00:01:35,360 --> 00:01:37,000
The agent keeps running.

51
00:01:37,000 --> 00:01:38,440
Nobody knows who owns it anymore.

52
00:01:38,440 --> 00:01:39,960
Nobody knows what it's touching.

53
00:01:39,960 --> 00:01:41,560
And nobody knows why it still exists.

54
00:01:41,560 --> 00:01:42,720
It's not malicious.

55
00:01:42,720 --> 00:01:45,440
It's just unaccounted for.

56
00:01:45,440 --> 00:01:47,520
And unaccounted for is exactly the condition

57
00:01:47,520 --> 00:01:49,960
auditors hate most, which brings us to compliance risk.

58
00:01:49,960 --> 00:01:51,360
This is where it gets serious.

59
00:01:51,360 --> 00:01:53,720
When an auditor asks who authorised an agent

60
00:01:53,720 --> 00:01:56,040
to read customer records, you need an answer

61
00:01:56,040 --> 00:01:58,120
that traces back to a human decision maker.

62
00:01:58,120 --> 00:02:01,360
Right now, for most organisations, that trace goes cold.

63
00:02:01,360 --> 00:02:03,400
The service principle shows a client ID.

64
00:02:03,400 --> 00:02:04,880
But it doesn't show a person.

65
00:02:04,880 --> 00:02:06,800
It doesn't show a business justification.

66
00:02:06,800 --> 00:02:08,160
And it doesn't show a review date.

67
00:02:08,160 --> 00:02:10,600
You're left explaining a gap, not a control.

68
00:02:10,600 --> 00:02:12,600
And here's the part that should really get your attention.

69
00:02:12,600 --> 00:02:13,800
This is small right now.

70
00:02:13,800 --> 00:02:15,240
Microsoft's own internal numbers

71
00:02:15,240 --> 00:02:17,120
point to adding thousands of agents a week.

72
00:02:17,120 --> 00:02:18,480
And they expect to have more agents

73
00:02:18,480 --> 00:02:19,880
than employees before long.

74
00:02:19,880 --> 00:02:21,560
The direction is the same everywhere.

75
00:02:21,560 --> 00:02:24,320
You're heading toward a population of non-human identities

76
00:02:24,320 --> 00:02:26,280
that outnumbers your human workforce.

77
00:02:26,280 --> 00:02:28,200
And you're using a governance model that was never

78
00:02:28,200 --> 00:02:30,160
built to handle scale like that.

79
00:02:30,160 --> 00:02:31,920
Think about what your identity team currently

80
00:02:31,920 --> 00:02:33,320
does for a new employee.

81
00:02:33,320 --> 00:02:35,680
Background checks, roll assignments, access reviews,

82
00:02:35,680 --> 00:02:37,640
manager sign-offs, off-boarding checklists.

83
00:02:37,640 --> 00:02:39,120
Now ask yourself, does any of that

84
00:02:39,120 --> 00:02:42,120
exist for the agent your marketing team spun up last week?

85
00:02:42,120 --> 00:02:44,000
For most companies, the honest answer is no.

86
00:02:44,000 --> 00:02:44,760
There's no onboarding.

87
00:02:44,760 --> 00:02:45,560
There's no off-boarding.

88
00:02:45,560 --> 00:02:46,600
There's no manager.

89
00:02:46,600 --> 00:02:48,640
There's just an app registration sitting quietly

90
00:02:48,640 --> 00:02:49,760
in the directory.

91
00:02:49,760 --> 00:02:51,360
Doing whatever it was told to do.

92
00:02:51,360 --> 00:02:53,880
For as long as nobody notices it, that's the setup.

93
00:02:54,880 --> 00:02:57,120
Now let's diagnose exactly why the tool

94
00:02:57,120 --> 00:03:00,000
you're using to solve this problem is the wrong tool for the job.

95
00:03:00,000 --> 00:03:02,160
Why service principles fail for AI?

96
00:03:02,160 --> 00:03:04,080
To understand the fix, we need to diagnose

97
00:03:04,080 --> 00:03:05,480
why the old model breaks.

98
00:03:05,480 --> 00:03:07,080
And it breaks at the architecture level,

99
00:03:07,080 --> 00:03:08,680
not the configuration level.

100
00:03:08,680 --> 00:03:11,800
Service principles were built for static, long-lived applications.

101
00:03:11,800 --> 00:03:14,200
Think of a billing system that calls an API every night

102
00:03:14,200 --> 00:03:16,960
at 2am or a backend service that syncs data

103
00:03:16,960 --> 00:03:18,240
between two systems.

104
00:03:18,240 --> 00:03:19,560
That workload is predictable.

105
00:03:19,560 --> 00:03:21,960
It does the same thing the same way on the same schedule

106
00:03:21,960 --> 00:03:22,840
for years.

107
00:03:22,840 --> 00:03:25,200
You register it once, granted permissions once,

108
00:03:25,200 --> 00:03:26,480
and mostly leave it alone.

109
00:03:26,480 --> 00:03:28,120
AI agents don't behave that way.

110
00:03:28,120 --> 00:03:28,880
They're dynamic.

111
00:03:28,880 --> 00:03:31,360
They're often ephemeral spun up for a task, run for minutes,

112
00:03:31,360 --> 00:03:32,200
and then they're gone.

113
00:03:32,200 --> 00:03:34,920
They make decisions based on context that changes from call

114
00:03:34,920 --> 00:03:35,680
to call.

115
00:03:35,680 --> 00:03:38,440
An agent might read a document, decide it needs another data

116
00:03:38,440 --> 00:03:40,920
source, call a different tool, and then hand

117
00:03:40,920 --> 00:03:42,200
off to another agent entirely.

118
00:03:42,200 --> 00:03:44,600
That's not a static workload wearing a slightly different hat.

119
00:03:44,600 --> 00:03:46,280
That's a completely different operating pattern

120
00:03:46,280 --> 00:03:47,720
than the identity model underneath it

121
00:03:47,720 --> 00:03:48,840
needs to reflect that.

122
00:03:48,840 --> 00:03:51,120
But here's where the architecture actually breaks down.

123
00:03:51,120 --> 00:03:53,240
A service principle has a one-to-one relationship

124
00:03:53,240 --> 00:03:54,600
with an app registration.

125
00:03:54,600 --> 00:03:56,920
One app, one service principle, pertinent.

126
00:03:56,920 --> 00:03:58,920
There's no concept of instanting built-in.

127
00:03:58,920 --> 00:04:01,120
So if you want 20 instances of the same agent

128
00:04:01,120 --> 00:04:03,800
doing slightly different jobs across 20 departments,

129
00:04:03,800 --> 00:04:06,440
you don't get 20 identities with a shared lineage.

130
00:04:06,440 --> 00:04:09,520
You either build 20 separate app registrations manually,

131
00:04:09,520 --> 00:04:12,320
one at a time, or you cram all 20 use cases

132
00:04:12,320 --> 00:04:14,800
behind a single identity and lose any ability

133
00:04:14,800 --> 00:04:16,280
to tell them apart later.

134
00:04:16,280 --> 00:04:18,640
Now multiply that by credential management.

135
00:04:18,640 --> 00:04:21,200
Every service principle needs its own way to authenticate,

136
00:04:21,200 --> 00:04:22,760
whether that's a secret, a certificate,

137
00:04:22,760 --> 00:04:24,320
or a managed identity binding.

138
00:04:24,320 --> 00:04:26,600
Thousands of agents means thousands of credentials

139
00:04:26,600 --> 00:04:28,480
to create, rotate, and protect.

140
00:04:28,480 --> 00:04:30,960
Most identity teams already struggle to rotate secrets

141
00:04:30,960 --> 00:04:32,720
on a few hundred service principles.

142
00:04:32,720 --> 00:04:34,960
Ask them to do that across a population of agents

143
00:04:34,960 --> 00:04:36,560
that outnumbers their employees.

144
00:04:36,560 --> 00:04:38,840
And the answer isn't, we'll manage it.

145
00:04:38,840 --> 00:04:41,240
The answer is, we'll stop rotating them, which

146
00:04:41,240 --> 00:04:43,520
is exactly how credential compromise becomes a matter

147
00:04:43,520 --> 00:04:44,760
of when, not if.

148
00:04:44,760 --> 00:04:47,320
Logging makes this worse, because it hides the very thing

149
00:04:47,320 --> 00:04:48,600
you need to see.

150
00:04:48,600 --> 00:04:50,760
When a service principle acts, the logs show

151
00:04:50,760 --> 00:04:52,880
that service principle's identity as the client.

152
00:04:52,880 --> 00:04:56,080
If you've got one identity standing behind 50 logical agent

153
00:04:56,080 --> 00:04:58,240
instances, every one of those 50 shows up

154
00:04:58,240 --> 00:05:00,440
looking identical in your sign in logs.

155
00:05:00,440 --> 00:05:02,400
You can't tell which instance did what.

156
00:05:02,400 --> 00:05:04,280
You can't build an audit trail that says,

157
00:05:04,280 --> 00:05:07,160
this specific agent running this specific task,

158
00:05:07,160 --> 00:05:08,600
access this specific record.

159
00:05:08,600 --> 00:05:10,160
You just get a wall of identical entries

160
00:05:10,160 --> 00:05:11,600
in no way to pull them apart.

161
00:05:11,600 --> 00:05:13,240
So what do most teams do when they can't

162
00:05:13,240 --> 00:05:14,840
scope permissions per agent?

163
00:05:14,840 --> 00:05:16,760
They overprivilege the whole class.

164
00:05:16,760 --> 00:05:19,200
Instead of granting narrow task specific access

165
00:05:19,200 --> 00:05:21,600
to each instance, they grant broad permissions

166
00:05:21,600 --> 00:05:23,800
to the shared identity, because narrowing it down

167
00:05:23,800 --> 00:05:26,720
would mean building separate infrastructure for every use case.

168
00:05:26,720 --> 00:05:28,640
That's not a security team failing at their job.

169
00:05:28,640 --> 00:05:31,360
That's the identity model forcing them into a bad trade-off,

170
00:05:31,360 --> 00:05:34,480
and then there's retirement, or rather, the absence of it.

171
00:05:34,480 --> 00:05:36,720
Classic service principles don't come with lifecycle governance

172
00:05:36,720 --> 00:05:37,280
baked in.

173
00:05:37,280 --> 00:05:39,520
There's no expiration date tied to business need,

174
00:05:39,520 --> 00:05:42,760
no automatic review cycle, and no clean deprovisioning path.

175
00:05:42,760 --> 00:05:45,440
An agent finishes its purpose, and the service principle

176
00:05:45,440 --> 00:05:48,040
just sits there credentials intact, permissions intact,

177
00:05:48,040 --> 00:05:49,840
waiting for someone to remember it exists.

178
00:05:49,840 --> 00:05:50,440
Nobody does.

179
00:05:50,440 --> 00:05:51,480
That's not a policy gap.

180
00:05:51,480 --> 00:05:53,560
That's what happens when the underlying object was never

181
00:05:53,560 --> 00:05:56,400
designed to expire in the first place.

182
00:05:56,400 --> 00:05:59,520
The event that changed everything, Microsoft saw this coming.

183
00:05:59,520 --> 00:06:01,680
Here's what they built to fix it.

184
00:06:01,680 --> 00:06:04,480
Mark the date, May 1, 2026.

185
00:06:04,480 --> 00:06:07,200
That's when agent 365 and Entra Agent ID

186
00:06:07,200 --> 00:06:09,080
reached general availability.

187
00:06:09,080 --> 00:06:11,320
And I want to be precise about what actually shifted,

188
00:06:11,320 --> 00:06:13,640
because it's easy to hear new product and tune out.

189
00:06:13,640 --> 00:06:14,800
This isn't a new product.

190
00:06:14,800 --> 00:06:16,280
It's a new identity type.

191
00:06:16,280 --> 00:06:19,480
Up to this point, every non-human actor in your directory

192
00:06:19,480 --> 00:06:21,720
has been forced into one of two boxes.

193
00:06:21,720 --> 00:06:23,880
User or application.

194
00:06:23,880 --> 00:06:25,520
Agent ID creates a third box.

195
00:06:25,520 --> 00:06:28,000
An AI agent is no longer a hidden component

196
00:06:28,000 --> 00:06:29,840
riding inside an app registration.

197
00:06:29,840 --> 00:06:32,400
It's a first class identity, sitting alongside users

198
00:06:32,400 --> 00:06:35,000
and service principles in Entra ID, with its own object,

199
00:06:35,000 --> 00:06:37,600
its own lineage, and its own governance surface.

200
00:06:37,600 --> 00:06:40,200
Here's how they solved the instant problem we just walked through.

201
00:06:40,200 --> 00:06:43,120
Instead of one app registration producing one identity,

202
00:06:43,120 --> 00:06:45,040
Microsoft introduced the blueprint.

203
00:06:45,040 --> 00:06:47,320
A blueprint is a template created once

204
00:06:47,320 --> 00:06:50,480
that can spawn hundreds or thousands of individual agent identities.

205
00:06:50,480 --> 00:06:52,400
Each instance gets its own object ID.

206
00:06:52,400 --> 00:06:54,680
Each instance shows up separately in your logs.

207
00:06:54,680 --> 00:06:56,800
20 departments running the same agent type

208
00:06:56,800 --> 00:06:59,560
no longer means 20 manually built registrations

209
00:06:59,560 --> 00:07:01,200
or one blurry shared identity.

210
00:07:01,200 --> 00:07:04,560
It means one blueprint, 20 distinct, trackable instances.

211
00:07:04,560 --> 00:07:05,800
Then there's the credential fix,

212
00:07:05,800 --> 00:07:08,080
and this is the part that should actually change how you sleep

213
00:07:08,080 --> 00:07:08,760
at night.

214
00:07:08,760 --> 00:07:10,600
Agents themselves don't hold secrets.

215
00:07:10,600 --> 00:07:12,240
The blueprint holds the credential,

216
00:07:12,240 --> 00:07:13,880
whether that's a managed identity,

217
00:07:13,880 --> 00:07:15,960
a certificate, or a federated trust.

218
00:07:15,960 --> 00:07:17,960
The agent authenticates through the blueprint,

219
00:07:17,960 --> 00:07:21,280
not with its own standalone secret sitting in a script somewhere.

220
00:07:21,280 --> 00:07:24,280
So instead of thousands of credentials scattered across your environment,

221
00:07:24,280 --> 00:07:27,360
you're managing a much smaller number of blueprint-level credentials,

222
00:07:27,360 --> 00:07:30,240
centrally, with real rotation discipline behind them.

223
00:07:30,240 --> 00:07:33,040
And here's the piece that directly answers the often problem.

224
00:07:33,040 --> 00:07:35,640
Every agent identity now requires a sponsor.

225
00:07:35,640 --> 00:07:37,600
Not a developer, not a team alias,

226
00:07:37,600 --> 00:07:40,680
but a named human who is accountable for why that agent exists,

227
00:07:40,680 --> 00:07:44,000
what it's allowed to touch, and whether it still needs to exist next quarter.

228
00:07:44,000 --> 00:07:45,960
No sponsor, no agent.

229
00:07:45,960 --> 00:07:47,720
That single requirement closes the gap

230
00:07:47,720 --> 00:07:51,360
that let agents linger for years without anyone able to explain their presence.

231
00:07:51,360 --> 00:07:52,880
I want to be clear about what this is not.

232
00:07:52,880 --> 00:07:55,040
This is not Microsoft bolting a dashboard

233
00:07:55,040 --> 00:07:56,440
onto the old service principal model

234
00:07:56,440 --> 00:07:57,720
and calling it agent governance.

235
00:07:57,720 --> 00:08:01,000
This is a rebuild of how identity works for non-human actors

236
00:08:01,000 --> 00:08:02,880
from the object type up.

237
00:08:02,880 --> 00:08:04,680
The Instancing model, the Credential model,

238
00:08:04,680 --> 00:08:08,120
and the Accountability model all break from what came before at the same time

239
00:08:08,120 --> 00:08:10,040
because all three problems were connected.

240
00:08:10,040 --> 00:08:11,080
That's the shift.

241
00:08:11,080 --> 00:08:13,960
Now we need to open it up and actually look at how a blueprint works

242
00:08:13,960 --> 00:08:18,120
piece by piece because the architecture itself is where the real discipline lives.

243
00:08:18,120 --> 00:08:20,000
Understanding agent ID blueprints.

244
00:08:20,000 --> 00:08:22,720
The architecture is elegant once you see the pieces laid out.

245
00:08:22,720 --> 00:08:23,920
But here's the problem.

246
00:08:23,920 --> 00:08:26,040
Most people think of an agent as a single object.

247
00:08:26,040 --> 00:08:27,720
In reality, it starts with the blueprint.

248
00:08:27,720 --> 00:08:29,800
Think of the blueprint as a reusable template.

249
00:08:29,800 --> 00:08:31,120
It defines three things.

250
00:08:31,120 --> 00:08:34,760
What the agent is, what it's allowed to do, and how it proves its identity.

251
00:08:34,760 --> 00:08:37,360
You build this once, and inside that definition,

252
00:08:37,360 --> 00:08:40,720
you set the roles, the Microsoft Graph Scopes, and the Authentication method.

253
00:08:40,720 --> 00:08:42,560
Everything downstream inherits from this.

254
00:08:42,560 --> 00:08:44,400
That inheritance is where the scaling happens

255
00:08:44,400 --> 00:08:46,640
because one blueprint doesn't just produce one agent.

256
00:08:46,640 --> 00:08:48,040
It produces a class of agents.

257
00:08:48,040 --> 00:08:50,560
You could spin up 10 instances for regional offices

258
00:08:50,560 --> 00:08:52,960
or 2,000 instances for customer accounts

259
00:08:52,960 --> 00:08:55,840
and every single one traces back to that same template.

260
00:08:55,840 --> 00:08:58,880
The blueprint isn't just a naming convention or a folder structure.

261
00:08:58,880 --> 00:09:02,000
It's the actual source of permissions for everything spawned underneath it.

262
00:09:02,000 --> 00:09:04,320
But here's where it gets useful for real world design.

263
00:09:04,320 --> 00:09:06,360
Permission inheritance isn't all or nothing.

264
00:09:06,360 --> 00:09:08,760
Agents pull their baseline roles from the blueprint,

265
00:09:08,760 --> 00:09:12,040
but individual instances can pick up extra permissions on top of that.

266
00:09:12,040 --> 00:09:14,600
A finance agent built from a shared document assistant blueprint

267
00:09:14,600 --> 00:09:17,240
might inherit read access to SharePoint by default,

268
00:09:17,240 --> 00:09:20,600
but then it gets a specific grant to touch a finance-only data source.

269
00:09:20,600 --> 00:09:24,120
You get consistency at the class level and precision at the instance level.

270
00:09:24,120 --> 00:09:26,920
You don't have to rebuild the whole permission set from scratch

271
00:09:26,920 --> 00:09:28,680
every time you need a new instance.

272
00:09:28,680 --> 00:09:30,520
Now let's look at the Authentication model.

273
00:09:30,520 --> 00:09:33,960
This is the part that actually removes the credential sprawl problem

274
00:09:33,960 --> 00:09:35,480
instead of just relabeling it.

275
00:09:35,480 --> 00:09:38,600
The blueprint holds the credential that could be a managed identity,

276
00:09:38,600 --> 00:09:40,760
a certificate or a federated trust.

277
00:09:40,760 --> 00:09:43,720
The agents themselves never touch a secret directly.

278
00:09:43,720 --> 00:09:47,240
When an agent needs to act, the blueprint acquires a token on its behalf

279
00:09:47,240 --> 00:09:48,920
and performs a token exchange.

280
00:09:48,920 --> 00:09:52,840
The resulting token identifies that specific agent instance as the client.

281
00:09:52,840 --> 00:09:55,240
It sounds technical, but the payoff is simple.

282
00:09:55,240 --> 00:09:57,480
Your audit logs show the individual agent,

283
00:09:57,480 --> 00:09:59,480
not a generic blueprint identity,

284
00:09:59,480 --> 00:10:02,120
even though the blueprint did the actual authenticating.

285
00:10:02,120 --> 00:10:03,880
That distinction matters more than it sounds.

286
00:10:03,880 --> 00:10:06,520
It means you get centralized credential control

287
00:10:06,520 --> 00:10:08,920
and per instance accountability at the same time.

288
00:10:08,920 --> 00:10:11,880
You're not choosing between easy to manage and easy to audit.

289
00:10:11,880 --> 00:10:13,240
The architecture gives you both.

290
00:10:13,240 --> 00:10:15,480
The blueprint absorbs the operational burden.

291
00:10:15,480 --> 00:10:18,680
The agent identity absorbs the responsibility for the audit trail.

292
00:10:18,680 --> 00:10:20,280
One more piece worth understanding.

293
00:10:20,280 --> 00:10:22,200
Agents operate in two distinct modes.

294
00:10:22,200 --> 00:10:24,600
Attended agents act on behalf of assigned inhuman.

295
00:10:24,600 --> 00:10:28,120
They use delegated permissions, much like how an app acts as you

296
00:10:28,120 --> 00:10:29,880
when you granted consent.

297
00:10:29,880 --> 00:10:32,760
Unattended agents act under their own authority entirely.

298
00:10:32,760 --> 00:10:34,200
There is no human in the loop,

299
00:10:34,200 --> 00:10:37,000
and they run against app assigned roles through standard RBAC.

300
00:10:37,000 --> 00:10:39,480
It's the same blueprint architecture underneath,

301
00:10:39,480 --> 00:10:41,640
but the risk profiles are very different.

302
00:10:41,640 --> 00:10:43,160
When you put all of this together,

303
00:10:43,160 --> 00:10:45,240
you can see what the design is actually doing.

304
00:10:45,240 --> 00:10:47,160
It's not adding complexity for its own sake.

305
00:10:47,160 --> 00:10:50,280
It's centralizing the parts that are dangerous to leave decentralized,

306
00:10:50,280 --> 00:10:51,320
like credentials,

307
00:10:51,320 --> 00:10:53,640
while decentralizing the parts that need precision.

308
00:10:53,640 --> 00:10:56,920
That's the trade the old service principle model could never make.

309
00:10:56,920 --> 00:10:59,800
It had no concept of a blueprint sitting above the identity.

310
00:10:59,800 --> 00:11:01,000
With that structure in place,

311
00:11:01,000 --> 00:11:03,400
we can zoom out and look at the full identity hierarchy.

312
00:11:03,400 --> 00:11:05,080
Blueprints are only one layer.

313
00:11:05,080 --> 00:11:07,320
The identity hierarchy.

314
00:11:07,320 --> 00:11:10,360
We need to understand the layers of identity that make this work.

315
00:11:10,360 --> 00:11:11,560
Because in reality,

316
00:11:11,560 --> 00:11:13,080
agent ID isn't one object.

317
00:11:13,080 --> 00:11:14,040
It's a stack.

318
00:11:14,040 --> 00:11:16,120
Each layer exists to solve a governance problem.

319
00:11:16,120 --> 00:11:17,480
The layer below it can't.

320
00:11:17,480 --> 00:11:18,360
Start at the top.

321
00:11:18,360 --> 00:11:21,480
The agent identity blueprint is the template we just walked through.

322
00:11:21,480 --> 00:11:22,600
It's owned by whoever built it,

323
00:11:22,600 --> 00:11:25,400
whether that's your internal platform team or an ISV.

324
00:11:25,400 --> 00:11:26,760
This is the master definition,

325
00:11:26,760 --> 00:11:28,920
and it isn't tied to any single tenant yet.

326
00:11:28,920 --> 00:11:31,720
Below that sits the blueprint service principle.

327
00:11:31,720 --> 00:11:34,920
This is where the blueprint actually lands inside your tenant.

328
00:11:34,920 --> 00:11:37,320
When your organization consents to use a blueprint,

329
00:11:37,320 --> 00:11:39,640
you get a tenant-specific manifestation of it.

330
00:11:39,640 --> 00:11:41,720
This is the object that holds credentials

331
00:11:41,720 --> 00:11:42,840
and does the authenticating.

332
00:11:42,840 --> 00:11:44,280
It's the operational anchor.

333
00:11:44,280 --> 00:11:46,760
It's the thing your identity team can point to and say,

334
00:11:46,760 --> 00:11:48,760
this is the trust relationship we approved.

335
00:11:48,760 --> 00:11:49,960
Then underneath that,

336
00:11:49,960 --> 00:11:51,960
you get the agent identities themselves.

337
00:11:51,960 --> 00:11:53,960
Each instance spawned from the blueprint

338
00:11:53,960 --> 00:11:55,880
is its own service principle,

339
00:11:55,880 --> 00:11:58,600
but it's tagged with a specific subtype agent.

340
00:11:58,760 --> 00:12:00,200
That subtype matters.

341
00:12:00,200 --> 00:12:02,360
It's how EntraID and conditional access

342
00:12:02,360 --> 00:12:05,320
know to treat this object differently from a regular application.

343
00:12:05,320 --> 00:12:06,920
There's an optional fourth layer,

344
00:12:06,920 --> 00:12:08,200
and this is where things change.

345
00:12:08,200 --> 00:12:09,800
The agent user exists for agents

346
00:12:09,800 --> 00:12:12,680
that need to act more like co-workers than back-end processes.

347
00:12:12,680 --> 00:12:14,840
These are agents that need an exchange mailbox

348
00:12:14,840 --> 00:12:17,320
a presence in Teams or visibility in the org chart.

349
00:12:17,320 --> 00:12:19,320
A back-end automation pulling nightly reports

350
00:12:19,320 --> 00:12:21,400
doesn't need to show up in a Teams conversation,

351
00:12:21,400 --> 00:12:23,800
but an agent that's meant to be mentioned in a document

352
00:12:23,800 --> 00:12:26,600
or looped into a channel needs a user-shaped presence

353
00:12:26,600 --> 00:12:27,560
to make that natural.

354
00:12:27,560 --> 00:12:30,280
This layer is tied back to its parent agent identity,

355
00:12:30,280 --> 00:12:33,000
so the lineage back to the blueprint stays intact.

356
00:12:33,000 --> 00:12:35,560
And here is the part that ties the whole stack together.

357
00:12:35,560 --> 00:12:37,560
Every one of these objects is a native Entra object.

358
00:12:37,560 --> 00:12:39,320
They aren't bolt-ons or shadow directories

359
00:12:39,320 --> 00:12:40,920
living outside your normal tools.

360
00:12:40,920 --> 00:12:42,520
They participate in conditional access

361
00:12:42,520 --> 00:12:43,880
the same way a user does.

362
00:12:43,880 --> 00:12:45,240
They show up in access reviews.

363
00:12:45,240 --> 00:12:46,920
They get evaluated by risk detection.

364
00:12:46,920 --> 00:12:48,280
You're not learning a parallel system.

365
00:12:48,280 --> 00:12:50,200
You're extending the one you already run.

366
00:12:50,200 --> 00:12:51,880
This hierarchy matters because it gives you

367
00:12:51,880 --> 00:12:53,880
multiple altitudes to govern from.

368
00:12:53,880 --> 00:12:55,800
You can set policy at the blueprint level

369
00:12:55,800 --> 00:12:57,720
to ensure baseline is never missed.

370
00:12:57,720 --> 00:13:00,360
You can also scope policy at the individual instance level

371
00:13:00,360 --> 00:13:02,760
when one particular agent needs tighter restrictions

372
00:13:02,760 --> 00:13:03,800
than its siblings.

373
00:13:03,800 --> 00:13:05,480
And where an agent user exists,

374
00:13:05,480 --> 00:13:08,600
you can govern access at that human-facing layer too.

375
00:13:08,600 --> 00:13:11,000
You can control what it can see and do inside Teams

376
00:13:11,000 --> 00:13:12,440
or exchange specifically.

377
00:13:12,440 --> 00:13:14,360
None of this was possible under the old model.

378
00:13:14,360 --> 00:13:16,920
A service principle was a flat single-layer object

379
00:13:16,920 --> 00:13:18,120
with no concept of linear,

380
00:13:18,120 --> 00:13:20,040
above it or presence below it.

381
00:13:20,040 --> 00:13:21,720
Now, you get a structure that mirrors

382
00:13:21,720 --> 00:13:24,200
how your organization actually thinks about accountability.

383
00:13:24,200 --> 00:13:25,720
You have a template someone owns,

384
00:13:25,720 --> 00:13:27,320
an instance someone sponsors,

385
00:13:27,320 --> 00:13:29,160
and a face your employees can recognize

386
00:13:29,160 --> 00:13:30,680
and work with directly.

387
00:13:30,680 --> 00:13:33,960
That layered structure is what makes the next piece possible.

388
00:13:33,960 --> 00:13:36,360
Once you have identity organized this cleanly,

389
00:13:36,360 --> 00:13:38,520
governance stops being something you write down

390
00:13:38,520 --> 00:13:39,560
in a policy document.

391
00:13:39,560 --> 00:13:42,200
It starts being something the architecture itself enforces

392
00:13:42,200 --> 00:13:43,960
and governance as physics.

393
00:13:43,960 --> 00:13:45,640
Governance isn't a policy document.

394
00:13:45,640 --> 00:13:46,680
It's architecture,

395
00:13:46,680 --> 00:13:48,840
the blueprints and the hierarchy we built.

396
00:13:48,840 --> 00:13:50,840
They aren't just for organizing identities.

397
00:13:50,840 --> 00:13:52,120
They are a physical structure.

398
00:13:52,120 --> 00:13:54,840
They enforce rules whether you remember to check them or not.

399
00:13:54,840 --> 00:13:56,680
It starts with sponsor accountability.

400
00:13:56,680 --> 00:13:59,720
Every agent needs a named human tied to its existence

401
00:13:59,720 --> 00:14:00,920
and its behavior.

402
00:14:00,920 --> 00:14:02,040
Not a distribution list,

403
00:14:02,040 --> 00:14:03,560
not the platform team.

404
00:14:03,560 --> 00:14:05,000
A specific person.

405
00:14:05,000 --> 00:14:07,240
That requirement isn't a suggestion sitting in a wiki.

406
00:14:07,240 --> 00:14:08,760
It's a field that must be populated

407
00:14:08,760 --> 00:14:10,600
before the agent identity can even exist.

408
00:14:10,600 --> 00:14:12,840
If you try to spin one up without a sponsor,

409
00:14:12,840 --> 00:14:13,720
the system blocks you.

410
00:14:13,720 --> 00:14:15,320
That's the difference between governance

411
00:14:15,320 --> 00:14:17,640
as a document and governance as physics.

412
00:14:17,640 --> 00:14:19,480
One relies on people reading and complying.

413
00:14:19,480 --> 00:14:21,320
The others simply won't let the object exist

414
00:14:21,320 --> 00:14:22,600
in a non-compliant state.

415
00:14:22,600 --> 00:14:24,680
The same logic applies to access reviews.

416
00:14:24,680 --> 00:14:26,760
Agents now sit inside the same review cycle

417
00:14:26,760 --> 00:14:28,760
your human accounts already go through.

418
00:14:28,760 --> 00:14:29,560
Periodically,

419
00:14:29,560 --> 00:14:32,280
someone has to confirm this agent still needs the access it holds.

420
00:14:32,280 --> 00:14:33,560
This isn't a new committee meeting

421
00:14:33,560 --> 00:14:35,640
you have to schedule and hope people show up to.

422
00:14:35,640 --> 00:14:38,280
It's the identity governance tooling you already run.

423
00:14:38,280 --> 00:14:39,800
Extended to cover a population

424
00:14:39,800 --> 00:14:41,800
that used to sit entirely outside of it.

425
00:14:41,800 --> 00:14:43,640
Life cycle policies work the same way.

426
00:14:43,640 --> 00:14:45,800
You can attach exploration to an agent identity

427
00:14:45,800 --> 00:14:47,080
based on business rules.

428
00:14:47,080 --> 00:14:49,080
Instead of an abandoned service principle

429
00:14:49,080 --> 00:14:50,760
quietly holding access for years,

430
00:14:50,760 --> 00:14:53,400
you get automatic deprovisioning tied to actual need.

431
00:14:53,400 --> 00:14:56,440
Renewal isn't assumed it has to be justified on a schedule

432
00:14:56,440 --> 00:14:57,960
or the access lapses on its own.

433
00:14:57,960 --> 00:14:59,320
Then there's least privilege.

434
00:14:59,320 --> 00:15:01,400
This is where the blueprint inheritance model

435
00:15:01,400 --> 00:15:03,480
pays off in a governance context.

436
00:15:03,480 --> 00:15:05,480
Permissions get scoped per agent instance.

437
00:15:05,480 --> 00:15:07,640
Not blanket granted to an entire class of agents

438
00:15:07,640 --> 00:15:10,200
because scoping individually felt like too much work.

439
00:15:10,200 --> 00:15:12,440
The blueprint gives you a consistent baseline.

440
00:15:12,440 --> 00:15:14,360
Instance level grants handle the exceptions.

441
00:15:14,360 --> 00:15:16,600
Nobody makes the old trade off of over-privileging

442
00:15:16,600 --> 00:15:18,680
the whole group just to avoid managing

443
00:15:18,680 --> 00:15:20,280
scope one agent at a time.

444
00:15:20,280 --> 00:15:22,520
Conditional access extends into the same structure.

445
00:15:22,520 --> 00:15:25,320
You can block challenge or require additional controls

446
00:15:25,320 --> 00:15:27,720
based on an agent's risk signal or its location.

447
00:15:27,720 --> 00:15:30,520
This isn't a separate security layer bolted on top.

448
00:15:30,520 --> 00:15:32,360
It's evaluating the same identity object

449
00:15:32,360 --> 00:15:33,480
that the blueprint spawned.

450
00:15:33,480 --> 00:15:35,240
The same object that holds the sponsor field.

451
00:15:35,240 --> 00:15:37,640
The same object showing up in your access reviews.

452
00:15:37,640 --> 00:15:38,600
One identity.

453
00:15:38,600 --> 00:15:41,000
Evaluated consistently across every governance surface

454
00:15:41,000 --> 00:15:43,640
you already operate and audit trails close the loop.

455
00:15:43,640 --> 00:15:45,880
Every action an agent takes carries lineage back

456
00:15:45,880 --> 00:15:47,480
to its blueprint and its sponsor.

457
00:15:47,480 --> 00:15:48,760
When something goes wrong,

458
00:15:48,760 --> 00:15:50,760
you aren't staring at a generic client ID

459
00:15:50,760 --> 00:15:53,320
wondering which of 50 instances did the damage.

460
00:15:53,320 --> 00:15:55,000
You're looking at one specific agent,

461
00:15:55,000 --> 00:15:56,120
one specific sponsor,

462
00:15:56,120 --> 00:15:57,800
one specific chain of accountability

463
00:15:57,800 --> 00:15:59,880
all the way back to the template it came from.

464
00:15:59,880 --> 00:16:01,880
This is why I call it physics rather than policy.

465
00:16:01,880 --> 00:16:04,120
Policy is something you write and hope people follow.

466
00:16:04,120 --> 00:16:06,840
Physics is a property of the structure itself.

467
00:16:06,840 --> 00:16:08,520
It's a rule the system can't violate

468
00:16:08,520 --> 00:16:11,320
because the architecture doesn't allow the violation to occur.

469
00:16:11,320 --> 00:16:12,680
Sponsor requirements.

470
00:16:12,680 --> 00:16:13,720
Access reviews.

471
00:16:13,720 --> 00:16:15,000
Life cycle expiration.

472
00:16:15,000 --> 00:16:16,120
Scoped permissions.

473
00:16:16,120 --> 00:16:17,240
Conditional access.

474
00:16:17,240 --> 00:16:18,360
Audit lineage.

475
00:16:18,360 --> 00:16:21,400
None of it depends on someone remembering to enforce it manually.

476
00:16:21,400 --> 00:16:23,720
It's already built into the identity fabric itself.

477
00:16:23,720 --> 00:16:25,000
That's not governance theatre.

478
00:16:25,000 --> 00:16:27,960
That's enforcement structurally guaranteed.

479
00:16:27,960 --> 00:16:30,120
And this leads directly to the next problem.

480
00:16:30,120 --> 00:16:31,720
What happens when these governed agents

481
00:16:31,720 --> 00:16:33,320
actually start touching your data?

482
00:16:33,320 --> 00:16:35,400
The data access problem.

483
00:16:35,400 --> 00:16:36,600
Agents touch data.

484
00:16:36,600 --> 00:16:38,360
This is where governance becomes critical.

485
00:16:38,360 --> 00:16:39,560
Everything we've covered.

486
00:16:39,560 --> 00:16:40,840
Blueprints, sponsors,

487
00:16:40,840 --> 00:16:42,360
lifecycle policies.

488
00:16:42,360 --> 00:16:44,440
Exists to answer one question.

489
00:16:44,440 --> 00:16:47,160
What happens the moment an agent reaches into your systems?

490
00:16:47,160 --> 00:16:48,840
An agent's reach far.

491
00:16:48,840 --> 00:16:49,720
SharePoint.

492
00:16:49,720 --> 00:16:50,440
OneDrive.

493
00:16:50,440 --> 00:16:51,080
Teams.

494
00:16:51,080 --> 00:16:51,880
Exchange.

495
00:16:51,880 --> 00:16:54,040
Plus whatever line of business systems you've wired them into.

496
00:16:54,040 --> 00:16:55,240
That's not a narrow surface.

497
00:16:55,240 --> 00:16:57,400
That's most of your organization's working data.

498
00:16:57,400 --> 00:16:59,240
It's accessible to an identity that.

499
00:16:59,240 --> 00:17:01,080
Without the structure we've been building

500
00:17:01,080 --> 00:17:03,880
has no clear boundary around what it should and shouldn't touch.

501
00:17:03,880 --> 00:17:04,920
The risk is simple.

502
00:17:04,920 --> 00:17:07,240
An agent with broad access and no clear scoping

503
00:17:07,240 --> 00:17:08,600
isn't just a compliance gap.

504
00:17:08,600 --> 00:17:09,960
It's a lateral movement vector.

505
00:17:09,960 --> 00:17:12,440
If you compromise one agent with wide permissions

506
00:17:12,440 --> 00:17:14,040
you haven't just compromised one task.

507
00:17:14,040 --> 00:17:16,440
You've compromised every system that agent could reach.

508
00:17:16,440 --> 00:17:19,080
This is exactly why the scope per instance permission model

509
00:17:19,080 --> 00:17:21,320
from the blueprint architecture matters so much.

510
00:17:21,320 --> 00:17:23,720
A tightly-scoped agent limits the blast radius.

511
00:17:23,720 --> 00:17:26,600
A broadly privileged one, hands an attacker, a map.

512
00:17:26,600 --> 00:17:28,920
This is where Perview comes in as the enforcement layer.

513
00:17:28,920 --> 00:17:31,480
DLP policies that already govern how your employees share

514
00:17:31,480 --> 00:17:33,800
and move data now apply to agent activity too.

515
00:17:33,800 --> 00:17:36,120
An agent doesn't get a pass just because it's automated.

516
00:17:36,120 --> 00:17:38,280
If a policy blocks a human from emailing

517
00:17:38,280 --> 00:17:40,200
a sensitive spreadsheet externally

518
00:17:40,200 --> 00:17:43,320
that same policy blocks an agent from doing it on someone's behalf.

519
00:17:43,320 --> 00:17:45,320
Classification and labeling work the same way.

520
00:17:45,320 --> 00:17:47,240
Agents respect sensitivity labels

521
00:17:47,240 --> 00:17:49,000
and information protection policies

522
00:17:49,000 --> 00:17:51,640
the same way a properly configured user session does.

523
00:17:51,640 --> 00:17:54,200
A document marked confidential doesn't become readable

524
00:17:54,200 --> 00:17:55,800
just because the thing requesting it

525
00:17:55,800 --> 00:17:58,360
is an AI agent instead of a person sitting at a desk.

526
00:17:58,360 --> 00:18:01,080
There's a principle here, no source, no answer.

527
00:18:01,080 --> 00:18:03,880
An agent should only provide information

528
00:18:03,880 --> 00:18:05,800
it can actually ground in an enterprise source

529
00:18:05,800 --> 00:18:07,080
its authorized to see.

530
00:18:07,080 --> 00:18:09,240
Not something it inferred, not something it guessed at

531
00:18:09,240 --> 00:18:11,080
from a training pattern, it needs to be something

532
00:18:11,080 --> 00:18:13,960
it can point to and say, here is where this came from.

533
00:18:13,960 --> 00:18:16,600
That grounding requirement is what keeps an agent's output tied

534
00:18:16,600 --> 00:18:19,080
to something auditable instead of something invented.

535
00:18:19,080 --> 00:18:21,320
And because agent generated content is discoverable

536
00:18:21,320 --> 00:18:22,840
it falls under the same e-discovery

537
00:18:22,840 --> 00:18:26,120
and legal hold processes as anything a human produces.

538
00:18:26,120 --> 00:18:29,480
If an agent drafted a summary that ends up relevant to litigation

539
00:18:29,480 --> 00:18:31,800
that content doesn't sit outside your compliance tooling

540
00:18:31,800 --> 00:18:33,960
just because no human typed it is part of the record.

541
00:18:33,960 --> 00:18:35,000
Same as anything else.

542
00:18:35,000 --> 00:18:36,760
Put all of this together and you get something

543
00:18:36,760 --> 00:18:39,320
most organizations could not answer six months ago

544
00:18:39,320 --> 00:18:41,720
what data is this agent accessing and why?

545
00:18:41,720 --> 00:18:44,680
Not a vague sense of it probably touches SharePoint somewhere.

546
00:18:44,680 --> 00:18:48,280
A specific traceable answer it's backed by scoped permissions.

547
00:18:48,280 --> 00:18:50,440
DLP enforcement, label compliance,

548
00:18:50,440 --> 00:18:52,920
and a grounding requirement that ties every response back

549
00:18:52,920 --> 00:18:53,800
to a real source.

550
00:18:53,800 --> 00:18:55,000
That answer is the whole point.

551
00:18:55,000 --> 00:18:57,400
Data access without that answer is just exposure

552
00:18:57,400 --> 00:18:59,800
waiting to be discovered by someone other than you.

553
00:18:59,800 --> 00:19:02,440
Data access with that answer is a govern system

554
00:19:02,440 --> 00:19:04,280
doing exactly what you designed it to do.

555
00:19:04,280 --> 00:19:08,600
The security shift, security changes when agents become first class identities

556
00:19:08,600 --> 00:19:11,000
it doesn't change a little, it changes completely

557
00:19:11,000 --> 00:19:13,400
because up to now we've been applying human shape tools

558
00:19:13,400 --> 00:19:14,760
to a non-human problem.

559
00:19:14,760 --> 00:19:16,600
We were just hoping the fit was close enough.

560
00:19:16,600 --> 00:19:17,560
It wasn't.

561
00:19:17,560 --> 00:19:18,760
Start with risk detection.

562
00:19:18,760 --> 00:19:21,800
EntraID protection now reads threat patterns specific to agents.

563
00:19:21,800 --> 00:19:24,600
It doesn't just borrow signals from user risk models anymore.

564
00:19:24,600 --> 00:19:25,960
That distinction matters.

565
00:19:25,960 --> 00:19:27,880
Agent behavior doesn't look like human behavior.

566
00:19:27,880 --> 00:19:31,000
We'll get into why that comparison breaks down in the next section.

567
00:19:31,000 --> 00:19:33,320
But for now, the important point is this.

568
00:19:33,320 --> 00:19:36,440
The system actually understands what normal looks like for an agent.

569
00:19:36,440 --> 00:19:38,920
It isn't just looking for a person pretending to be one.

570
00:19:38,920 --> 00:19:41,080
That understanding feeds your anomaly detection.

571
00:19:41,080 --> 00:19:44,040
Unusual data access, activity crossing tenant boundaries,

572
00:19:44,040 --> 00:19:47,320
a tool getting called in a way that doesn't match the typical pattern.

573
00:19:47,320 --> 00:19:50,040
Any of these can trigger a block before the damage spreads.

574
00:19:50,040 --> 00:19:53,400
This isn't a report generated the next morning for someone to review over coffee.

575
00:19:53,400 --> 00:19:54,920
It's real-time evaluation.

576
00:19:54,920 --> 00:19:57,800
And it's tied to the same identity object carrying the sponsor field

577
00:19:57,800 --> 00:19:59,800
and the blueprint lineage we already covered.

578
00:19:59,800 --> 00:20:02,520
Conditional access gives you the mechanism to act on that risk.

579
00:20:02,520 --> 00:20:04,520
You can require MFA equivalent controls.

580
00:20:04,520 --> 00:20:08,520
Demand, device compliance, or restrict network conditions.

581
00:20:08,520 --> 00:20:10,920
But you're doing it for agent identities specifically.

582
00:20:10,920 --> 00:20:13,960
An agent operating from an unexpected location can be challenged

583
00:20:13,960 --> 00:20:16,040
or blocked using the exact same policy engine

584
00:20:16,040 --> 00:20:17,800
already protecting your human accounts.

585
00:20:17,800 --> 00:20:19,400
One engine, one set of rules.

586
00:20:19,400 --> 00:20:22,440
Extended to cover a population it was never built to see before.

587
00:20:22,440 --> 00:20:25,400
Managing this requires someone with the right scope of control.

588
00:20:25,400 --> 00:20:28,680
That's why there's now a dedicated agent ID administrator role.

589
00:20:28,680 --> 00:20:31,240
This isn't the same as handing someone global administrator

590
00:20:31,240 --> 00:20:32,840
and hoping they use it carefully.

591
00:20:32,840 --> 00:20:36,280
It's a role built specifically for managing agent identities and blueprints.

592
00:20:36,280 --> 00:20:40,120
It's narrower in scope, its purpose built for the object type it governs.

593
00:20:40,120 --> 00:20:42,920
Early implementations of this role showed some scope overreach

594
00:20:42,920 --> 00:20:44,600
into non-agent service principles

595
00:20:44,600 --> 00:20:47,800
because agent identities are built on shared infrastructure underneath.

596
00:20:47,800 --> 00:20:48,840
That's been addressed.

597
00:20:48,840 --> 00:20:50,280
But it's a useful reminder.

598
00:20:50,280 --> 00:20:53,320
Any privileged role touching this stack deserves the same scrutiny

599
00:20:53,320 --> 00:20:55,720
you'd apply to any other high trust assignment.

600
00:20:55,720 --> 00:20:57,720
Defender extends into this picture too.

601
00:20:57,720 --> 00:21:00,360
Threat protection already watches for compromised accounts.

602
00:21:00,360 --> 00:21:02,840
Now it covers agent-driven attacks specifically.

603
00:21:02,840 --> 00:21:04,760
It looks for prompt injection attempts.

604
00:21:04,760 --> 00:21:09,240
Unsafe tool invocations or an agent being manipulated into acting outside its purpose.

605
00:21:09,240 --> 00:21:11,960
Investigation and hunting can correlate agent activity

606
00:21:11,960 --> 00:21:13,800
with user actions and system changes.

607
00:21:13,800 --> 00:21:17,000
An incident involving an agent doesn't sit in a separate silo anymore.

608
00:21:17,000 --> 00:21:20,600
And then there's the piece that actually removes an entire category of risk.

609
00:21:20,600 --> 00:21:21,960
The credential less model.

610
00:21:21,960 --> 00:21:25,400
No secrets held per agent means no per agent credential to steal.

611
00:21:25,400 --> 00:21:26,760
Leak. Or forget to rotate.

612
00:21:26,760 --> 00:21:30,840
An attacker looking for a stolen API key sitting in a script finds nothing

613
00:21:30,840 --> 00:21:32,200
that key was never there to begin with.

614
00:21:32,200 --> 00:21:35,240
Put it together. And this transforms agents from what they've been.

615
00:21:35,240 --> 00:21:38,120
There used to be a security blind spot nobody fully monitored.

616
00:21:38,120 --> 00:21:39,800
Now they are governed and observable.

617
00:21:39,800 --> 00:21:42,040
They are evaluated by the same risk engine,

618
00:21:42,040 --> 00:21:43,960
the same conditional access policies.

619
00:21:43,960 --> 00:21:46,920
And the same threat protection tooling already protecting

620
00:21:46,920 --> 00:21:48,440
every human identity in your tenant.

621
00:21:48,440 --> 00:21:50,040
That's not a parallel security program.

622
00:21:50,040 --> 00:21:51,320
That's one program.

623
00:21:51,320 --> 00:21:53,240
Finally covering the whole population.

624
00:21:53,240 --> 00:21:54,680
It was always meant to protect.

625
00:21:54,680 --> 00:21:56,840
The licensing reality.

626
00:21:56,840 --> 00:21:58,920
Now let's talk about what this costs and who needs it.

627
00:21:58,920 --> 00:22:01,640
The pricing model tells you exactly how Microsoft expects this

628
00:22:01,640 --> 00:22:02,920
to get deployed.

629
00:22:02,920 --> 00:22:06,600
Agent 365 stand alone runs 15 dollars per user per month.

630
00:22:06,600 --> 00:22:09,080
That starts on May 1st, 2026.

631
00:22:09,080 --> 00:22:11,560
The same general availability date we covered earlier.

632
00:22:11,560 --> 00:22:16,840
If you wanted bundled, Microsoft 365 e7 comes in at 99 dollars per user per month.

633
00:22:16,840 --> 00:22:19,800
That bundle includes e5, copilot, and trust suite.

634
00:22:19,800 --> 00:22:21,240
And agent 365 together.

635
00:22:21,240 --> 00:22:22,840
If you buy those four pieces separately,

636
00:22:22,840 --> 00:22:25,160
you're paying more than bundling them under e7.

637
00:22:25,160 --> 00:22:26,840
But here's the detail that trips people up.

638
00:22:26,840 --> 00:22:29,480
This is licensed per user, not per agent.

639
00:22:29,480 --> 00:22:33,160
You're not paying a fee for every individual agent instance spawned from a blueprint.

640
00:22:33,160 --> 00:22:35,960
You're licensing the humans who govern those agents.

641
00:22:35,960 --> 00:22:39,240
The sponsors, the admins, the people actually touching the control plane.

642
00:22:39,240 --> 00:22:41,960
An organization running 2000 agent instances

643
00:22:41,960 --> 00:22:45,160
offer handful of blueprints only pays for the platform team's seats.

644
00:22:45,160 --> 00:22:47,800
They don't pay for 2000 separate agent licenses.

645
00:22:47,800 --> 00:22:49,880
This matters because it directly shapes

646
00:22:49,880 --> 00:22:51,880
how you should be thinking about your structure.

647
00:22:51,880 --> 00:22:53,160
It rewards centralization.

648
00:22:53,160 --> 00:22:56,200
A small team governing many agents cost far less

649
00:22:56,200 --> 00:22:59,160
than the same agent population spread across dozens of unlicensed

650
00:22:59,160 --> 00:23:00,440
departmental owners.

651
00:23:00,440 --> 00:23:02,680
Before you can even buy this, there are prerequisites.

652
00:23:02,680 --> 00:23:05,560
And they vary depending on where your organization sits.

653
00:23:05,560 --> 00:23:09,880
Enterprise customers need Microsoft 365 e5 as the qualifying base.

654
00:23:09,880 --> 00:23:12,680
Frontline worker populations need Defender plus Per View Suite,

655
00:23:12,680 --> 00:23:13,800
FLW.

656
00:23:13,800 --> 00:23:15,720
SMB customers need business premium.

657
00:23:15,720 --> 00:23:19,000
You don't get to bolt agent 365 onto just any tenant.

658
00:23:19,000 --> 00:23:21,800
It sits on top of a security and compliance foundation

659
00:23:21,800 --> 00:23:23,400
that has to already be in place.

660
00:23:23,400 --> 00:23:26,280
There's also a split between what's free and what requires payment.

661
00:23:26,280 --> 00:23:28,680
Basic agent discovery doesn't require a license.

662
00:23:28,680 --> 00:23:31,880
That's the visibility that lets you see agents exist in your registry.

663
00:23:31,880 --> 00:23:34,920
But the governance layer we've spent this entire episode building

664
00:23:34,920 --> 00:23:38,760
toward is gated behind the paid tier, the analytics, the enforcement,

665
00:23:38,760 --> 00:23:41,640
the deeper policy controls you can see your agents for free,

666
00:23:41,640 --> 00:23:43,080
governing them costs money.

667
00:23:43,080 --> 00:23:44,680
One more thing worth flagging clearly.

668
00:23:44,680 --> 00:23:47,400
There's no consumption meter on agent 365 itself.

669
00:23:47,400 --> 00:23:48,120
At least not yet.

670
00:23:48,120 --> 00:23:49,320
It's a flat per user fee.

671
00:23:49,320 --> 00:23:51,880
What isn't flat is the AI runtime underneath it.

672
00:23:51,880 --> 00:23:54,360
Co-pilot credits as your token consumption.

673
00:23:54,360 --> 00:23:57,400
Whatever compute your agents are actually burning to do their work.

674
00:23:57,400 --> 00:24:00,040
That's built separately from the governance layer entirely.

675
00:24:00,040 --> 00:24:03,320
You could hold your agent 365 licensing cost steady

676
00:24:03,320 --> 00:24:05,720
while your runtime bill climbs significantly.

677
00:24:05,720 --> 00:24:09,880
Those are two entirely different meters measuring two entirely different things.

678
00:24:09,880 --> 00:24:12,600
Step back and look at what this pricing structure assumes.

679
00:24:12,600 --> 00:24:15,880
It assumes most organizations won't try to license every employee

680
00:24:15,880 --> 00:24:17,960
individually against every agent they touch.

681
00:24:17,960 --> 00:24:20,440
It assumes governance gets concentrated in a small,

682
00:24:20,440 --> 00:24:23,000
accountable team, sponsors and administrators.

683
00:24:23,000 --> 00:24:25,560
Rather than the whole workforce, that's not just a pricing choice.

684
00:24:25,560 --> 00:24:28,440
It's Microsoft quietly telling you what operating model they expect

685
00:24:28,440 --> 00:24:29,480
to actually work at scale.

686
00:24:29,480 --> 00:24:32,440
The registry and discovery.

687
00:24:32,440 --> 00:24:33,880
Agents need to find each other.

688
00:24:33,880 --> 00:24:36,120
This is where the registry becomes critical.

689
00:24:36,120 --> 00:24:37,960
It's a piece that often gets overlooked

690
00:24:37,960 --> 00:24:39,640
because it doesn't feel like security work.

691
00:24:39,640 --> 00:24:40,840
It feels like plumbing.

692
00:24:40,840 --> 00:24:42,760
But you can't govern what you can't see.

693
00:24:42,760 --> 00:24:44,920
The registry is what makes agents visible in the first place.

694
00:24:44,920 --> 00:24:48,120
Think of it as the central catalog for every agent in your organization.

695
00:24:48,120 --> 00:24:51,000
It doesn't matter which platform built it or which team owns it.

696
00:24:51,000 --> 00:24:53,320
Every blueprint and every instance shows up here.

697
00:24:53,320 --> 00:24:55,240
This isn't just a nice to have dashboard.

698
00:24:55,240 --> 00:24:58,840
It is the source of truth for what your agent population actually looks like.

699
00:24:58,840 --> 00:25:00,520
Each entry carries an agent card.

700
00:25:00,520 --> 00:25:03,080
This is metadata describing what the agent does,

701
00:25:03,080 --> 00:25:05,640
what it can reach and how it connects to other systems.

702
00:25:05,640 --> 00:25:09,800
That card lets a human or another agent understand an unfamiliar identity

703
00:25:09,800 --> 00:25:12,200
without having to dig through configuration lines.

704
00:25:12,200 --> 00:25:13,240
You look at the card.

705
00:25:13,240 --> 00:25:14,280
You know the purpose.

706
00:25:14,280 --> 00:25:15,320
You know the scope.

707
00:25:15,320 --> 00:25:16,360
And you know the owner.

708
00:25:16,360 --> 00:25:18,200
That last part matters more than it sounds.

709
00:25:18,200 --> 00:25:20,120
Because agents don't just get discovered by people.

710
00:25:20,120 --> 00:25:21,560
They get discovered by each other.

711
00:25:21,560 --> 00:25:23,320
An agent built for customer intake

712
00:25:23,320 --> 00:25:25,640
might need to hand a task to a billing agent.

713
00:25:25,640 --> 00:25:27,800
It queries the registry, finds the right card,

714
00:25:27,800 --> 00:25:29,240
and initiates that handoff.

715
00:25:29,240 --> 00:25:31,560
Discovery here isn't about granting access.

716
00:25:31,560 --> 00:25:35,320
Permissions are still governed through the roles and policies we already covered.

717
00:25:35,320 --> 00:25:37,480
The registry answers a narrower question.

718
00:25:37,480 --> 00:25:39,480
Does something exist that can help with this?

719
00:25:39,480 --> 00:25:40,520
And where do I find it?

720
00:25:40,520 --> 00:25:42,520
For organizations with a large agent population,

721
00:25:42,520 --> 00:25:44,680
you don't want everything visible by default.

722
00:25:44,680 --> 00:25:45,960
That's where collections come in.

723
00:25:45,960 --> 00:25:47,560
These are groupings by business function,

724
00:25:47,560 --> 00:25:49,320
environment, or approval status.

725
00:25:49,320 --> 00:25:53,160
You might keep a finance-approved collection separate from an experimental one.

726
00:25:53,480 --> 00:25:55,800
This stops people from tripping over half finished pilots

727
00:25:55,800 --> 00:25:57,480
while looking for production tools.

728
00:25:57,480 --> 00:26:00,040
The closest comparison is the employee directory.

729
00:26:00,040 --> 00:26:02,120
That's the list that shows a name, a title,

730
00:26:02,120 --> 00:26:03,480
and a way to reach someone.

731
00:26:03,480 --> 00:26:05,880
The registry does that same job for agents.

732
00:26:05,880 --> 00:26:07,160
It's not access control.

733
00:26:07,160 --> 00:26:09,720
It's the mechanism that makes a population discoverable.

734
00:26:09,720 --> 00:26:12,600
Instead of scattered across silos that nobody can see into,

735
00:26:12,600 --> 00:26:14,280
there's also a quarantine capability.

736
00:26:14,280 --> 00:26:17,000
If an agent starts behaving badly or fails a risk review,

737
00:26:17,000 --> 00:26:18,280
you can pull it from discovery.

738
00:26:18,280 --> 00:26:19,560
You don't have to delete it.

739
00:26:19,560 --> 00:26:21,240
It stops showing up in searches.

740
00:26:21,240 --> 00:26:24,280
But the object and its audit trails stay intact for investigation.

741
00:26:24,280 --> 00:26:26,760
That distinction between hiding and destroying matters

742
00:26:26,760 --> 00:26:28,760
when you're trying to understand what went wrong.

743
00:26:28,760 --> 00:26:31,560
None of this replaces the governance layers we've already built.

744
00:26:31,560 --> 00:26:33,160
The sponsors, the scope permissions,

745
00:26:33,160 --> 00:26:34,520
the conditional access policies,

746
00:26:34,520 --> 00:26:36,280
the registry sits underneath all of it.

747
00:26:36,280 --> 00:26:38,600
It's the layer that makes the rest of the system honest.

748
00:26:38,600 --> 00:26:41,640
A sponsor can only be accountable for agents they know exist.

749
00:26:41,640 --> 00:26:45,000
An access review can only cover agents someone remembered to include.

750
00:26:45,000 --> 00:26:47,240
Without a registry, governance quietly degrades.

751
00:26:47,240 --> 00:26:49,880
You end up only governing the agents you happen to remember.

752
00:26:49,880 --> 00:26:51,640
And that is exactly the failure mode.

753
00:26:51,640 --> 00:26:54,200
This entire structure was built to eliminate.

754
00:26:54,200 --> 00:26:56,120
The attended versus unattended decision.

755
00:26:56,120 --> 00:26:58,040
Not all agents operate the same way.

756
00:26:58,040 --> 00:27:01,160
This distinction shapes every governance decision downstream.

757
00:27:01,160 --> 00:27:02,840
So we need to be precise about the difference.

758
00:27:02,840 --> 00:27:05,640
An attended agent acts on behalf of assigned inhuman.

759
00:27:05,640 --> 00:27:07,160
Someone is actively in the loop.

760
00:27:07,160 --> 00:27:09,400
The agent works with delegated permissions tied directly

761
00:27:09,400 --> 00:27:10,600
to that person's session.

762
00:27:10,600 --> 00:27:12,600
Picture someone drafting a proposal in word.

763
00:27:12,600 --> 00:27:15,720
They ask an agent to pull last quarter's numbers into a table.

764
00:27:15,720 --> 00:27:18,840
That agent isn't operating under its own independent authority.

765
00:27:18,840 --> 00:27:20,600
It's an extension of the person sitting there.

766
00:27:20,600 --> 00:27:24,040
It is bounded by whatever that person is already allowed to touch.

767
00:27:24,040 --> 00:27:26,600
An unattended agent is a different animal entirely.

768
00:27:26,600 --> 00:27:27,560
No human in the loop.

769
00:27:27,560 --> 00:27:28,840
No session to inherit from.

770
00:27:28,840 --> 00:27:30,360
It acts under its own identity.

771
00:27:30,360 --> 00:27:33,400
It is governed by the roles assigned directly to its blueprint.

772
00:27:33,400 --> 00:27:36,760
Think of a nightly process that scans invoices for anomalies.

773
00:27:36,760 --> 00:27:38,280
It doesn't wait for someone to log in.

774
00:27:38,280 --> 00:27:39,560
It runs on its own authority.

775
00:27:39,560 --> 00:27:41,000
It runs on its own schedule.

776
00:27:41,000 --> 00:27:44,040
And it has its own accountability chain back to its sponsor.

777
00:27:44,040 --> 00:27:46,440
This split matters for a very practical reason.

778
00:27:46,440 --> 00:27:49,960
When an agent is attended, your existing policies for that human already apply.

779
00:27:49,960 --> 00:27:52,920
If that person needs a compliant device, the agent inherits that requirement.

780
00:27:52,920 --> 00:27:54,280
You're not building new policy.

781
00:27:54,280 --> 00:27:56,200
Your extending policy, you already trust.

782
00:27:56,200 --> 00:27:58,040
An unattended agent don't have that luxury.

783
00:27:58,040 --> 00:27:59,720
There is no human context to borrow.

784
00:27:59,720 --> 00:28:02,760
These need agent-specific policies and risk-based controls.

785
00:28:02,760 --> 00:28:05,800
There is no user session to lean on for signals like location.

786
00:28:05,800 --> 00:28:10,120
The entire risk evaluation has to stand on the agent's own behavioral baseline instead.

787
00:28:10,120 --> 00:28:12,280
The token mechanics reflect the same split.

788
00:28:12,280 --> 00:28:15,080
Attended agents typically use an on-be-half of flow.

789
00:28:15,080 --> 00:28:18,200
The request permission that traces back to the user's consent.

790
00:28:18,200 --> 00:28:20,600
Unattended agents authenticate directly.

791
00:28:20,600 --> 00:28:22,600
They use the Blueprint's credential model.

792
00:28:22,600 --> 00:28:25,320
There is no user token involved anywhere in the chain.

793
00:28:25,320 --> 00:28:27,240
These are two different authentication paths.

794
00:28:27,240 --> 00:28:31,080
Because there are two fundamentally different trust relationships underneath them.

795
00:28:31,080 --> 00:28:33,320
This isn't a minor toggle you said once and forget.

796
00:28:33,320 --> 00:28:34,680
It shapes permissions.

797
00:28:34,680 --> 00:28:37,080
Delegated access is bounded by the user.

798
00:28:37,080 --> 00:28:39,640
Appassigned access needs its own explicit scoping.

799
00:28:39,640 --> 00:28:41,320
It shapes your governance posture.

800
00:28:41,320 --> 00:28:43,800
Unattended agents demand a more rigorous risk model

801
00:28:43,800 --> 00:28:45,720
because there is no human fallback.

802
00:28:45,720 --> 00:28:47,400
And it shapes incident response.

803
00:28:47,400 --> 00:28:49,240
When an attended agent misbehaves,

804
00:28:49,240 --> 00:28:51,240
you're investigating a person in a session.

805
00:28:51,240 --> 00:28:53,320
When an unattended agent misbehaves,

806
00:28:53,320 --> 00:28:56,200
you're investigating an identity that acted entirely on its own.

807
00:28:56,200 --> 00:28:59,400
There is no human decision point to interrogate in the moment.

808
00:28:59,400 --> 00:29:02,200
If you get this classification wrong at design time,

809
00:29:02,200 --> 00:29:04,520
you'll spend the next year retrofitting policies.

810
00:29:04,520 --> 00:29:07,160
But if you get it right, everything else slots into place.

811
00:29:07,160 --> 00:29:09,080
The sponsors, the policies, the risk detection.

812
00:29:09,080 --> 00:29:11,720
It all works because the foundation is correct.

813
00:29:11,720 --> 00:29:15,720
Conditional access for agents, conditional access extends zero trust to AI.

814
00:29:15,720 --> 00:29:17,880
But here's how that actually gets built into policy.

815
00:29:17,880 --> 00:29:22,040
Agent conditional access is now a first class policy target inside EntraID.

816
00:29:22,040 --> 00:29:23,160
It isn't a workaround.

817
00:29:23,160 --> 00:29:25,240
It isn't bolted onto an existing ruleset.

818
00:29:25,240 --> 00:29:28,840
When you build a policy, you select agents as its own assignment category.

819
00:29:28,840 --> 00:29:31,880
It sits right alongside users and workload identities.

820
00:29:31,880 --> 00:29:34,600
That matters because it means you're no longer forcing agent governance

821
00:29:34,600 --> 00:29:36,040
through a structure designed for people.

822
00:29:36,040 --> 00:29:38,040
You're targeting the object type directly.

823
00:29:38,040 --> 00:29:39,640
Agent risk plugs in as a condition.

824
00:29:39,640 --> 00:29:43,320
It draws on the same EntraID protection signals we covered earlier.

825
00:29:43,320 --> 00:29:44,680
You can build a policy that says,

826
00:29:44,680 --> 00:29:47,960
"If this agent's risk level crosses a threshold, block the token request."

827
00:29:47,960 --> 00:29:50,280
Or require a step-up control before it proceeds.

828
00:29:50,280 --> 00:29:51,560
That's the enforcement hook.

829
00:29:51,560 --> 00:29:53,000
It turns detection into action.

830
00:29:53,000 --> 00:29:56,680
Because detection without an enforcement point is just an interesting log entry.

831
00:29:56,680 --> 00:29:58,760
This is what makes the signal actually do something.

832
00:29:58,760 --> 00:30:01,400
Resource scoping is where this gets genuinely precise.

833
00:30:01,400 --> 00:30:05,000
You aren't limited to a blanket allow a deny for an agent's entire existence.

834
00:30:05,000 --> 00:30:08,360
You can restrict a specific agent identity to specific APIs.

835
00:30:08,360 --> 00:30:10,920
Specific applications and specific data sources.

836
00:30:10,920 --> 00:30:12,360
Nothing beyond that boundary.

837
00:30:12,360 --> 00:30:15,320
Pair this with the scoped permission model from the blueprint architecture.

838
00:30:15,320 --> 00:30:18,600
Now you have two independent layers narrowing what an agent can touch.

839
00:30:18,600 --> 00:30:20,040
The permission grant itself.

840
00:30:20,040 --> 00:30:22,440
And the conditional access policy standing in front of it.

841
00:30:22,440 --> 00:30:24,520
Before you flip any of this into full enforcement,

842
00:30:24,520 --> 00:30:26,280
use the phased rollout capability.

843
00:30:26,280 --> 00:30:28,360
Policies can run in report only mode first.

844
00:30:28,360 --> 00:30:30,600
You see exactly what would have been blocked or challenged

845
00:30:30,600 --> 00:30:32,920
without disrupting a production agent mid-task.

846
00:30:32,920 --> 00:30:37,480
An agent population can grow fast once departments start requesting their own instances.

847
00:30:37,480 --> 00:30:40,120
Testing in report only mode isn't optional caution.

848
00:30:40,120 --> 00:30:43,960
It's the only realistic way to validate a policy before it touches something running unattended

849
00:30:43,960 --> 00:30:44,680
at two in the morning.

850
00:30:44,680 --> 00:30:45,480
But here's the problem.

851
00:30:45,480 --> 00:30:49,400
It's easy to misread how this works if you expect it to behave like user access.

852
00:30:49,400 --> 00:30:51,640
The enforcement point sits at token acquisition.

853
00:30:51,640 --> 00:30:55,160
Conditional access evaluates the moment an agent requests a token.

854
00:30:55,160 --> 00:31:00,120
It does not evaluate every single downstream action that agent takes after it has one.

855
00:31:00,120 --> 00:31:05,160
So if an agent successfully authenticates and then calls 15 different tools across a task,

856
00:31:05,160 --> 00:31:07,320
conditional access made its decision once.

857
00:31:07,320 --> 00:31:08,120
At the gate.

858
00:31:08,120 --> 00:31:09,880
Not 15 separate times along the way.

859
00:31:09,880 --> 00:31:11,240
That's a deliberate design choice.

860
00:31:11,240 --> 00:31:12,840
It isn't a gap someone forgot to close.

861
00:31:12,840 --> 00:31:14,680
The real authorization happens at runtime.

862
00:31:14,680 --> 00:31:18,360
The fine grain decision about whether this specific action should be permitted

863
00:31:18,360 --> 00:31:20,600
happens inside the agent platform itself.

864
00:31:20,600 --> 00:31:24,760
It uses the scope commissions and roles we've already built into the blueprint and instance layers.

865
00:31:24,760 --> 00:31:26,760
Conditional access is the checkpoint at the door.

866
00:31:26,760 --> 00:31:28,360
It's lightweight by design.

867
00:31:28,360 --> 00:31:32,840
Because asking it to re-evaluate every single tool call would turn a policy engine into a bottleneck

868
00:31:32,840 --> 00:31:34,280
nobody's runtime could tolerate.

869
00:31:34,280 --> 00:31:37,800
So what's actually happening is two systems working at two different speeds.

870
00:31:37,800 --> 00:31:40,760
Conditional access handles the slower higher state's question.

871
00:31:40,760 --> 00:31:43,160
Should this identity be allowed to operate right now?

872
00:31:43,160 --> 00:31:46,600
The agent platform handles the faster higher volume question.

873
00:31:46,600 --> 00:31:49,480
What exactly is it allowed to do with this specific call?

874
00:31:49,480 --> 00:31:51,400
Neither one is trying to do the other's job.

875
00:31:51,400 --> 00:31:54,600
And that separation is precisely what keeps the whole model workable at scale.

876
00:31:54,600 --> 00:31:56,920
It doesn't collapse under its own overhead.

877
00:31:56,920 --> 00:31:58,600
Identity protection for agents.

878
00:31:58,600 --> 00:31:59,880
Agents can be compromised.

879
00:31:59,880 --> 00:32:01,400
Detection is built in now.

880
00:32:01,400 --> 00:32:03,560
And this is where the risk signal actually gets defined.

881
00:32:03,560 --> 00:32:04,920
Agent risk isn't one signal.

882
00:32:04,920 --> 00:32:05,800
It's a cluster of them.

883
00:32:05,800 --> 00:32:06,840
A normalist behavior.

884
00:32:06,840 --> 00:32:08,760
Access patterns that don't match history.

885
00:32:08,760 --> 00:32:12,680
Activity suddenly reaching across tenant boundaries when it never has before.

886
00:32:12,680 --> 00:32:16,200
EntraID protection watches for all of this simultaneously.

887
00:32:16,200 --> 00:32:19,800
It builds a picture of what a specific agent identity typically does.

888
00:32:19,800 --> 00:32:22,120
Then it flags the moment that pattern breaks.

889
00:32:22,120 --> 00:32:24,360
That picture comes from behavioral baselines.

890
00:32:24,360 --> 00:32:26,200
And this is worth sitting with for a second.

891
00:32:26,200 --> 00:32:29,240
EntraID doesn't apply a generic rule to every agent equally.

892
00:32:29,240 --> 00:32:32,680
It learns what normal actually looks like for each individual identity.

893
00:32:32,680 --> 00:32:35,960
Because a document summarization agent and a finance reconciliation agent

894
00:32:35,960 --> 00:32:37,880
have wildly different normal patterns,

895
00:32:37,880 --> 00:32:42,040
treating them identically with either misreal threats or drown you in false positives.

896
00:32:42,040 --> 00:32:45,880
When something crosses that baseline, the response isn't a ticket in a queue.

897
00:32:45,880 --> 00:32:47,800
It isn't for someone to review next week.

898
00:32:47,800 --> 00:32:50,600
High risk agents can be denied a token in real time.

899
00:32:50,600 --> 00:32:51,560
Automatically.

900
00:32:51,560 --> 00:32:53,480
The same instant the risk signal fires.

901
00:32:53,480 --> 00:32:55,560
That's the enforcement point we described earlier.

902
00:32:55,560 --> 00:32:57,080
The token request gate.

903
00:32:57,080 --> 00:33:01,160
It's now acting on identity-specific behavioral data instead of a static rule.

904
00:33:01,160 --> 00:33:04,840
Investigation is where this pays off for the person who has to figure out what happened.

905
00:33:04,840 --> 00:33:07,400
The logs don't just show that something was blocked.

906
00:33:07,400 --> 00:33:08,520
They show why.

907
00:33:08,520 --> 00:33:10,920
What specific deviation triggered the flag?

908
00:33:10,920 --> 00:33:13,480
What the baseline expected versus what actually occurred?

909
00:33:13,480 --> 00:33:17,880
That context is the difference between an analyst spending 20 minutes understanding an incident.

910
00:33:17,880 --> 00:33:19,960
And spending half a day reconstructing it from scratch.

911
00:33:19,960 --> 00:33:20,840
But here's the shift.

912
00:33:20,840 --> 00:33:24,760
There is a distinction that trips people up if they think about this through a human risk lens.

913
00:33:24,760 --> 00:33:28,920
An agent legitimately touching 500 documents in 10 minutes is unremarkable.

914
00:33:28,920 --> 00:33:31,640
That's what a retrieval heavy agent does on a normal Tuesday.

915
00:33:31,640 --> 00:33:36,200
A human account doing the same thing in the same window is almost certainly a compromise in progress.

916
00:33:36,200 --> 00:33:37,160
Same raw number.

917
00:33:37,160 --> 00:33:38,120
Opposite conclusion.

918
00:33:38,120 --> 00:33:40,920
Because the baseline being measured against is entirely different.

919
00:33:40,920 --> 00:33:44,040
This is exactly why agent-specific risk modeling isn't optional.

920
00:33:44,040 --> 00:33:48,680
Borrowing the thresholds built for human accounts and pointing them at agent traffic would be a mistake.

921
00:33:48,680 --> 00:33:51,560
You would either lock down legitimate automation constantly

922
00:33:51,560 --> 00:33:54,680
or miss the actual anomalies buried underneath normal looking volume.

923
00:33:54,680 --> 00:33:57,000
Defender integration extends this further.

924
00:33:57,000 --> 00:34:01,080
It connects agent risk signals to the same threat detection already watching for

925
00:34:01,080 --> 00:34:02,840
compromised accounts elsewhere.

926
00:34:02,840 --> 00:34:05,960
An agent-driven attack doesn't sit in an isolated silo.

927
00:34:05,960 --> 00:34:08,840
It isn't separate from everything else defender is correlating.

928
00:34:08,840 --> 00:34:10,760
It's part of the same investigation surface.

929
00:34:10,760 --> 00:34:11,960
The same hunting queries.

930
00:34:11,960 --> 00:34:13,560
The same attack chain reconstruction.

931
00:34:13,560 --> 00:34:15,320
Your security team already runs.

932
00:34:15,320 --> 00:34:18,440
Put together, this closes a gap that used to be uncomfortably wide.

933
00:34:18,440 --> 00:34:20,920
Agent compromise used to mean discovery weeks later.

934
00:34:20,920 --> 00:34:24,760
Usually through an unrelated audit or a data leak surfacing somewhere downstream.

935
00:34:24,760 --> 00:34:28,760
Now it means the same response speed you'd expect from a compromised human account,

936
00:34:28,760 --> 00:34:33,000
detection, evaluation, blocking, all happening in the moment all tied to an identity that

937
00:34:33,000 --> 00:34:37,880
carries its own behavioral history instead of borrowing rules built for someone else entirely.

938
00:34:37,880 --> 00:34:40,520
The 30-day road map to an agentic workforce.

939
00:34:40,520 --> 00:34:42,200
Here is how you actually build this.

940
00:34:42,200 --> 00:34:44,600
Blueprints, sponsors, conditional access.

941
00:34:44,600 --> 00:34:47,240
None of that matters if it stays on a whiteboard.

942
00:34:47,240 --> 00:34:47,960
You need a plan.

943
00:34:47,960 --> 00:34:49,000
A 30-day road map.

944
00:34:49,000 --> 00:34:51,480
Four weeks each with one specific job to do.

945
00:34:51,480 --> 00:34:53,080
Week one is about the baseline.

946
00:34:53,080 --> 00:34:56,440
Before you build anything new, you have to find what already exists.

947
00:34:56,440 --> 00:34:59,480
You need to inventory every agent currently running in your tenant.

948
00:34:59,480 --> 00:35:00,840
Even the ones nobody is tracking.

949
00:35:00,840 --> 00:35:03,320
The ones a team spun up 18 months ago and forgot about.

950
00:35:03,320 --> 00:35:04,600
You are hunting for orphans.

951
00:35:04,600 --> 00:35:06,120
Agents with no clear owner.

952
00:35:06,120 --> 00:35:07,480
No documented purpose.

953
00:35:07,480 --> 00:35:09,640
Linguering access that nobody remembers granting.

954
00:35:09,640 --> 00:35:11,480
Once you have that list, you set the rules.

955
00:35:11,480 --> 00:35:12,680
Who can create an agent?

956
00:35:12,680 --> 00:35:14,120
What do baseline permissions look like?

957
00:35:14,120 --> 00:35:16,920
What does the sponsor requirement actually mean for your team?

958
00:35:16,920 --> 00:35:18,760
And then you assign the sponsors.

959
00:35:18,760 --> 00:35:22,120
Every single agent on that list gets a human name attached to it.

960
00:35:22,120 --> 00:35:22,840
No exceptions.

961
00:35:22,840 --> 00:35:24,840
No, we will figure it out later.

962
00:35:24,840 --> 00:35:26,280
This is the accountability structure

963
00:35:26,280 --> 00:35:27,800
locking into place immediately.

964
00:35:27,800 --> 00:35:28,840
Not eventually.

965
00:35:28,840 --> 00:35:30,840
Week two shifts to construction.

966
00:35:30,840 --> 00:35:31,720
Build and ground.

967
00:35:31,720 --> 00:35:34,440
This is where you start creating actual agent blueprints.

968
00:35:34,440 --> 00:35:35,880
But you do it deliberately.

969
00:35:35,880 --> 00:35:39,080
Pick two or three high-value areas like support.

970
00:35:39,080 --> 00:35:40,760
Finance or HR.

971
00:35:40,760 --> 00:35:43,080
Places where an agent can produce measurable value quickly.

972
00:35:43,080 --> 00:35:46,040
While you build, you handle data grounding.

973
00:35:46,040 --> 00:35:48,040
You connect these new agents to enterprise search

974
00:35:48,040 --> 00:35:49,720
and the knowledge bases you actually trust.

975
00:35:49,720 --> 00:35:53,160
This ensures every answer they produce ties back to something real.

976
00:35:53,160 --> 00:35:55,480
Instead of something invented, it is the no source,

977
00:35:55,480 --> 00:35:57,240
no answer principle we talked about.

978
00:35:57,240 --> 00:35:58,840
You build it in from day one.

979
00:35:58,840 --> 00:36:01,560
Instead of trying to fix it after a problem surfaces.

980
00:36:01,560 --> 00:36:03,320
Week three is about integration.

981
00:36:03,320 --> 00:36:04,440
Your blueprints exist.

982
00:36:04,440 --> 00:36:06,200
They are grounded in real data.

983
00:36:06,200 --> 00:36:08,440
Now, they need to live where your people actually work.

984
00:36:08,440 --> 00:36:09,880
You wire them into teams.

985
00:36:09,880 --> 00:36:10,840
Into Outlook.

986
00:36:10,840 --> 00:36:11,640
Into SharePoint.

987
00:36:11,640 --> 00:36:13,960
Into the systems your team uses every single day.

988
00:36:13,960 --> 00:36:15,720
An agent that only works in a separate console

989
00:36:15,720 --> 00:36:17,560
is just another tab collecting dust.

990
00:36:17,560 --> 00:36:19,480
It adds no value if nobody opens it.

991
00:36:19,480 --> 00:36:22,040
At the same time, you stand up the approval workflows,

992
00:36:22,040 --> 00:36:24,280
the sponsorship reviews, the access cycles

993
00:36:24,280 --> 00:36:25,720
that keep the system honest.

994
00:36:25,720 --> 00:36:28,120
This is where governance stops being a setup task

995
00:36:28,120 --> 00:36:29,160
and becomes a rhythm.

996
00:36:29,160 --> 00:36:31,240
Week four is when you harden the system.

997
00:36:31,240 --> 00:36:33,880
This is where the security layers actually get switched on.

998
00:36:33,880 --> 00:36:37,160
You apply conditional access policies to your new agent population.

999
00:36:37,160 --> 00:36:38,280
You enable risk detection.

1000
00:36:38,280 --> 00:36:41,000
So strange behavior gets caught the moment it happens.

1001
00:36:41,000 --> 00:36:42,760
Then you test your incident response.

1002
00:36:42,760 --> 00:36:44,360
Use a specific agent scenario.

1003
00:36:44,360 --> 00:36:46,840
Because responding to a compromised agent is not the same

1004
00:36:46,840 --> 00:36:48,440
as responding to a human account.

1005
00:36:48,440 --> 00:36:51,160
You want to know that before you are doing it under pressure.

1006
00:36:51,160 --> 00:36:53,480
Alongside that, you build the monitoring.

1007
00:36:53,480 --> 00:36:55,640
Dashboards that show activity at a glance.

1008
00:36:55,640 --> 00:36:57,400
Audit logs that people actually review.

1009
00:36:57,400 --> 00:37:00,200
A normally detection tuned to how these agents actually behave.

1010
00:37:00,200 --> 00:37:01,000
30 days.

1011
00:37:01,000 --> 00:37:01,800
Four phases.

1012
00:37:01,800 --> 00:37:03,080
Each one builds on the last.

1013
00:37:03,080 --> 00:37:04,280
If you skip the inventory,

1014
00:37:04,280 --> 00:37:06,120
you are building on top of a mess.

1015
00:37:06,120 --> 00:37:09,240
If you skip the grounding, your agents produce answers.

1016
00:37:09,240 --> 00:37:10,440
Nobody can trust.

1017
00:37:10,440 --> 00:37:12,600
The sequence matters as much as the work itself.

1018
00:37:12,600 --> 00:37:14,440
The sponsor model and accountability.

1019
00:37:14,440 --> 00:37:16,680
Governance only works if someone is accountable.

1020
00:37:16,680 --> 00:37:19,160
We have mentioned the sponsor in every section.

1021
00:37:19,160 --> 00:37:21,800
Because it is the thread that holds the architecture together.

1022
00:37:21,800 --> 00:37:24,120
But let's look at what that role actually demands.

1023
00:37:24,120 --> 00:37:26,920
Because saying every agent needs a sponsor is easy.

1024
00:37:26,920 --> 00:37:29,960
It is easy to turn it into a checkbox that nobody takes seriously.

1025
00:37:29,960 --> 00:37:31,960
The sponsor is the human who owns the agent.

1026
00:37:31,960 --> 00:37:33,320
Its existence, its behavior.

1027
00:37:33,320 --> 00:37:35,240
Not in a symbolic way, but a functional one.

1028
00:37:35,240 --> 00:37:36,840
This person approved the agent.

1029
00:37:36,840 --> 00:37:38,360
That approval carries weight.

1030
00:37:38,360 --> 00:37:41,000
They are the one who certifies its access every few months.

1031
00:37:41,000 --> 00:37:44,040
They are the one who manages its retirement when the work is done.

1032
00:37:44,040 --> 00:37:45,160
There is a distinction here.

1033
00:37:45,160 --> 00:37:46,120
You need to get right.

1034
00:37:46,120 --> 00:37:47,560
The sponsor is not the developer.

1035
00:37:47,560 --> 00:37:50,760
It is tempting to assume the person who built the blueprint is the owner.

1036
00:37:50,760 --> 00:37:53,000
They understand the technical details best.

1037
00:37:53,000 --> 00:37:53,640
Right?

1038
00:37:53,640 --> 00:37:56,360
But technical authorship and business accountability are different things.

1039
00:37:56,360 --> 00:37:57,880
The sponsor is the business owner.

1040
00:37:57,880 --> 00:38:00,120
The person who can explain why this agent exists.

1041
00:38:00,120 --> 00:38:01,320
What problem it solves.

1042
00:38:01,320 --> 00:38:03,960
And whether that problem still needs solving six months from now.

1043
00:38:03,960 --> 00:38:07,000
A developer can build something without ever being able to answer those questions.

1044
00:38:07,000 --> 00:38:09,000
Accountability shows up through attestations.

1045
00:38:09,000 --> 00:38:11,000
Sponsors do not sign off once and disappear.

1046
00:38:11,000 --> 00:38:13,800
Every quarter, they confirm the agent is still needed.

1047
00:38:13,800 --> 00:38:16,680
They make sure it isn't picking up permissions it no longer requires.

1048
00:38:16,680 --> 00:38:19,960
This gives the access review a specific face and a specific cadence.

1049
00:38:19,960 --> 00:38:22,920
The sponsor is also the first point of contact when things go wrong.

1050
00:38:22,920 --> 00:38:25,160
If an agent starts pulling data, it shouldn't.

1051
00:38:25,160 --> 00:38:26,280
The path leads to them.

1052
00:38:26,280 --> 00:38:27,880
Not to a generic ITQ.

1053
00:38:27,880 --> 00:38:29,800
Not to an engineer who happens to be on call.

1054
00:38:29,800 --> 00:38:32,680
It goes to the person who understands the agent's purpose.

1055
00:38:32,680 --> 00:38:35,880
The person who can judge quickly if this is a bug or a compromise.

1056
00:38:35,880 --> 00:38:37,880
And this is where the model closes the loop.

1057
00:38:37,880 --> 00:38:40,040
What happens when a sponsor leaves the company?

1058
00:38:40,040 --> 00:38:41,480
Or moves to a different role.

1059
00:38:41,480 --> 00:38:43,880
Under the old model, the answer was usually nothing.

1060
00:38:43,880 --> 00:38:45,560
The identity just kept running.

1061
00:38:45,560 --> 00:38:47,480
Quietly detached from any real ownership.

1062
00:38:47,480 --> 00:38:48,760
It became an orphan.

1063
00:38:48,760 --> 00:38:51,160
Under this model, that departure triggers a review.

1064
00:38:51,160 --> 00:38:53,720
Automatically, no sponsor, no operation.

1065
00:38:53,720 --> 00:38:55,320
Someone has to claim accountability.

1066
00:38:55,320 --> 00:38:56,520
Or the agent is retired.

1067
00:38:56,520 --> 00:38:58,600
That single mechanism is what makes this different.

1068
00:38:58,600 --> 00:39:00,040
No orphans by design.

1069
00:39:00,040 --> 00:39:02,200
It doesn't rely on someone remembering to clean up.

1070
00:39:02,200 --> 00:39:03,880
It is built into the lifecycle itself.

1071
00:39:03,880 --> 00:39:05,800
When you put this together, you get something new.

1072
00:39:05,800 --> 00:39:07,640
Not shadow it running in the background.

1073
00:39:07,640 --> 00:39:09,160
But governed digital workers.

1074
00:39:09,160 --> 00:39:11,400
Each one has a named human standing behind it.

1075
00:39:11,400 --> 00:39:13,480
Behind its access, behind its behavior.

1076
00:39:13,480 --> 00:39:15,960
Exactly like every other person on your payroll.

1077
00:39:15,960 --> 00:39:18,040
Per view and data governance for agents.

1078
00:39:18,040 --> 00:39:20,040
Agents interact with sensitive data.

1079
00:39:20,040 --> 00:39:22,200
We touched on grounding in DLP earlier.

1080
00:39:22,200 --> 00:39:25,480
But there is a deeper layer of enforcement sitting underneath all of it.

1081
00:39:25,480 --> 00:39:26,840
That layer is Per view.

1082
00:39:26,840 --> 00:39:28,840
It starts with your DLP policies.

1083
00:39:28,840 --> 00:39:30,920
This is the piece that does the most immediate work.

1084
00:39:30,920 --> 00:39:35,160
The rules already governing how sensitive data moves through your organization

1085
00:39:35,160 --> 00:39:37,240
now applied directly to agent activity.

1086
00:39:37,240 --> 00:39:39,720
The same rules for what can be shared externally.

1087
00:39:39,720 --> 00:39:41,800
And what triggers a block versus a warning.

1088
00:39:41,800 --> 00:39:43,480
Now watch every move an agent makes.

1089
00:39:43,480 --> 00:39:47,080
If an agent tries to move a labeled document outside an approved boundary,

1090
00:39:47,080 --> 00:39:49,080
it hits the same wall a person would.

1091
00:39:49,080 --> 00:39:50,680
Retention rules apply the same way.

1092
00:39:50,680 --> 00:39:52,840
Sharing restrictions apply the same way.

1093
00:39:52,840 --> 00:39:54,760
The policy doesn't care if the entity is a human

1094
00:39:54,760 --> 00:39:57,320
or an agent identity spawned from a blueprint.

1095
00:39:57,320 --> 00:39:58,600
The rule is the rule.

1096
00:39:58,600 --> 00:40:02,120
Information protection labels extend that same logic to classification.

1097
00:40:02,120 --> 00:40:04,680
A file marked as highly confidential carries that label

1098
00:40:04,680 --> 00:40:06,440
regardless of what is requesting it.

1099
00:40:06,440 --> 00:40:08,520
Agents respect that classification the same way

1100
00:40:08,520 --> 00:40:10,120
a properly configured session would.

1101
00:40:10,120 --> 00:40:12,840
This means the labeling work your organization already invested in

1102
00:40:12,840 --> 00:40:16,440
doesn't need to be rebuilt or re-scoped just because agents entered the picture.

1103
00:40:16,440 --> 00:40:18,040
It was already doing the job.

1104
00:40:18,040 --> 00:40:21,400
Now it is doing that job against a larger population of identities.

1105
00:40:21,400 --> 00:40:23,960
E-discovery and legal hold work on the same principle.

1106
00:40:23,960 --> 00:40:26,120
But we need to be specific about what changes here.

1107
00:40:26,120 --> 00:40:29,560
We already established that agent generated content is discoverable.

1108
00:40:29,560 --> 00:40:32,600
What Per view adds is the mechanism that actually preserves it.

1109
00:40:32,600 --> 00:40:35,720
Legal hold applied to a mailbox or a shared document library

1110
00:40:35,720 --> 00:40:39,000
now extends to capture agent output tied to that same scope.

1111
00:40:39,000 --> 00:40:42,520
This ensures a hold doesn't quietly miss half the relevant record

1112
00:40:42,520 --> 00:40:45,080
just because an agent produced it instead of a person.

1113
00:40:45,080 --> 00:40:48,120
Inside a risk detection is where Per view starts doing something new.

1114
00:40:48,120 --> 00:40:50,440
It isn't just extending and existing control.

1115
00:40:50,440 --> 00:40:53,800
It watches for patterns that look wrong at the agent level specifically.

1116
00:40:53,800 --> 00:40:57,000
Bulk downloads that don't match a task's expected footprint.

1117
00:40:57,000 --> 00:40:59,880
Activity suddenly crossing into a different tenant boundary.

1118
00:40:59,880 --> 00:41:03,400
Access patterns that deviate from what that particular agent normally does.

1119
00:41:03,400 --> 00:41:07,640
This isn't the same signal, enter ID protection evaluates for authentication risk.

1120
00:41:07,640 --> 00:41:08,920
It is a data behavior signal.

1121
00:41:08,920 --> 00:41:09,880
It sits one layer up.

1122
00:41:09,880 --> 00:41:12,200
It watches what happens after an agent already has a token

1123
00:41:12,200 --> 00:41:13,880
and is actively moving through content.

1124
00:41:13,880 --> 00:41:17,640
I describe the effect as something closer to a magnifying glass than a gate.

1125
00:41:17,640 --> 00:41:21,000
Per view isn't deciding whether an agent gets access in the first place.

1126
00:41:21,000 --> 00:41:24,120
It is watching what that access actually produces in real time.

1127
00:41:24,120 --> 00:41:26,920
It flags the moment behavior around sensitive data,

1128
00:41:26,920 --> 00:41:29,320
stops looking like the agent's established pattern.

1129
00:41:29,320 --> 00:41:31,080
And these policies aren't static.

1130
00:41:31,080 --> 00:41:34,600
Enforcement can tighten dynamically based on how sensitive the data is

1131
00:41:34,600 --> 00:41:37,560
and how risky the agent has been flagged elsewhere in the stack.

1132
00:41:37,560 --> 00:41:41,720
An agent operating cleanly against low sensitivity content might see minimal friction.

1133
00:41:41,720 --> 00:41:45,560
But that same agent reaching towards something classified as highly restricted encounters

1134
00:41:45,560 --> 00:41:48,120
a stricter version of the same policy automatically.

1135
00:41:48,120 --> 00:41:52,760
The same thing happens if the agent carries an elevated risk score from a recent anomaly.

1136
00:41:52,760 --> 00:41:56,920
What this closes ultimately is the gap that made agents dangerous in the first place.

1137
00:41:56,920 --> 00:41:58,520
The ability to move data quietly.

1138
00:41:58,520 --> 00:42:02,120
Without triggering any of the compliance machinery already protecting your tenant,

1139
00:42:02,120 --> 00:42:03,560
that gap doesn't exist anymore.

1140
00:42:03,560 --> 00:42:07,080
Data governance built for people now covers the agents acting alongside them.

1141
00:42:07,080 --> 00:42:08,600
Evaluated by the same rules,

1142
00:42:08,600 --> 00:42:09,960
held to the same standard,

1143
00:42:09,960 --> 00:42:12,200
with no separate weaker track running underneath.

1144
00:42:12,200 --> 00:42:15,720
Defender and threat protection for agents.

1145
00:42:15,720 --> 00:42:18,920
Agents are targets, not theoretical ones, actual ones.

1146
00:42:18,920 --> 00:42:23,400
Defender treats them exactly like any other identity worth protecting.

1147
00:42:23,400 --> 00:42:27,000
It doesn't bolt on a separate weaker security track just because they are automated.

1148
00:42:27,000 --> 00:42:29,720
That starts with AI security posture management.

1149
00:42:29,720 --> 00:42:32,760
This is the piece that catches problems before they become incidents.

1150
00:42:32,760 --> 00:42:36,280
It is constantly scanning your agent population for misconfigurations,

1151
00:42:36,280 --> 00:42:38,440
permissions that drifted wider than intended.

1152
00:42:38,440 --> 00:42:41,560
Blueprints that granted more scope than the use case actually required.

1153
00:42:41,560 --> 00:42:44,120
This is posture assessment, not incident response.

1154
00:42:44,120 --> 00:42:45,880
It is answering a quieter question.

1155
00:42:45,880 --> 00:42:48,840
Before anything goes wrong, where are we already exposed?

1156
00:42:48,840 --> 00:42:51,000
Run time protection is where things get active.

1157
00:42:51,000 --> 00:42:53,720
Defender watches agent behavior as it happens.

1158
00:42:53,720 --> 00:42:58,680
It can block malicious actions in real time instead of just flagging them for review after the damage is done.

1159
00:42:58,680 --> 00:43:03,160
An agent attempting something outside its intended function gets stopped at the moment of the attempt.

1160
00:43:03,160 --> 00:43:07,000
It isn't discovered three days later in a log review that nobody scheduled.

1161
00:43:07,000 --> 00:43:08,920
Attack chain detection extends that further.

1162
00:43:08,920 --> 00:43:12,120
A single flagged action rarely tells the whole story on its own.

1163
00:43:12,120 --> 00:43:16,520
Defender connects an agent compromised to the broader sequence surrounding it,

1164
00:43:16,520 --> 00:43:18,680
what led up to it, what it touched after it,

1165
00:43:18,680 --> 00:43:22,360
and whether it is one isolated event or a link in something larger,

1166
00:43:22,360 --> 00:43:23,640
moving through your environment.

1167
00:43:23,640 --> 00:43:28,200
That connective view is what separates a contained incident from one that spreads quietly,

1168
00:43:28,200 --> 00:43:30,600
while everyone is looking at the wrong piece of it.

1169
00:43:30,600 --> 00:43:33,160
Two specific attack patterns deserve naming directly.

1170
00:43:33,160 --> 00:43:35,640
They are unique to how agents actually get manipulated.

1171
00:43:35,640 --> 00:43:41,160
Jailbreak and prompt injection attempts try to talk an agent into acting outside its intended behavior.

1172
00:43:41,160 --> 00:43:45,480
It is essentially social engineering aimed at a non-human target instead of a person.

1173
00:43:45,480 --> 00:43:48,440
Defender is built to recognize these attempts specifically.

1174
00:43:48,440 --> 00:43:50,280
It doesn't just look for generic anomalies,

1175
00:43:50,280 --> 00:43:55,160
it looks for the particular shape a manipulation attempt takes when the target is a language driven system.

1176
00:43:55,160 --> 00:43:58,200
Unsafe invocations get handled at the enforcement layer directly.

1177
00:43:58,200 --> 00:44:03,160
If an agent tries calling a dangerous API or reaching toward a resource outside its permitted boundary,

1178
00:44:03,160 --> 00:44:05,560
that call gets blocked before it executes.

1179
00:44:05,560 --> 00:44:09,480
This sits alongside the scoped permissions we built into the blueprint architecture,

1180
00:44:09,480 --> 00:44:10,760
but it is a distinct check.

1181
00:44:10,760 --> 00:44:13,080
It evaluates the action itself in the moment,

1182
00:44:13,080 --> 00:44:16,600
not just whether the underlying permission technically exists somewhere in the grant.

1183
00:44:16,600 --> 00:44:20,840
Investigation and hunting is where all of this becomes usable by an actual human analyst.

1184
00:44:20,840 --> 00:44:24,760
Agent activity correlates directly with user actions and broader system changes,

1185
00:44:24,760 --> 00:44:28,680
an investigation never treats an agent incident as its own isolated puzzle.

1186
00:44:28,680 --> 00:44:31,720
It isn't disconnected from everything else happening in the tenant,

1187
00:44:31,720 --> 00:44:33,080
it is one continuous picture.

1188
00:44:33,080 --> 00:44:35,640
Agents and humans are woven into the same timeline.

1189
00:44:35,640 --> 00:44:38,200
What this ultimately delivers is parity, plain and simple.

1190
00:44:38,200 --> 00:44:43,960
The same threat detection depth your organization already built for human identities now covers agents too,

1191
00:44:43,960 --> 00:44:45,560
not a scaled down version,

1192
00:44:45,560 --> 00:44:49,160
not a best effort add on shipped later because someone remembered agents existed.

1193
00:44:49,160 --> 00:44:51,960
The same post-gear management, the same runtime blocking,

1194
00:44:51,960 --> 00:44:53,560
the same attack chain reconstruction,

1195
00:44:53,560 --> 00:44:56,040
all of it applied to a population of identities that,

1196
00:44:56,040 --> 00:45:00,440
until recently, sat almost entirely outside anyone's threat model.

1197
00:45:00,440 --> 00:45:02,120
The multi-tenant complexity.

1198
00:45:02,120 --> 00:45:05,400
If you operate across tenants, the model gets more sophisticated.

1199
00:45:05,400 --> 00:45:09,560
This is where the architecture has to handle a problem the single tenant view doesn't prepare you for.

1200
00:45:09,560 --> 00:45:13,480
What happens when the organization building an agent isn't the same organization running it?

1201
00:45:13,480 --> 00:45:16,760
Start with the distinction between a publishing tenant and a consuming tenant.

1202
00:45:16,760 --> 00:45:19,960
An independent software vendor building an agent for broad distribution

1203
00:45:19,960 --> 00:45:23,320
creates that agent's blueprint in its own tenant, the publishing side.

1204
00:45:23,320 --> 00:45:26,520
But the custom is actually deploying that agent are consuming tenants

1205
00:45:26,520 --> 00:45:29,960
that there could be dozens or hundreds of separate organizations involved here.

1206
00:45:29,960 --> 00:45:32,760
Each one is running its own instance of something they didn't build

1207
00:45:32,760 --> 00:45:35,960
and something they don't directly control at the template level.

1208
00:45:35,960 --> 00:45:39,080
That relationship works through blueprint service principles.

1209
00:45:39,080 --> 00:45:41,960
Each consuming tenant that adopts a published blueprint

1210
00:45:41,960 --> 00:45:46,200
gets its own service principle and that principle links back to the original blueprint

1211
00:45:46,200 --> 00:45:47,720
sitting in the publisher's environment.

1212
00:45:47,720 --> 00:45:49,560
This isn't a copy of the blueprint itself.

1213
00:45:49,560 --> 00:45:51,640
It's a tenant-specific manifestation.

1214
00:45:51,640 --> 00:45:55,640
It holds the credentials and configuration relevant to that one organization's deployment.

1215
00:45:55,640 --> 00:45:58,760
While the underlying template stays owned and maintained by the publisher,

1216
00:45:58,760 --> 00:46:02,760
nothing about that instantiation happens automatically or silently.

1217
00:46:02,760 --> 00:46:05,800
Consent and approval sit in front of it deliberately.

1218
00:46:05,800 --> 00:46:09,400
A consuming organization has to explicitly agree to use a given blueprint

1219
00:46:09,400 --> 00:46:13,000
before any agent instances can spawn from it inside their tenant.

1220
00:46:13,000 --> 00:46:15,880
That approval step is the same trust boundary you'd expect

1221
00:46:15,880 --> 00:46:19,320
from any third-party application requesting access to your directory.

1222
00:46:19,320 --> 00:46:23,000
But it's applied here to an agent template instead of a traditional app registration.

1223
00:46:23,000 --> 00:46:26,440
Once that consent exists, the scaling potential is significant.

1224
00:46:26,440 --> 00:46:29,400
A single blueprint maintained in one place by the publisher

1225
00:46:29,400 --> 00:46:34,440
can power agent instances running across a hundred or more separate organizations simultaneously.

1226
00:46:34,440 --> 00:46:37,800
Each of those instances still carries its own agent identity.

1227
00:46:37,800 --> 00:46:41,480
Each one still gets its own sponsor requirement inside the consuming tenant

1228
00:46:41,480 --> 00:46:44,120
and each one still logs its own activity independently.

1229
00:46:44,120 --> 00:46:47,240
The publisher isn't managing every individual instance directly,

1230
00:46:47,240 --> 00:46:49,000
they're managing the template.

1231
00:46:49,000 --> 00:46:51,560
While consuming tenants manage the accountability layer

1232
00:46:51,560 --> 00:46:53,560
for what runs inside their own boundary,

1233
00:46:53,560 --> 00:46:56,360
that split creates a specific kind of audit alignment.

1234
00:46:56,360 --> 00:46:59,640
Each consuming tenant sees its own agent activity in full,

1235
00:46:59,640 --> 00:47:01,800
including its own logs, its own risk signals,

1236
00:47:01,800 --> 00:47:03,320
and its own sponsor attribution.

1237
00:47:03,320 --> 00:47:07,240
This is exactly the visibility we covered when we walked through observability earlier.

1238
00:47:07,240 --> 00:47:10,120
The publisher meanwhile maintains the blueprint itself.

1239
00:47:10,120 --> 00:47:13,080
They are responsible for what the template defines and how it behaves

1240
00:47:13,080 --> 00:47:17,880
without necessarily having visibility into every downstream tenant's specific usage patterns.

1241
00:47:17,880 --> 00:47:20,600
Two different parties, two different scopes of accountability,

1242
00:47:20,600 --> 00:47:23,160
both operating against the same underlying object.

1243
00:47:23,160 --> 00:47:25,800
What this ultimately enables is ecosystem level scaling

1244
00:47:25,800 --> 00:47:27,880
without collapsing tenant isolation.

1245
00:47:27,880 --> 00:47:30,520
An ISV can build once and distribute broadly.

1246
00:47:30,520 --> 00:47:35,080
It's the same efficiency that makes traditional multi-tenant applications viable at scale.

1247
00:47:35,080 --> 00:47:39,240
But every organization running that agent keeps its own governance boundary fully intact.

1248
00:47:39,240 --> 00:47:42,120
They keep their own sponsors, their own conditional access policies,

1249
00:47:42,120 --> 00:47:43,560
and their own compliance posture.

1250
00:47:43,560 --> 00:47:47,960
None of it is inherited or diluted just because the underlying template came from somewhere else.

1251
00:47:47,960 --> 00:47:49,880
The blueprint travels, the accountability doesn't,

1252
00:47:49,880 --> 00:47:51,320
the agent user extension,

1253
00:47:51,320 --> 00:47:53,240
some agents need to be more human-like.

1254
00:47:53,240 --> 00:47:56,600
And this is where the architecture we've spent so long on runs into its own boundary.

1255
00:47:56,600 --> 00:47:57,880
Everything we've covered up to now,

1256
00:47:57,880 --> 00:48:00,840
Blueprints, agent identities, service principles, subtypes,

1257
00:48:00,840 --> 00:48:03,400
is credentialless and service-principled based by design.

1258
00:48:03,400 --> 00:48:06,280
That design works cleanly for an agent calling APIs,

1259
00:48:06,280 --> 00:48:10,280
reaching into data sources, or executing tasks under its own authority.

1260
00:48:10,280 --> 00:48:11,880
But it doesn't work for everything.

1261
00:48:11,880 --> 00:48:13,240
Because some systems,

1262
00:48:13,240 --> 00:48:15,320
Exchange mailboxes, teams conversations,

1263
00:48:15,320 --> 00:48:17,400
the organizational chart itself,

1264
00:48:17,400 --> 00:48:21,000
are built around the assumption that whatever is interacting with them is a user object.

1265
00:48:21,000 --> 00:48:22,600
They aren't looking for a service principle,

1266
00:48:22,600 --> 00:48:23,800
wearing an agent label.

1267
00:48:23,800 --> 00:48:25,480
That's the gap the agent user fills,

1268
00:48:25,480 --> 00:48:27,080
and it's explicitly optional.

1269
00:48:27,080 --> 00:48:28,680
You don't create one by default.

1270
00:48:28,680 --> 00:48:31,880
You create one when an agent genuinely needs to show up in teams,

1271
00:48:31,880 --> 00:48:33,320
or receive mail in exchange,

1272
00:48:33,320 --> 00:48:36,840
or appear as an entry in the org chart alongside actual employees.

1273
00:48:36,840 --> 00:48:38,680
Most agents running background tasks,

1274
00:48:38,680 --> 00:48:41,000
reconciling data, or monitoring systems,

1275
00:48:41,000 --> 00:48:41,960
never need this extension.

1276
00:48:41,960 --> 00:48:46,600
It exists specifically for the subset that has to operate in spaces built around human presence.

1277
00:48:46,600 --> 00:48:49,000
The relationship here is a parent-child structure.

1278
00:48:49,000 --> 00:48:50,200
It's not a replacement.

1279
00:48:50,200 --> 00:48:53,480
An agent user doesn't stand alone as its own independent identity

1280
00:48:53,480 --> 00:48:55,640
floating separately from everything we've built.

1281
00:48:55,640 --> 00:48:58,120
It's tied directly to its parent agent identity.

1282
00:48:58,120 --> 00:48:59,400
It inherits that lineage,

1283
00:48:59,400 --> 00:49:01,000
that sponsor accountability,

1284
00:49:01,000 --> 00:49:03,800
and that audit trail we covered under observability.

1285
00:49:03,800 --> 00:49:06,840
The agent user is an extension of something that already exists.

1286
00:49:06,840 --> 00:49:10,760
It's not a second disconnected identity requiring its own separate governance model,

1287
00:49:10,760 --> 00:49:11,800
bolted on afterward.

1288
00:49:11,800 --> 00:49:14,360
What that extension actually unlocks is fairly specific.

1289
00:49:14,360 --> 00:49:17,640
Mailbox capability means an agent user can hold an exchange mailbox

1290
00:49:17,640 --> 00:49:19,080
and receive email directly.

1291
00:49:19,080 --> 00:49:21,640
The same way a person would get looped into a thread.

1292
00:49:21,640 --> 00:49:25,080
Teams presence means that agent can participate in conversations and channels.

1293
00:49:25,080 --> 00:49:27,000
It's visible the way a colleague is visible,

1294
00:49:27,000 --> 00:49:30,360
not hidden behind an API call nobody in the room can see happening.

1295
00:49:30,360 --> 00:49:34,200
An org-charge visibility means the agent actually appears in the organizational hierarchy.

1296
00:49:34,200 --> 00:49:37,560
It's a digital entry sitting alongside the human entries around it.

1297
00:49:37,560 --> 00:49:40,280
Discoverable in exactly the way employees are discoverable.

1298
00:49:40,280 --> 00:49:43,240
I want to be precise about where this sits in the maturity timeline.

1299
00:49:43,240 --> 00:49:47,000
It's easy to assume everything in this episode is equally available today.

1300
00:49:47,000 --> 00:49:47,720
It isn't.

1301
00:49:47,720 --> 00:49:49,480
This piece is still in Frontier Preview,

1302
00:49:49,480 --> 00:49:50,920
not general availability.

1303
00:49:50,920 --> 00:49:53,960
It's not something you're deploying broadly into production this quarter,

1304
00:49:53,960 --> 00:49:55,560
but it's worth understanding now.

1305
00:49:55,560 --> 00:49:58,200
Because it's the clearest signal of where the roadmap is heading.

1306
00:49:58,200 --> 00:50:01,640
To what agents that don't just execute tasks quietly in the background.

1307
00:50:01,640 --> 00:50:04,840
But sit inside the same collaborative space as your people already work in.

1308
00:50:04,840 --> 00:50:05,960
They become addressable.

1309
00:50:05,960 --> 00:50:07,480
The same way a colleague is addressable.

1310
00:50:07,480 --> 00:50:11,640
That's a meaningfully different kind of integration than anything we've discussed so far.

1311
00:50:11,640 --> 00:50:14,440
Everything earlier in this episode governs what an agent can access

1312
00:50:14,440 --> 00:50:16,040
and who's accountable for it.

1313
00:50:16,040 --> 00:50:18,840
The agent user governs how an agent shows up, how it's found,

1314
00:50:18,840 --> 00:50:22,200
how someone reaches it without needing to know which platform built it,

1315
00:50:22,200 --> 00:50:23,480
or which blueprints spawned it.

1316
00:50:23,480 --> 00:50:25,720
It's not a governance layer, it's a presence layer.

1317
00:50:25,720 --> 00:50:29,160
And it sits on top of a governance model that already has to be solid

1318
00:50:29,160 --> 00:50:32,040
before you'd ever want an agent visible enough to email directly.

1319
00:50:32,040 --> 00:50:34,920
Observability and logging.

1320
00:50:34,920 --> 00:50:36,600
You can't govern what you can't see.

1321
00:50:36,600 --> 00:50:38,280
Everything we've covered so far.

1322
00:50:38,280 --> 00:50:41,560
Sponsors, conditional access, risk detection.

1323
00:50:41,560 --> 00:50:44,200
It all depends on one thing sitting underneath it.

1324
00:50:44,200 --> 00:50:45,560
A record of what actually happened.

1325
00:50:45,560 --> 00:50:49,160
Observability isn't a feature you bolt on after the big decisions are made.

1326
00:50:49,160 --> 00:50:51,320
It's the foundation the entire structure rests on.

1327
00:50:51,320 --> 00:50:53,160
It starts with agent sign-in logs.

1328
00:50:53,160 --> 00:50:54,840
This is dedicated telemetry.

1329
00:50:54,840 --> 00:50:57,240
It was built specifically to capture how agents authenticate

1330
00:50:57,240 --> 00:50:58,760
and how they get their tokens.

1331
00:50:58,760 --> 00:51:02,360
It's separate from the general sign-in stream your directory creates for human users.

1332
00:51:02,360 --> 00:51:04,840
When an agent requests a token through its blueprint,

1333
00:51:04,840 --> 00:51:08,440
that event is recorded with the specificity the identity deserves.

1334
00:51:08,440 --> 00:51:11,080
It isn't folded into a generic service account log,

1335
00:51:11,080 --> 00:51:13,160
where it's indistinguishable from 100 other things.

1336
00:51:13,160 --> 00:51:16,120
Activity logs go one level deeper than authentication.

1337
00:51:16,120 --> 00:51:19,000
Every action an agent takes is recorded with full context.

1338
00:51:19,000 --> 00:51:22,440
Not just that something happened, but what was touched when it happened.

1339
00:51:22,440 --> 00:51:23,880
And what authority was used,

1340
00:51:23,880 --> 00:51:26,280
that's the difference between knowing an agent existed

1341
00:51:26,280 --> 00:51:28,440
and knowing what it actually did while it was running.

1342
00:51:28,440 --> 00:51:30,280
And this is where we connect back to the architecture.

1343
00:51:30,280 --> 00:51:32,040
Logs don't just show that an agent acted.

1344
00:51:32,040 --> 00:51:33,480
They show the blueprint lineage.

1345
00:51:33,480 --> 00:51:36,040
They show which blueprint spawned that specific instance,

1346
00:51:36,040 --> 00:51:37,800
tracing the identity back to its template,

1347
00:51:37,800 --> 00:51:39,240
its permission inheritance.

1348
00:51:39,240 --> 00:51:40,680
And its original configuration.

1349
00:51:40,680 --> 00:51:42,760
If something looks wrong with one instance,

1350
00:51:42,760 --> 00:51:44,920
you aren't investigating in isolation.

1351
00:51:44,920 --> 00:51:46,760
You can pull every other instance spawned

1352
00:51:46,760 --> 00:51:50,040
from that same blueprint to see if the problem is contained to one agent.

1353
00:51:50,040 --> 00:51:52,280
Or if it's baked into the template itself.

1354
00:51:52,280 --> 00:51:55,160
Sponsor attribution closes the loop from the other side.

1355
00:51:55,160 --> 00:51:57,320
Every logged action ties back to the agent,

1356
00:51:57,320 --> 00:51:58,520
to the blueprint,

1357
00:51:58,520 --> 00:52:01,400
and to the human accountable for that agent's existence.

1358
00:52:01,400 --> 00:52:04,600
This is the sponsor model made operational inside the logging layer.

1359
00:52:04,600 --> 00:52:06,840
It isn't a separate lookup someone has to perform manually

1360
00:52:06,840 --> 00:52:08,200
when an incident starts.

1361
00:52:08,200 --> 00:52:09,720
The accountability we talked about earlier

1362
00:52:09,720 --> 00:52:11,240
isn't just a policy commitment.

1363
00:52:11,240 --> 00:52:12,840
It shows up directly in the record.

1364
00:52:12,840 --> 00:52:14,440
All of this feeds into Azure Monitor.

1365
00:52:14,440 --> 00:52:17,400
This telemetry doesn't live in a silo built only for agents.

1366
00:52:17,400 --> 00:52:19,000
It feeds into the same infrastructure,

1367
00:52:19,000 --> 00:52:21,080
your security and operations teams already used

1368
00:52:21,080 --> 00:52:22,120
for everything else.

1369
00:52:22,120 --> 00:52:22,920
That matters.

1370
00:52:22,920 --> 00:52:24,680
It means agent activity is correlated

1371
00:52:24,680 --> 00:52:27,240
alongside every other signal your teams are already watching.

1372
00:52:27,240 --> 00:52:28,440
You don't need a separate tool

1373
00:52:28,440 --> 00:52:30,840
that nobody outside the AI team ever opens.

1374
00:52:30,840 --> 00:52:32,840
There's also a specific capability you need to know

1375
00:52:32,840 --> 00:52:34,440
the is agent filter.

1376
00:52:34,440 --> 00:52:35,720
Inside your existing logs,

1377
00:52:35,720 --> 00:52:39,080
you can isolate agent activity from user activity with one click.

1378
00:52:39,080 --> 00:52:41,560
You don't have to manually pass through mixed telemetry

1379
00:52:41,560 --> 00:52:44,200
trying to guess which entries belong to which category

1380
00:52:44,200 --> 00:52:45,960
when you're investigating at speed.

1381
00:52:45,960 --> 00:52:48,600
That filter is the difference between minutes and hours.

1382
00:52:48,600 --> 00:52:50,840
This visibility does two jobs at once.

1383
00:52:50,840 --> 00:52:52,680
It satisfies governance compliance,

1384
00:52:52,680 --> 00:52:54,680
giving you the evidence trail auditors expect

1385
00:52:54,680 --> 00:52:57,240
when they ask how an agent's actions map back to a human.

1386
00:52:57,240 --> 00:52:59,080
And it satisfies incident response,

1387
00:52:59,080 --> 00:53:01,640
giving your security team the same investigative depth

1388
00:53:01,640 --> 00:53:04,040
for an agent that they'd expect for a human account.

1389
00:53:04,040 --> 00:53:05,880
Neither of those outcomes is possible

1390
00:53:05,880 --> 00:53:07,240
without this logging layer.

1391
00:53:07,240 --> 00:53:08,840
Every mechanism we've described,

1392
00:53:08,840 --> 00:53:11,160
sponsors, blueprints, conditional access,

1393
00:53:11,160 --> 00:53:13,560
it all depends on a record that proves it actually worked.

1394
00:53:13,560 --> 00:53:16,440
The ecosystem and platform integration.

1395
00:53:16,440 --> 00:53:18,600
Agent ID doesn't exist in isolation.

1396
00:53:18,600 --> 00:53:19,800
The identity model,

1397
00:53:19,800 --> 00:53:22,280
the governance layers, the observability.

1398
00:53:22,280 --> 00:53:25,160
It all sits underneath a broader ecosystem of platforms

1399
00:53:25,160 --> 00:53:26,440
where agents actually get built.

1400
00:53:26,440 --> 00:53:28,280
You need to understand this ecosystem

1401
00:53:28,280 --> 00:53:30,760
because your agents won't come from just one source.

1402
00:53:30,760 --> 00:53:33,400
Most organizations will start with co-pilot studio.

1403
00:53:33,400 --> 00:53:34,680
It's the low-code platform.

1404
00:53:34,680 --> 00:53:36,200
It's built for teams that need to stand up

1405
00:53:36,200 --> 00:53:38,680
and agent without a dedicated engineering team.

1406
00:53:38,680 --> 00:53:40,840
A business analyst building a support agent

1407
00:53:40,840 --> 00:53:43,000
or an HR lead building and onboarding assistant

1408
00:53:43,000 --> 00:53:44,360
that work happens here.

1409
00:53:44,360 --> 00:53:45,320
But here's the thing,

1410
00:53:45,320 --> 00:53:47,160
whatever is built in co-pilot studio

1411
00:53:47,160 --> 00:53:48,520
still gets a proper agent ID.

1412
00:53:48,520 --> 00:53:49,640
It still gets a blueprint.

1413
00:53:49,640 --> 00:53:52,120
It still follows the exact same governance model.

1414
00:53:52,120 --> 00:53:53,720
Low-code doesn't mean low governance.

1415
00:53:53,720 --> 00:53:56,440
As your AI foundry sits at the other end of the spectrum,

1416
00:53:56,440 --> 00:53:57,880
this is the pro-code platform.

1417
00:53:57,880 --> 00:53:59,880
It's for agents that need real orchestration.

1418
00:53:59,880 --> 00:54:00,920
Custom logic.

1419
00:54:00,920 --> 00:54:03,640
And complex reasoning that a low-code builder can't express.

1420
00:54:03,640 --> 00:54:06,280
This is where your engineers build the sophisticated agents

1421
00:54:06,280 --> 00:54:08,440
that handle complicated business processes.

1422
00:54:08,440 --> 00:54:10,360
Different audience, different tooling,

1423
00:54:10,360 --> 00:54:12,120
same underlying identity architecture,

1424
00:54:12,120 --> 00:54:14,200
power platform threads through both of these.

1425
00:54:14,200 --> 00:54:17,400
It connects agents into power-automate flows and power apps.

1426
00:54:17,400 --> 00:54:19,720
Wiring them into the processes people run every day.

1427
00:54:19,720 --> 00:54:22,760
An agent built in foundry can trigger a power-automate flow.

1428
00:54:22,760 --> 00:54:25,960
One built in co-pilot studio can surface inside a power app.

1429
00:54:25,960 --> 00:54:28,760
The platforms aren't walled off, they interlock.

1430
00:54:28,760 --> 00:54:30,440
Then there is Microsoft Foundry.

1431
00:54:30,440 --> 00:54:32,600
This is the managed platform where agents run at scale

1432
00:54:32,600 --> 00:54:34,520
with the observability we just walked through.

1433
00:54:34,520 --> 00:54:36,680
It handles the tracing, the monitoring,

1434
00:54:36,680 --> 00:54:39,640
and the evaluation that keeps a production agent population healthy.

1435
00:54:39,640 --> 00:54:41,160
It's lesser place where you build.

1436
00:54:41,160 --> 00:54:42,680
And more a place where things operate

1437
00:54:42,680 --> 00:54:44,920
once they move past the prototype stage.

1438
00:54:44,920 --> 00:54:46,040
We also have MCP,

1439
00:54:46,040 --> 00:54:47,320
the model context protocol.

1440
00:54:47,320 --> 00:54:49,880
This is the standard connecting agents to tools and data sources

1441
00:54:49,880 --> 00:54:51,560
regardless of which platform built them.

1442
00:54:51,560 --> 00:54:53,720
Instead of every agent needing a custom integration

1443
00:54:53,720 --> 00:54:56,280
to reach a system, MCP gives you a common language.

1444
00:54:56,280 --> 00:54:59,240
An agent from foundry and an agent from co-pilot studio

1445
00:54:59,240 --> 00:55:01,800
can both reach the same tool through the same protocol.

1446
00:55:01,800 --> 00:55:04,840
The platforms don't need to understand each other's internals.

1447
00:55:04,840 --> 00:55:06,680
What ties all of this together is the registry.

1448
00:55:06,680 --> 00:55:08,600
The registry doesn't care where an agent came from.

1449
00:55:08,600 --> 00:55:10,600
Every agent appears in that central catalog

1450
00:55:10,600 --> 00:55:12,920
regardless of the platform, the discoverability,

1451
00:55:12,920 --> 00:55:14,840
the classification, the visibility.

1452
00:55:14,840 --> 00:55:17,640
It all applies whether the agent was built by a business analyst

1453
00:55:17,640 --> 00:55:18,840
or an engineering team.

1454
00:55:18,840 --> 00:55:21,400
That interoperability is what keeps this model from breaking.

1455
00:55:21,400 --> 00:55:24,760
The moment your organization uses more than one tool to build agents,

1456
00:55:24,760 --> 00:55:26,440
which you will, the model holds.

1457
00:55:26,440 --> 00:55:28,040
You aren't maintaining separate governance

1458
00:55:28,040 --> 00:55:30,280
for separate platforms, your governing agents.

1459
00:55:30,280 --> 00:55:31,320
Full stop.

1460
00:55:31,320 --> 00:55:33,480
One identity model, one registry,

1461
00:55:33,480 --> 00:55:35,400
one set of sponsor and access rules.

1462
00:55:35,400 --> 00:55:38,040
The rules don't care which logo appeared on the builder's screen.

1463
00:55:38,040 --> 00:55:39,560
The competitive advantage,

1464
00:55:39,560 --> 00:55:41,880
early agent governance is a structural advantage.

1465
00:55:41,880 --> 00:55:43,480
It sounds like a compliance burden.

1466
00:55:43,480 --> 00:55:45,240
If you only look at it through security,

1467
00:55:45,240 --> 00:55:47,640
but in reality, it's a business strategy.

1468
00:55:47,640 --> 00:55:49,400
The organization's treating it that way

1469
00:55:49,400 --> 00:55:51,800
will out execute the ones treating it like paperwork.

1470
00:55:51,800 --> 00:55:53,800
It starts with first mover governance.

1471
00:55:53,800 --> 00:55:56,760
Teams building sponsor models and blueprints standards right now

1472
00:55:56,760 --> 00:55:58,200
aren't just checking a box.

1473
00:55:58,200 --> 00:55:59,480
They're establishing the patterns

1474
00:55:59,480 --> 00:56:01,480
everyone else will eventually have to copy.

1475
00:56:01,480 --> 00:56:03,160
Being the organization with a working template

1476
00:56:03,160 --> 00:56:04,600
when new regulations land

1477
00:56:04,600 --> 00:56:06,680
or when the board asks about AI accountability

1478
00:56:06,680 --> 00:56:09,720
is a different position than scrambling to build one under pressure.

1479
00:56:09,720 --> 00:56:12,040
That leads directly into compliance readiness.

1480
00:56:12,040 --> 00:56:14,600
Regulators will eventually demand agent auditability

1481
00:56:14,600 --> 00:56:16,360
and given the trajectory we've traced.

1482
00:56:16,360 --> 00:56:17,320
That demand is coming.

1483
00:56:17,320 --> 00:56:19,160
Organizations with sponsor attribution

1484
00:56:19,160 --> 00:56:20,920
and full activity logging already in place

1485
00:56:20,920 --> 00:56:22,360
simply produce the evidence.

1486
00:56:22,360 --> 00:56:24,440
There is no emergency remediation project

1487
00:56:24,440 --> 00:56:26,280
and no six months scrambled to reconstruct

1488
00:56:26,280 --> 00:56:27,880
what an agent did two years ago.

1489
00:56:27,880 --> 00:56:29,400
The answer already exists in the logs.

1490
00:56:29,400 --> 00:56:31,240
Data protection follows the same logic.

1491
00:56:31,240 --> 00:56:33,240
If you've already built the purview integration

1492
00:56:33,240 --> 00:56:35,480
and the DLP enforcement we walked through earlier,

1493
00:56:35,480 --> 00:56:37,800
you've prevented the leak before it became a headline.

1494
00:56:37,800 --> 00:56:40,440
That isn't a defensive posture you prove after the fact.

1495
00:56:40,440 --> 00:56:41,880
It's already done.

1496
00:56:41,880 --> 00:56:44,680
Incident response compounds this advantage even further.

1497
00:56:44,680 --> 00:56:46,920
An organization that has tested its response process

1498
00:56:46,920 --> 00:56:48,360
against a compromised agent,

1499
00:56:48,360 --> 00:56:50,520
the way we described in the 30-day roadmap,

1500
00:56:50,520 --> 00:56:52,360
response to that threat as fast as they were

1501
00:56:52,360 --> 00:56:53,800
to compromise human account.

1502
00:56:53,800 --> 00:56:55,880
The organization that never ran that test

1503
00:56:55,880 --> 00:56:57,880
is discovering the truth in real time.

1504
00:56:57,880 --> 00:56:59,880
They're learning during an actual incident

1505
00:56:59,880 --> 00:57:03,320
that agent compromise doesn't behave like the playbooks they already have.

1506
00:57:03,320 --> 00:57:06,040
There is also an organizational learning dimension here.

1507
00:57:06,040 --> 00:57:08,440
Companies governing their agent population

1508
00:57:08,440 --> 00:57:10,200
properly are the ones who understand.

1509
00:57:10,200 --> 00:57:13,960
Concretely, how agents actually change the shape of work inside their walls.

1510
00:57:13,960 --> 00:57:15,800
They know what tasks genuinely got faster.

1511
00:57:15,800 --> 00:57:18,760
They know where an agent created friction instead of removing it.

1512
00:57:18,760 --> 00:57:20,680
That understanding doesn't come from good intentions.

1513
00:57:20,680 --> 00:57:23,400
It comes from having enough visibility and structure in place

1514
00:57:23,400 --> 00:57:24,840
to observe it honestly.

1515
00:57:24,840 --> 00:57:26,920
And finally, cross-control.

1516
00:57:26,920 --> 00:57:28,840
It sounds mundane next to security.

1517
00:57:28,840 --> 00:57:30,280
But it matters just as much.

1518
00:57:30,280 --> 00:57:32,760
Agents sprawl without a registry or lifecycle policies

1519
00:57:32,760 --> 00:57:34,120
doesn't just create a headache.

1520
00:57:34,120 --> 00:57:36,760
It creates runaway consumption and licensing waste.

1521
00:57:36,760 --> 00:57:38,520
It creates forgotten instances,

1522
00:57:38,520 --> 00:57:41,480
quietly consuming resources that nobody is tracking.

1523
00:57:41,480 --> 00:57:43,480
Preventing that sprawl from the start is cheaper

1524
00:57:43,480 --> 00:57:44,680
than untangling it later.

1525
00:57:44,680 --> 00:57:47,160
Put together, none of this reads as a security story anymore.

1526
00:57:47,160 --> 00:57:49,560
It's a competitive one, the gap between organizations

1527
00:57:49,560 --> 00:57:51,640
who built this early and those who didn't.

1528
00:57:51,640 --> 00:57:54,200
Will be visible within a few years, not decades.

1529
00:57:54,200 --> 00:57:55,720
The roadmap and what's coming.

1530
00:57:55,720 --> 00:57:57,160
Agent ID is evolving.

1531
00:57:57,160 --> 00:57:59,400
And it's worth being clear-eyed about what's ahead

1532
00:57:59,400 --> 00:58:00,760
versus what's already locked in.

1533
00:58:00,760 --> 00:58:02,760
Because treating a moving target as if it's finished

1534
00:58:02,760 --> 00:58:04,280
is its own kind of mistake.

1535
00:58:04,280 --> 00:58:07,880
Agent conditional access service plans are set for a July or August

1536
00:58:07,880 --> 00:58:09,480
2026 rollout.

1537
00:58:09,480 --> 00:58:11,880
This brings full licensing alignment to something

1538
00:58:11,880 --> 00:58:13,800
that is currently in a provisional state.

1539
00:58:13,800 --> 00:58:15,880
What you're building today under preview conditions

1540
00:58:15,880 --> 00:58:17,800
will need revisiting once that lands.

1541
00:58:17,800 --> 00:58:19,480
Not because the architecture changes,

1542
00:58:19,480 --> 00:58:21,720
but because the licensing scaffolding finally catches up

1543
00:58:21,720 --> 00:58:22,840
to the capability.

1544
00:58:22,840 --> 00:58:25,480
Identity protection for agents follows a similar arc.

1545
00:58:25,480 --> 00:58:27,480
The risk detection and behavioral baselines

1546
00:58:27,480 --> 00:58:29,000
we walked through earlier are heading

1547
00:58:29,000 --> 00:58:30,680
toward general availability.

1548
00:58:30,680 --> 00:58:32,200
This means more automated response

1549
00:58:32,200 --> 00:58:33,640
and less manual intervention.

1550
00:58:33,640 --> 00:58:35,080
The detection logic matures.

1551
00:58:35,080 --> 00:58:37,160
The action it triggers becomes less dependent

1552
00:58:37,160 --> 00:58:38,520
on a human sitting in the loop.

1553
00:58:38,520 --> 00:58:40,600
The agent user extension is also moving from

1554
00:58:40,600 --> 00:58:42,200
frontier preview toward production.

1555
00:58:42,200 --> 00:58:44,600
This includes mailboxes, teams presence,

1556
00:58:44,600 --> 00:58:46,120
and org chart visibility.

1557
00:58:46,120 --> 00:58:47,640
That is a meaningful shift.

1558
00:58:47,640 --> 00:58:49,960
It changes which agents are viable candidates

1559
00:58:49,960 --> 00:58:51,320
for that kind of integration.

1560
00:58:51,320 --> 00:58:53,080
Right now, you're testing it cautiously.

1561
00:58:53,080 --> 00:58:55,720
Once it hits GA, it becomes a real deployment decision

1562
00:58:55,720 --> 00:58:58,680
for any agent that needs to sit in collaborative spaces.

1563
00:58:58,680 --> 00:59:00,840
There is also a potential shift worth naming,

1564
00:59:00,840 --> 00:59:03,960
even though it isn't confirmed, per agent licensing.

1565
00:59:03,960 --> 00:59:05,560
Everything we've described up to now

1566
00:59:05,560 --> 00:59:07,480
licenses the human's governing agents,

1567
00:59:07,480 --> 00:59:08,600
not the agents themselves.

1568
00:59:08,600 --> 00:59:11,000
That could change for fully autonomous agents specifically.

1569
00:59:11,000 --> 00:59:12,840
Agents operating without a human directly

1570
00:59:12,840 --> 00:59:14,280
in the loop on a regular basis.

1571
00:59:14,280 --> 00:59:15,800
Nothing here is locked in yet,

1572
00:59:15,800 --> 00:59:17,240
but it's a signal worth watching

1573
00:59:17,240 --> 00:59:19,960
because it would change how organizations budget for scale.

1574
00:59:19,960 --> 00:59:22,360
Runtime authorization integration is where the architecture

1575
00:59:22,360 --> 00:59:23,320
keeps deepening.

1576
00:59:23,320 --> 00:59:24,760
We've been clear that conditional access

1577
00:59:24,760 --> 00:59:26,360
evaluates the token request.

1578
00:59:26,360 --> 00:59:29,160
Not every downstream action an agent takes afterward.

1579
00:59:29,160 --> 00:59:30,280
That gap is closing.

1580
00:59:30,280 --> 00:59:32,200
We are seeing deeper hooks into policy engines

1581
00:59:32,200 --> 00:59:33,400
and finer controls

1582
00:59:33,400 --> 00:59:34,920
that reach further into what happens

1583
00:59:34,920 --> 00:59:36,600
after the token has been issued.

1584
00:59:36,600 --> 00:59:39,000
Cross-cloud federation extends the model outward.

1585
00:59:39,000 --> 00:59:41,320
It moves beyond the Microsoft ecosystem entirely.

1586
00:59:41,320 --> 00:59:43,320
The concepts we've spent this episode on,

1587
00:59:43,320 --> 00:59:44,520
blueprints, sponsors,

1588
00:59:44,520 --> 00:59:46,280
and credentialless identity

1589
00:59:46,280 --> 00:59:47,880
aren't necessarily staying confined

1590
00:59:47,880 --> 00:59:49,480
to one vendor's infrastructure.

1591
00:59:49,480 --> 00:59:51,160
That's a bigger shift than it sounds.

1592
00:59:51,160 --> 00:59:54,120
It suggests agent ID isn't just a Microsoft feature.

1593
00:59:54,120 --> 00:59:56,200
It's becoming a patent other platforms will meet

1594
00:59:56,200 --> 00:59:57,640
to reckon with all of this points

1595
00:59:57,640 --> 00:59:59,960
toward a single baseline by 2027.

1596
00:59:59,960 --> 01:00:02,120
Agent governance stops being a differentiator.

1597
01:00:02,120 --> 01:00:03,560
It becomes table stakes.

1598
01:00:03,560 --> 01:00:06,360
It won't be something advanced organizations do to stand out.

1599
01:00:06,360 --> 01:00:09,400
It will be something every organization running AI at scale

1600
01:00:09,400 --> 01:00:10,920
is simply expected to have.

1601
01:00:10,920 --> 01:00:12,760
It's the same way multi-factor authentication

1602
01:00:12,760 --> 01:00:15,560
went from a selling point to an assumed default.

1603
01:00:15,560 --> 01:00:18,040
None of this changes what we've spent this episode building

1604
01:00:18,040 --> 01:00:18,760
toward.

1605
01:00:18,760 --> 01:00:20,200
It just sharpens the timeline.

1606
01:00:20,200 --> 01:00:22,760
What's optional today becomes mandatory tomorrow.

1607
01:00:22,760 --> 01:00:25,240
The organizations already operating with sponsors

1608
01:00:25,240 --> 01:00:26,600
and full observability

1609
01:00:26,600 --> 01:00:29,080
won't need to scramble when that mandatory line arrives.

1610
01:00:29,080 --> 01:00:31,400
They'll already be standing on the other side of it.

1611
01:00:31,400 --> 01:00:33,320
The mistakes organizations will make.

1612
01:00:33,320 --> 01:00:35,320
Most organizations will get this wrong.

1613
01:00:35,320 --> 01:00:37,240
The failures won't be exotic or surprising.

1614
01:00:37,240 --> 01:00:38,280
They are predictable.

1615
01:00:38,280 --> 01:00:41,080
We see them repeated by teams that have all the right information

1616
01:00:41,080 --> 01:00:43,240
but still trip over the same handful of errors.

1617
01:00:43,240 --> 01:00:46,280
The first mistake is treating agent ID like a feature you just enable.

1618
01:00:46,280 --> 01:00:47,560
It isn't a toggle in a menu.

1619
01:00:47,560 --> 01:00:50,120
It is a governance architecture you have to adopt.

1620
01:00:50,120 --> 01:00:52,440
What usually happens is IT teams flip the switch

1621
01:00:52,440 --> 01:00:53,800
and register a few agents.

1622
01:00:53,800 --> 01:00:55,000
They think the job is done.

1623
01:00:55,000 --> 01:00:57,800
But they never build the sponsor model or the blueprint standards.

1624
01:00:57,800 --> 01:00:59,880
They skip the review cycles that actually make

1625
01:00:59,880 --> 01:01:03,240
this identity type useful without governance wrapped around it.

1626
01:01:03,240 --> 01:01:05,640
An agent ID is just a fancier service principle.

1627
01:01:05,640 --> 01:01:08,040
The second mistake is failing to assign sponsors.

1628
01:01:08,040 --> 01:01:10,200
This recreates the exact problem we started with.

1629
01:01:10,200 --> 01:01:12,840
If an agent doesn't have a named human accountable for it,

1630
01:01:12,840 --> 01:01:13,560
it's an orphan.

1631
01:01:13,560 --> 01:01:16,440
It doesn't matter how sophisticated the underlying architecture is.

1632
01:01:16,440 --> 01:01:17,800
The label on the account changes

1633
01:01:17,800 --> 01:01:20,680
but the risk of abandonment stays exactly the same.

1634
01:01:20,680 --> 01:01:22,280
Then there is overprivileging agents.

1635
01:01:22,280 --> 01:01:24,360
This usually happens because of convenience.

1636
01:01:24,360 --> 01:01:26,920
Scoping permissions precisely takes a lot of work.

1637
01:01:26,920 --> 01:01:29,240
Teams under a deadline grant broad access instead.

1638
01:01:29,240 --> 01:01:31,880
They tell themselves they will narrow those permissions later.

1639
01:01:31,880 --> 01:01:33,080
But later rarely comes.

1640
01:01:33,080 --> 01:01:36,600
You end up with agents holding power far beyond what they actually need to function.

1641
01:01:36,600 --> 01:01:40,600
This is the exact pattern that made service principles dangerous in the first place.

1642
01:01:40,600 --> 01:01:42,840
Ignoring the registry is a quieter mistake.

1643
01:01:42,840 --> 01:01:44,600
But it undermines everything else you do.

1644
01:01:44,600 --> 01:01:47,000
When an agent is built outside the discovery system,

1645
01:01:47,000 --> 01:01:48,520
it doesn't show up during an audit.

1646
01:01:48,520 --> 01:01:50,520
It doesn't participate in the sponsor model.

1647
01:01:50,520 --> 01:01:52,600
It doesn't get caught by conditional access policies.

1648
01:01:52,600 --> 01:01:55,160
It is invisible by a mission in a live environment.

1649
01:01:55,160 --> 01:01:57,640
That is the same thing as being invisible by design.

1650
01:01:57,640 --> 01:02:00,360
Skipping conditional access is its own category of error.

1651
01:02:00,360 --> 01:02:03,320
Some organizations set up their roles carefully and stop there.

1652
01:02:03,320 --> 01:02:05,160
They assume role-based controls are enough.

1653
01:02:05,160 --> 01:02:05,720
They aren't.

1654
01:02:05,720 --> 01:02:07,160
Without context-based enforcement,

1655
01:02:07,160 --> 01:02:10,120
an agent can have the right permissions but act at the wrong time.

1656
01:02:10,120 --> 01:02:12,040
It might trigger from the wrong location

1657
01:02:12,040 --> 01:02:14,120
or under conditions that should have been blocked.

1658
01:02:14,120 --> 01:02:18,040
A subtler trap is assuming agent risk works like user risk.

1659
01:02:18,040 --> 01:02:19,880
We talked about this distinction earlier.

1660
01:02:19,880 --> 01:02:22,040
An agent touching 500 documents in 10 minutes

1661
01:02:22,040 --> 01:02:23,400
isn't necessarily a threat.

1662
01:02:23,400 --> 01:02:25,640
It might be doing exactly what you programmed it to do.

1663
01:02:25,640 --> 01:02:28,680
Teams that use their user risk intuition here

1664
01:02:28,680 --> 01:02:31,240
end up drowning in false positives or worse.

1665
01:02:31,240 --> 01:02:32,920
They tune the detection so loosely

1666
01:02:32,920 --> 01:02:34,520
that real attacks slip through.

1667
01:02:34,520 --> 01:02:38,040
The most expensive mistake is delaying implementation.

1668
01:02:38,040 --> 01:02:41,720
Organizations wait until an auditor asks an uncomfortable question

1669
01:02:41,720 --> 01:02:43,320
instead of building the answer now.

1670
01:02:43,320 --> 01:02:45,320
You can fix the other mistakes incrementally

1671
01:02:45,320 --> 01:02:47,000
but waiting for external pressure means

1672
01:02:47,000 --> 01:02:48,840
building under a deadline you didn't choose.

1673
01:02:48,840 --> 01:02:50,680
You'll be dealing with visibility gaps

1674
01:02:50,680 --> 01:02:52,840
that have been growing for months or years.

1675
01:02:52,840 --> 01:02:54,200
The cost here isn't abstract.

1676
01:02:54,200 --> 01:02:55,880
It's compliance violations.

1677
01:02:55,880 --> 01:02:58,680
It's data breaches that nobody can trace back to a person.

1678
01:02:58,680 --> 01:03:00,760
It's a slow loss of trust in AI systems

1679
01:03:00,760 --> 01:03:02,200
that were supposed to be assets.

1680
01:03:02,200 --> 01:03:03,800
You don't need a sophisticated attacker

1681
01:03:03,800 --> 01:03:04,840
to reach these outcomes.

1682
01:03:04,840 --> 01:03:06,840
You just need these ordinary shortcuts

1683
01:03:06,840 --> 01:03:09,000
left alone long enough to compound.

1684
01:03:09,000 --> 01:03:10,840
The structural shift in summary.

1685
01:03:10,840 --> 01:03:12,360
So what is actually changing?

1686
01:03:12,360 --> 01:03:15,160
You are moving from shadow IT to governed digital workers.

1687
01:03:15,160 --> 01:03:17,320
Agents now hold first class identities

1688
01:03:17,320 --> 01:03:18,840
instead of borrowed permissions.

1689
01:03:18,840 --> 01:03:20,520
You are moving from credential sprawl

1690
01:03:20,520 --> 01:03:21,960
to centralized blueprints.

1691
01:03:21,960 --> 01:03:24,440
Security is architected in, not bolted on at the end.

1692
01:03:24,440 --> 01:03:26,200
You are moving from orphaned accounts

1693
01:03:26,200 --> 01:03:28,040
to sponsored responsibility.

1694
01:03:28,040 --> 01:03:29,880
Every agent answers to a named human.

1695
01:03:29,880 --> 01:03:33,080
You are moving from static roles to dynamic governance.

1696
01:03:33,080 --> 01:03:35,560
Life cycle policies and reviews now run continuously.

1697
01:03:35,560 --> 01:03:38,120
You are moving from blind spots to observable systems.

1698
01:03:38,120 --> 01:03:39,560
Every action is traceable.

1699
01:03:39,560 --> 01:03:42,280
You are moving from compliance risk to compliance readiness.

1700
01:03:42,280 --> 01:03:44,840
This is built by architecture, not by policy documents.

1701
01:03:44,840 --> 01:03:46,520
This isn't an incremental change.

1702
01:03:46,520 --> 01:03:47,720
It's a structural one.

1703
01:03:47,720 --> 01:03:49,880
The window to govern agents is closing.

1704
01:03:49,880 --> 01:03:52,040
Organizations that wait will inherit chaos.

1705
01:03:52,040 --> 01:03:54,680
Agent 365 and agent ID aren't optional anymore.

1706
01:03:54,680 --> 01:03:57,800
Start now, inventory your agents, assign sponsors,

1707
01:03:57,800 --> 01:03:59,480
build blueprints.

1708
01:03:59,480 --> 01:04:01,880
If this changed how you think about agent governance,

1709
01:04:01,880 --> 01:04:03,880
follow me, Mirko Peters, on LinkedIn.

1710
01:04:03,880 --> 01:04:06,680
And if you want more of this, subscribe to the podcast.