This episode of the M365.FM Podcast titled “The Agentic Mirage: Why Your Enterprise Architecture is Eroding Under Copilot” explains why simply adopting Microsoft Copilot without a disciplined architectural strategy can quietly collapse your enterprise architecture. Most organizations treat Copilot as a feature or better search box — but once Copilot becomes agentic (able to take actions that change state), it multiplies executive authority across the environment without explicit approval or controls. This leads to identity drift, tool and connector sprawl, and obedient data leakage because agents execute within your permission graph and data sprawl rather than a governed system. The episode identifies three failure modes that shut down programs (none of which are about hallucinations) and introduces four safeguards — non-human identities, standardized tool contracts, authoritative data boundaries, and runtime drift detection — that can actually scale safely. It emphasizes that governance is an enforced control plane, not a set of policies or dashboards, and that if you can’t isolate, prove, and contain individual agent actions, you’re not running a program — you’re accumulating incident debt.
🧠 Core Theme
Copilot is not just a feature — it’s a distributed decision engine layered on top of your existing architecture (permission graph, connectors, data, and unfinished governance).
Once Copilot transitions from assistive AI (generating text) to agentic AI (executing actions), it changes your enterprise architecture — often in uncontrolled and invisible ways.
The episode reframes how enterprises must govern and architect Copilot to avoid architectural erosion and unmanaged authority proliferation.
🔑 Key Concepts Explained
🔹 Copilot’s Dual Nature: Assistive vs. Agentic
Assistive AI produces text — when it’s wrong, humans ignore or correct it.
Agentic AI produces actions — and actions are either authorized or unauthorized, contained or tenant-wide.
The architectural risk emerges not from hallucinations but from uncontrolled execution authority.
The episode urges shifting from modeling Copilot as UI features to viewing it as part of the enterprise control plane.
⚠️ Three Failure Modes of Agentic Copilot
1️⃣ Identity Drift
Agents often run under ambiguous principals — maker identities, shared service accounts, or vague automation contexts.
This results in unprovable actions and breaks accountability.
In enterprise settings, once an agent action cannot be attributed with evidence, the architecture fails to meet audit and compliance standards.
2️⃣ Tool & Connector Sprawl
Tools and connectors aren’t accessories — they represent executable authority.
When different teams wire Copilot to perform actions independently (“create ticket,” “update record,” “grant access”), system boundaries collapse.
The estate stops being architectural and becomes accidental — duplicate tools, divergent permissions, inconsistent approvals, and unpredictable blast radii.
Without shared contracts and standard paths, containment politics prevent surgical fixes.
3️⃣ Obedient Data Leakage
Agents leak sensitive or inappropriate data not out of malice but obedience.
If agents are grounded on all readable content rather than curated authoritative domains, they operationalize stale copies, overshared documents, and unmanaged artifacts.
Compliance depends on proof of authority and source, not whether the answer “looks correct.”
🛠️ Four Safeguards That Actually Scale
To avoid architectural erosion, the episode introduces four safeguards:
🔹 1. One Agent, One Identity
Assign each agent a first-class Entra (Azure AD) identity.
Add ownership, lifecycle policies, and a kill switch.
Permit disabling without disabling Copilot globally.
🔹 2. Standardized Tool Contracts
Treat tools as contracts, not connectors.
Use structured outputs, explicit refusal modes, and irreversible action tokens tied to identity and parameters.
Reduce duplication and inconsistent blast radii.
🔹 3. Authoritative Data Domains
Agents should only ground on curated, approved content domains.
Humans can wander, but agents must respect data boundaries.
“Readable” is not the same as “authorized to action.”
🔹 4. Runtime Drift Detection
Design-time controls alone are insufficient.
Agents must be monitored continuously for drift in identity, tool usage, and bounding conditions.
Drift detection enables survival containment playbooks that don’t freeze the entire AI program.
📌 Minimal Viable Agent Control Plane (MVACP)
The episode defines a control plane — not a framework — that includes:
• One distinct agent identity
• One curated tool path
• One bounded data domain
• One tested runtime containment playbook
• Provenance and auditability by defaultWithout this, Copilot adoption accumulates incident debt instead of governed capability.
🔎 Executive Reality Check
If your organization can’t answer these reliably, you’re not ready to scale Copilot agent programs:
Can we disable one agent without disabling Copilot entirely?
Can we prove where a specific answer came from?
Can we show who authorized an action and which tool executed it?
Do we know how many tools exist and where authority duplicates?
Narratives don’t pass audit — evidence does.
🧠 Why This Matters
Copilot erodes architecture not because it’s intelligent, but because it’s executable authority without enforced boundaries.
Helping systems are local and reversible; executing systems modify state globally.
Sprawl isn’t a chaos symptom — it’s a predictable consequence of undefined authority, identity drift, and lack of control plane enforcement.
🎯 Key Takeaways
Copilot is a distributed decision system, not a feature toggle.
Agentic AI changes state — meaning authority controls and accountability must be explicit.
Architectural erosion happens quietly — helpful becomes authorized without clear audits.
Identity, tool contracts, authoritative domains, and runtime containment are non-negotiable for scale.
Without a control plane, enterprises risk reactive incident management instead of strategic automation.
1
00:00:00,000 --> 00:00:04,300
Most enterprises roll out co-pilot like it's a nicer search box and a faster PowerPoint
2
00:00:04,300 --> 00:00:05,300
in turn.
3
00:00:05,300 --> 00:00:06,300
They are wrong.
4
00:00:06,300 --> 00:00:09,760
The moment co-pilot becomes agentic, it stops answering questions and starts taking
5
00:00:09,760 --> 00:00:13,160
actions and that multiplies authority across your tenant without anyone admitting they
6
00:00:13,160 --> 00:00:14,500
approved it.
7
00:00:14,500 --> 00:00:19,180
In this episode, three failure modes that shut programs down, four safeguards that actually
8
00:00:19,180 --> 00:00:24,400
scale, and one minimal viable control plane you can build without pretending policy decks
9
00:00:24,400 --> 00:00:25,700
are enforcement.
10
00:00:25,700 --> 00:00:29,820
And yes, identity drift will halt your program faster than hallucinations.
11
00:00:29,820 --> 00:00:30,820
That detail matters.
12
00:00:30,820 --> 00:00:31,820
Hold it.
13
00:00:31,820 --> 00:00:34,120
The core misconception.
14
00:00:34,120 --> 00:00:36,440
Assistance don't erode architecture actors do.
15
00:00:36,440 --> 00:00:40,200
The foundational misunderstanding is that co-pilot is a feature.
16
00:00:40,200 --> 00:00:45,060
Something you toggle on, then users get faster at email and meetings and everyone claps.
17
00:00:45,060 --> 00:00:47,800
In architectural terms, co-pilot is not a feature.
18
00:00:47,800 --> 00:00:52,000
It is a distributed decision engine sitting on top of your permission graph, your connectors,
19
00:00:52,000 --> 00:00:54,120
your data sprawl, and your unfinished governance.
20
00:00:54,120 --> 00:00:57,080
It behaves exactly like every other distributed system.
21
00:00:57,080 --> 00:01:02,200
It amplifies whatever is already true, including the parts you hoped nobody would notice.
22
00:01:02,200 --> 00:01:04,160
So the first simplification is this.
23
00:01:04,160 --> 00:01:08,000
Assistive AI and agentic AI are not the same category.
24
00:01:08,000 --> 00:01:11,080
Assistive AI drafts, summarizes, searches and proposes.
25
00:01:11,080 --> 00:01:15,040
It produces text even when it's wrong, it's usually reversible, a human can ignore it.
26
00:01:15,040 --> 00:01:17,540
The blast radius is social and local.
27
00:01:17,540 --> 00:01:21,800
One person makes one bad decision, then you clean it up with training, disclaimers and
28
00:01:21,800 --> 00:01:23,840
the usual corporate therapy.
29
00:01:23,840 --> 00:01:25,480
Agentic AI does something else.
30
00:01:25,480 --> 00:01:30,240
It decides to call tools, trigger workflows, create records, change permissions, send messages,
31
00:01:30,240 --> 00:01:33,560
file tickets, update systems of record, it produces actions.
32
00:01:33,560 --> 00:01:35,160
And actions aren't mostly correct.
33
00:01:35,160 --> 00:01:39,600
Er, they are either authorized or unauthorized, contained or uncontained, attributable or
34
00:01:39,600 --> 00:01:40,760
unprovable.
35
00:01:40,760 --> 00:01:44,360
That distinction matters because enterprises love probabilistic outcomes when the output
36
00:01:44,360 --> 00:01:49,360
is a paragraph, but they demand deterministic outcomes when the output is a state change.
37
00:01:49,360 --> 00:01:52,360
And an agent's output is always a state change somewhere.
38
00:01:52,360 --> 00:01:56,040
In a place your team won't notice for weeks, this is where the mirage begins.
39
00:01:56,040 --> 00:01:59,120
In the assistive world, the core question is, did it hallucinate?
40
00:01:59,120 --> 00:02:03,000
In the agentic world, the core questions are, who executed this?
41
00:02:03,000 --> 00:02:04,360
By what authority?
42
00:02:04,360 --> 00:02:05,960
Through which tool path?
43
00:02:05,960 --> 00:02:07,520
Against which data boundary?
44
00:02:07,520 --> 00:02:11,120
Can we stop just this one thing without shutting down the entire program?
45
00:02:11,120 --> 00:02:15,280
Most organizations don't ask those questions upfront because they misclassify agents as
46
00:02:15,280 --> 00:02:16,800
UI extensions.
47
00:02:16,800 --> 00:02:20,720
They treat them like a chat surface glued onto Microsoft 365, something cute inside
48
00:02:20,720 --> 00:02:21,720
teams.
49
00:02:21,720 --> 00:02:23,320
Antic systems don't live in the UI.
50
00:02:23,320 --> 00:02:24,560
They live in the graph.
51
00:02:24,560 --> 00:02:29,400
Every permission, every connector, every delegated grant, every environment, every DLP
52
00:02:29,400 --> 00:02:34,520
exception, every temporary service account becomes part of the agent's reachable universe.
53
00:02:34,520 --> 00:02:37,720
Not because the model is evil, because the estate is permissive.
54
00:02:37,720 --> 00:02:40,960
And then the inevitable happens, helpful becomes authorized.
55
00:02:40,960 --> 00:02:42,560
It doesn't happen with a big approval meeting.
56
00:02:42,560 --> 00:02:45,920
It happens with the quiet accumulation of capability.
57
00:02:45,920 --> 00:02:50,200
Someone adds a connector to just read tickets, then it needs to update status, then it needs
58
00:02:50,200 --> 00:02:51,640
to create a record.
59
00:02:51,640 --> 00:02:55,120
And it needs a delegated permission because the maker didn't want to do app registration
60
00:02:55,120 --> 00:02:56,120
work.
61
00:02:56,120 --> 00:03:00,880
Then a service account appears because it's easier than designing non-human identity properly.
62
00:03:00,880 --> 00:03:04,840
Then the agent is shared because it worked for one team, then cloned because another team
63
00:03:04,840 --> 00:03:06,840
wants a version optimized locally.
64
00:03:06,840 --> 00:03:10,080
None of those steps feels like a security event in the moment.
65
00:03:10,080 --> 00:03:12,160
Collectively, they are architectural erosion.
66
00:03:12,160 --> 00:03:13,720
Here's the counter-intuitive part.
67
00:03:13,720 --> 00:03:18,080
The more productive the agent feels, the more dangerous the governance drift becomes.
68
00:03:18,080 --> 00:03:22,200
Because success creates demand, demand creates replication and replication creates sprawl.
69
00:03:22,200 --> 00:03:23,960
And sprawl is where architecture dies.
70
00:03:23,960 --> 00:03:27,600
Because in a sprawl scenario, the enterprise stops operating a designed automation pathway
71
00:03:27,600 --> 00:03:29,960
and starts operating a folklore network.
72
00:03:29,960 --> 00:03:34,240
Dozens of agents, dozens of tools, overlapping scopes and inconsistent enforcement.
73
00:03:34,240 --> 00:03:36,240
You can't reason about it as a system anymore.
74
00:03:36,240 --> 00:03:37,840
You can only react to incidents.
75
00:03:37,840 --> 00:03:39,600
Now layer in probabilistic behavior.
76
00:03:39,600 --> 00:03:41,480
The human operator understands context.
77
00:03:41,480 --> 00:03:42,480
They can pause.
78
00:03:42,480 --> 00:03:43,720
They can say this looks wrong.
79
00:03:43,720 --> 00:03:46,360
An agent doesn't pause unless you engineered it to pause.
80
00:03:46,360 --> 00:03:49,200
It will take the action it believes matches the intent.
81
00:03:49,200 --> 00:03:53,760
With whatever authority it can reach, using the toolpath you accidentally made available.
82
00:03:53,760 --> 00:03:57,680
So when leaders say we can tolerate some inaccuracy, they are importing an assistive mindset
83
00:03:57,680 --> 00:03:59,040
into an agentic environment.
84
00:03:59,040 --> 00:04:00,280
That is not a small error.
85
00:04:00,280 --> 00:04:01,280
That is the error.
86
00:04:01,280 --> 00:04:04,560
In an agentic system, good enough answers become irreversible outcomes.
87
00:04:04,560 --> 00:04:06,000
A wrong answer can be embarrassing.
88
00:04:06,000 --> 00:04:10,160
A wrong action can be a breach of financial posting, a permissions change, a contract email,
89
00:04:10,160 --> 00:04:11,160
or an audit finding.
90
00:04:11,160 --> 00:04:13,400
And when an audit asks, who did this?
91
00:04:13,400 --> 00:04:14,840
You don't get to respond with vibes.
92
00:04:14,840 --> 00:04:19,280
You need provable attribution, which brings the conversation back to what this episode is
93
00:04:19,280 --> 00:04:20,560
actually about.
94
00:04:20,560 --> 00:04:24,320
Not models, not prompts, not the weekly feature drop.
95
00:04:24,320 --> 00:04:25,480
Control.
96
00:04:25,480 --> 00:04:30,840
If agents are actors, governance has to govern actor primitives, identity, tool contracts,
97
00:04:30,840 --> 00:04:33,000
data boundaries, and runtime detection.
98
00:04:33,000 --> 00:04:37,320
Not after the fact, not in a policy PDF, enforced by design continuously at scale.
99
00:04:37,320 --> 00:04:39,440
Otherwise, you are not rolling out co-pilot.
100
00:04:39,440 --> 00:04:41,920
You are distributing authority.
101
00:04:41,920 --> 00:04:45,240
When you will act surprised when the system behaves like it always does.
102
00:04:45,240 --> 00:04:46,800
It takes the easiest path.
103
00:04:46,800 --> 00:04:51,760
It accretes exceptions and it converts your clean intent into conditional chaos.
104
00:04:51,760 --> 00:04:57,240
Next, what governance actually is when it's real, an enforcement chain, not a meeting.
105
00:04:57,240 --> 00:04:58,240
Governance isn't policy.
106
00:04:58,240 --> 00:05:00,200
It's an enforcement chai.
107
00:05:00,200 --> 00:05:02,760
Most enterprises confuse governance with documentation.
108
00:05:02,760 --> 00:05:08,080
They produce a policy deck, schedule a monthly AI steering committee, and declare the situation
109
00:05:08,080 --> 00:05:09,080
handled.
110
00:05:09,080 --> 00:05:12,280
It's not a ship agent anyway because the business wants momentum and the controls aren't
111
00:05:12,280 --> 00:05:13,880
real enough to slow anything down.
112
00:05:13,880 --> 00:05:15,440
That distinction matters.
113
00:05:15,440 --> 00:05:16,920
Policy is intent.
114
00:05:16,920 --> 00:05:18,920
Governance is enforced constraint.
115
00:05:18,920 --> 00:05:21,640
Intent without constraint is entropy with a nice font.
116
00:05:21,640 --> 00:05:24,280
An agent doesn't read your SharePoint policy side.
117
00:05:24,280 --> 00:05:27,640
It reads whatever it's allowed to read, calls whatever it's allowed to call, and acts as
118
00:05:27,640 --> 00:05:29,320
whatever identity you gave it.
119
00:05:29,320 --> 00:05:30,960
The system doesn't care what you meant.
120
00:05:30,960 --> 00:05:32,520
It only cares what you configured.
121
00:05:32,520 --> 00:05:35,280
So the right question isn't, do we have policies?
122
00:05:35,280 --> 00:05:37,800
The right question is, do we have an enforcement chain?
123
00:05:37,800 --> 00:05:42,320
An enforcement chain is the sequence of technical and operational gates that turn, we don't want
124
00:05:42,320 --> 00:05:44,160
that into, that cannot happen.
125
00:05:44,160 --> 00:05:49,560
And when it still happens, because it will, turns it into, we can prove it, contain it,
126
00:05:49,560 --> 00:05:52,720
and learn from it without freezing the program.
127
00:05:52,720 --> 00:05:56,560
In practice, an agent governance enforcement chain has four links.
128
00:05:56,560 --> 00:05:59,720
First, identity, not branding, not naming conventions.
129
00:05:59,720 --> 00:06:04,360
Actual identities that can be isolated, scoped, rotated, disabled, reviewed, and audited.
130
00:06:04,360 --> 00:06:06,720
If an agent runs as a maker, you don't have an agent.
131
00:06:06,720 --> 00:06:09,160
You have a shadow user with automation privileges.
132
00:06:09,160 --> 00:06:12,120
Second, tool contracts.
133
00:06:12,120 --> 00:06:13,760
Tools are not connectors.
134
00:06:13,760 --> 00:06:17,680
In architectural terms, they are executable interfaces into systems of record.
135
00:06:17,680 --> 00:06:23,080
A tool defines what actions exist, what parameters are allowed, what outputs look like, and
136
00:06:23,080 --> 00:06:25,480
what approvals gate irreversible steps.
137
00:06:25,480 --> 00:06:29,000
If you let every team wire up its own toolpath, you aren't building agents.
138
00:06:29,000 --> 00:06:33,360
You are building a distributed inconsistent integration layer with zero change control.
139
00:06:33,360 --> 00:06:35,360
Third, data boundaries.
140
00:06:35,360 --> 00:06:37,160
That will clean up SharePoint later.
141
00:06:37,160 --> 00:06:38,160
That's not a boundary.
142
00:06:38,160 --> 00:06:39,160
That's a backlog.
143
00:06:39,160 --> 00:06:43,920
A boundary is a deny by default decision that defines what an agent may ground on by domain,
144
00:06:43,920 --> 00:06:45,240
label, and purpose.
145
00:06:45,240 --> 00:06:46,800
Humans can roam because they have judgment.
146
00:06:46,800 --> 00:06:48,880
Agents can't, so they don't get to roam.
147
00:06:48,880 --> 00:06:51,880
Fourth, runtime detection and response, because drift is inevitable.
148
00:06:51,880 --> 00:06:53,080
People will pressure the system.
149
00:06:53,080 --> 00:06:54,160
They will add exceptions.
150
00:06:54,160 --> 00:06:55,280
They will broaden scopes.
151
00:06:55,280 --> 00:06:57,000
They will temporarily bypass approvals.
152
00:06:57,000 --> 00:06:59,960
They will do it with good intentions, and the system will accept it.
153
00:06:59,960 --> 00:07:03,200
So detection becomes part of governance, not an afterthought.
154
00:07:03,200 --> 00:07:06,680
Now, enterprises love to say, we do security reviews.
155
00:07:06,680 --> 00:07:08,000
A security review is a meeting.
156
00:07:08,000 --> 00:07:09,400
A meeting is not a control plane.
157
00:07:09,400 --> 00:07:13,920
A control plane is the set of mechanisms that enforces your assumptions at scale.
158
00:07:13,920 --> 00:07:18,400
The identities that represent actors, the contracts that constrain action, the boundaries
159
00:07:18,400 --> 00:07:23,760
that constrain data, and the telemetry that tells you when reality diverges from intent.
160
00:07:23,760 --> 00:07:28,440
In other words, the control plane is the thing that makes safe to scale a measurable property,
161
00:07:28,440 --> 00:07:31,640
and safe to scale has three non-negotiable attributes.
162
00:07:31,640 --> 00:07:36,200
Icelate, you must be able to isolate one agent's identity, one agent's tool access, one agent's
163
00:07:36,200 --> 00:07:39,160
data domain, and stop it without collateral damage.
164
00:07:39,160 --> 00:07:43,200
If your only emergency response is turn off co-pilot, you don't have governance.
165
00:07:43,200 --> 00:07:44,720
You have a panic button.
166
00:07:44,720 --> 00:07:45,720
Attribute.
167
00:07:45,720 --> 00:07:50,040
You must be able to answer, who did this, and by what authority with evidence, not inference?
168
00:07:50,040 --> 00:07:52,080
That includes agent to agent chains.
169
00:07:52,080 --> 00:07:55,960
If attribution disappears after the first hop, then your audit story becomes a probabilistic
170
00:07:55,960 --> 00:07:56,960
narrative.
171
00:07:56,960 --> 00:07:58,360
Auditors don't accept narratives.
172
00:07:58,360 --> 00:07:59,680
They accept proof.
173
00:07:59,680 --> 00:08:00,680
Contain.
174
00:08:00,680 --> 00:08:02,800
You must be able to limit blast radius by design.
175
00:08:02,800 --> 00:08:08,640
That means approvals for irreversible actions, scoped permissions, and bounded data access.
176
00:08:08,640 --> 00:08:12,480
Otherwise a single prompt injection, a single bad tool call or a single overshared site,
177
00:08:12,480 --> 00:08:14,080
becomes a tenant-wide incident.
178
00:08:14,080 --> 00:08:16,000
And here's the drift pattern that always shows up.
179
00:08:16,000 --> 00:08:17,200
It starts as an exception.
180
00:08:17,200 --> 00:08:18,400
Then it becomes a shortcut.
181
00:08:18,400 --> 00:08:20,560
Then it becomes a local optimization.
182
00:08:20,560 --> 00:08:24,400
One team fixes friction by widening access or adding a connector.
183
00:08:24,400 --> 00:08:28,480
Then it becomes global ambiguity, because now five teams copied that pattern, and none
184
00:08:28,480 --> 00:08:30,360
of them tracked the rationale.
185
00:08:30,360 --> 00:08:32,360
Entropy compounds through convenience.
186
00:08:32,360 --> 00:08:33,960
That's not a failure of people.
187
00:08:33,960 --> 00:08:36,280
That is the default behavior of complex systems.
188
00:08:36,280 --> 00:08:38,760
Over time, policies drift away from enforcement.
189
00:08:38,760 --> 00:08:43,160
Exceptions become norms, ownership dissolves, and the system quietly becomes a probabilistic
190
00:08:43,160 --> 00:08:44,160
security model.
191
00:08:44,160 --> 00:08:47,680
So if you want real governance, you stop writing rules and start building constraints.
192
00:08:47,680 --> 00:08:51,440
You define a minimal control plane that you can actually operate, and you treat every
193
00:08:51,440 --> 00:08:53,640
missing constraint as an entropy generator.
194
00:08:53,640 --> 00:08:56,680
Next, the first failure mode that collapses the whole illusion.
195
00:08:56,680 --> 00:08:57,680
Identity drift.
196
00:08:57,680 --> 00:09:01,600
Once accountability goes probabilistic, security pauses the program.
197
00:09:01,600 --> 00:09:04,360
Every time, failure mode won, identity drift.
198
00:09:04,360 --> 00:09:06,120
Silent accountability loss.
199
00:09:06,120 --> 00:09:09,720
Identity drift is where the whole will govern this later fantasy dies.
200
00:09:09,720 --> 00:09:12,680
Not because the agent said something wrong, because you can't prove who did something
201
00:09:12,680 --> 00:09:13,680
real.
202
00:09:13,680 --> 00:09:18,480
In the early days, most co-pilot studio and power platform agents run in one of three identity
203
00:09:18,480 --> 00:09:19,480
shapes.
204
00:09:19,480 --> 00:09:24,000
The makers credentials, a shared service account, or some vague automation context that
205
00:09:24,000 --> 00:09:26,520
exists mostly to keep the flow running.
206
00:09:26,520 --> 00:09:29,600
All three create the same operational outcome.
207
00:09:29,600 --> 00:09:33,480
Accountability becomes a story you tell, not a fact you can demonstrate.
208
00:09:33,480 --> 00:09:37,720
And when the first incident happens, an unexpected permission change, a record update in a system
209
00:09:37,720 --> 00:09:42,400
of action, an email sent to the wrong distribution list, the question isn't, "Why did the model
210
00:09:42,400 --> 00:09:43,400
hallucinate?"
211
00:09:43,400 --> 00:09:45,960
The question is, who executed this action?
212
00:09:45,960 --> 00:09:49,160
If your answer starts with, "Well, it depends, you're done."
213
00:09:49,160 --> 00:09:52,160
Because once identity drifts, you don't get deterministic auditability.
214
00:09:52,160 --> 00:09:53,680
You get a probabilistic narrative.
215
00:09:53,680 --> 00:09:58,480
The maker built it, the agent ran it, the connector used delegated permissions, the flow executed
216
00:09:58,480 --> 00:10:02,560
under a connection reference, the action happened in the target system, and the initiating
217
00:10:02,560 --> 00:10:06,680
user is somewhere in the chat transcript maybe.
218
00:10:06,680 --> 00:10:09,200
That is not attribution, that is archaeology.
219
00:10:09,200 --> 00:10:13,080
And the moment security teams realize they're doing archaeology, they pause the program,
220
00:10:13,080 --> 00:10:16,520
not because they hate co-pilot, because the cost of being wrong is higher than the cost
221
00:10:16,520 --> 00:10:17,520
of being late.
222
00:10:17,520 --> 00:10:21,720
They can't sign off on a system where who did this can't be answered with evidence.
223
00:10:21,720 --> 00:10:23,240
Here's the uncomfortable truth.
224
00:10:23,240 --> 00:10:24,880
Security drift is usually designed in.
225
00:10:24,880 --> 00:10:28,720
It gets designed in because people optimize for velocity, not for probability.
226
00:10:28,720 --> 00:10:31,320
A maker wants to test quickly so they use their own credentials.
227
00:10:31,320 --> 00:10:36,300
A team wants to avoid app registrations and proper non-human identity design, so they
228
00:10:36,300 --> 00:10:38,320
grab an existing service account.
229
00:10:38,320 --> 00:10:41,960
Someone wants an integration that just works, so they accept whatever identity the connector
230
00:10:41,960 --> 00:10:42,960
defaults to.
231
00:10:42,960 --> 00:10:44,160
None of that looks malicious.
232
00:10:44,160 --> 00:10:46,960
Its convenience, convenience is an entropy generator.
233
00:10:46,960 --> 00:10:52,440
And once it ships, identity drift becomes sticky, because it's invisible during success.
234
00:10:52,440 --> 00:10:55,160
And the agent behaves, nobody questions which identity it used.
235
00:10:55,160 --> 00:10:56,160
The agent helped.
236
00:10:56,160 --> 00:11:00,280
The ticket got created, the record got updated, the email went out, everyone moves on until
237
00:11:00,280 --> 00:11:01,280
the day it doesn't.
238
00:11:01,280 --> 00:11:06,160
Then you get the incident review where someone asks for the simplest thing in enterprise computing.
239
00:11:06,160 --> 00:11:07,160
Show the actor.
240
00:11:07,160 --> 00:11:10,720
Not the owner of the solution, not the person who last edited the flow, not the user who
241
00:11:10,720 --> 00:11:13,640
typed the prompt, the actor that had authority at runtime.
242
00:11:13,640 --> 00:11:18,320
And if the agent executed actions as the maker identity, you've created an automation pathway
243
00:11:18,320 --> 00:11:21,080
that depends on a human account life cycle.
244
00:11:21,080 --> 00:11:26,120
That's what resets MFA changes, conditional access policy updates, a role removal, a disabled
245
00:11:26,120 --> 00:11:30,720
account, suddenly the agent breaks or worse, the team creates workarounds that expand privileges
246
00:11:30,720 --> 00:11:32,920
just to keep the automation alive.
247
00:11:32,920 --> 00:11:37,400
If the agent executed actions as a shared service account, you've created the opposite problem,
248
00:11:37,400 --> 00:11:38,840
continuity without accountability.
249
00:11:38,840 --> 00:11:43,720
The automation keeps running even when the people behind it change roles or leave.
250
00:11:43,720 --> 00:11:46,640
Security can't tie actions to a responsible sponsor.
251
00:11:46,640 --> 00:11:50,920
Auditors see one identity, doing everything, everywhere across multiple agents.
252
00:11:50,920 --> 00:11:52,800
It's not service reliability.
253
00:11:52,800 --> 00:11:54,760
That's a single point of irreversible blame.
254
00:11:54,760 --> 00:11:59,040
And if the agent executed actions through a vague automation context, you get the worst
255
00:11:59,040 --> 00:12:00,280
possible outcome.
256
00:12:00,280 --> 00:12:03,000
Logs exist, but they don't answer the question you're being asked.
257
00:12:03,000 --> 00:12:04,200
You can see that something happened.
258
00:12:04,200 --> 00:12:06,040
You can often see that a connector fired.
259
00:12:06,040 --> 00:12:09,800
You might even see the flow run, but you can't draw a clean line from initiating intent
260
00:12:09,800 --> 00:12:12,080
to executing identity across hops.
261
00:12:12,080 --> 00:12:15,520
This is why identity drift stops programs faster than hallucinations.
262
00:12:15,520 --> 00:12:17,840
Hallucinations are a model quality problem.
263
00:12:17,840 --> 00:12:22,640
It's a treat that like training data, prompt design, and will add a disclaimer.
264
00:12:22,640 --> 00:12:24,360
Identity drift is a governance failure.
265
00:12:24,360 --> 00:12:28,360
It means the enterprise can't assert control over the system's actors, and once an enterprise
266
00:12:28,360 --> 00:12:32,720
can't assert control over actors, it cannot claim compliance, accountability, or containment.
267
00:12:32,720 --> 00:12:35,920
So the reality in incident response becomes brutal.
268
00:12:35,920 --> 00:12:40,440
Security looks at the system and asks, can we disable the specific agent that misbehaved?
269
00:12:40,440 --> 00:12:44,480
If the agent identity is the maker, disabling it means disabling a person.
270
00:12:44,480 --> 00:12:45,880
That is a HR event.
271
00:12:45,880 --> 00:12:47,120
Not a containment action.
272
00:12:47,120 --> 00:12:52,080
If the agent identity is a shared service account, disabling it might kill five other automations
273
00:12:52,080 --> 00:12:53,920
that also quietly depend on it.
274
00:12:53,920 --> 00:12:55,160
That is collateral damage.
275
00:12:55,160 --> 00:12:59,960
So the default choice becomes pause co-pilot broadly, stop publishing, stop experimentation,
276
00:12:59,960 --> 00:13:02,440
freeze the program, then run a retroactive inventory.
277
00:13:02,440 --> 00:13:03,520
And that's the pattern.
278
00:13:03,520 --> 00:13:05,760
One attribution gap creates a full stop.
279
00:13:05,760 --> 00:13:08,920
Not because the organization is dramatic, because it can't isolate the actor.
280
00:13:08,920 --> 00:13:11,480
So if you remember one thing from this failure mode, it's this.
281
00:13:11,480 --> 00:13:16,400
An agent without a stable, non-human, isolatable identity is not an agent you can govern.
282
00:13:16,400 --> 00:13:18,400
It is a distributed liability generator.
283
00:13:18,400 --> 00:13:22,160
Next, where identity drift actually comes from in Microsoft Estates.
284
00:13:22,160 --> 00:13:26,200
Because it's not magic, it's the accumulation of specific pathways you can name.
285
00:13:26,200 --> 00:13:29,760
How identity drift is manufactured in Microsoft Estate.
286
00:13:29,760 --> 00:13:31,520
Identity drift doesn't happen.
287
00:13:31,520 --> 00:13:34,600
You build it, usually with good intentions and a deadline.
288
00:13:34,600 --> 00:13:37,320
The first factory line is the maker credential path.
289
00:13:37,320 --> 00:13:42,360
In co-pilot studio, power automate, logic apps, and the broader power platform ecosystem,
290
00:13:42,360 --> 00:13:47,240
creates something under their own identity, connects to outlook, SharePoint, Graph, Service
291
00:13:47,240 --> 00:13:48,400
Now, whatever.
292
00:13:48,400 --> 00:13:49,400
And it works.
293
00:13:49,400 --> 00:13:51,040
That success becomes a prototype.
294
00:13:51,040 --> 00:13:55,040
Then because prototypes always get promoted to temporary production, the maker's connection
295
00:13:55,040 --> 00:13:57,000
becomes the runtime authority.
296
00:13:57,000 --> 00:13:59,840
Now the agent isn't operating as an enterprise actor.
297
00:13:59,840 --> 00:14:01,200
It's operating as a human shadow.
298
00:14:01,200 --> 00:14:02,680
You don't have a stable principle.
299
00:14:02,680 --> 00:14:08,400
You have a person-shaped dependency that will change, leave, rotate, MFA, or get conditional
300
00:14:08,400 --> 00:14:09,800
access hardened.
301
00:14:09,800 --> 00:14:13,800
And the automation will either fail or get fixed by widening privileges.
302
00:14:13,800 --> 00:14:17,000
The second factory line is the service account shortcut.
303
00:14:17,000 --> 00:14:21,160
Someone creates a single account named something like SVC Automation and uses it everywhere
304
00:14:21,160 --> 00:14:25,840
because it avoids the pain of proper app registration and non-human identity life cycle.
305
00:14:25,840 --> 00:14:27,480
This feels operationally mature.
306
00:14:27,480 --> 00:14:28,480
It is not.
307
00:14:28,480 --> 00:14:32,520
You've just created one identity with broad, long-lived access that becomes the execution
308
00:14:32,520 --> 00:14:35,520
substrate for multiple agents, flows, and connectors.
309
00:14:35,520 --> 00:14:39,200
When anything goes wrong, you can't isolate without collateral damage.
310
00:14:39,200 --> 00:14:44,160
That service account becomes the tenant's anonymous root for automation, except it's not anonymous.
311
00:14:44,160 --> 00:14:45,160
It's worse.
312
00:14:45,160 --> 00:14:47,400
It's attributable to everyone and therefore to no one.
313
00:14:47,400 --> 00:14:50,840
The third factory line is delegated permissions and implicit graph reach.
314
00:14:50,840 --> 00:14:54,720
People talk about the agent respects permissions and they mean user access controls for reading
315
00:14:54,720 --> 00:14:55,720
content.
316
00:14:55,720 --> 00:14:56,720
That's not the whole story.
317
00:14:56,720 --> 00:15:01,340
Tool calls and connectors often run through delegated permissions, connection references,
318
00:15:01,340 --> 00:15:07,160
and consent grants that create reach far beyond what the business thinks it approved.
319
00:15:07,160 --> 00:15:11,040
If is the big one once you allow a toolpath that can call graph under a delegated or application
320
00:15:11,040 --> 00:15:16,080
context, you've effectively handed the agent a programmable interface to the tenant.
321
00:15:16,080 --> 00:15:18,520
The agent doesn't need access to everything.
322
00:15:18,520 --> 00:15:24,480
It needs access to the right pivot points, group membership, mailbox actions, teams messages,
323
00:15:24,480 --> 00:15:26,440
share point sites, user profiles.
324
00:15:26,440 --> 00:15:30,880
That is the graph and that reach doesn't feel real until you discover it during an incident.
325
00:15:30,880 --> 00:15:33,200
Now add environments sprawl.
326
00:15:33,200 --> 00:15:36,640
Every enterprise says it has dev test prod.
327
00:15:36,640 --> 00:15:40,840
When the power platform is state evolves like all estates do, people create environments for
328
00:15:40,840 --> 00:15:46,000
a business unit, for a project, for a proof of concept, for a partner demo, for a crisis.
329
00:15:46,000 --> 00:15:50,800
DLP policies differ, connector allowances differ, who can create connections differs.
330
00:15:50,800 --> 00:15:55,360
And when an agent built in a permissive environment becomes popular, it gets cloned or exported
331
00:15:55,360 --> 00:15:59,360
or rebuilt elsewhere with slightly different identity and permission behavior.
332
00:15:59,360 --> 00:16:00,920
That's how drift becomes permanent.
333
00:16:00,920 --> 00:16:06,440
The same agent exists as five similar implementations, each with different runtime identity
334
00:16:06,440 --> 00:16:07,840
and tool wiring.
335
00:16:07,840 --> 00:16:09,760
And nobody can say which one is authoritative.
336
00:16:09,760 --> 00:16:11,360
Then you get agent to agent chains.
337
00:16:11,360 --> 00:16:13,320
This is where attribution dies quietly.
338
00:16:13,320 --> 00:16:17,920
In a multi-step interaction, an initiating user triggers agent A, agent A calls agent B,
339
00:16:17,920 --> 00:16:23,120
agent B calls a tool, the tool triggers a flow, the flow writes to a system of record.
340
00:16:23,120 --> 00:16:26,840
Logs existed each hop, but the initiating identity often doesn't survive across hops
341
00:16:26,840 --> 00:16:28,360
as a clean, queryable chain.
342
00:16:28,360 --> 00:16:31,680
You can find the conversation transcript, you can find the tool call, you can find the
343
00:16:31,680 --> 00:16:32,680
flow run.
344
00:16:32,680 --> 00:16:35,480
What you can't always prove is the end-to-end actor lineage.
345
00:16:35,480 --> 00:16:40,640
This human intent caused this specific state change under this specific non-human identity
346
00:16:40,640 --> 00:16:42,080
with these permissions.
347
00:16:42,080 --> 00:16:45,320
In other words, you have telemetry, you don't have accountability.
348
00:16:45,320 --> 00:16:47,600
And the runs as ambiguity makes it worse.
349
00:16:47,600 --> 00:16:52,360
Power automate, connector execution and tool invocation can look like it ran as the connection,
350
00:16:52,360 --> 00:16:56,920
it ran as the owner, it ran as the maker, it ran as the environment or it ran as the service
351
00:16:56,920 --> 00:17:00,240
principle depending on how the solution was built.
352
00:17:00,240 --> 00:17:01,400
Operators know this pain.
353
00:17:01,400 --> 00:17:05,640
The system offers multiple valid pathways and each pathway has different audit semantics.
354
00:17:05,640 --> 00:17:09,520
The logs will faithfully record what happened, but not in the narrative structure auditors
355
00:17:09,520 --> 00:17:10,520
demand.
356
00:17:10,520 --> 00:17:12,880
So when security asks, can we contain one agent?
357
00:17:12,880 --> 00:17:16,840
The honest answer becomes not reliably because you can't isolate the identity, you can't
358
00:17:16,840 --> 00:17:21,360
scope the permissions and you can't guarantee the kill switch won't take down other automations
359
00:17:21,360 --> 00:17:23,240
that reuse the same credential.
360
00:17:23,240 --> 00:17:24,840
That's why more logging is not the fix.
361
00:17:24,840 --> 00:17:26,480
Logging tells you what burned down.
362
00:17:26,480 --> 00:17:27,960
It doesn't stop the fire.
363
00:17:27,960 --> 00:17:32,080
The first thing you do is you just have to do the same thing.
364
00:17:32,080 --> 00:17:36,800
And the first thing you do is you just have to do the same thing.
365
00:17:36,800 --> 00:17:41,320
And the second thing you do is you just have to do the same thing.
366
00:17:41,320 --> 00:17:45,600
And the second thing you do is you just have to do the same thing.
367
00:17:45,600 --> 00:17:49,600
And the second thing you do is you just have to do the same thing.
368
00:17:49,600 --> 00:17:53,600
And the second thing you do is you just have to do the same thing.
369
00:17:53,600 --> 00:17:57,920
And the second thing you do is you just have to do the same thing.
370
00:17:57,920 --> 00:17:59,920
And the second thing you do is you just have to do the same thing.
371
00:17:59,920 --> 00:18:01,920
And the second thing you do is you just have to do the same thing.
372
00:18:01,920 --> 00:18:03,920
And the second thing you do is you just have to do the same thing.
373
00:18:03,920 --> 00:18:05,920
And the second thing you do is you just have to do the same thing.
374
00:18:05,920 --> 00:18:07,920
And the second thing you do is you just have to do the same thing.
375
00:18:07,920 --> 00:18:09,920
And the second thing you do is you just have to do the same thing.
376
00:18:09,920 --> 00:18:11,920
And the second thing you do is you just have to do the same thing.
377
00:18:11,920 --> 00:18:13,920
And the second thing you do is you just have to do the same thing.
378
00:18:13,920 --> 00:18:15,920
And the second thing you do is you just have to do the same thing.
379
00:18:15,920 --> 00:18:17,920
And the second thing you do is you just have to do the same thing.
380
00:18:17,920 --> 00:18:19,920
And the second thing you do is you just have to do the same thing.
381
00:18:19,920 --> 00:18:21,920
And the second thing you do is you just have to do the same thing.
382
00:18:21,920 --> 00:18:33,920
And the second thing you do is you just have to do the same thing.
383
00:18:33,920 --> 00:18:35,920
And the second thing you do is you just have to do the same thing.
384
00:18:35,920 --> 00:18:37,920
And the second thing you do is you just have to do the same thing.
385
00:18:37,920 --> 00:18:39,920
And the second thing you do is you just have to do the same thing.
386
00:18:39,920 --> 00:18:41,920
And the second thing you do is you just have to do the same thing.
387
00:18:41,920 --> 00:18:43,920
And the second thing you do is you just have to do the same thing.
388
00:18:43,920 --> 00:18:45,920
And the second thing you do is you just have to do the same thing.
389
00:18:45,920 --> 00:18:47,920
And the second thing you do is you just have to do the same thing.
390
00:18:47,920 --> 00:18:49,920
And the second thing you do is you just have to do the same thing.
391
00:18:49,920 --> 00:18:51,920
And the second thing you do is you just have to do the same thing.
392
00:18:51,920 --> 00:18:53,920
And the second thing you do is you just have to do the same thing.
393
00:18:53,920 --> 00:18:55,920
And the second thing you do is you just have to do the same thing.
394
00:18:55,920 --> 00:18:57,920
And the second thing you do is you just have to do the same thing.
395
00:18:57,920 --> 00:18:59,920
And the second thing you do is you just have to do the same thing.
396
00:18:59,920 --> 00:19:01,920
And the second thing you do is you just have to do the same thing.
397
00:19:01,920 --> 00:19:03,920
And the second thing you do is you just have to do the same thing.
398
00:19:03,920 --> 00:19:05,920
And the second thing you do is you just have to do the same thing.
399
00:19:05,920 --> 00:19:07,920
And the second thing you do is you just have to do the same thing.
400
00:19:07,920 --> 00:19:09,920
And the second thing you do is you just have to do the same thing.
401
00:19:09,920 --> 00:19:11,920
And the second thing you do is you just have to do the same thing.
402
00:19:11,920 --> 00:19:13,920
And the second thing you do is you just have to do the same thing.
403
00:19:13,920 --> 00:19:23,920
And the second thing you do is you just have to do the same thing.
404
00:19:23,920 --> 00:19:25,920
And the second thing you do is you just have to do the same thing.
405
00:19:25,920 --> 00:19:27,920
And the second thing you do is you just have to do the same thing.
406
00:19:27,920 --> 00:19:29,920
And the second thing you do is you just have to do the same thing.
407
00:19:29,920 --> 00:19:31,920
And the second thing you do is you just have to do the same thing.
408
00:19:31,920 --> 00:19:33,920
And the second thing you do is you just have to do the same thing.
409
00:19:33,920 --> 00:19:35,920
And the second thing you do is you just have to do the same thing.
410
00:19:35,920 --> 00:19:37,920
And the second thing you do is you just have to do the same thing.
411
00:19:37,920 --> 00:19:39,920
And the second thing you do is you just have to do the same thing.
412
00:19:39,920 --> 00:19:41,920
And the second thing you do is you just have to do the same thing.
413
00:19:41,920 --> 00:19:43,920
And the second thing you do is you just have to do the same thing.
414
00:19:43,920 --> 00:19:45,920
And the second thing you do is you just have to do the same thing.
415
00:19:45,920 --> 00:19:47,920
And the second thing you do is you just have to do the same thing.
416
00:19:47,920 --> 00:19:49,920
And the second thing you do is you just have to do the same thing.
417
00:19:49,920 --> 00:19:51,920
And the second thing you do is you just have to do the same thing.
418
00:19:51,920 --> 00:19:53,920
And the second thing you do is you just have to do the same thing.
419
00:19:53,920 --> 00:19:55,920
And the second thing you do is you just have to do the same thing.
420
00:19:55,920 --> 00:19:57,920
And the second thing you do is you just have to do the same thing.
421
00:19:57,920 --> 00:19:59,920
And the second thing you do is you just have to do the same thing.
422
00:19:59,920 --> 00:20:01,920
And the second thing you do is you just have to do the same thing.
423
00:20:01,920 --> 00:20:03,920
And the second thing you do is you just have to do the same thing.
424
00:20:03,920 --> 00:20:05,920
And the second thing you do is you just have to do the same thing.
425
00:20:05,920 --> 00:20:13,920
And the second thing you do is you just have to do the same thing.
426
00:20:13,920 --> 00:20:15,920
And the second thing you do is you just have to do the same thing.
427
00:20:15,920 --> 00:20:17,920
And the second thing you do is you just have to do the same thing.
428
00:20:17,920 --> 00:20:19,920
And the second thing you do is you just have to do the same thing.
429
00:20:19,920 --> 00:20:21,920
And the second thing you do is you just have to do the same thing.
430
00:20:21,920 --> 00:20:23,920
And the second thing you do is you just have to do the same thing.
431
00:20:23,920 --> 00:20:25,920
And the second thing you do is you just have to do the same thing.
432
00:20:25,920 --> 00:20:27,920
And the second thing you do is you just have to do the same thing.
433
00:20:27,920 --> 00:20:29,920
And the second thing you do is you just have to do the same thing.
434
00:20:29,920 --> 00:20:31,920
And the second thing you do is you just have to do the same thing.
435
00:20:31,920 --> 00:20:33,920
And the second thing you do is you just have to do the same thing.
436
00:20:33,920 --> 00:20:33,920
And the second thing you do is you just have to do the same thing.
437
00:20:33,920 --> 00:20:35,920
And the second thing you do is you just have to do the same thing.
438
00:20:35,920 --> 00:20:37,920
And the second thing you do is you just have to do the same thing.
439
00:20:37,920 --> 00:20:39,920
And the second thing you do is you just have to do the same thing.
440
00:20:39,920 --> 00:20:41,920
And the second thing you do is you just have to do the same thing.
441
00:20:41,920 --> 00:20:43,920
And the second thing you do is you just have to do the same thing.
442
00:20:43,920 --> 00:20:45,920
And the second thing you do is you just have to do the same thing.
443
00:20:45,920 --> 00:20:47,920
And the second thing you do is you just have to do the same thing.
444
00:20:47,920 --> 00:20:49,920
And the second thing you do is you just have to do the same thing.
445
00:20:49,920 --> 00:20:51,920
And the second thing you do is you just have to do the same thing.
446
00:20:51,920 --> 00:20:53,920
And the second thing you do is you just have to do the same thing.
447
00:20:53,920 --> 00:20:55,920
And the second thing you do is you just have to do the same thing.
448
00:20:55,920 --> 00:20:57,920
And the second thing you do is you just have to do the same thing.
449
00:20:57,920 --> 00:21:09,920
And the second thing you do is you just have to do the same thing.
450
00:21:09,920 --> 00:21:11,920
And the second thing you do is you just have to do the same thing.
451
00:21:11,920 --> 00:21:13,920
And the second thing you do is you just have to do the same thing.
452
00:21:13,920 --> 00:21:15,920
And the second thing you do is you just have to do the same thing.
453
00:21:15,920 --> 00:21:17,920
And the second thing you do is you just have to do the same thing.
454
00:21:17,920 --> 00:21:19,920
And the second thing you do is you just have to do the same thing.
455
00:21:19,920 --> 00:21:21,920
And the second thing you do is you just have to do the same thing.
456
00:21:21,920 --> 00:21:23,920
And the second thing you do is you just have to do the same thing.
457
00:21:23,920 --> 00:21:25,920
And the second thing you do is you just have to do the same thing.
458
00:21:25,920 --> 00:21:26,920
And the second thing you do is you just have to do the same thing.
459
00:21:26,920 --> 00:21:28,920
And the second thing you do is you just have to do the same thing.
460
00:21:28,920 --> 00:21:30,920
And the second thing you do is you just have to do the same thing.
461
00:21:30,920 --> 00:21:32,920
And the second thing you do is you just have to do the same thing.
462
00:21:32,920 --> 00:21:34,920
And the second thing you do is you just have to do the same thing.
463
00:21:34,920 --> 00:21:36,920
And the second thing you do is you just have to do the same thing.
464
00:21:36,920 --> 00:21:38,920
And the second thing you do is you just have to do the same thing.
465
00:21:38,920 --> 00:21:40,920
And the second thing you do is you just have to do the same thing.
466
00:21:40,920 --> 00:21:42,920
And the second thing you do is you just have to do the same thing.
467
00:21:42,920 --> 00:21:44,920
And the second thing you do is you just have to do the same thing.
468
00:21:44,920 --> 00:21:46,920
And the second thing you do is you just have to do the same thing.
469
00:21:46,920 --> 00:21:48,920
And the second thing you do is you just have to do the same thing.
470
00:21:48,920 --> 00:21:50,920
And the second thing you do is you just have to do the same thing.
471
00:21:50,920 --> 00:22:02,920
And the second thing you do is you just have to do the same thing.
472
00:22:02,920 --> 00:22:04,920
And the second thing you do is you just have to do the same thing.
473
00:22:04,920 --> 00:22:06,920
And the second thing you do is you just have to do the same thing.
474
00:22:06,920 --> 00:22:08,920
And the second thing you do is you just have to do the same thing.
475
00:22:08,920 --> 00:22:10,920
And the second thing you do is you just have to do the same thing.
476
00:22:10,920 --> 00:22:12,920
And the second thing you do is you just have to do the same thing.
477
00:22:12,920 --> 00:22:14,920
And the second thing you do is you just have to do the same thing.
478
00:22:14,920 --> 00:22:16,920
And the second thing you do is you just have to do the same thing.
479
00:22:16,920 --> 00:22:18,920
And the second thing you do is you just have to do the same thing.
480
00:22:18,920 --> 00:22:20,920
And the second thing you do is you just have to do the same thing.
481
00:22:20,920 --> 00:22:22,920
And the second thing you do is you just have to do the same thing.
482
00:22:22,920 --> 00:22:24,920
And the second thing you do is you just have to do the same thing.
483
00:22:24,920 --> 00:22:26,920
And the second thing you do is you just have to do the same thing.
484
00:22:26,920 --> 00:22:28,920
And the second thing you do is you just have to do the same thing.
485
00:22:28,920 --> 00:22:30,920
And the second thing you do is you just have to do the same thing.
486
00:22:30,920 --> 00:22:32,920
And the second thing you do is you just have to do the same thing.
487
00:22:32,920 --> 00:22:34,920
And the second thing you do is you just have to do the same thing.
488
00:22:34,920 --> 00:22:36,920
And the second thing you do is you just have to do the same thing.
489
00:22:36,920 --> 00:22:38,920
And the second thing you do is you just have to do the same thing.
490
00:22:38,920 --> 00:22:40,920
And the second thing you do is you just have to do the same thing.
491
00:22:40,920 --> 00:22:42,920
And the second thing you do is you just have to do the same thing.
492
00:22:42,920 --> 00:22:53,920
When every team wires its own tool chain, you get multiple implementations of the same business outcome, each with different permissions, different logging semantics, different error handling, different approvals and different drift behavior.
493
00:22:53,920 --> 00:22:57,920
Over time, the estate stops being an architecture, it becomes an accident.
494
00:22:57,920 --> 00:23:05,920
The sprawl usually looks harmless because it hides behind familiar words, connector, flow, integration, skill, tool.
495
00:23:05,920 --> 00:23:07,920
Those are comforting nouns.
496
00:23:07,920 --> 00:23:10,920
In reality, they are decision paths and decision paths accumulate.
497
00:23:10,920 --> 00:23:12,920
The first sprawl vector is duplication.
498
00:23:12,920 --> 00:23:16,920
Two teams both need create service now ticket, so they each build a separate flow.
499
00:23:16,920 --> 00:23:19,920
One uses delegated credentials.
500
00:23:19,920 --> 00:23:21,920
One uses a service account. One includes an approval step.
501
00:23:21,920 --> 00:23:23,920
One doesn't. One writes back a ticket number.
502
00:23:23,920 --> 00:23:25,920
One fails silently when the API throttles.
503
00:23:25,920 --> 00:23:27,920
Same outcome on the whiteboard.
504
00:23:27,920 --> 00:23:29,920
Completely different operational behavior in the tenant.
505
00:23:29,920 --> 00:23:31,920
Then comes variation.
506
00:23:31,920 --> 00:23:35,920
Team A adds a connector to just read from a SharePoint site for grounding.
507
00:23:35,920 --> 00:23:40,920
Team B adds a different connector to read from team's messages because it's faster.
508
00:23:40,920 --> 00:23:43,920
Team C adds graph because they couldn't get the connector to behave.
509
00:23:43,920 --> 00:23:47,920
Each one expands the agent's reachable universe in a slightly different way.
510
00:23:47,920 --> 00:23:52,920
And because no one is tracking tool contracts centrally, nobody can say how many ways your tenant can now create a ticket,
511
00:23:52,920 --> 00:23:54,920
update a record, or grant access.
512
00:23:54,920 --> 00:24:00,920
The second sprawl vector is chaining agents call tools that trigger flows, that call other tools that trigger other agents.
513
00:24:00,920 --> 00:24:04,920
This is where helpful automation becomes distributed transaction behavior.
514
00:24:04,920 --> 00:24:07,920
Without any of the discipline of distributed transactions.
515
00:24:07,920 --> 00:24:10,920
No explicit failure domains. No consistent rollback.
516
00:24:10,920 --> 00:24:12,920
No idem potency guarantees.
517
00:24:12,920 --> 00:24:14,920
No single place to see the full path of an action.
518
00:24:14,920 --> 00:24:17,920
So a small change becomes a wide blast radius.
519
00:24:17,920 --> 00:24:19,920
Someone updates a tool to add a new field.
520
00:24:19,920 --> 00:24:22,920
Another agent that reuses the tool interprets the new output differently.
521
00:24:22,920 --> 00:24:24,920
A downstream flow fails and retries.
522
00:24:24,920 --> 00:24:26,920
The agency's a retries a new instruction.
523
00:24:26,920 --> 00:24:28,920
The ticket gets created twice.
524
00:24:28,920 --> 00:24:31,920
Then the cleanup automation closes the wrong one.
525
00:24:31,920 --> 00:24:34,920
Then the human gets blamed for not using the system correctly.
526
00:24:34,920 --> 00:24:35,920
Conditional chaos.
527
00:24:35,920 --> 00:24:38,920
And this is where enterprises make the foundational mistake.
528
00:24:38,920 --> 00:24:41,920
They try to govern tools like the govern apps.
529
00:24:41,920 --> 00:24:42,920
Apps have bounded surfaces.
530
00:24:42,920 --> 00:24:44,920
Tools don't. Tools are composable authority.
531
00:24:44,920 --> 00:24:47,920
A tool can be called by any agent that can see it.
532
00:24:47,920 --> 00:24:50,920
In any sequence under pressure with partial context.
533
00:24:50,920 --> 00:24:54,920
So if you allow tools to proliferate, you don't scale productivity.
534
00:24:54,920 --> 00:24:55,920
You scale side effects.
535
00:24:55,920 --> 00:24:59,920
And side effects are what turn executive enthusiasm into executive risk aversion.
536
00:24:59,920 --> 00:25:03,920
Because once sprawl sets in, nobody can answer the core operational questions with confidence.
537
00:25:03,920 --> 00:25:04,920
How many tools exist?
538
00:25:04,920 --> 00:25:05,920
Which ones are duplicates?
539
00:25:05,920 --> 00:25:07,920
Which ones write to systems of record?
540
00:25:07,920 --> 00:25:09,920
Which ones can change permissions?
541
00:25:09,920 --> 00:25:11,920
Which ones can send messages externally?
542
00:25:11,920 --> 00:25:13,920
Which ones can trigger irreversible actions?
543
00:25:13,920 --> 00:25:18,920
If the answer is we're not sure, the organization is already operating a probabilistic security model.
544
00:25:18,920 --> 00:25:21,920
And the worst part is that sprawl makes containment politically impossible.
545
00:25:21,920 --> 00:25:26,920
Security can see an issue and want to disable a connector, restrict a tool, or block an agent.
546
00:25:26,920 --> 00:25:29,920
But they also know that tool might be used by five other teams.
547
00:25:29,920 --> 00:25:32,920
Nobody owns the dependency graph. Nobody can guarantee what will break.
548
00:25:32,920 --> 00:25:35,920
So the safe operational decision becomes the dumb one.
549
00:25:35,920 --> 00:25:38,920
Paws publishing frees the program into a tenant-wide inventory.
550
00:25:38,920 --> 00:25:40,920
sprawl turns incident response into paralysis.
551
00:25:40,920 --> 00:25:42,920
That's why it's unbounded authority.
552
00:25:42,920 --> 00:25:44,920
Not because one tool is powerful.
553
00:25:44,920 --> 00:25:50,920
Because the system has no enforced limit on how many tool pathways can exist, how they compose, or how they drift.
554
00:25:50,920 --> 00:25:55,920
So when people say agents are just co-pilot with plugins, that's the lie they tell themselves to stay comfortable.
555
00:25:55,920 --> 00:26:01,920
Architecturally, they're building a distributed integration platform where every team can mint authority.
556
00:26:01,920 --> 00:26:04,920
And there is no stable equilibrium for that.
557
00:26:04,920 --> 00:26:10,920
Next, the pattern everyone recognizes, the service desk agent that worked and then multiplied until it became operational noise.
558
00:26:10,920 --> 00:26:14,920
Pattern case, the service desk, success that triggered sprawl.
559
00:26:14,920 --> 00:26:19,920
This pattern always starts with a win, because that's how enterprise entropy earns funding.
560
00:26:19,920 --> 00:26:22,920
A service desk team ships a triage agent, nothing fancy.
561
00:26:22,920 --> 00:26:28,920
It reads an incoming request, summarizes it, suggests a category, drafts a response, and, because someone wanted real value,
562
00:26:28,920 --> 00:26:30,920
it can also open a ticket and update the status.
563
00:26:30,920 --> 00:26:34,920
It reduces first response time, it makes the dashboard look better.
564
00:26:34,920 --> 00:26:39,920
Leadership sees a demo where the agent turns a messy paragraph into a clean incident record with one click.
565
00:26:39,920 --> 00:26:41,920
And the organization concludes the wrong thing.
566
00:26:41,920 --> 00:26:42,920
We should scale this.
567
00:26:42,920 --> 00:26:44,920
Not we should standardize it.
568
00:26:44,920 --> 00:26:45,920
Scale comes first.
569
00:26:45,920 --> 00:26:46,920
Discipline comes later.
570
00:26:46,920 --> 00:26:48,920
Discipline never arrives.
571
00:26:48,920 --> 00:26:54,920
Week one, the agent lives in one place with one set of connectors and one informal owner who remembers how it works.
572
00:26:54,920 --> 00:26:57,920
The blast radius is small, everyone feels safe.
573
00:26:57,920 --> 00:27:01,920
Week two, another team asks for the same thing, but for HR tickets.
574
00:27:01,920 --> 00:27:05,920
Someone clones the agent because cloning is easier than negotiating requirements.
575
00:27:05,920 --> 00:27:10,920
They reuse most of the tool chain, but swap one connector and add one approval step.
576
00:27:10,920 --> 00:27:16,920
Now there are two agents that do triage, and they are already different in behavior, permissions and logging.
577
00:27:16,920 --> 00:27:20,920
Week three, the infrastructure team wants it for access requests.
578
00:27:20,920 --> 00:27:23,920
They don't like the approval step because it slows them down.
579
00:27:23,920 --> 00:27:28,920
They remove it, they add graph calls because the connector didn't return the group membership data they wanted.
580
00:27:28,920 --> 00:27:31,920
The agent now has a new toolpath that can touch identity objects.
581
00:27:31,920 --> 00:27:35,920
Nobody calls that a security event because it's just service desk automation.
582
00:27:35,920 --> 00:27:40,920
Week four, original IT team wants the same agent, but their environment has different DLP rules,
583
00:27:40,920 --> 00:27:42,920
so they can't use the same connector.
584
00:27:42,920 --> 00:27:47,920
The workaround flow, it runs as a service account because their makers don't have the right permissions.
585
00:27:47,920 --> 00:27:51,920
Now the same business outcome, create, categorize and update tickets.
586
00:27:51,920 --> 00:27:55,920
Exists through multiple identity and toolpathways across multiple environments.
587
00:27:55,920 --> 00:27:59,920
And then comes the optimization phase, which is the polite word for divergence.
588
00:27:59,920 --> 00:28:03,920
Each team tweaks prompts, they tweak categories, they tweak routing logic.
589
00:28:03,920 --> 00:28:07,920
They add their own small enhancements because they have local knowledge and local pain.
590
00:28:07,920 --> 00:28:11,920
They do not coordinate changes because coordination is slower than building.
591
00:28:11,920 --> 00:28:15,920
Publish changes as versioned contracts because nobody framed tools as contracts.
592
00:28:15,920 --> 00:28:19,920
They're thinking like app makers, not like operators of a distributed decision engine.
593
00:28:19,920 --> 00:28:21,920
Now the collisions start.
594
00:28:21,920 --> 00:28:25,920
Agent A, routes to network incident when it sees VPN keywords.
595
00:28:25,920 --> 00:28:29,920
Agent B, routes to security incident because it learned from a different set of examples.
596
00:28:29,920 --> 00:28:34,920
Agent C creates two tickets because it retreats on time out and nobody made the operation idempotent.
597
00:28:34,920 --> 00:28:39,920
Agent D closes tickets automatically if the user hasn't responded in 24 hours
598
00:28:39,920 --> 00:28:41,920
and someone wanted to reduce backlog metrics.
599
00:28:41,920 --> 00:28:44,920
Those automations now overlap. They touch the same objects.
600
00:28:44,920 --> 00:28:46,920
They produce different outcomes for the same input.
601
00:28:46,920 --> 00:28:48,920
So service desk staff start seeing nonsense.
602
00:28:48,920 --> 00:28:51,920
Tickets bounce between cues because routing logic disagrees.
603
00:28:51,920 --> 00:28:54,920
Approvals arrive for tickets that were already handled by another agent.
604
00:28:54,920 --> 00:28:59,920
Users get two different responses to the same question depending on which teams channel they asked in.
605
00:28:59,920 --> 00:29:04,920
And because agents can trigger actions, not just suggest them, these inconsistencies aren't just confusing.
606
00:29:04,920 --> 00:29:11,920
They pay the operational state, wrong category, wrong assignment group, wrong SLA clock, wrong closure notes, wrong escalation.
607
00:29:11,920 --> 00:29:14,920
Then leadership asks the question that always shows up once the mirage collapses.
608
00:29:14,920 --> 00:29:16,920
Why do we have five different answers?
609
00:29:16,920 --> 00:29:19,920
Nobody has a clean answer because the system doesn't have a control plane.
610
00:29:19,920 --> 00:29:24,920
There is no canonical agent, there is no canonical tool chain, there is no standard contract,
611
00:29:24,920 --> 00:29:27,920
there is no enforced approval boundary for irreversible actions.
612
00:29:27,920 --> 00:29:32,920
There is only a growing set of helpful implementations that share a name, not a behavior.
613
00:29:32,920 --> 00:29:34,920
And here is the hidden cost, credibility loss.
614
00:29:34,920 --> 00:29:39,920
Service desk teams stop trusting the agent because it behaves differently week to week.
615
00:29:39,920 --> 00:29:42,920
Users stop trusting the service desk because outcomes are inconsistent.
616
00:29:42,920 --> 00:29:46,920
The program loses political capital which matters more than the first month's productivity gain.
617
00:29:46,920 --> 00:29:51,920
So now the organization does what organizations always do when automation creates ambiguity.
618
00:29:51,920 --> 00:29:52,920
They add manual steps.
619
00:29:52,920 --> 00:29:55,920
Someone says, "We'll keep the agent but only for drafting."
620
00:29:55,920 --> 00:29:58,920
Someone else says, "We'll keep it but disable auto-rooting."
621
00:29:58,920 --> 00:30:01,920
Someone else says, "We'll keep it but only in one region."
622
00:30:01,920 --> 00:30:04,920
That sounds like risk management, it's actually architectural retreat.
623
00:30:04,920 --> 00:30:09,920
Because the organization didn't reduce risk, it reduced scope after deploying uncontrolled authority.
624
00:30:09,920 --> 00:30:16,920
And the artifacts remain, duplicated tools, often flows, shared accounts, inconsistent DLP exceptions,
625
00:30:16,920 --> 00:30:18,920
and agents nobody remembers to decommission.
626
00:30:18,920 --> 00:30:23,920
This is why toolsprall is not an inconvenience, it's an authority multiplication problem.
627
00:30:23,920 --> 00:30:30,920
The initial win creates demand, demand creates replication, replication creates divergence, divergence creates collisions, collisions create incidents, incidents.
628
00:30:30,920 --> 00:30:35,920
Created governance theatre and governance theatre eventually becomes a freeze.
629
00:30:35,920 --> 00:30:37,920
Next comes the uncomfortable part.
630
00:30:37,920 --> 00:30:41,920
Sprall is inevitable unless tools are treated as contracts, designed once,
631
00:30:41,920 --> 00:30:46,920
reused everywhere and governed like the execution interfaces they actually are.
632
00:30:46,920 --> 00:30:50,920
Safeguard 2, standardised tool contracts, MCP discipline.
633
00:30:50,920 --> 00:30:56,920
Toolsprall only happens because the organization treats tools like accessories, they are not.
634
00:30:56,920 --> 00:31:00,920
A tool is an executable interface into something that matters.
635
00:31:00,920 --> 00:31:06,920
A system of record, a system of action, a mailbox, a permission surface, a ledger, a ticketing queue.
636
00:31:06,920 --> 00:31:13,920
Once an agent can call a tool, the agent stops being AI and becomes automation with a language model as the dispatcher.
637
00:31:13,920 --> 00:31:15,920
So the safeguard isn't approved connectors.
638
00:31:15,920 --> 00:31:17,920
The safeguard is to standardise tool contracts.
639
00:31:17,920 --> 00:31:22,920
A tool contract is the same idea as an API contract, just dragged into the copilot era.
640
00:31:22,920 --> 00:31:29,920
What actions exist, what inputs are allowed, what outputs look like, what identity executes the call, what data gets touched,
641
00:31:29,920 --> 00:31:34,920
what auditing must exist, and what approval gates sit in front of irreversible steps.
642
00:31:34,920 --> 00:31:37,920
And yes, MCP discipline is the right mental model here.
643
00:31:37,920 --> 00:31:41,920
Tools as contracts, not as a "bring your own connector" buffet.
644
00:31:41,920 --> 00:31:44,920
The simple version is this, you want fewer tools, reused everywhere.
645
00:31:44,920 --> 00:31:51,920
Enterprises do the opposite by default, they let every team wire a slightly different create ticket flow because autonomy feels faster.
646
00:31:51,920 --> 00:31:57,920
Then they wake up with five variations, none of which can be changed safely because no one knows who depends on what.
647
00:31:57,920 --> 00:31:58,920
So you invert the model.
648
00:31:58,920 --> 00:32:04,920
You build a small centrally governed catalog of tools that represent common enterprise actions and you force reuse.
649
00:32:04,920 --> 00:32:17,920
You don't have to centralise everything, but you do have to centralise the primitives that create blast radius, ticket creation, identity changes, data rights, approval paths, external messaging, and anything that mutates a system of record.
650
00:32:17,920 --> 00:32:21,920
That distinction matters because governance doesn't care that an agent can read a document.
651
00:32:21,920 --> 00:32:23,920
Governance cares when an agent can change state.
652
00:32:23,920 --> 00:32:26,920
Now a standardized tool contract has three properties.
653
00:32:26,920 --> 00:32:28,920
First, structured outputs.
654
00:32:28,920 --> 00:32:30,920
Chatty blobs are useless for automation.
655
00:32:30,920 --> 00:32:39,920
If a tool returns "Sure, I created your ticket in pros", you've just created a system that can't be reliably orchestrated, tested, or audited.
656
00:32:39,920 --> 00:32:41,920
Tool outputs must be machine readable.
657
00:32:41,920 --> 00:32:46,920
Ticket ID, system action taken, approval state, and an explicit status.
658
00:32:46,920 --> 00:32:54,920
This is how you prevent the agent from hallucinating the existence of an action that never happened and how you prevent downstream agents from misinterpreting vague text.
659
00:32:54,920 --> 00:32:56,920
Second, provenance.
660
00:32:56,920 --> 00:33:01,920
Every tool call needs to produce evidence, not for the humans in the moment, but for incident response later.
661
00:33:01,920 --> 00:33:06,920
What tool was called, what parameters were passed, what identity executed, and what system responded.
662
00:33:06,920 --> 00:33:12,920
If an agent can't cite its tool calls, then you can't prove why a state change occurred.
663
00:33:12,920 --> 00:33:16,920
And if you can't prove that, you don't have governance, you have optimism.
664
00:33:16,920 --> 00:33:19,920
Third, separation of recommend from act.
665
00:33:19,920 --> 00:33:24,920
This is where most organizations accidentally convert assistive AI into agentic AI without meaning to.
666
00:33:24,920 --> 00:33:35,920
A safe tool contract lets an agent propose actions freely, but requires explicit gates for execution when actions are irreversible, closing a ticket, granting access, sending an external email,
667
00:33:35,920 --> 00:33:39,920
updating a financial record, deleting content, changing policy.
668
00:33:39,920 --> 00:33:41,920
These aren't steps, they're commitments.
669
00:33:41,920 --> 00:33:45,920
So the contract must encode approvals, not as an afterthought.
670
00:33:45,920 --> 00:33:49,920
As a required parameter, approval token, approval ID, and a reason code.
671
00:33:49,920 --> 00:33:52,920
If the approval isn't present, the tool must refuse to act.
672
00:33:52,920 --> 00:33:54,920
That is what enforcement looks like.
673
00:33:54,920 --> 00:33:56,920
The tool itself becomes the policy boundary.
674
00:33:56,920 --> 00:34:01,920
Now, versioning enterprises change tools constantly and pretend nothing downstream will break.
675
00:34:01,920 --> 00:34:06,920
In an agentic estate, a tool change is a breaking change unless proven otherwise.
676
00:34:06,920 --> 00:34:08,920
You need contract versioning, deprecation, and change control.
677
00:34:08,920 --> 00:34:13,920
Not because governance loves paperwork, because a tool is a shared dependency across a fleet.
678
00:34:13,920 --> 00:34:18,920
If a tool signature changes, and five agents interpret the output differently, you've created distributed failure.
679
00:34:18,920 --> 00:34:23,920
So treat tool changes like code releases, review, test, staged rollout, rollback plan.
680
00:34:23,920 --> 00:34:26,920
The tool catalog is a product, it has life cycle.
681
00:34:26,920 --> 00:34:28,920
If you don't run it like a product, the estate will run you.
682
00:34:28,920 --> 00:34:31,920
And here's the uncomfortable truth for citizen development narratives.
683
00:34:31,920 --> 00:34:34,920
Local creativity is not a strategy for shared execution surfaces.
684
00:34:34,920 --> 00:34:37,920
Let people build agents. Let them iterate.
685
00:34:37,920 --> 00:34:42,920
But don't let them mint new tool pathways into critical systems without contract review.
686
00:34:42,920 --> 00:34:44,920
That's the minimum line between innovation and entropy.
687
00:34:44,920 --> 00:34:47,920
Everything else is theater, so the safeguard is not no tools.
688
00:34:47,920 --> 00:34:48,920
It's controlled tools.
689
00:34:48,920 --> 00:34:54,920
Fewer, standardized, versioned with structured outputs, provenance, and approval gates for irreversible actions.
690
00:34:54,920 --> 00:34:58,920
Once you do that, sprawl doesn't disappear, but it stops being unbounded.
691
00:34:58,920 --> 00:35:04,920
Toolpaths become known, dependencies become discoverable, change becomes survivable, and containment becomes possible
692
00:35:04,920 --> 00:35:09,920
because you can revoke one tool grant or disable one tool version without guessing what else collapses.
693
00:35:09,920 --> 00:35:11,920
Identity gave you who.
694
00:35:11,920 --> 00:35:14,920
Tool contracts give you what and how.
695
00:35:14,920 --> 00:35:17,920
And now you hit the third accelerant, data.
696
00:35:17,920 --> 00:35:22,920
Because once tools are constrained, the next thing that silently expands in agents blast radius is what it can read,
697
00:35:22,920 --> 00:35:24,920
and what it treats as truths.
698
00:35:24,920 --> 00:35:26,920
Failure mode 3.
699
00:35:26,920 --> 00:35:28,920
Obidient data leakage.
700
00:35:28,920 --> 00:35:29,920
Governance theatre.
701
00:35:29,920 --> 00:35:31,920
Tool contracts constrain what an agent can do.
702
00:35:31,920 --> 00:35:37,920
Data access decides what the agent will do, and this is where most enterprises accidentally build the perfect compliance incident.
703
00:35:37,920 --> 00:35:41,920
An agent that leaks, not because it's malicious, but because it's obedient.
704
00:35:41,920 --> 00:35:45,920
They ground the agent on everything it can read, then act surprised when it reads the wrong thing.
705
00:35:45,920 --> 00:35:48,920
This failure mode doesn't look like a breach at first.
706
00:35:48,920 --> 00:35:49,920
It looks like a helpful answer.
707
00:35:49,920 --> 00:35:55,920
The agent finds a document, it quotes it, it sounds confident, the user takes action, everyone feels productive.
708
00:35:55,920 --> 00:35:59,920
Then compliance shows up weeks later and asks the question nobody designed for.
709
00:35:59,920 --> 00:36:03,920
Was that answer sourced from an authoritative location and can you prove it?
710
00:36:03,920 --> 00:36:08,920
Silence, because the agent didn't leak secrets in the Hollywood sense, it leaked trust.
711
00:36:08,920 --> 00:36:12,920
It gave a correct looking answer sourced from an ungoverned corpus.
712
00:36:12,920 --> 00:36:13,920
Draft policies.
713
00:36:13,920 --> 00:36:15,920
Stale SharePoint copies.
714
00:36:15,920 --> 00:36:16,920
Duplicated PDFs.
715
00:36:16,920 --> 00:36:19,920
Someone's one drive export from two years ago.
716
00:36:19,920 --> 00:36:25,920
And the final V7 really final docs graveyard that every tenant accumulates and the enterprise learns the wrong lesson.
717
00:36:25,920 --> 00:36:31,920
It says the model hallucinated, no, the model didn't hallucinate, the system hallucinated governance.
718
00:36:31,920 --> 00:36:33,920
The foundational mistake is this.
719
00:36:33,920 --> 00:36:36,920
Allowed for humans is treated as allowed for agents.
720
00:36:36,920 --> 00:36:42,920
Humans can have broad read access and still behave safely because humans have judgment, context and fear of consequences.
721
00:36:42,920 --> 00:36:46,920
Humans know when a policy doc looks outdated. Humans can spot that the footer says draft.
722
00:36:46,920 --> 00:36:48,920
Humans can ask is this the latest version?
723
00:36:48,920 --> 00:36:51,920
Agents do none of that unless you forced it into the design.
724
00:36:51,920 --> 00:36:57,920
Agents will happily ground on whatever is reachable and they will do it at machine speed consistently and at scale.
725
00:36:57,920 --> 00:37:05,920
That means every overshared site, every often team, every temporary external share link, every library, with broken inheritance becomes an accelerant.
726
00:37:05,920 --> 00:37:07,920
Not because the agent is clever.
727
00:37:07,920 --> 00:37:10,920
Because it is compliant with your permissions and your permissions are a mess.
728
00:37:10,920 --> 00:37:13,920
Now here is the part that really annoys security teams.
729
00:37:13,920 --> 00:37:17,920
You can have perfect model accuracy and still trigger a compliance incident.
730
00:37:17,920 --> 00:37:23,920
Because compliance doesn't care that the answer was plausible. Compliance cares that the answer was sourced from the wrong place.
731
00:37:23,920 --> 00:37:30,920
So you get situations like this. The agent answers a question about retention, exports, HR procedure, access approvals or financial controls.
732
00:37:30,920 --> 00:37:33,920
It sights something. It might even cite the right thing.
733
00:37:33,920 --> 00:37:39,920
But you can't prove it consistently because the agent's retrieval surface was never constrained to authoritative sources only.
734
00:37:39,920 --> 00:37:45,920
In the moment you can't prove authoritative sourcing, you've converted co-pilot from a productivity feature into governance theatre.
735
00:37:45,920 --> 00:37:50,920
A system that produces outputs that look legitimate without the evidence chain that makes them legitimate.
736
00:37:50,920 --> 00:37:53,920
This is also why we'll just clean up SharePoint is not a strategy.
737
00:37:53,920 --> 00:37:58,920
Content cleanup is infinite. Every day someone creates a new copy. Every project spins up a new team.
738
00:37:58,920 --> 00:38:01,920
Every merger imports a new file share. The backlog never ends.
739
00:38:01,920 --> 00:38:06,920
And as long as agents are allowed to roam the same way humans roam, they will exploit that entropy automatically.
740
00:38:06,920 --> 00:38:12,920
The result is institutional oversharing, not a single catastrophic leak but a thousand small exposures that add up to systemic risk.
741
00:38:12,920 --> 00:38:17,920
The agent answers the wrong user with the right data or the right user with the wrong version.
742
00:38:17,920 --> 00:38:21,920
Or it summarizes something that was never meant to be operational guidance.
743
00:38:21,920 --> 00:38:23,920
And because it's grounded it looks safe. It's not.
744
00:38:23,920 --> 00:38:27,920
Grounding on everything you can read is not safety. It's amplification.
745
00:38:27,920 --> 00:38:31,920
Now add one more twist. Agents don't just read. They can act.
746
00:38:31,920 --> 00:38:37,920
So obedient data leakage doesn't stop at wrong answer. It becomes wrong action based on wrong source.
747
00:38:37,920 --> 00:38:43,920
A stale policy says approvals aren't required. The agent recommends skipping the approval gate.
748
00:38:43,920 --> 00:38:48,920
A draft procedure says a system owner is IT operations but that changed last quarter.
749
00:38:48,920 --> 00:38:53,920
The agent routes access request to the wrong group. A duplicate spreadsheet lists an old vendor bank account.
750
00:38:53,920 --> 00:38:58,920
The agent files the payment update, nothing in that chain required hallucination. Only reach.
751
00:38:58,920 --> 00:39:02,920
And when the incident happens the business will ask for the simplest assurance.
752
00:39:02,920 --> 00:39:04,920
Why was the agent allowed to see that?
753
00:39:04,920 --> 00:39:08,920
If your answer is because the user could you've just admitted you didn't design agent boundaries at all.
754
00:39:08,920 --> 00:39:13,920
This is why obedient leakage is worse than people think. It's not an AI failure. It's a boundary failure.
755
00:39:13,920 --> 00:39:19,920
It exposes that your governance model assumed human judgment then delegated the same access to a non-human actor.
756
00:39:19,920 --> 00:39:22,920
So the core symptom of failure mode number three is this.
757
00:39:22,920 --> 00:39:29,920
The enterprise can't differentiate between data that is merely accessible and data that is operational authoritative for agents.
758
00:39:29,920 --> 00:39:33,920
And without that distinction the program will collapse under its own credibility gap.
759
00:39:33,920 --> 00:39:38,920
User stop trusting answers, leader stop trusting the risk posture, security stops trusting containment.
760
00:39:38,920 --> 00:39:43,920
And everyone returns to the safest system of record in the enterprise meetings.
761
00:39:43,920 --> 00:39:46,920
Next, the pattern case that proves the point.
762
00:39:46,920 --> 00:39:53,920
The policy agent that was right and still failed because right is not the same as governed pattern case.
763
00:39:53,920 --> 00:40:01,920
The policy agent that was right and still failed. This one is the fastest way to lose executive confidence because the agent does everything correctly and you still end up in an incident review.
764
00:40:01,920 --> 00:40:10,920
A team builds a policy agent the pitch is responsible even boring, reduce HR and compliance email load, give employees a single place to ask what's the travel policy.
765
00:40:10,920 --> 00:40:14,920
Can I expense this? What's the retention rule for customer data?
766
00:40:14,920 --> 00:40:20,920
It's framed as assistive, it's just answers, no actions, low risk, everyone relaxes, then they ground it.
767
00:40:20,920 --> 00:40:29,920
And because this is Microsoft 365, grounding usually means some mix of share point sites, teams files, maybe a couple of curated folders if you're lucky.
768
00:40:29,920 --> 00:40:32,920
And a lot of it respects permissions confidence.
769
00:40:32,920 --> 00:40:38,920
The agent can read what the user can read, therefore it's safe, that comforting assumption breaks immediately.
770
00:40:38,920 --> 00:40:44,920
Because in the real tenant, what the user can read includes drafts, duplicates, stale PDFs and migration artifacts.
771
00:40:44,920 --> 00:40:48,920
It includes the policy wiki someone copied into a project team two years ago.
772
00:40:48,920 --> 00:40:52,920
It includes the temporary share point site created during a merger that nobody cleaned up.
773
00:40:52,920 --> 00:40:58,920
It includes the PowerPoint deck, someone used for training that contains policy summaries that were never formally approved.
774
00:40:58,920 --> 00:41:04,920
The agent is asked a simple question, do we need manager approval for international travel over X-days?
775
00:41:04,920 --> 00:41:08,920
Or can we share customer data with vendor Y? Or what's the retention period for these records?
776
00:41:08,920 --> 00:41:11,920
The agent returns an answer, and the answer is plausible.
777
00:41:11,920 --> 00:41:17,920
It's well written, it's consistent with something in the tenant, sometimes it's even technically accurate in the abstract.
778
00:41:17,920 --> 00:41:25,920
But it's sourced from a draft policy copy that was never approved, or an outdated version that was superseded, or a summary deck that omits the exceptions.
779
00:41:25,920 --> 00:41:30,920
The agent did not hallucinate, it retrieved, it grounded, it answered like it was trained to.
780
00:41:30,920 --> 00:41:37,920
The user trusts it because it sounds authoritative, and because it's delivered with the implied legitimacy of, "This is the company's copilot."
781
00:41:37,920 --> 00:41:49,920
So the user acts, maybe they submit travel without approval, maybe they share data under the wrong assumption, maybe they retain or delete records incorrectly, maybe they root a process based on the wrong control, nothing explodes that day. That's important.
782
00:41:49,920 --> 00:41:54,920
This failure mode doesn't give you a dramatic security alert, it gives you delayed consequences.
783
00:41:54,920 --> 00:42:06,920
Two weeks later an audit sample finds a mismatch, or legal reviews an incident and sees the wrong policy cited in an email chain, or a manager asks, "Where did you get that guidance?"
784
00:42:06,920 --> 00:42:16,920
And now you're in the worst kind of incident review, one where the agent didn't do something obviously malicious, but the organization still can't defend the outcome, so someone asked for provenance.
785
00:42:16,920 --> 00:42:26,920
Show me which policy the agent used, and you can show them a link, maybe, if you were lucky enough to log it, but even if you can, you immediately hit the second question, "Is that an authoritative source?"
786
00:42:26,920 --> 00:42:30,920
And that's where the program dies, quietly.
787
00:42:30,920 --> 00:42:34,920
Because the honest answer is, "We don't know, or worse, it's one of the copies."
788
00:42:34,920 --> 00:42:44,920
At that point, the organization realizes it built a system that turns overshared unmanaged content into operational guidance, and it did it at scale, the agent didn't break policy, it weaponized ambiguity.
789
00:42:44,920 --> 00:42:52,920
Then leadership does the predictable thing. They stop trusting the agent, not because the agent is always wrong, but because it can't prove it's right in the way the organization needs.
790
00:42:52,920 --> 00:43:00,920
It can't prove it used the current version, it can't prove the source is the single approved policy object, it can't prove it didn't mix content from two conflicting documents.
791
00:43:00,920 --> 00:43:09,920
So, users stop using it because they don't want to be the person who followed the bot and got flagged later, and leaders stop funding it because it creates reputational risk with no clear containment story.
792
00:43:09,920 --> 00:43:21,920
Now, here's the part that most teams miss. The Fix is not a content cleaner project. You can't fix this by telling people to delete old files. You can't fix it by sending a memo about where policies should live.
793
00:43:21,920 --> 00:43:27,920
That's intent without enforcement again. The Fix is to define authoritative domains and deny everything else by default.
794
00:43:27,920 --> 00:43:30,920
Policy agents can only ground on a curated corpus.
795
00:43:30,920 --> 00:43:41,920
One site, one library, one set of label documents with versioning ownership and review cadence. Everything outside that boundary is treated as untrusted even if it's readable. Humans can still roam. Agents cannot.
796
00:43:41,920 --> 00:43:47,920
And unless you enforce that boundary technically, you will replay this incident forever just with different topics.
797
00:43:47,920 --> 00:43:52,920
That's why this pattern matters. It proves that accurate is not the bar. Govend is the bar.
798
00:43:52,920 --> 00:44:08,920
Next, data boundaries as runtime controls, not a heroic cleanup initiative that never finishes. Safeguard 3, purview DSPM for AI as a runtime data boundary. The Fix for Obedient Data leakage isn't a cleanup initiative and it definitely isn't another policy memo about where content should live.
799
00:44:08,920 --> 00:44:21,920
Enterprises already know where content should live. They just don't enforce it. And without enforcement, the tenant does what tenants do. It accumulates duplicates drafts, abandoned sites, broken inheritance and well meaning oversharing that nobody remembers approving.
800
00:44:21,920 --> 00:44:33,920
So the Safeguard has to operate at runtime against the reality you actually have. This is where purview DSPM for AI matters, not as a compliance dashboard. As a data boundary system that makes agent grounding a controlled surface, not a scavenger hunt.
801
00:44:33,920 --> 00:44:43,920
DSPM is posture management. That means it's designed to answer the only question that matters before you scale. Where is sensitive data exposed in ways agents will exploit automatically?
802
00:44:43,920 --> 00:44:49,920
Humans exploit oversharing occasionally. Agents exploit it deterministically. That distinction matters.
803
00:44:49,920 --> 00:44:58,920
When people hear data boundary, they think classification projects and content labeling campaigns that take a year, produce a scorecard and change nothing operationally.
804
00:44:58,920 --> 00:45:13,920
DSPM is the opposite posture. It gives visibility into risky exposure now tied to AI interactions so you can prioritize containment work where it actually reduces blast radius. And the boundary rule is simple. Agents ground on curated corporate, humans can roam.
805
00:45:13,920 --> 00:45:24,920
That sounds unfair until you remember what agents do. They produce outputs at scale. They don't have judgment. They don't understand this looks like a draft. They don't know which SharePoint library is the real one and which is the shadow one.
806
00:45:24,920 --> 00:45:34,920
They will treat readability as legitimacy and they will do it faster than your governance process can react. So you enforce an authoritative sources model. Allow lists by domain, by label, by purpose.
807
00:45:34,920 --> 00:45:48,920
Not search everything, not respect permissions. Those are not boundaries. Those are retrieval strategies. An authoritative sources model means you decide explicitly which repositories represent truth for a given agent and you deny grounding everywhere else by default.
808
00:45:48,920 --> 00:45:57,920
Policy agents get one library, finance agents get one data set service desk agents get one knowledge base. If it isn't in the allow list, it doesn't exist to the agent.
809
00:45:57,920 --> 00:46:08,920
This is also where the uncomfortable governance gap becomes visible allowed for humans is not allowed for agents. A human being able to read a draft policy might be tolerable because the human also knows it's a draft.
810
00:46:08,920 --> 00:46:16,920
An agent reading it is not tolerable because the agent will confidently operationalize it. So the boundary must be enforced at the agent layer, not at the human permission layer.
811
00:46:16,920 --> 00:46:31,920
Now DSPM earns its keep because it shows you where the boundary will fail before you have an incident. It highlights overshared sharepoint sides, sensitive data types, risky exposure patterns and the places where AI interactions will produce the worst compliance outcomes.
812
00:46:31,920 --> 00:46:38,920
That lets you remediate with intent, not clean everything, but fix the specific exposures that will predictably become agent outputs.
813
00:46:38,920 --> 00:46:48,920
And that's the operational posture shift. Remediation becomes risk driven, not hygiene driven, hygiene driven remediation never finishes, risk driven remediation ships.
814
00:46:48,920 --> 00:46:57,920
So the practical workflow looks like this. First use DSPM posture and observability to see where sensitive interactions are happening or are likely to happen.
815
00:46:57,920 --> 00:47:06,920
Identify the high risk locations, overshared sites, unlabeled repositories with regulated content and the everyone has access libraries that were created for convenience.
816
00:47:06,920 --> 00:47:21,920
Second, define authoritative domains for each agent class. This is not a philosophical exercise. It's a deny by default decision. If the policy agent is allowed to ground on the official policy library, then it is denied access to the rest of sharepoint by design, even if a human user has access.
817
00:47:21,920 --> 00:47:26,920
Third, use labels and purview controls to make those boundaries enforceable and reviewable.
818
00:47:26,920 --> 00:47:35,920
Labels become the policy handle. You can't govern what you can't name. If sensitive content has no label and no ownership, it becomes ambient risk. DSPM helps you find those hotspots.
819
00:47:35,920 --> 00:47:44,920
Fourth, iterate based on actual exposure discovery, not governance backlog fantasies. If DSPM shows you 10 sites that will predictably leak, fix those 10.
820
00:47:44,920 --> 00:47:51,920
Don't create a program to label the entire tenant. That's how you end up with a beautiful road map and the same incidents. The end state is boring, which is the point.
821
00:47:51,920 --> 00:47:59,920
Agents can only ground on what you deliberately curated. Everything else is denied. And when someone asks, why didn't the agent answer from that other sharepoint site?
822
00:47:59,920 --> 00:48:07,920
The answer becomes, because it isn't authoritative and the agent isn't allowed to improvise truth. That's how you prevent the policy agent pattern from repeating forever.
823
00:48:07,920 --> 00:48:20,920
But even with boundaries, behavior still drifts under pressure. Teams will broaden access, temporarily, but makers will request exceptions, business sponsors will demand more coverage, and the system will accept that drift unless you detect it.
824
00:48:20,920 --> 00:48:29,920
That's the next safeguard, runtime detection that treats agent drift as an incident surface, not a training opportunity. Safeguard 4, Defender for AI as drift detection.
825
00:48:29,920 --> 00:48:40,920
At this point, the enterprise usually relaxes. It has identities, tool contracts and data boundaries. It feels like control. It is not. It is an initial condition, because the system will drift, not as a possibility, as physics.
826
00:48:40,920 --> 00:48:55,920
Every agent program lives under pressure. Support tickets piling up. Executives asking why the agent can't just do it. makers trying to remove friction, business sponsors wanting broader coverage, and platform teams trying to keep the lights on.
827
00:48:55,920 --> 00:49:04,920
Under that pressure, people don't break governance maliciously. They eroded incrementally. One exception, one widen scope, one connector added, temporarily.
828
00:49:04,920 --> 00:49:15,920
One approval gate bypassed because the approval was on vacation. The system accepts all of it. That's why governance can't end at design time controls. You need runtime detection that assumes drift and treats it as an operational certainty.
829
00:49:15,920 --> 00:49:25,920
This is where Defender for AI matters, not as a marketing checkbox. As the enterprise's drift detector, the thing that tells you when agents start behaving like a different system than the one you approved.
830
00:49:25,920 --> 00:49:36,920
Most organizations try to build agent governance around intent. They write acceptable use policies. They document the agent will only. They get a sign of. They move on, but intent isn't observable. Behavior is.
831
00:49:36,920 --> 00:49:44,920
Defenders value is that it shifts governance from trust us. We designed it right to prove it continuously based on what the agent is actually doing.
832
00:49:44,920 --> 00:49:56,920
And the moment you make that shift, you stop arguing about whether an agent is safe in theory and you start operating it like any other enterprise workload. Monitor, hunt, alert, contain. That distinction matters.
833
00:49:56,920 --> 00:50:06,920
Because once agents can call tools, agents are no longer a chat feature. They are new endpoints with a language interface. They initiate actions, touch sensitive data, and traverse your authorization graph.
834
00:50:06,920 --> 00:50:16,920
The blast radius looks less like a chatbot and more like automation that can be socially engineered. So the safeguards have to look like endpoint protection, not training. The simple version is detection beats hope.
835
00:50:16,920 --> 00:50:24,920
Defender for AI gives you behavior-based signals that map to the real attack and failure patterns enterprises actually see with agents.
836
00:50:24,920 --> 00:50:35,920
Prompt injection attempts, tool misuse, unexpected access patterns, and abnormal volumes. It catches the uncomfortable cases where the model output looks fine, but the underlying behavior is not.
837
00:50:35,920 --> 00:50:43,920
Because what breaks enterprises isn't usually the one obvious catastrophic prompt. It's the subtle drift into this agent now reads more than it did last week.
838
00:50:43,920 --> 00:50:52,920
Or this agent now writes to a system it didn't write to before. Or this agent now calls tools at a frequency that looks like automation abuse.
839
00:50:52,920 --> 00:50:58,920
And with agents frequency matters. Tools can be invoked thousands of times. A human making a mistake is one event.
840
00:50:58,920 --> 00:51:08,920
An agent following a bad pathway is a flood. So you build on a containment model that aligns to the first safeguard. One agent, one identity, one kill switch. Detection without containment is theater.
841
00:51:08,920 --> 00:51:16,920
If defender flags an agent for suspicious behavior and your only option is disable copilot, you will not act quickly. You will convene, you will hesitate.
842
00:51:16,920 --> 00:51:23,920
And the incident will expand while people debate blast radius. But if the agent has a dedicated, entra identity, containment is mechanical.
843
00:51:23,920 --> 00:51:33,920
Quarantine the agent identity, revoke sessions, disable the tool grounds, freeze publishing for that one agent. That is what a control plane feels like during an incident targeted boring fast.
844
00:51:33,920 --> 00:51:40,920
Now the part enterprises under invest in is response playbooks. They turn on telemetry and call it done. Telemetry isn't response.
845
00:51:40,920 --> 00:51:46,920
Response is a pre-decided set of actions that the on call team can execute without improvising policy during an incident.
846
00:51:46,920 --> 00:51:56,920
Defender for AI matters because it can feed those playbooks with reliable triggers. Tool abuse detected, abnormal access, suspicious prompt patterns, unexpected data interaction.
847
00:51:56,920 --> 00:52:06,920
The labels don't matter as much as the operational behavior, something changed and you need to contain before you analyze. And yes, hunting matters because agents don't fail loudly. They degrade quietly.
848
00:52:06,920 --> 00:52:15,920
Defender becomes the place where security teams can treat agents as a new hunting surface, correlate activity to identities, tool usage and data exposure.
849
00:52:15,920 --> 00:52:24,920
And look for drift patterns across the fleet. One agent doing something strange is an incident. 10 agents doing it means you approved a pattern you didn't understand.
850
00:52:24,920 --> 00:52:33,920
This is also how you avoid the program freeze reflex. Most freezes happen because security can't predict blast radius. They can't isolate, attribute or contain with confidence.
851
00:52:33,920 --> 00:52:41,920
Defender when tied to agent identities and tool contracts gives security something they almost never get with new platforms. The ability to act surgically.
852
00:52:41,920 --> 00:52:52,920
So the governance law is simple. Design time controls constrain what should happen. Run time detection tells you what is happening. And containment lets you survive the gap between the two without shutting down the entire program.
853
00:52:52,920 --> 00:53:01,920
Next, the uncomfortable reason program still frees even when controls exist. Approvals that don't bind to identity tools and containment are just governance theatre.
854
00:53:01,920 --> 00:53:12,920
Pattern case at the approval that nobody owned. This pattern is how we have approvals turns into we have plausible deniability and everyone pretends those are the same thing until audit day.
855
00:53:12,920 --> 00:53:27,920
It starts with a good intention. Don't let agents take irreversible actions without a human in the loop. So a team adds an approval step. Maybe it's a team's adaptive card, maybe it's a power automate approval, maybe it's a message to a channel with a button that says approve or reject. The mechanism doesn't matter.
856
00:53:27,920 --> 00:53:37,920
What matters is what the approval is bound to. In this pattern the approval is bound to a conversation. Not to an identity, not to a tool contract, not to a containment model. So the human in the loop becomes theatre.
857
00:53:37,920 --> 00:53:46,920
A human clicked a button, but nobody can prove what exactly they approved which execution path consumed that approval and which identity performed the action at run time.
858
00:53:46,920 --> 00:53:52,920
Here's how it breaks in the real world. An agent receives a request that crosses the line from assistance into action.
859
00:53:52,920 --> 00:54:04,920
Provision access resets something, create an external share, update a record in a system of action, anything that changes state. The agent does the responsible thing, it asks for approval, it sends an adaptive card to teams that looks clean and reassuring.
860
00:54:04,920 --> 00:54:12,920
Request summary, target, maybe a risk hint and then approve. Someone approves. Everyone feels good. Then the action executes.
861
00:54:12,920 --> 00:54:26,920
But it doesn't execute through the path everyone assumed because the agent's tool surface isn't a single deterministic pipeline. It's an option set connectors, flows, MCP tools, custom APIs, delegated permissions, application permissions.
862
00:54:26,920 --> 00:54:33,920
And under pressure the agent will choose a path that satisfies the goal, not the path you intended unless you force that intention into a contract.
863
00:54:33,920 --> 00:54:47,920
So the approval gets consumed by the wrong toolpath. The card says approve access for user X to resource Y. The action that runs updates a group membership. But it does it through a connector that uses a shared service account instead of the agent identity.
864
00:54:47,920 --> 00:55:00,920
Or it runs a flow that references a different group because someone cloned the tool months ago and changed the parameter mapping. Or it uses graph directly because the connector throttled last week and someone added a fallback path. The action succeeds.
865
00:55:00,920 --> 00:55:10,920
Which is the worst kind of failure because now the organization has an irreversible state change backed by an approval artifact that looks legitimate but cannot be bound to approval execution chain.
866
00:55:10,920 --> 00:55:20,920
Then the incident happens not necessarily because access was wrong. Sometimes it's because access was right and still unauthorized. The approval wasn't the right approver. The approval didn't include the full context.
867
00:55:20,920 --> 00:55:33,920
The approval didn't include the exact identity that would execute it. Or the approval was reused, replayed or interpreted by the wrong agent hop. So security asks the obvious questions who approved it, who executed it. Which tool call consumed the approval.
868
00:55:33,920 --> 00:55:46,920
Was that tool called the one you reviewed? Can you prove the approval content match the executed parameters? If the answers require stitching together chat transcripts, flow run history, and best guesses about which connection reference was active you don't have governance.
869
00:55:46,920 --> 00:56:01,920
You have vibes and logs and the organization discovers a specific kind of accountability vacuum. There is no sponsor who owns the risk decision. The maker built the flow, the platform team approved the environment, the security team approved the concept, the business requested the feature and the approver clicked the button.
870
00:56:01,920 --> 00:56:13,920
But nobody owns the outcome. So when leadership asks who signed off on this, you get a familiar enterprise sentence. It was approved in teams. That sentence is useless because approved in teams isn't a control. It's a screenshot.
871
00:56:13,920 --> 00:56:26,920
In operator terms, the approval is a detached artifact. It's not part of an enforcement chain. It doesn't constrain the tool. It doesn't bind the identity. It doesn't define the blast radius. It doesn't create a kill switch. It just records that someone clicked something at some time.
872
00:56:26,920 --> 00:56:39,920
Which means incident response becomes a negotiation. Security wants to contain by disabling the agent. But the agent doesn't have an isolatable identity or the action didn't run under that identity anyway. They want to disable the tool. But they don't know who else depends on it.
873
00:56:39,920 --> 00:56:46,920
They want to revoke the connector, but that connector also powers other flows. They want to pause publishing, but the business says the agent is critical now.
874
00:56:46,920 --> 00:56:56,920
So security does the only thing that is always safe. They freeze the program. They stop new agents. They stop new tools. They turn off the risky pathways broadly because they can't predict containment boundaries.
875
00:56:56,920 --> 00:57:05,920
And the team that built the approval step is confused because they did governance. No, they built a UI prompt for a human. Governance is an enforcement chain.
876
00:57:05,920 --> 00:57:15,920
So, the entity that can be quarantined, tool contracts that refuse to act without the right approval token and provenance that proves which approval authorized which tool call.
877
00:57:15,920 --> 00:57:22,920
Without that chain, approvals are just ceremony and ceremony doesn't survive contact with audit. This is why the control plane has to come before scale.
878
00:57:22,920 --> 00:57:28,920
Because once approvals float free of identity and tool execution, you don't just get incidents, you get paralysis.
879
00:57:28,920 --> 00:57:36,920
The only sane starting point, minimal viable agent control plane because it's the first point where approvals, identity, tools and containment finally snap into the same system.
880
00:57:36,920 --> 00:57:46,920
Minimal viable agent control plane, MVACP, the only sane starting point, enterprises keep asking for a framework like this is a maturity model problem.
881
00:57:46,920 --> 00:57:53,920
It isn't. This is a control plane problem. And control planes don't start as a catalog of aspirations. They start as containment primitives you can execute under stress.
882
00:57:53,920 --> 00:58:03,920
So, the minimal viable agent control plane is not a power point. It's the smallest set of enforced constraints that makes an agent safe to scale without turning every incident into a tenent wide shutdown.
883
00:58:03,920 --> 00:58:09,920
It has four pillars and they match the failure modes because the platform will drift directly into those failures unless you stop it.
884
00:58:09,920 --> 00:58:18,920
First, one agent, one identity, not one maker, not one service account, not one environment connection, one non-human entity that represents the agent as a first class actor.
885
00:58:18,920 --> 00:58:29,920
That identity is the thing you can quarantine, revoke and decommission without guessing who else you break. If you can't disable one agent without disabling co-pilot broadly, you don't have a control plane. You have a shared fate.
886
00:58:29,920 --> 00:58:41,920
Second, one curated toolpath, this is the opposite of connector freedom. You pick the smallest tool surface that achieves the business outcome, you bind it to a standardized contract and you treat any new tool as a change request, not a creative exercise.
887
00:58:41,920 --> 00:58:49,920
The rule is simple, no new tools without contract review, not because governance wants to slow teams down, but because every tool is a new executable interface into your estate.
888
00:58:49,920 --> 00:58:56,920
Tools are authority, authority is what creates incidents. So you don't let authority proliferate without a registry, versioning and a refusal mode.
889
00:58:56,920 --> 00:59:04,920
And you do one other thing that feels harsh until it saves your program. You separate, recommend, from act. The agent can suggest actions freely.
890
00:59:04,920 --> 00:59:16,920
The tool can execute actions only with an approval token that is bound to the identity, bound to the exact parameters, and logged as part of the tool called Providence. If the approval isn't present, the tool refuses. That is enforcement, not ceremony.
891
00:59:16,920 --> 00:59:28,920
Third, one bounded data domain. This is where most people try to be generous in end up creating obedient leakage. The MVACP rule is that every agent has an explicit authoritative grounding boundary.
892
00:59:28,920 --> 00:59:40,920
Specific set of sources, it is allowed to treat as truth, and a deny by default posture for everything else. The fact that a user can read something does not make it eligible for agent grounding agents are not humans. They do not get human roaming rights.
893
00:59:40,920 --> 00:59:51,920
So you define the domain by label, location and purpose. If the agent is a policy agent, it grounds on the policy library and nowhere else. If the agent is a service desk agent, it grounds on the service desk knowledge base and nowhere else.
894
00:59:51,920 --> 01:00:05,920
If someone wants it to read more, that's a scope change. Scope changes get reviewed because scope is blast radius. Fourth, one containment playbook. Enterprises love talking about detection, then discover they can't act on detection without collateral damage.
895
01:00:05,920 --> 01:00:16,920
So MVACP includes the containment sequence as a first class artifact, not an afterthought. Disable the agent identity, revoke tool permissions, freeze publishing and quarantine the agent's access to the data boundary.
896
01:00:16,920 --> 01:00:39,920
The playbook is not call a meeting. It's a deterministic runbook that a security operator can execute in minutes. And yes, it has to be rehearsed because under real pressure nobody reads the wiki. Now add the piece that makes this enforceable at scale. Providence as a standard. Every agent responds and every agent action must be able to cite what it used. For answers, source links, source labels and a notion of authoritative versus supporting references.
897
01:00:39,920 --> 01:00:56,920
If the agent can't cite sources, the answer is treated as untrusted output, even if it sounds correct. For actions, tool call logs, parameters, identity and result codes. If the agent can't cite its tool calls, you can't prove what happened. If you can't prove what happened, security will eventually shut it down.
898
01:00:56,920 --> 01:01:09,920
So MVACP is one inventory, one identity, one toolpath, one data boundary, one containment playbook, one provenance standard and one intake gate. That's it. It sounds small because it is small, it is also the minimum line between experimentation and scale.
899
01:01:09,920 --> 01:01:18,920
Anything less means you are running agents as a lab project inside a production tenant and you are calling it a program because the word pilot makes executives feel better.
900
01:01:18,920 --> 01:01:27,920
This is the uncomfortable truth. A pilot without a control plane is not a pilot. It's an incident backlog you haven't earned yet. And once MVACP exists, the operating model shifts.
901
01:01:27,920 --> 01:01:39,920
Teams stop asking, can we build another agent and start asking the only question that matters. Can we fit this agent inside the control plane without creating new authority we can't contain? That distinction is where the mirage ends.
902
01:01:39,920 --> 01:01:53,920
Operating model who owns what when agents ship MVACP changes the technical shape of the program. The operating model changes whether it survives. Because the minute agents ship, the organization stops being a tenant with co pilot and becomes a distributed automation shop.
903
01:01:53,920 --> 01:02:04,920
And distributed automation has a predictable failure pattern. Everyone wants the outcome nobody wants the ownership and governance collapses into a weekly meeting where people read screenshots of incidents to each other.
904
01:02:04,920 --> 01:02:18,920
So ownership has to be explicit, not collaborative, not shared responsibility explicit. Start with the platform team. The platform team owns environments, publishing gates and the scaffolding that prevents sprawl from becoming default.
905
01:02:18,920 --> 01:02:26,920
They control where agents can be built, where they can be promoted and what the default constraints are. If every environment is a playground, every agent becomes a snowflake.
906
01:02:26,920 --> 01:02:40,920
Every publishing path is open, every team creates its own tool chain. So the platform team owns the boring enforcement surfaces, environment strategy, DLP enforcement scaffolding, solution boundaries, ALM pathways and the catalog mechanics for tools.
907
01:02:40,920 --> 01:02:49,920
They also own the default friction, friction is not a failure. Friction is entropy management. If creating a new tool path is easier than reusing an existing one, your catalog becomes decoration.
908
01:02:49,920 --> 01:02:57,920
The platform team makes reuse the path of least resistance, templates, standardized tool wrappers and opinionated golden paths that teams can fork only with review.
909
01:02:57,920 --> 01:03:06,920
Next is security. Security owns runtime detection, conditional access constraints and incident response for agent behavior, not the agent's business logic, not the prompt tuning.
910
01:03:06,920 --> 01:03:15,920
The control surfaces, policies that bind identities to conditions, signals that detect drift and playbooks that contain it. Security also owns the kill decision.
911
01:03:15,920 --> 01:03:22,920
When an agent misbehaves, someone has to be able to quarantine it without asking permission from the product owner who built it. That's the whole point of an enforcement chain.
912
01:03:22,920 --> 01:03:30,920
So security owns the containment lever, disable the agent identity, revoke tool grants and freeze publishing for that one actor.
913
01:03:30,920 --> 01:03:35,920
If security can't act surgically, security will act broadly. That's how programs die. Then comes data and compliance.
914
01:03:35,920 --> 01:03:41,920
This group defines authoritative sources and the policy boundaries for what agents are allowed to treat as truth.
915
01:03:41,920 --> 01:03:50,920
They own labels, retention semantics and the DSPM posture that reveals where sensitive exposure lives. The key ownership here isn't classification as a project.
916
01:03:50,920 --> 01:03:58,920
It's authoritative domain definition as an operational contract. If the policy agent's domain isn't defined and enforced, it will ground on the tenant's mess and the mess will win.
917
01:03:58,920 --> 01:04:06,920
So compliance owns the decision of what counts as authoritative and they own the remediation priorities that follow from DSPM findings.
918
01:04:06,920 --> 01:04:13,920
Fix the overshared sites that agents will exploit, not the ones that look bad on a hygiene report. Now the business sponsor.
919
01:04:13,920 --> 01:04:20,920
This is the role enterprises keep trying to delete because it forces uncomfortable accountability. The sponsor owns outcomes and risk acceptance.
920
01:04:20,920 --> 01:04:29,920
They decide what the agent is for, what it is not for, what actions are allowed and what the failure tolerance is. They also decide whether the organization is willing to accept the trade.
921
01:04:29,920 --> 01:04:32,920
Productivity in exchange for a new kind of operational risk surface.
922
01:04:32,920 --> 01:04:38,920
Without a sponsor, every incident becomes a debate about whether the agent should have been allowed to do the thing it did.
923
01:04:38,920 --> 01:04:47,920
That debate is always too late. The sponsor makes that call before shipping and signs their name to it in the directory metadata where the control plane can actually attach.
924
01:04:47,920 --> 01:04:55,920
Then the technical owner. They own build quality, tool wiring, permission scoping, structured outputs, provenance, test coverage and release discipline.
925
01:04:55,920 --> 01:05:03,920
They are the person who gets paged when the agent's tool contract breaks, not because they are morally responsible but because the system needs a human with hands on the controls.
926
01:05:03,920 --> 01:05:08,920
And here's the part that stops the fantasy. One admin cannot hold this control plane alone.
927
01:05:08,920 --> 01:05:15,920
If your organization's model is the power platform admin will govern agents. You are building a bottleneck and calling it a strategy.
928
01:05:15,920 --> 01:05:20,920
That person will either rubber stamp everything to avoid being hated or block everything to avoid being blamed.
929
01:05:20,920 --> 01:05:26,920
Both outcomes produce the same result architectural erosion. So the operating model rule is separate powers.
930
01:05:26,920 --> 01:05:32,920
Platform sets defaults and gates, security detects and contains. Data compliance defines authoritative boundaries.
931
01:05:32,920 --> 01:05:37,920
Business sponsors accept risk, owners implement and maintain.
932
01:05:37,920 --> 01:05:46,920
And those roles must have a shared artifact, an agent registry that isn't a list but a record of identity, tool contracts, data domains and containment playbooks.
933
01:05:46,920 --> 01:05:52,920
That registry becomes the only place an agent is allowed to be real. Everything else is just code someone wrote.
934
01:05:52,920 --> 01:06:00,920
This is where the program becomes scalable, not because there are more agents but because responsibility doesn't drift the way identity and tools drift.
935
01:06:00,920 --> 01:06:09,920
Next comes the scaling path, how to go from one agent to a fleet without recreating the same collapse at higher speed, scaling path from single agent to agent fleet without collapse.
936
01:06:09,920 --> 01:06:18,920
Scaling doesn't mean more agents, it means more change, more builders, more dependencies, more exception pressure, more version drift, more blame shifting when something breaks at 2 a.m.
937
01:06:18,920 --> 01:06:25,920
The fleet doesn't collapse because the model is weak. It collapses because the organization tries to scale outcomes without scaling the control plane.
938
01:06:25,920 --> 01:06:30,920
So the scaling path has one rule, prove containment and attribution at each step then expand.
939
01:06:30,920 --> 01:06:37,920
Anything else is just multiplying uncertainty. Start with a single agent that fits inside MVICP, not a showcase agent, a real one.
940
01:06:37,920 --> 01:06:42,920
Something that touches a system of action uses a tool contract and grounds on an authoritative domain.
941
01:06:42,920 --> 01:06:54,920
Then you run it long enough to learn the uncomfortable behaviors, how people actually prompt it, what edge cases hit the tool contract, where it tries to widen scope, and what telemetry you wish you had when the first weird thing happens.
942
01:06:54,920 --> 01:07:00,920
Remember this detail because it's going to matter later. Fleet governance is not a policy document, it is defaults.
943
01:07:00,920 --> 01:07:14,920
So once that first agent is stable, you don't clone it, you template it, cloning copies behavior, without copying accountability. Templates copy the control plane primitives, identity pattern, tool contracts, data boundaries, provenance standard, and containment playbook.
944
01:07:14,920 --> 01:07:25,920
Templates are control distribution, cloning is chaos replication. This is where most enterprises do the opposite. They celebrate a win, then encourage innovation by letting five teams fork the implementation.
945
01:07:25,920 --> 01:07:35,920
Forking is an entropy generator. The divergence becomes permanent the second the team tweaks a prompt, a connector, or an approval gate to satisfy local speed. So you enforce reuse over replication.
946
01:07:35,920 --> 01:07:45,920
If a second team wants an agent, they pick a template, they register a new agent identity, and they bind to existing tool contracts. If they need a new action, they request a new tool contract entry.
947
01:07:45,920 --> 01:07:51,920
That request becomes the intake gate you defined earlier. New authority requires review. Now multi agent orchestration.
948
01:07:51,920 --> 01:08:03,920
This is the part nobody models honestly. A fleet is not a set of independent bots. It's a distributed system where agents call tools, trigger flows, and sometimes call other agents. That is distributed transaction behavior, whether you admit it or not.
949
01:08:03,920 --> 01:08:15,920
And distributed transactions have failure domains. So you treat orchestration like you would treat any distributed integration explicit boundaries, explicit retries, and explicit failure handling. You don't let an agent keep trying indefinitely.
950
01:08:15,920 --> 01:08:28,920
Retries must be idempotent. If create ticket is called twice, the contract must not create two tickets. It must return the same result for the same request or refuse. This is not theoretical. This is how you prevent sprawl collisions from turning into operational noise.
951
01:08:28,920 --> 01:08:36,920
You also define failure domains. Which actions can fail without cascading into other systems? And which actions must stop the chain immediately?
952
01:08:36,920 --> 01:08:47,920
If an approval token is missing, the chain stops. If the authoritative data source can't be reached, the agent responds with unavailable and does not improvise truth from other sources. That distinction matters.
953
01:08:47,920 --> 01:08:58,920
Change management is the other scaling trap. Agents don't just run. They evolve. Tools get updated. Apis change. Permissions drift. Data domains expand.
954
01:08:58,920 --> 01:09:20,920
If you ship changes like it's just a prompt tweak, you're building invisible breaking changes. So you enforce tool versioning and rollback as the default posture. A tool contract gets a version. Agents bind to a version. Updates deploy in stages. If something breaks, you rollback the tool version, not the entire agent estate. That's how you avoid the program wide freeze. You contain change the same way you contain incidents.
955
01:09:20,920 --> 01:09:30,920
And you keep irreversible actions behind explicit gates. Always irreversible actions don't scale with trust. They scale with proof. Now expand the fleet only when two things are true.
956
01:09:30,920 --> 01:09:38,920
One, you can isolate and disable a single agent identity without collateral damage. Not in theory, in practice during a test incident.
957
01:09:38,920 --> 01:09:51,920
Two, you can prove the provenance chain for both answers and actions. If an executive asks why did it do that? You can show the tool call, the parameters, the identity, the approval token and the authoritative source. If you can't, the fleet is not ready to grow.
958
01:09:51,920 --> 01:10:01,920
So the scaling path is boring by design. Registry identity contracts boundaries detection, defaults applied automatically and expansion gated on operational evidence.
959
01:10:01,920 --> 01:10:10,920
That's what safe to scale actually means. Not that the agent feels smart, that you can survive it being wrong in mapping the safeguards to Microsoft's control surfaces.
960
01:10:10,920 --> 01:10:21,920
Now the part that derails most programs, people confuse. We bought the Microsoft features with, we built a control plane. Those are not the same thing. Microsoft gives you control surfaces. You still have to assemble an enforcement chain.
961
01:10:21,920 --> 01:10:33,920
If you don't, you end up with a comforting dashboard and the same three failure modes, identity drift tools, brawl, obedient leakage. Start with the obvious surface everyone latches on to, the agent registry.
962
01:10:33,920 --> 01:10:51,920
Agent 365 and the M365 admin center view of agents is useful because it answers the first operational question, what exists? Inventory matters. It's the prerequisite for containment, review and decommissioning. But inventory is not governance. A list of agents doesn't prevent one of them from running under the wrong identity calling the wrong tool or grounding on the wrong data.
963
01:10:51,920 --> 01:11:02,920
So treat the registry as an index, not a control. The control begins in enter, enter agent IDs where you make agents first class non-human identities with sponsors, owners, life cycle and most importantly, an isolatable kill switch.
964
01:11:02,920 --> 01:11:10,920
If you can't quarantine one agent identity during an incident, your response option becomes pause the whole program because that's the only action that's always safe.
965
01:11:10,920 --> 01:11:26,920
This is also where conditional access stops being a user story and becomes an agent boundary. Agents need constraints that don't depend on a maker's workstation or user's context. They need deterministic access envelopes, what tenant resources they can reach, under what conditions and with what authentication posture.
966
01:11:26,920 --> 01:11:34,920
If the agent is a shadow of the user, conditional access just becomes conditional chaos. Enter is how you turn who did this back into a provable answer.
967
01:11:34,920 --> 01:11:43,920
Next, the Power Platform control plane. If your agents live in co-pilot studio, the Power Platform admin center is the enforcement scaffolding most organizations pretend they already have.
968
01:11:43,920 --> 01:11:50,920
Environments, DLP, solution boundaries, connection references and publishing controls are the only way to stop dev shortcuts from becoming production habits.
969
01:11:50,920 --> 01:12:00,920
This is where you decide whether makers can freely share agents, whether tools can be added without review and whether connector use is constrained by environment tier. It is not glamorous, it is entropy management.
970
01:12:00,920 --> 01:12:08,920
Power Platform governance does not solve identity drift by itself, but it does help you prevent tools from becoming the default behavior of your estate.
971
01:12:08,920 --> 01:12:17,920
Then comes the data boundary surface. Per view, Per view DSPM for AI is how you stop it respects permissions from becoming your entire data governance story.
972
01:12:17,920 --> 01:12:30,920
Because permissions are not authority and readable is not authoritative. DSPM gives you two things you actually need to operate agents, visibility into sensitive interactions and a way to prioritize remediation based on exposure that agents will exploit.
973
01:12:30,920 --> 01:12:38,920
This is also where you enforce the authoritative sources model, not by cleaning up everything, by constraining what agents can ground on, by label, location and purpose.
974
01:12:38,920 --> 01:12:46,920
Humans can roam because humans can judge. Agents can't, so the boundary must be stricter for agents than for people and Per view is the surface that makes that boundary defensible.
975
01:12:46,920 --> 01:12:52,920
Now runtime drift defender for AI is your detection and hunting surface. The point isn't to prove the agent is secure.
976
01:12:52,920 --> 01:13:05,920
The point is to catch behavior changes before they become incidents. Prompt injection attempts, abnormal tool use, unexpected access patterns and the slow creep of scope expansion that happens when business pressure meets a flexible platform.
977
01:13:05,920 --> 01:13:11,920
Detection only matters if containment is real. That means defender alerts must map to action security can take.
978
01:13:11,920 --> 01:13:17,920
Quarantine the agent identity, revoke tool permissions, freeze publishing and block data domain access.
979
01:13:17,920 --> 01:13:24,920
If the alert can't trigger a surgical response, you'll get the predictable outcome. A meeting, a delay and then a broad shutdown.
980
01:13:24,920 --> 01:13:30,920
Now the awkward one, power platform DLP will save us. It won't. DLP is necessary, but it's not a tool contract.
981
01:13:30,920 --> 01:13:42,920
DLP can restrict connectors. It can't guarantee structured outputs. It can't enforce approval tokens at the tool boundary. It can't version a create ticket action as a shared enterprise primitive. It's a guardrail, not a contract compiler.
982
01:13:42,920 --> 01:13:50,920
So tool contracts live above connectors. Whether you implement them through MCP style tools, custom connectors, API management or standardized flows doesn't matter.
983
01:13:50,920 --> 01:13:59,920
What matters is that they behave like contracts. Version, reused, refusal modes baked in, provenance emitted every time and approvals required for irreversible actions.
984
01:13:59,920 --> 01:14:06,920
So when people ask, which Microsoft feature do we turn on to be safe? The answer is none of them. There is no feature that prevents entropy.
985
01:14:06,920 --> 01:14:15,920
What prevents entropy is defaults. One agent identity, curated tool paths, bounded data domains, runtime detection and containment that can execute in minutes.
986
01:14:15,920 --> 01:14:27,920
Microsoft gives you the surfaces. You provide the discipline. And if you don't, the platform behaves exactly as designed. It democratizes capability until authority becomes unbounded and then your architecture collapses under the weight of its own exceptions.
987
01:14:27,920 --> 01:14:38,920
The executive reality check, questions that expose readiness. Executives don't need a diagram of agent orchestration. They need a way to detect whether the program is real or whether it's a productivity story that will die in audit.
988
01:14:38,920 --> 01:14:46,920
So the reality check is a small set of questions that force the organization to reveal what it actually built. A control plane or a collection of experiments.
989
01:14:46,920 --> 01:14:52,920
And the trick is this, the questions must be binary. They must produce an answer that is either provable or it isn't.
990
01:14:52,920 --> 01:14:59,920
If the response is a narrative, you already failed. Start with identity because identities where accountability either exists or dissolves.
991
01:14:59,920 --> 01:15:06,920
Do our agents have non-human identities with named owners and business sponsors? Not someone in IT built it. Not the power platform team manages it.
992
01:15:06,920 --> 01:15:12,920
A named sponsor who accepts the risk of the outcome and a named technical owner who maintains the implementation.
993
01:15:12,920 --> 01:15:18,920
If the sponsor role doesn't exist, the agent is a shadow project and shadow projects don't survive the first incident review.
994
01:15:18,920 --> 01:15:30,920
Second, can we disable one agent without disabling co-pilot? This is the kill switch question. If the answer is we can turn off the environment or we can block the connector or we can disable the maker, then you don't have containment. You have collateral damage.
995
01:15:30,920 --> 01:15:37,920
And when collateral damage is the only containment option, the organization will choose the safest move every time. Freeze the program.
996
01:15:37,920 --> 01:15:45,920
Third, can we prove where an answer came from and why it acted? Not its cited share point. Not it respects permissions. Can you show?
997
01:15:45,920 --> 01:15:52,920
These were the sources, these were the labels, this was the authoritative domain and this was the tool called chain for actions.
998
01:15:52,920 --> 01:15:57,920
Which tool was called with what parameters under which identity and with which approval token.
999
01:15:57,920 --> 01:16:04,920
If you can't produce that evidence chain inside the time window of an incident call, then your system is not governable. It is merely observable in hindsight.
1000
01:16:04,920 --> 01:16:09,920
Now shift to the sprawl questions because sprawl is what turns small success into systemic ambiguity.
1001
01:16:09,920 --> 01:16:21,920
How many tools exist and how many are duplicates? Most organizations don't know, they can't even define what duplicate means because the same business action has been implemented five different ways across flows, connectors, MCP tools and custom APIs.
1002
01:16:21,920 --> 01:16:29,920
If you can't count tools and identify overlaps, you can't reason about blast radius. You also can't do change control because you don't know what depends on what.
1003
01:16:29,920 --> 01:16:33,920
Next, do we have standardized tool contracts for irreversible actions?
1004
01:16:33,920 --> 01:16:44,920
This is where executives tend to not and say we require approvals. That isn't the question. The question is does the tool refuse to act without the approval token and does it emit provenance every time it executes?
1005
01:16:44,920 --> 01:16:54,920
If approval is a team's message and execution is a different pathway, you are operating governance theater. It will fail and it will fail in a way that makes everyone look irresponsible even when they were trying.
1006
01:16:54,920 --> 01:17:04,920
Now the data boundary question because this is where people mistake accessibility for legitimacy. What data sources are considered authoritative for each agent and what is explicitly denied?
1007
01:17:04,920 --> 01:17:15,920
If the answer is whatever the user can access, then the agent's truth model is the tenant's mess. That means you are one stale policy copy away from a credibility collapse and you will not discover it until after someone acted on it.
1008
01:17:15,920 --> 01:17:25,920
Executives should also ask a harder version of that question. How do we know an agent didn't ground on a draft, a duplicate or a stale version if you can't answer that, you can't defend the program?
1009
01:17:25,920 --> 01:17:37,920
Because the output might be accurate but you can't prove it was governed and governed is the bar. Now the drift question because drift is what turns good controls into outdated assumptions. What's our containment playbook when an agent misbehaves at scale?
1010
01:17:37,920 --> 01:17:53,920
Not we'll investigate, not we'll talk to the team, a playbook, quarantine identity, revoke tool permissions, freeze publishing and lock the data boundary. And it needs an owner because if an incident happens at 2 a.m, the system will behave according to the playbook you wrote, not the policy you hoped for.
1011
01:17:53,920 --> 01:18:02,920
And finally the question that exposes whether you're scaling responsibly or just shipping faster. What is our not ready to scale yet criteria?
1012
01:18:02,920 --> 01:18:10,920
Executives hate this question because it forces discipline but it's the only thing that prevents a pilot from turning into a fleet of uncontainable actors.
1013
01:18:10,920 --> 01:18:23,920
If you can't isolate one agent, can't prove provenance, can't bound data domains and can't count tools, you are not ready to scale. That doesn't mean don't build agents, it means you are still experimenting and you need to stop pretending experimentation is governance.
1014
01:18:23,920 --> 01:18:30,920
Answer these questions honestly and you'll know whether you're operating a control plane or just watching entropy accumulate with better marketing.
1015
01:18:30,920 --> 01:18:42,920
Executive ready action list, the four non-negotiables. Executives don't need a reference architecture to start doing the right thing, they need four decisions they can enforce across teams without waiting for maturity journey.
1016
01:18:42,920 --> 01:18:46,920
Here they are, non-negotiable number one, identity per agent, no exceptions.
1017
01:18:46,920 --> 01:18:54,920
Every agent that can take action, call tools or ground on enterprise data gets a non-human identity with an explicit owner and a business sponsor.
1018
01:18:54,920 --> 01:19:03,920
The sponsor owns outcomes and risk acceptance, the owner owns maintenance and operational integrity. If a team can't name both, the agent stays in development, period.
1019
01:19:03,920 --> 01:19:09,920
And the identity must be containable, that means a kill switch you can pull without disabling, copilot for everyone.
1020
01:19:09,920 --> 01:19:17,920
If disabling one agent requires disabling a shared service account and maker or an entire environment, you've built shared fate, not governance, non-negotiable number two.
1021
01:19:17,920 --> 01:19:23,920
Standardized tool contracts, reused everywhere. You stop treating tools as whatever connector someone found.
1022
01:19:23,920 --> 01:19:36,920
You treat tools as version contracts with refusal modes. If the agent can trigger a workflow, update a record, grant access, create a ticket or send data externally, that action must be implemented as a shared, reviewed versioned tool.
1023
01:19:36,920 --> 01:19:46,920
Not five different flows that do basically the same thing. The contract must emit provenance, what tool ran, under what identity with what parameters and what it changed. It must also separate recommend from act.
1024
01:19:46,920 --> 01:19:55,920
The agent can suggest, the tool executes only when an approval token exists and matches the exact parameters, that is how you stop approvals from becoming screenshots.
1025
01:19:55,920 --> 01:20:03,920
Non-negotiable number three, enforced data boundaries with an authoritative sources model. This is where most programs pretend permissions equal governance.
1026
01:20:03,920 --> 01:20:11,920
They don't, you define what is authoritative for each agent class and you deny everything else by default. Policy agents ground on the official policy library.
1027
01:20:11,920 --> 01:20:23,920
Service desk agents ground on the official knowledge base. Finance agents ground on specific labeled data sets. Humans can still roam because humans can judge. Agents can't.
1028
01:20:23,920 --> 01:20:29,920
Per view, DSPM for AI becomes the posture lens that tells you where the boundary will fail in real life.
1029
01:20:29,920 --> 01:20:47,920
Unlabeled sensitive data, often libraries and the drift zones where temporary access becomes permanent. And you use DSPM findings to drive remediation priorities like an operator, not like a committee. Fix the exposures that will become agent outputs first and stop pretending a tenant-wide content cleanup is ever going to finish.
1030
01:20:47,920 --> 01:20:55,920
Non-negotiable number four, turn on drift detection and build response playbooks. If your governance stops that we approved it, you are operating on faith.
1031
01:20:55,920 --> 01:21:08,920
For AI exists because drift is inevitable, tool surfaces expand. Permissions widen, exception pressure accumulates, prompt injection attempts show up, abnormal access patterns emerge, you don't prevent all of that with design, you detect it then you contain it.
1032
01:21:08,920 --> 01:21:19,920
So you build runbooks that security can execute without negotiating with the business during an incident. Quarantine, the agent identity, revoke tool permissions, freeze publishing and lock the data boundary.
1033
01:21:19,920 --> 01:21:27,920
You can't do those steps quickly and surgically, the only safe response will be a program-wide pause. Now the final piece executives need is the stop condition.
1034
01:21:27,920 --> 01:21:40,920
Define not ready to scale yet, criteria and enforce it like a release gate, not a warning label. If an agent doesn't have a unique identity, a sponsor, a curated toolpath, an authoritative data boundary and a containment playbook, it does not ship.
1035
01:21:40,920 --> 01:21:52,920
It can exist as an experiment, but you don't pretend experiments are enterprise automation, that's how you keep credibility and this is where the opening loop closes. Identity drift ends programs first because audit doesn't negotiate.
1036
01:21:52,920 --> 01:22:02,920
Hallucinations are embarrassing. Identity ambiguity is an operational control failure. Once you can't answer who did this with proof, the organization loses the right to scale, security pauses you.
1037
01:22:02,920 --> 01:22:13,920
Because they hate innovation, but because the system is no longer governable. That's the adult posture, build the control plane, then scale the agents. Anything else is just distributing authority faster than you can explain it.
1038
01:22:13,920 --> 01:22:25,920
Conclusion. Control plane or collapse. Agents turn your Microsoft estate into a distributed decision engine and entropy wins unless you enforce identity, tool contracts, data boundaries and drift detection by design.
1039
01:22:25,920 --> 01:22:34,920
If you want the practical next step, watch the next episode on building a minimal viable agent control plane for Copilot Studio Systems of Action. Subscribe!
















