Dataverse MCP: The End of Custom Integration

1
00:00:00,000 --> 00:00:01,480
Your Dataverse is a database.

2
00:00:01,480 --> 00:00:04,200
That is the assumption most organizations are still working with,

3
00:00:04,200 --> 00:00:06,120
but in reality, that assumption is broken.

4
00:00:06,120 --> 00:00:09,000
What Dataverse is actually becoming is something else entirely.

5
00:00:09,000 --> 00:00:12,280
It is turning into an orchestration layer, a context engine,

6
00:00:12,280 --> 00:00:14,680
and the connective tissue between your AI systems,

7
00:00:14,680 --> 00:00:16,560
and everything your organization knows.

8
00:00:16,560 --> 00:00:18,920
Most organizations have not noticed this shift yet.

9
00:00:18,920 --> 00:00:20,880
They are still building custom API wrappers

10
00:00:20,880 --> 00:00:23,520
to connect systems the same way they did five years ago,

11
00:00:23,520 --> 00:00:25,760
where you build a connector and then maintain it forever.

12
00:00:25,760 --> 00:00:28,320
That model worked when integration was a point-to-point problem,

13
00:00:28,320 --> 00:00:29,920
but AI changes everything.

14
00:00:29,920 --> 00:00:31,560
Here is what is happening right now.

15
00:00:31,560 --> 00:00:34,800
Organizations are discovering that the custom connectors they built,

16
00:00:34,800 --> 00:00:37,120
the ones they thought solved their integration problem,

17
00:00:37,120 --> 00:00:38,840
are actually becoming a bottleneck.

18
00:00:38,840 --> 00:00:41,640
Every new AI tool means building a new integration,

19
00:00:41,640 --> 00:00:44,360
and every new platform means rewriting the connector logic.

20
00:00:44,360 --> 00:00:47,360
The maintenance costs keep climbing, yet nobody is keeping score.

21
00:00:47,360 --> 00:00:49,200
By the end of this episode, you will understand

22
00:00:49,200 --> 00:00:51,400
why custom integration is becoming technical debt.

23
00:00:51,400 --> 00:00:52,960
You will see what is replacing it,

24
00:00:52,960 --> 00:00:56,200
and you will know exactly what to do about it in your organization.

25
00:00:56,200 --> 00:00:59,600
The legacy model, why custom integration became the default?

26
00:00:59,600 --> 00:01:00,720
Go back 20 years.

27
00:01:00,720 --> 00:01:02,120
Integration was a real problem.

28
00:01:02,120 --> 00:01:05,240
You had SAP over here, you had Salesforce over there,

29
00:01:05,240 --> 00:01:07,160
and maybe some legacy mainframe system

30
00:01:07,160 --> 00:01:08,880
that nobody fully understood anymore.

31
00:01:08,880 --> 00:01:10,720
None of those systems talked to each other.

32
00:01:10,720 --> 00:01:12,440
Custom connectors solved that.

33
00:01:12,440 --> 00:01:14,760
Developers built bridges by writing an API wrapper,

34
00:01:14,760 --> 00:01:18,000
adding some error handling, and throwing in some retry logic.

35
00:01:18,000 --> 00:01:18,720
It worked.

36
00:01:18,720 --> 00:01:21,440
The systems talked data flowed and problems got solved.

37
00:01:21,440 --> 00:01:22,920
This was not a stupid solution.

38
00:01:22,920 --> 00:01:24,680
It was pragmatic and necessary.

39
00:01:24,680 --> 00:01:26,880
In a world where systems were built in isolation,

40
00:01:26,880 --> 00:01:29,200
custom integration was how you made things work together.

41
00:01:29,200 --> 00:01:32,240
But the model had a structural flaw and nobody saw it coming.

42
00:01:32,240 --> 00:01:34,440
The flaw was this every new system meant new code,

43
00:01:34,440 --> 00:01:36,520
every new AI tool, every new platform,

44
00:01:36,520 --> 00:01:38,400
and every new consumer of your data

45
00:01:38,400 --> 00:01:40,480
meant building another custom connector.

46
00:01:40,480 --> 00:01:42,280
You had to implement authentication again,

47
00:01:42,280 --> 00:01:44,120
you had to figure out the schema again,

48
00:01:44,120 --> 00:01:47,080
and then you had to test it, document it, and maintain it forever.

49
00:01:47,080 --> 00:01:50,040
The fragmentation tax started accumulating silently.

50
00:01:50,040 --> 00:01:54,400
By 2024, most enterprises had built hundreds of custom integrations.

51
00:01:54,400 --> 00:01:55,520
It did not happen by intention.

52
00:01:55,520 --> 00:01:56,240
It just happened.

53
00:01:56,240 --> 00:01:57,960
A team needed Salesforce data,

54
00:01:57,960 --> 00:01:59,800
so they built a Salesforce connector,

55
00:01:59,800 --> 00:02:03,360
and then another team needed Salesforce data connected to ServiceNow,

56
00:02:03,360 --> 00:02:04,520
so they built that bridge.

57
00:02:04,520 --> 00:02:06,520
Then someone else connected it all to Azure,

58
00:02:06,520 --> 00:02:08,360
and the web of custom code grew.

59
00:02:08,360 --> 00:02:09,840
Each connector was a liability.

60
00:02:09,840 --> 00:02:12,800
Each one had dependencies nobody fully documented.

61
00:02:12,800 --> 00:02:14,760
Some were maintained while others were not,

62
00:02:14,760 --> 00:02:17,600
and some had security holds that nobody knew about.

63
00:02:17,600 --> 00:02:19,200
As people left organizations,

64
00:02:19,200 --> 00:02:21,880
the knowledge of how these connectors worked left with them.

65
00:02:21,880 --> 00:02:23,800
The real cost was not the initial build.

66
00:02:23,800 --> 00:02:25,240
It was the maintenance tax.

67
00:02:25,240 --> 00:02:27,000
Organizations discovered they were spending

68
00:02:27,000 --> 00:02:29,120
300% of the original integration costs

69
00:02:29,120 --> 00:02:31,440
just keeping these things running over two years.

70
00:02:31,440 --> 00:02:33,720
They were updating them when underlying systems changed,

71
00:02:33,720 --> 00:02:37,000
fixing bugs, responding to security issues, and patching dependencies.

72
00:02:37,000 --> 00:02:38,160
But here is what is important.

73
00:02:38,160 --> 00:02:39,800
Nobody framed this as a problem.

74
00:02:39,800 --> 00:02:41,480
It was just infrastructure.

75
00:02:41,480 --> 00:02:42,960
It was how integration worked.

76
00:02:42,960 --> 00:02:45,880
You built connectors, you maintained them, and that was the job.

77
00:02:45,880 --> 00:02:47,360
The assumption was always the same.

78
00:02:47,360 --> 00:02:49,800
Build an API wrapper and maintain it forever.

79
00:02:49,800 --> 00:02:51,440
If you needed a new integration,

80
00:02:51,440 --> 00:02:54,040
you just built another wrapper and added it to the pile.

81
00:02:54,040 --> 00:02:56,400
This worked fine when integration was a one-time problem

82
00:02:56,400 --> 00:02:58,440
where you connect system A to system B.

83
00:02:58,440 --> 00:03:00,360
But it breaks down completely when you are connecting

84
00:03:00,360 --> 00:03:02,480
one system to 50 different AI tools,

85
00:03:02,480 --> 00:03:04,160
especially when each of those tools might change

86
00:03:04,160 --> 00:03:06,960
its interface next quarter, and you need to move fast.

87
00:03:06,960 --> 00:03:08,120
That is where the model breaks.

88
00:03:08,120 --> 00:03:09,960
That is where everything changes.

89
00:03:09,960 --> 00:03:11,200
The flow exposed.

90
00:03:11,200 --> 00:03:13,400
Why custom integration fails at scale?

91
00:03:13,400 --> 00:03:16,960
Now, take that single problem and scale it across an entire enterprise.

92
00:03:16,960 --> 00:03:20,240
You have 10 different systems like SIP, Salesforce, ServiceNow,

93
00:03:20,240 --> 00:03:23,440
and Azure, along with legacy applications and HR tools.

94
00:03:23,440 --> 00:03:24,680
When you use custom connectors,

95
00:03:24,680 --> 00:03:26,560
you don't just have 10 problems to solve.

96
00:03:26,560 --> 00:03:29,200
You actually have 10 systems multiplied by every team

97
00:03:29,200 --> 00:03:32,080
that needs that data, which creates a massive web of connections.

98
00:03:32,080 --> 00:03:34,240
Maybe three teams are pulling from Salesforce

99
00:03:34,240 --> 00:03:37,080
while five others need SIP and two more

100
00:03:37,080 --> 00:03:39,400
want real-time access to your data warehouse.

101
00:03:39,400 --> 00:03:42,880
The math gets ugly fast because you aren't building one bridge to Salesforce.

102
00:03:42,880 --> 00:03:43,880
You're building three.

103
00:03:43,880 --> 00:03:45,840
Instead of one SIP connection,

104
00:03:45,840 --> 00:03:48,480
you're managing five, and suddenly those 10 original problems

105
00:03:48,480 --> 00:03:51,440
have turned into hundreds of individual points of failure.

106
00:03:51,440 --> 00:03:53,320
But here's the problem nobody talks about.

107
00:03:53,320 --> 00:03:55,880
Every single one of those connectors is slightly different.

108
00:03:55,880 --> 00:03:58,480
The Salesforce connector built by the first team looks nothing like

109
00:03:58,480 --> 00:03:59,920
the one built by the second,

110
00:03:59,920 --> 00:04:01,680
and they use different error handling,

111
00:04:01,680 --> 00:04:04,920
different security rules and different assumptions about the data.

112
00:04:04,920 --> 00:04:06,600
If a security flaw is found in one,

113
00:04:06,600 --> 00:04:08,720
you have no idea if the others are at risk.

114
00:04:08,720 --> 00:04:10,520
When an underlying system changes,

115
00:04:10,520 --> 00:04:12,520
you won't even know which connectors are broken

116
00:04:12,520 --> 00:04:14,880
until they start failing in the middle of a production run.

117
00:04:14,880 --> 00:04:17,600
Shadow-AT doesn't even begin to describe this mess.

118
00:04:17,600 --> 00:04:18,960
It is integration sprawl,

119
00:04:18,960 --> 00:04:21,400
and it represents a massive amount of organizational debt

120
00:04:21,400 --> 00:04:23,840
piling up in the infrastructure where nobody is looking.

121
00:04:23,840 --> 00:04:26,520
Security teams are usually the first ones to hit the wall.

122
00:04:26,520 --> 00:04:28,720
A security engineer might ask a simple question about

123
00:04:28,720 --> 00:04:30,240
where customer data is flowing,

124
00:04:30,240 --> 00:04:32,040
which is a reasonable thing to want to know.

125
00:04:32,040 --> 00:04:33,480
But instead of a clear answer,

126
00:04:33,480 --> 00:04:36,840
they spend three weeks tracing custom code through a dozen systems.

127
00:04:36,840 --> 00:04:39,840
They find one connector written in Python, another in C-Pars,

128
00:04:39,840 --> 00:04:41,760
and a third that is just a scheduled power shell

129
00:04:41,760 --> 00:04:43,080
script running every night.

130
00:04:43,080 --> 00:04:46,000
Some are hidden inside undocumented power automate flows,

131
00:04:46,000 --> 00:04:49,160
while others are hard-coded on a laptop and pushed through DevOps.

132
00:04:49,160 --> 00:04:51,600
The reality is that they can't govern what they can't see,

133
00:04:51,600 --> 00:04:53,880
and right now they are completely blind.

134
00:04:53,880 --> 00:04:55,880
Audit trails are just as scattered.

135
00:04:55,880 --> 00:04:57,600
One connector might log to Azure,

136
00:04:57,600 --> 00:04:59,360
another to application insights,

137
00:04:59,360 --> 00:05:02,520
and a third to a file share that nobody has checked in months.

138
00:05:02,520 --> 00:05:04,560
If data leaks or someone abuses their access,

139
00:05:04,560 --> 00:05:06,720
trying to piece together the timeline takes weeks,

140
00:05:06,720 --> 00:05:09,440
and even then you probably won't have the full picture.

141
00:05:09,440 --> 00:05:10,920
Then the AI tool start showing up.

142
00:05:10,920 --> 00:05:13,440
Your company decides to connect Claude to Database,

143
00:05:13,440 --> 00:05:15,800
so someone builds a custom connector to make it happen.

144
00:05:15,800 --> 00:05:18,360
Six months later, another team wants to use chat GPT

145
00:05:18,360 --> 00:05:19,560
with that same data,

146
00:05:19,560 --> 00:05:21,240
but they don't know the first connector exists,

147
00:05:21,240 --> 00:05:22,560
so they build a second one.

148
00:05:22,560 --> 00:05:24,760
Now you have two different versions of the same thing,

149
00:05:24,760 --> 00:05:27,560
each with its own security risks and maintenance needs,

150
00:05:27,560 --> 00:05:30,840
and both of them are invisible to the people in charge of governance.

151
00:05:30,840 --> 00:05:32,600
This is the moment organizations realize

152
00:05:32,600 --> 00:05:34,600
they aren't building integrations anymore.

153
00:05:34,600 --> 00:05:36,280
They are building integration debt.

154
00:05:36,280 --> 00:05:39,120
The debt starts small with a few hundred lines of code

155
00:05:39,120 --> 00:05:40,520
that one person understands,

156
00:05:40,520 --> 00:05:44,200
but it compounds every time a new system or user is added to the mix.

157
00:05:44,200 --> 00:05:47,360
Every quarter that passes without documentation makes the pile bigger,

158
00:05:47,360 --> 00:05:48,800
and every time a team member leaves,

159
00:05:48,800 --> 00:05:51,400
they take the knowledge of how to fix it with them.

160
00:05:51,400 --> 00:05:53,960
After five years, you aren't maintaining a system.

161
00:05:53,960 --> 00:05:55,440
You are performing archaeology.

162
00:05:55,440 --> 00:05:58,240
You're trying to figure out why everything crashed at 3am

163
00:05:58,240 --> 00:06:00,360
by reading code that nobody understands anymore,

164
00:06:00,360 --> 00:06:02,920
which is connected to systems that have changed three times

165
00:06:02,920 --> 00:06:04,480
since the script was written.

166
00:06:04,480 --> 00:06:07,320
The team that should have deployed AI automation in weeks

167
00:06:07,320 --> 00:06:09,920
is now spending months just trying to figure out

168
00:06:09,920 --> 00:06:11,520
which connectors are safe to touch.

169
00:06:11,520 --> 00:06:13,040
Security can't track the data,

170
00:06:13,040 --> 00:06:14,840
architecture can't see the landscape,

171
00:06:14,840 --> 00:06:17,160
and the cost to keep it all running is becoming astronomical.

172
00:06:17,160 --> 00:06:20,160
That is what happens when you try to scale a broken model.

173
00:06:20,160 --> 00:06:22,200
What is the model context protocol?

174
00:06:22,200 --> 00:06:25,440
Before we go further, you need to understand what MCP actually is.

175
00:06:25,440 --> 00:06:27,400
It isn't a database, it isn't another API,

176
00:06:27,400 --> 00:06:29,080
and it isn't a traditional connector.

177
00:06:29,080 --> 00:06:31,200
MCP stands for Model Context Protocol.

178
00:06:31,200 --> 00:06:33,680
At its core, it is a standardized way for AI systems

179
00:06:33,680 --> 00:06:35,960
to discover and use the tools you already have.

180
00:06:35,960 --> 00:06:38,640
The big idea here isn't just about how to fetch data,

181
00:06:38,640 --> 00:06:41,200
but how to let an AI see what is available,

182
00:06:41,200 --> 00:06:42,760
understand what it can do,

183
00:06:42,760 --> 00:06:44,920
and perform tasks without needing custom code

184
00:06:44,920 --> 00:06:46,520
for every single scenario.

185
00:06:46,520 --> 00:06:49,040
Anthropic introduced MCP in late 2024,

186
00:06:49,040 --> 00:06:50,160
and within just a few months,

187
00:06:50,160 --> 00:06:53,400
it was adopted by OpenAI, Google, Microsoft, and Amazon.

188
00:06:53,400 --> 00:06:55,840
This happened because every major AI vendor realized

189
00:06:55,840 --> 00:06:57,880
they were facing the same infrastructure nightmare

190
00:06:57,880 --> 00:06:59,280
that ruined the API world.

191
00:06:59,280 --> 00:07:01,760
They knew that if they didn't create a standard early on,

192
00:07:01,760 --> 00:07:03,800
they would end up with Total Chaos later.

193
00:07:03,800 --> 00:07:05,320
The way it works is actually very elegant.

194
00:07:05,320 --> 00:07:07,320
One MCP server shows a set of tools

195
00:07:07,320 --> 00:07:08,960
that are described in a standard format.

196
00:07:08,960 --> 00:07:11,680
Any AI client, whether it's Claude, ChatGPT,

197
00:07:11,680 --> 00:07:13,920
or GitHubCopilot, can connect to that server

198
00:07:13,920 --> 00:07:15,800
and automatically see what tools are there.

199
00:07:15,800 --> 00:07:17,720
It understands what each tool does

200
00:07:17,720 --> 00:07:19,280
and how to use it immediately.

201
00:07:19,280 --> 00:07:22,000
You don't need a custom integration for every client

202
00:07:22,000 --> 00:07:24,880
because you have one server serving many different AI tools.

203
00:07:24,880 --> 00:07:26,200
Think of it like USB-C.

204
00:07:26,200 --> 00:07:29,080
For a long time, every device had its own specific charging cable,

205
00:07:29,080 --> 00:07:31,960
so your phone, laptop, and tablet all needed something different.

206
00:07:31,960 --> 00:07:34,160
Then USB-C arrived and gave us one standard plug

207
00:07:34,160 --> 00:07:35,240
that works for everything.

208
00:07:35,240 --> 00:07:37,440
You no longer need a different cable for every device

209
00:07:37,440 --> 00:07:40,120
because the standard ensures they all play together.

210
00:07:40,120 --> 00:07:43,480
That is exactly what MCP is doing for AI and enterprise software.

211
00:07:43,480 --> 00:07:47,520
Under the hood, MCP uses a lightweight protocol called JSON RPC

212
00:07:47,520 --> 00:07:49,120
that can run over almost any connection,

213
00:07:49,120 --> 00:07:51,000
including HTTP or Web sockets.

214
00:07:51,000 --> 00:07:52,640
The specific way the data travels

215
00:07:52,640 --> 00:07:54,880
doesn't matter as much as the protocol itself.

216
00:07:54,880 --> 00:07:57,160
It provides a standard way for tools to describe themselves,

217
00:07:57,160 --> 00:07:59,040
a standard way for AI to find them,

218
00:07:59,040 --> 00:08:01,880
and a standard way for the tools to report back what happened.

219
00:08:01,880 --> 00:08:03,200
This solves a massive problem

220
00:08:03,200 --> 00:08:05,160
that custom connectors never even touched.

221
00:08:05,160 --> 00:08:07,080
A custom connector only solves the problem

222
00:08:07,080 --> 00:08:09,440
of moving data from point A to point B,

223
00:08:09,440 --> 00:08:10,960
but that is only half the battle.

224
00:08:10,960 --> 00:08:12,520
The harder part is discovery

225
00:08:12,520 --> 00:08:14,720
because the AI needs to know what is available

226
00:08:14,720 --> 00:08:17,120
and what operations are actually safe to perform.

227
00:08:17,120 --> 00:08:18,840
It needs to know its own permissions

228
00:08:18,840 --> 00:08:21,800
and understand exactly which data it can access

229
00:08:21,800 --> 00:08:22,680
and which it can't.

230
00:08:22,680 --> 00:08:24,600
Custom connectors usually bury those details

231
00:08:24,600 --> 00:08:26,120
in documents that nobody reads,

232
00:08:26,120 --> 00:08:27,520
or they don't record them at all.

233
00:08:27,520 --> 00:08:28,880
The AI gets connected,

234
00:08:28,880 --> 00:08:30,800
but then it has no idea what it's allowed to do.

235
00:08:30,800 --> 00:08:32,240
It doesn't know the shape of the data

236
00:08:32,240 --> 00:08:33,720
and it doesn't know if it's about to trigger

237
00:08:33,720 --> 00:08:35,240
a massive financial transaction

238
00:08:35,240 --> 00:08:36,480
or just read a simple file.

239
00:08:36,480 --> 00:08:38,120
MCP makes all of that explicit.

240
00:08:38,120 --> 00:08:40,880
The server tells the AI exactly which tools are exposed,

241
00:08:40,880 --> 00:08:42,000
what parameters they need

242
00:08:42,000 --> 00:08:43,840
and what security rules are in place.

243
00:08:43,840 --> 00:08:46,760
Now, the AI system can actually understand its own boundaries.

244
00:08:46,760 --> 00:08:48,600
It knows what is in scope and what is off limits.

245
00:08:48,600 --> 00:08:50,040
That is the real structural shift.

246
00:08:50,040 --> 00:08:52,800
It isn't about better network speeds or faster APIs.

247
00:08:52,800 --> 00:08:55,320
It is about better discovery and better constraints

248
00:08:55,320 --> 00:08:58,240
that allow AI to move fast while staying completely safe.

249
00:08:58,240 --> 00:09:00,000
This is the change that is going to redefine

250
00:09:00,000 --> 00:09:02,200
enterprise integration forever.

251
00:09:02,200 --> 00:09:04,560
The data verse, MCP connector, what changed?

252
00:09:04,560 --> 00:09:06,440
Microsoft took this standardized protocol

253
00:09:06,440 --> 00:09:07,720
and did something very specific

254
00:09:07,720 --> 00:09:10,560
by building a dedicated data verse MCP server.

255
00:09:10,560 --> 00:09:12,560
In practical terms, this means data verse

256
00:09:12,560 --> 00:09:14,600
is no longer just a static data repository

257
00:09:14,600 --> 00:09:16,440
that requires custom code to reach.

258
00:09:16,440 --> 00:09:19,320
It has become a first-class citizen in the MCP ecosystem,

259
00:09:19,320 --> 00:09:21,640
which changes how every AI agent interacts

260
00:09:21,640 --> 00:09:22,720
with your business data.

261
00:09:22,720 --> 00:09:24,840
Whether you use Claude, GitHub Copilot,

262
00:09:24,840 --> 00:09:27,000
or any other MCP-aware client,

263
00:09:27,000 --> 00:09:28,880
these tools can now connect to data verse

264
00:09:28,880 --> 00:09:31,800
and automatically discover what operations are available.

265
00:09:31,800 --> 00:09:34,000
They understand the governance around those operations

266
00:09:34,000 --> 00:09:35,480
and can use them immediately

267
00:09:35,480 --> 00:09:38,400
or without you ever building a single custom connector.

268
00:09:38,400 --> 00:09:39,480
To make this concrete,

269
00:09:39,480 --> 00:09:40,760
we should look at how things worked

270
00:09:40,760 --> 00:09:42,880
before MCP changed the landscape.

271
00:09:42,880 --> 00:09:45,400
If you wanted an AI tool to access data verse data

272
00:09:45,400 --> 00:09:47,960
in the past, you had to write a rest API wrapper

273
00:09:47,960 --> 00:09:49,560
or a custom connector from scratch.

274
00:09:49,560 --> 00:09:51,680
You were responsible for handling authentication manually

275
00:09:51,680 --> 00:09:53,960
and deciding exactly which tables that wrapper could touch.

276
00:09:53,960 --> 00:09:55,480
You had to write the error handling,

277
00:09:55,480 --> 00:09:56,880
document the API contract,

278
00:09:56,880 --> 00:09:59,480
and bake assumptions into the code about who could do what.

279
00:09:59,480 --> 00:10:00,480
Once that was finished,

280
00:10:00,480 --> 00:10:02,240
you still had to deploy it, test it,

281
00:10:02,240 --> 00:10:03,880
and maintain that code forever.

282
00:10:03,880 --> 00:10:06,440
The problem got worse when you wanted to add a second AI tool

283
00:10:06,440 --> 00:10:07,480
to your workflow.

284
00:10:07,480 --> 00:10:09,160
You would usually have to build another wrapper

285
00:10:09,160 --> 00:10:11,400
with the same logic, but slightly different scaffolding

286
00:10:11,400 --> 00:10:13,720
to satisfy a different authentication flow.

287
00:10:13,720 --> 00:10:16,040
This led to different assumptions about what data to surface

288
00:10:16,040 --> 00:10:17,840
and documentation that often contradicted

289
00:10:17,840 --> 00:10:20,680
the first wrapper in subtle, frustrating ways.

290
00:10:20,680 --> 00:10:22,480
The data verse MCP connector

291
00:10:22,480 --> 00:10:24,640
replaces that entire broken workflow

292
00:10:24,640 --> 00:10:26,000
with something much simpler.

293
00:10:26,000 --> 00:10:28,960
You install a local proxy, configure your tenant ID,

294
00:10:28,960 --> 00:10:31,200
and point your AI client at that proxy

295
00:10:31,200 --> 00:10:32,240
to get everything running.

296
00:10:32,240 --> 00:10:33,920
The proxy handles all the discovery

297
00:10:33,920 --> 00:10:35,800
and understands the data verse security model,

298
00:10:35,800 --> 00:10:38,320
so it can translate between what the client needs

299
00:10:38,320 --> 00:10:39,760
and what the platform provides.

300
00:10:39,760 --> 00:10:42,640
Every client that connects to the system gets the same behavior,

301
00:10:42,640 --> 00:10:43,960
the same security constraints,

302
00:10:43,960 --> 00:10:46,480
and the same permissions model every single time.

303
00:10:46,480 --> 00:10:49,520
This shift matters because the security model in data verse

304
00:10:49,520 --> 00:10:51,360
is incredibly sophisticated.

305
00:10:51,360 --> 00:10:53,480
You have security roles, field level security,

306
00:10:53,480 --> 00:10:55,600
and business units that all work together

307
00:10:55,600 --> 00:10:57,320
alongside organization level settings

308
00:10:57,320 --> 00:10:59,200
to determine who can see what.

309
00:10:59,200 --> 00:11:02,480
A custom connector either respects all that complexity,

310
00:11:02,480 --> 00:11:04,520
which means you have to implement it yourself in code,

311
00:11:04,520 --> 00:11:06,880
or it doesn't, which means you've accidentally created

312
00:11:06,880 --> 00:11:08,640
a massive security bypass.

313
00:11:08,640 --> 00:11:11,240
The data verse MCP connector doesn't bypass your governance

314
00:11:11,240 --> 00:11:12,960
because it actually flows through it.

315
00:11:12,960 --> 00:11:15,240
When an AI agent connects through MCP,

316
00:11:15,240 --> 00:11:17,000
it operates under the specific permissions

317
00:11:17,000 --> 00:11:18,600
of whoever initiated that session.

318
00:11:18,600 --> 00:11:21,320
The security roles apply, the field level security applies,

319
00:11:21,320 --> 00:11:23,760
and the business unit boundaries remain fully intact.

320
00:11:23,760 --> 00:11:26,080
You don't get a special AI connector security model

321
00:11:26,080 --> 00:11:27,880
that's weaker than what a human user has,

322
00:11:27,880 --> 00:11:29,600
but instead you get the same constraints

323
00:11:29,600 --> 00:11:31,560
and audit trails you already trust.

324
00:11:31,560 --> 00:11:34,000
This represents a fundamental structural difference

325
00:11:34,000 --> 00:11:36,160
in how we handle integrations.

326
00:11:36,160 --> 00:11:38,600
Most custom connectors require security teams

327
00:11:38,600 --> 00:11:40,920
to accept a lower bar because they promise

328
00:11:40,920 --> 00:11:43,240
to restrict access on the application side.

329
00:11:43,240 --> 00:11:45,520
They claim they will make sure only trusted tools

330
00:11:45,520 --> 00:11:48,400
can call the API, but that is always a weaker model

331
00:11:48,400 --> 00:11:50,840
than the built-in security data verse offers.

332
00:11:50,840 --> 00:11:53,800
With MCP, you aren't creating a parallel security model

333
00:11:53,800 --> 00:11:55,080
that your team has to manage,

334
00:11:55,080 --> 00:11:57,240
but you are finally using the one you already built.

335
00:11:57,240 --> 00:12:00,160
Setting this up is genuinely straightforward for any team.

336
00:12:00,160 --> 00:12:03,200
You download the Microsoft Power Platform Dataverse MCP tool

337
00:12:03,200 --> 00:12:04,920
from the standard package repository

338
00:12:04,920 --> 00:12:06,640
and install it locally or in a container.

339
00:12:06,640 --> 00:12:09,440
After you give it your tenant ID and connection information,

340
00:12:09,440 --> 00:12:10,960
you simply start the proxy.

341
00:12:10,960 --> 00:12:13,120
Then you configure your AI client,

342
00:12:13,120 --> 00:12:15,480
like Claude Desktop or GitHub Co-Pilot,

343
00:12:15,480 --> 00:12:17,600
to connect to that proxy and start working.

344
00:12:17,600 --> 00:12:18,840
That is the entire process.

345
00:12:18,840 --> 00:12:20,440
Now Claude can talk to Dataverse,

346
00:12:20,440 --> 00:12:22,720
GitHub Co-Pilot can access your CRM data,

347
00:12:22,720 --> 00:12:25,400
and any MCP-aware agent can work with your business data

348
00:12:25,400 --> 00:12:27,040
every single one of those tools uses

349
00:12:27,040 --> 00:12:29,480
the same security model and the same data governance

350
00:12:29,480 --> 00:12:31,320
while leaving behind the same audit trail.

351
00:12:31,320 --> 00:12:33,800
But we need to be clear about what is actually happening here.

352
00:12:33,800 --> 00:12:35,280
This isn't just a convenience upgrade

353
00:12:35,280 --> 00:12:37,560
where you only have to build one connector instead of five.

354
00:12:37,560 --> 00:12:39,080
That is a small tactical benefit,

355
00:12:39,080 --> 00:12:41,200
but the strategic benefit is much larger.

356
00:12:41,200 --> 00:12:43,880
The real shift is that Dataverse becomes an AI ready platform

357
00:12:43,880 --> 00:12:46,440
without requiring custom code for every new use case.

358
00:12:46,440 --> 00:12:48,800
You don't need a separate integration for Co-Pilot

359
00:12:48,800 --> 00:12:50,960
or a different one for Claude or a custom connector

360
00:12:50,960 --> 00:12:53,120
for whatever new tool appears next quarter.

361
00:12:53,120 --> 00:12:55,920
The platform itself is ready, the data is discoverable,

362
00:12:55,920 --> 00:12:57,200
the permissions are clear,

363
00:12:57,200 --> 00:12:58,880
and the audit trail is automatic.

364
00:12:58,880 --> 00:13:01,200
This is what true restructuring looks like.

365
00:13:01,200 --> 00:13:05,080
The performance reality, why MCP is slower, but it doesn't matter.

366
00:13:05,080 --> 00:13:06,720
There is something you need to hear early

367
00:13:06,720 --> 00:13:10,080
before the enthusiasm for this technology builds too high.

368
00:13:10,080 --> 00:13:12,360
MCP is slower than direct rest calls

369
00:13:12,360 --> 00:13:14,840
when you look at raw latency and pure speed.

370
00:13:14,840 --> 00:13:16,960
If you measure the milliseconds per request,

371
00:13:16,960 --> 00:13:20,320
a custom API integration is going to win every single time.

372
00:13:20,320 --> 00:13:22,080
The JSON RPC protocol adds overhead

373
00:13:22,080 --> 00:13:24,320
because every call has to go through an extra hop.

374
00:13:24,320 --> 00:13:26,280
The MCP layer sits between the client

375
00:13:26,280 --> 00:13:28,720
and the underlying system where it translates requests,

376
00:13:28,720 --> 00:13:31,080
unpacks responses and manages the conversation.

377
00:13:31,080 --> 00:13:32,760
Those milliseconds add up quickly

378
00:13:32,760 --> 00:13:35,280
and benchmarks show that you are looking at a performance hit

379
00:13:35,280 --> 00:13:39,160
of 15 to 25% compared to hitting a rest end point directly.

380
00:13:39,160 --> 00:13:40,600
That isn't a trivial difference

381
00:13:40,600 --> 00:13:43,480
and in certain environments, it is a very real problem.

382
00:13:43,480 --> 00:13:46,080
For some systems, this latency matters deeply.

383
00:13:46,080 --> 00:13:47,840
If you are running real time trading systems

384
00:13:47,840 --> 00:13:50,160
or millisecond sensitive financial operations,

385
00:13:50,160 --> 00:13:51,680
you can't afford that extra weight.

386
00:13:51,680 --> 00:13:54,400
High frequency data streams where every hundred microseconds

387
00:13:54,400 --> 00:13:56,800
of latency compounds into a real cost

388
00:13:56,800 --> 00:13:58,800
require the fastest path to the data.

389
00:13:58,800 --> 00:14:01,520
In those cases, custom integration and direct API calls

390
00:14:01,520 --> 00:14:02,920
are still the right answer.

391
00:14:02,920 --> 00:14:05,480
But here is what is actually happening in your organization.

392
00:14:05,480 --> 00:14:06,960
You probably stopped measuring latency

393
00:14:06,960 --> 00:14:10,120
and caring about request milliseconds sometime around 2018.

394
00:14:10,120 --> 00:14:12,840
What you are actually optimizing for now has changed completely.

395
00:14:12,840 --> 00:14:15,520
The real metric today is the cost per decision.

396
00:14:15,520 --> 00:14:17,960
We aren't looking at milliseconds per call anymore,

397
00:14:17,960 --> 00:14:20,800
but rather the cost per AI driven outcome.

398
00:14:20,800 --> 00:14:22,680
You should be measuring the time it takes

399
00:14:22,680 --> 00:14:24,520
to go from having a business question

400
00:14:24,520 --> 00:14:27,160
to having a working answer implemented in your workflow.

401
00:14:27,160 --> 00:14:28,800
This is where the conversation about performance

402
00:14:28,800 --> 00:14:30,120
completely changes.

403
00:14:30,120 --> 00:14:34,160
MCP can cut your language model token usage by 50 to 80%.

404
00:14:34,160 --> 00:14:37,120
That isn't a typo, but is actually the documented range

405
00:14:37,120 --> 00:14:38,960
for these types of implementations.

406
00:14:38,960 --> 00:14:40,280
The reason for this is straightforward

407
00:14:40,280 --> 00:14:42,360
because with a custom rest connector,

408
00:14:42,360 --> 00:14:44,560
you have to stuff every detail into the prompt.

409
00:14:44,560 --> 00:14:47,560
You give the AI model a schema, handed a list of endpoints

410
00:14:47,560 --> 00:14:49,760
and explain what each one does while hoping it figures out

411
00:14:49,760 --> 00:14:51,120
which parameters to pass.

412
00:14:51,120 --> 00:14:53,760
The AI has to hold all of that in its working memory,

413
00:14:53,760 --> 00:14:56,120
which burns through tokens just to understand

414
00:14:56,120 --> 00:14:58,640
what is available to it, dynamic schema serving changes

415
00:14:58,640 --> 00:15:00,040
that dynamic entirely.

416
00:15:00,040 --> 00:15:02,720
MCP lets the AI ask what is available as it goes

417
00:15:02,720 --> 00:15:05,240
so it doesn't need to memorize the entire schema at once.

418
00:15:05,240 --> 00:15:08,560
The server gives back only what is relevant to the current task,

419
00:15:08,560 --> 00:15:12,320
which means the AI gets smaller, focused context chunks

420
00:15:12,320 --> 00:15:14,200
instead of a giant information dump.

421
00:15:14,200 --> 00:15:17,080
This results in fewer tokens and a much more efficient process.

422
00:15:17,080 --> 00:15:18,480
When you look at this at scale,

423
00:15:18,480 --> 00:15:20,320
that is where your actual costs live.

424
00:15:20,320 --> 00:15:22,320
It isn't about milliseconds per request,

425
00:15:22,320 --> 00:15:24,400
but token consumption per operation.

426
00:15:24,400 --> 00:15:27,560
If you run 1,000 AI operations a month through dataverse,

427
00:15:27,560 --> 00:15:29,240
the difference between token efficient

428
00:15:29,240 --> 00:15:32,240
and token wasteful integration adds up to thousands of dollars.

429
00:15:32,240 --> 00:15:34,000
But there is something deeper happening here

430
00:15:34,000 --> 00:15:35,400
than just saving money.

431
00:15:35,400 --> 00:15:37,640
You aren't just optimizing for token cost,

432
00:15:37,640 --> 00:15:40,600
but you are optimizing for what is actually possible to achieve.

433
00:15:40,600 --> 00:15:43,000
With custom connectors, the AI doesn't really discover

434
00:15:43,000 --> 00:15:45,480
what is available because it is just reading a document

435
00:15:45,480 --> 00:15:46,280
and guessing.

436
00:15:46,280 --> 00:15:49,000
With MCP, the AI knows exactly what tools exist

437
00:15:49,000 --> 00:15:50,240
and what permissions govern them

438
00:15:50,240 --> 00:15:52,120
because the server tells it directly.

439
00:15:52,120 --> 00:15:55,160
That means the AI can operate with much more autonomy.

440
00:15:55,160 --> 00:15:56,480
It can attempt operations.

441
00:15:56,480 --> 00:15:58,880
It wasn't explicitly trained for and chain tools

442
00:15:58,880 --> 00:15:59,880
together in novel ways.

443
00:15:59,880 --> 00:16:02,040
It can reason about what is possible and what isn't

444
00:16:02,040 --> 00:16:04,960
without constantly asking a human for permission or clarification.

445
00:16:04,960 --> 00:16:07,080
This is the structural point I want to emphasize.

446
00:16:07,080 --> 00:16:08,840
Yes, MCP adds latency.

447
00:16:08,840 --> 00:16:11,160
And for bulk operations moving terabytes of data,

448
00:16:11,160 --> 00:16:12,560
you should still use rest.

449
00:16:12,560 --> 00:16:14,840
Direct calls win for high throughput tasks.

450
00:16:14,840 --> 00:16:17,080
But for AI-driven discovery and autonomous agents

451
00:16:17,080 --> 00:16:19,000
that need to understand their own constraints,

452
00:16:19,000 --> 00:16:20,800
MCP wins decisively.

453
00:16:20,800 --> 00:16:22,920
The slowness is simply the price of capability.

454
00:16:22,920 --> 00:16:25,080
It is a trade you should be willing to make.

455
00:16:25,080 --> 00:16:26,360
And when you look at the economics,

456
00:16:26,360 --> 00:16:28,400
you aren't really trading anything at all.

457
00:16:28,400 --> 00:16:29,320
The economics.

458
00:16:29,320 --> 00:16:31,920
Why organizations are retiring custom connectors?

459
00:16:31,920 --> 00:16:33,920
Let's talk about what actually moves decisions

460
00:16:33,920 --> 00:16:35,160
inside an organization.

461
00:16:35,160 --> 00:16:38,200
It isn't the architecture or the governance frameworks.

462
00:16:38,200 --> 00:16:40,520
It's the money, the time, and the spreadsheet

463
00:16:40,520 --> 00:16:42,200
that gets presented to the board.

464
00:16:42,200 --> 00:16:44,400
Organizations are retiring custom connectors

465
00:16:44,400 --> 00:16:46,280
because the economics are undeniable.

466
00:16:46,280 --> 00:16:48,520
Start with implementation time.

467
00:16:48,520 --> 00:16:50,480
If you want to build a custom API wrapper,

468
00:16:50,480 --> 00:16:53,000
so an AI tool can access data versus data,

469
00:16:53,000 --> 00:16:55,320
you should plan for four to eight weeks.

470
00:16:55,320 --> 00:16:56,640
That is the industry standard.

471
00:16:56,640 --> 00:16:59,440
You need an architecture review and a security assessment.

472
00:16:59,440 --> 00:17:01,240
Then you have to handle development, testing,

473
00:17:01,240 --> 00:17:04,080
and documentation before you even think about deployment.

474
00:17:04,080 --> 00:17:06,720
Eight weeks is actually being optimistic for anything meaningful.

475
00:17:06,720 --> 00:17:08,080
Now add a second AI tool.

476
00:17:08,080 --> 00:17:09,520
You have to repeat that entire process

477
00:17:09,520 --> 00:17:11,000
for another four to eight weeks.

478
00:17:11,000 --> 00:17:13,160
Maybe the authentication mechanism is different

479
00:17:13,160 --> 00:17:15,400
or perhaps the error handling and schema mapping

480
00:17:15,400 --> 00:17:16,680
require a new approach.

481
00:17:16,680 --> 00:17:18,720
You are looking at another team and another budget cycle

482
00:17:18,720 --> 00:17:20,160
for another two months of work.

483
00:17:20,160 --> 00:17:22,880
With Dataverse MCP, that second AI tool takes days,

484
00:17:22,880 --> 00:17:24,360
not weeks, days.

485
00:17:24,360 --> 00:17:25,880
The MCP server already exists.

486
00:17:25,880 --> 00:17:27,600
It already handles authentication

487
00:17:27,600 --> 00:17:30,040
and it already understands the Dataverse security model.

488
00:17:30,040 --> 00:17:31,640
You simply configure the new client

489
00:17:31,640 --> 00:17:34,040
to point at that server and run a quick test.

490
00:17:34,040 --> 00:17:35,400
That is not a minor difference.

491
00:17:35,400 --> 00:17:36,880
It is an order of magnitude.

492
00:17:36,880 --> 00:17:39,640
When you multiply that across an entire organization,

493
00:17:39,640 --> 00:17:41,720
the scale of the problem becomes clear.

494
00:17:41,720 --> 00:17:44,280
If you have five new AI initiatives queued up,

495
00:17:44,280 --> 00:17:47,440
custom connectors turn that into a 40-week project at minimum.

496
00:17:47,440 --> 00:17:48,880
It will probably take 50 weeks

497
00:17:48,880 --> 00:17:51,520
once you account for rework and interdependencies.

498
00:17:51,520 --> 00:17:54,520
With MCP, that same workload takes a couple of weeks total.

499
00:17:54,520 --> 00:17:56,040
This allows your team to spend their time

500
00:17:56,040 --> 00:17:58,040
building actual AI experiences

501
00:17:58,040 --> 00:17:59,760
instead of fixing infrastructure plumbing.

502
00:17:59,760 --> 00:18:01,800
But implementation time is just the beginning.

503
00:18:01,800 --> 00:18:04,960
The real economics hit when you look at the maintenance burden.

504
00:18:04,960 --> 00:18:07,560
Every custom connector you build requires ongoing care.

505
00:18:07,560 --> 00:18:10,440
When Dataverse adds a new field to a critical entity,

506
00:18:10,440 --> 00:18:12,440
you have to search through your entire portfolio

507
00:18:12,440 --> 00:18:14,880
to find out which connectors just broke.

508
00:18:14,880 --> 00:18:16,640
When a security vulnerability is discovered

509
00:18:16,640 --> 00:18:17,720
in the rest API layer,

510
00:18:17,720 --> 00:18:19,920
you have to audit every single connector one by one.

511
00:18:19,920 --> 00:18:21,360
If the team member who understood

512
00:18:21,360 --> 00:18:24,040
how a specific connector worked leaves the company,

513
00:18:24,040 --> 00:18:26,200
that knowledge walks out the door with them.

514
00:18:26,200 --> 00:18:28,040
Each custom connector is a point of friction

515
00:18:28,040 --> 00:18:29,600
and a place where things can fail.

516
00:18:29,600 --> 00:18:31,840
It is a dependency that needs constant monitoring

517
00:18:31,840 --> 00:18:33,720
and an artifact that needs updating

518
00:18:33,720 --> 00:18:35,680
every time the underlying systems change.

519
00:18:35,680 --> 00:18:38,800
If you multiply this across 50 or 100 custom connectors,

520
00:18:38,800 --> 00:18:40,240
you create a maintenance burden

521
00:18:40,240 --> 00:18:42,720
that grows faster than your development team can handle.

522
00:18:42,720 --> 00:18:44,560
Dataverse MCP inverts this model.

523
00:18:44,560 --> 00:18:46,200
You maintain one server, one code base,

524
00:18:46,200 --> 00:18:47,960
and one set of security policies.

525
00:18:47,960 --> 00:18:49,880
There is only one audit trail to follow.

526
00:18:49,880 --> 00:18:51,600
When the underlying systems change,

527
00:18:51,600 --> 00:18:53,600
you update the MCP server once

528
00:18:53,600 --> 00:18:55,840
and every client automatically gets that update.

529
00:18:55,840 --> 00:18:58,480
You no longer have 50 different implementations to fix.

530
00:18:58,480 --> 00:19:00,600
The early Adopter Data tells a very clear story.

531
00:19:00,600 --> 00:19:03,920
Organizations with 20 to 100 power platform developers

532
00:19:03,920 --> 00:19:06,480
are reporting monthly MCP consumption costs

533
00:19:06,480 --> 00:19:08,800
between $208 hundred dollars.

534
00:19:08,800 --> 00:19:10,880
That is the entire infrastructure cost

535
00:19:10,880 --> 00:19:12,760
to provide AI access to Dataverse

536
00:19:12,760 --> 00:19:14,680
across an entire development organization.

537
00:19:14,680 --> 00:19:16,200
Now compare that to the alternative

538
00:19:16,200 --> 00:19:18,160
of maintaining custom connectors.

539
00:19:18,160 --> 00:19:20,320
One analyst estimates the fully loaded cost

540
00:19:20,320 --> 00:19:22,760
of maintaining a single enterprise integration

541
00:19:22,760 --> 00:19:24,520
at about $15,000 per year.

542
00:19:24,520 --> 00:19:26,000
That includes salary, infrastructure,

543
00:19:26,000 --> 00:19:27,760
testing, and security reviews.

544
00:19:27,760 --> 00:19:29,600
If you have 50 custom connectors,

545
00:19:29,600 --> 00:19:31,960
you are spending $750,000 annually

546
00:19:31,960 --> 00:19:33,160
just to keep the lights on.

547
00:19:33,160 --> 00:19:34,640
The math gets worse over time.

548
00:19:34,640 --> 00:19:36,480
The first connector costs money to build,

549
00:19:36,480 --> 00:19:38,240
and the maintenance tax starts small,

550
00:19:38,240 --> 00:19:39,360
but then it compounds.

551
00:19:39,360 --> 00:19:40,520
Every year more teams touch it

552
00:19:40,520 --> 00:19:42,040
and more complexity accumulates.

553
00:19:42,040 --> 00:19:43,960
By year three, you are spending three times

554
00:19:43,960 --> 00:19:46,880
the original build cost just to keep that one connector alive.

555
00:19:46,880 --> 00:19:49,720
This is why organizations are retiring custom connectors.

556
00:19:49,720 --> 00:19:51,040
It isn't for philosophical reasons

557
00:19:51,040 --> 00:19:54,480
or because they discovered MCP is theoretically superior.

558
00:19:54,480 --> 00:19:56,360
They are moving because the economics of the old way

559
00:19:56,360 --> 00:19:57,040
are brutal.

560
00:19:57,040 --> 00:19:59,520
With custom connectors, your AI integration cost rises

561
00:19:59,520 --> 00:20:00,320
exponentially.

562
00:20:00,320 --> 00:20:02,640
Every new tool and every new system multiplies

563
00:20:02,640 --> 00:20:05,520
the burden until the cost curve accelerates out of control.

564
00:20:05,520 --> 00:20:07,080
By the time you realize there is a problem,

565
00:20:07,080 --> 00:20:08,240
you have built an infrastructure

566
00:20:08,240 --> 00:20:09,640
that is expensive to maintain

567
00:20:09,640 --> 00:20:11,480
and nearly impossible to change.

568
00:20:11,480 --> 00:20:13,800
With MCP, your integration cost stays flat.

569
00:20:13,800 --> 00:20:15,240
You have one server and many clients

570
00:20:15,240 --> 00:20:16,680
which means your overhead is fixed.

571
00:20:16,680 --> 00:20:19,120
The cost per new AI initiative approaches zero

572
00:20:19,120 --> 00:20:21,080
because the only variable is the complexity

573
00:20:21,080 --> 00:20:22,640
of the use case, not the plumbing.

574
00:20:22,640 --> 00:20:24,640
That is why organizations are moving.

575
00:20:24,640 --> 00:20:28,920
The governance gap, why DLP policies don't cover MCP yet?

576
00:20:28,920 --> 00:20:31,720
A massive gap is opening up in enterprise governance right now,

577
00:20:31,720 --> 00:20:33,840
but the problem isn't the model context protocol itself.

578
00:20:33,840 --> 00:20:36,520
The issue is how your organization's existing security controls

579
00:20:36,520 --> 00:20:37,600
actually handle it.

580
00:20:37,600 --> 00:20:39,080
Your data loss prevention policies

581
00:20:39,080 --> 00:20:40,960
exist for a very specific reason.

582
00:20:40,960 --> 00:20:42,520
They protect sensitive information

583
00:20:42,520 --> 00:20:44,200
and prevent customer data from flowing

584
00:20:44,200 --> 00:20:45,920
to unauthorized SaaS platforms

585
00:20:45,920 --> 00:20:47,560
while also stopping intellectual property

586
00:20:47,560 --> 00:20:49,360
from leaking to your competitors.

587
00:20:49,360 --> 00:20:51,200
These policies enforce compliance requirements

588
00:20:51,200 --> 00:20:53,120
around financial data and health information

589
00:20:53,120 --> 00:20:54,520
and because they've been battle tested

590
00:20:54,520 --> 00:20:57,120
across thousands of organizations, they generally work.

591
00:20:57,120 --> 00:20:58,760
But in reality, they don't see MCP.

592
00:20:58,760 --> 00:21:01,800
Your current DLP policies are built to understand connectors

593
00:21:01,800 --> 00:21:03,280
so they check the Salesforce connector

594
00:21:03,280 --> 00:21:06,360
or the SharePoint connector and block the data verse one.

595
00:21:06,360 --> 00:21:08,520
They understand flow actions in Power Automate

596
00:21:08,520 --> 00:21:10,840
and know exactly which SaaS applications your organization

597
00:21:10,840 --> 00:21:12,160
is allowed to integrate with.

598
00:21:12,160 --> 00:21:13,720
These systems have full visibility

599
00:21:13,720 --> 00:21:15,760
into your approved and blocked vendor lists

600
00:21:15,760 --> 00:21:17,640
because they work through patent recognition.

601
00:21:17,640 --> 00:21:19,560
If the system sees a Slack connector,

602
00:21:19,560 --> 00:21:21,080
it applies the Slack policy

603
00:21:21,080 --> 00:21:24,120
and if it sees Outlook, it applies the Outlook policy.

604
00:21:24,120 --> 00:21:26,440
MCP servers simply don't show up in their taxonomy.

605
00:21:26,440 --> 00:21:27,840
They aren't Slack or Outlook

606
00:21:27,840 --> 00:21:29,560
and they aren't a named SaaS vendor

607
00:21:29,560 --> 00:21:31,640
with a pre-built connector that your security team

608
00:21:31,640 --> 00:21:33,160
can easily identify.

609
00:21:33,160 --> 00:21:35,520
An MCP server is a generic protocol endpoint

610
00:21:35,520 --> 00:21:37,240
that could expose almost anything,

611
00:21:37,240 --> 00:21:39,360
ranging from legitimate business data

612
00:21:39,360 --> 00:21:42,120
to a misconfigured server that's leaking more than it should.

613
00:21:42,120 --> 00:21:44,840
Your DLP policies can't distinguish between these cases

614
00:21:44,840 --> 00:21:47,000
because MCP servers don't match the patents

615
00:21:47,000 --> 00:21:48,920
your security rules were built to recognize.

616
00:21:48,920 --> 00:21:50,920
This isn't a flaw in the protocol

617
00:21:50,920 --> 00:21:53,640
but it is a major gap in how organizations

618
00:21:53,640 --> 00:21:55,280
govern AI-driven data access.

619
00:21:55,280 --> 00:21:56,680
Nobody actually planned for this

620
00:21:56,680 --> 00:22:00,480
because most DLP policies were written years before MCP even existed.

621
00:22:00,480 --> 00:22:02,040
The people who designed your policies

622
00:22:02,040 --> 00:22:04,240
didn't account for a standardized protocol

623
00:22:04,240 --> 00:22:07,560
where AI agents could discover and use tools dynamically.

624
00:22:07,560 --> 00:22:09,400
They built their controls around known platforms

625
00:22:09,400 --> 00:22:10,640
and integration patterns

626
00:22:10,640 --> 00:22:13,280
and now MCP is breaking every one of those assumptions.

627
00:22:13,280 --> 00:22:15,000
Microsoft is aware of this problem

628
00:22:15,000 --> 00:22:16,640
which is why they are currently building

629
00:22:16,640 --> 00:22:18,080
advanced connector policies.

630
00:22:18,080 --> 00:22:19,880
ACP is supposed to be the definitive answer

631
00:22:19,880 --> 00:22:22,800
because it's designed to understand MCP servers specifically

632
00:22:22,800 --> 00:22:24,400
and see them whenever they are in use.

633
00:22:24,400 --> 00:22:25,960
The goal is to give security teams

634
00:22:25,960 --> 00:22:28,440
governance over what an MCP server can expose

635
00:22:28,440 --> 00:22:29,720
and who is allowed to use it.

636
00:22:29,720 --> 00:22:31,240
In theory, the logic is solid,

637
00:22:31,240 --> 00:22:33,480
allowing you to define policies at the MCP level

638
00:22:33,480 --> 00:22:35,760
so you can permit one server while blocking another.

639
00:22:35,760 --> 00:22:38,120
You could even specify that a tool within a server

640
00:22:38,120 --> 00:22:39,800
is available for finance teams

641
00:22:39,800 --> 00:22:42,520
but completely blocked for anyone on an external network.

642
00:22:42,520 --> 00:22:44,080
That's the theory, anyway.

643
00:22:44,080 --> 00:22:45,520
The real problem here is timing.

644
00:22:45,520 --> 00:22:48,400
Since ACP is still in preview as of early 2026,

645
00:22:48,400 --> 00:22:50,560
it isn't generally available for most users yet.

646
00:22:50,560 --> 00:22:53,240
This means if you're deploying data versus MCP today,

647
00:22:53,240 --> 00:22:54,680
you're putting it into an environment

648
00:22:54,680 --> 00:22:57,600
where your security controls are essentially blind to it.

649
00:22:57,600 --> 00:23:00,120
You can't govern it through your standard DLP policies

650
00:23:00,120 --> 00:23:01,920
so you have to build manual workarounds

651
00:23:01,920 --> 00:23:04,640
like restricted access lists and governance workflows

652
00:23:04,640 --> 00:23:06,560
that sit outside your normal framework.

653
00:23:06,560 --> 00:23:09,440
Even when ACP finally reaches general availability,

654
00:23:09,440 --> 00:23:11,760
it has a limitation that security teams

655
00:23:11,760 --> 00:23:13,360
are already starting to grumble about.

656
00:23:13,360 --> 00:23:16,280
You can block an entire MCP server or you can allow it

657
00:23:16,280 --> 00:23:18,280
but granular control over individual tools

658
00:23:18,280 --> 00:23:20,640
within that server is a feature that's coming later.

659
00:23:20,640 --> 00:23:22,200
Right now it's an all or nothing choice

660
00:23:22,200 --> 00:23:24,680
at the server level, think through what that actually means

661
00:23:24,680 --> 00:23:25,640
for your operations.

662
00:23:25,640 --> 00:23:27,280
If you've deployed an MCP server

663
00:23:27,280 --> 00:23:29,400
that exposes 10 different tools

664
00:23:29,400 --> 00:23:31,960
and one of them accesses sensitive HR data

665
00:23:31,960 --> 00:23:34,040
while the rest are low-risk support queries,

666
00:23:34,040 --> 00:23:35,160
you're in a tough spot.

667
00:23:35,160 --> 00:23:36,680
With current ACP capabilities,

668
00:23:36,680 --> 00:23:37,960
you can't allow the support tools

669
00:23:37,960 --> 00:23:39,760
while blocking the finance operations

670
00:23:39,760 --> 00:23:41,560
so you're stuck choosing between

671
00:23:41,560 --> 00:23:44,040
shutting down the whole system or allowing everything.

672
00:23:44,040 --> 00:23:45,680
This creates accountability problems

673
00:23:45,680 --> 00:23:48,240
that shouldn't exist in a professional environment.

674
00:23:48,240 --> 00:23:50,440
When an AI agent acts through an MCP server,

675
00:23:50,440 --> 00:23:52,000
the audit trail shows the human user

676
00:23:52,000 --> 00:23:53,160
who started the session

677
00:23:53,160 --> 00:23:54,440
but it doesn't show the agent

678
00:23:54,440 --> 00:23:55,960
or what that agent decided to do.

679
00:23:55,960 --> 00:23:57,880
You can see that Sarah opened a session

680
00:23:57,880 --> 00:23:59,080
and data was accessed

681
00:23:59,080 --> 00:24:00,880
but you can't see if Claude decided

682
00:24:00,880 --> 00:24:03,240
to pull customer financial records on its own.

683
00:24:03,240 --> 00:24:05,400
You have no way to tell if Sarah instructed the AI

684
00:24:05,400 --> 00:24:06,240
to do that

685
00:24:06,240 --> 00:24:08,400
or if the agent made that decision autonomously.

686
00:24:08,400 --> 00:24:09,880
That's a massive governance problem

687
00:24:09,880 --> 00:24:11,520
and a total lack of accountability,

688
00:24:11,520 --> 00:24:13,720
which is exactly why this gap matters so much.

689
00:24:13,720 --> 00:24:15,600
Your security team simply cannot govern

690
00:24:15,600 --> 00:24:18,000
what it can't see with the right level of detail.

691
00:24:18,000 --> 00:24:20,560
The identity problem.

692
00:24:20,560 --> 00:24:22,800
Who is responsible for AI actions?

693
00:24:22,800 --> 00:24:24,080
In the old integration model,

694
00:24:24,080 --> 00:24:25,560
the identity trail was always clean.

695
00:24:25,560 --> 00:24:27,440
When an API call came from somewhere,

696
00:24:27,440 --> 00:24:29,160
that source had a name like a service account

697
00:24:29,160 --> 00:24:30,720
or a specific user ID.

698
00:24:30,720 --> 00:24:31,720
You followed the trail

699
00:24:31,720 --> 00:24:34,360
and knew exactly who or what made the request

700
00:24:34,360 --> 00:24:37,520
because ownership was explicit and responsibility was clear.

701
00:24:37,520 --> 00:24:39,440
The audit log would show that a specific identity

702
00:24:39,440 --> 00:24:40,920
called an endpoint at a certain time

703
00:24:40,920 --> 00:24:42,160
with specific parameters.

704
00:24:42,160 --> 00:24:43,280
If something went wrong,

705
00:24:43,280 --> 00:24:44,880
you had a clear starting point

706
00:24:44,880 --> 00:24:46,760
and an actor you could hold accountable.

707
00:24:46,760 --> 00:24:48,080
You could revoke their access

708
00:24:48,080 --> 00:24:50,040
or retrain the responsible party

709
00:24:50,040 --> 00:24:51,880
because the entire accountability model

710
00:24:51,880 --> 00:24:54,680
worked on the idea that identity was never a mystery.

711
00:24:54,680 --> 00:24:56,560
MCP breaks that model completely.

712
00:24:56,560 --> 00:24:58,760
Here is what the process looks like now.

713
00:24:58,760 --> 00:25:00,240
A human user starts a session

714
00:25:00,240 --> 00:25:02,200
and connects to the dataverse MCP server

715
00:25:02,200 --> 00:25:04,440
through an agent like Claude or GitHub Co-Pilot.

716
00:25:04,440 --> 00:25:05,960
The agent then starts working by discovering

717
00:25:05,960 --> 00:25:08,160
available tools and reasoning about which operations

718
00:25:08,160 --> 00:25:09,600
will accomplish the user's goal.

719
00:25:09,600 --> 00:25:11,800
It invokes a tool, data moves,

720
00:25:11,800 --> 00:25:14,160
and suddenly, a sensitive customer list is pulled

721
00:25:14,160 --> 00:25:16,120
or a financial transaction is queued up.

722
00:25:16,120 --> 00:25:17,720
The audit log records the timestamp

723
00:25:17,720 --> 00:25:19,080
and the result of the operation,

724
00:25:19,080 --> 00:25:20,680
but it attributes every single action

725
00:25:20,680 --> 00:25:22,520
to the human who started the session.

726
00:25:22,520 --> 00:25:24,800
It doesn't mention the agent or the system at all.

727
00:25:24,800 --> 00:25:26,200
It only mentions the human.

728
00:25:26,200 --> 00:25:28,120
This creates what security professionals call

729
00:25:28,120 --> 00:25:29,400
an attribution gap.

730
00:25:29,400 --> 00:25:32,040
You might see that Sarah opened a dataverse MCP session

731
00:25:32,040 --> 00:25:33,680
at 2.15 pm on Tuesday

732
00:25:33,680 --> 00:25:36,560
and that financial records were accessed two minutes later.

733
00:25:36,560 --> 00:25:37,800
The records show a data flow

734
00:25:37,800 --> 00:25:38,720
that should have never happened

735
00:25:38,720 --> 00:25:40,280
according to your security policies,

736
00:25:40,280 --> 00:25:42,720
but the audit trail can't answer the most important question.

737
00:25:42,720 --> 00:25:44,280
You don't know if Sarah intentionally

738
00:25:44,280 --> 00:25:45,720
decided to export that data

739
00:25:45,720 --> 00:25:47,840
or if the AI agent pulled it autonomously

740
00:25:47,840 --> 00:25:50,240
because it thought it needed the information.

741
00:25:50,240 --> 00:25:52,680
This matters for more than just internal rules

742
00:25:52,680 --> 00:25:54,640
as it impacts regulatory accountability

743
00:25:54,640 --> 00:25:56,000
and legal liability.

744
00:25:56,000 --> 00:25:57,000
You need to be able to prove

745
00:25:57,000 --> 00:25:59,040
who authorized a sensitive operation

746
00:25:59,040 --> 00:26:00,600
for your compliance certifications.

747
00:26:00,600 --> 00:26:02,840
If Sarah intentionally pulled customer data

748
00:26:02,840 --> 00:26:04,320
she wasn't supposed to see,

749
00:26:04,320 --> 00:26:05,840
that's a clear security incident

750
00:26:05,840 --> 00:26:07,640
and a violation of your policies.

751
00:26:07,640 --> 00:26:09,440
You would need to investigate the situation

752
00:26:09,440 --> 00:26:11,760
and likely terminate her access immediately.

753
00:26:11,760 --> 00:26:14,560
But if Claude decided it needed that data to answer a question

754
00:26:14,560 --> 00:26:17,160
and pulled it without Sarah realizing what was happening,

755
00:26:17,160 --> 00:26:19,040
you have a completely different problem.

756
00:26:19,040 --> 00:26:20,240
That's a system failure

757
00:26:20,240 --> 00:26:22,280
where a permission boundary wasn't enforced

758
00:26:22,280 --> 00:26:23,760
and it points to a governance issue

759
00:26:23,760 --> 00:26:25,160
with the MCP server itself.

760
00:26:25,160 --> 00:26:27,400
In that scenario, Sarah might have done nothing wrong

761
00:26:27,400 --> 00:26:30,040
while the agent acted way outside its intended scope.

762
00:26:30,040 --> 00:26:31,200
The audit trail doesn't tell you

763
00:26:31,200 --> 00:26:32,800
which of those things actually happened

764
00:26:32,800 --> 00:26:35,600
and that kind of ambiguity is dangerous for any business.

765
00:26:35,600 --> 00:26:39,280
Microsoft's proposed answer is EntraID agent identities.

766
00:26:39,280 --> 00:26:40,880
The idea is pretty straightforward

767
00:26:40,880 --> 00:26:42,640
because instead of attributing operations

768
00:26:42,640 --> 00:26:45,400
to the human user, they get tagged to the agent itself.

769
00:26:45,400 --> 00:26:46,640
Claude gets its own identity

770
00:26:46,640 --> 00:26:48,320
in your Microsoft Entra directory

771
00:26:48,320 --> 00:26:51,400
and GitHub co-pilot becomes a first class security principle.

772
00:26:51,400 --> 00:26:52,920
They can be assigned their own permissions

773
00:26:52,920 --> 00:26:53,920
and audited separately

774
00:26:53,920 --> 00:26:56,400
so their actions show up in the log under their own names.

775
00:26:56,400 --> 00:26:57,760
This solves the attribution problem

776
00:26:57,760 --> 00:26:59,880
by letting the audit log show exactly

777
00:26:59,880 --> 00:27:01,560
when Claude accessed records

778
00:27:01,560 --> 00:27:02,840
and what parameters it used.

779
00:27:02,840 --> 00:27:04,680
You can finally govern the AI separately

780
00:27:04,680 --> 00:27:05,960
from the human user

781
00:27:05,960 --> 00:27:07,520
and enforce different permission boundaries

782
00:27:07,520 --> 00:27:08,360
for different agents.

783
00:27:08,360 --> 00:27:10,880
This allows you to see what each agent is authorised

784
00:27:10,880 --> 00:27:13,600
to do and compare it against what it actually did in the system.

785
00:27:13,600 --> 00:27:15,320
The problem once again is the timing.

786
00:27:15,320 --> 00:27:17,720
EntraID agent identities are still in preview

787
00:27:17,720 --> 00:27:19,960
as of the first quarter of 2026

788
00:27:19,960 --> 00:27:21,920
so they aren't generally available yet.

789
00:27:21,920 --> 00:27:24,280
Organizations that are deploying MCP today

790
00:27:24,280 --> 00:27:26,000
don't have this capability

791
00:27:26,000 --> 00:27:27,680
which means they have to find other ways

792
00:27:27,680 --> 00:27:28,880
to manage the risk.

793
00:27:28,880 --> 00:27:30,960
Most of these workarounds aren't very elegant.

794
00:27:30,960 --> 00:27:32,720
You might use approval workflows

795
00:27:32,720 --> 00:27:34,600
where sensitive operations require a human

796
00:27:34,600 --> 00:27:36,560
to click confirm before anything happens.

797
00:27:36,560 --> 00:27:38,720
Some teams use human in the loop gates

798
00:27:38,720 --> 00:27:40,880
or detailed logging of agent reasoning

799
00:27:40,880 --> 00:27:42,160
so they can try to reconstruct

800
00:27:42,160 --> 00:27:43,240
why a decision was made.

801
00:27:43,240 --> 00:27:46,040
These are just compensating controls that work well enough

802
00:27:46,040 --> 00:27:47,760
but they are far from perfect.

803
00:27:47,760 --> 00:27:49,960
This is the exact point where technical problems

804
00:27:49,960 --> 00:27:51,320
turn into organizational problems.

805
00:27:51,320 --> 00:27:52,680
You can't just deploy MCP

806
00:27:52,680 --> 00:27:54,720
and hope your governance works out on its own.

807
00:27:54,720 --> 00:27:55,920
You need explicit policies

808
00:27:55,920 --> 00:27:57,840
for how AI agents should behave

809
00:27:57,840 --> 00:28:00,240
and a clear separation between what agents can do

810
00:28:00,240 --> 00:28:01,720
and what humans can tell them to do.

811
00:28:01,720 --> 00:28:03,800
You need audit trails that capture the intent

812
00:28:03,800 --> 00:28:06,160
behind an action rather than just the action itself.

813
00:28:06,160 --> 00:28:09,000
Until those EntraID agent identities are ready for production

814
00:28:09,000 --> 00:28:10,280
you need interim controls

815
00:28:10,280 --> 00:28:12,680
that slow things down enough to keep everyone safe.

816
00:28:12,680 --> 00:28:14,560
This is why your governance teams need to start thinking

817
00:28:14,560 --> 00:28:17,040
about MCP in a completely different way.

818
00:28:17,040 --> 00:28:20,000
The security implications, MCP as a new attack surface

819
00:28:20,000 --> 00:28:22,320
but there is something else happening right now

820
00:28:22,320 --> 00:28:24,560
and it is a shift that gets far less attention

821
00:28:24,560 --> 00:28:26,120
than it actually deserves.

822
00:28:26,120 --> 00:28:28,520
MCP servers are becoming high value targets

823
00:28:28,520 --> 00:28:30,280
for anyone looking to break into your systems.

824
00:28:30,280 --> 00:28:33,280
Think about what these servers actually expose to the world.

825
00:28:33,280 --> 00:28:36,320
They reveal your business logic, your data access patterns

826
00:28:36,320 --> 00:28:38,280
and exactly what operations your organization

827
00:28:38,280 --> 00:28:39,480
considers safe to perform.

828
00:28:39,480 --> 00:28:41,120
They essentially become a detailed map

829
00:28:41,120 --> 00:28:42,720
of your internal capabilities

830
00:28:42,720 --> 00:28:45,480
and that map is exactly what an attacker wants to find.

831
00:28:45,480 --> 00:28:48,040
Their goal isn't necessarily to steal data right away

832
00:28:48,040 --> 00:28:50,120
but to understand how to move through your systems

833
00:28:50,120 --> 00:28:52,440
and see what permissions are available to exploit.

834
00:28:52,440 --> 00:28:55,520
An MCP server is never just a simple pass through for data.

835
00:28:55,520 --> 00:28:56,760
It is a concentration point.

836
00:28:56,760 --> 00:28:58,520
It acts as a single endpoint

837
00:28:58,520 --> 00:29:00,600
where dozens of tools, operations and paths

838
00:29:00,600 --> 00:29:03,400
to sensitive information all live together in one place.

839
00:29:03,400 --> 00:29:05,000
If that server is compromised

840
00:29:05,000 --> 00:29:08,080
an attacker doesn't just get access to one single capability.

841
00:29:08,080 --> 00:29:10,440
They get access to every single one of them.

842
00:29:10,440 --> 00:29:12,520
Every tool you have exposed through that server suddenly

843
00:29:12,520 --> 00:29:14,640
becomes a weapon that can be used against you.

844
00:29:14,640 --> 00:29:17,800
This is where supply chain risk starts to feel very real.

845
00:29:17,800 --> 00:29:21,200
MCP servers depend on external libraries, registries and code

846
00:29:21,200 --> 00:29:23,160
that your team didn't write and doesn't control.

847
00:29:23,160 --> 00:29:26,160
If a malicious library finds its way into your build pipeline

848
00:29:26,160 --> 00:29:29,560
or if a compromised package is published to a repository you use,

849
00:29:29,560 --> 00:29:33,600
your MCP server imports that threat directly into your infrastructure.

850
00:29:33,600 --> 00:29:36,960
It brings the compromise straight into your organization's data,

851
00:29:36,960 --> 00:29:39,880
access layer, without anyone realizing it happened.

852
00:29:39,880 --> 00:29:42,320
But there is a much more subtle attack vector

853
00:29:42,320 --> 00:29:44,640
that security researchers are starting to worry about

854
00:29:44,640 --> 00:29:46,000
and it's called tool poisoning.

855
00:29:46,000 --> 00:29:47,640
The way it works is actually quite simple

856
00:29:47,640 --> 00:29:51,080
an attacker doesn't even need to break into your MCP server directly.

857
00:29:51,080 --> 00:29:53,520
Instead, they can compromise any minor MCP tool

858
00:29:53,520 --> 00:29:55,160
that your server happens to depend on.

859
00:29:55,160 --> 00:29:58,280
It doesn't have to be a critical tool or something obviously dangerous.

860
00:29:58,280 --> 00:30:00,920
It could be a simple logging utility or a small script

861
00:30:00,920 --> 00:30:02,640
that formats text responses.

862
00:30:02,640 --> 00:30:04,480
Because it looks peripheral and harmless,

863
00:30:04,480 --> 00:30:07,000
the compromised tool sits inside your MCP server

864
00:30:07,000 --> 00:30:10,120
and remains completely invisible during a normal audit.

865
00:30:10,120 --> 00:30:12,080
Once it's inside, the compromised tool

866
00:30:12,080 --> 00:30:15,440
instructs the AI agent to do something completely unexpected.

867
00:30:15,440 --> 00:30:17,680
It might tell the agent to pull sensitive records,

868
00:30:17,680 --> 00:30:19,440
access systems it shouldn't touch,

869
00:30:19,440 --> 00:30:23,080
or invoke tools in a specific chain that creates a backdoor.

870
00:30:23,080 --> 00:30:25,960
The attack travels through the agent's own decision making process.

871
00:30:25,960 --> 00:30:28,080
Disguised is a legitimate response from a tool.

872
00:30:28,080 --> 00:30:32,120
The agent follows the instruction because it was told to trust that tool

873
00:30:32,120 --> 00:30:35,240
and the audit trail will simply show that the agent made a choice.

874
00:30:35,240 --> 00:30:36,560
But that choice wasn't autonomous.

875
00:30:36,560 --> 00:30:37,840
It was coerced.

876
00:30:37,840 --> 00:30:39,560
Then we have to talk about prompt injection

877
00:30:39,560 --> 00:30:41,960
which doesn't require compromising any code at all.

878
00:30:41,960 --> 00:30:45,200
Imagine your dataverse contains thousands of customer support records

879
00:30:45,200 --> 00:30:47,600
with long text fields and detailed notes.

880
00:30:47,600 --> 00:30:50,720
An attacker can embed hidden instructions inside one of those records

881
00:30:50,720 --> 00:30:53,480
using language that is subtle and easy to miss.

882
00:30:53,480 --> 00:30:57,400
When the MCP server exposes that specific record to an AI agent,

883
00:30:57,400 --> 00:30:59,680
the agent sees the legitimate support ticket

884
00:30:59,680 --> 00:31:01,760
and the hidden command at the same time.

885
00:31:01,760 --> 00:31:05,240
That instruction might tell the agent to pull a customer's financial data

886
00:31:05,240 --> 00:31:07,640
or send private information to an external system.

887
00:31:07,640 --> 00:31:10,000
The agent follows the instruction because it is part of the context

888
00:31:10,000 --> 00:31:11,520
it is currently reasoning over.

889
00:31:11,520 --> 00:31:14,240
It has no way of knowing the command came from an adversary

890
00:31:14,240 --> 00:31:18,080
so it treats the malicious text as part of the data it is supposed to process.

891
00:31:18,080 --> 00:31:20,000
When you look at the audit trail later,

892
00:31:20,000 --> 00:31:22,160
it looks like the agent just decided to do it.

893
00:31:22,160 --> 00:31:26,400
In reality, the agent was being manipulated by the very data it was trying to analyze.

894
00:31:26,400 --> 00:31:30,720
These attacks do not require massive sophistication or expensive zero day exploits.

895
00:31:30,720 --> 00:31:34,920
They only require an understanding of how AI systems reason about trust and context.

896
00:31:34,920 --> 00:31:38,040
Attackers know that an MCP server will often expose tools

897
00:31:38,040 --> 00:31:41,960
without validating where they came from or checking what they are telling the agents to do.

898
00:31:41,960 --> 00:31:44,360
The need for strict governance becomes obvious here.

899
00:31:44,360 --> 00:31:46,760
MCP security is not a problem with the protocol itself,

900
00:31:46,760 --> 00:31:48,000
but a problem with the tools.

901
00:31:48,000 --> 00:31:50,680
It comes down to what you choose to expose through the server

902
00:31:50,680 --> 00:31:53,000
and how you maintain control over those choices.

903
00:31:53,000 --> 00:31:55,880
An over-privileged server that offers too many capabilities

904
00:31:55,880 --> 00:31:59,000
creates a blast radius that is almost impossible to contain.

905
00:31:59,000 --> 00:32:01,800
One compromised tool can enable a dozen different attacks

906
00:32:01,800 --> 00:32:04,640
and one poisoned record can change how your agents behave.

907
00:32:04,640 --> 00:32:08,480
This is why the shift in how we think about security has become so urgent.

908
00:32:08,480 --> 00:32:11,400
You cannot just connect dataverse to an MCP server

909
00:32:11,400 --> 00:32:13,760
and assume the security will handle itself.

910
00:32:13,760 --> 00:32:17,200
You have to think critically about which tools are safe to expose

911
00:32:17,200 --> 00:32:20,240
and understand exactly what damage they could cause if they were misused.

912
00:32:20,240 --> 00:32:23,640
You have to validate the integrity of every piece of code you're running.

913
00:32:23,640 --> 00:32:27,080
Most importantly, you have to implement controls that limit what a tool can do

914
00:32:27,080 --> 00:32:29,520
even if the agent using it has been manipulated.

915
00:32:29,520 --> 00:32:32,280
This is exactly why moving to an MCP architecture

916
00:32:32,280 --> 00:32:34,600
requires a high level of security maturity.

917
00:32:34,600 --> 00:32:37,400
The architecture shift from point to point to hub and spoke.

918
00:32:37,400 --> 00:32:40,000
The old way of building architecture was defined by sprawl.

919
00:32:40,000 --> 00:32:42,920
It was unsystematic and mostly happened by accident.

920
00:32:42,920 --> 00:32:46,360
You had a Salesforce instance, a dataverse environment, a data warehouse

921
00:32:46,360 --> 00:32:48,360
and maybe a few legacy applications.

922
00:32:48,360 --> 00:32:51,040
To make them work together, you built custom connectors.

923
00:32:51,040 --> 00:32:53,760
You probably had dozens or even hundreds of them.

924
00:32:53,760 --> 00:32:56,880
Each one was a point to point connection where System A talked to System B

925
00:32:56,880 --> 00:32:59,840
through a bridge built for that one specific conversation.

926
00:32:59,840 --> 00:33:02,800
The problem is that this kind of complexity isn't linear.

927
00:33:02,800 --> 00:33:05,920
It compounds if you have three systems and three apps using them.

928
00:33:05,920 --> 00:33:07,720
You have nine integration points to manage.

929
00:33:07,720 --> 00:33:11,640
But if you move to 10 systems and 10 apps, you suddenly have 100 points of failure.

930
00:33:11,640 --> 00:33:16,040
The number of problems grows exponentially with every new piece of software you add.

931
00:33:16,040 --> 00:33:20,640
Eventually, the network becomes so tangled that nobody in the company fully understands how it works.

932
00:33:20,640 --> 00:33:25,440
When something inevitably breaks, you have no idea which downstream teams are going to be affected.

933
00:33:25,440 --> 00:33:27,840
The new architecture model inverts this entire mess.

934
00:33:27,840 --> 00:33:31,480
Instead of those messy point to point lines, you build a hub and spoke system.

935
00:33:31,480 --> 00:33:34,000
You create one MCP server for each business domain,

936
00:33:34,000 --> 00:33:37,680
such as a server for sales, one for support, and another for finance.

937
00:33:37,680 --> 00:33:42,880
Each server exposes only the tools and data relevant to that specific part of the business.

938
00:33:42,880 --> 00:33:46,000
Now your AI clients, like Claude or GitHub Co-Pilot,

939
00:33:46,000 --> 00:33:48,600
don't connect to the underlying databases anymore.

940
00:33:48,600 --> 00:33:51,800
They connect to the MCP servers, discover what is available there,

941
00:33:51,800 --> 00:33:53,760
and perform their work through that single interface.

942
00:33:53,760 --> 00:33:59,160
This patent isn't actually new and it has been proven to work in almost every other layer of infrastructure.

943
00:33:59,160 --> 00:34:02,240
API gateways work this way, service meshes work this way,

944
00:34:02,240 --> 00:34:04,360
and even message brokers follow this logic.

945
00:34:04,360 --> 00:34:08,240
You create one central point that knows how to talk to a family of related systems.

946
00:34:08,240 --> 00:34:09,960
The clients talk to that center,

947
00:34:09,960 --> 00:34:13,200
and the center handles the headache of connecting to everything else.

948
00:34:13,200 --> 00:34:15,080
The architectural benefit here is huge.

949
00:34:15,080 --> 00:34:17,360
When Salesforce decides to change its API,

950
00:34:17,360 --> 00:34:20,440
you only have to update the sales MCP server one time.

951
00:34:20,440 --> 00:34:23,840
Every client using that server will automatically work with the new version.

952
00:34:23,840 --> 00:34:26,520
You don't have to go back and rewrite 50 different integrations

953
00:34:26,520 --> 00:34:28,560
because you only have one to worry about.

954
00:34:28,560 --> 00:34:32,040
The same principle applies to your data warehouse, your legacy systems,

955
00:34:32,040 --> 00:34:33,360
and everything else in your stack.

956
00:34:33,360 --> 00:34:36,280
One server per domain handles many different clients,

957
00:34:36,280 --> 00:34:39,240
but there is a governance benefit here that is even more important,

958
00:34:39,240 --> 00:34:41,480
though it's often less obvious to teams at first.

959
00:34:41,480 --> 00:34:43,800
When you rely on point-to-point integrations,

960
00:34:43,800 --> 00:34:46,080
your governance is scattered all over the place.

961
00:34:46,080 --> 00:34:48,760
Security policies live in 10 different locations.

962
00:34:48,760 --> 00:34:51,760
One connector might use strong encryption while another one doesn't.

963
00:34:51,760 --> 00:34:53,760
One team might log their data to the cloud

964
00:34:53,760 --> 00:34:56,520
while another team saves it to a local file share.

965
00:34:56,520 --> 00:34:58,840
You end up with a mix of OAuth and API keys,

966
00:34:58,840 --> 00:35:01,280
and your audit trails are fragmented across the dozen systems.

967
00:35:01,280 --> 00:35:03,400
You don't have a real policy. You have policy chaos.

968
00:35:03,400 --> 00:35:07,720
A hub and spoke model changes the game because it gives you one place to enforce the rules.

969
00:35:07,720 --> 00:35:12,440
One MCP server for a domain means you have one set of rate limits and one clean audit trail.

970
00:35:12,440 --> 00:35:14,960
It gives you a single place to manage approval workflows,

971
00:35:14,960 --> 00:35:17,200
data classification, and access controls.

972
00:35:17,200 --> 00:35:20,160
When you need to update a security policy, you change it in one spot,

973
00:35:20,160 --> 00:35:23,120
and every client using that server sees the change immediately.

974
00:35:23,120 --> 00:35:26,520
This is the architectural shift that actually matters for the long term.

975
00:35:26,520 --> 00:35:29,400
You are moving away from seeing integration as a point problem

976
00:35:29,400 --> 00:35:31,320
where you solve each connection one by one.

977
00:35:31,320 --> 00:35:34,040
Instead, you are treating integration as a platform problem.

978
00:35:34,040 --> 00:35:36,920
You are building a layer that handles the complexity once

979
00:35:36,920 --> 00:35:39,640
so that your users don't have to deal with it over and over again.

980
00:35:39,640 --> 00:35:41,280
The implication here is subtle,

981
00:35:41,280 --> 00:35:44,400
but it completely changes what your team is actually building every day.

982
00:35:44,400 --> 00:35:47,040
In a point to point world, you are just building connectors.

983
00:35:47,040 --> 00:35:51,720
You are solving small specific problems like getting system A to talk to system B.

984
00:35:51,720 --> 00:35:54,840
That mindset focuses on speed and getting the immediate task done.

985
00:35:54,840 --> 00:35:56,840
It doesn't care about sustainability or governance

986
00:35:56,840 --> 00:35:58,440
because those things aren't visible

987
00:35:58,440 --> 00:36:00,880
when you're just looking at one single bridge.

988
00:36:00,880 --> 00:36:03,480
With a hub and spoke model, you are building a platform.

989
00:36:03,480 --> 00:36:07,520
You are designing a surface and thinking about how a domain should be governed.

990
00:36:07,520 --> 00:36:10,240
You are forced to think about how multiple different clients

991
00:36:10,240 --> 00:36:12,000
will use these tools in the future.

992
00:36:12,000 --> 00:36:15,320
You start planning for how to absorb changes before they even happen.

993
00:36:15,320 --> 00:36:18,920
This mindset is what allows you to scale as demand grows.

994
00:36:18,920 --> 00:36:22,040
The organizations that are actually going to succeed with MCP

995
00:36:22,040 --> 00:36:23,840
are the ones that make this mental shift.

996
00:36:23,840 --> 00:36:27,000
They stop looking at integration as a series of connector problems

997
00:36:27,000 --> 00:36:29,280
and start seeing it as a platform challenge.

998
00:36:29,280 --> 00:36:31,920
Dataverse is context, not just storage.

999
00:36:31,920 --> 00:36:34,160
Most organizations are stuck in an old mental model

1000
00:36:34,160 --> 00:36:36,520
where they view dataverse as nothing more than a database.

1001
00:36:36,520 --> 00:36:39,280
They see it as a repository, a place to store records,

1002
00:36:39,280 --> 00:36:42,400
or a bucket where you dump customer data and log transactions.

1003
00:36:42,400 --> 00:36:46,160
In this traditional view, you persist everything the company needs to remember.

1004
00:36:46,160 --> 00:36:48,760
And then, when you need that information, you query it.

1005
00:36:48,760 --> 00:36:50,920
It is a simple cycle of storage and retrieval,

1006
00:36:50,920 --> 00:36:53,640
which is exactly how databases have worked for decades.

1007
00:36:53,640 --> 00:36:54,880
But that model is ending.

1008
00:36:54,880 --> 00:36:57,200
Dataverse isn't becoming less of a database,

1009
00:36:57,200 --> 00:36:59,920
but it is certainly becoming something much more significant.

1010
00:36:59,920 --> 00:37:02,040
It is transforming into a context layer,

1011
00:37:02,040 --> 00:37:06,520
serving as the semantic foundation for how your organization's AI actually understands itself.

1012
00:37:06,520 --> 00:37:09,040
This isn't just about where the data lives anymore,

1013
00:37:09,040 --> 00:37:10,960
but rather how that data carries meaning

1014
00:37:10,960 --> 00:37:14,120
and what specific connections exist between different entities.

1015
00:37:14,120 --> 00:37:17,680
It defines the business logic, explains why certain fields exist,

1016
00:37:17,680 --> 00:37:21,000
and outlines the constraints that govern how they are used.

1017
00:37:21,000 --> 00:37:24,120
Think about the difference between a human and a machine looking at a table.

1018
00:37:24,120 --> 00:37:27,600
A database optimized for people doesn't really care about deep descriptions

1019
00:37:27,600 --> 00:37:30,000
because the field might be named Act2Ball.

1020
00:37:30,000 --> 00:37:31,440
And you already know what that is.

1021
00:37:31,440 --> 00:37:34,360
You've seen it a thousand times, you understand it intuitively,

1022
00:37:34,360 --> 00:37:37,480
and whether or not there is a tooltip in the interface doesn't change much.

1023
00:37:37,480 --> 00:37:40,080
The human sees the data within a visual context,

1024
00:37:40,080 --> 00:37:41,600
like a form or a dashboard,

1025
00:37:41,600 --> 00:37:44,840
and that surrounding interface tells them exactly what they are looking at.

1026
00:37:44,840 --> 00:37:47,720
An AI system doesn't have the luxury of a contextual interface

1027
00:37:47,720 --> 00:37:51,240
because it only sees the schema, the field names, and the data types.

1028
00:37:51,240 --> 00:37:53,840
If a field is labeled ACT-Ball,

1029
00:37:53,840 --> 00:37:57,560
the AI doesn't automatically know if that represents a customer's personal balance

1030
00:37:57,560 --> 00:38:00,600
or an internal clearing account used for backend processing.

1031
00:38:00,600 --> 00:38:03,800
It has no idea if that field should be visible to the support team,

1032
00:38:03,800 --> 00:38:07,160
or if changing that number triggers a massive chain of business processes.

1033
00:38:07,160 --> 00:38:09,120
The AI understands the technical definition,

1034
00:38:09,120 --> 00:38:12,720
but it is completely blind to the actual business meaning.

1035
00:38:12,720 --> 00:38:16,080
The model context protocol changes this dynamic entirely,

1036
00:38:16,080 --> 00:38:18,360
because MCP exposes your schema dynamically,

1037
00:38:18,360 --> 00:38:20,720
the quality of your metadata becomes immediately visible

1038
00:38:20,720 --> 00:38:23,360
and carries massive consequences for your results.

1039
00:38:23,360 --> 00:38:26,480
An AI system can now ask what a specific field represents

1040
00:38:26,480 --> 00:38:28,880
and the server responds with the description you wrote.

1041
00:38:28,880 --> 00:38:30,960
If that description is cryptic or lazy,

1042
00:38:30,960 --> 00:38:32,560
the AI is going to struggle,

1043
00:38:32,560 --> 00:38:34,840
but if it's clear and focused on business logic,

1044
00:38:34,840 --> 00:38:36,520
the AI finally understands.

1045
00:38:36,520 --> 00:38:38,800
This is the fundamental shift you have to make.

1046
00:38:38,800 --> 00:38:41,160
You aren't just storing data points anymore.

1047
00:38:41,160 --> 00:38:44,280
You are curating semantic meaning for a non-human intelligence.

1048
00:38:44,280 --> 00:38:47,560
You are encoding the way your organization thinks into a structure

1049
00:38:47,560 --> 00:38:49,920
that an AI can actually reason over.

1050
00:38:49,920 --> 00:38:52,760
Field descriptions are suddenly the most important part of your setup,

1051
00:38:52,760 --> 00:38:54,160
not because users need them,

1052
00:38:54,160 --> 00:38:56,560
but because the AI requires them to function.

1053
00:38:56,560 --> 00:38:59,560
These descriptions need to be written for how a large language model

1054
00:38:59,560 --> 00:39:03,920
processes language, which means moving away from technical jargon and database short-hand.

1055
00:39:03,920 --> 00:39:06,640
You need to use clear, concise business language

1056
00:39:06,640 --> 00:39:08,440
that explains what a field represents

1057
00:39:08,440 --> 00:39:10,400
and why it exists in the first place.

1058
00:39:10,400 --> 00:39:13,920
When an LLM reads account balance as of last reconciliation

1059
00:39:13,920 --> 00:39:16,000
used for reporting and fraud detection,

1060
00:39:16,000 --> 00:39:17,480
it understands the purpose,

1061
00:39:17,480 --> 00:39:20,960
but when it reads active, bell, it understands nothing.

1062
00:39:20,960 --> 00:39:23,120
Relationship definitions have to change as well.

1063
00:39:23,120 --> 00:39:24,280
In a traditional database,

1064
00:39:24,280 --> 00:39:25,920
relationships are just structural links

1065
00:39:25,920 --> 00:39:29,120
enforced by foreign keys that stay invisible to the average user.

1066
00:39:29,120 --> 00:39:32,720
In an AI context, those relationships are semantic pathways

1067
00:39:32,720 --> 00:39:36,480
that help the AI understand how different parts of your business connect.

1068
00:39:36,480 --> 00:39:39,640
If you explicitly define that accounts relate to opportunities

1069
00:39:39,640 --> 00:39:41,240
and those relate to activities,

1070
00:39:41,240 --> 00:39:44,680
the AI can traverse those links together its own context.

1071
00:39:44,680 --> 00:39:46,880
It begins to understand your business structure implicitly

1072
00:39:46,880 --> 00:39:49,920
because you took the time to make those relationships explicit.

1073
00:39:49,920 --> 00:39:51,800
The same logic applies to your business rules,

1074
00:39:51,800 --> 00:39:54,320
validation steps and workflow triggers.

1075
00:39:54,320 --> 00:39:56,800
Usually this logic is buried in code, hidden in plugins

1076
00:39:56,800 --> 00:39:59,840
or tucked away inside power automate flows where the AI can't see it.

1077
00:39:59,840 --> 00:40:02,720
If you expose which business rules apply to which entities,

1078
00:40:02,720 --> 00:40:05,840
the AI starts to understand the constraints of your organization.

1079
00:40:05,840 --> 00:40:08,000
It learns that certain operations require approval

1080
00:40:08,000 --> 00:40:11,080
or that changing one field might cause a cascade of effects.

1081
00:40:11,080 --> 00:40:13,720
It begins to operate within your organizational boundaries

1082
00:40:13,720 --> 00:40:16,680
because you made those structures visible through metadata.

1083
00:40:16,680 --> 00:40:19,640
This changes everything about how we handle data governance

1084
00:40:19,640 --> 00:40:21,960
for years you've been optimizing your data

1085
00:40:21,960 --> 00:40:25,480
so humans can read it on forms or so developers can write fast queries.

1086
00:40:25,480 --> 00:40:28,680
Continuing that same approach under MCP is a major mistake

1087
00:40:28,680 --> 00:40:31,880
because you now need to optimize for an AI's ability to reason.

1088
00:40:31,880 --> 00:40:34,720
Your data structures must support autonomous discovery

1089
00:40:34,720 --> 00:40:36,760
and your descriptions must be precise enough

1090
00:40:36,760 --> 00:40:39,040
that an AI can make confident choices.

1091
00:40:39,040 --> 00:40:41,960
This is the deeper requirement that most organizations miss

1092
00:40:41,960 --> 00:40:45,120
and it isn't a technical hurdle, it's an organizational one.

1093
00:40:45,120 --> 00:40:48,360
Data modeling for AI, the hidden cost of poor schema.

1094
00:40:48,360 --> 00:40:50,360
Large language models are incredibly sensitive

1095
00:40:50,360 --> 00:40:51,960
to how you package information.

1096
00:40:51,960 --> 00:40:54,600
Though that isn't always obvious until you watch a system fail.

1097
00:40:54,600 --> 00:40:58,360
If you give an AI a dataverse table with 50 fields but no descriptions,

1098
00:40:58,360 --> 00:41:01,120
you're essentially handing it a puzzle with missing pieces.

1099
00:41:01,120 --> 00:41:03,360
Imagine field names like FLD001

1100
00:41:03,360 --> 00:41:06,480
or cryptic codes from a legacy system built in 1997

1101
00:41:06,480 --> 00:41:09,040
that nobody on your current team even remembers.

1102
00:41:09,040 --> 00:41:11,400
Without context or explained relationships,

1103
00:41:11,400 --> 00:41:13,960
the AI just sees a flat list of attributes

1104
00:41:13,960 --> 00:41:17,120
with no way to know what is sensitive or what actually matters.

1105
00:41:17,120 --> 00:41:19,360
It might have the permissions to access the data

1106
00:41:19,360 --> 00:41:21,320
but it doesn't understand the business context

1107
00:41:21,320 --> 00:41:23,680
or the constraints governing that information.

1108
00:41:23,680 --> 00:41:26,680
In that scenario, the AI is going to do one of two things.

1109
00:41:26,680 --> 00:41:28,360
It will either make a lot of mistakes

1110
00:41:28,360 --> 00:41:30,600
or it will ask you for permission every five seconds.

1111
00:41:30,600 --> 00:41:33,440
The system becomes brittle, requiring explicit instructions

1112
00:41:33,440 --> 00:41:34,920
for every tiny operation

1113
00:41:34,920 --> 00:41:37,600
because it lacks the foundation to make its own decisions.

1114
00:41:37,600 --> 00:41:40,200
You end up with an AI that can technically reach your data

1115
00:41:40,200 --> 00:41:42,880
but practically has no idea how to use it effectively.

1116
00:41:42,880 --> 00:41:44,960
Now compare that to an AI working with a table

1117
00:41:44,960 --> 00:41:47,720
where every field has a clear business readable description.

1118
00:41:47,720 --> 00:41:51,040
When relationships are defined and sensitive fields are clearly marked,

1119
00:41:51,040 --> 00:41:54,600
the AI sees a map of your business rather than just a list of numbers.

1120
00:41:54,600 --> 00:41:56,640
It knows which fields are safe to expose,

1121
00:41:56,640 --> 00:41:58,880
it understands the implications of its actions

1122
00:41:58,880 --> 00:42:01,080
and it can chain complex operations together.

1123
00:42:01,080 --> 00:42:02,680
The difference isn't the data itself

1124
00:42:02,680 --> 00:42:05,480
but rather how that data is presented to the model.

1125
00:42:05,480 --> 00:42:06,960
This is a context engineering problem.

1126
00:42:06,960 --> 00:42:08,880
You can have the highest data quality in the world

1127
00:42:08,880 --> 00:42:10,480
with perfect values in every single row

1128
00:42:10,480 --> 00:42:12,960
but if your schema is opaque, the AI is useless.

1129
00:42:12,960 --> 00:42:16,360
Organizations that jump into MCP without doing this foundational work

1130
00:42:16,360 --> 00:42:18,200
usually end up disappointed very quickly.

1131
00:42:18,200 --> 00:42:20,760
They connect their tools, expect instant efficiency

1132
00:42:20,760 --> 00:42:22,920
and then get frustrated when the AI makes mistakes

1133
00:42:22,920 --> 00:42:24,640
or constantly asks for clarification.

1134
00:42:24,640 --> 00:42:26,680
They usually blame the tool or the connector

1135
00:42:26,680 --> 00:42:29,880
but the real culprit is almost always the underlying schema.

1136
00:42:29,880 --> 00:42:31,680
The real cost here isn't technical.

1137
00:42:31,680 --> 00:42:34,160
It's the weight of 20 years of data modeling choices made

1138
00:42:34,160 --> 00:42:36,480
without ever considering an AI consumer.

1139
00:42:36,480 --> 00:42:38,120
Most of your dataverse implementation

1140
00:42:38,120 --> 00:42:40,600
was likely built for humans who use forms, reports,

1141
00:42:40,600 --> 00:42:42,680
and dashboards to find their way around.

1142
00:42:42,680 --> 00:42:45,400
A person sees a label that says "Account Balance"

1143
00:42:45,400 --> 00:42:47,160
and they know exactly what to do,

1144
00:42:47,160 --> 00:42:49,880
regardless of what the actual database field is named.

1145
00:42:49,880 --> 00:42:51,880
But the AI doesn't see your beautiful UI.

1146
00:42:51,880 --> 00:42:53,360
It only sees your metadata.

1147
00:42:53,360 --> 00:42:55,000
If that metadata is poor,

1148
00:42:55,000 --> 00:42:57,960
the AI's entire understanding of your business will be poor as well.

1149
00:42:57,960 --> 00:42:59,840
The best practice here is simple to understand

1150
00:42:59,840 --> 00:43:02,040
but requires a lot of discipline to actually execute.

1151
00:43:02,040 --> 00:43:03,920
You have to start writing metadata specifically

1152
00:43:03,920 --> 00:43:06,560
for an LLM to read rather than for a developer

1153
00:43:06,560 --> 00:43:08,080
who already knows the system.

1154
00:43:08,080 --> 00:43:10,160
Field descriptions should be complete such as

1155
00:43:10,160 --> 00:43:12,880
total balance of all accounts held by this customer,

1156
00:43:12,880 --> 00:43:14,640
updated nightly for credit decisions,

1157
00:43:14,640 --> 00:43:16,560
instead of just balance.

1158
00:43:16,560 --> 00:43:18,160
You have to stop using abbreviations

1159
00:43:18,160 --> 00:43:19,960
that only made sense 30 years ago

1160
00:43:19,960 --> 00:43:22,080
and start using the language of your business.

1161
00:43:22,080 --> 00:43:24,920
This logic applies to every single part of your schema

1162
00:43:24,920 --> 00:43:27,080
from field names to business rules.

1163
00:43:27,080 --> 00:43:28,760
You have to be explicit because an AI

1164
00:43:28,760 --> 00:43:30,880
cannot infirm meaning the way a human does.

1165
00:43:30,880 --> 00:43:33,920
When a person sees a field called "modified by"

1166
00:43:33,920 --> 00:43:36,560
they automatically know it refers to the last user

1167
00:43:36,560 --> 00:43:37,800
who touched the record.

1168
00:43:37,800 --> 00:43:39,640
An AI doesn't just know that.

1169
00:43:39,640 --> 00:43:43,360
It only knows what you have explicitly told it through your metadata.

1170
00:43:43,360 --> 00:43:45,640
The organizations that actually succeed with MCP

1171
00:43:45,640 --> 00:43:47,160
are the ones that do this heavy lifting

1172
00:43:47,160 --> 00:43:49,000
before they ever turn on a connector.

1173
00:43:49,000 --> 00:43:51,360
They audit their schema, rewrite their descriptions

1174
00:43:51,360 --> 00:43:54,600
and define relationships that might have been technically functional

1175
00:43:54,600 --> 00:43:56,520
but were semantically confusing.

1176
00:43:56,520 --> 00:43:59,360
They document their constraints and mark their sensitive data

1177
00:43:59,360 --> 00:44:01,520
so that when they finally deploy MCP

1178
00:44:01,520 --> 00:44:02,760
the difference is night and day.

1179
00:44:02,760 --> 00:44:04,640
The AI operates with a level of confidence

1180
00:44:04,640 --> 00:44:06,880
that requires far less human oversight.

1181
00:44:06,880 --> 00:44:09,000
The hidden cost of AI adoption is the work

1182
00:44:09,000 --> 00:44:11,360
that happens before the tools even arrive.

1183
00:44:11,360 --> 00:44:13,800
It's the metadata cleanup, the schema reviews

1184
00:44:13,800 --> 00:44:15,280
and the documentation of business rules

1185
00:44:15,280 --> 00:44:16,720
that everyone wants to skip.

1186
00:44:16,720 --> 00:44:18,440
This isn't just infrastructure work,

1187
00:44:18,440 --> 00:44:20,920
it is the architectural foundation of the future

1188
00:44:20,920 --> 00:44:22,680
and it's the one step that organizations

1189
00:44:22,680 --> 00:44:24,360
consistently underestimate.

1190
00:44:24,360 --> 00:44:26,400
That is where the real work lives.

1191
00:44:26,400 --> 00:44:29,760
The organizational impact, new roles, new skills,

1192
00:44:29,760 --> 00:44:31,960
moving to MCP isn't just a technical swap

1193
00:44:31,960 --> 00:44:33,560
that keeps your org chart the same.

1194
00:44:33,560 --> 00:44:35,360
It is a total role transformation.

1195
00:44:35,360 --> 00:44:37,840
The work your integration engineers do is changing

1196
00:44:37,840 --> 00:44:39,160
but it isn't disappearing.

1197
00:44:39,160 --> 00:44:41,440
That is a distinction you need to understand clearly.

1198
00:44:41,440 --> 00:44:42,880
You aren't actually cutting developers.

1199
00:44:42,880 --> 00:44:46,360
Sometimes leadership sees MCP slashing implementation times

1200
00:44:46,360 --> 00:44:48,160
from eight weeks down to two days

1201
00:44:48,160 --> 00:44:50,120
and assumes the headcount should shrink too.

1202
00:44:50,120 --> 00:44:51,560
But that is looking at it backwards.

1203
00:44:51,560 --> 00:44:53,360
What is really happening is that your developers

1204
00:44:53,360 --> 00:44:55,000
are moving away from writing glue code

1205
00:44:55,000 --> 00:44:56,640
and starting to design platforms.

1206
00:44:56,640 --> 00:44:59,240
Before MCP arrived, the job of an integration engineer

1207
00:44:59,240 --> 00:45:00,360
was very straightforward.

1208
00:45:00,360 --> 00:45:03,480
You had a problem where System A wouldn't talk to System B

1209
00:45:03,480 --> 00:45:05,960
and you were the person who forced them to communicate.

1210
00:45:05,960 --> 00:45:09,040
You spent your days writing rest-wrappers, handling authentication

1211
00:45:09,040 --> 00:45:10,720
and translating API contracts

1212
00:45:10,720 --> 00:45:12,880
into something another system could actually read.

1213
00:45:12,880 --> 00:45:15,280
You wrote the error handling, tested the deployment

1214
00:45:15,280 --> 00:45:17,120
and then you maintained that specific connection

1215
00:45:17,120 --> 00:45:18,280
for the next five years.

1216
00:45:18,280 --> 00:45:20,240
You stayed busy because there was always a new system

1217
00:45:20,240 --> 00:45:23,200
to connect and every time an underlying system changed,

1218
00:45:23,200 --> 00:45:25,120
you had to go back in and fix the bridge.

1219
00:45:25,120 --> 00:45:26,760
That work still exists in the world

1220
00:45:26,760 --> 00:45:27,840
but here is the problem.

1221
00:45:27,840 --> 00:45:29,120
It isn't the bottleneck anymore.

1222
00:45:29,120 --> 00:45:30,280
The bottleneck has shifted.

1223
00:45:30,280 --> 00:45:32,240
Now the real challenge is designing which tools

1224
00:45:32,240 --> 00:45:34,640
should be available through your MCP servers.

1225
00:45:34,640 --> 00:45:37,080
The struggle isn't the technical connection itself

1226
00:45:37,080 --> 00:45:39,360
but rather designing the semantic surface.

1227
00:45:39,360 --> 00:45:41,840
You have to understand which business capabilities

1228
00:45:41,840 --> 00:45:43,840
your organization actually exposes

1229
00:45:43,840 --> 00:45:46,400
through dataverse and how those pieces relate to each other.

1230
00:45:46,400 --> 00:45:47,920
You need to figure out who gets access,

1231
00:45:47,920 --> 00:45:49,840
what constraints govern the operations

1232
00:45:49,840 --> 00:45:52,240
and how to make that surface discoverable for AI.

1233
00:45:52,240 --> 00:45:55,240
Designing that interface so it supports AI-driven workflows

1234
00:45:55,240 --> 00:45:57,440
is a different skill entirely.

1235
00:45:57,440 --> 00:46:00,520
A new role is emerging called the MCP server owner.

1236
00:46:00,520 --> 00:46:02,080
This person owns the tools, the scope

1237
00:46:02,080 --> 00:46:03,720
and the governance for a specific domain.

1238
00:46:03,720 --> 00:46:05,800
They understand what an MCP server should expose

1239
00:46:05,800 --> 00:46:08,000
because they actually understand the business side of the house.

1240
00:46:08,000 --> 00:46:09,520
They work closely with the teams

1241
00:46:09,520 --> 00:46:11,360
owning the underlying systems to understand

1242
00:46:11,360 --> 00:46:13,560
the data models and security constraints.

1243
00:46:13,560 --> 00:46:15,320
Then they design tool interfaces

1244
00:46:15,320 --> 00:46:17,720
that make those rules visible to AI agents.

1245
00:46:17,720 --> 00:46:20,880
They are the ones deciding which operations are safe to automate

1246
00:46:20,880 --> 00:46:23,960
and which ones still need a human to click approve.

1247
00:46:23,960 --> 00:46:25,320
This isn't just API design,

1248
00:46:25,320 --> 00:46:27,240
it is tool design and capability modeling.

1249
00:46:27,240 --> 00:46:30,560
It is about predicting how an AI will discover a resource

1250
00:46:30,560 --> 00:46:32,840
and then building the surface to match that behavior.

1251
00:46:32,840 --> 00:46:35,200
The people who excel here understand both technical limits

1252
00:46:35,200 --> 00:46:36,280
and business intent.

1253
00:46:36,280 --> 00:46:39,000
They aren't just developers and they aren't just business analysts.

1254
00:46:39,000 --> 00:46:41,960
They are architects who act as a bridge between the two worlds.

1255
00:46:41,960 --> 00:46:44,240
The skills for this are still being defined.

1256
00:46:44,240 --> 00:46:47,360
There is no degree for becoming an MCP server owner yet,

1257
00:46:47,360 --> 00:46:49,240
but the pattern is getting easier to see.

1258
00:46:49,240 --> 00:46:51,160
You need people who know your domain deeply

1259
00:46:51,160 --> 00:46:53,360
and understand how dataverse functions.

1260
00:46:53,360 --> 00:46:56,560
You need writers who can describe complex business logic clearly

1261
00:46:56,560 --> 00:46:58,680
so an autonomous agent can actually use it.

1262
00:46:58,680 --> 00:47:01,320
Most importantly, you need people who understand governance

1263
00:47:01,320 --> 00:47:04,560
well enough to draw the line between what is safe and what is dangerous.

1264
00:47:04,560 --> 00:47:06,880
Your current developers can absolutely learn this.

1265
00:47:06,880 --> 00:47:08,440
It isn't a brand new skill set,

1266
00:47:08,440 --> 00:47:10,480
but rather an evolution of what they already know.

1267
00:47:10,480 --> 00:47:12,880
If someone has spent five years building custom connectors,

1268
00:47:12,880 --> 00:47:15,280
they already understand integration complexity

1269
00:47:15,280 --> 00:47:16,720
and they know exactly what breaks.

1270
00:47:16,720 --> 00:47:19,400
And if you give that person training on tool design and agent behavior,

1271
00:47:19,400 --> 00:47:21,880
they will become incredible at building MCP servers.

1272
00:47:21,880 --> 00:47:23,880
But you have to recognize the capacity shift.

1273
00:47:23,880 --> 00:47:27,280
You aren't moving from writing integrations to doing nothing.

1274
00:47:27,280 --> 00:47:30,840
You are moving from writing integrations to designing tool platforms.

1275
00:47:30,840 --> 00:47:33,080
The work is different, the output is different,

1276
00:47:33,080 --> 00:47:34,920
and the impact is much higher.

1277
00:47:34,920 --> 00:47:38,160
One engineer can now unblock 50 different AI use cases

1278
00:47:38,160 --> 00:47:41,320
instead of solving one single point-to-point connection.

1279
00:47:41,320 --> 00:47:44,280
That isn't less work. That is leverage.

1280
00:47:44,280 --> 00:47:46,800
The organizational reality is that you will need fewer people

1281
00:47:46,800 --> 00:47:48,200
doing repetitive manual labor

1282
00:47:48,200 --> 00:47:50,520
and more people doing high-level architecture.

1283
00:47:50,520 --> 00:47:53,280
You need thinkers who can be strategic about which capabilities

1284
00:47:53,280 --> 00:47:55,280
the company should expose and how to govern them.

1285
00:47:55,280 --> 00:47:57,920
You need people who realize that tool design is really about

1286
00:47:57,920 --> 00:48:00,480
making constraints visible to autonomous systems.

1287
00:48:00,480 --> 00:48:02,480
This is where the shift stops being technical

1288
00:48:02,480 --> 00:48:04,440
and starts being organizational.

1289
00:48:04,440 --> 00:48:07,760
The business case, why executives should care about MCP?

1290
00:48:07,760 --> 00:48:10,000
This is where we move away from the technical details

1291
00:48:10,000 --> 00:48:11,160
and talk about the bottom line.

1292
00:48:11,160 --> 00:48:13,600
This is why your CFO, your CEO, and your board

1293
00:48:13,600 --> 00:48:17,240
should view MCP differently than a standard infrastructure decision.

1294
00:48:17,240 --> 00:48:19,080
Technology leaders care about architecture

1295
00:48:19,080 --> 00:48:20,080
because that is their job.

1296
00:48:20,080 --> 00:48:21,920
They worry about protocols, schemers,

1297
00:48:21,920 --> 00:48:23,920
and whether the system is designed to scale.

1298
00:48:23,920 --> 00:48:25,760
Those are infrastructure concerns.

1299
00:48:25,760 --> 00:48:27,600
But executives care about something else entirely.

1300
00:48:27,600 --> 00:48:30,080
They care about velocity, competitive positioning,

1301
00:48:30,080 --> 00:48:33,080
and what the organization can actually get done this quarter.

1302
00:48:33,080 --> 00:48:36,240
The technical gap between custom connectors and MCP is massive.

1303
00:48:36,240 --> 00:48:38,760
But for an executive, the difference is much simpler.

1304
00:48:38,760 --> 00:48:39,720
It is speed.

1305
00:48:39,720 --> 00:48:42,400
Imagine you have a business problem that AI could solve.

1306
00:48:42,400 --> 00:48:45,560
You want to pull customer data, compare it to operations data,

1307
00:48:45,560 --> 00:48:47,400
and have a model-generate recommendations.

1308
00:48:47,400 --> 00:48:49,440
Your team could build this, and it would save time

1309
00:48:49,440 --> 00:48:51,080
and improve every decision you make.

1310
00:48:51,080 --> 00:48:52,520
It is clearly worth doing.

1311
00:48:52,520 --> 00:48:54,320
But how long does it take to actually launch?

1312
00:48:54,320 --> 00:48:57,800
If you use custom connectors, you are looking at a full-scale project

1313
00:48:57,800 --> 00:48:59,560
that takes eight weeks minimum.

1314
00:48:59,560 --> 00:49:01,960
You have to scope it, build the connector, validate the data,

1315
00:49:01,960 --> 00:49:03,520
and then monitor the deployment.

1316
00:49:03,520 --> 00:49:04,920
While you are stuck in that cycle,

1317
00:49:04,920 --> 00:49:07,200
your competitors who already have MCP infrastructure

1318
00:49:07,200 --> 00:49:08,840
have already built their automation.

1319
00:49:08,840 --> 00:49:11,280
They are already learning from it and gaining an advantage

1320
00:49:11,280 --> 00:49:13,360
while you are still stuck in the design phase.

1321
00:49:13,360 --> 00:49:14,600
Then another problem pops up.

1322
00:49:14,600 --> 00:49:17,640
You see another chance to use AI, but it requires a different system.

1323
00:49:17,640 --> 00:49:19,320
That is another eight weeks of waiting

1324
00:49:19,320 --> 00:49:21,120
and another project cycle.

1325
00:49:21,120 --> 00:49:23,760
You are looking at another quarter of standing still.

1326
00:49:23,760 --> 00:49:26,800
The company that can say, we will have that running in two days

1327
00:49:26,800 --> 00:49:29,560
has a massive strategic advantage over the company that says

1328
00:49:29,560 --> 00:49:31,320
that is a six-month project.

1329
00:49:31,320 --> 00:49:32,600
That isn't a technical win.

1330
00:49:32,600 --> 00:49:33,600
That is a business win.

1331
00:49:33,600 --> 00:49:36,280
It is the difference between being reactive and being nimble.

1332
00:49:36,280 --> 00:49:39,280
It is how you dominate a market instead of just surviving in it.

1333
00:49:39,280 --> 00:49:41,040
This is the core argument for velocity.

1334
00:49:41,040 --> 00:49:43,040
When you use MCP, new AI use cases

1335
00:49:43,040 --> 00:49:45,080
don't start massive infrastructure projects.

1336
00:49:45,080 --> 00:49:46,880
They just trigger configuration tasks.

1337
00:49:46,880 --> 00:49:48,320
The tools are already there.

1338
00:49:48,320 --> 00:49:50,120
Dataverse is already exposed.

1339
00:49:50,120 --> 00:49:52,920
And the security model is already set.

1340
00:49:52,920 --> 00:49:54,960
You aren't building from scratch anymore.

1341
00:49:54,960 --> 00:49:57,200
You are consuming what you already have.

1342
00:49:57,200 --> 00:49:59,360
You aren't designing for one specific use case,

1343
00:49:59,360 --> 00:50:02,440
but using existing capabilities to solve new problems.

1344
00:50:02,440 --> 00:50:04,040
That changes your timeline and expands

1345
00:50:04,040 --> 00:50:05,920
what your team can attempt in a single month.

1346
00:50:05,920 --> 00:50:09,880
This is also the shift from AI as a project to AI as a capability.

1347
00:50:09,880 --> 00:50:12,800
Right now most companies treat AI like a one-off project.

1348
00:50:12,800 --> 00:50:15,480
You find an opening, you assign a team, you fund it,

1349
00:50:15,480 --> 00:50:16,680
and you get a result.

1350
00:50:16,680 --> 00:50:18,280
When the project ends, the team moves on.

1351
00:50:18,280 --> 00:50:19,680
This works, but it is serial.

1352
00:50:19,680 --> 00:50:21,400
You can only do one thing at a time.

1353
00:50:21,400 --> 00:50:24,640
And you are limited by how many projects your managers can handle at once.

1354
00:50:24,640 --> 00:50:26,840
But the best organizations are making a change.

1355
00:50:26,840 --> 00:50:29,240
They are building AI as a core capability

1356
00:50:29,240 --> 00:50:30,400
that the company just does.

1357
00:50:30,400 --> 00:50:33,160
It becomes like analytics or reporting.

1358
00:50:33,160 --> 00:50:35,640
AI-driven automation isn't a special event.

1359
00:50:35,640 --> 00:50:37,960
It is just how you operate every day.

1360
00:50:37,960 --> 00:50:40,880
This shift only happens when the infrastructure removes the friction.

1361
00:50:40,880 --> 00:50:44,360
When adding AI to a workflow doesn't require an eight-week integration,

1362
00:50:44,360 --> 00:50:46,240
anyone with a good idea can try it.

1363
00:50:46,240 --> 00:50:49,160
When the barrier to entry is low enough that you can afford to fail,

1364
00:50:49,160 --> 00:50:51,360
AI stops being something you plan for

1365
00:50:51,360 --> 00:50:53,560
and starts being something that just happens.

1366
00:50:53,560 --> 00:50:55,120
For an executive, that is the pitch.

1367
00:50:55,120 --> 00:50:57,120
Your speed in deploying AI goes up,

1368
00:50:57,120 --> 00:50:59,120
your competitive position gets stronger,

1369
00:50:59,120 --> 00:51:01,400
and your organization learns to adapt faster.

1370
00:51:01,400 --> 00:51:02,600
That is the business case.

1371
00:51:02,600 --> 00:51:03,640
But there is a catch.

1372
00:51:03,640 --> 00:51:06,600
You can't just flip a switch and expect all of this to work instantly.

1373
00:51:06,600 --> 00:51:09,760
The governance first approach, why you can't just flip a switch.

1374
00:51:09,760 --> 00:51:12,440
Most organizations stumble right at the starting line.

1375
00:51:12,440 --> 00:51:13,640
They see the business case.

1376
00:51:13,640 --> 00:51:15,480
They understand why velocity matters.

1377
00:51:15,480 --> 00:51:19,400
They decide to deploy MCP, but then they treat it like a standard IT project.

1378
00:51:19,400 --> 00:51:20,720
They install the local proxy,

1379
00:51:20,720 --> 00:51:22,920
configure the connection to their dataverse tenant,

1380
00:51:22,920 --> 00:51:25,120
and point their AI tools at the data.

1381
00:51:25,120 --> 00:51:27,240
They announce the big rollout to the company,

1382
00:51:27,240 --> 00:51:31,080
and then they're completely shocked when the security team step into shut it down.

1383
00:51:31,080 --> 00:51:32,640
That pushback isn't just red tape.

1384
00:51:32,640 --> 00:51:36,760
It's the sound of the organization realizing that flipping the switch on MCP without a plan

1385
00:51:36,760 --> 00:51:38,280
creates a massive backdoor.

1386
00:51:38,280 --> 00:51:41,400
You've essentially built a way to sidesteep every security control.

1387
00:51:41,400 --> 00:51:43,480
You've spent the last decade putting in place.

1388
00:51:43,480 --> 00:51:45,720
Adopting MCP is not a technical migration,

1389
00:51:45,720 --> 00:51:48,480
and that's the fundamental misunderstanding most leaders have.

1390
00:51:48,480 --> 00:51:50,960
You aren't just swapping one protocol for another,

1391
00:51:50,960 --> 00:51:53,040
or upgrading your server infrastructure.

1392
00:51:53,040 --> 00:51:56,040
You are actually restructuring how your entire organization

1393
00:51:56,040 --> 00:51:58,440
exposes its capabilities to autonomous systems.

1394
00:51:58,440 --> 00:52:00,520
This is a governance problem, not a technical one.

1395
00:52:00,520 --> 00:52:03,640
The coding and configuration might take up 20% of your time,

1396
00:52:03,640 --> 00:52:06,000
but the governance work is the other 80%.

1397
00:52:06,000 --> 00:52:10,680
The temptation is to just expose everything in dataverse through MCP and hope for the best.

1398
00:52:10,680 --> 00:52:14,160
You have a platform full of data and an MCP connector ready to go,

1399
00:52:14,160 --> 00:52:16,840
so you figure you'll just let the AI sort out what's useful.

1400
00:52:16,840 --> 00:52:18,720
That approach sounds efficient on paper,

1401
00:52:18,720 --> 00:52:20,880
but in reality, it's incredibly dangerous.

1402
00:52:20,880 --> 00:52:24,040
It's like handing an unsupervised AI the keys to every filing cabinet

1403
00:52:24,040 --> 00:52:26,520
and office door in the building and trusting it to behave.

1404
00:52:26,520 --> 00:52:28,240
The AI might not have bad intentions,

1405
00:52:28,240 --> 00:52:31,400
but intentions won't stop a disaster when the boundaries are invisible.

1406
00:52:31,400 --> 00:52:34,480
A governance first approach means something very specific.

1407
00:52:34,480 --> 00:52:36,640
Before you ever build an MCP server,

1408
00:52:36,640 --> 00:52:38,960
you have to decide exactly what it should be allowed to see.

1409
00:52:38,960 --> 00:52:40,840
You aren't asking what is technically possible,

1410
00:52:40,840 --> 00:52:43,600
but what is strategically appropriate for an AI to handle.

1411
00:52:43,600 --> 00:52:46,800
You have to ask which business capabilities are safe for an autonomous system

1412
00:52:46,800 --> 00:52:48,800
to trigger without a human in the loop.

1413
00:52:48,800 --> 00:52:51,280
You need to know which data is routine and which is sensitive,

1414
00:52:51,280 --> 00:52:54,400
and you must define the business rules that the AI has to follow.

1415
00:52:54,400 --> 00:52:56,360
This requires absolute clarity on ownership.

1416
00:52:56,360 --> 00:52:59,840
You need to know who owns the MCP server from a business perspective,

1417
00:52:59,840 --> 00:53:01,560
not just who maintains the code.

1418
00:53:01,560 --> 00:53:04,880
Someone has to be accountable for what that server exposes to the world.

1419
00:53:04,880 --> 00:53:07,000
That person decides when to add a new tool,

1420
00:53:07,000 --> 00:53:10,000
reviews every change and monitors how the system is being used.

1421
00:53:10,000 --> 00:53:12,360
These aren't just academic questions for a meeting,

1422
00:53:12,360 --> 00:53:15,080
they are operational necessities for the system to function.

1423
00:53:15,080 --> 00:53:18,000
Without a clear owner, your governance model will eventually fail.

1424
00:53:18,000 --> 00:53:21,000
You also need to be ruthless about the scope of your data.

1425
00:53:21,000 --> 00:53:24,600
The MCP server shouldn't have access to everything in dataverse.

1426
00:53:24,600 --> 00:53:26,880
It should only see a specific subset of information.

1427
00:53:26,880 --> 00:53:29,360
You have to define which tables and fields are open,

1428
00:53:29,360 --> 00:53:33,080
and whether the AI can create, read, update or delete records.

1429
00:53:33,080 --> 00:53:35,040
There are always files that should stay off limits

1430
00:53:35,040 --> 00:53:37,440
like customer bank details, HR records,

1431
00:53:37,440 --> 00:53:39,360
or sensitive contract negotiations.

1432
00:53:39,360 --> 00:53:42,520
That scope has to be written in stone and enforced at the server level,

1433
00:53:42,520 --> 00:53:43,960
so there's no room for error.

1434
00:53:43,960 --> 00:53:46,120
Then you have to look at your approval workflows.

1435
00:53:46,120 --> 00:53:49,320
You need to decide which actions require a human to sign off

1436
00:53:49,320 --> 00:53:51,160
before the AI can execute them.

1437
00:53:51,160 --> 00:53:53,040
This might include creating new records,

1438
00:53:53,040 --> 00:53:54,400
exporting data in bulk,

1439
00:53:54,400 --> 00:53:56,640
or changing any business-critical information.

1440
00:53:56,640 --> 00:53:59,400
These gates have to be designed before you deploy the system,

1441
00:53:59,400 --> 00:54:02,840
because trying to retrofit them after a mistake happens is a losing game.

1442
00:54:02,840 --> 00:54:05,760
You have to enforce these rules at the tool level

1443
00:54:05,760 --> 00:54:08,440
rather than just hoping they work downstream.

1444
00:54:08,440 --> 00:54:12,040
Without the structure, MCP just becomes a new way to build Shadow IT.

1445
00:54:12,040 --> 00:54:13,680
Teams will start spinning up their own servers

1446
00:54:13,680 --> 00:54:14,680
without any oversight,

1447
00:54:14,680 --> 00:54:16,960
and they will inevitably expose more data than they should.

1448
00:54:16,960 --> 00:54:18,480
They won't log the activity properly,

1449
00:54:18,480 --> 00:54:21,520
and they'll create approval steps that nobody actually follows.

1450
00:54:21,520 --> 00:54:23,360
This leads to invisible integration,

1451
00:54:23,360 --> 00:54:26,000
where autonomous systems are running with permissions

1452
00:54:26,000 --> 00:54:28,120
that nobody in the company fully understands.

1453
00:54:28,120 --> 00:54:29,480
When data starts flowing in ways,

1454
00:54:29,480 --> 00:54:31,200
the governance team can't see,

1455
00:54:31,200 --> 00:54:33,560
you're in a worse position than the old model.

1456
00:54:33,560 --> 00:54:35,680
The maturity requirement here is very real.

1457
00:54:35,680 --> 00:54:37,160
If you want to move to MCP,

1458
00:54:37,160 --> 00:54:40,680
you need strong data governance already running in your organization.

1459
00:54:40,680 --> 00:54:42,880
You need clear owners for every data domain

1460
00:54:42,880 --> 00:54:45,440
and a solid understanding of what information is sensitive.

1461
00:54:45,440 --> 00:54:47,680
You must have the discipline to audit your systems

1462
00:54:47,680 --> 00:54:49,760
and the structure to enforce your own policies.

1463
00:54:49,760 --> 00:54:51,640
If you're already struggling to manage your data

1464
00:54:51,640 --> 00:54:53,240
or your audit trails or a mess,

1465
00:54:53,240 --> 00:54:56,000
adding MCP will only make those problems explode.

1466
00:54:56,000 --> 00:54:58,960
This is the hard truth that sends most organizations into a tailspin.

1467
00:54:58,960 --> 00:55:00,560
They deploy the technology first

1468
00:55:00,560 --> 00:55:02,320
because the business case looks great,

1469
00:55:02,320 --> 00:55:04,560
and they tell themselves they'll handle the governance later.

1470
00:55:04,560 --> 00:55:06,080
By the time they get around to it,

1471
00:55:06,080 --> 00:55:07,760
they've already created a massive mess

1472
00:55:07,760 --> 00:55:10,080
and exposed things that should have stayed private.

1473
00:55:10,080 --> 00:55:12,600
The blast radius is always larger than they expected.

1474
00:55:12,600 --> 00:55:14,280
The organizations that actually succeed

1475
00:55:14,280 --> 00:55:15,640
are the ones that plan their governance

1476
00:55:15,640 --> 00:55:17,560
before they ride a single line of code.

1477
00:55:17,560 --> 00:55:19,160
They define the boundaries,

1478
00:55:19,160 --> 00:55:21,000
build those rules into the servers

1479
00:55:21,000 --> 00:55:22,840
and monitor the results constantly.

1480
00:55:22,840 --> 00:55:24,800
That timeline takes longer to get started,

1481
00:55:24,800 --> 00:55:27,040
but the final outcome is actually sustainable.

1482
00:55:27,040 --> 00:55:30,560
This is where the shift from a cool demo to real work actually happens.

1483
00:55:30,560 --> 00:55:33,560
The common mistakes, what organizations get wrong?

1484
00:55:33,560 --> 00:55:35,320
Pattern recognition is a powerful tool

1485
00:55:35,320 --> 00:55:37,120
when you're looking at how companies fail.

1486
00:55:37,120 --> 00:55:38,520
When you study the organizations

1487
00:55:38,520 --> 00:55:40,440
that have tried to move to MCP,

1488
00:55:40,440 --> 00:55:42,720
you see the same mistakes happening over and over again.

1489
00:55:42,720 --> 00:55:43,920
These failures don't happen

1490
00:55:43,920 --> 00:55:45,800
because the people are bad at their jobs,

1491
00:55:45,800 --> 00:55:48,200
but because their mental models are incomplete.

1492
00:55:48,200 --> 00:55:50,600
They don't quite grasp what MCP is meant to do,

1493
00:55:50,600 --> 00:55:53,240
and that confusion leads to very predictable disasters.

1494
00:55:53,240 --> 00:55:56,640
The biggest mistake is trying to build one giant monolithic MCP server

1495
00:55:56,640 --> 00:55:57,960
that handles everything.

1496
00:55:57,960 --> 00:55:59,440
Leaders think they're being efficient

1497
00:55:59,440 --> 00:56:01,560
by putting every table, every tool,

1498
00:56:01,560 --> 00:56:04,320
and every business capability into a single place.

1499
00:56:04,320 --> 00:56:07,320
They assume maintaining one server is easier than maintaining 10,

1500
00:56:07,320 --> 00:56:09,280
but the reality is the exact opposite.

1501
00:56:09,280 --> 00:56:13,360
The server that tries to do everything becomes impossible to manage almost immediately.

1502
00:56:13,360 --> 00:56:14,920
You can't set clear boundaries,

1503
00:56:14,920 --> 00:56:17,440
and an AI agent looking at 10,000 different tools

1504
00:56:17,440 --> 00:56:20,400
will never be able to figure out what's actually relevant.

1505
00:56:20,400 --> 00:56:21,880
It just turns into noise,

1506
00:56:21,880 --> 00:56:24,520
and that single server becomes a massive point of failure

1507
00:56:24,520 --> 00:56:27,640
where one small mistake can take down your entire operation.

1508
00:56:27,640 --> 00:56:30,440
The second mistake is getting your timeline backwards.

1509
00:56:30,440 --> 00:56:32,960
Organizations decide they'll deploy the technology now

1510
00:56:32,960 --> 00:56:35,480
and figure out the rules of the road later on.

1511
00:56:35,480 --> 00:56:38,440
But governance later almost always turns into governance never,

1512
00:56:38,440 --> 00:56:40,200
or at least not until something breaks.

1513
00:56:40,200 --> 00:56:42,600
Teams start building servers without any review process,

1514
00:56:42,600 --> 00:56:44,200
permissions get set incorrectly,

1515
00:56:44,200 --> 00:56:47,120
and people skip the approval steps because they're a hassle.

1516
00:56:47,120 --> 00:56:49,680
By the time the governance team realizes what's going on,

1517
00:56:49,680 --> 00:56:50,880
the mess is so deep,

1518
00:56:50,880 --> 00:56:53,440
it takes months of work just to untangle it.

1519
00:56:53,440 --> 00:56:55,160
The third mistake is launching MCP

1520
00:56:55,160 --> 00:56:57,600
without cleaning up your dataverse metadata first.

1521
00:56:57,600 --> 00:57:00,240
If you expose a table that uses cryptic internal codes

1522
00:57:00,240 --> 00:57:01,640
and has no descriptions,

1523
00:57:01,640 --> 00:57:04,000
the AI won't have any idea what is looking at.

1524
00:57:04,000 --> 00:57:06,640
It will either stop to ask for permission every five minutes

1525
00:57:06,640 --> 00:57:09,400
or it will start making dangerous assumptions about your data.

1526
00:57:09,400 --> 00:57:12,000
Sometimes the AI will just refuse to use the table at all

1527
00:57:12,000 --> 00:57:13,760
because it can't reason through the logic.

1528
00:57:13,760 --> 00:57:15,840
In those cases, people usually blame the connector,

1529
00:57:15,840 --> 00:57:18,760
but the real problem was the messy data they fed into it.

1530
00:57:18,760 --> 00:57:21,680
The fourth mistake is thinking that MCP is a total replacement

1531
00:57:21,680 --> 00:57:22,760
for REST APIs.

1532
00:57:22,760 --> 00:57:25,520
It isn't, and REST APIs are not going anywhere anytime soon.

1533
00:57:25,520 --> 00:57:27,040
They are still the best choice for things

1534
00:57:27,040 --> 00:57:30,560
like moving huge amounts of data, scheduled background tasks,

1535
00:57:30,560 --> 00:57:33,000
or high-speed communication between servers.

1536
00:57:33,000 --> 00:57:35,080
MCP is built for something else entirely,

1537
00:57:35,080 --> 00:57:37,760
which is discovery-driven access for autonomous systems

1538
00:57:37,760 --> 00:57:39,480
that need to understand intent.

1539
00:57:39,480 --> 00:57:41,360
If you try to force everything through MCP,

1540
00:57:41,360 --> 00:57:43,600
your system will end up slower and more complicated

1541
00:57:43,600 --> 00:57:44,840
than the one you replaced.

1542
00:57:44,840 --> 00:57:46,880
You have to use the right tool for the right job.

1543
00:57:46,880 --> 00:57:48,560
The fifth mistake is moving too fast

1544
00:57:48,560 --> 00:57:50,600
without setting up proper audit trails.

1545
00:57:50,600 --> 00:57:53,200
MCP makes it incredibly easy to access data,

1546
00:57:53,200 --> 00:57:54,960
but easy access without any visibility

1547
00:57:54,960 --> 00:57:57,000
is a recipe for security nightmare.

1548
00:57:57,000 --> 00:57:58,000
You need to log everything,

1549
00:57:58,000 --> 00:57:59,200
including what was requested,

1550
00:57:59,200 --> 00:58:00,040
who asked for it,

1551
00:58:00,040 --> 00:58:01,560
and exactly what data was sent back.

1552
00:58:01,560 --> 00:58:03,040
Without those detailed records,

1553
00:58:03,040 --> 00:58:04,240
you won't be able to investigate

1554
00:58:04,240 --> 00:58:05,920
when something inevitably goes wrong.

1555
00:58:05,920 --> 00:58:07,520
You won't be able to prove what happened,

1556
00:58:07,520 --> 00:58:09,520
and you won't be able to fix the root cause.

1557
00:58:09,520 --> 00:58:12,200
There is a clear pattern underneath all of these common failures.

1558
00:58:12,200 --> 00:58:13,920
The organizations that win with MCP

1559
00:58:13,920 --> 00:58:15,200
are the ones that do the boring work

1560
00:58:15,200 --> 00:58:16,600
before they start the exciting work.

1561
00:58:16,600 --> 00:58:18,400
They design the governance, define the scope,

1562
00:58:18,400 --> 00:58:20,920
and clean up their data before they ever go live.

1563
00:58:20,920 --> 00:58:22,200
The teams that stumble are the ones

1564
00:58:22,200 --> 00:58:23,240
who skip the planning phase

1565
00:58:23,240 --> 00:58:25,720
and hope that fast execution will solve their problems.

1566
00:58:25,720 --> 00:58:26,840
It never does.

1567
00:58:26,840 --> 00:58:28,160
The cost of these mistakes

1568
00:58:28,160 --> 00:58:30,080
isn't always obvious on day one.

1569
00:58:30,080 --> 00:58:32,200
A poorly designed server might work perfectly fine

1570
00:58:32,200 --> 00:58:33,120
for a few weeks,

1571
00:58:33,120 --> 00:58:35,440
but eventually it becomes a massive liability

1572
00:58:35,440 --> 00:58:36,840
that's too hard to maintain.

1573
00:58:36,840 --> 00:58:38,000
By the time you have to replace it,

1574
00:58:38,000 --> 00:58:39,120
you've wasted months of time

1575
00:58:39,120 --> 00:58:40,640
and lost the trust of your stakeholders.

1576
00:58:40,640 --> 00:58:42,200
This is the point where strategic thinking

1577
00:58:42,200 --> 00:58:43,520
becomes much more valuable

1578
00:58:43,520 --> 00:58:45,680
than the technical implementation itself.

1579
00:58:45,680 --> 00:58:46,720
The maturity model,

1580
00:58:46,720 --> 00:58:49,200
from custom integration to MCP ready.

1581
00:58:49,200 --> 00:58:51,240
You need to know where you stand on the MCP journey

1582
00:58:51,240 --> 00:58:52,680
because not every organization

1583
00:58:52,680 --> 00:58:53,960
starts from the same place,

1584
00:58:53,960 --> 00:58:56,600
and honestly not everyone needs to reach the same finish line.

1585
00:58:56,600 --> 00:58:57,680
Having a clear framework

1586
00:58:57,680 --> 00:58:58,960
just helps you put your resources

1587
00:58:58,960 --> 00:59:00,320
where they actually matter.

1588
00:59:00,320 --> 00:59:02,680
Think of maturity as a landscape you move through,

1589
00:59:02,680 --> 00:59:05,560
rather than a ladder you climb in need robotic steps.

1590
00:59:05,560 --> 00:59:07,480
Every stage has its own personality,

1591
00:59:07,480 --> 00:59:08,760
its own set of headaches

1592
00:59:08,760 --> 00:59:10,840
and its own specific requirements.

1593
00:59:10,840 --> 00:59:13,560
Level zero is the current reality for most companies,

1594
00:59:13,560 --> 00:59:15,360
and it usually looks like custom connectors

1595
00:59:15,360 --> 00:59:17,680
scattered everywhere with no central plan.

1596
00:59:17,680 --> 00:59:19,240
Integration decisions happen locally

1597
00:59:19,240 --> 00:59:20,720
because one team needs Salesforce

1598
00:59:20,720 --> 00:59:22,160
talking to Power Platform,

1599
00:59:22,160 --> 00:59:23,840
while another team is busy wiring

1600
00:59:23,840 --> 00:59:25,920
a data warehouse into an analytics tool.

1601
00:59:25,920 --> 00:59:28,160
Then a third team builds something from scratch

1602
00:59:28,160 --> 00:59:30,200
just because they couldn't find a pre-made connector

1603
00:59:30,200 --> 00:59:31,720
that did exactly what they wanted.

1604
00:59:31,720 --> 00:59:34,640
You end up with dozens or even hundreds of these integrations,

1605
00:59:34,640 --> 00:59:36,520
but they aren't coordinated or governed,

1606
00:59:36,520 --> 00:59:37,600
so they just sit there.

1607
00:59:37,600 --> 00:59:39,640
Integration eventually becomes a massive bottleneck

1608
00:59:39,640 --> 00:59:42,080
because there is no standard way to add new connections,

1609
00:59:42,080 --> 00:59:45,160
meaning every new system requires a fresh round of custom work.

1610
00:59:45,160 --> 00:59:48,200
Level one is where you finally take an inventory of the mess.

1611
00:59:48,200 --> 00:59:50,200
You actually know which connectors you own,

1612
00:59:50,200 --> 00:59:52,360
and you've started thinking about how to consolidate them

1613
00:59:52,360 --> 00:59:53,680
into something manageable.

1614
00:59:53,680 --> 00:59:55,840
Maybe you've picked a platform like Azure Logic Apps

1615
00:59:55,840 --> 00:59:58,240
or a third party, I pass to host everything,

1616
00:59:58,240 --> 01:00:00,120
but you're still mostly building custom connectors.

1617
01:00:00,120 --> 01:00:01,960
MCP isn't even in your vocabulary yet,

1618
01:00:01,960 --> 01:00:03,600
and you haven't deployed a single server,

1619
01:00:03,600 --> 01:00:06,640
but the organizational structure is starting to take shape.

1620
01:00:06,640 --> 01:00:09,320
You have an integration team and a catalog of what exists,

1621
01:00:09,320 --> 01:00:11,560
which means you've at least admitted the problem is real.

1622
01:00:11,560 --> 01:00:13,400
Level two is the experimentation phase

1623
01:00:13,400 --> 01:00:15,120
where you decide to give MCP a shot.

1624
01:00:15,120 --> 01:00:16,560
You've deployed your first servers,

1625
01:00:16,560 --> 01:00:17,640
but you aren't trusting them

1626
01:00:17,640 --> 01:00:19,600
with business-critical workloads quite yet.

1627
01:00:19,600 --> 01:00:22,240
Instead, you're testing with support data

1628
01:00:22,240 --> 01:00:23,760
or low-risk analytics

1629
01:00:23,760 --> 01:00:25,640
to learn how to design these servers

1630
01:00:25,640 --> 01:00:27,120
and figure out the governance.

1631
01:00:27,120 --> 01:00:28,640
You will definitely run into problems

1632
01:00:28,640 --> 01:00:30,400
like metadata errors, design flaws,

1633
01:00:30,400 --> 01:00:32,720
or permission boundaries that don't feel right,

1634
01:00:32,720 --> 01:00:34,360
but that is exactly why you're doing this.

1635
01:00:34,360 --> 01:00:36,120
You are learning in a controlled environment

1636
01:00:36,120 --> 01:00:38,880
while your governance framework starts to emerge in draft form.

1637
01:00:38,880 --> 01:00:41,040
Most of your portfolio is still custom connectors,

1638
01:00:41,040 --> 01:00:41,960
but for the first time,

1639
01:00:41,960 --> 01:00:44,160
you can actually see a future where that changes.

1640
01:00:44,160 --> 01:00:47,040
Level three is where the shift becomes undeniable.

1641
01:00:47,040 --> 01:00:49,120
Your core business domains, sales, support,

1642
01:00:49,120 --> 01:00:51,240
finance, and operations are now exposed

1643
01:00:51,240 --> 01:00:53,360
through production grade MCP servers.

1644
01:00:53,360 --> 01:00:56,080
Real AI automation is running against these workloads,

1645
01:00:56,080 --> 01:00:58,520
and your governance framework is finally being enforced

1646
01:00:58,520 --> 01:01:01,280
with audit trails flowing directly to your CM.

1647
01:01:01,280 --> 01:01:03,440
You have clear ownership and approval workflows

1648
01:01:03,440 --> 01:01:07,040
for sensitive tasks making MCP the primary way AI accesses

1649
01:01:07,040 --> 01:01:07,800
your data.

1650
01:01:07,800 --> 01:01:09,920
Custom connectors are moving into maintenance mode,

1651
01:01:09,920 --> 01:01:11,240
and while they aren't retired yet,

1652
01:01:11,240 --> 01:01:12,480
they aren't growing either.

1653
01:01:12,480 --> 01:01:14,920
New AI use cases are built on MCP,

1654
01:01:14,920 --> 01:01:16,440
and the velocity change is obvious

1655
01:01:16,440 --> 01:01:18,400
because projects that used to take eight weeks

1656
01:01:18,400 --> 01:01:19,600
now only take two.

1657
01:01:19,600 --> 01:01:21,240
Level four is the final destination

1658
01:01:21,240 --> 01:01:24,320
where MCP becomes the default for every new AI use case.

1659
01:01:24,320 --> 01:01:25,920
When a business problem comes in,

1660
01:01:25,920 --> 01:01:28,600
nobody asks if they can build a custom connector.

1661
01:01:28,600 --> 01:01:32,160
They ask if an MCP server already exposes the data they need.

1662
01:01:32,160 --> 01:01:34,160
Custom connectors are officially deprecated,

1663
01:01:34,160 --> 01:01:35,720
and only exist for legacy systems

1664
01:01:35,720 --> 01:01:38,040
that haven't been wrapped in an MCP server yet.

1665
01:01:38,040 --> 01:01:40,800
They aren't being maintained beyond basic security patches

1666
01:01:40,800 --> 01:01:42,680
because integration is no longer a bottleneck.

1667
01:01:42,680 --> 01:01:44,400
It's a platform capability,

1668
01:01:44,400 --> 01:01:46,960
allowing the organization to build new automations

1669
01:01:46,960 --> 01:01:48,720
at the speed of business decisions

1670
01:01:48,720 --> 01:01:51,280
rather than the speed of infrastructure projects.

1671
01:01:51,280 --> 01:01:52,920
The timeline here is a reality check

1672
01:01:52,920 --> 01:01:54,920
because most organizations won't move through

1673
01:01:54,920 --> 01:01:56,240
this progression in a few months.

1674
01:01:56,240 --> 01:01:58,880
Moving from level zero to level three typically takes 12

1675
01:01:58,880 --> 01:02:01,600
to 24 months, and that isn't because the technology is slow.

1676
01:02:01,600 --> 01:02:03,920
It takes time because governance restructuring is hard,

1677
01:02:03,920 --> 01:02:05,360
metadata needs cleaning,

1678
01:02:05,360 --> 01:02:07,080
and teams have to learn entirely new skills.

1679
01:02:07,080 --> 01:02:09,240
Organizational change is just naturally slower

1680
01:02:09,240 --> 01:02:10,440
than infrastructure change.

1681
01:02:10,440 --> 01:02:12,720
This timeline matters because it sets your expectations.

1682
01:02:12,720 --> 01:02:14,960
You aren't going to deploy MCP and hit level three

1683
01:02:14,960 --> 01:02:17,000
by next quarter, you're going to be at level two,

1684
01:02:17,000 --> 01:02:19,000
finding gaps and learning from mistakes.

1685
01:02:19,000 --> 01:02:20,960
That isn't a failure, it's just the process.

1686
01:02:20,960 --> 01:02:23,120
Organizations that try to skip the governance work

1687
01:02:23,120 --> 01:02:25,440
to move faster are usually the ones that end up

1688
01:02:25,440 --> 01:02:26,480
with a bigger mess.

1689
01:02:26,480 --> 01:02:28,960
The real question isn't which level you should aim for,

1690
01:02:28,960 --> 01:02:30,720
but which level actually makes sense

1691
01:02:30,720 --> 01:02:32,640
for your specific business drivers.

1692
01:02:32,640 --> 01:02:34,720
He dithaverse road map, what's coming?

1693
01:02:34,720 --> 01:02:36,240
Where this technology is heading matters

1694
01:02:36,240 --> 01:02:37,840
for the decisions you need to make right now.

1695
01:02:37,840 --> 01:02:39,600
If you're looking at adopting MCP,

1696
01:02:39,600 --> 01:02:41,400
you need to know what is being prioritized

1697
01:02:41,400 --> 01:02:43,440
and what is still just a preview feature.

1698
01:02:43,440 --> 01:02:45,720
The road map tells you if the gaps you see today

1699
01:02:45,720 --> 01:02:47,440
are being fixed or if you'll be stuck

1700
01:02:47,440 --> 01:02:48,760
with workarounds forever.

1701
01:02:48,760 --> 01:02:50,360
Microsoft is treating dithaverse MCP

1702
01:02:50,360 --> 01:02:51,920
as a first-class platform capability,

1703
01:02:51,920 --> 01:02:52,920
which is a big deal.

1704
01:02:52,920 --> 01:02:55,560
Not every Microsoft investment gets this kind of attention

1705
01:02:55,560 --> 01:02:57,080
as some features are announced

1706
01:02:57,080 --> 01:02:58,840
and then slowly fade into the background.

1707
01:02:58,840 --> 01:03:01,160
The signal from the 2026 release plans shows

1708
01:03:01,160 --> 01:03:04,760
that dithaverse MCP is getting consistent resources.

1709
01:03:04,760 --> 01:03:06,520
The power platform wave one release

1710
01:03:06,520 --> 01:03:08,760
specifically mentions improving server quality

1711
01:03:08,760 --> 01:03:11,480
with updated tools, which isn't just a minor add-on.

1712
01:03:11,480 --> 01:03:13,080
It is foundational infrastructure work

1713
01:03:13,080 --> 01:03:15,720
and it proves that Microsoft is preparing for massive scale.

1714
01:03:15,720 --> 01:03:17,400
These planned updates are important

1715
01:03:17,400 --> 01:03:19,080
because they solve the exact problems

1716
01:03:19,080 --> 01:03:20,560
people are dealing with today.

1717
01:03:20,560 --> 01:03:22,480
Remote MCP servers are finally on the road map,

1718
01:03:22,480 --> 01:03:23,680
which changes everything.

1719
01:03:23,680 --> 01:03:26,120
Right now you have to run a local proxy on your machine

1720
01:03:26,120 --> 01:03:28,760
or network to make dithaverse MCP work.

1721
01:03:28,760 --> 01:03:30,480
Remote servers mean the code can run anywhere,

1722
01:03:30,480 --> 01:03:32,080
whether that's in Azure, a container,

1723
01:03:32,080 --> 01:03:33,480
or as a managed service.

1724
01:03:33,480 --> 01:03:35,960
This removes the burden of managing proxy infrastructure

1725
01:03:35,960 --> 01:03:38,160
yourself and turns MCP into something

1726
01:03:38,160 --> 01:03:39,600
Microsoft maintains for you.

1727
01:03:39,600 --> 01:03:41,600
Table-level crowd operations are also on the way

1728
01:03:41,600 --> 01:03:42,680
to give you better control.

1729
01:03:42,680 --> 01:03:44,880
Currently, the MCP server is somewhat limited

1730
01:03:44,880 --> 01:03:47,440
in what it exposes, but as create, update,

1731
01:03:47,440 --> 01:03:48,960
and delete functions expand,

1732
01:03:48,960 --> 01:03:52,040
you get much finer control over what AI agents can do.

1733
01:03:52,040 --> 01:03:54,840
Right now it's easy to show an agent how to read ditha,

1734
01:03:54,840 --> 01:03:57,000
but writing ditha is much more difficult.

1735
01:03:57,000 --> 01:03:58,720
As these crowd operations grow,

1736
01:03:58,720 --> 01:04:01,280
the range of use cases for MCP expands,

1737
01:04:01,280 --> 01:04:03,320
making things like autonomous record creation

1738
01:04:03,320 --> 01:04:05,760
and bulk updates actually viable.

1739
01:04:05,760 --> 01:04:07,880
We are also seeing better admin controls

1740
01:04:07,880 --> 01:04:10,720
on the horizon to fix current governance gaps.

1741
01:04:10,720 --> 01:04:13,280
Right now you can block an entire MCP server,

1742
01:04:13,280 --> 01:04:15,520
but you can't get surgical and block individual tools

1743
01:04:15,520 --> 01:04:16,520
within it.

1744
01:04:16,520 --> 01:04:18,360
Microsoft is moving toward more precise controls

1745
01:04:18,360 --> 01:04:19,760
and richer audit trails,

1746
01:04:19,760 --> 01:04:21,560
which is a direct response to the feedback

1747
01:04:21,560 --> 01:04:23,480
they're getting from early adopters.

1748
01:04:23,480 --> 01:04:25,120
The biggest governance milestone to watch

1749
01:04:25,120 --> 01:04:27,880
is advanced connector policies moving from preview

1750
01:04:27,880 --> 01:04:29,160
to general availability.

1751
01:04:29,160 --> 01:04:31,920
These policies are how Microsoft plans to fix the DLP gap,

1752
01:04:31,920 --> 01:04:35,000
because classic policies simply don't see MCP servers yet.

1753
01:04:35,000 --> 01:04:37,440
As of early 2026, these are still in preview,

1754
01:04:37,440 --> 01:04:39,840
so you can't fully rely on them for production.

1755
01:04:39,840 --> 01:04:41,760
When they finally hit general availability,

1756
01:04:41,760 --> 01:04:43,600
you'll be able to enforce DLP policies

1757
01:04:43,600 --> 01:04:46,600
with real regulatory teeth and actually prove compliance.

1758
01:04:46,600 --> 01:04:49,600
Identity is the other piece of the puzzle that changes the game.

1759
01:04:49,600 --> 01:04:51,280
Entra-agent identities are coming

1760
01:04:51,280 --> 01:04:53,480
and they will finally separate what a human did

1761
01:04:53,480 --> 01:04:55,560
from what an agent decided to do.

1762
01:04:55,560 --> 01:04:57,560
Until these reach general availability,

1763
01:04:57,560 --> 01:05:00,480
organizations are stuck with ambiguous audit trails

1764
01:05:00,480 --> 01:05:02,280
that make accountability difficult.

1765
01:05:02,280 --> 01:05:04,680
Once they are production ready, that gap closes

1766
01:05:04,680 --> 01:05:07,440
and actions are correctly attributed to the agent itself.

1767
01:05:07,440 --> 01:05:08,880
This isn't just a small fix,

1768
01:05:08,880 --> 01:05:12,120
it's a fundamental shift in how we trust autonomous systems.

1769
01:05:12,120 --> 01:05:13,920
Performance is also getting a major overhaul

1770
01:05:13,920 --> 01:05:16,040
because high volume agents need better engineering

1771
01:05:16,040 --> 01:05:17,200
than simple experiments.

1772
01:05:17,200 --> 01:05:19,920
We're seeing work on caching strategies, schema efficiency,

1773
01:05:19,920 --> 01:05:21,760
connection pooling and rate limiting.

1774
01:05:21,760 --> 01:05:23,280
This is the same infrastructure work

1775
01:05:23,280 --> 01:05:26,040
that made REST APIs reliable at scale years ago.

1776
01:05:26,040 --> 01:05:28,400
The underlying message here is very consistent.

1777
01:05:28,400 --> 01:05:31,040
Microsoft sees MCP as the future architecture

1778
01:05:31,040 --> 01:05:33,640
for how AI interacts with enterprise data.

1779
01:05:33,640 --> 01:05:36,920
It isn't just one option among many, it's the path forward.

1780
01:05:36,920 --> 01:05:38,720
They are investing in the infrastructure

1781
01:05:38,720 --> 01:05:41,440
and closing the gaps because they are preparing for a shift,

1782
01:05:41,440 --> 01:05:43,200
they believe is inevitable.

1783
01:05:43,200 --> 01:05:45,640
The action plan, starting your MCP journey,

1784
01:05:45,640 --> 01:05:46,840
you need a starting point,

1785
01:05:46,840 --> 01:05:48,840
not a vision, not a transformation roadmap,

1786
01:05:48,840 --> 01:05:50,320
a starting point.

1787
01:05:50,320 --> 01:05:52,560
Monday morning, what actually happens?

1788
01:05:52,560 --> 01:05:54,720
Here is the realistic timeline for organizations

1789
01:05:54,720 --> 01:05:57,760
moving from where they are now to operating MCP at scale.

1790
01:05:57,760 --> 01:06:01,280
Month one, audit and prioritize.

1791
01:06:01,280 --> 01:06:03,480
Start by understanding what you actually have,

1792
01:06:03,480 --> 01:06:05,720
not theoretically, concretely.

1793
01:06:05,720 --> 01:06:08,160
Run an inventory of every custom connector,

1794
01:06:08,160 --> 01:06:09,440
every integration service

1795
01:06:09,440 --> 01:06:11,480
and every bespoke middleware component

1796
01:06:11,480 --> 01:06:13,040
your organization maintains.

1797
01:06:13,040 --> 01:06:14,600
This isn't an exercise in documentation,

1798
01:06:14,600 --> 01:06:15,840
it's an exercise in honesty,

1799
01:06:15,840 --> 01:06:17,680
what is actually running, what is in production,

1800
01:06:17,680 --> 01:06:20,000
what is half maintained and barely understood.

1801
01:06:20,000 --> 01:06:21,600
You need to identify what is so critical

1802
01:06:21,600 --> 01:06:23,280
that losing it would break the business

1803
01:06:23,280 --> 01:06:25,400
and contrast that against what is so peripheral

1804
01:06:25,400 --> 01:06:27,880
that you are not even sure what it does anymore.

1805
01:06:27,880 --> 01:06:30,880
Map each integration against a simple criterion.

1806
01:06:30,880 --> 01:06:32,920
Is this a candidate for MCP?

1807
01:06:32,920 --> 01:06:34,680
Some integrations are so high throughput

1808
01:06:34,680 --> 01:06:37,480
or so latency sensitive that they will never move to MCP

1809
01:06:37,480 --> 01:06:38,880
so you should leave those alone.

1810
01:06:38,880 --> 01:06:40,960
Other integrations exist only because point-to-point

1811
01:06:40,960 --> 01:06:42,880
was the only option available five years ago.

1812
01:06:42,880 --> 01:06:43,880
Those are your candidates.

1813
01:06:43,880 --> 01:06:46,440
They do not need the performance characteristics of rest.

1814
01:06:46,440 --> 01:06:49,280
They need the governance and discoverability benefits of MCP.

1815
01:06:49,280 --> 01:06:51,480
Separate the two groups, you are not retiring everything,

1816
01:06:51,480 --> 01:06:54,120
you are identifying what could benefit from the shift.

1817
01:06:54,120 --> 01:06:56,600
Month one, two, metadata cleanup.

1818
01:06:56,600 --> 01:06:59,280
This is where most organizations delay or skip work.

1819
01:06:59,280 --> 01:07:00,080
Don't.

1820
01:07:00,080 --> 01:07:01,920
Before you even think about deploying MCP,

1821
01:07:01,920 --> 01:07:04,920
your data versus metadata must be written for AI to read.

1822
01:07:04,920 --> 01:07:08,080
Go through the tables you have identified as MCP candidates

1823
01:07:08,080 --> 01:07:10,920
and ensure every field has a description written in plain English.

1824
01:07:10,920 --> 01:07:13,160
Explain what it represents, explain why it exists.

1825
01:07:13,160 --> 01:07:16,040
These are not technical definitions, they are business meanings.

1826
01:07:16,040 --> 01:07:18,320
Instead of phone or contact pH, you write

1827
01:07:18,320 --> 01:07:20,200
customer's primary contact phone number

1828
01:07:20,200 --> 01:07:23,640
used for support outreach and fraud verification.

1829
01:07:23,640 --> 01:07:25,480
This work feels tedious because it is.

1830
01:07:25,480 --> 01:07:26,800
It is also non-negotiable.

1831
01:07:26,800 --> 01:07:28,440
You are not just cleaning up documentation.

1832
01:07:28,440 --> 01:07:30,600
You are building the foundation for autonomous systems

1833
01:07:30,600 --> 01:07:32,360
to reason over your data effectively.

1834
01:07:32,360 --> 01:07:33,880
Spend the time, get it right.

1835
01:07:33,880 --> 01:07:35,840
The weeks you invest here prevent months of agent

1836
01:07:35,840 --> 01:07:37,440
behavior problems downstream.

1837
01:07:37,440 --> 01:07:39,600
Month two, design your first server.

1838
01:07:39,600 --> 01:07:41,080
Pick a non-critical domain.

1839
01:07:41,080 --> 01:07:42,680
Support data is often a good choice

1840
01:07:42,680 --> 01:07:43,960
and analytics is another.

1841
01:07:43,960 --> 01:07:46,520
You want something where mistakes have a limited blast radius.

1842
01:07:46,520 --> 01:07:48,240
Something where you can experiment and learn

1843
01:07:48,240 --> 01:07:49,760
without regulatory pressure.

1844
01:07:49,760 --> 01:07:51,960
Design what that MCP server should expose,

1845
01:07:51,960 --> 01:07:55,120
not everything in that domain, a thoughtful subset.

1846
01:07:55,120 --> 01:07:58,360
Which capabilities should AI agents invoke autonomously?

1847
01:07:58,360 --> 01:08:00,440
Which operations require human approval?

1848
01:08:00,440 --> 01:08:03,400
Which data is sensitive enough that access should be restricted?

1849
01:08:03,400 --> 01:08:04,280
Write it down.

1850
01:08:04,280 --> 01:08:05,440
Don't build yet.

1851
01:08:05,440 --> 01:08:06,440
Design first.

1852
01:08:06,440 --> 01:08:07,800
Month two to three.

1853
01:08:07,800 --> 01:08:09,040
Governance framework.

1854
01:08:09,040 --> 01:08:11,880
Before the server goes live, you need the guard rails in place.

1855
01:08:11,880 --> 01:08:14,800
Define who owns the server, who approves changes,

1856
01:08:14,800 --> 01:08:17,280
what approval workflows apply to which operations.

1857
01:08:17,280 --> 01:08:19,600
You need to determine what audit logging is required

1858
01:08:19,600 --> 01:08:21,440
and how you will detect misuse.

1859
01:08:21,440 --> 01:08:24,080
If something goes wrong, you need a plan for how to respond.

1860
01:08:24,080 --> 01:08:27,120
Write actual policies, not aspirational guidelines.

1861
01:08:27,120 --> 01:08:29,320
Inforcible policies that your teams will implement.

1862
01:08:29,320 --> 01:08:30,920
This is the governance infrastructure

1863
01:08:30,920 --> 01:08:33,160
that keeps MCP from becoming chaos.

1864
01:08:33,160 --> 01:08:34,480
Month three to four.

1865
01:08:34,480 --> 01:08:35,520
Pilot deployment.

1866
01:08:35,520 --> 01:08:37,640
Deploy the MCP server to a pilot group.

1867
01:08:37,640 --> 01:08:38,920
One business use case.

1868
01:08:38,920 --> 01:08:40,600
One team, one AI tool.

1869
01:08:40,600 --> 01:08:42,120
Measure what changes.

1870
01:08:42,120 --> 01:08:43,880
How long did it take to build the automation

1871
01:08:43,880 --> 01:08:46,320
compared to if you had used custom connectors?

1872
01:08:46,320 --> 01:08:47,440
What issues emerged?

1873
01:08:47,440 --> 01:08:49,200
What worked better than expected?

1874
01:08:49,200 --> 01:08:51,840
You need to see which governance controls needed adjustment.

1875
01:08:51,840 --> 01:08:53,360
This isn't production at scale.

1876
01:08:53,360 --> 01:08:54,760
It's controlled learning.

1877
01:08:54,760 --> 01:08:57,280
Month four plus deliberate expansion.

1878
01:08:57,280 --> 01:09:00,000
Once the pilot succeeds, expand gradually.

1879
01:09:00,000 --> 01:09:02,640
Add another domain, build another MCP server.

1880
01:09:02,640 --> 01:09:05,880
Retire the custom connectors that MCP now handles.

1881
01:09:05,880 --> 01:09:06,680
This isn't a race.

1882
01:09:06,680 --> 01:09:08,120
It's a structured migration.

1883
01:09:08,120 --> 01:09:09,920
Each new domain teaches you something.

1884
01:09:09,920 --> 01:09:11,600
Each new server improves your pattern.

1885
01:09:11,600 --> 01:09:14,040
Each retired connector reduces your maintenance burden.

1886
01:09:14,040 --> 01:09:16,000
The timeline matters less than the sequence.

1887
01:09:16,000 --> 01:09:18,000
Order then improve metadata, then design,

1888
01:09:18,000 --> 01:09:20,280
then govern, then deploy, then expand.

1889
01:09:20,280 --> 01:09:22,040
Skip steps and you create problems.

1890
01:09:22,040 --> 01:09:23,920
Rush and you build on weak foundations.

1891
01:09:23,920 --> 01:09:25,240
The structural shift.

1892
01:09:25,240 --> 01:09:26,680
What's actually changing?

1893
01:09:26,680 --> 01:09:28,560
You can understand MCP technically

1894
01:09:28,560 --> 01:09:30,240
and miss what is actually changing.

1895
01:09:30,240 --> 01:09:32,400
The protocol is JSON RPC.

1896
01:09:32,400 --> 01:09:33,960
The architecture is hub and spoke.

1897
01:09:33,960 --> 01:09:35,360
The tools are discoverable.

1898
01:09:35,360 --> 01:09:36,720
The governance is centralized.

1899
01:09:36,720 --> 01:09:37,920
You can comprehend all of that

1900
01:09:37,920 --> 01:09:39,840
and still not understand the fundamental shift

1901
01:09:39,840 --> 01:09:40,760
happening underneath.

1902
01:09:40,760 --> 01:09:41,960
The shift isn't technical.

1903
01:09:41,960 --> 01:09:43,920
It's philosophical.

1904
01:09:43,920 --> 01:09:47,240
For 20 years, integration teams asked a specific question.

1905
01:09:47,240 --> 01:09:49,440
How do I connect this system to that system?

1906
01:09:49,440 --> 01:09:51,080
That's the question that defined the work.

1907
01:09:51,080 --> 01:09:52,440
You have Salesforce over here.

1908
01:09:52,440 --> 01:09:54,040
You have a data warehouse over there.

1909
01:09:54,040 --> 01:09:55,240
How do you make them talk?

1910
01:09:55,240 --> 01:09:56,320
You build a bridge.

1911
01:09:56,320 --> 01:09:59,000
You write code that understands the Salesforce API.

1912
01:09:59,000 --> 01:10:01,000
Understands the data warehouse schema,

1913
01:10:01,000 --> 01:10:03,080
translates between them and handles the errors.

1914
01:10:03,080 --> 01:10:04,280
That's the integration problem.

1915
01:10:04,280 --> 01:10:05,880
That's what consumed engineering effort

1916
01:10:05,880 --> 01:10:07,440
and mental cycles for decades.

1917
01:10:07,440 --> 01:10:08,640
That question is still valid.

1918
01:10:08,640 --> 01:10:10,200
You still need to connect systems,

1919
01:10:10,200 --> 01:10:12,200
but it's no longer the organizing question.

1920
01:10:12,200 --> 01:10:13,720
The organizing question is shifting.

1921
01:10:13,720 --> 01:10:14,840
Now the question is,

1922
01:10:14,840 --> 01:10:17,360
what capabilities should this system expose?

1923
01:10:17,360 --> 01:10:18,920
That is a different question entirely.

1924
01:10:18,920 --> 01:10:20,760
It is not how do I connect?

1925
01:10:20,760 --> 01:10:23,680
It is, what do I want others to do with this system?

1926
01:10:23,680 --> 01:10:25,680
Not what can I technically make possible?

1927
01:10:25,680 --> 01:10:27,680
But what should be possible?

1928
01:10:27,680 --> 01:10:29,400
Not how do I write the code?

1929
01:10:29,400 --> 01:10:31,160
But what does the surface look like?

1930
01:10:31,160 --> 01:10:33,200
This isn't semantic wordplay.

1931
01:10:33,200 --> 01:10:36,200
This is a structural shift in how you think about the problem.

1932
01:10:36,200 --> 01:10:38,120
When you ask, how do I connect?

1933
01:10:38,120 --> 01:10:39,920
You are thinking about point to point.

1934
01:10:39,920 --> 01:10:41,480
You are solving a specific problem.

1935
01:10:41,480 --> 01:10:42,440
You are writing code.

1936
01:10:42,440 --> 01:10:43,640
You are building the bridge.

1937
01:10:43,640 --> 01:10:45,720
The code solves that particular problem

1938
01:10:45,720 --> 01:10:48,440
and then you are done until the next problem arrives.

1939
01:10:48,440 --> 01:10:51,680
This mindset optimizes for the speed of individual solutions.

1940
01:10:51,680 --> 01:10:53,800
It focuses on velocity for the current task

1941
01:10:53,800 --> 01:10:55,280
and getting the connector built.

1942
01:10:55,280 --> 01:10:57,920
But when you ask, what should this system expose?

1943
01:10:57,920 --> 01:10:59,200
You are thinking about platforms.

1944
01:10:59,200 --> 01:11:00,800
You are designing surfaces.

1945
01:11:00,800 --> 01:11:03,000
You are thinking about all the potential consumers

1946
01:11:03,000 --> 01:11:04,840
and what constraints should be visible.

1947
01:11:04,840 --> 01:11:07,280
You are deciding what should be safe and what shouldn't.

1948
01:11:07,280 --> 01:11:10,280
You are thinking about governance and discoverability.

1949
01:11:10,280 --> 01:11:12,480
This mindset optimizes for sustainability.

1950
01:11:12,480 --> 01:11:15,320
It focuses on reusability and letting the system evolve

1951
01:11:15,320 --> 01:11:16,840
without breaking everything downstream.

1952
01:11:16,840 --> 01:11:18,880
These questions produce different results.

1953
01:11:18,880 --> 01:11:22,080
The first question produces a collection of custom connectors.

1954
01:11:22,080 --> 01:11:23,520
Each one solves one problem.

1955
01:11:23,520 --> 01:11:26,440
Each one embeds the thinking of the person who built it.

1956
01:11:26,440 --> 01:11:28,120
Each one handles errors in its own way.

1957
01:11:28,120 --> 01:11:30,120
Each one implements security differently.

1958
01:11:30,120 --> 01:11:31,640
Together, they form a patchwork.

1959
01:11:31,640 --> 01:11:32,480
It works.

1960
01:11:32,480 --> 01:11:33,440
But it is not cohesive.

1961
01:11:33,440 --> 01:11:34,280
It is not governed.

1962
01:11:34,280 --> 01:11:36,280
It is not sustainable at scale.

1963
01:11:36,280 --> 01:11:38,280
The second question produces platforms.

1964
01:11:38,280 --> 01:11:39,600
Design surfaces.

1965
01:11:39,600 --> 01:11:41,000
Explicit boundaries.

1966
01:11:41,000 --> 01:11:44,080
Intentional choices about what is available and what isn't.

1967
01:11:44,080 --> 01:11:45,560
Consistent governance.

1968
01:11:45,560 --> 01:11:47,440
It requires more upfront thinking,

1969
01:11:47,440 --> 01:11:48,880
but the result scales.

1970
01:11:48,880 --> 01:11:49,720
The result evolves.

1971
01:11:49,720 --> 01:11:50,920
The result can be governed.

1972
01:11:50,920 --> 01:11:53,600
MCP isn't forcing this shift, but it is enabling it.

1973
01:11:53,600 --> 01:11:55,280
By making it possible to expose tools

1974
01:11:55,280 --> 01:11:57,560
through a standard protocol that AI can discover,

1975
01:11:57,560 --> 01:12:00,240
MCP removes the constraint that made point to point

1976
01:12:00,240 --> 01:12:01,440
feel necessary.

1977
01:12:01,440 --> 01:12:03,880
Before, you needed custom code for each connection

1978
01:12:03,880 --> 01:12:05,240
because every consumer was different

1979
01:12:05,240 --> 01:12:07,200
and every consumer had different requirements.

1980
01:12:07,200 --> 01:12:08,840
But with MCP and AI automation,

1981
01:12:08,840 --> 01:12:11,000
you can have many consumers accessing the same tools

1982
01:12:11,000 --> 01:12:12,440
through a standard interface.

1983
01:12:12,440 --> 01:12:14,240
That makes platform thinking practical.

1984
01:12:14,240 --> 01:12:16,120
The organization succeeding with MCP

1985
01:12:16,120 --> 01:12:18,520
are the ones making this mental shift consciously.

1986
01:12:18,520 --> 01:12:21,960
They are not deploying MCP as a replacement for custom connectors.

1987
01:12:21,960 --> 01:12:24,080
They are deploying MCP as a different way

1988
01:12:24,080 --> 01:12:25,560
of thinking about integration.

1989
01:12:25,560 --> 01:12:26,840
They are asking different questions.

1990
01:12:26,840 --> 01:12:29,760
They are designing surfaces instead of building bridges.

1991
01:12:29,760 --> 01:12:31,920
This is also why you cannot just bolt MCP

1992
01:12:31,920 --> 01:12:33,800
onto your existing integration infrastructure

1993
01:12:33,800 --> 01:12:35,000
and expect success.

1994
01:12:35,000 --> 01:12:36,840
The technical integration is easy.

1995
01:12:36,840 --> 01:12:37,880
Plug in the connector.

1996
01:12:37,880 --> 01:12:38,600
Done.

1997
01:12:38,600 --> 01:12:40,200
But the thinking shift is hard.

1998
01:12:40,200 --> 01:12:42,840
It requires you to look at your systems differently.

1999
01:12:42,840 --> 01:12:45,640
You have to ask yourself what capabilities you want to expose

2000
01:12:45,640 --> 01:12:47,480
rather than just what you need to connect.

2001
01:12:47,480 --> 01:12:49,360
You have to think about governance and boundaries

2002
01:12:49,360 --> 01:12:51,600
explicitly rather than implicitly.

2003
01:12:51,600 --> 01:12:53,400
You have to design for discoverability

2004
01:12:53,400 --> 01:12:55,200
rather than just for functionality.

2005
01:12:55,200 --> 01:12:56,880
The organizations that treat MCP

2006
01:12:56,880 --> 01:12:59,680
as a technical implementation fail quietly.

2007
01:12:59,680 --> 01:13:00,920
They deploy it, they get some value.

2008
01:13:00,920 --> 01:13:02,800
But they don't unlock the velocity gains

2009
01:13:02,800 --> 01:13:05,040
because they haven't made the conceptual shift.

2010
01:13:05,040 --> 01:13:07,360
The organizations that treat it as a thinking shift,

2011
01:13:07,360 --> 01:13:09,800
as a fundamental change in how integration should work,

2012
01:13:09,800 --> 01:13:12,520
those are the ones that get the disproportionate returns.

2013
01:13:12,520 --> 01:13:16,120
It's not about the protocol, it's about the model, the future.

2014
01:13:16,120 --> 01:13:18,960
What MCP means for enterprise integration?

2015
01:13:18,960 --> 01:13:20,400
The path forward is visible.

2016
01:13:20,400 --> 01:13:22,680
It isn't a certainty because nothing ever is.

2017
01:13:22,680 --> 01:13:25,200
But the direction matters much more than the speed right now.

2018
01:13:25,200 --> 01:13:27,280
Custom integration as we know it is ending.

2019
01:13:27,280 --> 01:13:28,440
This won't happen in six months

2020
01:13:28,440 --> 01:13:30,240
and it might not even happen in two years.

2021
01:13:30,240 --> 01:13:32,920
But the model that organized how companies connect systems

2022
01:13:32,920 --> 01:13:34,760
for two decades is finishing.

2023
01:13:34,760 --> 01:13:36,920
The real question isn't whether this shift happens.

2024
01:13:36,920 --> 01:13:40,160
It's how quickly it moves and who gets left behind in the process.

2025
01:13:40,160 --> 01:13:43,560
Within three to five years, MCP will be the default way

2026
01:13:43,560 --> 01:13:45,800
that AI accesses your enterprise data.

2027
01:13:45,800 --> 01:13:48,600
It won't be the exception or some innovative side project.

2028
01:13:48,600 --> 01:13:50,520
It will be the default infrastructure layer

2029
01:13:50,520 --> 01:13:53,320
that every new AI use case sits on top of.

2030
01:13:53,320 --> 01:13:55,880
Organizations will stop thinking about integration

2031
01:13:55,880 --> 01:13:57,720
as a series of point-to-point connections

2032
01:13:57,720 --> 01:13:59,840
and start seeing it as a capability platform.

2033
01:13:59,840 --> 01:14:02,600
The companies that move early will finish their consolidation

2034
01:14:02,600 --> 01:14:04,800
while the ones that delayed will still be stuck,

2035
01:14:04,800 --> 01:14:08,040
managing a messy hybrid of custom connectors and REST APIs.

2036
01:14:08,040 --> 01:14:08,920
This isn't a prophecy.

2037
01:14:08,920 --> 01:14:10,440
It's just tracking the inevitable.

2038
01:14:10,440 --> 01:14:13,160
The economic forces driving this change are structural,

2039
01:14:13,160 --> 01:14:15,800
which means you simply cannot maintain hundreds of custom

2040
01:14:15,800 --> 01:14:18,400
connectors under the cost structure that AI creates.

2041
01:14:18,400 --> 01:14:21,280
You can't stay competitive if every new AI project

2042
01:14:21,280 --> 01:14:23,360
requires eight weeks of integration work

2043
01:14:23,360 --> 01:14:25,480
while your competitor deploys in days.

2044
01:14:25,480 --> 01:14:27,920
Governing AI-driven data access becomes impossible

2045
01:14:27,920 --> 01:14:30,680
when that access is scattered across point-to-point connections

2046
01:14:30,680 --> 01:14:32,000
that nobody fully understands.

2047
01:14:32,000 --> 01:14:34,520
The old model breaks under scale and organizations

2048
01:14:34,520 --> 01:14:36,280
will migrate away because they have to,

2049
01:14:36,280 --> 01:14:37,760
not because they want to.

2050
01:14:37,760 --> 01:14:39,480
Competitive advantage goes to the teams

2051
01:14:39,480 --> 01:14:41,360
that make this shift early and on purpose.

2052
01:14:41,360 --> 01:14:43,560
These organizations aren't drowning in integration debt

2053
01:14:43,560 --> 01:14:46,200
because they're busy building platform capabilities instead.

2054
01:14:46,200 --> 01:14:48,520
They measure the velocity of new AI automations

2055
01:14:48,520 --> 01:14:50,120
in weeks rather than months.

2056
01:14:50,120 --> 01:14:52,480
They deploy insights at a pace their rivals can't match

2057
01:14:52,480 --> 01:14:54,920
because their infrastructure actually supports that scale.

2058
01:14:54,920 --> 01:14:57,720
For a few years, this creates a massive structural advantage

2059
01:14:57,720 --> 01:14:59,480
and while the laggards might catch up eventually

2060
01:14:59,480 --> 01:15:00,880
the gap will be wide by then.

2061
01:15:00,880 --> 01:15:02,720
So what happens to the companies that don't move?

2062
01:15:02,720 --> 01:15:05,000
They won't disappear but they will become severely constrained

2063
01:15:05,000 --> 01:15:06,640
by their own lack of capacity.

2064
01:15:06,640 --> 01:15:09,120
They'll spend their time maintaining old infrastructure

2065
01:15:09,120 --> 01:15:11,560
and building custom connectors for every new problem

2066
01:15:11,560 --> 01:15:12,440
that pops up.

2067
01:15:12,440 --> 01:15:14,640
While they wait months for a single automation project

2068
01:15:14,640 --> 01:15:16,960
to finish, their competitors will be experimenting

2069
01:15:16,960 --> 01:15:18,320
and learning every single day.

2070
01:15:18,320 --> 01:15:19,960
That rate of experimentation compounds

2071
01:15:19,960 --> 01:15:22,040
into a massive disadvantage over time.

2072
01:15:22,040 --> 01:15:23,800
The slower organization falls behind

2073
01:15:23,800 --> 01:15:26,000
because they're running the same race on a treadmill

2074
01:15:26,000 --> 01:15:27,680
while everyone else moves forward.

2075
01:15:27,680 --> 01:15:29,800
This shift is inevitable because the economic equation

2076
01:15:29,800 --> 01:15:30,640
has tipped.

2077
01:15:30,640 --> 01:15:33,920
It isn't about MCP being perfect or custom integration being bad.

2078
01:15:33,920 --> 01:15:36,160
It's about the fact that the cost structure has changed.

2079
01:15:36,160 --> 01:15:38,560
Organizations in competitive markets have to move

2080
01:15:38,560 --> 01:15:39,520
or they will lose.

2081
01:15:39,520 --> 01:15:41,200
That's the mechanism at work here.

2082
01:15:41,200 --> 01:15:43,120
We also have to look at how vendors are converging

2083
01:15:43,120 --> 01:15:44,440
and Thropic didn't create MCP

2084
01:15:44,440 --> 01:15:46,240
because they had a problem with REST APIs.

2085
01:15:46,240 --> 01:15:47,840
They built it because they saw a future

2086
01:15:47,840 --> 01:15:50,280
where AI agents are autonomous and need a standardized way

2087
01:15:50,280 --> 01:15:51,560
to talk to enterprise systems.

2088
01:15:51,560 --> 01:15:55,040
Open AI, Google, Microsoft, and AWS all see the same thing.

2089
01:15:55,040 --> 01:15:57,680
The entire AI industry is moving toward MCP

2090
01:15:57,680 --> 01:15:59,720
as the integration layer for the future.

2091
01:15:59,720 --> 01:16:02,600
That consensus makes any individual resistance irrelevant

2092
01:16:02,600 --> 01:16:04,520
because the train is already moving.

2093
01:16:04,520 --> 01:16:07,160
You can be on it or you can be run over by it.

2094
01:16:07,160 --> 01:16:08,680
The leaders who understand this are making

2095
01:16:08,680 --> 01:16:09,880
different decisions right now.

2096
01:16:09,880 --> 01:16:11,800
They aren't debating whether to move to MCP

2097
01:16:11,800 --> 01:16:14,400
but are instead busy planning the actual migration.

2098
01:16:14,400 --> 01:16:16,400
They're training their teams and accepting

2099
01:16:16,400 --> 01:16:18,440
that this is necessary infrastructure work

2100
01:16:18,440 --> 01:16:20,280
rather than optional innovation.

2101
01:16:20,280 --> 01:16:22,360
That mindset changes everything from how they allocate

2102
01:16:22,360 --> 01:16:25,080
resources to who they hire and where they invest.

2103
01:16:25,080 --> 01:16:27,000
Dataverse MCP isn't the end of integration.

2104
01:16:27,000 --> 01:16:28,440
It's the end of custom integration

2105
01:16:28,440 --> 01:16:30,280
being the default way we solve problems.

2106
01:16:30,280 --> 01:16:31,800
That is the distinction that matters.

2107
01:16:31,800 --> 01:16:34,640
For the last 20 years, integration meant writing code

2108
01:16:34,640 --> 01:16:36,920
and building wrappers for specific problems.

2109
01:16:36,920 --> 01:16:39,040
That model served its purpose when change was slow

2110
01:16:39,040 --> 01:16:41,600
and scale was limited but that era is over.

2111
01:16:41,600 --> 01:16:43,120
You're moving from static endpoints

2112
01:16:43,120 --> 01:16:45,040
to intent-driven context discovery.

2113
01:16:45,040 --> 01:16:47,680
You're moving from building bridges to designing platforms.

2114
01:16:47,680 --> 01:16:49,440
You're moving from solving one of problems

2115
01:16:49,440 --> 01:16:51,240
to building sustainable infrastructure.

2116
01:16:51,240 --> 01:16:53,800
This shift requires three specific things from you.

2117
01:16:53,800 --> 01:16:55,920
First, you need to audit your custom connectors

2118
01:16:55,920 --> 01:16:58,600
to see which ones are actually candidates for MCP.

2119
01:16:58,600 --> 01:17:01,840
Second, you must improve your dataverse metadata right now

2120
01:17:01,840 --> 01:17:03,840
even before you deploy anything.

2121
01:17:03,840 --> 01:17:06,680
Write descriptions that an AI can actually reason over

2122
01:17:06,680 --> 01:17:08,520
so your data structure is intelligible

2123
01:17:08,520 --> 01:17:09,920
to an autonomous system.

2124
01:17:09,920 --> 01:17:13,200
Third, design your first MCP server with a deliberate plan.

2125
01:17:13,200 --> 01:17:16,360
Start small, learn the lessons and then scale up.

2126
01:17:16,360 --> 01:17:19,200
Don't just deploy and hope that governance follows later.

2127
01:17:19,200 --> 01:17:22,120
You have to build governance into the deployment from day one.

2128
01:17:22,120 --> 01:17:23,720
The future of enterprise integration

2129
01:17:23,720 --> 01:17:26,520
is intent-driven, governed and standardized.

2130
01:17:26,520 --> 01:17:29,440
Dataverse MCP is the tool that gets you there.