This episode explains why attempts to integrate AI into enterprise systems fail not because of model intelligence, but because of unbounded action and brittle integrations. The core claim is that the Model Context Protocol (MCP) is not a plugin system, API wrapper, or merely “standardized function calling”—those descriptions miss the point and lead teams back into the same brittle “AI glue” patterns they want to escape.

Custom AI glue—ad hoc connectors, bespoke wrappers, temporary service principals, and middleware—felt reasonable in small projects but, when combined across teams, creates tool sprawl, permission creep, policy drift, and inconsistent logging. These failures are especially dangerous for agentic systems because models fill in gaps confidently. MCP inserts a protocol-level choke point where identity, scope, auditability, and failure behavior can be enforced without trusting the model to behave deterministically.

Unlike plugins or function calling conventions that treat integration as developer ergonomics, MCP is an integration security boundary. It standardizes how capabilities are described, discovered, and invoked and defines where control stops. In Microsoft-native environments, MCP aligns with identity-first controls like Entra, Conditional Access, and centralized audit logging, making it a natural fit to enforce governance at scale. MCP doesn’t remove complexity — it makes AI integration governable.

As enterprises rush to integrate AI into real systems, a familiar pattern is repeating itself: custom wrappers, bespoke connectors, temporary permissions, and “just for now” glue code holding everything together. These integrations often look harmless at first, but at scale they become brittle, opaque, and dangerous—especially when combined with agentic AI systems that act probabilistically rather than deterministically.

This episode makes the case that the Model Context Protocol (MCP) marks the end of custom AI glue. Not because MCP is more convenient, but because it introduces something enterprises have been missing: a protocol-level authority boundary for AI actions.

Rather than treating AI integration as a developer productivity problem, MCP reframes it as a governance and control problem. The discussion explains why plugins, function calling, and agent frameworks all fall short, and why protocols—not abstractions—are what actually scale in enterprise environments.


The Real Problem: Unbounded AI Action

AI does not “call APIs” in the traditional sense.
It predicts tokens, selects tool names, and fills in parameters based on probability.

Without strict boundaries, this leads to:

  • Over-permissive integrations

  • Hidden assumptions baked into glue code

  • Inconsistent logging and audit trails

  • Silent policy violations

  • Escalating blast radius as agents gain autonomy

Custom AI glue asks the model to behave responsibly inside systems that were never designed for probabilistic callers.

That is not an intelligence problem.
It is an architecture problem.


What People Get Wrong About MCP

Most discussions describe MCP as:

  • A plugin standard

  • A better function calling mechanism

  • An API abstraction layer

  • A convenience feature for agents

All of these descriptions miss the point.

MCP is not about making integrations easier to write.
It is about making AI action governable.

Protocols historically exist to define where responsibility stops:

  • HTTP does not define business logic—it defines interaction boundaries

  • OAuth does not make applications smarter—it constrains authority

MCP plays the same role for AI systems.


Custom AI Glue as an Entropy Generator

Custom glue code feels flexible, but it compounds risk over time.

Typical failure patterns include:

  • One-off wrappers built by different teams

  • Slightly different permission models per integration

  • Undocumented assumptions about identity and scope

  • Inconsistent error handling and retry behavior

  • No shared understanding of what an agent is allowed to do

Each integration works locally.
Collectively, they create organizational blind spots.

When something goes wrong, teams can’t answer:

  • Who approved this action?

  • Which system was authoritative?

  • What policy applied at runtime?

  • Why did the agent choose this path?

  • Where is the evidence?


Why Agent Frameworks Don’t Solve This

Agent frameworks often promise “autonomy,” but autonomy without constraints is just delegated chaos.

Frameworks tend to:

  • Hide integration logic behind abstractions

  • Encourage broad, reusable permissions

  • Optimize for flexibility over control

  • Treat failure handling as an afterthought

They move complexity, but do not reduce it.

MCP does not try to make agents smarter.
It makes their possible actions smaller and clearer.


MCP as a Protocol-Level Boundary

MCP defines a strict contract between:

  • The model, which proposes actions

  • The host, which enforces what is allowed

  • The tools, which expose explicit, bounded capabilities

This separation is critical.

The model can suggest.
The protocol decides.
The system executes—or refuses.

That distinction is what turns AI from a risk amplifier into a controllable component.


Why Protocols Win Where Abstractions Fail

Enterprise history is clear:

  • Protocols scale across teams and time

  • Abstractions decay under organizational churn

Abstractions assume shared context.
Protocols assume none.

MCP works because it:

  • Makes capabilities explicit

  • Makes constraints machine-enforceable

  • Makes discovery predictable

  • Makes failure behavior visible

That is exactly what agentic systems need.


MCP and Enterprise Control Planes

In identity-first environments—especially Microsoft-centric ones—control planes already exist:

  • Identity defines who can act

  • Policy defines when they can act

  • Audit defines what actually happened

MCP aligns naturally with this model by ensuring that AI integrations respect the same boundaries humans do.

Instead of inventing new trust models for AI, MCP allows organizations to reuse existing governance structures.


Why This Matters Now

As AI moves from “assistive” to “agentic,” the cost of mistakes rises sharply.

Reading data is forgiving.
Writing data is not.

Every AI-driven write operation:

  • Changes system state

  • Affects downstream processes

  • Creates compliance exposure

MCP creates a hard stop between intent and execution—exactly where enterprises need it.


Key Architectural Takeaways

  • Custom AI glue does not scale—it accumulates hidden risk

  • MCP is not about convenience, but about authority

  • Agent autonomy must be bounded by protocol, not convention

  • Governance must be enforced structurally, not socially

  • Protocols succeed because they define where responsibility ends


Who Should Care About This Episode

This episode is especially relevant for:

  • Enterprise architects

  • Security and identity leaders

  • Platform engineers

  • AI governance and risk teams

  • Organizations building internal AI agents

  • Microsoft-centric enterprises planning agent adoption


Final Thought

Every generation of distributed systems eventually learns the same lesson:
Without protocols, power leaks everywhere.

MCP is not exciting because it adds features.
It is important because it draws a line.

And for AI in the enterprise, drawing that line is the difference between experimentation and control.

Transcript

1
00:00:00,000 --> 00:00:01,920
Why is everyone suddenly talking about MCP

2
00:00:01,920 --> 00:00:03,620
and why should Microsoft people care?

3
00:00:03,620 --> 00:00:07,280
Because the AI integration story you've been selling internally

4
00:00:07,280 --> 00:00:09,120
is collapsing under its own weight.

5
00:00:09,120 --> 00:00:10,940
Models can write decent plans.

6
00:00:10,940 --> 00:00:12,900
They can even sound confident while doing it,

7
00:00:12,900 --> 00:00:14,560
but enterprises don't pay for confidence.

8
00:00:14,560 --> 00:00:16,080
They pay for controlled outcomes.

9
00:00:16,080 --> 00:00:17,520
Here's the comfortable assumption.

10
00:00:17,520 --> 00:00:19,860
MCP is plugins for LLMs.

11
00:00:19,860 --> 00:00:21,480
A nicer way to bolt tools onto chat.

12
00:00:21,480 --> 00:00:23,240
That's the story because it feels familiar.

13
00:00:23,240 --> 00:00:25,880
It sounds like what we already did with add-ins, connectors,

14
00:00:25,880 --> 00:00:27,160
and yet another SDK.

15
00:00:27,160 --> 00:00:27,960
It is not.

16
00:00:27,960 --> 00:00:29,040
MCP is not a plugin system.

17
00:00:29,040 --> 00:00:30,200
It's not an API wrapper.

18
00:00:30,200 --> 00:00:32,520
It's not function-calling, but standardized.

19
00:00:32,520 --> 00:00:34,080
Those descriptions are how you end up

20
00:00:34,080 --> 00:00:37,080
rebuilding the same glue code just with a new logo on it.

21
00:00:37,080 --> 00:00:38,360
This is the uncomfortable truth.

22
00:00:38,360 --> 00:00:40,160
MCP is where authority stops.

23
00:00:40,160 --> 00:00:42,320
In architectural terms, MCP is a protocol

24
00:00:42,320 --> 00:00:44,440
that sits between an AI host and the systems

25
00:00:44,440 --> 00:00:45,680
you actually care about.

26
00:00:45,680 --> 00:00:48,680
Graph, SharePoint, Line of Business APIs,

27
00:00:48,680 --> 00:00:50,160
anything with Blastradius.

28
00:00:50,160 --> 00:00:52,360
And the point of that protocol isn't convenience.

29
00:00:52,360 --> 00:00:54,040
The point is to create a choke point

30
00:00:54,040 --> 00:00:57,400
where you can enforce identity, scope, audit, and failure

31
00:00:57,400 --> 00:01:00,120
behavior without trusting the model to behave,

32
00:01:00,120 --> 00:01:02,640
because the model will not behave, not because it's evil,

33
00:01:02,640 --> 00:01:03,720
because it's probabilistic.

34
00:01:03,720 --> 00:01:05,560
It picks the next token, then the next token,

35
00:01:05,560 --> 00:01:07,760
and somewhere inside that it decides which tool to call

36
00:01:07,760 --> 00:01:08,640
and with what inputs.

37
00:01:08,640 --> 00:01:11,040
That's fine when the worst outcome is a wrong sentence.

38
00:01:11,040 --> 00:01:14,640
It's catastrophic when the outcome is create a user,

39
00:01:14,640 --> 00:01:19,200
share a file, delete a record, or ex-filterate a report.

40
00:01:19,200 --> 00:01:22,680
So the real problem MCP solves isn't model intelligence.

41
00:01:22,680 --> 00:01:24,760
It's bounded action at enterprise scale.

42
00:01:24,760 --> 00:01:27,600
Before MCP, every team built their own bridge.

43
00:01:27,600 --> 00:01:30,320
A bespoke wrapper around graph, a custom connector

44
00:01:30,320 --> 00:01:32,800
to SharePoint, a hand-rolled middleware service

45
00:01:32,800 --> 00:01:34,880
with a service principle that never gets rotated

46
00:01:34,880 --> 00:01:36,560
because it's temporary.

47
00:01:36,560 --> 00:01:39,080
Meanwhile, policy drift happens, endpoints change,

48
00:01:39,080 --> 00:01:41,720
someone adds a permission just for this sprint.

49
00:01:41,720 --> 00:01:43,840
And now your integration becomes a permanent incident

50
00:01:43,840 --> 00:01:44,840
generator.

51
00:01:44,840 --> 00:01:46,600
And Microsoft environments amplify this

52
00:01:46,600 --> 00:01:48,320
because identity is the control plane.

53
00:01:48,320 --> 00:01:49,760
Entra decides what is possible.

54
00:01:49,760 --> 00:01:52,160
Conditional access decides what is survivable.

55
00:01:52,160 --> 00:01:54,880
Or did decides what is defensible when something goes wrong.

56
00:01:54,880 --> 00:01:57,720
So in this episode, the goal isn't to celebrate MCP.

57
00:01:57,720 --> 00:01:58,960
The goal is to make it obvious.

58
00:01:58,960 --> 00:02:01,400
We're going to build MCP from first principles,

59
00:02:01,400 --> 00:02:04,240
then place it inside a Microsoft native architecture.

60
00:02:04,240 --> 00:02:06,440
Entra on behalf of for delegated authority,

61
00:02:06,440 --> 00:02:08,920
managed identity for operational baselines,

62
00:02:08,920 --> 00:02:12,000
and service principle plus Azure API management

63
00:02:12,000 --> 00:02:14,880
for the part everyone forgets, governance at the edge.

64
00:02:14,880 --> 00:02:16,840
And there's one claim I'm going to prove later

65
00:02:16,840 --> 00:02:18,200
with real entrufflose.

66
00:02:18,200 --> 00:02:20,000
MCP isn't AI tooling.

67
00:02:20,000 --> 00:02:22,080
It's an integration security boundary

68
00:02:22,080 --> 00:02:24,960
masquerading as developer ergonomics.

69
00:02:24,960 --> 00:02:28,760
The foundational misunderstanding, LLMs don't touch APIs.

70
00:02:28,760 --> 00:02:30,760
Most teams start with the wrong mental model.

71
00:02:30,760 --> 00:02:33,120
They think the LLM is calling graph,

72
00:02:33,120 --> 00:02:35,880
or hitting SharePoint or running an API.

73
00:02:35,880 --> 00:02:38,440
And then they build a security story on top of that assumption.

74
00:02:38,440 --> 00:02:39,480
That assumption is false.

75
00:02:39,480 --> 00:02:41,240
The model never touches your API.

76
00:02:41,240 --> 00:02:44,760
It never sees your open API spec in the way a developer does.

77
00:02:44,760 --> 00:02:47,680
It never understands your error codes, your pagination rules,

78
00:02:47,680 --> 00:02:50,680
or your permissions model the way your integration code does.

79
00:02:50,680 --> 00:02:52,200
The model interacts with one thing,

80
00:02:52,200 --> 00:02:54,080
the text and structured tool descriptions

81
00:02:54,080 --> 00:02:55,720
you choose to put in front of it.

82
00:02:55,720 --> 00:02:58,640
That distinction matters because you are not securing an API call.

83
00:02:58,640 --> 00:03:00,440
You are securing a decision pipeline.

84
00:03:00,440 --> 00:03:02,840
Okay, so basically an agentic loop looks like this.

85
00:03:02,840 --> 00:03:06,000
You give the model a prompt plus a list of available tools.

86
00:03:06,000 --> 00:03:07,080
The model chooses a tool.

87
00:03:07,080 --> 00:03:09,120
Some host process executes the tool.

88
00:03:09,120 --> 00:03:11,560
The results come back, the model sees the results,

89
00:03:11,560 --> 00:03:13,200
then it decides what to do next.

90
00:03:13,200 --> 00:03:14,680
Repeat until it stops.

91
00:03:14,680 --> 00:03:16,280
Notice what's missing.

92
00:03:16,280 --> 00:03:18,280
There's no direct binding between the user

93
00:03:18,280 --> 00:03:21,200
asked the question and the API call is safe.

94
00:03:21,200 --> 00:03:23,880
The binding is mediated by tool descriptions, schemas,

95
00:03:23,880 --> 00:03:24,800
and host behavior.

96
00:03:24,800 --> 00:03:27,000
That's why I just call the API is not a plan.

97
00:03:27,000 --> 00:03:30,560
It's a shortcut around the part that actually fails in production.

98
00:03:30,560 --> 00:03:31,920
Here's what most people miss.

99
00:03:31,920 --> 00:03:34,680
In an enterprise, tool calling is not a coding problem.

100
00:03:34,680 --> 00:03:36,120
It's a context shaping problem.

101
00:03:36,120 --> 00:03:38,840
If the tool schema is vague, the model will fill in gaps.

102
00:03:38,840 --> 00:03:41,160
If the tool names overlap, the model will guess.

103
00:03:41,160 --> 00:03:43,560
If you allow optional parameters that change meaning,

104
00:03:43,560 --> 00:03:44,600
the model will improvise.

105
00:03:44,600 --> 00:03:47,360
If your output isn't stable, the model will learn the wrong patterns.

106
00:03:47,360 --> 00:03:49,720
And if you fix it later, you've already

107
00:03:49,720 --> 00:03:53,440
shipped a probabilistic interface into a deterministic environment.

108
00:03:53,440 --> 00:03:57,000
That's the collision APIs assume deterministic callers.

109
00:03:57,000 --> 00:03:58,880
LLMs are probabilistic callers.

110
00:03:58,880 --> 00:04:01,920
So the real failure mode isn't that the model can't do the task.

111
00:04:01,920 --> 00:04:04,600
The failure mode is ambiguity, ambiguity in naming,

112
00:04:04,600 --> 00:04:07,200
ambiguity in inputs, ambiguity in outputs,

113
00:04:07,200 --> 00:04:10,760
ambiguity in what authority is being exercised when the tool runs.

114
00:04:10,760 --> 00:04:13,760
And it gets worse over time because the tool surface drifts.

115
00:04:13,760 --> 00:04:15,240
Someone adds a new parameter.

116
00:04:15,240 --> 00:04:18,280
Another team wraps the same back end with a slightly different tool.

117
00:04:18,280 --> 00:04:21,280
A third team adds a search tool that returns a different shape.

118
00:04:21,280 --> 00:04:23,600
Now, the model isn't choosing between one correct action

119
00:04:23,600 --> 00:04:24,680
and one incorrect action.

120
00:04:24,680 --> 00:04:27,320
It's choosing between three nearly correct actions

121
00:04:27,320 --> 00:04:28,520
that all work sometimes.

122
00:04:28,520 --> 00:04:29,360
Congratulations.

123
00:04:29,360 --> 00:04:30,760
You've built conditional chaos.

124
00:04:30,760 --> 00:04:34,120
This is also why prompt injection becomes a real operational concern.

125
00:04:34,120 --> 00:04:35,840
The model is not defending your API.

126
00:04:35,840 --> 00:04:36,600
The host is.

127
00:04:36,600 --> 00:04:39,920
The host decides what tools are available, what schemas are valid,

128
00:04:39,920 --> 00:04:43,280
what tokens are presented, and what failures are allowed to proceed.

129
00:04:43,280 --> 00:04:47,720
If your system lets untrusted content influence tool selection or tool inputs,

130
00:04:47,720 --> 00:04:49,840
it doesn't matter how secure your API is.

131
00:04:49,840 --> 00:04:51,720
You just move the attack surface upstream.

132
00:04:51,720 --> 00:04:53,400
The attacker isn't bypassing auth.

133
00:04:53,400 --> 00:04:54,560
They're steering the caller.

134
00:04:54,560 --> 00:04:57,760
So when someone says, we'll just give Copilot a service principle

135
00:04:57,760 --> 00:04:59,240
and let it call graph.

136
00:04:59,240 --> 00:05:01,920
What they're really doing is bypassing the only place

137
00:05:01,920 --> 00:05:05,960
where policy can be enforced consistently, the orchestration boundary.

138
00:05:05,960 --> 00:05:08,760
That boundary is what MCP standardizes, not the intelligence,

139
00:05:08,760 --> 00:05:10,120
the plumbing around authority.

140
00:05:10,120 --> 00:05:15,600
And once you see that MCP stops sounding like plugins, it starts sounding like what it actually is.

141
00:05:15,600 --> 00:05:20,200
A way to describe capabilities precisely, invoke them consistently,

142
00:05:20,200 --> 00:05:24,800
and keep the model on the far side of a control plane you can audit and constrain.

143
00:05:24,800 --> 00:05:27,880
And now we can talk about the real cost of doing it the old way.

144
00:05:27,880 --> 00:05:31,480
Because every bespoke bridge you build becomes an entropy generator.

145
00:05:31,480 --> 00:05:35,440
The entropy tax, custom AI glue as a permanent incident generator.

146
00:05:35,440 --> 00:05:37,160
Here's the part nobody budgets for.

147
00:05:37,160 --> 00:05:39,240
Once you let AI glue into the enterprise,

148
00:05:39,240 --> 00:05:40,880
you're not building an integration.

149
00:05:40,880 --> 00:05:44,640
You're adopting a new kind of maintenance burden, one that grows on its own.

150
00:05:44,640 --> 00:05:47,760
Because glue code doesn't stay glue, it becomes policy.

151
00:05:47,760 --> 00:05:49,720
It starts innocently.

152
00:05:49,720 --> 00:05:54,080
A team wants Copilot, sorry, an agent to read a SharePoint library,

153
00:05:54,080 --> 00:05:57,400
summarise a document set and maybe create a planner task.

154
00:05:57,400 --> 00:05:59,440
So someone writes a thin wrapper around graph.

155
00:05:59,440 --> 00:06:00,760
They add a service principle.

156
00:06:00,760 --> 00:06:02,160
They store the secret in Key Vault.

157
00:06:02,160 --> 00:06:04,920
They ship everyone claps and then reality shows up.

158
00:06:04,920 --> 00:06:06,960
The first failure mode is toolsprull.

159
00:06:06,960 --> 00:06:10,880
Multiple teams will build the same bridge in parallel because there's no shared contract layer.

160
00:06:10,880 --> 00:06:12,440
One wrapper calls graph search.

161
00:06:12,440 --> 00:06:14,480
Another wrapper calls SharePoint rest.

162
00:06:14,480 --> 00:06:18,560
A third wrapper scrapes results from the graph drive endpoint because it was faster.

163
00:06:18,560 --> 00:06:20,080
Now you don't have one integration.

164
00:06:20,080 --> 00:06:23,280
You have three inconsistent interpretations of the same system,

165
00:06:23,280 --> 00:06:25,840
each with its own permissions, error handling and logging.

166
00:06:25,840 --> 00:06:28,880
That's not innovation, that's fragmentation.

167
00:06:28,880 --> 00:06:31,520
The second failure mode is humans acting as transport.

168
00:06:31,520 --> 00:06:36,640
If you've ever watched someone use Copilot by copy-pasting an email thread into a prompt,

169
00:06:36,640 --> 00:06:38,640
then copy-pasting a response into teams.

170
00:06:38,640 --> 00:06:40,040
You've seen the architecture.

171
00:06:40,040 --> 00:06:42,080
It's manual ETL with vibes.

172
00:06:42,080 --> 00:06:45,680
It works right up until it becomes a process and then it becomes an audit problem.

173
00:06:45,680 --> 00:06:47,520
You can't prove what data was used.

174
00:06:47,520 --> 00:06:49,080
You can't prove what the model saw.

175
00:06:49,080 --> 00:06:52,920
You can't prove what was sent out and you definitely can't prove the user had authority

176
00:06:52,920 --> 00:06:54,920
to move that data in the first place.

177
00:06:54,920 --> 00:06:58,440
The third failure mode is security debt that masquerades as velocity.

178
00:06:58,440 --> 00:07:00,120
This is where entropy becomes measurable.

179
00:07:00,120 --> 00:07:01,800
You add temporary app permissions.

180
00:07:01,800 --> 00:07:03,120
You grant sites.

181
00:07:03,120 --> 00:07:05,040
Read all because scoping is annoying.

182
00:07:05,040 --> 00:07:08,240
You add "mail" don't read to help with summarisation.

183
00:07:08,240 --> 00:07:11,880
You keep a long-lived credential because rotating it breaks the tool.

184
00:07:11,880 --> 00:07:13,360
Over time exceptions pile up.

185
00:07:13,360 --> 00:07:15,240
These exceptions are not edge cases.

186
00:07:15,240 --> 00:07:17,800
They are entropy generators.

187
00:07:17,800 --> 00:07:21,160
Because every exception weakens your ability to reason about the system.

188
00:07:21,160 --> 00:07:25,000
You no longer know which identities can touch which data, through which parts, under which

189
00:07:25,000 --> 00:07:26,160
conditions.

190
00:07:26,160 --> 00:07:30,120
You have transformed a deterministic security model into a probabilistic one.

191
00:07:30,120 --> 00:07:31,560
The fourth failure mode is drift.

192
00:07:31,560 --> 00:07:32,880
API is change.

193
00:07:32,880 --> 00:07:34,720
Graph endpoints evolve.

194
00:07:34,720 --> 00:07:36,400
Inseman tics shift.

195
00:07:36,400 --> 00:07:38,520
Conditional access policies tighten.

196
00:07:38,520 --> 00:07:42,520
SharePoint inheritance gets fixed by someone who doesn't understand the business impact.

197
00:07:42,520 --> 00:07:44,960
Your glue code is now stale but it doesn't fail loudly.

198
00:07:44,960 --> 00:07:45,960
It fails weirdly.

199
00:07:45,960 --> 00:07:46,960
Partial results.

200
00:07:46,960 --> 00:07:47,960
Empty arrays.

201
00:07:47,960 --> 00:07:48,960
Works for me access.

202
00:07:48,960 --> 00:07:50,760
Tool outputs that look valid but aren't.

203
00:07:50,760 --> 00:07:53,880
And this is the worst kind of failure for an LLM driven loop.

204
00:07:53,880 --> 00:07:56,200
Because the model will treat ambiguity as a suggestion.

205
00:07:56,200 --> 00:07:59,640
If the tool returns a 403, the model might try a different tool.

206
00:07:59,640 --> 00:08:04,160
If the tool returns an empty response, the model might assume no data exists.

207
00:08:04,160 --> 00:08:07,880
If the tool returns a truncated payload, the model will fill the gap.

208
00:08:07,880 --> 00:08:09,640
Not maliciously.

209
00:08:09,640 --> 00:08:10,640
Automatically.

210
00:08:10,640 --> 00:08:14,840
So custom glue becomes a permanent incident generator even when the code is correct because

211
00:08:14,840 --> 00:08:16,920
the environment it depends on is not static.

212
00:08:16,920 --> 00:08:22,080
It's a live policy changes, data changes, identity posture changes, and the more AI capabilities

213
00:08:22,080 --> 00:08:25,120
you bolt on, the more pathways you create for silent failure.

214
00:08:25,120 --> 00:08:28,160
This is why enterprises don't actually struggle with AI reasoning.

215
00:08:28,160 --> 00:08:30,360
They struggle with orchestration entropy.

216
00:08:30,360 --> 00:08:32,360
And the uncomfortable part is this.

217
00:08:32,360 --> 00:08:36,800
Every new team that just needs one tool makes the entropy worse for everyone else.

218
00:08:36,800 --> 00:08:40,320
Because now you have more identities, more secrets, more permissions, more rappers, more

219
00:08:40,320 --> 00:08:44,320
logging formats, more exception handling styles, and more undocumented behavior.

220
00:08:44,320 --> 00:08:46,280
MCP doesn't magically make systems safe.

221
00:08:46,280 --> 00:08:47,800
It gives you a place to stop the spread.

222
00:08:47,800 --> 00:08:49,120
A standard contract boundary.

223
00:08:49,120 --> 00:08:50,920
A predictable capability surface.

224
00:08:50,920 --> 00:08:56,320
A single choke point where identity scope, audit, and rate control can be enforced consistently.

225
00:08:56,320 --> 00:08:58,240
Without that choke point you don't get a platform.

226
00:08:58,240 --> 00:09:02,720
You get a thousand slightly different bridges, all quietly rotting, all still holding production

227
00:09:02,720 --> 00:09:03,720
traffic.

228
00:09:03,720 --> 00:09:05,160
Pre-MCP pattern one.

229
00:09:05,160 --> 00:09:06,920
Rest everywhere, context nowhere.

230
00:09:06,920 --> 00:09:09,560
The first pattern everyone tried was the obvious one.

231
00:09:09,560 --> 00:09:11,800
Just expose rest endpoints and call it a day.

232
00:09:11,800 --> 00:09:12,800
And yes, rest is fine.

233
00:09:12,800 --> 00:09:14,320
It's been fine for 20 years.

234
00:09:14,320 --> 00:09:18,200
It's predictable, cashable, debuggable, and it makes developers feel like they're doing

235
00:09:18,200 --> 00:09:21,400
real engineering instead of arguing about prompt phrasing.

236
00:09:21,400 --> 00:09:23,720
But rest was designed for deterministic clients.

237
00:09:23,720 --> 00:09:25,000
An LLM is not one.

238
00:09:25,000 --> 00:09:29,160
Rest assumes the caller already knows which end point to hit, what parameters mean, what

239
00:09:29,160 --> 00:09:32,240
shape comes back, and what to do when it doesn't.

240
00:09:32,240 --> 00:09:36,160
Rest assumes the caller has a stable mental model of the API surface and enough discipline

241
00:09:36,160 --> 00:09:37,160
to follow it.

242
00:09:37,160 --> 00:09:38,520
The model has none of that discipline.

243
00:09:38,520 --> 00:09:39,720
It has pattern matching.

244
00:09:39,720 --> 00:09:43,320
So what happens in practice is that you don't actually give the model your rest API.

245
00:09:43,320 --> 00:09:45,600
You give it a description of your rest API.

246
00:09:45,600 --> 00:09:50,040
In the prompt, or through tool metadata, or through some internal tool router layer that

247
00:09:50,040 --> 00:09:53,400
translates natural language intent into HTTP calls.

248
00:09:53,400 --> 00:09:57,200
And this is where the ROT starts because the moment you do that, pagination becomes a reasoning

249
00:09:57,200 --> 00:09:58,200
problem.

250
00:09:58,200 --> 00:09:59,960
Error handling becomes a reasoning problem.

251
00:09:59,960 --> 00:10:01,920
Edempotency becomes a reasoning problem.

252
00:10:01,920 --> 00:10:03,520
Filtering becomes a reasoning problem.

253
00:10:03,520 --> 00:10:07,600
And the model is now doing probabilistic inference over details that were never meant to be

254
00:10:07,600 --> 00:10:08,600
inferred.

255
00:10:08,600 --> 00:10:09,600
Here's the weird part.

256
00:10:09,600 --> 00:10:11,760
Even when you have an open API spec, you're still not safe.

257
00:10:11,760 --> 00:10:14,400
Open API is a contract for developers and code generators.

258
00:10:14,400 --> 00:10:18,280
It's great for documenting endpoints, schemers, all schemes, and response types.

259
00:10:18,280 --> 00:10:20,320
But it doesn't solve capability negotiation.

260
00:10:20,320 --> 00:10:24,840
It doesn't solve tool discovery in a multi tool world, and it definitely doesn't solve which

261
00:10:24,840 --> 00:10:28,800
of these five nearly identical endpoints should I call right now.

262
00:10:28,800 --> 00:10:31,440
In other words, open API can describe a surface.

263
00:10:31,440 --> 00:10:33,280
It can't enforce a decision boundary.

264
00:10:33,280 --> 00:10:37,600
So teams build wrappers, one wrapper for graph search, another wrapper for SharePoint lists,

265
00:10:37,600 --> 00:10:40,640
another wrapper for the one endpoint that returns less data.

266
00:10:40,640 --> 00:10:41,880
So it's faster.

267
00:10:41,880 --> 00:10:45,400
Each wrapper has slightly different defaults, slightly different filtering, slightly different

268
00:10:45,400 --> 00:10:47,400
error mapping, slightly different logging.

269
00:10:47,400 --> 00:10:48,560
And now you don't have rest.

270
00:10:48,560 --> 00:10:50,280
You have interpretations of rest.

271
00:10:50,280 --> 00:10:53,520
That distinction matters because interpretations drift independently.

272
00:10:53,520 --> 00:10:56,320
The backend might evolve cleanly, but the wrappers don't.

273
00:10:56,320 --> 00:10:57,320
They get patched.

274
00:10:57,320 --> 00:10:58,320
They get copied.

275
00:10:58,320 --> 00:10:59,520
They get forked.

276
00:10:59,520 --> 00:11:03,760
And over time, your API integration becomes a zoo of nearly correct callers with different

277
00:11:03,760 --> 00:11:04,840
assumptions.

278
00:11:04,840 --> 00:11:06,080
And then the LLM arrives.

279
00:11:06,080 --> 00:11:08,240
Now the model is asked to choose between those wrappers.

280
00:11:08,240 --> 00:11:09,320
It doesn't know your intent.

281
00:11:09,320 --> 00:11:11,120
It doesn't know which wrapper is the blessed one.

282
00:11:11,120 --> 00:11:15,440
It only sees names, descriptions, and whatever examples you happen to include in the context.

283
00:11:15,440 --> 00:11:19,760
So if you have three tools called search, search graph, and search SharePoint, you're

284
00:11:19,760 --> 00:11:24,720
not giving the model capability, you're giving it ambiguity, and ambiguity becomes behavior.

285
00:11:24,720 --> 00:11:28,360
This is also where security starts to degrade in ways that look harmless.

286
00:11:28,360 --> 00:11:32,040
Rest APIs often have broad permissions because developers want flexibility.

287
00:11:32,040 --> 00:11:36,560
But when you expose that same breadth to a model driven caller, you're effectively saying,

288
00:11:36,560 --> 00:11:37,960
here's a loaded interface.

289
00:11:37,960 --> 00:11:39,240
Please choose responsibly.

290
00:11:39,240 --> 00:11:40,400
It won't.

291
00:11:40,400 --> 00:11:45,040
Even worse, rest normalizes the idea that if one call fails, you just try another endpoint.

292
00:11:45,040 --> 00:11:48,600
That's acceptable in code where retries are bounded and logic is explicit.

293
00:11:48,600 --> 00:11:50,560
And an agent loop retries are creative.

294
00:11:50,560 --> 00:11:54,400
The model will attempt different calls, different parameters, different scopes of search, until

295
00:11:54,400 --> 00:11:56,160
it gets something that looks like progress.

296
00:11:56,160 --> 00:11:57,160
That's not resilience.

297
00:11:57,160 --> 00:11:58,600
That's wondering.

298
00:11:58,600 --> 00:12:02,200
So the rest everywhere pattern collapses because it externalizes context management.

299
00:12:02,200 --> 00:12:05,920
You push all the meaning into prompts and tool descriptions, and then you act surprised

300
00:12:05,920 --> 00:12:07,880
when the caller behaves inconsistently.

301
00:12:07,880 --> 00:12:10,680
This is why the industry pivoted to plugins next.

302
00:12:10,680 --> 00:12:14,980
Not because rest was broken, but because rest had no opinion about context, contracts, or

303
00:12:14,980 --> 00:12:16,920
governance at the AI boundary.

304
00:12:16,920 --> 00:12:20,720
Three MCP pattern two, plugins and extensions as vendor gravity.

305
00:12:20,720 --> 00:12:24,680
So after rest failed to give models a stable, governable tool surface, the industry did what

306
00:12:24,680 --> 00:12:25,680
it always does.

307
00:12:25,680 --> 00:12:27,560
It built plugins.

308
00:12:27,560 --> 00:12:31,440
Plugins feel like progress because they move the integration problem into a product shape,

309
00:12:31,440 --> 00:12:35,440
a marketplace, a manifest, an install button, and a permission prompt.

310
00:12:35,440 --> 00:12:37,040
Everyone recognizes that pattern.

311
00:12:37,040 --> 00:12:41,520
Microsoft people especially add ins, connectors, teams apps, power platform connectors, same

312
00:12:41,520 --> 00:12:43,040
movie, new cast.

313
00:12:43,040 --> 00:12:44,760
But here's the foundational mistake.

314
00:12:44,760 --> 00:12:48,160
Because plugin ecosystems don't exist to reduce your integration debt.

315
00:12:48,160 --> 00:12:49,720
They exist to concentrate it.

316
00:12:49,720 --> 00:12:53,760
Vendor gravity is what happens when the platform becomes the default integration runtime.

317
00:12:53,760 --> 00:12:55,240
Your tools aren't yours anymore.

318
00:12:55,240 --> 00:13:00,640
Their artifacts shaped around a vendor's permission model, their audit model, their schema conventions,

319
00:13:00,640 --> 00:13:01,880
and their release cadence.

320
00:13:01,880 --> 00:13:05,400
That sounds manageable until you realize you just outsourced your boundary decisions to

321
00:13:05,400 --> 00:13:06,840
someone else's roadmap.

322
00:13:06,840 --> 00:13:09,680
And enterprises don't fail because they lack features.

323
00:13:09,680 --> 00:13:11,600
They fail because boundaries erode.

324
00:13:11,600 --> 00:13:15,280
plugin systems typically start with an optimistic premise.

325
00:13:15,280 --> 00:13:20,080
We'll let the model call tools, but safely so the platform defines a plugin schema.

326
00:13:20,080 --> 00:13:24,120
You register an endpoint, you describe actions and the host decides when to call them.

327
00:13:24,120 --> 00:13:25,200
It looks clean.

328
00:13:25,200 --> 00:13:26,680
It demos well.

329
00:13:26,680 --> 00:13:28,400
Then you scale it.

330
00:13:28,400 --> 00:13:29,960
Now the real issues show up.

331
00:13:29,960 --> 00:13:34,120
In consistent permissions, in consistent schemas and inconsistent auditing, one plugin

332
00:13:34,120 --> 00:13:37,240
asks for broad read access because it can't function otherwise.

333
00:13:37,240 --> 00:13:40,840
Another uses fine grained scopes but returns messy, untyped output.

334
00:13:40,840 --> 00:13:45,080
A third logs nothing useful because the platform doesn't enforce audit discipline at the tool

335
00:13:45,080 --> 00:13:46,080
boundary.

336
00:13:46,080 --> 00:13:49,800
So you end up with an ecosystem of integrations that are all technically supported but operationally

337
00:13:49,800 --> 00:13:50,800
incomparable.

338
00:13:50,800 --> 00:13:52,160
That is not interoperability.

339
00:13:52,160 --> 00:13:53,760
That is standardization theater.

340
00:13:53,760 --> 00:13:55,920
The second problem is maintenance reality.

341
00:13:55,920 --> 00:13:59,600
In a plugin ecosystem, every platform update is a revalidation event.

342
00:13:59,600 --> 00:14:02,320
The host changes how it interprets tool descriptions.

343
00:14:02,320 --> 00:14:04,720
The model changes how it selects tools.

344
00:14:04,720 --> 00:14:09,000
The platform changes permission prompts or deprecates an auth flow or modifies how it

345
00:14:09,000 --> 00:14:10,160
passes context.

346
00:14:10,160 --> 00:14:14,280
The plugin still works until it doesn't and when it breaks, it breaks at the worst layer.

347
00:14:14,280 --> 00:14:17,200
The layer where an LLM decides what to do next.

348
00:14:17,200 --> 00:14:20,280
That means your incident isn't API call failed.

349
00:14:20,280 --> 00:14:24,720
Your incident is agent behavior drifted and you can't patch that with a hot fix in a postman

350
00:14:24,720 --> 00:14:25,720
test.

351
00:14:25,720 --> 00:14:29,880
The third problem is lock in and it's more subtle than we used proprietary APIs.

352
00:14:29,880 --> 00:14:33,800
Lock in happens because you build against the platform's integration contract, not your

353
00:14:33,800 --> 00:14:34,800
own.

354
00:14:34,800 --> 00:14:40,840
Saming conventions, parameter shapes, error mapping, rate limits, approval prompts and user interaction

355
00:14:40,840 --> 00:14:44,040
patterns become entangled with one vendor's client.

356
00:14:44,040 --> 00:14:48,120
So if you ever want to move the tool to another host, another co-pilot surface, another

357
00:14:48,120 --> 00:14:51,680
IDE agent, another model provider, you're not porting code.

358
00:14:51,680 --> 00:14:53,280
You're rebuilding semantics.

359
00:14:53,280 --> 00:14:54,920
And semantics are where the real cost is.

360
00:14:54,920 --> 00:14:56,960
This is also where governance gets weird.

361
00:14:56,960 --> 00:15:02,520
Enterprises want one consistent enforcement plane, identity, policy, logging, throttling, retention.

362
00:15:02,520 --> 00:15:06,320
Plug-in ecosystems usually give you some of that, but in platform-shaped ways, you get the

363
00:15:06,320 --> 00:15:07,640
platform's consent screen.

364
00:15:07,640 --> 00:15:11,800
The platform's audit format, the platform's throttling assumptions and when you need to answer

365
00:15:11,800 --> 00:15:17,520
a compliance question, who accessed what, under what user through which tool, with what input,

366
00:15:17,520 --> 00:15:20,680
you discover that your data is trapped inside the platform's lens.

367
00:15:20,680 --> 00:15:23,880
It's auditable, but only in the way the vendor thinks matters.

368
00:15:23,880 --> 00:15:28,760
So plugins solved one pain, distribution and replaced it with a bigger one.

369
00:15:28,760 --> 00:15:32,000
Your integration boundary became a product feature you don't control.

370
00:15:32,000 --> 00:15:35,200
Which is why everyone got excited about function calling next.

371
00:15:35,200 --> 00:15:36,960
It looked like the escape hatch.

372
00:15:36,960 --> 00:15:41,400
Forget marketplaces, forget vendor schemers, just define functions in code, call them with

373
00:15:41,400 --> 00:15:46,640
structured arguments, keep it inside your app, and then scale arrived, pre-mcp pattern

374
00:15:46,640 --> 00:15:49,400
three, function calling without a protocol.

375
00:15:49,400 --> 00:15:51,840
Function calling looked like the grown-up version of plugins.

376
00:15:51,840 --> 00:15:56,280
No marketplace, no vendor manifest format, no install this extension, just a set of functions

377
00:15:56,280 --> 00:16:00,560
in your own code base, describe with JSON schema and invoked by the model with structured

378
00:16:00,560 --> 00:16:04,960
arguments, clean, familiar, contained, and for a single app in a single repo with a single

379
00:16:04,960 --> 00:16:06,440
team, it mostly works.

380
00:16:06,440 --> 00:16:08,680
But here's what function calling actually is.

381
00:16:08,680 --> 00:16:10,680
It's a local convention inside one client.

382
00:16:10,680 --> 00:16:11,680
It is not a protocol.

383
00:16:11,680 --> 00:16:16,120
A protocol is what lets independent systems coordinate without sharing a code base, a deployment

384
00:16:16,120 --> 00:16:17,880
pipeline, or a set of assumptions.

385
00:16:17,880 --> 00:16:19,160
HTTP is a protocol.

386
00:16:19,160 --> 00:16:20,200
Oh, auth is a protocol.

387
00:16:20,200 --> 00:16:24,320
They survive because they define the interaction boundary clearly enough that two strangers

388
00:16:24,320 --> 00:16:27,160
can interoperate and still argue about everything else.

389
00:16:27,160 --> 00:16:28,840
Function calling doesn't do that.

390
00:16:28,840 --> 00:16:30,240
Function calling says.

391
00:16:30,240 --> 00:16:34,320
But this one application will give the model a list of callable things.

392
00:16:34,320 --> 00:16:36,080
It does not standardize.

393
00:16:36,080 --> 00:16:40,400
Discovery across environments, version negotiation, transports, isolation, governance, or audit

394
00:16:40,400 --> 00:16:41,400
semantics.

395
00:16:41,400 --> 00:16:44,040
And those missing layers are exactly where enterprises bleed.

396
00:16:44,040 --> 00:16:45,040
So what happens?

397
00:16:45,040 --> 00:16:46,200
Everyone invents them again.

398
00:16:46,200 --> 00:16:49,160
One team puts functions behind an internal gateway.

399
00:16:49,160 --> 00:16:51,880
Another team wraps them with a thin tool router.

400
00:16:51,880 --> 00:16:56,720
A third team adds a database-backed registry so tools can be enabled per tenant.

401
00:16:56,720 --> 00:17:00,600
One else adds policy checks before execution, and now you've rebuilt a platform.

402
00:17:00,600 --> 00:17:04,320
Poorly, in five different ways, with five different security failure modes.

403
00:17:04,320 --> 00:17:06,600
This is the part most people don't want to hear.

404
00:17:06,600 --> 00:17:08,000
Function calling is not a boundary.

405
00:17:08,000 --> 00:17:09,000
It's a convenience layer.

406
00:17:09,000 --> 00:17:10,720
The model still doesn't touch your API.

407
00:17:10,720 --> 00:17:12,640
The model still only sees descriptions.

408
00:17:12,640 --> 00:17:15,560
And if your descriptions are incomplete, the model still improvises.

409
00:17:15,560 --> 00:17:20,080
You just move the surface from rest endpoints to function names, and then you hit the overlap

410
00:17:20,080 --> 00:17:21,080
problem.

411
00:17:21,080 --> 00:17:24,160
In the real world, every enterprise has three search functions.

412
00:17:24,160 --> 00:17:25,160
One search is graph.

413
00:17:25,160 --> 00:17:26,480
One search is SharePoint.

414
00:17:26,480 --> 00:17:28,360
One searches the app database.

415
00:17:28,360 --> 00:17:29,840
Each one returns a different shape.

416
00:17:29,840 --> 00:17:34,120
Each one has different paging, different throttling, different semantics for top.

417
00:17:34,120 --> 00:17:37,400
The model sees three tools that look like they do the same thing, and it chooses based

418
00:17:37,400 --> 00:17:39,080
on vibes and token probabilities.

419
00:17:39,080 --> 00:17:40,080
That's not tool use.

420
00:17:40,080 --> 00:17:41,080
That's tool roulette.

421
00:17:41,080 --> 00:17:45,440
So teams try to fix it by stuffing more explanation into the tool description.

422
00:17:45,440 --> 00:17:48,240
Longer prompts, more examples, more rules.

423
00:17:48,240 --> 00:17:51,440
And it works until the next team adds the fourth search function.

424
00:17:51,440 --> 00:17:54,600
Because the root cause isn't documentation quality, the root cause is that you never

425
00:17:54,600 --> 00:17:56,880
established a governable contract boundary.

426
00:17:56,880 --> 00:18:00,080
There's also a security trap hidden here with function calling.

427
00:18:00,080 --> 00:18:04,200
Teams often assume that because the function is in the app, it inherits the app security

428
00:18:04,200 --> 00:18:05,200
posture.

429
00:18:05,200 --> 00:18:10,240
But the function is typically executed by the server side runtime identity, not the user,

430
00:18:10,240 --> 00:18:13,000
not the requester, the runtime.

431
00:18:13,000 --> 00:18:15,720
So you end up with a quiet privilege escalation.

432
00:18:15,720 --> 00:18:20,480
User asks a question, model requests a function, server executes it with whatever identity

433
00:18:20,480 --> 00:18:22,240
the service is running under.

434
00:18:22,240 --> 00:18:27,720
If that identity is a service principle with broad graph permissions, because it was easier,

435
00:18:27,720 --> 00:18:32,720
then your AI helper is now an unbounded automation account with a chat interface.

436
00:18:32,720 --> 00:18:34,080
That is not a good time.

437
00:18:34,080 --> 00:18:37,360
And even if you do the right thing and thread user tokens through, you still don't have

438
00:18:37,360 --> 00:18:40,320
the protocol level enforcement and telemetry you need.

439
00:18:40,320 --> 00:18:42,240
You don't have standardized call envelopes.

440
00:18:42,240 --> 00:18:45,040
You don't have consistent correlation IDs across tool calls.

441
00:18:45,040 --> 00:18:46,720
You don't have portable audit events.

442
00:18:46,720 --> 00:18:51,040
You don't have a clean way to say this tool requires delegated access, and this other tool

443
00:18:51,040 --> 00:18:54,920
requires app only access, and the host must enforce that distinction.

444
00:18:54,920 --> 00:18:59,800
Instead you rely on developer discipline, which is just entropy with a nicer commit history.

445
00:18:59,800 --> 00:19:03,880
Function calling was the escape hatch from plug-in lock-in, but at enterprise scale it just

446
00:19:03,880 --> 00:19:08,680
created a new kind of sprawl, private tool APIs that can't interoperate, can't be governed

447
00:19:08,680 --> 00:19:12,720
consistently, and can't be shared across hosts without rewriting everything again.

448
00:19:12,720 --> 00:19:15,800
And that's why the next step wasn't a better function calling library.

449
00:19:15,800 --> 00:19:16,800
It was a protocol.

450
00:19:16,800 --> 00:19:18,760
Pre-MCP pattern 4.

451
00:19:18,760 --> 00:19:21,000
Agent frameworks aren't standards.

452
00:19:21,000 --> 00:19:24,480
After function calling hit its limits, the next move was predictable.

453
00:19:24,480 --> 00:19:25,480
Frameworks.

454
00:19:25,480 --> 00:19:28,960
Lang chain, semantic kernel, autogen, lang graph.

455
00:19:28,960 --> 00:19:31,800
Then a new one every week, each promising the same thing.

456
00:19:31,800 --> 00:19:34,600
Stop writing glue, start building agents.

457
00:19:34,600 --> 00:19:35,600
Frameworks do help.

458
00:19:35,600 --> 00:19:39,160
They give you patterns for tool selection, memory, retries, planning and orchestration.

459
00:19:39,160 --> 00:19:42,040
They make prototypes feel like products for about two weeks.

460
00:19:42,040 --> 00:19:43,280
And then the enterprise shows up.

461
00:19:43,280 --> 00:19:44,280
Here's the foundational mistake.

462
00:19:44,280 --> 00:19:47,840
Frameworks optimize developer velocity inside a project.

463
00:19:47,840 --> 00:19:50,360
Standards optimize interoperability across projects.

464
00:19:50,360 --> 00:19:51,480
Those are not the same job.

465
00:19:51,480 --> 00:19:54,760
A framework is a set of conventions plus runtime code.

466
00:19:54,760 --> 00:19:59,080
It assumes you'll run its loop, store state its way, define tools its way, and deploy it

467
00:19:59,080 --> 00:20:01,160
in a world where you control both ends.

468
00:20:01,160 --> 00:20:03,400
That's fine when you own the whole stack.

469
00:20:03,400 --> 00:20:04,600
Enterprises don't own the whole stack.

470
00:20:04,600 --> 00:20:08,080
They have multiple teams, multiple languages, multiple hosting environments, multiple

471
00:20:08,080 --> 00:20:12,000
risk postures and multiple approval chains that exist because auditors don't accept

472
00:20:12,000 --> 00:20:14,480
the framework handles it as an answer.

473
00:20:14,480 --> 00:20:16,320
So portability collapses first.

474
00:20:16,320 --> 00:20:20,240
Tools written for one framework don't transfer cleanly to another, even when they look similar.

475
00:20:20,240 --> 00:20:23,480
One framework calls tools with a certain schema shape.

476
00:20:23,480 --> 00:20:27,920
Another embeds extra metadata, a third models tools as a class with side effects.

477
00:20:27,920 --> 00:20:30,760
A fourth assumes a specific message format for streaming.

478
00:20:30,760 --> 00:20:33,800
The details vary and those details are where systems break.

479
00:20:33,800 --> 00:20:37,480
You end up with the same problem you had with plugins, just redistributed.

480
00:20:37,480 --> 00:20:41,440
Integration artifacts tied to a runtime you didn't want to standardize on.

481
00:20:41,440 --> 00:20:43,320
Then governance collapses.

482
00:20:43,320 --> 00:20:44,600
Most frameworks can log.

483
00:20:44,600 --> 00:20:45,600
They can trace.

484
00:20:45,600 --> 00:20:46,840
They can do observability.

485
00:20:46,840 --> 00:20:50,560
But they don't give you audit grade boundaries by default because audit grade boundaries are

486
00:20:50,560 --> 00:20:51,840
not a library feature.

487
00:20:51,840 --> 00:20:57,080
They're an architectural decision enforced at the edges, identity proof, policy evaluation,

488
00:20:57,080 --> 00:21:01,840
data minimization and a clear mapping from action to accountable principle.

489
00:21:01,840 --> 00:21:06,440
If your agent framework executes tools using an application identity with broad permissions,

490
00:21:06,440 --> 00:21:07,760
you didn't build an agent.

491
00:21:07,760 --> 00:21:11,000
You built a privileged automation account with conversational UX.

492
00:21:11,000 --> 00:21:15,440
If your framework allows a tool to receive arbitrary user provided strings that flow straight

493
00:21:15,440 --> 00:21:18,400
into downstream APIs you didn't build orchestration.

494
00:21:18,400 --> 00:21:20,800
You built a prompt injection amplifier.

495
00:21:20,800 --> 00:21:24,280
And frameworks tend to hide the sharp edges because they're trying to be helpful, helpful

496
00:21:24,280 --> 00:21:26,560
means convenience defaults.

497
00:21:26,560 --> 00:21:30,960
Convenience defaults mean silent permission expansion, implicit retries, broad tool exposure

498
00:21:30,960 --> 00:21:32,880
and just make it work behavior.

499
00:21:32,880 --> 00:21:35,080
That's how entropy enters.

500
00:21:35,080 --> 00:21:38,800
There's also a life cycle problem that frameworks can't solve for you.

501
00:21:38,800 --> 00:21:40,600
Enterprises don't just need agents to run.

502
00:21:40,600 --> 00:21:41,920
They need them to survive.

503
00:21:41,920 --> 00:21:47,080
Final executions, timeouts, compensating actions, fail-close behavior, human approvals, cost

504
00:21:47,080 --> 00:21:51,280
controls, change management, a stable contract that other teams can build against without

505
00:21:51,280 --> 00:21:53,320
importing your entire runtime.

506
00:21:53,320 --> 00:21:54,960
Frameworks are not built to be that contract.

507
00:21:54,960 --> 00:21:57,120
They are built to be your scaffolding.

508
00:21:57,120 --> 00:21:59,040
So what happens over time is simple.

509
00:21:59,040 --> 00:22:03,400
Every team picks a different framework than every team builds a different tool abstraction.

510
00:22:03,400 --> 00:22:06,160
Then every team invents a different way to secure it.

511
00:22:06,160 --> 00:22:10,320
Then security teams show up and ban half of it because there's no consistent enforcement

512
00:22:10,320 --> 00:22:11,800
point.

513
00:22:11,800 --> 00:22:13,480
Now you're back to the beginning.

514
00:22:13,480 --> 00:22:14,480
Custom glue everywhere.

515
00:22:14,480 --> 00:22:16,000
This is the uncomfortable truth.

516
00:22:16,000 --> 00:22:18,640
Agent frameworks are accelerators for prototypes.

517
00:22:18,640 --> 00:22:21,480
They are not coordination layers for ecosystems.

518
00:22:21,480 --> 00:22:24,280
And once you accept that, the next step becomes inevitable.

519
00:22:24,280 --> 00:22:26,640
The missing layer isn't a better agent loop.

520
00:22:26,640 --> 00:22:31,520
The missing layer is a protocol that defines how tools are described, how capabilities

521
00:22:31,520 --> 00:22:35,640
are discovered, how calls are transported, and where isolation boundaries live.

522
00:22:35,640 --> 00:22:37,480
That's what MCPs are trying to be.

523
00:22:37,480 --> 00:22:39,600
Why a protocol was inevitable?

524
00:22:39,600 --> 00:22:41,480
Standard speed frameworks at scale.

525
00:22:41,480 --> 00:22:45,760
Once you've watched rest rappers drift, plug in ecosystems, trap you, function calling

526
00:22:45,760 --> 00:22:50,600
fragment into private conventions, and agent frameworks multiply like rabbits, you end

527
00:22:50,600 --> 00:22:51,920
up with one conclusion.

528
00:22:51,920 --> 00:22:54,720
The problem isn't that teams can't build integrations.

529
00:22:54,720 --> 00:22:56,800
The problem is that they can't coordinate them.

530
00:22:56,800 --> 00:22:58,520
Coordination is not a library feature.

531
00:22:58,520 --> 00:22:59,520
It's a protocol problem.

532
00:22:59,520 --> 00:23:04,200
This is why protocols keep showing up at the exact moment an ecosystem stops being a project

533
00:23:04,200 --> 00:23:05,880
and starts being an economy.

534
00:23:05,880 --> 00:23:09,360
HTTP didn't win because it was the most elegant way to move bytes.

535
00:23:09,360 --> 00:23:13,280
But one, because it let strangers build software that could talk to other software without a

536
00:23:13,280 --> 00:23:14,280
shared code base.

537
00:23:14,280 --> 00:23:17,280
Oh, oath didn't win because developers love oath flows.

538
00:23:17,280 --> 00:23:21,520
It won because it let independent systems delegate authority without exchanging passwords

539
00:23:21,520 --> 00:23:25,040
and without inventing a new custom trust dance every time.

540
00:23:25,040 --> 00:23:29,280
Open API exists for the same reason, not because APIs were impossible, but because organizations

541
00:23:29,280 --> 00:23:34,240
needed a shared contract language to reduce ambiguity across teams, vendors, and tooling.

542
00:23:34,240 --> 00:23:37,160
MCP is the same move, just aimed at a new a failure mode.

543
00:23:37,160 --> 00:23:40,640
Because the moment you put an LLM in the loop, you introduce a caller that is inherently

544
00:23:40,640 --> 00:23:44,720
non-deterministic, operating against systems that are designed to be deterministic.

545
00:23:44,720 --> 00:23:48,440
The integration problem stops being how do we call the API and becomes how do we express

546
00:23:48,440 --> 00:23:53,280
capabilities and authority in a way that stays stable even when the caller is probabilistic.

547
00:23:53,280 --> 00:23:54,280
Frameworks can't solve that.

548
00:23:54,280 --> 00:23:55,640
They can only hide it.

549
00:23:55,640 --> 00:23:56,880
Standards don't hide complexity.

550
00:23:56,880 --> 00:23:57,880
They pin it down.

551
00:23:57,880 --> 00:23:59,360
That distinction matters.

552
00:23:59,360 --> 00:24:02,680
A framework says, here's how we do tool calling in this runtime.

553
00:24:02,680 --> 00:24:07,680
A standard says, here's how any runtime can describe tools, negotiate capabilities, and invoke

554
00:24:07,680 --> 00:24:09,760
them over a consistent envelope.

555
00:24:09,760 --> 00:24:13,040
That's the difference between an integration that works in one repo and an integration that

556
00:24:13,040 --> 00:24:14,800
can become an organizational asset.

557
00:24:14,800 --> 00:24:18,880
And in an enterprise, organizational assets are the only thing worth building.

558
00:24:18,880 --> 00:24:22,480
Everything else becomes abandoned middleware with a service principle nobody owns.

559
00:24:22,480 --> 00:24:24,400
Here's the other uncomfortable truth.

560
00:24:24,400 --> 00:24:29,440
Once multiple tool providers and multiple tool consumers exist, best practice collapses.

561
00:24:29,440 --> 00:24:30,440
It always does.

562
00:24:30,440 --> 00:24:32,240
Best practice requires alignment.

563
00:24:32,240 --> 00:24:33,680
It requires governance.

564
00:24:33,680 --> 00:24:35,520
Governance requires a shared boundary.

565
00:24:35,520 --> 00:24:39,600
Without a shared boundary, your best practice is just a style guide no one reads.

566
00:24:39,600 --> 00:24:42,480
So a protocol becomes inevitable because it gives you three things.

567
00:24:42,480 --> 00:24:44,560
Frameworks can't provide across an ecosystem.

568
00:24:44,560 --> 00:24:46,680
First, a stable interaction contract.

569
00:24:46,680 --> 00:24:51,240
Not we call functions, but how you list capabilities, how you call them, what the requests and response

570
00:24:51,240 --> 00:24:57,280
envelopes look like, how errors are represented, and how state is managed when state matters.

571
00:24:57,280 --> 00:24:58,280
Second, portability.

572
00:24:58,280 --> 00:25:01,880
A tool described through a protocol can outlive your current agent framework.

573
00:25:01,880 --> 00:25:03,880
It can outlive your current model provider.

574
00:25:03,880 --> 00:25:06,040
It can outlive your current host application.

575
00:25:06,040 --> 00:25:07,040
That's not theoretical.

576
00:25:07,040 --> 00:25:10,080
That's the difference between a two year investment and a quarterly experiment.

577
00:25:10,080 --> 00:25:12,920
Third, a place to enforce boundaries consistently.

578
00:25:12,920 --> 00:25:16,440
Not by trusting developers to remember rules, but by forcing the interaction through a

579
00:25:16,440 --> 00:25:19,200
shape where identity policy and audit can attach.

580
00:25:19,200 --> 00:25:23,560
And this is why MCP's bet is not let standardized AI integrations.

581
00:25:23,560 --> 00:25:24,960
It's narrower and smarter.

582
00:25:24,960 --> 00:25:28,560
Standardize how context and capabilities are presented to a model driven host and how

583
00:25:28,560 --> 00:25:31,600
the host invokes external tool servers in a controlled way.

584
00:25:31,600 --> 00:25:33,920
That's why MCP isn't competing with agent frameworks.

585
00:25:33,920 --> 00:25:35,640
It's sitting underneath them.

586
00:25:35,640 --> 00:25:39,520
Frameworks can keep innovating on planning loops and memory strategies and orchestration

587
00:25:39,520 --> 00:25:40,520
patterns.

588
00:25:40,520 --> 00:25:41,520
Fine, let them.

589
00:25:41,520 --> 00:25:44,640
But they need a stable substrate for tool integration that doesn't turn into glue code

590
00:25:44,640 --> 00:25:47,240
entropy the moment you cross team boundaries.

591
00:25:47,240 --> 00:25:49,880
This is also why this fits Microsoft's world so well.

592
00:25:49,880 --> 00:25:52,040
Microsoft doesn't sell simple.

593
00:25:52,040 --> 00:25:53,800
Microsoft sells governable.

594
00:25:53,800 --> 00:25:58,480
Identity first, policy driven, audit heavy systems that assume entropy is the default

595
00:25:58,480 --> 00:26:00,880
and control has to be enforced by design.

596
00:26:00,880 --> 00:26:05,440
So yes, a protocol was inevitable because at scale you either standardize the boundary

597
00:26:05,440 --> 00:26:07,760
or you standardize the incident review.

598
00:26:07,760 --> 00:26:13,080
MCP defined precisely communication plus capabilities plus boundaries.

599
00:26:13,080 --> 00:26:18,280
So now define MCP without the analogies because USB for AI is cute but it hides the part

600
00:26:18,280 --> 00:26:19,760
that matters.

601
00:26:19,760 --> 00:26:24,600
MCP is a protocol that defines how an AI host talks to external capability servers.

602
00:26:24,600 --> 00:26:25,600
That's it.

603
00:26:25,600 --> 00:26:26,840
Not the model talks to tools.

604
00:26:26,840 --> 00:26:28,360
The model still doesn't touch anything.

605
00:26:28,360 --> 00:26:29,360
The host does.

606
00:26:29,360 --> 00:26:34,200
MCP defines the shape of that interaction so it can be repeatable, inspectable and governable.

607
00:26:34,200 --> 00:26:38,160
At the wire level, MCP uses JSON RPC2 as the message format.

608
00:26:38,160 --> 00:26:41,560
That means you get a predictable request and response envelope.

609
00:26:41,560 --> 00:26:44,800
Method names, parameters, IDs and structured error objects.

610
00:26:44,800 --> 00:26:46,960
The point isn't that JSON RPC is fashionable.

611
00:26:46,960 --> 00:26:51,960
The point is that the tool call stops being some HTTP request your agent loop invented

612
00:26:51,960 --> 00:26:55,560
and becomes a standardized call with a known life cycle.

613
00:26:55,560 --> 00:26:59,720
MCP also forces you to separate two layers people keep mixing up.

614
00:26:59,720 --> 00:27:01,120
Transport and protocol.

615
00:27:01,120 --> 00:27:03,400
The protocol is the message format and semantics.

616
00:27:03,400 --> 00:27:05,440
The transport is how bytes move.

617
00:27:05,440 --> 00:27:11,880
MCP supports local process boundary transports like SDDIO and remote transports over HTTP

618
00:27:11,880 --> 00:27:13,240
with streaming options.

619
00:27:13,240 --> 00:27:14,840
Those transports aren't cosmetic.

620
00:27:14,840 --> 00:27:16,960
They define where your trust boundary sits.

621
00:27:16,960 --> 00:27:19,200
Local stereo is a local execution trust problem.

622
00:27:19,200 --> 00:27:22,040
Remote HTTP is an identity and policy problem.

623
00:27:22,040 --> 00:27:23,640
Same protocol, different blast radius.

624
00:27:23,640 --> 00:27:25,600
Now the second part, capabilities.

625
00:27:25,600 --> 00:27:28,800
MCP is not, here's an endpoint, good luck.

626
00:27:28,800 --> 00:27:30,320
It's capability declaration.

627
00:27:30,320 --> 00:27:34,560
An MCP server advertises what it can do and the client negotiates what it supports.

628
00:27:34,560 --> 00:27:38,880
That means the host can enumerate tools and decide what to expose to the model and under

629
00:27:38,880 --> 00:27:39,880
what conditions.

630
00:27:39,880 --> 00:27:43,440
This matters because tools for all doesn't become manageable by writing better prompts.

631
00:27:43,440 --> 00:27:47,920
It becomes manageable when the host can treat tools as a capability surface.

632
00:27:47,920 --> 00:27:50,600
Discoverable, versionable and constrained.

633
00:27:50,600 --> 00:27:54,000
Start a pile of bespoke function calls scattered across repos.

634
00:27:54,000 --> 00:27:58,280
In MCP, servers expose three primitives, tools, resources and prompts.

635
00:27:58,280 --> 00:27:59,280
Tools are actions.

636
00:27:59,280 --> 00:28:01,480
They have names, descriptions and schemers.

637
00:28:01,480 --> 00:28:05,280
They are the part that changes the world or at least queries it with intent.

638
00:28:05,280 --> 00:28:07,840
Because the model is probabilistic, tools have to be deterministic.

639
00:28:07,840 --> 00:28:10,880
Your tool schema is you forcing ambiguity out of the interface.

640
00:28:10,880 --> 00:28:14,320
If you leave ambiguity in, the model will reintroduce it for you.

641
00:28:14,320 --> 00:28:15,640
Resources are raw context.

642
00:28:15,640 --> 00:28:19,640
Think, read oriented inputs that can be pulled into the model's working set or used

643
00:28:19,640 --> 00:28:20,640
for retrieval.

644
00:28:20,640 --> 00:28:21,640
They're not actions.

645
00:28:21,640 --> 00:28:23,680
They are structured ways to fetch data.

646
00:28:23,680 --> 00:28:26,720
And separating resources from tools is not pedantry.

647
00:28:26,720 --> 00:28:29,280
It's how you separate knowledge from authority.

648
00:28:29,280 --> 00:28:30,280
Prompts or templates.

649
00:28:30,280 --> 00:28:31,960
They are productized in tent shaping.

650
00:28:31,960 --> 00:28:36,200
In practice, they are how a host can offer a consistent entry point like a slash command

651
00:28:36,200 --> 00:28:40,440
without requiring every user to reinvent the same instruction set.

652
00:28:40,440 --> 00:28:43,560
Prompts aren't governance by themselves, but they reduce drift in how people ask for

653
00:28:43,560 --> 00:28:44,560
the same operation.

654
00:28:44,560 --> 00:28:46,120
Now the third part, boundaries.

655
00:28:46,120 --> 00:28:49,160
MCP's isolation model is the thing you should care about most.

656
00:28:49,160 --> 00:28:52,360
And MCP server does not automatically see the full conversation.

657
00:28:52,360 --> 00:28:54,520
The host mediates what context is sent.

658
00:28:54,520 --> 00:28:56,440
Each server is isolated from other servers.

659
00:28:56,440 --> 00:29:00,320
That means MCP gives you a place to implement data minimization by design.

660
00:29:00,320 --> 00:29:04,280
Only send the minimum context necessary for this call to this server at this time.

661
00:29:04,280 --> 00:29:05,840
That is the architectural choke point.

662
00:29:05,840 --> 00:29:10,160
It's the difference between the model can do things and the model can request things

663
00:29:10,160 --> 00:29:12,480
and the platform decides what actually happens.

664
00:29:12,480 --> 00:29:16,960
So when people describe MCP as standardized function calling, they're missing the enforcement

665
00:29:16,960 --> 00:29:17,960
potential.

666
00:29:17,960 --> 00:29:19,920
Calling is usually an in-process feature.

667
00:29:19,920 --> 00:29:25,600
MCP is an externalized contract with explicit discovery, explicit capability surfaces,

668
00:29:25,600 --> 00:29:29,000
and transport choices that map cleanly to trust boundaries.

669
00:29:29,000 --> 00:29:31,040
And the cleanest way to say it is this.

670
00:29:31,040 --> 00:29:35,840
MCP is a protocol that turns tool use into an auditable, governable interface.

671
00:29:35,840 --> 00:29:38,160
Because it puts the host back in charge of authority.

672
00:29:38,160 --> 00:29:39,400
That's what we needed all along.

673
00:29:39,400 --> 00:29:43,720
Now that MCP is defined precisely, the next step is to break down the primitives that

674
00:29:43,720 --> 00:29:47,760
actually matter in real systems, resources, tools and prompts.

675
00:29:47,760 --> 00:29:52,840
And why mixing them is how you accidentally give an LLM more power than you intended.

676
00:29:52,840 --> 00:29:57,040
MCP primitives that actually matter, resources, tools, prompts.

677
00:29:57,040 --> 00:30:01,400
Most explanations of MCP stop at the vocabulary list, resources, tools, prompts.

678
00:30:01,400 --> 00:30:05,520
And then they move on like naming the parts is the same as understanding the failure modes.

679
00:30:05,520 --> 00:30:06,520
It isn't.

680
00:30:06,520 --> 00:30:10,960
These three primitives are MCP's real contribution because they force you to separate things,

681
00:30:10,960 --> 00:30:13,200
enterprises keep mixing together.

682
00:30:13,200 --> 00:30:16,240
Information, action and intent shaping.

683
00:30:16,240 --> 00:30:19,400
When you mix them, you don't just create messy integrations.

684
00:30:19,400 --> 00:30:22,800
You create authority leaks, start with resources.

685
00:30:22,800 --> 00:30:24,480
Resources are read-oriented.

686
00:30:24,480 --> 00:30:29,280
They are how an MCP server exposes context without pretending it's an action.

687
00:30:29,280 --> 00:30:32,120
Think of them as controlled retrieval surfaces.

688
00:30:32,120 --> 00:30:33,640
Give me the policy text.

689
00:30:33,640 --> 00:30:34,640
Give me the schema.

690
00:30:34,640 --> 00:30:35,840
Give me the metadata.

691
00:30:35,840 --> 00:30:37,600
Give me the last 20 entries.

692
00:30:37,600 --> 00:30:41,000
They're rag-friendly by design because they produce inputs the host can decide to pass

693
00:30:41,000 --> 00:30:42,800
into the model's context window.

694
00:30:42,800 --> 00:30:44,520
But here's the crucial part.

695
00:30:44,520 --> 00:30:45,960
Resources should not mutate anything.

696
00:30:45,960 --> 00:30:49,360
The moment you let a resource also perform an action you've created a hidden side effect

697
00:30:49,360 --> 00:30:50,360
channel.

698
00:30:50,360 --> 00:30:53,880
Side effects are where audit trails get fuzzy and blame gets shared.

699
00:30:53,880 --> 00:30:55,680
Enterprises don't survive shared blame.

700
00:30:55,680 --> 00:31:00,640
So you treat resources as context supply, stable shapes, clear identifiers, minimal surprise.

701
00:31:00,640 --> 00:31:04,920
If you want a model to understand what confidential means in your tenant, you don't give it a tool

702
00:31:04,920 --> 00:31:07,040
called "interpret confidentiality".

703
00:31:07,040 --> 00:31:11,400
You give it a resource that returns the actual classification policy, deterministic input,

704
00:31:11,400 --> 00:31:13,440
probabilistic reasoning, that's the correct separation.

705
00:31:13,440 --> 00:31:14,920
Now tools.

706
00:31:14,920 --> 00:31:16,560
Tools are where the blast radius lives.

707
00:31:16,560 --> 00:31:18,000
A tool is an action interface.

708
00:31:18,000 --> 00:31:22,440
It either changes the world or it queries something in a way that drives downstream action.

709
00:31:22,440 --> 00:31:26,800
And because the model is probabilistic, tool interfaces must be intentionally boring.

710
00:31:26,800 --> 00:31:27,800
Strict schemas.

711
00:31:27,800 --> 00:31:32,240
Stable output shapes, narrow parameter ranges, and names that make overlap impossible.

712
00:31:32,240 --> 00:31:34,320
This is where most teams sabotage themselves.

713
00:31:34,320 --> 00:31:38,840
They define tools like search, get, update, and create with optional parameters that

714
00:31:38,840 --> 00:31:39,840
change meaning.

715
00:31:39,840 --> 00:31:43,120
Then they wonder why the model calls the wrong thing or calls the right thing with the

716
00:31:43,120 --> 00:31:44,120
wrong scope.

717
00:31:44,120 --> 00:31:45,600
A tool schema is not documentation.

718
00:31:45,600 --> 00:31:48,440
It is your enforcement mechanism against ambiguity.

719
00:31:48,440 --> 00:31:52,960
If you allow site id or site URL as optional fields, the model will sometimes send both.

720
00:31:52,960 --> 00:31:57,120
If you allow query as a free string, the model will eventually embed instructions in it.

721
00:31:57,120 --> 00:32:01,440
If you return results as an untyped array of mixed objects, you're making the model reverse

722
00:32:01,440 --> 00:32:03,520
engineer your domain model mid-flight.

723
00:32:03,520 --> 00:32:06,600
That's not intelligence, that's punishment.

724
00:32:06,600 --> 00:32:10,760
The correct pattern is to design tools like deterministic RPC calls.

725
00:32:10,760 --> 00:32:15,040
And input so a model can't get creatively, constraint output so a model can't hallucinate

726
00:32:15,040 --> 00:32:16,760
structure that isn't there.

727
00:32:16,760 --> 00:32:21,520
And log every call as a first class audit event tied to an identity, a scope, and a correlation

728
00:32:21,520 --> 00:32:22,520
ID.

729
00:32:22,520 --> 00:32:26,120
Now prompts in MCPR templates, productized intent shaping.

730
00:32:26,120 --> 00:32:28,920
They exist because humans are the original entropy source.

731
00:32:28,920 --> 00:32:33,160
If you let every user invent their own, please summarize this and then do the thing instruction

732
00:32:33,160 --> 00:32:35,200
set, you get behavioral drift.

733
00:32:35,200 --> 00:32:40,400
And drift turns into inconsistent tool usage, inconsistent approvals, and inconsistent risk.

734
00:32:40,400 --> 00:32:42,040
Let's reduce that.

735
00:32:42,040 --> 00:32:46,160
They give the host a stable entry point, use the approved template for SharePoint document

736
00:32:46,160 --> 00:32:47,160
review.

737
00:32:47,160 --> 00:32:50,440
Not because prompts are magic, but because they standardize how the task is framed and

738
00:32:50,440 --> 00:32:51,800
what constraints are stated.

739
00:32:51,800 --> 00:32:53,080
But prompts are not governance.

740
00:32:53,080 --> 00:32:55,400
They're guardrails for the human, not the model.

741
00:32:55,400 --> 00:32:59,200
The governance still lives in the hosts' decision about which resources and tools are

742
00:32:59,200 --> 00:33:01,520
even available, and under which identity.

743
00:33:01,520 --> 00:33:03,040
So the split matters.

744
00:33:03,040 --> 00:33:07,160
Resources feed knowledge, tools exercise authority, prompts shape intent.

745
00:33:07,160 --> 00:33:09,720
Knowledge is not authority, authority is not intent.

746
00:33:09,720 --> 00:33:12,920
And MCP's primitives force you to stop pretending they are.

747
00:33:12,920 --> 00:33:15,360
Next, the uncomfortable part transport and state.

748
00:33:15,360 --> 00:33:21,720
Because when you move from local studio to remote HTTP, you're not changing performance

749
00:33:21,720 --> 00:33:22,720
characteristics.

750
00:33:22,720 --> 00:33:25,200
You're changing who has to be trusted.

751
00:33:25,200 --> 00:33:26,200
Transport and state.

752
00:33:26,200 --> 00:33:31,440
Stiav versus HTTP, local versus remote, and why it's not cosmetic.

753
00:33:31,440 --> 00:33:34,760
Transport is where most protocol people lose the room because it sounds like plumbing.

754
00:33:34,760 --> 00:33:36,520
But transport is not plumbing.

755
00:33:36,520 --> 00:33:39,040
Transport is the first place your trust model becomes real.

756
00:33:39,040 --> 00:33:41,240
MCP gives you at least two common transports.

757
00:33:41,240 --> 00:33:42,440
Stiav and HTTP.

758
00:33:42,440 --> 00:33:44,720
People talk about them like the difference is performance.

759
00:33:44,720 --> 00:33:47,360
Local is faster, remote is slower, pick your favorite.

760
00:33:47,360 --> 00:33:48,840
That's the comfortable story.

761
00:33:48,840 --> 00:33:53,760
The real story is, STDO and HTTP change who you have to trust, what identity you can

762
00:33:53,760 --> 00:33:55,920
prove and what failure looks like.

763
00:33:55,920 --> 00:33:56,920
Start with STDO.

764
00:33:56,920 --> 00:33:58,440
STDO is a local process boundary.

765
00:33:58,440 --> 00:34:02,760
The host starts the MCP server as a child process, then communicates over standard input

766
00:34:02,760 --> 00:34:03,760
and output.

767
00:34:03,760 --> 00:34:06,000
No network, no load balancer, no TLS.

768
00:34:06,000 --> 00:34:08,440
It feels safe because it's on the machine.

769
00:34:08,440 --> 00:34:11,760
And it can be safe if you treat local execution as a security boundary.

770
00:34:11,760 --> 00:34:12,760
But most teams don't.

771
00:34:12,760 --> 00:34:14,840
They treat local as trusted.

772
00:34:14,840 --> 00:34:18,720
Then they start running random community MCP servers because it's convenient.

773
00:34:18,720 --> 00:34:23,120
And now your AI host is launching arbitrary code with whatever file system and network access

774
00:34:23,120 --> 00:34:24,560
your user account has.

775
00:34:24,560 --> 00:34:26,160
Local doesn't mean safe.

776
00:34:26,160 --> 00:34:29,160
Local means the trust decision moved from the network to the endpoint.

777
00:34:29,160 --> 00:34:33,160
If you're on Windows, that endpoint is now a workstation with browser sessions, cache

778
00:34:33,160 --> 00:34:38,040
tokens, synced one drive content, and usually an over-privileged developer identity.

779
00:34:38,040 --> 00:34:39,720
If you're on a build agent, it's worse.

780
00:34:39,720 --> 00:34:42,840
It's a machine with CI secrets and deployment permissions.

781
00:34:42,840 --> 00:34:47,000
So STDO is great for development because it's simple and fast.

782
00:34:47,000 --> 00:34:50,040
And the isolation is basically the OS process boundary.

783
00:34:50,040 --> 00:34:52,840
But it also means the server is inside your blast radius.

784
00:34:52,840 --> 00:34:58,520
Now HTTP, HTTP is where the enterprise story begins because remote MCP servers are how

785
00:34:58,520 --> 00:35:01,080
you build shared capability services.

786
00:35:01,080 --> 00:35:06,880
The SharePoint MCP server, the Graph MCP server, the ticketing MCP server, centralized,

787
00:35:06,880 --> 00:35:09,600
managed, logged, rate-limited, scalable.

788
00:35:09,600 --> 00:35:13,040
But remote means every tool call is now a distributed system call.

789
00:35:13,040 --> 00:35:14,480
So identity must be explicit.

790
00:35:14,480 --> 00:35:18,520
If your MCP server is remote and it doesn't authenticate callers properly, you didn't

791
00:35:18,520 --> 00:35:19,600
build a tool server.

792
00:35:19,600 --> 00:35:22,000
You build Shadow IT with a JSON RPC wrapper.

793
00:35:22,000 --> 00:35:23,640
This is where entra flows matter.

794
00:35:23,640 --> 00:35:26,440
With HTTP, you can and should require a token.

795
00:35:26,440 --> 00:35:30,520
That token should have an audience, scopes or roles, and an accountable principle.

796
00:35:30,520 --> 00:35:34,240
And you need to decide whether that principle is the user, the workload, or a broken identity

797
00:35:34,240 --> 00:35:35,600
via on behalf of.

798
00:35:35,600 --> 00:35:38,360
As remote changes, what the audit trail can prove.

799
00:35:38,360 --> 00:35:41,080
With STDO, your audit trail is mostly host local.

800
00:35:41,080 --> 00:35:42,440
The user ran this tool.

801
00:35:42,440 --> 00:35:45,680
With HTTP, your audit trail can be centralized.

802
00:35:45,680 --> 00:35:50,520
This user, through this host, called this tool under this policy at this time.

803
00:35:50,520 --> 00:35:52,040
That's a different class of defensibility.

804
00:35:52,040 --> 00:35:55,800
Now state, MCP connections are typically stateful at the protocol level.

805
00:35:55,800 --> 00:35:58,600
That doesn't mean the server stores your conversation history.

806
00:35:58,600 --> 00:36:00,520
It means there's a session lifecycle.

807
00:36:00,520 --> 00:36:05,840
Initialize, negotiate capabilities, exchange messages, and the server can send notifications

808
00:36:05,840 --> 00:36:08,400
or progress updates in a consistent way.

809
00:36:08,400 --> 00:36:11,200
Statefulness matters because tool execution isn't always instant.

810
00:36:11,200 --> 00:36:13,000
A search files tool might be fast.

811
00:36:13,000 --> 00:36:15,240
A raindeck's aside tool might take minutes.

812
00:36:15,240 --> 00:36:17,440
A, create a report tool might be queued.

813
00:36:17,440 --> 00:36:22,080
If you treat every tool as a stateless request response call, you end up reinventing long-running

814
00:36:22,080 --> 00:36:23,920
task patterns poorly.

815
00:36:23,920 --> 00:36:28,560
Polling endpoints, random retries, duplicate actions, and half-finished operations that look

816
00:36:28,560 --> 00:36:30,720
successful to the model.

817
00:36:30,720 --> 00:36:33,680
And remember, agent loops amplify ambiguity.

818
00:36:33,680 --> 00:36:36,440
If a tool call is slow or flaky, the model doesn't just wait.

819
00:36:36,440 --> 00:36:40,200
It tries again, or it tries something else, or it assumes the action completed and moves

820
00:36:40,200 --> 00:36:41,200
on.

821
00:36:41,200 --> 00:36:45,840
So you need explicit patterns for state, progress events, correlation IDs, and idempotency

822
00:36:45,840 --> 00:36:48,200
keys, where actions mutate systems.

823
00:36:48,200 --> 00:36:49,200
That's not optional.

824
00:36:49,200 --> 00:36:51,240
Now connect this back to Microsoft reality.

825
00:36:51,240 --> 00:36:52,560
Studio is your dev loop.

826
00:36:52,560 --> 00:36:54,520
HTTP is your enterprise loop.

827
00:36:54,520 --> 00:36:57,480
Local MCP servers are for building and experimenting.

828
00:36:57,480 --> 00:36:59,960
Vote MCP servers are for governance.

829
00:36:59,960 --> 00:37:05,200
Entra backed A, A, P, I, M, front doors, logging into Sentinel and policy enforcement that

830
00:37:05,200 --> 00:37:08,880
doesn't depend on whether a developer remembered to do the right thing.

831
00:37:08,880 --> 00:37:12,560
And here's the rule you should tattoo onto every architecture diagram.

832
00:37:12,560 --> 00:37:16,360
Transport choices change trust boundaries, not just latency.

833
00:37:16,360 --> 00:37:20,680
So before you ask functions or container apps ask the real question, where does this tool

834
00:37:20,680 --> 00:37:25,400
run, under which identity, with what policy, and what happens when it fails.

835
00:37:25,400 --> 00:37:29,120
Because if you can't answer that, you don't have an MCP architecture, you have a demo.

836
00:37:29,120 --> 00:37:31,040
MCP meets Microsoft.

837
00:37:31,040 --> 00:37:32,760
Why this fits too well.

838
00:37:32,760 --> 00:37:37,280
This is where MCP stops being an AI developer trend and starts looking like a Microsoft

839
00:37:37,280 --> 00:37:39,520
platform move that was going to happen anyway.

840
00:37:39,520 --> 00:37:42,000
Because Microsoft doesn't really build products around models.

841
00:37:42,000 --> 00:37:44,560
Microsoft builds products around governance.

842
00:37:44,560 --> 00:37:50,000
And that distinction matters because MCP is, architecturally, a governance primitive, pretending

843
00:37:50,000 --> 00:37:51,800
to be an integration protocol.

844
00:37:51,800 --> 00:37:55,360
Most ecosystems treat tool integration as a convenience feature.

845
00:37:55,360 --> 00:37:59,480
When you add after the model works, Microsoft environments treat integration as the blast

846
00:37:59,480 --> 00:38:00,480
radius.

847
00:38:00,480 --> 00:38:04,480
Identity policy audit, retention, e-discovery, DLP, those aren't add-ons, they're the shape

848
00:38:04,480 --> 00:38:05,480
of the environment.

849
00:38:05,480 --> 00:38:09,200
And when you drop LLM tool use into that environment, you don't get to treat it like a weekend

850
00:38:09,200 --> 00:38:10,200
project.

851
00:38:10,200 --> 00:38:11,480
You need a boundary.

852
00:38:11,480 --> 00:38:13,040
Microsoft's posture is identity first.

853
00:38:13,040 --> 00:38:16,320
Entra sits in the middle of everything, not because Microsoft loves orth prompts, but because

854
00:38:16,320 --> 00:38:21,400
identities, the only stable perimeter that survives cloud remote work and SaaS sprawl.

855
00:38:21,400 --> 00:38:26,200
That means MCP's host mediates authority model plugs into existing instincts.

856
00:38:26,200 --> 00:38:30,200
Make the caller prove who they are, make the token express what they can do, and log

857
00:38:30,200 --> 00:38:33,040
the action in a way that maps to an accountable principle.

858
00:38:33,040 --> 00:38:37,120
MCP doesn't magically solve that, but it gives you a consistent place to attach it.

859
00:38:37,120 --> 00:38:39,480
Now look at the co-pilot ecosystem pressure.

860
00:38:39,480 --> 00:38:41,760
Co-pilot exists across multiple hosts.

861
00:38:41,760 --> 00:38:48,000
M365 surfaces, teams, windows, edge, VS code, custom apps, and whatever the next assistant

862
00:38:48,000 --> 00:38:49,880
endpoint becomes.

863
00:38:49,880 --> 00:38:55,000
If tool integrations are bespoke per host, Microsoft inherits the worst problem on Earth, a thousand

864
00:38:55,000 --> 00:38:59,280
inconsistent adapters to the same enterprise systems, each with different permission handling

865
00:38:59,280 --> 00:39:01,160
and audit semantics.

866
00:39:01,160 --> 00:39:03,240
That is not a scalable platform strategy.

867
00:39:03,240 --> 00:39:05,680
So MCP aligns with inevitability.

868
00:39:05,680 --> 00:39:08,840
Tool integration has to become a shared substrate.

869
00:39:08,840 --> 00:39:12,960
Not because it's elegant, but because it's the only way to keep co-pilot style experiences

870
00:39:12,960 --> 00:39:17,560
consistent across hosts without rebuilding the tool ecosystem for every new client, and

871
00:39:17,560 --> 00:39:20,080
Microsoft is structurally built for choke points.

872
00:39:20,080 --> 00:39:21,800
Azure is a control plane company.

873
00:39:21,800 --> 00:39:23,760
The value isn't we can call an API.

874
00:39:23,760 --> 00:39:27,560
The value is we can put policy in front of the API.

875
00:39:27,560 --> 00:39:32,560
Resource groups, RBAC, private link, APIM, Key Vault, Defender, Perview, these are all

876
00:39:32,560 --> 00:39:34,800
different ways of saying the same thing.

877
00:39:34,800 --> 00:39:37,440
Control, by centralizing enforcement.

878
00:39:37,440 --> 00:39:41,000
MCP is the same pattern applied to model tool use.

879
00:39:41,000 --> 00:39:45,120
Now the part most people miss, Microsoft already has the data gravity that makes MCP

880
00:39:45,120 --> 00:39:48,120
useful.

881
00:39:48,120 --> 00:39:49,120
Graph and SharePoint aren't just APIs.

882
00:39:49,120 --> 00:39:52,120
They're the enterprise's nervous system, files, permissions, groups, chats, meetings, tasks,

883
00:39:52,120 --> 00:39:55,120
identities, devices, risk signals.

884
00:39:55,120 --> 00:40:00,120
When you let a model use tools in that ecosystem, the failure mode isn't the model made a mistake.

885
00:40:00,120 --> 00:40:04,520
The failure mode is the model acted with the wrong authority across a graph of interconnected

886
00:40:04,520 --> 00:40:05,520
resources.

887
00:40:05,520 --> 00:40:09,400
That's why MCP fits it forces you to treat tools as declared capabilities with explicit

888
00:40:09,400 --> 00:40:12,000
contracts, not whatever endpoint we can reach.

889
00:40:12,000 --> 00:40:17,000
It encourages an integration boundary where you can standardize the boring parts, tool naming,

890
00:40:17,000 --> 00:40:19,800
schemers, identity handling, logging and rate control.

891
00:40:19,800 --> 00:40:23,720
And yes, Microsoft is culturally inclined to standardize the boring parts.

892
00:40:23,720 --> 00:40:25,000
That's half the platform.

893
00:40:25,000 --> 00:40:28,040
There's also a compliance angle that's not optional.

894
00:40:28,040 --> 00:40:31,720
Enterprises want audit trails that survive incident response and regulatory review.

895
00:40:31,720 --> 00:40:34,120
MCP's host-mediated model makes that feasible.

896
00:40:34,120 --> 00:40:39,040
You can correlate a user prompt to tool selection, to tool execution, to downstream API calls.

897
00:40:39,040 --> 00:40:41,200
Not perfectly, not automatically, but feasibly.

898
00:40:41,200 --> 00:40:45,040
Without a protocol boundary, you end up scraping logs across five layers and still not knowing

899
00:40:45,040 --> 00:40:47,880
what the model saw or why it chose the tool it did.

900
00:40:47,880 --> 00:40:53,440
So MCP fits Microsoft because it reinforces Microsoft's default operating model.

901
00:40:53,440 --> 00:40:58,320
Reduce entropy by making boundaries explicit, make identity central and make enforcement

902
00:40:58,320 --> 00:41:00,600
attached to a consistent interface.

903
00:41:00,600 --> 00:41:02,160
It's not AI stuff.

904
00:41:02,160 --> 00:41:06,200
Its integration architecture catching up to a world where the corner is probabilistic

905
00:41:06,200 --> 00:41:09,520
and the enterprise environment is not allowed to be.

906
00:41:09,520 --> 00:41:12,560
MCP versus proprietary co-pilot extensions.

907
00:41:12,560 --> 00:41:15,000
Open standard versus platform gravity.

908
00:41:15,000 --> 00:41:18,280
This is where people try to turn MCP into a culture war.

909
00:41:18,280 --> 00:41:20,320
Open standard good proprietary bad does.

910
00:41:20,320 --> 00:41:22,600
That's not architecture, that's branding.

911
00:41:22,600 --> 00:41:26,160
In Microsoft land, you're going to live in a hybrid world for a long time.

912
00:41:26,160 --> 00:41:29,640
Some capabilities will come through co-pilot native extension points.

913
00:41:29,640 --> 00:41:32,160
Some will come through open protocols like MCP.

914
00:41:32,160 --> 00:41:34,120
The question is in which one is morally superior.

915
00:41:34,120 --> 00:41:36,840
The question is where you want to pay your integration tax.

916
00:41:36,840 --> 00:41:40,160
Start with what proprietary co-pilot extensions optimize for.

917
00:41:40,160 --> 00:41:42,440
Speed inside a single platform.

918
00:41:42,440 --> 00:41:46,720
When Microsoft owns the host, the identity integration, the UX surface and the distribution

919
00:41:46,720 --> 00:41:49,560
channel, they can deliver a very coherent experience.

920
00:41:49,560 --> 00:41:50,880
Permissions prompts feel consistent.

921
00:41:50,880 --> 00:41:53,160
Admin controls show up in familiar places.

922
00:41:53,160 --> 00:41:56,600
Telemetry is good enough for most deployments because it's standardized to the platform.

923
00:41:56,600 --> 00:41:59,320
That's the upside of platform gravity.

924
00:41:59,320 --> 00:42:02,720
It reduces choices and reduces choices feel like simplicity.

925
00:42:02,720 --> 00:42:05,720
The platform gravity also captures your integration semantics.

926
00:42:05,720 --> 00:42:08,200
You build the tool the way the platform wants it built.

927
00:42:08,200 --> 00:42:10,400
You name things the way the platform wants them named.

928
00:42:10,400 --> 00:42:15,520
You accept the platform's interpretation of what an action is, what approval is, what

929
00:42:15,520 --> 00:42:18,280
logging is, and how versioning should work.

930
00:42:18,280 --> 00:42:22,840
If Microsoft changes any of that, your integration isn't wrong, but it becomes out of date.

931
00:42:22,840 --> 00:42:25,000
Then you get drift not in your backend API.

932
00:42:25,000 --> 00:42:28,360
In the user facing behavior of the agent, that's the part enterprises hate because it's

933
00:42:28,360 --> 00:42:30,200
difficult to regression test.

934
00:42:30,200 --> 00:42:33,520
Your security review can validate scopes and endpoints.

935
00:42:33,520 --> 00:42:38,400
It cannot easily validate the model now chooses this action more often because the host changed

936
00:42:38,400 --> 00:42:39,840
how it presents tools.

937
00:42:39,840 --> 00:42:44,560
Now MCP's value proposition in this comparison is narrower and therefore more durable.

938
00:42:44,560 --> 00:42:47,680
It standardizes the boundary between host and tool server.

939
00:42:47,680 --> 00:42:52,400
You can build a SharePoint MCP server once, with a stable contract and multiple hosts can

940
00:42:52,400 --> 00:42:53,400
consume it.

941
00:42:53,400 --> 00:42:57,760
IDE agents internal chat apps, whatever co-pilot surface comes next.

942
00:42:57,760 --> 00:43:02,200
The host experience can evolve without forcing you to rebuild the tool server every time.

943
00:43:02,200 --> 00:43:06,520
So the integration investment becomes less host shaped and more enterprise shaped.

944
00:43:06,520 --> 00:43:08,240
That distinction matters.

945
00:43:08,240 --> 00:43:11,000
But don't mistake open protocol for free.

946
00:43:11,000 --> 00:43:14,000
With MCP, you inherit responsibility for the boundary.

947
00:43:14,000 --> 00:43:17,320
You have to decide how discovery works inside your organization.

948
00:43:17,320 --> 00:43:19,880
You have to decide how you version tool schemers.

949
00:43:19,880 --> 00:43:22,280
You have to decide how you authenticate remote servers.

950
00:43:22,280 --> 00:43:25,320
You have to decide how you log and attribute tool calls.

951
00:43:25,320 --> 00:43:27,360
You have to decide what you will not allow.

952
00:43:27,360 --> 00:43:30,400
With a proprietary extension surface, Microsoft makes those calls for you.

953
00:43:30,400 --> 00:43:32,160
With MCP, you make them.

954
00:43:32,160 --> 00:43:34,160
Enterprises tend to pretend they want flexibility.

955
00:43:34,160 --> 00:43:35,160
They don't.

956
00:43:35,160 --> 00:43:36,480
They want survivability.

957
00:43:36,480 --> 00:43:38,280
So here's the practical trade.

958
00:43:38,280 --> 00:43:41,120
Propriatory co-pilot extensions maximize time to first demo.

959
00:43:41,120 --> 00:43:44,560
And MCP maximizes time to still working in two years.

960
00:43:44,560 --> 00:43:49,160
One optimizes for initial integration velocity inside Microsoft's ecosystem.

961
00:43:49,160 --> 00:43:53,440
The other optimizes for portability and governance across an ecosystem that won't stay still.

962
00:43:53,440 --> 00:43:55,200
Now the deeper issue, ecosystem effects.

963
00:43:55,200 --> 00:43:59,360
A proprietary extension model creates a winner takes most gravity well.

964
00:43:59,360 --> 00:44:04,160
Integration value accrues to the platform owner because the extensions are shaped to that platform.

965
00:44:04,160 --> 00:44:07,920
Tool vendors build where the users are and users stay where the tools are.

966
00:44:07,920 --> 00:44:08,600
It's efficient.

967
00:44:08,600 --> 00:44:10,960
It's also how lock-in becomes just the way things are.

968
00:44:10,960 --> 00:44:13,880
An open protocol like MCP flips that incentive.

969
00:44:13,880 --> 00:44:17,360
Tool builders target the protocol and host compete on experience.

970
00:44:17,360 --> 00:44:19,040
That's a different market structure.

971
00:44:19,040 --> 00:44:24,000
Less captured by any single client, more resilient to shifts in model providers and app surfaces.

972
00:44:24,000 --> 00:44:28,800
And yes, Microsoft can participate in that world while still running proprietary surfaces.

973
00:44:28,800 --> 00:44:29,480
That's the point.

974
00:44:29,480 --> 00:44:30,960
Protocols don't kill platforms.

975
00:44:30,960 --> 00:44:34,320
They limit how much the platform can trap you at the integration boundary.

976
00:44:34,320 --> 00:44:37,440
So if you're deciding where to standardize the rule is simple.

977
00:44:37,440 --> 00:44:40,560
Standardize at the boundary you can't afford to rebuild.

978
00:44:40,560 --> 00:44:44,200
If your business logic lives in the tool server, standardize that with MCP.

979
00:44:44,200 --> 00:44:47,400
If your differentiator is the host UX inside Microsoft 365,

980
00:44:47,400 --> 00:44:49,760
then use co-pilot extensions where they fit.

981
00:44:49,760 --> 00:44:53,600
But don't confuse those layers because the moment you build enterprise integrations,

982
00:44:53,600 --> 00:44:57,880
directly against the single host's extension model, you are not building AI capability.

983
00:44:57,880 --> 00:45:00,440
You're leasing it and lease terms change.

984
00:45:00,440 --> 00:45:04,360
Microsoft reference architecture where MCP sits in the stack.

985
00:45:04,360 --> 00:45:10,240
Now put all of this into a Microsoft shaped architecture because protocol only becomes real

986
00:45:10,240 --> 00:45:12,440
when you can point at a diagram and say,

987
00:45:12,440 --> 00:45:18,640
that box is where authority is enforced and this other box is where entropy leaks in.

988
00:45:18,640 --> 00:45:23,880
At a high level, an MCP enabled system in Microsoft land has five moving parts.

989
00:45:23,880 --> 00:45:28,400
The model, the host, the MCP client, the MCP server and the enterprise systems behind it.

990
00:45:28,400 --> 00:45:32,280
The model is boring by design as your open AI foundry models, whatever you're using.

991
00:45:32,280 --> 00:45:33,200
The model reasons.

992
00:45:33,200 --> 00:45:34,400
It does not execute.

993
00:45:34,400 --> 00:45:35,520
It does not authenticate.

994
00:45:35,520 --> 00:45:36,800
It does not own credentials.

995
00:45:36,800 --> 00:45:40,280
If you let the model become the actor, you're not building an agent system.

996
00:45:40,280 --> 00:45:41,600
You're building a breach narrative.

997
00:45:41,600 --> 00:45:43,800
The host is where the real power sits.

998
00:45:43,800 --> 00:45:44,800
This is your application.

999
00:45:44,800 --> 00:45:50,640
The co-pilot like chat surface, a team's app, a custom web app, an internal obsassistent

1000
00:45:50,640 --> 00:45:51,840
or an IDE agent.

1001
00:45:51,840 --> 00:45:55,720
The host is the only component allowed to see the full conversation and the user's intent

1002
00:45:55,720 --> 00:45:56,720
and to end.

1003
00:45:56,720 --> 00:45:57,880
That's not a convenience detail.

1004
00:45:57,880 --> 00:45:59,880
That's the privacy and governance boundary.

1005
00:45:59,880 --> 00:46:01,720
Inside the host lives the MCP client.

1006
00:46:01,720 --> 00:46:04,000
Think of it as the protocol adapter and session manager.

1007
00:46:04,000 --> 00:46:09,720
It negotiates capabilities with servers, lists tools, invokes tools and receives results.

1008
00:46:09,720 --> 00:46:13,960
But more importantly, it's the mechanism that allows the host to decide what the model

1009
00:46:13,960 --> 00:46:15,600
is even allowed to ask for.

1010
00:46:15,600 --> 00:46:18,320
This is the first Microsoft native reframe.

1011
00:46:18,320 --> 00:46:21,040
The host is an authorization broker.

1012
00:46:21,040 --> 00:46:22,280
Not an AI wrapper.

1013
00:46:22,280 --> 00:46:26,360
It decides which MCP servers are connected, which tools are exposed, which resources can

1014
00:46:26,360 --> 00:46:28,360
be fetched and what context gets forwarded.

1015
00:46:28,360 --> 00:46:33,480
In practice, it's the thing that turns user-aster question into a scoped attributable action

1016
00:46:33,480 --> 00:46:34,480
was executed.

1017
00:46:34,480 --> 00:46:36,800
Now the MCP server, this is the integration boundary.

1018
00:46:36,800 --> 00:46:41,720
It wraps enterprise systems, graph, sharepoint, secle, service, now, whatever, into a declared

1019
00:46:41,720 --> 00:46:43,320
set of capabilities.

1020
00:46:43,320 --> 00:46:47,320
These are your actions, resources are your context surfaces, prompts are your standardized

1021
00:46:47,320 --> 00:46:48,560
entry points.

1022
00:46:48,560 --> 00:46:52,640
And the server is where you translate messy backend reality into deterministic contracts

1023
00:46:52,640 --> 00:46:55,120
that a probabilistic caller can't ruin.

1024
00:46:55,120 --> 00:46:58,680
But don't confuse integration boundary with security boundary.

1025
00:46:58,680 --> 00:47:03,440
In Microsoft environments, security is enforced by identity plus policy, not by your Python

1026
00:47:03,440 --> 00:47:04,880
code behaving politely.

1027
00:47:04,880 --> 00:47:08,560
So the reference architecture needs explicit integration points that enterprises already

1028
00:47:08,560 --> 00:47:09,560
trust.

1029
00:47:09,560 --> 00:47:14,720
Enter ID. Every series deployment uses Entra to prove identities, issue tokens and express

1030
00:47:14,720 --> 00:47:15,720
least privilege.

1031
00:47:15,720 --> 00:47:17,520
The host authenticates the user.

1032
00:47:17,520 --> 00:47:21,920
The host then either calls the MCP server with a delegated token model or the MCP server

1033
00:47:21,920 --> 00:47:23,880
operates under a workload identity model.

1034
00:47:23,880 --> 00:47:27,840
We'll go deep on the token flows next, but for now, the architectural rule is simple.

1035
00:47:27,840 --> 00:47:31,560
Tool execution must map to an accountable principle and Entra is the only system that

1036
00:47:31,560 --> 00:47:33,840
can make that defensible at scale.

1037
00:47:33,840 --> 00:47:35,760
Second, Key Vault.

1038
00:47:35,760 --> 00:47:40,080
If your MCP server needs secrets for downstream APIs that aren't entrusted integrated for

1039
00:47:40,080 --> 00:47:44,080
certificates for legacy systems, Key Vault is where those secrets live.

1040
00:47:44,080 --> 00:47:47,920
Not in environment variables, not in app settings copied between environments, not in temporary

1041
00:47:47,920 --> 00:47:50,560
service principle secrets that never expire.

1042
00:47:50,560 --> 00:47:51,560
Key Vault isn't exciting.

1043
00:47:51,560 --> 00:47:54,520
It's where entropy goes to die if you actually use it.

1044
00:47:54,520 --> 00:47:56,520
Third, Azure API management.

1045
00:47:56,520 --> 00:47:58,560
This is where you put governance at the edge.

1046
00:47:58,560 --> 00:48:00,200
APM doesn't replace MCP.

1047
00:48:00,200 --> 00:48:01,200
It governs exposure.

1048
00:48:01,200 --> 00:48:02,560
It validates tokens.

1049
00:48:02,560 --> 00:48:06,520
And forces Quoters applies rate limits, does request transformation when needed and gives

1050
00:48:06,520 --> 00:48:07,760
you central logging.

1051
00:48:07,760 --> 00:48:11,680
Most importantly, it gives you a consistent place to say, this tool is allowed for these

1052
00:48:11,680 --> 00:48:16,120
callers from these networks at this rate with this retention and with this cost profile.

1053
00:48:16,120 --> 00:48:18,000
MCP standardizes tool invocation.

1054
00:48:18,000 --> 00:48:19,720
APM standardizes the consequences.

1055
00:48:19,720 --> 00:48:21,720
Fourth, logging and monitoring.

1056
00:48:21,720 --> 00:48:27,000
In a Microsoft stack that means Azure Monitor application insights, log analytics and then

1057
00:48:27,000 --> 00:48:28,440
Sentinel if you're serious.

1058
00:48:28,440 --> 00:48:31,200
The reference architecture should emit audit grade events.

1059
00:48:31,200 --> 00:48:36,760
Call name, input schema version, caller identity, correlation ID, downstream dependency calls

1060
00:48:36,760 --> 00:48:37,760
and outcome.

1061
00:48:37,760 --> 00:48:41,600
If you can't answer who did what in one query, you built a demo, not a platform.

1062
00:48:41,600 --> 00:48:44,600
Now, place enterprise systems behind the MCP server.

1063
00:48:44,600 --> 00:48:49,000
SharePoint and graph databases, line of business APIs, even legacy soap endpoints.

1064
00:48:49,000 --> 00:48:53,320
The point is that MCP servers are adapters with contracts, not direct pipes.

1065
00:48:53,320 --> 00:48:55,160
You're not exposing your raw back end.

1066
00:48:55,160 --> 00:48:57,840
You're exposing an intentional capability surface.

1067
00:48:57,840 --> 00:48:59,840
So the stack looks like this.

1068
00:48:59,840 --> 00:49:01,680
Azure Interacts with host.

1069
00:49:01,680 --> 00:49:05,440
Host authenticates with Entra, model reasons within the host.

1070
00:49:05,440 --> 00:49:11,640
Host invokes MCP tools via MCP client, MCP server enforces its contract, APIM and Entra

1071
00:49:11,640 --> 00:49:13,120
enforce policy.

1072
00:49:13,120 --> 00:49:15,920
Backends do the work, telemetry proves what happened.

1073
00:49:15,920 --> 00:49:19,520
And the next question is the only one that matters, which identity is actually holding

1074
00:49:19,520 --> 00:49:25,120
the knife when a tool runs identity flow one, Entra on behalf of delegated authority,

1075
00:49:25,120 --> 00:49:26,960
not LLM God mode.

1076
00:49:26,960 --> 00:49:30,880
So answer the knife question, when a tool runs whose authority is it using?

1077
00:49:30,880 --> 00:49:34,560
If you can't say that in one sentence, you don't have an AI architecture.

1078
00:49:34,560 --> 00:49:35,960
You have a liability generator.

1079
00:49:35,960 --> 00:49:39,360
The cleanest place to start is Entra on behalf of.

1080
00:49:39,360 --> 00:49:42,000
Because it forces a truth enterprises love to avoid.

1081
00:49:42,000 --> 00:49:45,720
Most AI integrations quietly run as an app with broad permissions.

1082
00:49:45,720 --> 00:49:49,640
And then everyone acts surprised when it behaves like an app with broad permissions.

1083
00:49:49,640 --> 00:49:52,840
On behalf of is the opposite, it's delegated authority.

1084
00:49:52,840 --> 00:49:56,920
It's the platform saying, the user is the actor, the application is the broker.

1085
00:49:56,920 --> 00:50:02,680
And the downstream call must remain attributable to the user's permissions and the user's context.

1086
00:50:02,680 --> 00:50:03,680
That distinction matters.

1087
00:50:03,680 --> 00:50:05,400
Here's the core idea in plain terms.

1088
00:50:05,400 --> 00:50:06,920
The user signs into the host.

1089
00:50:06,920 --> 00:50:09,640
The host gets a user token from Entra.

1090
00:50:09,640 --> 00:50:14,480
Then when the host wants to call an MCP server, it passes a token or a proof of user identity

1091
00:50:14,480 --> 00:50:15,480
to that server.

1092
00:50:15,480 --> 00:50:18,480
The MCP server doesn't just reuse that token blindly.

1093
00:50:18,480 --> 00:50:24,160
It exchanges it using the OBO flow to obtain a new access token for the downstream API,

1094
00:50:24,160 --> 00:50:27,480
like Microsoft Graph, scope for the user and for the specific audience.

1095
00:50:27,480 --> 00:50:28,840
So the sequence is simple.

1096
00:50:28,840 --> 00:50:30,640
User authenticates to the host.

1097
00:50:30,640 --> 00:50:32,400
Host receives a delegated token.

1098
00:50:32,400 --> 00:50:35,560
MCP server exchanges that token on behalf of the user.

1099
00:50:35,560 --> 00:50:40,200
MCP server calls Graph or SharePoint with a delegated token representing the user.

1100
00:50:40,200 --> 00:50:41,200
And the result comes back.

1101
00:50:41,200 --> 00:50:43,120
What this buys you is not security theater.

1102
00:50:43,120 --> 00:50:45,320
It buys you scope trimming as architecture.

1103
00:50:45,320 --> 00:50:47,680
Because delegated tokens carry scopes.

1104
00:50:47,680 --> 00:50:49,560
Scopes are the contract of least privilege.

1105
00:50:49,560 --> 00:50:53,560
When the tool is list documents in this site, the server requests the specific graph scopes

1106
00:50:53,560 --> 00:50:54,560
it needs.

1107
00:50:54,560 --> 00:50:58,640
And Entra enforces whether that user has consented, whether the tenant allows it and whether

1108
00:50:58,640 --> 00:51:00,400
policy conditions apply.

1109
00:51:00,400 --> 00:51:02,040
The model never gets got mode.

1110
00:51:02,040 --> 00:51:05,040
The model gets a request path that can be denied.

1111
00:51:05,040 --> 00:51:07,200
And that denial is a feature, not an outage.

1112
00:51:07,200 --> 00:51:08,800
Now the part people get wrong.

1113
00:51:08,800 --> 00:51:11,840
OBO is not about letting the model do user stuff.

1114
00:51:11,840 --> 00:51:13,560
It's about preserving accountability.

1115
00:51:13,560 --> 00:51:18,560
If an MCP tool uses OBO, your audit trail can say, "This action happened because this

1116
00:51:18,560 --> 00:51:24,040
user asked for it through this host and the downstream system evaluated the user's own permissions."

1117
00:51:24,040 --> 00:51:27,800
That's how you survive incident review, because the question will be who did it, not which

1118
00:51:27,800 --> 00:51:29,040
model suggested it.

1119
00:51:29,040 --> 00:51:33,600
And if your tools run under app only permissions, your answer becomes the service principle,

1120
00:51:33,600 --> 00:51:35,720
which is another way of saying nobody.

1121
00:51:35,720 --> 00:51:40,600
OBO is also the clean way to separate knowledge access from action authority without inventing

1122
00:51:40,600 --> 00:51:41,760
custom logic.

1123
00:51:41,760 --> 00:51:44,880
If the user can read a document in SharePoint, Graph will allow the call.

1124
00:51:44,880 --> 00:51:49,160
If the user can't graph will deny it, your MCP server doesn't have to become a parallel authorization

1125
00:51:49,160 --> 00:51:50,160
system.

1126
00:51:50,160 --> 00:51:53,920
It becomes an integration boundary that respects the enterprise authorization engine.

1127
00:51:53,920 --> 00:51:55,880
Entra and graph remain the decision engine.

1128
00:51:55,880 --> 00:51:58,280
Your server becomes a translator, not a judge.

1129
00:51:58,280 --> 00:52:00,840
Now the failure modes, because OBO is not magic.

1130
00:52:00,840 --> 00:52:02,960
First consent and permissions sprawl.

1131
00:52:02,960 --> 00:52:06,120
OBO requires that your app is configured with the right delegated permissions and that

1132
00:52:06,120 --> 00:52:08,280
admin consent is handled intentionally.

1133
00:52:08,280 --> 00:52:11,920
If you treat admin consent as just make it work, you reintroduce the same entropy you

1134
00:52:11,920 --> 00:52:15,080
were trying to eliminate, just earlier in the life cycle.

1135
00:52:15,080 --> 00:52:16,280
Second token handling.

1136
00:52:16,280 --> 00:52:19,240
The host must not leak user tokens into places they don't belong.

1137
00:52:19,240 --> 00:52:24,200
If you forward user tokens to random downstream systems or third party MCP servers, you've turned

1138
00:52:24,200 --> 00:52:28,040
your delegated model into a portable credential theft mechanism.

1139
00:52:28,040 --> 00:52:32,080
Third conditional access, this is where Microsoft environments get serious.

1140
00:52:32,080 --> 00:52:36,240
Conditional access might require compliant devices, specific locations or MFA for certain

1141
00:52:36,240 --> 00:52:37,240
resources.

1142
00:52:37,240 --> 00:52:38,320
OBO doesn't bypass that.

1143
00:52:38,320 --> 00:52:39,320
It inherits it.

1144
00:52:39,320 --> 00:52:42,800
It's good because it means your tool execution respects the same risk posture as the rest

1145
00:52:42,800 --> 00:52:47,440
of the tenant, but it also means your tool calls can fail for reasons that look non-technical

1146
00:52:47,440 --> 00:52:48,440
to developers.

1147
00:52:48,440 --> 00:52:49,840
They aren't non-technical.

1148
00:52:49,840 --> 00:52:51,120
They're policy doing its job.

1149
00:52:51,120 --> 00:52:55,200
So if you implement OBO, you need to design for denial, clear error mapping, fail closed

1150
00:52:55,200 --> 00:52:59,840
behavior and user visible explanations that don't leak sensitive policy detail.

1151
00:52:59,840 --> 00:53:02,280
Because access denied is a correct outcome.

1152
00:53:02,280 --> 00:53:03,760
And that's the takeaway.

1153
00:53:03,760 --> 00:53:08,880
OBO turns MCP tool execution into delegated authority with auditability, scope trimming

1154
00:53:08,880 --> 00:53:10,200
and policy inheritance.

1155
00:53:10,200 --> 00:53:14,520
It is the closest thing you get to a deterministic security model in a probabilistic tool selection

1156
00:53:14,520 --> 00:53:15,520
world.

1157
00:53:15,520 --> 00:53:17,200
Now the uncomfortable contrast.

1158
00:53:17,200 --> 00:53:22,400
Same MCP tool surface, different blast radius when you switch to managed identity.

1159
00:53:22,400 --> 00:53:23,520
Identity flow 2.

1160
00:53:23,520 --> 00:53:26,760
Managed identity plus Microsoft graph, the operational baseline.

1161
00:53:26,760 --> 00:53:31,200
Now take the same idea, an MCP server calling Microsoft Graph and remove the user.

1162
00:53:31,200 --> 00:53:32,720
That's the managed identity pattern.

1163
00:53:32,720 --> 00:53:36,440
This is the operational baseline because it matches how Azure is supposed to work, workloads

1164
00:53:36,440 --> 00:53:38,000
authenticate as workloads.

1165
00:53:38,000 --> 00:53:42,800
No secrets, no copied client secrets in app settings, no temporary certificates that become

1166
00:53:42,800 --> 00:53:45,440
permanent because nobody owns rotation.

1167
00:53:45,440 --> 00:53:50,320
Just a resource in Azure with an identity asking entra for a token and calling graph.

1168
00:53:50,320 --> 00:53:51,520
Clean.

1169
00:53:51,520 --> 00:53:54,800
But don't confuse clean with equivalent to OBO.

1170
00:53:54,800 --> 00:53:55,800
It isn't.

1171
00:53:55,800 --> 00:53:59,280
The authority model is different and that changes everything about accountability.

1172
00:53:59,280 --> 00:54:01,600
With managed identity, the principle is the workload.

1173
00:54:01,600 --> 00:54:03,160
The MCP server is the actor.

1174
00:54:03,160 --> 00:54:07,440
So when the host invokes a tool and the tool ends up calling graph, the downstream system

1175
00:54:07,440 --> 00:54:09,680
sees an app identity, not a user identity.

1176
00:54:09,680 --> 00:54:13,600
And that means the audit question changes from which user did this and to which workload

1177
00:54:13,600 --> 00:54:15,200
did this and that can be acceptable.

1178
00:54:15,200 --> 00:54:16,720
Sometimes it's the correct model.

1179
00:54:16,720 --> 00:54:20,320
The right use cases are the boring ones that keep enterprises alive.

1180
00:54:20,320 --> 00:54:24,320
Background indexing, scheduled classification, metadata normalization,

1181
00:54:24,320 --> 00:54:29,120
nightly reports, content inventory and controlled automation that's explicitly not user-driven.

1182
00:54:29,120 --> 00:54:30,080
You're building a service.

1183
00:54:30,080 --> 00:54:31,920
The service should have a service identity.

1184
00:54:31,920 --> 00:54:36,000
This is also why managed identity is the baseline for shared MCP servers.

1185
00:54:36,000 --> 00:54:40,080
If your organization wants a centrally hosted SharePoint Graph MCP server

1186
00:54:40,080 --> 00:54:44,240
that multiple hosts can use Teams Assistance internal chat apps, dev tooling,

1187
00:54:44,240 --> 00:54:47,920
managed identity is the simplest identity story that doesn't involve

1188
00:54:47,920 --> 00:54:50,960
the user token forwarding across every client.

1189
00:54:50,960 --> 00:54:52,560
Mechanically, it looks like this.

1190
00:54:52,560 --> 00:54:56,800
The MCP server runs on an Azure host that supports managed identity, functions,

1191
00:54:56,800 --> 00:54:59,760
container apps, AKS with workload identity, whatever.

1192
00:54:59,760 --> 00:55:02,960
The server requests an access token from Entra for the Microsoft Graph audience.

1193
00:55:02,960 --> 00:55:04,320
It calls graph with that token.

1194
00:55:04,320 --> 00:55:08,720
Graph evaluates app permissions and directory roles assigned to that managed identity.

1195
00:55:08,720 --> 00:55:10,160
The call succeeds or fails.

1196
00:55:10,160 --> 00:55:12,640
The server returns a deterministic response to the host.

1197
00:55:12,640 --> 00:55:14,800
No user tokens ever cross that boundary.

1198
00:55:14,800 --> 00:55:15,680
And that's the benefit.

1199
00:55:15,680 --> 00:55:20,560
Fewer moving parts, fewer consent flows, fewer conditional access surprises tied to user posture.

1200
00:55:20,560 --> 00:55:23,280
The system behaves like any other server to server integration.

1201
00:55:23,280 --> 00:55:24,160
But there's a price.

1202
00:55:24,160 --> 00:55:26,480
You lose user-level accountability by default.

1203
00:55:26,480 --> 00:55:29,440
If a tool mutates data, create a Teams message,

1204
00:55:29,440 --> 00:55:32,560
update a SharePoint list item, modify permissions.

1205
00:55:32,560 --> 00:55:37,520
You've just created an action surface that is not naturally attributable to the user who asked for it.

1206
00:55:37,520 --> 00:55:39,040
You can add your own logging, of course.

1207
00:55:39,040 --> 00:55:42,240
You can stamp "requested by user x" into telemetry.

1208
00:55:42,240 --> 00:55:45,200
But that is not the same as graph enforcing user permissions.

1209
00:55:45,200 --> 00:55:46,800
It's your app asserting a story.

1210
00:55:46,800 --> 00:55:50,640
And incident reviews don't accept the app says so as a strong boundary.

1211
00:55:50,640 --> 00:55:54,240
So the correct pattern is to treat managed identity as operational authority,

1212
00:55:54,240 --> 00:55:55,440
not delegated authority.

1213
00:55:55,440 --> 00:55:56,880
Keep the tools read heavy.

1214
00:55:56,880 --> 00:56:01,680
Keep the mutation tools rare, narrow, and gated behind explicit approvals in the host.

1215
00:56:01,680 --> 00:56:06,400
And never pretend that because the user asked means the user is accountable

1216
00:56:06,400 --> 00:56:07,920
when the token is app-only.

1217
00:56:07,920 --> 00:56:12,240
Now the failure mode, this is where managed identity turns into silent privilege expansion.

1218
00:56:12,240 --> 00:56:15,440
Because it's so easy, a team needs one more graph capability.

1219
00:56:15,440 --> 00:56:18,240
They add one more application permission, everything works.

1220
00:56:18,240 --> 00:56:21,680
Then another team needs another capability, another permission.

1221
00:56:21,680 --> 00:56:24,880
Then six months later, your managed identity has broad read access

1222
00:56:24,880 --> 00:56:29,360
across male files, users, groups, sites because every request was individually reasonable.

1223
00:56:29,360 --> 00:56:31,520
And collectively, it became a super user.

1224
00:56:31,520 --> 00:56:34,000
That's how security that grows in Microsoft environments,

1225
00:56:34,000 --> 00:56:36,240
not through one catastrophic misconfiguration,

1226
00:56:36,240 --> 00:56:39,760
but through cumulative permission accretion that nobody revisits.

1227
00:56:39,760 --> 00:56:41,520
Managed identity doesn't prevent that.

1228
00:56:41,520 --> 00:56:43,840
It accelerates it because it feels safe.

1229
00:56:43,840 --> 00:56:46,480
So if you use managed identity for MCP servers,

1230
00:56:46,480 --> 00:56:49,360
you enforce three disciplines, first explicit scoping.

1231
00:56:49,360 --> 00:56:51,840
Prefer graph application permissions that are narrow

1232
00:56:51,840 --> 00:56:54,960
and when possible, scope access to specific sites or resources,

1233
00:56:54,960 --> 00:56:56,080
rather than tenant-wide.

1234
00:56:56,080 --> 00:56:59,040
Don't build a tenant reader identity unless you actually mean it.

1235
00:56:59,040 --> 00:57:00,640
Second, road separation.

1236
00:57:00,640 --> 00:57:03,520
Don't run every MCP server under one identity.

1237
00:57:03,520 --> 00:57:06,080
Different tool surfaces get different identities.

1238
00:57:06,080 --> 00:57:09,360
Read only servers and write capable servers do not share principles.

1239
00:57:09,360 --> 00:57:11,680
Shared principles are entropy generators.

1240
00:57:11,680 --> 00:57:13,840
Third, audit as architecture.

1241
00:57:13,840 --> 00:57:16,320
Every tool call emits a structured event.

1242
00:57:16,320 --> 00:57:20,880
Two name parameters, graph endpoint called result, correlation ID,

1243
00:57:20,880 --> 00:57:22,560
and the calling host identity.

1244
00:57:22,560 --> 00:57:24,640
That's the minimum bar for survivability.

1245
00:57:24,640 --> 00:57:28,880
So managed identity is the baseline because it's operationally sane and agonative.

1246
00:57:28,880 --> 00:57:31,040
But it is not a free substitute for OBO.

1247
00:57:31,040 --> 00:57:33,840
It's the same tools, the same server, the same graph calls,

1248
00:57:33,840 --> 00:57:35,680
and a completely different blast radius.

1249
00:57:35,680 --> 00:57:37,120
Identity flow three.

1250
00:57:37,120 --> 00:57:40,160
Service principle plus azure API management.

1251
00:57:40,160 --> 00:57:41,440
Governance at the edge.

1252
00:57:41,440 --> 00:57:44,720
Now take the managed identity pattern and make it enterprise scale on purposes.

1253
00:57:44,720 --> 00:57:48,240
Because managed identity answers how does the workload authenticate?

1254
00:57:48,240 --> 00:57:50,480
But it doesn't answer how do we govern exposure

1255
00:57:50,480 --> 00:57:53,040
when the caller is multiplying the traffic turns bursty?

1256
00:57:53,040 --> 00:57:56,560
That's where the service principle plus azure API management pattern shows up.

1257
00:57:56,560 --> 00:57:57,600
Not because it's trendy.

1258
00:57:57,600 --> 00:58:00,480
Because it's the only place you can consistently enforce policy

1259
00:58:00,480 --> 00:58:02,720
when the tool surface becomes a shared utility.

1260
00:58:02,720 --> 00:58:03,680
Here's the shape.

1261
00:58:03,680 --> 00:58:06,080
Your MCP server is still the integration boundary.

1262
00:58:06,080 --> 00:58:08,320
It still exposes tools, resources, and prompts.

1263
00:58:08,320 --> 00:58:10,880
But you don't let random host caller directly.

1264
00:58:10,880 --> 00:58:13,120
You put azure API management in front of it

1265
00:58:13,120 --> 00:58:15,440
and you treat APM as the enforcement layer.

1266
00:58:15,440 --> 00:58:19,360
Validate tokens, apply throttles, do quota, log everything,

1267
00:58:19,360 --> 00:58:22,800
and reject anything that doesn't match your policy posture.

1268
00:58:22,800 --> 00:58:25,120
In this pattern, the caller is a service principle.

1269
00:58:25,120 --> 00:58:26,800
That might be the host application itself

1270
00:58:26,800 --> 00:58:30,320
or it might be a broker component that fronts multiple hosts.

1271
00:58:30,320 --> 00:58:33,280
Either way, it's app to app auth client credentials,

1272
00:58:33,280 --> 00:58:36,400
deterministic, boring, which is what you want at the edge.

1273
00:58:36,400 --> 00:58:40,320
And before anyone panics about service principle equals broad permissions,

1274
00:58:40,320 --> 00:58:42,560
separate two concerns that people keep mixing.

1275
00:58:42,560 --> 00:58:45,120
The service principle is for calling the MCP server.

1276
00:58:45,120 --> 00:58:48,480
The MCP server's downstream identity is a separate decision.

1277
00:58:48,480 --> 00:58:52,080
The server can still use OBO for user delegated operations

1278
00:58:52,080 --> 00:58:54,320
or manage identity for operational calls

1279
00:58:54,320 --> 00:58:57,200
or even a different app identity for downstream systems.

1280
00:58:57,200 --> 00:58:59,600
APM doesn't force one model. It forces one entrance.

1281
00:58:59,600 --> 00:59:00,240
That's the point.

1282
00:59:00,240 --> 00:59:02,320
APM is where you standardize the gate,

1283
00:59:02,320 --> 00:59:04,640
not where you collapse all identities into one blob.

1284
00:59:04,640 --> 00:59:06,640
So what does APM actually give you that matters

1285
00:59:06,640 --> 00:59:07,840
in an MCP world?

1286
00:59:07,840 --> 00:59:10,640
First, authentication and authorization at the boundary.

1287
00:59:10,640 --> 00:59:16,000
APM can validate Entra-issue JWTs and force issuer, audience, and claims

1288
00:59:16,000 --> 00:59:18,400
and reject callers that aren't who they claim to be.

1289
00:59:18,400 --> 00:59:19,520
And because it's centralized,

1290
00:59:19,520 --> 00:59:21,840
you don't end up with every MCP server team

1291
00:59:21,840 --> 00:59:25,600
implemented else differently. That inconsistency is where breach is hide.

1292
00:59:25,600 --> 00:59:27,600
Second, throttling and quotas.

1293
00:59:27,600 --> 00:59:29,360
Agent traffic is not normal traffic.

1294
00:59:29,360 --> 00:59:32,080
It is spiky, recursive, and sometimes stupid.

1295
00:59:32,080 --> 00:59:35,520
When a model hits a transient error, the agent loop tends to retry.

1296
00:59:35,520 --> 00:59:38,560
When a tool call is slow, the model tends to try alternate tools.

1297
00:59:38,560 --> 00:59:40,800
When you expose 10 tools, you don't get 10 calls.

1298
00:59:40,800 --> 00:59:42,000
You get call cascades.

1299
00:59:42,000 --> 00:59:45,840
APM is where you stop that from turning into a back end denial of service

1300
00:59:45,840 --> 00:59:47,040
you did to yourself.

1301
00:59:47,040 --> 00:59:49,280
Rate limits per client. Quotas per time period.

1302
00:59:49,280 --> 00:59:50,240
Verse control.

1303
00:59:50,240 --> 00:59:54,240
And if you want to be sane, you enforce different limits per tool category.

1304
00:59:54,240 --> 00:59:56,320
Read tools get higher throughput.

1305
00:59:56,320 --> 00:59:57,920
Write tools get tighter limits.

1306
00:59:57,920 --> 01:00:02,160
And expensive tools get explicit quotas tied to cost centers.

1307
01:00:02,160 --> 01:00:04,000
Third, transformation and normalization.

1308
01:00:04,000 --> 01:00:06,080
This is not about making JSON pretty.

1309
01:00:06,080 --> 01:00:07,760
It's about enforcing stable contracts.

1310
01:00:07,760 --> 01:00:09,360
If your MCP server evolves,

1311
01:00:09,360 --> 01:00:13,040
APM can help you keep a stable external surface while you transition

1312
01:00:13,040 --> 01:00:13,920
internals.

1313
01:00:13,920 --> 01:00:15,040
Version routing,

1314
01:00:15,040 --> 01:00:16,640
header-based feature flags,

1315
01:00:16,640 --> 01:00:18,800
or even schema validation if you go that far.

1316
01:00:19,600 --> 01:00:21,680
Enterprises don't want surprises.

1317
01:00:21,680 --> 01:00:23,120
They want managed change.

1318
01:00:23,120 --> 01:00:27,200
Fourth, observability and audit trails that don't require you to stitch logs

1319
01:00:27,200 --> 01:00:28,480
from every app team.

1320
01:00:28,480 --> 01:00:31,680
APM gives you a single choke point where every request and response

1321
01:00:31,680 --> 01:00:34,480
can be logged with correlation IDs and client identity.

1322
01:00:34,480 --> 01:00:37,680
You still need application-level logs inside the MCP server,

1323
01:00:37,680 --> 01:00:41,520
but APM becomes the authoritative record of who called what when.

1324
01:00:41,520 --> 01:00:44,080
And that matters because MCP is a tool protocol.

1325
01:00:44,080 --> 01:00:45,520
Tool calls are actions.

1326
01:00:45,520 --> 01:00:46,800
Actions require attribution.

1327
01:00:46,800 --> 01:00:48,800
Attribution requires a reliable ledger.

1328
01:00:48,800 --> 01:00:52,160
Now, the uncomfortable boundary question, where does MCP end?

1329
01:00:52,160 --> 01:00:54,880
MCP standardizes how tools are described and invoked.

1330
01:00:54,880 --> 01:00:57,040
It does not standardize enterprise governance.

1331
01:00:57,040 --> 01:00:58,640
It doesn't enforce your rate limits.

1332
01:00:58,640 --> 01:01:00,560
It doesn't implement your tenant restrictions.

1333
01:01:00,560 --> 01:01:01,840
It doesn't control your budgets.

1334
01:01:01,840 --> 01:01:03,600
It doesn't decide what allowed means.

1335
01:01:03,600 --> 01:01:06,160
APM is where those enterprise controls live.

1336
01:01:06,160 --> 01:01:07,680
So the clean framing is this.

1337
01:01:07,680 --> 01:01:09,840
MCP is the tool invocation protocol.

1338
01:01:09,840 --> 01:01:11,760
APM is the policy engine at the edge.

1339
01:01:11,760 --> 01:01:15,440
Entra is the identity issuer and authorization substrate.

1340
01:01:15,440 --> 01:01:18,160
And your MCP server is the translator that keeps back-end

1341
01:01:18,160 --> 01:01:21,040
complexity from leaking into a probabilistic caller.

1342
01:01:21,040 --> 01:01:24,240
Once you have this pattern, you can finally answer the CFO question

1343
01:01:24,240 --> 01:01:27,200
and the incident reviewer question with the same architecture.

1344
01:01:27,200 --> 01:01:28,640
How do we control cost?

1345
01:01:28,640 --> 01:01:30,080
How do we prove accountability?

1346
01:01:30,080 --> 01:01:31,520
Because the edge is governable.

1347
01:01:31,520 --> 01:01:33,840
Now, we can build the SharePoint and Graph MCP server

1348
01:01:33,840 --> 01:01:35,920
without pretending the boundary will take care of itself.

1349
01:01:35,920 --> 01:01:38,000
Hands-on anchor.

1350
01:01:38,000 --> 01:01:41,120
Designing the SharePoint+ Graph MCP server.

1351
01:01:41,120 --> 01:01:43,760
Now, we stop talking about protocols like their philosophy

1352
01:01:43,760 --> 01:01:44,880
and we build one.

1353
01:01:44,880 --> 01:01:46,800
Not a toy Hello World MCP server.

1354
01:01:47,600 --> 01:01:50,640
A SharePoint+ Microsoft Graph MCP server

1355
01:01:50,640 --> 01:01:53,440
that survives contact with an enterprise tenant.

1356
01:01:53,440 --> 01:01:55,360
SharePoint is the perfect trap for this

1357
01:01:55,360 --> 01:01:57,840
because it looks simple until you ask one question.

1358
01:01:57,840 --> 01:01:58,880
Who can see what?

1359
01:01:58,880 --> 01:02:00,880
Then you realize permissions aren't a boolean.

1360
01:02:00,880 --> 01:02:02,640
They're an inheritance graph.

1361
01:02:02,640 --> 01:02:04,560
With exceptions, broken inheritance,

1362
01:02:04,560 --> 01:02:07,120
sharing links, guest access, sensitivity labels,

1363
01:02:07,120 --> 01:02:09,120
and whatever else the organization bolted on

1364
01:02:09,120 --> 01:02:11,280
during the last five reorganizations.

1365
01:02:11,280 --> 01:02:13,200
That is exactly why this is the right anchor.

1366
01:02:13,200 --> 01:02:15,360
If you can make MCP behave in SharePoint,

1367
01:02:15,360 --> 01:02:16,800
you can make it behave anywhere.

1368
01:02:16,800 --> 01:02:18,560
So the first architectural decision is not

1369
01:02:18,560 --> 01:02:20,800
what language you use or where you host it.

1370
01:02:20,800 --> 01:02:23,840
It's how you draw the boundary between context and authority

1371
01:02:23,840 --> 01:02:25,920
because SharePoint makes it painfully obvious

1372
01:02:25,920 --> 01:02:27,120
when you get that wrong.

1373
01:02:27,120 --> 01:02:28,320
Start with the server contract.

1374
01:02:28,320 --> 01:02:29,440
What resources exist?

1375
01:02:29,440 --> 01:02:30,240
What tools exist?

1376
01:02:30,240 --> 01:02:31,360
And what prompts exist?

1377
01:02:31,360 --> 01:02:33,520
Resources come first because if your MCP server

1378
01:02:33,520 --> 01:02:36,400
can't supply stable contacts, the model will improvise.

1379
01:02:36,400 --> 01:02:38,000
An improvisation inside SharePoint

1380
01:02:38,000 --> 01:02:39,520
turns into open the wrong document

1381
01:02:39,520 --> 01:02:41,040
and summarise it confidently.

1382
01:02:41,040 --> 01:02:43,280
So define read-oriented resources

1383
01:02:43,280 --> 01:02:45,280
that are predictable and low-risk.

1384
01:02:45,280 --> 01:02:48,000
A resource for site metadata is a good example.

1385
01:02:48,000 --> 01:02:50,960
Site ID, Site URL, Display Name,

1386
01:02:50,960 --> 01:02:53,920
Classification, Sensitivity Label if available,

1387
01:02:53,920 --> 01:02:56,640
and maybe the default document library identifiers.

1388
01:02:56,640 --> 01:02:59,280
Not the documents themselves, metadata first.

1389
01:02:59,280 --> 01:03:03,680
A resource for permission context is even more important.

1390
01:03:03,680 --> 01:03:06,480
Whether the caller is using OBO or app only,

1391
01:03:06,480 --> 01:03:07,840
which identity is active,

1392
01:03:07,840 --> 01:03:09,680
and what scope is being requested.

1393
01:03:09,680 --> 01:03:11,440
This isn't for the model's curiosity,

1394
01:03:11,440 --> 01:03:12,480
it's for determinism.

1395
01:03:12,480 --> 01:03:16,080
If the host and server can fetch a small structured permission context,

1396
01:03:16,080 --> 01:03:20,080
the host can decide whether to allow downstream tool calls without guessing.

1397
01:03:20,080 --> 01:03:22,880
A resource for content types and columns is also valuable

1398
01:03:22,880 --> 01:03:25,920
because in SharePoint, list data without schema is just noise.

1399
01:03:25,920 --> 01:03:27,600
Give the model stable names for fields,

1400
01:03:27,600 --> 01:03:29,280
expected types, and allowed values.

1401
01:03:29,280 --> 01:03:31,680
Otherwise, it will hallucinate a column called status

1402
01:03:31,680 --> 01:03:33,120
because every system has a status

1403
01:03:33,120 --> 01:03:35,280
and then your tool call fails and the loop retries

1404
01:03:35,280 --> 01:03:36,960
until your back end hates you.

1405
01:03:36,960 --> 01:03:38,080
Now tools.

1406
01:03:38,080 --> 01:03:39,680
Tools are where the damage happens,

1407
01:03:39,680 --> 01:03:42,160
so tools need strict schemas and narrow meaning.

1408
01:03:42,480 --> 01:03:44,080
Avoid the generic search.

1409
01:03:44,080 --> 01:03:45,520
SharePoint search is not one thing.

1410
01:03:45,520 --> 01:03:48,480
It's multiple things with different authorization surfaces

1411
01:03:48,480 --> 01:03:50,160
and different failure modes.

1412
01:03:50,160 --> 01:03:52,960
So instead, define tools with explicit scope and intent.

1413
01:03:52,960 --> 01:03:55,920
A tool like SharePoint search documents inside

1414
01:03:55,920 --> 01:03:58,080
with required site id and query text,

1415
01:03:58,080 --> 01:04:01,040
plus optional filters that you explicitly constrain,

1416
01:04:01,040 --> 01:04:03,440
file type, modified after, author,

1417
01:04:03,440 --> 01:04:05,840
upan, sensitivity label, top.

1418
01:04:05,840 --> 01:04:07,680
No freeform filters object.

1419
01:04:07,680 --> 01:04:09,920
You want schema discipline, not creativity.

1420
01:04:09,920 --> 01:04:13,040
A tool like SharePoint tag get document metadata

1421
01:04:13,040 --> 01:04:16,080
takes a stable identifier, returns stable fields,

1422
01:04:16,080 --> 01:04:18,240
and never returns full content by default.

1423
01:04:18,240 --> 01:04:20,880
If you want content, you make that a separate tool.

1424
01:04:20,880 --> 01:04:24,640
SharePoint get document content with explicit max bytes

1425
01:04:24,640 --> 01:04:26,720
and the host must enforce policy around it.

1426
01:04:26,720 --> 01:04:30,880
A tool like graph list user groups is a trap

1427
01:04:30,880 --> 01:04:33,360
unless you tightly scope why it exists.

1428
01:04:33,360 --> 01:04:34,480
In an enterprise tenant,

1429
01:04:34,480 --> 01:04:36,480
enumerating group membership is sensitive,

1430
01:04:36,480 --> 01:04:39,040
so if you need it, constrain it to a specific purpose.

1431
01:04:39,040 --> 01:04:42,320
Graph check user access to site where the server answers a yes,

1432
01:04:42,320 --> 01:04:45,760
no plus evidence fields instead of dumping raw group data.

1433
01:04:45,760 --> 01:04:47,920
Then prompts are templates that standardize

1434
01:04:47,920 --> 01:04:49,760
how humans invoke common workflows.

1435
01:04:49,760 --> 01:04:51,760
For SharePoint, the obvious ones are things like

1436
01:04:51,760 --> 01:04:53,680
review this document for policy compliance

1437
01:04:53,680 --> 01:04:56,160
or summarize changes since last week for this site.

1438
01:04:56,160 --> 01:04:57,600
But you keep prompts honest.

1439
01:04:57,600 --> 01:05:00,320
They don't grant permissions, they don't bypass approval

1440
01:05:00,320 --> 01:05:02,400
and they don't magically solve injection.

1441
01:05:02,400 --> 01:05:03,840
They just reduce human drift.

1442
01:05:03,840 --> 01:05:05,600
Now the identity model ties it together.

1443
01:05:05,600 --> 01:05:07,760
If the host uses oboe, your tools operate

1444
01:05:07,760 --> 01:05:10,320
under user delegated access and SharePoint and graph

1445
01:05:10,320 --> 01:05:11,840
become the enforcement engines.

1446
01:05:11,840 --> 01:05:13,760
If the host uses managed identity,

1447
01:05:13,760 --> 01:05:16,240
your tools must be scoped to operational tasks

1448
01:05:16,240 --> 01:05:18,480
and your server must log attribution explicitly

1449
01:05:18,480 --> 01:05:20,080
because graph won't do it for you.

1450
01:05:20,080 --> 01:05:22,000
If you front the whole thing with APM,

1451
01:05:22,000 --> 01:05:24,000
you get rate control and a ledger of calls

1452
01:05:24,000 --> 01:05:25,600
that doesn't depend on every developer

1453
01:05:25,600 --> 01:05:27,040
remembering to instrument,

1454
01:05:27,040 --> 01:05:29,600
finally you define what fail closed means.

1455
01:05:29,600 --> 01:05:31,520
If the tool can't prove site scope,

1456
01:05:31,520 --> 01:05:32,880
it refuses the call.

1457
01:05:32,880 --> 01:05:35,360
If a document is overshared or unlabeled

1458
01:05:35,360 --> 01:05:37,360
and your policy requires classification,

1459
01:05:37,360 --> 01:05:38,720
the tool refuses the call.

1460
01:05:38,720 --> 01:05:40,000
If the query is ambiguous,

1461
01:05:40,000 --> 01:05:41,360
the tool refuses the call

1462
01:05:41,360 --> 01:05:43,600
and forces illicitation through the host.

1463
01:05:43,600 --> 01:05:46,400
This is the real value of MCP in Microsoft land.

1464
01:05:46,400 --> 01:05:48,320
Not that the model can reach SharePoint,

1465
01:05:48,320 --> 01:05:50,800
that the model can't reach SharePoint unless you let it.

1466
01:05:50,800 --> 01:05:53,680
Contract design, tool schemers, naming

1467
01:05:53,680 --> 01:05:55,440
and the art of avoiding overlap.

1468
01:05:55,440 --> 01:05:57,040
Now comes the part everyone skips

1469
01:05:57,040 --> 01:05:59,600
because it feels too API-ish at contract design.

1470
01:05:59,600 --> 01:06:02,000
If you get the contract wrong, MCP doesn't save you,

1471
01:06:02,000 --> 01:06:03,840
it just makes your mistakes reusable.

1472
01:06:03,840 --> 01:06:05,360
And the first mistake is naming.

1473
01:06:05,360 --> 01:06:08,000
Most teams name tools like they name helper functions,

1474
01:06:08,000 --> 01:06:10,160
short, generic and optimistic.

1475
01:06:10,160 --> 01:06:13,040
Search, get files, create item.

1476
01:06:13,040 --> 01:06:15,040
That works when a human developer reads the code

1477
01:06:15,040 --> 01:06:16,240
and understands context.

1478
01:06:16,240 --> 01:06:17,760
A model doesn't have that context.

1479
01:06:17,760 --> 01:06:20,080
A model sees a menu of tools with descriptions.

1480
01:06:20,080 --> 01:06:22,160
Then it guesses, so naming has one job,

1481
01:06:22,160 --> 01:06:23,520
make guessing unnecessary.

1482
01:06:23,520 --> 01:06:26,720
The rule is verb first, scope second, and domain explicit.

1483
01:06:26,720 --> 01:06:30,400
Not search, SharePoint search, documents inside.

1484
01:06:30,400 --> 01:06:33,360
Not get, SharePoint get document metadata.

1485
01:06:33,360 --> 01:06:36,080
Not update, SharePoint update list item fields.

1486
01:06:36,080 --> 01:06:39,920
The name should answer, what system, what object, what scope, what action.

1487
01:06:39,920 --> 01:06:43,120
Every extra syllable is cheaper than an incident review.

1488
01:06:43,120 --> 01:06:45,840
Now the next rule, never create overlapping tools.

1489
01:06:45,840 --> 01:06:48,880
If you expose three tools that all feel like search,

1490
01:06:48,880 --> 01:06:50,800
the model will pick the wrong one eventually.

1491
01:06:50,800 --> 01:06:53,520
Not because it's dumb, but because you asked it to choose between

1492
01:06:53,520 --> 01:06:57,360
ambiguous options, so you define one canonical tool per intent, per scope.

1493
01:06:57,360 --> 01:06:59,360
If you need different search semantics,

1494
01:06:59,360 --> 01:07:02,960
graph search versus SharePoint rest versus search API,

1495
01:07:02,960 --> 01:07:04,400
you hide that inside the server.

1496
01:07:04,400 --> 01:07:07,440
You don't force the model to know which back end is better.

1497
01:07:07,440 --> 01:07:09,040
The server is the translator.

1498
01:07:09,040 --> 01:07:10,960
The model is not your integration engineer.

1499
01:07:10,960 --> 01:07:13,440
Now schemas, your input schema is not a convenience.

1500
01:07:13,440 --> 01:07:15,600
It is the boundary that keeps prompt injection

1501
01:07:15,600 --> 01:07:16,880
from becoming tool injection.

1502
01:07:16,880 --> 01:07:20,480
If you accept freeform strings where you actually need constrained fields,

1503
01:07:20,480 --> 01:07:22,960
the model will smuggle instructions into parameters.

1504
01:07:22,960 --> 01:07:23,920
It won't even mean to.

1505
01:07:23,920 --> 01:07:26,160
It's just optimizing for get the job done.

1506
01:07:26,160 --> 01:07:28,800
So constrained inputs until the model can't be clever.

1507
01:07:28,800 --> 01:07:31,360
If a tool needs a site, require a site ID,

1508
01:07:31,360 --> 01:07:34,240
not site URL or site name or whatever you can find,

1509
01:07:34,240 --> 01:07:35,120
one identifier.

1510
01:07:35,120 --> 01:07:39,680
If a tool needs a time window, require ISO 8601 timestamps,

1511
01:07:39,680 --> 01:07:40,800
not last week.

1512
01:07:40,800 --> 01:07:42,880
If a tool needs a filter, make it an in-home,

1513
01:07:42,880 --> 01:07:44,000
not filter text.

1514
01:07:44,000 --> 01:07:47,360
And if you absolutely must accept freeform text,

1515
01:07:47,360 --> 01:07:50,160
you treat it as untrusted, you validate it, you log it,

1516
01:07:50,160 --> 01:07:52,880
and you design the tool, so the worst case is bad query,

1517
01:07:52,880 --> 01:07:54,240
not privilege escalation.

1518
01:07:54,240 --> 01:07:56,000
Outputs matter just as much.

1519
01:07:56,000 --> 01:07:58,800
Most MCP servers return whatever the back end returned,

1520
01:07:58,800 --> 01:08:00,000
because it's easy.

1521
01:08:00,000 --> 01:08:03,120
That is how you make the model reverse engineer your system at runtime.

1522
01:08:03,120 --> 01:08:05,040
Instead, you return stable shapes.

1523
01:08:05,040 --> 01:08:08,640
For a search tool, a list of results with a strict object schema.

1524
01:08:08,640 --> 01:08:13,040
Each result has ID, title, web URL, last modified data time,

1525
01:08:13,040 --> 01:08:16,320
author, and classification signals you can reliably provide.

1526
01:08:16,320 --> 01:08:18,160
No polymorphic blobs.

1527
01:08:18,160 --> 01:08:20,880
For metadata tools, predictable fields,

1528
01:08:20,880 --> 01:08:23,680
predictable null behavior, predictable paging.

1529
01:08:23,680 --> 01:08:25,680
If there's paging, return the next cursor.

1530
01:08:25,680 --> 01:08:28,880
Don't dump our data next link and call it a day.

1531
01:08:28,880 --> 01:08:30,480
And here's the uncomfortable part.

1532
01:08:30,480 --> 01:08:33,280
You need to design outputs for audit, not just for the model.

1533
01:08:33,280 --> 01:08:36,560
If a tool fetches a document, include the permission path you used,

1534
01:08:36,560 --> 01:08:39,040
delegated user token, or app only,

1535
01:08:39,040 --> 01:08:40,720
include the resource identifiers,

1536
01:08:40,720 --> 01:08:43,360
include a correlation ID that ties back to logs.

1537
01:08:43,360 --> 01:08:45,280
That's how you prove what happened later,

1538
01:08:45,280 --> 01:08:48,960
when later becomes why did this tool access that file?

1539
01:08:48,960 --> 01:08:51,920
Now, versioning and MCP capability services are discoverable.

1540
01:08:51,920 --> 01:08:55,280
That's good, but it tempts teams into silent braking changes.

1541
01:08:55,280 --> 01:08:58,080
Rename fields, change meanings, add optional parameters

1542
01:08:58,080 --> 01:08:59,040
that alter behavior.

1543
01:08:59,040 --> 01:09:01,920
That's how deterministic contracts turn probabilistic.

1544
01:09:01,920 --> 01:09:04,640
So treat capability versioning as a first class design input.

1545
01:09:04,640 --> 01:09:06,880
Either version your tool names like SharePoint,

1546
01:09:06,880 --> 01:09:09,120
search documents inside V2,

1547
01:09:09,120 --> 01:09:11,520
or version your server capabilities explicitly

1548
01:09:11,520 --> 01:09:13,920
and keep old shapes alive until clients migrate.

1549
01:09:13,920 --> 01:09:16,000
It's not elegant, but it's survivable.

1550
01:09:16,000 --> 01:09:19,680
Finally, the anti-overlapped discipline needs a naming taxonomy.

1551
01:09:19,680 --> 01:09:22,560
Within a server, tools should follow a consistent pattern.

1552
01:09:22,560 --> 01:09:26,560
System prefix, SharePoint, graph, SQL, Action Verb,

1553
01:09:26,560 --> 01:09:30,640
Search, Get, List, Create, Update, Delete,

1554
01:09:30,640 --> 01:09:32,000
Scope Qualifier.

1555
01:09:32,000 --> 01:09:34,560
Inside, in library, by ID.

1556
01:09:34,560 --> 01:09:39,280
Object noun, documents, list items, permissions.

1557
01:09:39,280 --> 01:09:40,240
That's not aesthetics.

1558
01:09:40,240 --> 01:09:42,560
It's how you prevent the three search tools problem

1559
01:09:42,560 --> 01:09:44,080
that they are from Anthropic called out.

1560
01:09:44,080 --> 01:09:45,600
Overlapping tools, confuse models,

1561
01:09:45,600 --> 01:09:48,240
and confusion becomes unpredictable tool selection.

1562
01:09:48,240 --> 01:09:50,160
And when tool selection becomes unpredictable,

1563
01:09:50,160 --> 01:09:52,480
your security model becomes probabilistic.

1564
01:09:52,480 --> 01:09:54,240
So yes, contract design is boring.

1565
01:09:54,240 --> 01:09:55,280
That's why it works.

1566
01:09:55,280 --> 01:09:58,000
The whole point of MCP is to give a probabilistic model

1567
01:09:58,000 --> 01:09:59,920
a deterministic capability surface.

1568
01:09:59,920 --> 01:10:02,560
Names remove guesswork, skimmers remove ambiguity,

1569
01:10:02,560 --> 01:10:04,320
output shapes remove interpretation,

1570
01:10:04,320 --> 01:10:05,840
versioning removes drift.

1571
01:10:05,840 --> 01:10:08,560
If you do those four things, MCP becomes governable.

1572
01:10:08,560 --> 01:10:11,600
If you don't, MCP becomes just another way to scale your glue code.

1573
01:10:11,600 --> 01:10:16,640
Hosting decision point, functions, versus container apps, versus AKS.

1574
01:10:16,640 --> 01:10:18,080
Now you've got a contract.

1575
01:10:18,080 --> 01:10:20,080
You've got tool names that don't overlap.

1576
01:10:20,080 --> 01:10:22,560
You've got skimmers that don't invite improvisation.

1577
01:10:22,560 --> 01:10:24,400
So the next question is painfully unglomerate.

1578
01:10:24,400 --> 01:10:26,160
Where does the MCP server live?

1579
01:10:26,160 --> 01:10:28,560
This is where teams pretend they're discussing cost and latency,

1580
01:10:28,560 --> 01:10:31,440
but they're really choosing blast radius and operational ownership.

1581
01:10:31,440 --> 01:10:32,800
Hosting is not a runtime choice.

1582
01:10:32,800 --> 01:10:33,680
And it's a pager choice.

1583
01:10:33,680 --> 01:10:34,960
Start with Azure Functions.

1584
01:10:34,960 --> 01:10:38,000
Functions are the default reflex

1585
01:10:38,000 --> 01:10:40,080
because they feel like small tools.

1586
01:10:40,080 --> 01:10:42,960
One function per tool, scale to zero, paper execution.

1587
01:10:42,960 --> 01:10:44,240
It looks like alignment.

1588
01:10:44,240 --> 01:10:47,600
But MCP servers, especially remote ones over HTTP,

1589
01:10:47,600 --> 01:10:49,840
don't behave like typical webhook handlers.

1590
01:10:49,840 --> 01:10:51,680
They behave like interactive services

1591
01:10:51,680 --> 01:10:53,760
that get called in bursts in loops.

1592
01:10:53,760 --> 01:10:57,600
And sometimes in rapid retries, because the model is trying to complete a task.

1593
01:10:57,600 --> 01:11:00,880
Functions can work if your MCP server is truly stateless per call

1594
01:11:00,880 --> 01:11:02,480
and your tools are short-lived.

1595
01:11:02,480 --> 01:11:05,200
Read only queries, quick lookups, narrow transformations.

1596
01:11:05,200 --> 01:11:07,440
It's great for background automation tools too,

1597
01:11:07,440 --> 01:11:09,840
where a cold start is annoying but not catastrophic.

1598
01:11:09,840 --> 01:11:12,000
The catch is cold start and connection behavior.

1599
01:11:12,000 --> 01:11:13,520
In an interactive agent loop,

1600
01:11:13,520 --> 01:11:16,480
a few seconds of startup delay doesn't just slow the user.

1601
01:11:16,480 --> 01:11:17,840
It changes model behavior.

1602
01:11:17,840 --> 01:11:21,200
The model sees tool is slow, tries a different tool,

1603
01:11:21,200 --> 01:11:22,320
or retries.

1604
01:11:22,320 --> 01:11:25,040
And now you've built an accidental traffic amplifier.

1605
01:11:25,040 --> 01:11:27,840
Functions also push you toward fragmented deployments.

1606
01:11:27,840 --> 01:11:30,320
One server per team, per tool set,

1607
01:11:30,320 --> 01:11:32,400
each with slightly different auth handling,

1608
01:11:32,400 --> 01:11:34,240
logging and network controls.

1609
01:11:34,240 --> 01:11:36,720
That is not a platform that is distributed entropy.

1610
01:11:36,720 --> 01:11:38,080
Now, Azure Container Apps.

1611
01:11:38,080 --> 01:11:42,240
Container Apps is the middle path that enterprises should default to

1612
01:11:42,240 --> 01:11:44,480
and rarely do because it's not serverless pure

1613
01:11:44,480 --> 01:11:46,160
and it's not Kubernetes heroic.

1614
01:11:46,160 --> 01:11:48,960
It's a managed container runtime with sane scaling,

1615
01:11:48,960 --> 01:11:52,720
optional scale to zero, and a predictable execution environment

1616
01:11:52,720 --> 01:11:54,080
for HTTP services.

1617
01:11:54,080 --> 01:11:57,520
For MCP servers, that matters because you typically want a single process

1618
01:11:57,520 --> 01:11:59,360
that owns the tool registry,

1619
01:11:59,360 --> 01:12:01,760
can maintain session level behavior if needed,

1620
01:12:01,760 --> 01:12:03,200
and can handle streaming patterns

1621
01:12:03,200 --> 01:12:04,960
without you fighting the platform.

1622
01:12:04,960 --> 01:12:06,560
You also get cleaner identity stories,

1623
01:12:06,560 --> 01:12:08,560
managed identity integration is straightforward.

1624
01:12:08,560 --> 01:12:09,840
Network boundaries are clearer.

1625
01:12:09,840 --> 01:12:12,400
You can front it with APM without weird workarounds.

1626
01:12:12,400 --> 01:12:14,560
And your deployment artifact is a container image,

1627
01:12:14,560 --> 01:12:17,520
which means your dewex and your runtime are finally the same thing.

1628
01:12:17,520 --> 01:12:21,360
The trade is that container apps forces you to act like you're running a service.

1629
01:12:21,360 --> 01:12:24,400
You need health probes, resource limits, log strategy,

1630
01:12:24,400 --> 01:12:26,480
and you need to accept that scaling is not free.

1631
01:12:26,480 --> 01:12:29,520
A burst of tool calls becomes a burst of container replicas

1632
01:12:29,520 --> 01:12:31,840
unless you control concurrency intentionally.

1633
01:12:31,840 --> 01:12:33,760
Now, AKS-AKS is the correct answer

1634
01:12:33,760 --> 01:12:36,960
when you already operate Kubernetes as a first-class platform,

1635
01:12:36,960 --> 01:12:38,480
not when you might need it later.

1636
01:12:38,480 --> 01:12:40,240
Kubernetes isn't a hosting option.

1637
01:12:40,240 --> 01:12:42,400
It's an operating model with an attached tax.

1638
01:12:42,400 --> 01:12:45,360
AKS makes sense if you need strict network segmentation,

1639
01:12:45,360 --> 01:12:49,200
advanced routing, custom side cars, service mesh integration,

1640
01:12:49,200 --> 01:12:52,960
or if you're collocating MCP servers with other internal services

1641
01:12:52,960 --> 01:12:55,280
in a cluster that's already governed and monitored.

1642
01:12:55,280 --> 01:12:58,720
It's also reasonable if you're building a multi-tenant MCP platform

1643
01:12:58,720 --> 01:13:01,680
with strong isolation requirements per team or per environment.

1644
01:13:01,680 --> 01:13:03,520
But here's the architectural truth.

1645
01:13:03,520 --> 01:13:06,720
If this is your first MCP server and your first question is,

1646
01:13:06,720 --> 01:13:07,920
should we run AKS?

1647
01:13:07,920 --> 01:13:08,960
You're early solving.

1648
01:13:08,960 --> 01:13:11,280
You are optimizing for theoretical future scale

1649
01:13:11,280 --> 01:13:13,200
instead of today's boundary correctness.

1650
01:13:13,200 --> 01:13:15,920
An MCP doesn't fail first because you didn't have enough nodes.

1651
01:13:15,920 --> 01:13:18,160
It fails because you didn't have deterministic contracts

1652
01:13:18,160 --> 01:13:20,240
and forcible identity and a failure model

1653
01:13:20,240 --> 01:13:22,160
that closes doors instead of opening them.

1654
01:13:22,160 --> 01:13:23,840
So choose based on the real constraints.

1655
01:13:23,840 --> 01:13:26,560
If you need to move fast and your tools are short-lived,

1656
01:13:26,560 --> 01:13:29,360
functions can be fine, but treated as a stepping stone,

1657
01:13:29,360 --> 01:13:30,480
not the destination.

1658
01:13:30,480 --> 01:13:32,960
If you want a stable, governable HTTP service

1659
01:13:32,960 --> 01:13:35,760
with Sain Operations, container apps is the default.

1660
01:13:35,760 --> 01:13:37,200
If you already live in Kubernetes

1661
01:13:37,200 --> 01:13:39,040
and you need Kubernetes class controls,

1662
01:13:39,040 --> 01:13:40,000
AKS is reasonable,

1663
01:13:40,000 --> 01:13:42,640
but only if you're willing to pay the ongoing cost

1664
01:13:42,640 --> 01:13:43,840
in human attention.

1665
01:13:43,840 --> 01:13:46,720
Because the question behind every hosting decision is simple.

1666
01:13:46,720 --> 01:13:49,120
When this tool server misbehaves at 2am,

1667
01:13:49,120 --> 01:13:50,640
who gets blamed, who gets paged,

1668
01:13:50,640 --> 01:13:52,240
and what system is now at risk?

1669
01:13:52,240 --> 01:13:56,000
SLOs and failure modes, latency, timeouts, and failing closed.

1670
01:13:56,000 --> 01:13:57,520
Now assume you picked a host.

1671
01:13:57,520 --> 01:13:59,520
Great, your next problem is that agent traffic

1672
01:13:59,520 --> 01:14:01,280
doesn't behave like human traffic.

1673
01:14:01,280 --> 01:14:02,800
So you need SLOs, not vibes.

1674
01:14:02,800 --> 01:14:04,000
For interactive tool use,

1675
01:14:04,000 --> 01:14:06,720
the only number that matters is perceived responsiveness.

1676
01:14:06,720 --> 01:14:08,880
A good target is P95,

1677
01:14:08,880 --> 01:14:11,920
around 300 to 500 milliseconds per tool call

1678
01:14:11,920 --> 01:14:15,360
end to end, not back end time, end to end,

1679
01:14:15,360 --> 01:14:19,120
arth, network, execution, serialization, logging.

1680
01:14:19,120 --> 01:14:21,120
Because the model doesn't care why it was slow.

1681
01:14:21,120 --> 01:14:23,440
It just reacts, and when it reacts, it amplifies.

1682
01:14:23,440 --> 01:14:24,800
A slow tool triggers retrieves.

1683
01:14:24,800 --> 01:14:26,640
Retrieves trigger concurrency.

1684
01:14:26,640 --> 01:14:28,400
Concurrency triggers throttling.

1685
01:14:28,400 --> 01:14:30,240
Throttling triggers more retrieves.

1686
01:14:30,240 --> 01:14:32,240
That loop is how you doss your own tenant.

1687
01:14:32,240 --> 01:14:34,880
So set explicit timeouts, short for read tools.

1688
01:14:34,880 --> 01:14:36,320
Longer only when the tool is designed

1689
01:14:36,320 --> 01:14:38,480
for long running work with progress reporting.

1690
01:14:38,480 --> 01:14:40,000
If the tool can mutate state,

1691
01:14:40,000 --> 01:14:41,440
it must be idempotent,

1692
01:14:41,440 --> 01:14:43,200
or you will eventually duplicate actions

1693
01:14:43,200 --> 01:14:44,560
under retry pressure,

1694
01:14:44,560 --> 01:14:47,360
then decide fail closed versus fail open.

1695
01:14:47,360 --> 01:14:48,720
Fail open feels helpful.

1696
01:14:48,720 --> 01:14:51,040
It's also how policy turns into a suggestion.

1697
01:14:51,040 --> 01:14:52,240
If oath fails deny.

1698
01:14:52,240 --> 01:14:53,680
If scope is unclear deny,

1699
01:14:53,680 --> 01:14:56,080
if classification is missing and policy requires it,

1700
01:14:56,080 --> 01:14:57,920
deny denial is stability.

1701
01:14:57,920 --> 01:14:59,920
MCP and developer experience,

1702
01:14:59,920 --> 01:15:01,120
strong interfaces,

1703
01:15:01,120 --> 01:15:02,960
fewer hallucinated integrations.

1704
01:15:02,960 --> 01:15:04,720
Now here's the part that gets MCP

1705
01:15:04,720 --> 01:15:06,880
adopted inside engineering teams.

1706
01:15:06,880 --> 01:15:08,160
Not governance,

1707
01:15:08,160 --> 01:15:09,280
developer experience.

1708
01:15:09,280 --> 01:15:11,440
Because most teams don't start a project by saying,

1709
01:15:11,440 --> 01:15:13,760
I'd like a new control plane boundary, they don't.

1710
01:15:13,760 --> 01:15:14,560
They start by saying,

1711
01:15:14,560 --> 01:15:16,160
I'm tired of rewriting this integration

1712
01:15:16,160 --> 01:15:17,680
for every agent framework,

1713
01:15:17,680 --> 01:15:18,880
and I'm tired of the model

1714
01:15:18,880 --> 01:15:20,640
guessing my API shape wrong.

1715
01:15:20,640 --> 01:15:22,560
This is the uncomfortable truth.

1716
01:15:22,560 --> 01:15:24,320
The average LLM integration fails

1717
01:15:24,320 --> 01:15:25,680
because the interface is vague,

1718
01:15:25,680 --> 01:15:27,120
not because the model is dumb.

1719
01:15:27,120 --> 01:15:28,800
When people say the model hallucinated,

1720
01:15:28,800 --> 01:15:30,320
what they usually mean is,

1721
01:15:30,320 --> 01:15:31,920
we handed a probabilistic caller

1722
01:15:31,920 --> 01:15:33,120
an ambiguous tool surface

1723
01:15:33,120 --> 01:15:34,800
and then acted surprised when it guessed.

1724
01:15:34,800 --> 01:15:38,800
MCP's real devex win is that it makes ambiguity expensive.

1725
01:15:38,800 --> 01:15:41,600
It forces you to declare the capability surface up front,

1726
01:15:41,600 --> 01:15:43,520
tool names, descriptions, schemers,

1727
01:15:43,520 --> 01:15:44,320
output shapes.

1728
01:15:44,320 --> 01:15:45,200
And once you have that,

1729
01:15:45,200 --> 01:15:47,520
you can do something that enterprises have always needed

1730
01:15:47,520 --> 01:15:49,360
but rarely got from AI tooling.

1731
01:15:49,360 --> 01:15:50,720
You can treat tool integrations

1732
01:15:50,720 --> 01:15:52,400
like software contracts again.

1733
01:15:52,400 --> 01:15:54,160
That distinction matters.

1734
01:15:54,160 --> 01:15:56,880
Because rest APIs and open API do this for developers,

1735
01:15:56,880 --> 01:16:00,160
but LLM tool use introduces an extra problem.

1736
01:16:00,160 --> 01:16:03,040
Tool discovery and selection happens at runtime

1737
01:16:03,040 --> 01:16:04,720
inside a reasoning loop

1738
01:16:04,720 --> 01:16:06,720
by a caller that does not read your docs

1739
01:16:06,720 --> 01:16:08,480
like a human reads docs.

1740
01:16:08,480 --> 01:16:12,000
So MCP gives you a structured inventory of capabilities

1741
01:16:12,000 --> 01:16:14,720
that the host can present to the model consistently

1742
01:16:14,720 --> 01:16:15,920
and it gives you schemers

1743
01:16:15,920 --> 01:16:18,400
that the host can validate before anything runs.

1744
01:16:18,400 --> 01:16:21,680
That means fewer hallucinated integrations in practice.

1745
01:16:21,680 --> 01:16:23,280
Fewer invented parameters,

1746
01:16:23,280 --> 01:16:24,960
fewer wrong endpoint assumptions,

1747
01:16:24,960 --> 01:16:27,680
fewer it tried to call search with a site name

1748
01:16:27,680 --> 01:16:28,960
when you needed a site ID,

1749
01:16:28,960 --> 01:16:30,800
not eliminated, reduced.

1750
01:16:30,800 --> 01:16:34,240
And reduction is the whole game in enterprise architecture.

1751
01:16:34,240 --> 01:16:36,240
Now the second devex upgrade is that MCP

1752
01:16:36,240 --> 01:16:39,040
makes testing possible in a way that most agent toolchains

1753
01:16:39,040 --> 01:16:39,920
quietly don't.

1754
01:16:39,920 --> 01:16:42,320
When tool invocation becomes a declared contract,

1755
01:16:42,320 --> 01:16:44,560
you can write contract tests that validate.

1756
01:16:44,560 --> 01:16:46,320
Does this tool accept the schema?

1757
01:16:46,320 --> 01:16:48,000
Does it reject invalid inputs?

1758
01:16:48,000 --> 01:16:49,920
Does it return the output shape you promised?

1759
01:16:49,920 --> 01:16:52,800
Does it fail closed when identity isn't present?

1760
01:16:52,800 --> 01:16:55,120
And you can run those tests without a model in the loop.

1761
01:16:55,120 --> 01:16:56,560
That's not a small improvement.

1762
01:16:56,560 --> 01:16:58,400
That's the difference between AI prototype

1763
01:16:58,400 --> 01:17:00,720
and integration that survives a quarter.

1764
01:17:00,720 --> 01:17:03,360
Because if you can't test the tool layer deterministically,

1765
01:17:03,360 --> 01:17:05,760
you end up testing the entire system through the model

1766
01:17:05,760 --> 01:17:08,000
and the model will never give you stable test cases.

1767
01:17:08,000 --> 01:17:09,360
It's probabilistic by design.

1768
01:17:09,360 --> 01:17:11,600
So MCP lets you split the work.

1769
01:17:11,600 --> 01:17:14,480
The model is tested for behavior and guardrails.

1770
01:17:14,480 --> 01:17:17,280
The tools are tested for contracts and policy.

1771
01:17:17,280 --> 01:17:20,160
Two different test strategies for two different types of components.

1772
01:17:20,160 --> 01:17:22,000
That is what mature engineering looks like.

1773
01:17:22,000 --> 01:17:24,320
Now talk about versioning because every integration

1774
01:17:24,320 --> 01:17:25,600
eventually changes.

1775
01:17:25,600 --> 01:17:28,720
Schemas evolve, back ends evolve, requirements evolve.

1776
01:17:28,720 --> 01:17:31,200
And if you handle that by just update the code,

1777
01:17:31,200 --> 01:17:33,360
you will break clients you don't even know exist,

1778
01:17:33,360 --> 01:17:34,880
especially in an MCP world

1779
01:17:34,880 --> 01:17:37,520
where multiple hosts can connect to the same server.

1780
01:17:37,520 --> 01:17:41,200
So the Devex benefit is not that MCP magically versions your tools.

1781
01:17:41,200 --> 01:17:44,480
That's that MCP gives you a place to version them cleanly.

1782
01:17:44,480 --> 01:17:46,640
You can add a new tool without deleting the old one.

1783
01:17:46,640 --> 01:17:49,600
You can introduce V2 shapes while keeping V1 alive.

1784
01:17:49,600 --> 01:17:51,600
You can mark capabilities as deprecated.

1785
01:17:51,600 --> 01:17:53,760
You can run compatibility checks in CI.

1786
01:17:53,760 --> 01:17:55,600
And the clients don't need to be rewritten

1787
01:17:55,600 --> 01:17:57,680
just because you changed the back end implementation.

1788
01:17:57,680 --> 01:18:00,000
Because the contract is the thing you treat as durable.

1789
01:18:00,000 --> 01:18:02,000
Again, survivability over novelty.

1790
01:18:02,000 --> 01:18:04,000
But there's a warning here.

1791
01:18:04,000 --> 01:18:06,400
And it's the same warning from earlier sections.

1792
01:18:06,400 --> 01:18:08,960
If you treat MCP as faster plugins,

1793
01:18:08,960 --> 01:18:10,720
you will rebuild the glue code anyway.

1794
01:18:10,720 --> 01:18:13,600
You'll create 10 overlapping tools because it feels convenient.

1795
01:18:13,600 --> 01:18:16,000
You'll expose raw back end responses because it's faster.

1796
01:18:16,000 --> 01:18:19,200
You'll accept freeform parameters because the model will figure it out.

1797
01:18:19,200 --> 01:18:22,000
And then you'll spend the next six months writing prompt band aids

1798
01:18:22,000 --> 01:18:24,800
and system messages to compensate for a capability surface

1799
01:18:24,800 --> 01:18:25,840
that never had discipline.

1800
01:18:25,840 --> 01:18:27,120
That's not MCP failing.

1801
01:18:27,120 --> 01:18:29,360
That's you refusing to design an interface.

1802
01:18:29,360 --> 01:18:31,920
An MCP can't fix that because MCP is not intelligence.

1803
01:18:31,920 --> 01:18:34,320
It's a protocol. A protocol can enforce structure,

1804
01:18:34,320 --> 01:18:37,920
but it cannot enforce intent unless you actually embed intent

1805
01:18:37,920 --> 01:18:41,120
into the structure names, schemas, scoping rules,

1806
01:18:41,120 --> 01:18:42,640
and fail closed behavior.

1807
01:18:42,640 --> 01:18:44,560
So the clean takeaway for DevEx is simple.

1808
01:18:44,560 --> 01:18:46,400
MCP doesn't make agents smarter.

1809
01:18:46,400 --> 01:18:48,080
It makes integrations less ambiguous.

1810
01:18:48,080 --> 01:18:50,560
And when you reduce ambiguity, you reduce hallucination,

1811
01:18:50,560 --> 01:18:52,880
you reduce retries, you reduce incident fuel,

1812
01:18:52,880 --> 01:18:55,440
and you reduce the amount of custom glue code you need

1813
01:18:55,440 --> 01:18:58,480
to keep rewriting every time the ecosystem shifts.

1814
01:18:58,480 --> 01:18:59,760
That's why engineers like it.

1815
01:18:59,760 --> 01:19:00,880
Not because it's magical.

1816
01:19:01,520 --> 01:19:04,320
Because it's boring in exactly the right place.

1817
01:19:04,320 --> 01:19:09,440
Tooling integration, VS Code, GitHub, Copilot, CICD, and in a source.

1818
01:19:09,440 --> 01:19:11,680
Once you accept that MCP is a contract boundary,

1819
01:19:11,680 --> 01:19:12,880
the next question is obvious.

1820
01:19:12,880 --> 01:19:16,160
How does it actually live inside real engineering workflows?

1821
01:19:16,160 --> 01:19:18,160
Because nobody deploys a protocol.

1822
01:19:18,160 --> 01:19:21,040
They deploy code through pipelines with approvals

1823
01:19:21,040 --> 01:19:23,520
under the comforting illusion that someone reviewed it.

1824
01:19:23,520 --> 01:19:24,800
So start with VS Code,

1825
01:19:24,800 --> 01:19:27,360
because that's where most MCP adoption shows up first.

1826
01:19:27,360 --> 01:19:29,520
Developer tools and agent enabled IDs.

1827
01:19:29,520 --> 01:19:31,600
Not because IDs are the center of the universe,

1828
01:19:31,600 --> 01:19:34,480
but because they're where tool use is easiest to demonstrate.

1829
01:19:34,480 --> 01:19:37,680
You can wire up an MCP server locally, expose a couple of tools,

1830
01:19:37,680 --> 01:19:40,080
and suddenly your assistant stops being a text generator

1831
01:19:40,080 --> 01:19:41,680
and starts being a bounded actor.

1832
01:19:41,680 --> 01:19:43,520
But don't let that demo lie to you.

1833
01:19:43,520 --> 01:19:45,440
VS Code integration is a DevEx feature.

1834
01:19:45,440 --> 01:19:46,720
It is not an enterprise boundary.

1835
01:19:46,720 --> 01:19:49,120
The enterprise boundary is the MCP server contract

1836
01:19:49,120 --> 01:19:50,640
and the identity model behind it.

1837
01:19:50,640 --> 01:19:53,120
VS Code is just one host, a convenient one.

1838
01:19:53,120 --> 01:19:54,800
So the right mental model is this.

1839
01:19:54,800 --> 01:19:58,240
VS Code is where you develop and test MCP servers.

1840
01:19:58,240 --> 01:20:01,280
Your organization's platform is where you publish and govern them.

1841
01:20:01,280 --> 01:20:03,280
Now, layer GitHub co-pilot on top of that.

1842
01:20:03,280 --> 01:20:05,280
Co-pilot helps you write the server quickly.

1843
01:20:05,280 --> 01:20:07,360
It will happily generate tool schemers,

1844
01:20:07,360 --> 01:20:09,600
JSON, RPC handlers, and boilerplate.

1845
01:20:09,600 --> 01:20:10,160
That's fine.

1846
01:20:10,160 --> 01:20:11,520
It's also not the hard part.

1847
01:20:11,520 --> 01:20:14,640
The hard part is deciding what tools should exist at all.

1848
01:20:14,640 --> 01:20:18,000
Because co-pilot will default to generic convenient tools.

1849
01:20:18,000 --> 01:20:19,840
Search, get, update.

1850
01:20:19,840 --> 01:20:22,240
And you already know what happens when you expose ambiguous

1851
01:20:22,240 --> 01:20:24,400
capabilities to a probabilistic caller.

1852
01:20:24,400 --> 01:20:25,680
So use co-pilot for speed,

1853
01:20:25,680 --> 01:20:27,600
but you still own the boundary design.

1854
01:20:27,600 --> 01:20:30,160
If you delegate boundary design to an autocomplete engine,

1855
01:20:30,160 --> 01:20:31,280
you're not moving faster.

1856
01:20:31,280 --> 01:20:32,720
You're moving the incident earlier.

1857
01:20:32,720 --> 01:20:35,360
Now, the part most teams ignore until they get burned.

1858
01:20:35,360 --> 01:20:37,120
CI/CD.

1859
01:20:37,120 --> 01:20:40,000
If MCP is going to be the end of custom AI glue,

1860
01:20:40,000 --> 01:20:42,800
then MCP servers must become shared assets.

1861
01:20:42,800 --> 01:20:46,480
And shared assets require the same discipline you apply to APIs.

1862
01:20:46,480 --> 01:20:49,600
Linting, testing, versioning, and deployment gates.

1863
01:20:49,600 --> 01:20:53,040
So treat an MCP server like a product with three non-negotiables.

1864
01:20:53,040 --> 01:20:54,960
First, schema validation in CI.

1865
01:20:54,960 --> 01:20:58,640
Every tool input schema and output shape should be machine validated,

1866
01:20:58,640 --> 01:21:00,240
not reviewed in a PR.

1867
01:21:00,240 --> 01:21:01,120
Validated.

1868
01:21:01,120 --> 01:21:03,680
This is where you catch the slow death of contract drift.

1869
01:21:03,680 --> 01:21:05,440
Renamed fields, changed meanings,

1870
01:21:05,440 --> 01:21:06,960
loose types creeping back in.

1871
01:21:06,960 --> 01:21:08,800
Second, contract tests for each tool,

1872
01:21:08,800 --> 01:21:10,880
test the success path and the denial path.

1873
01:21:10,880 --> 01:21:12,000
Especially the denial path.

1874
01:21:12,000 --> 01:21:14,000
If identity is missing, does it fail closed?

1875
01:21:14,000 --> 01:21:15,760
If scope is wrong, does it refuse?

1876
01:21:15,760 --> 01:21:19,440
If the request is ambiguous, does it force elicitation through the host?

1877
01:21:19,440 --> 01:21:20,560
Instead of guessing.

1878
01:21:20,560 --> 01:21:22,240
Your model is not your test harness.

1879
01:21:22,240 --> 01:21:23,120
Your pipeline is.

1880
01:21:23,920 --> 01:21:25,600
Third, policy gates on deployment.

1881
01:21:25,600 --> 01:21:27,440
If you run MCP servers in Azure,

1882
01:21:27,440 --> 01:21:29,200
you already have the governance tooling.

1883
01:21:29,200 --> 01:21:31,600
Azure Policy, APIM policies,

1884
01:21:31,600 --> 01:21:33,920
deployment approvals, environment separation.

1885
01:21:33,920 --> 01:21:34,640
Use them.

1886
01:21:34,640 --> 01:21:36,480
Don't ship new tools straight to production

1887
01:21:36,480 --> 01:21:38,640
because it's just an internal assistant.

1888
01:21:38,640 --> 01:21:41,920
Internal is where the most expensive breaches live now in a source.

1889
01:21:41,920 --> 01:21:45,040
This is where MCP becomes a real organizational multiplier

1890
01:21:45,040 --> 01:21:47,680
or just another pile of half-maintained repositories.

1891
01:21:47,680 --> 01:21:49,440
In most enterprises, every team

1892
01:21:49,440 --> 01:21:52,080
builds the same integration three times.

1893
01:21:52,080 --> 01:21:56,080
One for their app, one for power automate, one for whatever agent framework

1894
01:21:56,080 --> 01:21:57,200
they're experimenting with.

1895
01:21:57,200 --> 01:21:58,000
And they all drift.

1896
01:21:58,000 --> 01:22:00,960
Different naming, different permissions, different behavior,

1897
01:22:00,960 --> 01:22:02,080
different logs.

1898
01:22:02,080 --> 01:22:03,280
Same backend.

1899
01:22:03,280 --> 01:22:05,360
MCP can collapse that duplication,

1900
01:22:05,360 --> 01:22:09,360
but only if you treat MCP servers as shared products with shared ownership.

1901
01:22:09,360 --> 01:22:10,720
Inner source is the mechanism.

1902
01:22:10,720 --> 01:22:14,880
Publish MCP servers as internal packages

1903
01:22:14,880 --> 01:22:16,000
with documentation,

1904
01:22:16,000 --> 01:22:17,920
versioning and a contribution model.

1905
01:22:17,920 --> 01:22:19,200
One team owns the boundary,

1906
01:22:19,200 --> 01:22:20,800
other teams contribute improvements.

1907
01:22:20,800 --> 01:22:22,960
Everyone consumes the same capability surface.

1908
01:22:22,960 --> 01:22:24,320
That's how you reduce toolsprall,

1909
01:22:24,320 --> 01:22:26,080
without creating a central bottleneck.

1910
01:22:26,080 --> 01:22:30,080
And it also changes how you think about platform engineering for AI.

1911
01:22:30,080 --> 01:22:31,440
The platform isn't the model.

1912
01:22:31,440 --> 01:22:34,400
The platform is the catalog of govern tool surfaces.

1913
01:22:34,400 --> 01:22:38,080
SharePoint access, graph search, ticket creation, deployment status,

1914
01:22:38,080 --> 01:22:39,440
whatever your organization needs.

1915
01:22:39,440 --> 01:22:40,240
The moment you do this,

1916
01:22:40,240 --> 01:22:43,120
your host applications become interchangeable at the tool boundary.

1917
01:22:43,120 --> 01:22:44,800
Teams can build different experiences,

1918
01:22:44,800 --> 01:22:46,800
Teams bots, web chat, IDE agents,

1919
01:22:46,800 --> 01:22:48,880
without rebuilding the integration every time.

1920
01:22:48,880 --> 01:22:51,200
That's the practical payoff of standardization,

1921
01:22:51,200 --> 01:22:53,440
but it comes with one uncomfortable rule.

1922
01:22:53,440 --> 01:22:54,720
You need an internal registry,

1923
01:22:54,720 --> 01:22:56,400
even if it's informal at first.

1924
01:22:56,400 --> 01:22:58,160
Not a public marketplace fantasy.

1925
01:22:58,160 --> 01:23:00,640
An internal system that answers

1926
01:23:00,640 --> 01:23:02,080
what MCP servers exist,

1927
01:23:02,080 --> 01:23:02,720
who owns them,

1928
01:23:02,720 --> 01:23:03,840
what version is deployed,

1929
01:23:03,840 --> 01:23:05,040
what tools they expose,

1930
01:23:05,040 --> 01:23:06,800
and what identity model they run under.

1931
01:23:06,800 --> 01:23:08,320
If you can't answer those questions,

1932
01:23:08,320 --> 01:23:10,640
your shared MCP ecosystem

1933
01:23:10,640 --> 01:23:12,880
will become shadow IT with better marketing.

1934
01:23:12,880 --> 01:23:15,440
So the workflow is simple and also relentless.

1935
01:23:15,440 --> 01:23:16,880
Develop locally in VS Code.

1936
01:23:16,880 --> 01:23:18,960
Use co-pilot for code, not for boundaries,

1937
01:23:18,960 --> 01:23:22,880
enforce contracts in CI, deploy behind identity and APM,

1938
01:23:22,880 --> 01:23:24,560
publish as inner source assets.

1939
01:23:24,560 --> 01:23:26,800
And then, this is the part people hate.

1940
01:23:26,800 --> 01:23:28,320
Operate them like real services,

1941
01:23:28,320 --> 01:23:30,240
because MCP doesn't remove responsibility.

1942
01:23:30,240 --> 01:23:31,680
It concentrates it.

1943
01:23:31,680 --> 01:23:33,280
Limitations and risks,

1944
01:23:33,280 --> 01:23:35,920
latency, overreach, and governance debt.

1945
01:23:35,920 --> 01:23:39,040
Now for the part people treat like a disclaimer slide at the end,

1946
01:23:39,040 --> 01:23:40,880
limitations, risks.

1947
01:23:40,880 --> 01:23:42,640
The stuff that decides whether MCP

1948
01:23:42,640 --> 01:23:45,840
becomes infrastructure or becomes another abandoned integration pattern

1949
01:23:45,840 --> 01:23:46,800
with a nice logo.

1950
01:23:46,800 --> 01:23:47,600
Start with latency,

1951
01:23:47,600 --> 01:23:50,480
because agent systems are latency amplifiers.

1952
01:23:50,480 --> 01:23:53,120
MCP doesn't create latency out of thin air.

1953
01:23:53,120 --> 01:23:55,520
It exposes latency that was always there.

1954
01:23:55,520 --> 01:23:57,040
Out, network hops,

1955
01:23:57,040 --> 01:23:58,320
backend variability,

1956
01:23:58,320 --> 01:24:00,160
throttling, cold starts, and retries.

1957
01:24:00,160 --> 01:24:01,520
The difference is that an LLM

1958
01:24:01,520 --> 01:24:03,600
doesn't experience latency like a human does.

1959
01:24:03,600 --> 01:24:04,960
A human waits, a model adapts,

1960
01:24:04,960 --> 01:24:06,320
it tries another tool, it retries,

1961
01:24:06,320 --> 01:24:07,920
it changes its plan mid-flight.

1962
01:24:07,920 --> 01:24:09,200
And if your host is naive,

1963
01:24:09,200 --> 01:24:10,560
it lets the loop keep spinning

1964
01:24:10,560 --> 01:24:12,160
because the model is working.

1965
01:24:12,160 --> 01:24:14,320
So latency isn't just a UX problem,

1966
01:24:14,320 --> 01:24:16,400
it's a behavior shaping input.

1967
01:24:16,400 --> 01:24:17,600
If you don't design around that,

1968
01:24:17,600 --> 01:24:19,840
you train the system into conditional chaos.

1969
01:24:19,840 --> 01:24:20,960
Slow tool calls,

1970
01:24:20,960 --> 01:24:22,240
lead to more tool calls,

1971
01:24:22,240 --> 01:24:24,480
and more tool calls lead to more failures.

1972
01:24:24,480 --> 01:24:26,400
And the system becomes noisy and expensive

1973
01:24:26,400 --> 01:24:27,920
before it becomes useful.

1974
01:24:27,920 --> 01:24:29,520
That's why you front load SLOs

1975
01:24:29,520 --> 01:24:31,200
and fail closed behavior earlier.

1976
01:24:31,200 --> 01:24:32,800
But here's the deeper limitation.

1977
01:24:32,800 --> 01:24:35,760
MCP doesn't solve long running work by itself.

1978
01:24:35,760 --> 01:24:37,760
MCP can carry state incessions,

1979
01:24:37,760 --> 01:24:38,720
and it can stream,

1980
01:24:38,720 --> 01:24:40,480
and frameworks can build on it.

1981
01:24:40,480 --> 01:24:42,800
But your backend reality still exists.

1982
01:24:42,800 --> 01:24:44,480
Some enterprise actions take minutes,

1983
01:24:44,480 --> 01:24:45,600
some take hours.

1984
01:24:45,600 --> 01:24:48,320
And the model's default instinct is to keep the loop alive

1985
01:24:48,320 --> 01:24:50,640
until it gets a result that is not a safe default.

1986
01:24:50,640 --> 01:24:51,920
So for long running tasks,

1987
01:24:51,920 --> 01:24:53,280
you need explicit patterns.

1988
01:24:53,280 --> 01:24:55,120
Acing job submission, progress reporting,

1989
01:24:55,120 --> 01:24:56,240
and durable orchestration

1990
01:24:56,240 --> 01:24:58,560
that doesn't depend on one chat session staying alive.

1991
01:24:58,560 --> 01:24:59,760
MCP can be part of that.

1992
01:24:59,760 --> 01:25:01,280
MCP is not the whole thing.

1993
01:25:01,280 --> 01:25:02,960
Next risk, overreach.

1994
01:25:02,960 --> 01:25:05,120
MCP makes it easy to expose tools.

1995
01:25:05,120 --> 01:25:06,720
That's the problem.

1996
01:25:06,720 --> 01:25:09,520
When the cost of adding one more tool feels low,

1997
01:25:09,520 --> 01:25:12,160
teams will expose internal capability surfaces

1998
01:25:12,160 --> 01:25:13,680
that were never designed to be invoked

1999
01:25:13,680 --> 01:25:15,040
by a probabilistic planner.

2000
01:25:15,040 --> 01:25:17,840
Especially right tools, especially admin tools,

2001
01:25:17,840 --> 01:25:20,160
especially anything that touches permissions.

2002
01:25:20,160 --> 01:25:22,080
So the overreach failure mode looks like this.

2003
01:25:22,080 --> 01:25:25,920
A team starts with safe, read-oriented tools.

2004
01:25:25,920 --> 01:25:27,520
Then someone asks for convenience.

2005
01:25:27,520 --> 01:25:29,120
Can we also create tickets?

2006
01:25:29,120 --> 01:25:31,280
Can we also update list items?

2007
01:25:31,280 --> 01:25:33,200
Can we also post to teams?

2008
01:25:33,200 --> 01:25:34,960
Can we also invite guests?

2009
01:25:34,960 --> 01:25:36,880
And each one is reasonable.

2010
01:25:36,880 --> 01:25:40,320
Until you realize you've built an AI-driven control plane

2011
01:25:40,320 --> 01:25:42,320
with no consistent approval model

2012
01:25:42,320 --> 01:25:44,080
and no reliable attribution model.

2013
01:25:44,080 --> 01:25:45,280
MCP didn't cause that.

2014
01:25:45,280 --> 01:25:46,560
MCP made it scalable.

2015
01:25:46,560 --> 01:25:48,400
So the architectural rule is simple.

2016
01:25:48,400 --> 01:25:50,160
Expose read tools broadly.

2017
01:25:50,160 --> 01:25:51,680
Expose write tools narrowly.

2018
01:25:51,680 --> 01:25:53,520
Expose permission tools almost never.

2019
01:25:53,520 --> 01:25:55,920
And when you do expose write tools,

2020
01:25:55,920 --> 01:25:57,920
force explicit confirmations in the host

2021
01:25:57,920 --> 01:25:59,280
and design idempotency.

2022
01:25:59,280 --> 01:26:01,120
So retries don't duplicate damage.

2023
01:26:01,120 --> 01:26:03,280
Now the one everyone wants to believe is handled already.

2024
01:26:03,280 --> 01:26:04,000
Prompt injection.

2025
01:26:04,000 --> 01:26:06,160
MCP does not remove prompt injection risk.

2026
01:26:06,160 --> 01:26:07,280
It relocates it.

2027
01:26:07,280 --> 01:26:09,600
Instead of the model being tricked into outputting text,

2028
01:26:09,600 --> 01:26:10,320
it shouldn't.

2029
01:26:10,320 --> 01:26:12,720
It gets tricked into selecting tools it shouldn't

2030
01:26:12,720 --> 01:26:14,320
or passing parameters it shouldn't

2031
01:26:14,320 --> 01:26:16,400
or fetching resources it shouldn't.

2032
01:26:16,400 --> 01:26:18,720
The thread model shifts from what did the model say

2033
01:26:18,720 --> 01:26:20,240
to what did the model do.

2034
01:26:20,240 --> 01:26:22,800
So you design tool schemers to resist injection.

2035
01:26:22,800 --> 01:26:24,000
You validate inputs.

2036
01:26:24,000 --> 01:26:25,680
You constrain freeform fields

2037
01:26:25,680 --> 01:26:28,080
and you treat tool selection as a privileged operation

2038
01:26:28,080 --> 01:26:30,320
that can require approval or policy checks.

2039
01:26:30,320 --> 01:26:32,560
If you don't, you will eventually run a tool call

2040
01:26:32,560 --> 01:26:34,480
that looked reasonable in the prompt

2041
01:26:34,480 --> 01:26:37,040
and you'll still be accountable for what it did.

2042
01:26:37,040 --> 01:26:38,400
Now the enterprise class risks.

2043
01:26:38,400 --> 01:26:40,720
Data residency logging and auditability.

2044
01:26:40,720 --> 01:26:43,120
Remote MCP servers are the obvious trap here.

2045
01:26:43,120 --> 01:26:45,280
If your host forwards context to a remote server

2046
01:26:45,280 --> 01:26:47,760
you don't control, you are exporting data.

2047
01:26:47,760 --> 01:26:49,760
Not hypothetically, literally.

2048
01:26:49,760 --> 01:26:52,480
And we didn't mean to send sensitive data is not a control.

2049
01:26:52,480 --> 01:26:53,840
It's a post-incident quote.

2050
01:26:53,840 --> 01:26:57,840
So you need explicit decisions about what context can leave the boundary

2051
01:26:57,840 --> 01:27:01,200
where your MCP servers run and what telemetry is retained.

2052
01:27:01,200 --> 01:27:04,480
In regulated environments that means data residency constraints

2053
01:27:04,480 --> 01:27:07,440
and retention policies for logs that contain tool parameters

2054
01:27:07,440 --> 01:27:10,080
document identifiers and possibly content excerpts.

2055
01:27:10,080 --> 01:27:11,600
Audit trails are not optional.

2056
01:27:11,600 --> 01:27:13,920
They're the only reason enterprises will tolerate

2057
01:27:13,920 --> 01:27:15,440
agentex systems at scale.

2058
01:27:15,440 --> 01:27:17,440
If you can't reconstruct a tool called chain

2059
01:27:17,440 --> 01:27:19,440
who invoked what tool, what parameters,

2060
01:27:19,440 --> 01:27:21,680
what downstream API, what result,

2061
01:27:21,680 --> 01:27:24,160
you have no defensible story when something goes wrong.

2062
01:27:24,160 --> 01:27:25,360
And yes, it will go wrong.

2063
01:27:25,360 --> 01:27:28,480
Finally, governance.dead.mcp centralizes tool invocation

2064
01:27:28,480 --> 01:27:29,440
that sounds like control.

2065
01:27:29,440 --> 01:27:31,040
It is also concentration of risk.

2066
01:27:31,040 --> 01:27:34,160
A small number of MCP servers will become critical infrastructure

2067
01:27:34,160 --> 01:27:35,200
inside the organization.

2068
01:27:35,200 --> 01:27:36,800
Everyone will depend on them.

2069
01:27:36,800 --> 01:27:39,200
And then those servers become the new shared service

2070
01:27:39,200 --> 01:27:41,600
that accumulates exceptions, special cases,

2071
01:27:41,600 --> 01:27:43,280
and temporary bypasses.

2072
01:27:43,280 --> 01:27:44,400
Entropy doesn't disappear.

2073
01:27:44,400 --> 01:27:45,520
It moves to the choke point.

2074
01:27:45,520 --> 01:27:49,120
So treat MCP governance like you treat identity governance.

2075
01:27:49,120 --> 01:27:52,560
Ownership, life cycle, reviews, and deprecation discipline.

2076
01:27:52,560 --> 01:27:54,320
If a tool exists, someone owns it.

2077
01:27:54,320 --> 01:27:56,000
If no one owns it, it gets removed.

2078
01:27:56,000 --> 01:27:57,760
If it can't be audited, it doesn't ship.

2079
01:27:57,760 --> 01:27:59,920
If it can't fail closed, it's not production ready.

2080
01:27:59,920 --> 01:28:01,600
That's the honest limitation section.

2081
01:28:01,600 --> 01:28:03,120
MCP doesn't make AI safe.

2082
01:28:03,120 --> 01:28:05,920
It creates a place where safety can actually be enforced.

2083
01:28:05,920 --> 01:28:08,080
And that's only useful if you enforce it.

2084
01:28:08,080 --> 01:28:11,360
MCP's maturity curve, spec evolution, remote registries,

2085
01:28:11,360 --> 01:28:12,640
and agent discovery.

2086
01:28:12,640 --> 01:28:14,640
So now that the risks are on the table,

2087
01:28:14,640 --> 01:28:18,080
the next question is whether MCP is mature enough to bet on.

2088
01:28:18,080 --> 01:28:21,200
And the only honest answer is, it depends what you think you're betting on.

2089
01:28:21,200 --> 01:28:23,840
But if you're betting on a stable enterprise-grade ecosystem

2090
01:28:23,840 --> 01:28:27,200
of remote servers, you can plug into production tomorrow, you're early.

2091
01:28:27,200 --> 01:28:29,200
If you're betting on the core mechanics,

2092
01:28:29,200 --> 01:28:31,920
typed tool calls, declared capabilities,

2093
01:28:31,920 --> 01:28:34,640
and a host mediated boundary, then you're not early.

2094
01:28:34,640 --> 01:28:36,160
You're catching up to the inevitable.

2095
01:28:36,160 --> 01:28:38,000
That distinction matters.

2096
01:28:38,000 --> 01:28:41,760
Because MCP has two maturity curves running at the same time.

2097
01:28:41,760 --> 01:28:44,000
One curve is the protocol's core primitives.

2098
01:28:44,000 --> 01:28:47,920
Tools, resources, prompts, life cycle, capability negotiation, transport.

2099
01:28:47,920 --> 01:28:49,360
Those are already useful today.

2100
01:28:49,360 --> 01:28:53,440
They are the part that collapses custom glue code into a contract surface.

2101
01:28:53,440 --> 01:28:55,600
The other curve is the ecosystem layer.

2102
01:28:55,600 --> 01:28:59,520
Discovery, registries, trust, and how agents decide what to connect to

2103
01:28:59,520 --> 01:29:01,200
without humans handwiring everything.

2104
01:29:01,200 --> 01:29:02,400
That's where things are still moving.

2105
01:29:02,400 --> 01:29:05,280
So separate what exists from what's emerging.

2106
01:29:05,280 --> 01:29:06,880
What's real today is the boring part.

2107
01:29:06,880 --> 01:29:09,040
The protocol is JSON RPC-based.

2108
01:29:09,040 --> 01:29:12,240
Server's advertised capabilities host, mediate the conversation

2109
01:29:12,240 --> 01:29:14,240
and decide what context moves to what server.

2110
01:29:14,240 --> 01:29:16,640
Transport exists for local and remote operation.

2111
01:29:16,640 --> 01:29:18,960
In architectural terms, MCP already provides

2112
01:29:18,960 --> 01:29:22,640
the minimum structure needed to turn tool use into a governable interface.

2113
01:29:22,640 --> 01:29:23,840
That is the foundation.

2114
01:29:23,840 --> 01:29:27,120
Now, what's emerging is what turns MCP from integration standard

2115
01:29:27,120 --> 01:29:28,720
into integration marketplace.

2116
01:29:28,720 --> 01:29:30,640
Remote registries, agent discovery.

2117
01:29:30,640 --> 01:29:35,280
The ability for a host or agent to say, "I need a capability I don't currently have."

2118
01:29:35,280 --> 01:29:36,880
Go find me a server that provides it.

2119
01:29:36,880 --> 01:29:38,080
That sounds convenient.

2120
01:29:38,080 --> 01:29:41,120
It is also where trust collapses if you're not careful.

2121
01:29:41,120 --> 01:29:44,560
Because discovery without governance is just automated supply chain risk.

2122
01:29:44,560 --> 01:29:47,280
If the model can discover servers on demand,

2123
01:29:47,280 --> 01:29:50,080
then the model can expand its tool surface on demand.

2124
01:29:50,080 --> 01:29:52,560
And if that tool surface expansion isn't controlled by policy,

2125
01:29:52,560 --> 01:29:53,760
you didn't build a boundary.

2126
01:29:53,760 --> 01:29:54,480
You built a hole.

2127
01:29:54,480 --> 01:29:56,880
So when people get excited about registries,

2128
01:29:56,880 --> 01:29:59,200
the correct mental model is not App Store.

2129
01:29:59,200 --> 01:30:00,720
It's Package Manager.

2130
01:30:00,720 --> 01:30:04,240
And Package Managers have supply chain incidents for a living.

2131
01:30:04,240 --> 01:30:07,520
So what does a mature registry model need to become enterprise usable?

2132
01:30:07,520 --> 01:30:08,800
First, a trust story.

2133
01:30:08,800 --> 01:30:10,240
Not its open source.

2134
01:30:10,240 --> 01:30:11,280
A real trust story.

2135
01:30:11,280 --> 01:30:12,400
Who published the server?

2136
01:30:12,400 --> 01:30:13,280
Who maintains it?

2137
01:30:13,280 --> 01:30:14,720
What version is deployed?

2138
01:30:14,720 --> 01:30:17,040
What identity and authorization model does it use?

2139
01:30:17,040 --> 01:30:18,240
What data does it receive?

2140
01:30:18,240 --> 01:30:19,040
Where does it run?

2141
01:30:19,040 --> 01:30:20,160
What logs does it keep?

2142
01:30:20,160 --> 01:30:23,440
And in Microsoft Land, the trust story eventually collapses into Entra.

2143
01:30:23,440 --> 01:30:26,880
Because Entra is where identity becomes enforceable at scale.

2144
01:30:26,880 --> 01:30:28,880
If a registry can't map servers

2145
01:30:28,880 --> 01:30:31,680
to tenant identity, policy, and ownership,

2146
01:30:31,680 --> 01:30:33,440
it's not an enterprise registry.

2147
01:30:33,440 --> 01:30:35,520
It's a directory of things you shouldn't connect to.

2148
01:30:35,520 --> 01:30:36,800
Second, a governance story.

2149
01:30:36,800 --> 01:30:38,880
Even if discovery exists,

2150
01:30:38,880 --> 01:30:41,280
enterprises don't allow install anything.

2151
01:30:41,280 --> 01:30:43,360
They allow install from the approved catalog.

2152
01:30:43,360 --> 01:30:45,920
That means you need approval workflows,

2153
01:30:45,920 --> 01:30:47,680
environment promotion, and policy gates

2154
01:30:47,680 --> 01:30:49,120
that sit outside the protocol.

2155
01:30:49,120 --> 01:30:50,800
MCP is the protocol.

2156
01:30:50,800 --> 01:30:52,080
The approval model is not.

2157
01:30:52,080 --> 01:30:53,120
So expect a split.

2158
01:30:53,120 --> 01:30:54,640
MCP standardizes the calls

2159
01:30:54,640 --> 01:30:57,600
and Microsoft governance tooling, Entra, APM, PerView,

2160
01:30:57,600 --> 01:31:00,400
whatever else will be used to control what gets connected.

2161
01:31:00,400 --> 01:31:02,560
Third, a maturity story for agent discovery itself,

2162
01:31:02,560 --> 01:31:04,880
because discovery isn't just finding a server.

2163
01:31:04,880 --> 01:31:07,760
It's deciding whether the server's capabilities overlap

2164
01:31:07,760 --> 01:31:09,120
with what you already have,

2165
01:31:09,120 --> 01:31:10,640
whether the two names are ambiguous,

2166
01:31:10,640 --> 01:31:12,160
whether the schemas are safe,

2167
01:31:12,160 --> 01:31:14,000
and whether the outcomes are predictable.

2168
01:31:14,000 --> 01:31:15,360
Remember the earlier rule.

2169
01:31:15,360 --> 01:31:17,920
Overlapping tools create probabilistic behavior.

2170
01:31:17,920 --> 01:31:19,840
Discovery increases overlap by default,

2171
01:31:19,840 --> 01:31:22,480
so if you want agent-driven discovery in an enterprise,

2172
01:31:22,480 --> 01:31:25,200
the real work is not how do we find more tools.

2173
01:31:25,200 --> 01:31:27,440
It's how do we prevent tool collisions?

2174
01:31:27,440 --> 01:31:29,920
That likely means standard naming taxonomies,

2175
01:31:29,920 --> 01:31:31,520
server certification, and tool-linting

2176
01:31:31,520 --> 01:31:33,920
that catches generic or overlapping capabilities

2177
01:31:33,920 --> 01:31:35,520
before they hit production.

2178
01:31:35,520 --> 01:31:38,240
In other words, MCP will grow into the same governance shape

2179
01:31:38,240 --> 01:31:39,440
as APIs did.

2180
01:31:39,440 --> 01:31:40,480
Registries will exist,

2181
01:31:40,480 --> 01:31:42,160
but enterprises will treat them

2182
01:31:42,160 --> 01:31:44,560
like internal marketplaces with procurement rules,

2183
01:31:44,560 --> 01:31:45,840
not like the open internet.

2184
01:31:45,840 --> 01:31:48,320
And if you're listening to this as a Microsoft architect,

2185
01:31:48,320 --> 01:31:50,240
the practical decision rule is simple.

2186
01:31:50,240 --> 01:31:53,040
Build against the stable layer, contracts, and identity.

2187
01:31:53,040 --> 01:31:54,960
Treat the ecosystem layer as optional.

2188
01:31:54,960 --> 01:31:57,680
Use community servers for prototypes, demos, and learning,

2189
01:31:57,680 --> 01:32:00,400
but for real tenants, you run your own MCP servers,

2190
01:32:00,400 --> 01:32:02,880
or you consume vendor servers only when they come

2191
01:32:02,880 --> 01:32:04,720
with enterprise-grade identity, auditing,

2192
01:32:04,720 --> 01:32:06,400
and data-residency guarantees.

2193
01:32:06,400 --> 01:32:09,280
Because MCP's maturity curve doesn't reward optimism,

2194
01:32:09,280 --> 01:32:10,800
it rewards boundary discipline,

2195
01:32:10,800 --> 01:32:13,040
and if you anchor on contracts and identity today,

2196
01:32:13,040 --> 01:32:15,760
the registry and discovery world can evolve later

2197
01:32:15,760 --> 01:32:17,920
without forcing you to rewrite everything again.

2198
01:32:17,920 --> 01:32:20,320
That's the only kind of future-proofing that works.

2199
01:32:20,320 --> 01:32:22,720
Looking ahead in Microsoft Land speculation,

2200
01:32:22,720 --> 01:32:25,760
Co-Pilot Studio, Power Platform, D365,

2201
01:32:25,760 --> 01:32:27,440
now the part that needs a warning label.

2202
01:32:27,440 --> 01:32:29,840
This is speculation, not because nobody has opinions,

2203
01:32:29,840 --> 01:32:31,600
but because Microsoft Product Direction

2204
01:32:31,600 --> 01:32:34,000
is a moving target and marketing names change faster

2205
01:32:34,000 --> 01:32:35,520
than your tenant policies.

2206
01:32:35,520 --> 01:32:37,440
So treat this as architectural trajectory,

2207
01:32:37,440 --> 01:32:40,000
not roadmap promises, start with the simplest observation.

2208
01:32:40,000 --> 01:32:42,400
Microsoft is already building an agent ecosystem,

2209
01:32:42,400 --> 01:32:44,400
whether you call it Co-Pilot, Co-Pilot Studio,

2210
01:32:44,400 --> 01:32:46,640
or whatever got renamed last quarter.

2211
01:32:46,640 --> 01:32:50,320
And the ecosystem problem is the same one MCP was created to solve.

2212
01:32:50,320 --> 01:32:53,040
How does an agent safely discover and use tools

2213
01:32:53,040 --> 01:32:55,680
across thousands of tenants and millions of workloads

2214
01:32:55,680 --> 01:32:58,720
without every integration becoming bespoke glue?

2215
01:32:58,720 --> 01:33:01,840
So if MCP keeps its momentum as an open protocol,

2216
01:33:01,840 --> 01:33:05,360
the most likely future is that it becomes a common integration surface

2217
01:33:05,360 --> 01:33:08,320
that sits underneath multiple Microsoft experiences,

2218
01:33:08,320 --> 01:33:10,960
not replacing proprietary extensibility overnight,

2219
01:33:10,960 --> 01:33:13,120
coexisting and quietly winning over time.

2220
01:33:13,120 --> 01:33:15,440
Co-Pilot Studio is the obvious pressure point.

2221
01:33:15,440 --> 01:33:18,000
Co-Pilot Studio lives in the world of connectors,

2222
01:33:18,000 --> 01:33:21,040
actions, plugins and custom agents.

2223
01:33:21,040 --> 01:33:24,000
That world is powerful, but it is also highly platform-shaped.

2224
01:33:24,000 --> 01:33:25,920
You build inside the Co-Pilot ecosystem,

2225
01:33:25,920 --> 01:33:27,200
you inherit its constraints,

2226
01:33:27,200 --> 01:33:29,040
and you accept that portability is limited.

2227
01:33:29,040 --> 01:33:31,600
MCP in contrast is portable by design.

2228
01:33:31,600 --> 01:33:33,280
So the architectural question is not,

2229
01:33:33,280 --> 01:33:35,360
will Co-Pilot Studio support MCP?

2230
01:33:35,360 --> 01:33:38,320
It's, will enterprises standardize their internal tool surface

2231
01:33:38,320 --> 01:33:41,280
on MCP so that Co-Pilot Studio becomes just one client,

2232
01:33:41,280 --> 01:33:44,480
because that's the move that changes the power dynamic.

2233
01:33:44,480 --> 01:33:46,800
If the organization exposes SharePoint access,

2234
01:33:46,800 --> 01:33:48,960
ticketing operations, inventory systems,

2235
01:33:48,960 --> 01:33:51,280
and approvals through a governed MCP server layer,

2236
01:33:51,280 --> 01:33:53,760
then Co-Pilot Studio becomes a user experience layer,

2237
01:33:53,760 --> 01:33:55,520
a good one, probably, but not the only one.

2238
01:33:55,520 --> 01:33:57,760
And then you can swap clients without rebuilding the boundary.

2239
01:33:57,760 --> 01:34:00,480
That's the end of custom glue in Microsoft terms.

2240
01:34:00,480 --> 01:34:03,040
Now, power platform, power platform is where this gets uncomfortable

2241
01:34:03,040 --> 01:34:06,720
because low-code and governance have a long, hostile history together.

2242
01:34:06,720 --> 01:34:08,320
Low-code ones make it work.

2243
01:34:08,320 --> 01:34:10,480
Governance once proves it's allowed.

2244
01:34:10,480 --> 01:34:14,000
So if MCP enters power platform, it won't be as a developer toy.

2245
01:34:14,000 --> 01:34:15,600
It will be as an enforcement surface.

2246
01:34:15,600 --> 01:34:19,440
Because the moment citizen developers can build agents that call tools,

2247
01:34:19,440 --> 01:34:23,280
the organization needs deterministic boundaries, identity, policy,

2248
01:34:23,280 --> 01:34:25,120
logging, throttling, and change control,

2249
01:34:25,120 --> 01:34:27,440
power platform is excellent at scaling creation.

2250
01:34:27,440 --> 01:34:29,440
It is not excellent at scaling restraint

2251
01:34:29,440 --> 01:34:31,680
unless you enforce restraint by design.

2252
01:34:31,680 --> 01:34:34,480
MCP provides a language for tool invocation

2253
01:34:34,480 --> 01:34:37,120
that could let power platform consume enterprise tools

2254
01:34:37,120 --> 01:34:39,280
without building yet another connector format

2255
01:34:39,280 --> 01:34:42,480
and without forcing the model to guess API shapes.

2256
01:34:42,480 --> 01:34:45,120
But the real value would be the governance alignment.

2257
01:34:45,120 --> 01:34:48,320
The tools become centrally defined, centrally audited,

2258
01:34:48,320 --> 01:34:49,440
and centrally versioned.

2259
01:34:49,440 --> 01:34:52,320
That's the only way low-code agents don't become shadow IT

2260
01:34:52,320 --> 01:34:53,680
with better UX.

2261
01:34:53,680 --> 01:34:58,320
Now Dynamics 365.d365 is the place where the agents can act story

2262
01:34:58,320 --> 01:34:59,840
becomes politically real.

2263
01:34:59,840 --> 01:35:03,200
Because D365 is money, leads, quotes, invoices,

2264
01:35:03,200 --> 01:35:04,960
customer records, support cases.

2265
01:35:04,960 --> 01:35:07,440
This is where a bad tool call is not an inconvenience.

2266
01:35:07,440 --> 01:35:08,400
It's a business event.

2267
01:35:08,400 --> 01:35:11,840
And D365 also has the most obvious permission complexity

2268
01:35:11,840 --> 01:35:14,000
because it's full of role-based security models

2269
01:35:14,000 --> 01:35:15,920
that were built for humans, clicking forms,

2270
01:35:15,920 --> 01:35:19,040
not for probabilistic systems, issuing multi-step actions.

2271
01:35:19,040 --> 01:35:22,160
So if MCP becomes the tool boundary for D365 actions,

2272
01:35:22,160 --> 01:35:24,400
the identity model matters even more.

2273
01:35:24,400 --> 01:35:26,880
OBS becomes non-negotiable for user-driven actions

2274
01:35:26,880 --> 01:35:28,480
because you need downstream enforcement

2275
01:35:28,480 --> 01:35:29,840
that maps to a user.

2276
01:35:29,840 --> 01:35:32,480
Managed identity becomes acceptable for controlled automation

2277
01:35:32,480 --> 01:35:34,640
but it has to be narrow and heavily audited.

2278
01:35:34,640 --> 01:35:36,720
APM becomes the expected wrapper

2279
01:35:36,720 --> 01:35:39,120
because D365 oriented tool traffic

2280
01:35:39,120 --> 01:35:40,640
will be bursty and expensive

2281
01:35:40,640 --> 01:35:43,120
and cost-control becomes a first-class requirement.

2282
01:35:43,120 --> 01:35:45,680
The likely Microsoft direction if it happens

2283
01:35:45,680 --> 01:35:48,000
is that MCP becomes one of the standardized ways

2284
01:35:48,000 --> 01:35:50,880
to expose actions and context across business systems

2285
01:35:50,880 --> 01:35:52,880
while Entra becomes the standardized way

2286
01:35:52,880 --> 01:35:54,720
to issue authority for those actions.

2287
01:35:54,720 --> 01:35:57,200
Which is the same pattern Microsoft always ships.

2288
01:35:57,200 --> 01:35:58,960
The protocol stabilizes the ecosystem.

2289
01:35:58,960 --> 01:36:00,560
Identity stabilizes the risk.

2290
01:36:00,560 --> 01:36:02,160
Everything else is product-packaging.

2291
01:36:02,160 --> 01:36:04,240
So if you're trying to interpret what this means

2292
01:36:04,240 --> 01:36:06,000
over the next couple of years,

2293
01:36:06,000 --> 01:36:08,000
here's the simplest prediction you can actually use.

2294
01:36:08,000 --> 01:36:10,640
MCP adoption in Microsoft Land will follow the path

2295
01:36:10,640 --> 01:36:12,400
of every successful standard.

2296
01:36:12,400 --> 01:36:15,120
First it shows up in developer tools and side projects

2297
01:36:15,120 --> 01:36:17,120
because that's where friction is loudest.

2298
01:36:17,120 --> 01:36:20,160
Then it shows up in platform products as a compatibility layer.

2299
01:36:20,160 --> 01:36:22,320
Then it becomes the thing you assume exists

2300
01:36:22,320 --> 01:36:24,560
and everyone forgets why it was controversial.

2301
01:36:24,560 --> 01:36:27,200
But only if enterprises do the hard part.

2302
01:36:27,200 --> 01:36:28,800
They build the tool boundary once,

2303
01:36:28,800 --> 01:36:29,760
with discipline,

2304
01:36:29,760 --> 01:36:32,400
and they refuse to let convenience erase intent.

2305
01:36:32,400 --> 01:36:34,560
Because Microsoft will happily give you 100 ways

2306
01:36:34,560 --> 01:36:36,800
to integrate the platform always does.

2307
01:36:36,800 --> 01:36:39,360
Your job is to choose one boundary model

2308
01:36:39,360 --> 01:36:41,840
and enforce it until entropy gives up.

2309
01:36:41,840 --> 01:36:44,560
The MCP as AI infrastructure,

2310
01:36:44,560 --> 01:36:46,400
the control plane for tool use.

2311
01:36:46,400 --> 01:36:48,320
If you step back from all the mechanics,

2312
01:36:48,320 --> 01:36:51,120
JSON, RPC, schemas, transports, and droplets,

2313
01:36:51,120 --> 01:36:52,720
the real pattern shows up.

2314
01:36:52,720 --> 01:36:55,520
MCP is not AI tooling, it's infrastructure.

2315
01:36:55,520 --> 01:36:58,160
More specifically, it's the control plane for tool use.

2316
01:36:58,160 --> 01:37:00,240
And that phrase matters because it reframes

2317
01:37:00,240 --> 01:37:01,440
what you're actually building.

2318
01:37:01,440 --> 01:37:03,360
You are not building a smarter assistant.

2319
01:37:03,360 --> 01:37:05,120
You are building a system that decides

2320
01:37:05,120 --> 01:37:06,560
what actions are even possible

2321
01:37:06,560 --> 01:37:08,880
under what authority with what observability

2322
01:37:08,880 --> 01:37:10,160
and with what failure behavior.

2323
01:37:10,160 --> 01:37:12,720
The model is the data plane, it generates proposals.

2324
01:37:12,720 --> 01:37:15,920
It makes plans, it produces structured tool calls.

2325
01:37:15,920 --> 01:37:17,760
But it doesn't own the permission boundary,

2326
01:37:17,760 --> 01:37:19,040
it can't, it's probabilistic.

2327
01:37:19,040 --> 01:37:21,600
It will optimize for completion unless you constrain it.

2328
01:37:21,600 --> 01:37:23,760
So the host plus the MCP server layer

2329
01:37:23,760 --> 01:37:25,280
becomes the control plane.

2330
01:37:25,280 --> 01:37:27,200
The place where your intent gets compiled

2331
01:37:27,200 --> 01:37:28,640
into enforceable capability.

2332
01:37:28,640 --> 01:37:30,320
That's why this whole thing feels inevitable.

2333
01:37:30,320 --> 01:37:33,120
Enterprises already know how to run control planes.

2334
01:37:33,120 --> 01:37:35,760
They just weren't running one for LLM tool use yet.

2335
01:37:35,760 --> 01:37:37,680
Now connect that to familiar constructs.

2336
01:37:37,680 --> 01:37:40,400
People keep comparing MCP to an API gateway

2337
01:37:40,400 --> 01:37:43,360
and that comparison is useful as long as you don't oversimplify it.

2338
01:37:43,360 --> 01:37:45,440
API gateways sit in front of backends

2339
01:37:45,440 --> 01:37:47,600
and enforce things like authentication,

2340
01:37:47,600 --> 01:37:49,200
rate limiting and transformation.

2341
01:37:49,200 --> 01:37:50,000
APIM does that.

2342
01:37:50,000 --> 01:37:51,760
We already covered why it matters.

2343
01:37:51,760 --> 01:37:54,160
But MCP adds a model oriented contract surface

2344
01:37:54,160 --> 01:37:54,960
on top of that.

2345
01:37:54,960 --> 01:37:57,040
Tools and resources aren't just endpoints.

2346
01:37:57,040 --> 01:37:59,760
They are capabilities shaped for a reasoning loop.

2347
01:37:59,760 --> 01:38:02,480
They come with descriptions that influence selection,

2348
01:38:02,480 --> 01:38:04,400
schemas that constrain behavior

2349
01:38:04,400 --> 01:38:05,840
and output shapes that allow

2350
01:38:05,840 --> 01:38:08,320
deterministic downstream processing and auditing.

2351
01:38:08,320 --> 01:38:09,840
So MCP isn't your gateway.

2352
01:38:09,840 --> 01:38:11,680
It's the layer that makes your APIs

2353
01:38:11,680 --> 01:38:13,440
legible to a probabilistic caller

2354
01:38:13,440 --> 01:38:15,680
without letting that caller touch the raw edges.

2355
01:38:15,680 --> 01:38:17,600
Then there's the service mesh comparison.

2356
01:38:17,600 --> 01:38:19,680
Service meshes exist because microservices

2357
01:38:19,680 --> 01:38:22,080
created too many sideways dependencies.

2358
01:38:22,080 --> 01:38:24,160
Identity drift, inconsistent retries,

2359
01:38:24,160 --> 01:38:26,880
inconsistent telemetry, inconsistent policy.

2360
01:38:26,880 --> 01:38:30,240
So the mesh moved those concerns into shared infrastructure.

2361
01:38:30,240 --> 01:38:33,360
MTLS retries, circuit breakers, observability.

2362
01:38:33,360 --> 01:38:35,760
MCP is the same move but for tool calls.

2363
01:38:35,760 --> 01:38:38,000
Tool calls are just service calls

2364
01:38:38,000 --> 01:38:39,440
with a different failure mode.

2365
01:38:39,440 --> 01:38:42,240
The caller isn't a human or a deterministic client.

2366
01:38:42,240 --> 01:38:44,080
The caller is a reasoning engine

2367
01:38:44,080 --> 01:38:46,240
that can generate unexpected sequences

2368
01:38:46,240 --> 01:38:48,080
and amplify its own mistakes.

2369
01:38:48,080 --> 01:38:49,760
So you need the mesh-like controls

2370
01:38:49,760 --> 01:38:51,920
but oriented around tool invocation,

2371
01:38:51,920 --> 01:38:53,920
identity binding, throttling, logging,

2372
01:38:53,920 --> 01:38:56,320
input validation and explicit failure semantics.

2373
01:38:56,320 --> 01:38:58,400
And then there's the event-driven platform analogy

2374
01:38:58,400 --> 01:39:00,960
because not everything should be a synchronous tool call.

2375
01:39:00,960 --> 01:39:04,000
A lot of enterprise work is inherently asynchronous.

2376
01:39:04,000 --> 01:39:06,880
Start an export, kick off a compliance scan,

2377
01:39:06,880 --> 01:39:09,440
provision an environment, runner workflow,

2378
01:39:09,440 --> 01:39:10,880
wait for approval.

2379
01:39:10,880 --> 01:39:13,040
If you force those into synchronous tool calls

2380
01:39:13,040 --> 01:39:15,520
you end up with timeouts, retries, duplicate actions

2381
01:39:15,520 --> 01:39:17,600
and an agent loop that keeps poking the system

2382
01:39:17,600 --> 01:39:18,800
until something breaks.

2383
01:39:18,800 --> 01:39:20,560
So the mature pattern is,

2384
01:39:20,560 --> 01:39:22,960
MCP handles the invocation contract

2385
01:39:22,960 --> 01:39:26,080
but long-running actions become asynchronous jobs behind it.

2386
01:39:26,080 --> 01:39:28,560
Tool calls submit work, return a job ID,

2387
01:39:28,560 --> 01:39:30,160
stream progress if appropriate

2388
01:39:30,160 --> 01:39:32,160
and require the host to handle completion

2389
01:39:32,160 --> 01:39:33,520
without assuming the chat session

2390
01:39:33,520 --> 01:39:35,120
is a durable workflow engine.

2391
01:39:35,120 --> 01:39:38,160
That's where MCP integrates with actual cloud architecture

2392
01:39:38,160 --> 01:39:40,320
instead of pretending chat is a scheduler.

2393
01:39:40,320 --> 01:39:43,440
Now the hard truth, MCP doesn't make probabilistic systems safe.

2394
01:39:43,440 --> 01:39:44,800
It makes them governable.

2395
01:39:44,800 --> 01:39:47,360
Governable means you can enforce your assumptions at scale.

2396
01:39:47,360 --> 01:39:48,880
Identity is explicit.

2397
01:39:48,880 --> 01:39:51,040
Enter issues authority and you select the flow

2398
01:39:51,040 --> 01:39:52,400
that matches the scenario.

2399
01:39:52,400 --> 01:39:54,720
OBO, for user-delegated action,

2400
01:39:54,720 --> 01:39:56,880
manage identity for operational tasks,

2401
01:39:56,880 --> 01:39:58,720
service principles and APRM

2402
01:39:58,720 --> 01:40:01,360
for controlled multi-client exposure.

2403
01:40:01,360 --> 01:40:02,480
Contracts are explicit.

2404
01:40:02,480 --> 01:40:04,480
Tools are named, scoped and schematized

2405
01:40:04,480 --> 01:40:07,040
ambiguity gets removed before it hits the model.

2406
01:40:07,040 --> 01:40:08,160
Failure is explicit.

2407
01:40:08,160 --> 01:40:09,360
You decide fail-closed.

2408
01:40:09,360 --> 01:40:10,400
You decide timeouts.

2409
01:40:10,400 --> 01:40:11,760
You decide which tools can write.

2410
01:40:11,760 --> 01:40:13,440
You decide what requires approval

2411
01:40:13,440 --> 01:40:15,520
and observability is explicit.

2412
01:40:15,520 --> 01:40:16,720
You can build an audit trail

2413
01:40:16,720 --> 01:40:19,280
that reconstructs what happened without relying on

2414
01:40:19,280 --> 01:40:20,880
the model said it did X.

2415
01:40:20,880 --> 01:40:22,560
That's what infrastructure actually does.

2416
01:40:22,560 --> 01:40:23,920
It doesn't eliminate mistakes.

2417
01:40:23,920 --> 01:40:25,600
It makes mistakes containable.

2418
01:40:25,600 --> 01:40:26,720
So when someone asks,

2419
01:40:26,720 --> 01:40:29,040
is MCP just another integration trend?

2420
01:40:29,040 --> 01:40:30,240
The answer is simple.

2421
01:40:30,240 --> 01:40:31,040
No.

2422
01:40:31,040 --> 01:40:34,800
MCP is how enterprises stop letting probabilistic systems

2423
01:40:34,800 --> 01:40:36,880
talk directly to deterministic systems

2424
01:40:36,880 --> 01:40:39,120
without an enforcement layer in between.

2425
01:40:39,120 --> 01:40:40,640
It's the control plane for tool use.

2426
01:40:40,640 --> 01:40:42,800
And in Microsoft Land, that's not a niche feature.

2427
01:40:42,800 --> 01:40:45,520
That's how the platform survives the next decade of agents

2428
01:40:45,520 --> 01:40:47,840
without turning into conditional chaos.

2429
01:40:47,840 --> 01:40:48,880
Conclusion.

2430
01:40:48,880 --> 01:40:50,640
Protocols don't make things easy.

2431
01:40:50,640 --> 01:40:52,240
They make them governable.

2432
01:40:52,240 --> 01:40:55,280
Most organizations want MCP to be a productivity feature.

2433
01:40:55,280 --> 01:40:57,200
A faster way to bold tools onto a model.

2434
01:40:57,200 --> 01:40:58,880
That's the comfortable interpretation

2435
01:40:58,880 --> 01:41:00,960
because it keeps the story in developer land.

2436
01:41:00,960 --> 01:41:03,600
Better ergonomics, less glue code, more shipping.

2437
01:41:03,600 --> 01:41:05,360
But that's not what makes MCP matter.

2438
01:41:05,360 --> 01:41:08,160
MCP matters because it gives you a place to stop the model.

2439
01:41:08,160 --> 01:41:10,320
A place to say you can reason all day,

2440
01:41:10,320 --> 01:41:13,120
but you can't act unless the boundary allows it.

2441
01:41:13,120 --> 01:41:14,800
And that boundary can be made explicit.

2442
01:41:14,800 --> 01:41:17,760
Contracts, identity, policy, logging, throttling,

2443
01:41:17,760 --> 01:41:19,120
failure semantics.

2444
01:41:19,120 --> 01:41:20,560
That distinction matters.

2445
01:41:20,560 --> 01:41:22,320
Because in enterprise environments,

2446
01:41:22,320 --> 01:41:24,640
the hard problem is not can the model do this.

2447
01:41:24,640 --> 01:41:28,320
The hard problem is can the organization survive it doing this every day

2448
01:41:28,320 --> 01:41:30,000
across every tenant, under-ordered,

2449
01:41:30,000 --> 01:41:32,080
under-incident pressure, under-drift?

2450
01:41:32,080 --> 01:41:34,640
Most integrations fail the same way over time.

2451
01:41:34,640 --> 01:41:37,200
They start clean, then the first exception gets added,

2452
01:41:37,200 --> 01:41:39,280
then the second, then the workaround becomes permanent.

2453
01:41:39,280 --> 01:41:41,600
Then the logs get ignored because they're noisy.

2454
01:41:41,600 --> 01:41:44,480
Then nobody knows which identity is actually doing the work.

2455
01:41:44,480 --> 01:41:46,240
Then the system becomes probabilistic,

2456
01:41:46,240 --> 01:41:47,840
not because the model is probabilistic,

2457
01:41:47,840 --> 01:41:50,400
but because the boundary was never enforced as infrastructure.

2458
01:41:50,400 --> 01:41:52,080
MCP is the attempt to reverse that,

2459
01:41:52,080 --> 01:41:54,560
not by making models safer through wishful thinking,

2460
01:41:54,560 --> 01:41:57,200
by making tool use governable through structure.

2461
01:41:57,200 --> 01:41:59,120
So the key takeaway is one sentence,

2462
01:41:59,120 --> 01:42:00,560
and it's not inspirational.

2463
01:42:00,560 --> 01:42:02,880
MCP is a security boundary first.

2464
01:42:02,880 --> 01:42:05,360
Developer ergonomics are the side effect.

2465
01:42:05,360 --> 01:42:07,600
If you're building this in Microsoft Land,

2466
01:42:07,600 --> 01:42:10,640
you already have the ingredients most ecosystems don't.

2467
01:42:10,640 --> 01:42:14,000
Entra gives you identity that can actually bind authority.

2468
01:42:14,000 --> 01:42:17,200
OBO, when the user owns the action, manage identity,

2469
01:42:17,200 --> 01:42:19,280
when the workload owns the action,

2470
01:42:19,280 --> 01:42:20,880
service principles and APM,

2471
01:42:20,880 --> 01:42:24,880
when you need an enforcement edge that can meter and throttle reality,

2472
01:42:24,880 --> 01:42:28,000
Azure gives you a place to host the boundary as a real service,

2473
01:42:28,000 --> 01:42:29,360
not a developer toy,

2474
01:42:29,360 --> 01:42:32,560
and the governance stack, logging, auditing, policy,

2475
01:42:32,560 --> 01:42:35,040
data residency controls already exists.

2476
01:42:35,040 --> 01:42:36,880
But you still have to make the uncomfortable choice.

2477
01:42:36,880 --> 01:42:38,560
You're not adopting MCP.

2478
01:42:38,560 --> 01:42:41,360
You're defining where authority stops in your architecture.

2479
01:42:41,360 --> 01:42:43,520
So here's the decision checklist that actually matters,

2480
01:42:43,520 --> 01:42:44,400
and it's short.

2481
01:42:44,400 --> 01:42:46,320
Who owns identity for each tool call?

2482
01:42:46,320 --> 01:42:48,800
The user, the workload, or the platform?

2483
01:42:48,800 --> 01:42:50,640
Where is authority enforced?

2484
01:42:50,640 --> 01:42:54,960
In entroscopes, in APM policies, in the server, in the host, or nowhere,

2485
01:42:54,960 --> 01:42:56,720
what fails closed when things get weird,

2486
01:42:56,720 --> 01:42:59,760
and what is observable enough that you can reconstruct a tool chain

2487
01:42:59,760 --> 01:43:01,360
without trusting the model's story.

2488
01:43:01,360 --> 01:43:04,000
If you can answer those, MCP becomes infrastructure.

2489
01:43:04,000 --> 01:43:06,720
If you can't, MCP becomes another integration pattern

2490
01:43:06,720 --> 01:43:07,760
that scales your chaos.

2491
01:43:07,760 --> 01:43:10,960
If you want to see this implemented the way enterprises actually need it,

2492
01:43:10,960 --> 01:43:13,840
go watch the next episode on building the Entra OBO flow

2493
01:43:13,840 --> 01:43:16,720
and putting APM in front of your MCP server.

2494
01:43:16,720 --> 01:43:19,920
So your agent tools become a governed surface you can defend.