Most enterprises roll out co-pilot like it's a nicer search box and a faster PowerPoint
in turn.
They are wrong.
The moment co-pilot becomes agentic, it stops answering questions and starts taking
actions and that multiplies authority across your tenant without anyone admitting they
approved it.
In this episode, three failure modes that shut programs down, four safeguards that actually
scale, and one minimal viable control plane you can build without pretending policy decks
are enforcement.
And yes, identity drift will halt your program faster than hallucinations.
That detail matters.
Hold it.
The core misconception.
Assistance don't erode architecture actors do.
The foundational misunderstanding is that co-pilot is a feature.
Something you toggle on, then users get faster at email and meetings and everyone claps.
In architectural terms, co-pilot is not a feature.
It is a distributed decision engine sitting on top of your permission graph, your connectors,
your data sprawl, and your unfinished governance.
It behaves exactly like every other distributed system.
It amplifies whatever is already true, including the parts you hoped nobody would notice.
So the first simplification is this.
Assistive AI and agentic AI are not the same category.
Assistive AI drafts, summarizes, searches and proposes.
It produces text even when it's wrong, it's usually reversible, a human can ignore it.
The blast radius is social and local.
One person makes one bad decision, then you clean it up with training, disclaimers and
the usual corporate therapy.
Agentic AI does something else.
It decides to call tools, trigger workflows, create records, change permissions, send messages,
file tickets, update systems of record, it produces actions.
And actions aren't mostly correct.
Er, they are either authorized or unauthorized, contained or uncontained, attributable or
unprovable.
That distinction matters because enterprises love probabilistic outcomes when the output
is a paragraph, but they demand deterministic outcomes when the output is a state change.
And an agent's output is always a state change somewhere.
In a place your team won't notice for weeks, this is where the mirage begins.
In the assistive world, the core question is, did it hallucinate?
In the agentic world, the core questions are, who executed this?
By what authority?
Through which tool path?
Against which data boundary?
Can we stop just this one thing without shutting down the entire program?
Most organizations don't ask those questions upfront because they misclassify agents as
UI extensions.
They treat them like a chat surface glued onto Microsoft 365, something cute inside
teams.
Antic systems don't live in the UI.
They live in the graph.
Every permission, every connector, every delegated grant, every environment, every DLP
exception, every temporary service account becomes part of the agent's reachable universe.
Not because the model is evil, because the estate is permissive.
And then the inevitable happens, helpful becomes authorized.
It doesn't happen with a big approval meeting.
It happens with the quiet accumulation of capability.
Someone adds a connector to just read tickets, then it needs to update status, then it needs
to create a record.
And it needs a delegated permission because the maker didn't want to do app registration
work.
Then a service account appears because it's easier than designing non-human identity properly.
Then the agent is shared because it worked for one team, then cloned because another team
wants a version optimized locally.
None of those steps feels like a security event in the moment.
Collectively, they are architectural erosion.
Here's the counter-intuitive part.
The more productive the agent feels, the more dangerous the governance drift becomes.
Because success creates demand, demand creates replication and replication creates sprawl.
And sprawl is where architecture dies.
Because in a sprawl scenario, the enterprise stops operating a designed automation pathway
and starts operating a folklore network.
Dozens of agents, dozens of tools, overlapping scopes and inconsistent enforcement.
You can't reason about it as a system anymore.
You can only react to incidents.
Now layer in probabilistic behavior.
The human operator understands context.
They can pause.
They can say this looks wrong.
An agent doesn't pause unless you engineered it to pause.
It will take the action it believes matches the intent.
With whatever authority it can reach, using the toolpath you accidentally made available.
So when leaders say we can tolerate some inaccuracy, they are importing an assistive mindset
into an agentic environment.
That is not a small error.
That is the error.
In an agentic system, good enough answers become irreversible outcomes.
A wrong answer can be embarrassing.
A wrong action can be a breach of financial posting, a permissions change, a contract email,
or an audit finding.
And when an audit asks, who did this?
You don't get to respond with vibes.
You need provable attribution, which brings the conversation back to what this episode is
actually about.
Not models, not prompts, not the weekly feature drop.
Control.
If agents are actors, governance has to govern actor primitives, identity, tool contracts,
data boundaries, and runtime detection.
Not after the fact, not in a policy PDF, enforced by design continuously at scale.
Otherwise, you are not rolling out co-pilot.
You are distributing authority.
When you will act surprised when the system behaves like it always does.
It takes the easiest path.
It accretes exceptions and it converts your clean intent into conditional chaos.
Next, what governance actually is when it's real, an enforcement chain, not a meeting.
Governance isn't policy.
It's an enforcement chai.
Most enterprises confuse governance with documentation.
They produce a policy deck, schedule a monthly AI steering committee, and declare the situation
handled.
It's not a ship agent anyway because the business wants momentum and the controls aren't
real enough to slow anything down.
That distinction matters.
Policy is intent.
Governance is enforced constraint.
Intent without constraint is entropy with a nice font.
An agent doesn't read your SharePoint policy side.
It reads whatever it's allowed to read, calls whatever it's allowed to call, and acts as
whatever identity you gave it.
The system doesn't care what you meant.
It only cares what you configured.
So the right question isn't, do we have policies?
The right question is, do we have an enforcement chain?
An enforcement chain is the sequence of technical and operational gates that turn, we don't want
that into, that cannot happen.
And when it still happens, because it will, turns it into, we can prove it, contain it,
and learn from it without freezing the program.
In practice, an agent governance enforcement chain has four links.
First, identity, not branding, not naming conventions.
Actual identities that can be isolated, scoped, rotated, disabled, reviewed, and audited.
If an agent runs as a maker, you don't have an agent.
You have a shadow user with automation privileges.
Second, tool contracts.
Tools are not connectors.
In architectural terms, they are executable interfaces into systems of record.
A tool defines what actions exist, what parameters are allowed, what outputs look like, and
what approvals gate irreversible steps.
If you let every team wire up its own toolpath, you aren't building agents.
You are building a distributed inconsistent integration layer with zero change control.
Third, data boundaries.
That will clean up SharePoint later.
That's not a boundary.
That's a backlog.
A boundary is a deny by default decision that defines what an agent may ground on by domain,
label, and purpose.
Humans can roam because they have judgment.
Agents can't, so they don't get to roam.
Fourth, runtime detection and response, because drift is inevitable.
People will pressure the system.
They will add exceptions.
They will broaden scopes.
They will temporarily bypass approvals.
They will do it with good intentions, and the system will accept it.
So detection becomes part of governance, not an afterthought.
Now, enterprises love to say, we do security reviews.
A security review is a meeting.
A meeting is not a control plane.
A control plane is the set of mechanisms that enforces your assumptions at scale.
The identities that represent actors, the contracts that constrain action, the boundaries
that constrain data, and the telemetry that tells you when reality diverges from intent.
In other words, the control plane is the thing that makes safe to scale a measurable property,
and safe to scale has three non-negotiable attributes.
Icelate, you must be able to isolate one agent's identity, one agent's tool access, one agent's
data domain, and stop it without collateral damage.
If your only emergency response is turn off co-pilot, you don't have governance.
You have a panic button.
Attribute.
You must be able to answer, who did this, and by what authority with evidence, not inference?
That includes agent to agent chains.
If attribution disappears after the first hop, then your audit story becomes a probabilistic
narrative.
Auditors don't accept narratives.
They accept proof.
Contain.
You must be able to limit blast radius by design.
That means approvals for irreversible actions, scoped permissions, and bounded data access.
Otherwise a single prompt injection, a single bad tool call or a single overshared site,
becomes a tenant-wide incident.
And here's the drift pattern that always shows up.
It starts as an exception.
Then it becomes a shortcut.
Then it becomes a local optimization.
One team fixes friction by widening access or adding a connector.
Then it becomes global ambiguity, because now five teams copied that pattern, and none
of them tracked the rationale.
Entropy compounds through convenience.
That's not a failure of people.
That is the default behavior of complex systems.
Over time, policies drift away from enforcement.
Exceptions become norms, ownership dissolves, and the system quietly becomes a probabilistic
security model.
So if you want real governance, you stop writing rules and start building constraints.
You define a minimal control plane that you can actually operate, and you treat every
missing constraint as an entropy generator.
Next, the first failure mode that collapses the whole illusion.
Identity drift.
Once accountability goes probabilistic, security pauses the program.
Every time, failure mode won, identity drift.
Silent accountability loss.
Identity drift is where the whole will govern this later fantasy dies.
Not because the agent said something wrong, because you can't prove who did something
real.
In the early days, most co-pilot studio and power platform agents run in one of three identity
shapes.
The makers credentials, a shared service account, or some vague automation context that
exists mostly to keep the flow running.
All three create the same operational outcome.
Accountability becomes a story you tell, not a fact you can demonstrate.
And when the first incident happens, an unexpected permission change, a record update in a system
of action, an email sent to the wrong distribution list, the question isn't, "Why did the model
hallucinate?"
The question is, who executed this action?
If your answer starts with, "Well, it depends, you're done."
Because once identity drifts, you don't get deterministic auditability.
You get a probabilistic narrative.
The maker built it, the agent ran it, the connector used delegated permissions, the flow executed
under a connection reference, the action happened in the target system, and the initiating
user is somewhere in the chat transcript maybe.
That is not attribution, that is archaeology.
And the moment security teams realize they're doing archaeology, they pause the program,
not because they hate co-pilot, because the cost of being wrong is higher than the cost
of being late.
They can't sign off on a system where who did this can't be answered with evidence.
Here's the uncomfortable truth.
Security drift is usually designed in.
It gets designed in because people optimize for velocity, not for probability.
A maker wants to test quickly so they use their own credentials.
A team wants to avoid app registrations and proper non-human identity design, so they
grab an existing service account.
Someone wants an integration that just works, so they accept whatever identity the connector
defaults to.
None of that looks malicious.
Its convenience, convenience is an entropy generator.
And once it ships, identity drift becomes sticky, because it's invisible during success.
And the agent behaves, nobody questions which identity it used.
The agent helped.
The ticket got created, the record got updated, the email went out, everyone moves on until
the day it doesn't.
Then you get the incident review where someone asks for the simplest thing in enterprise computing.
Show the actor.
Not the owner of the solution, not the person who last edited the flow, not the user who
typed the prompt, the actor that had authority at runtime.
And if the agent executed actions as the maker identity, you've created an automation pathway
that depends on a human account life cycle.
That's what resets MFA changes, conditional access policy updates, a role removal, a disabled
account, suddenly the agent breaks or worse, the team creates workarounds that expand privileges
just to keep the automation alive.
If the agent executed actions as a shared service account, you've created the opposite problem,
continuity without accountability.
The automation keeps running even when the people behind it change roles or leave.
Security can't tie actions to a responsible sponsor.
Auditors see one identity, doing everything, everywhere across multiple agents.
It's not service reliability.
That's a single point of irreversible blame.
And if the agent executed actions through a vague automation context, you get the worst
possible outcome.
Logs exist, but they don't answer the question you're being asked.
You can see that something happened.
You can often see that a connector fired.
You might even see the flow run, but you can't draw a clean line from initiating intent
to executing identity across hops.
This is why identity drift stops programs faster than hallucinations.
Hallucinations are a model quality problem.
It's a treat that like training data, prompt design, and will add a disclaimer.
Identity drift is a governance failure.
It means the enterprise can't assert control over the system's actors, and once an enterprise
can't assert control over actors, it cannot claim compliance, accountability, or containment.
So the reality in incident response becomes brutal.
Security looks at the system and asks, can we disable the specific agent that misbehaved?
If the agent identity is the maker, disabling it means disabling a person.
That is a HR event.
Not a containment action.
If the agent identity is a shared service account, disabling it might kill five other automations
that also quietly depend on it.
That is collateral damage.
So the default choice becomes pause co-pilot broadly, stop publishing, stop experimentation,
freeze the program, then run a retroactive inventory.
And that's the pattern.
One attribution gap creates a full stop.
Not because the organization is dramatic, because it can't isolate the actor.
So if you remember one thing from this failure mode, it's this.
An agent without a stable, non-human, isolatable identity is not an agent you can govern.
It is a distributed liability generator.
Next, where identity drift actually comes from in Microsoft Estates.
Because it's not magic, it's the accumulation of specific pathways you can name.
How identity drift is manufactured in Microsoft Estate.
Identity drift doesn't happen.
You build it, usually with good intentions and a deadline.
The first factory line is the maker credential path.
In co-pilot studio, power automate, logic apps, and the broader power platform ecosystem,
creates something under their own identity, connects to outlook, SharePoint, Graph, Service
Now, whatever.
And it works.
That success becomes a prototype.
Then because prototypes always get promoted to temporary production, the maker's connection
becomes the runtime authority.
Now the agent isn't operating as an enterprise actor.
It's operating as a human shadow.
You don't have a stable principle.
You have a person-shaped dependency that will change, leave, rotate, MFA, or get conditional
access hardened.
And the automation will either fail or get fixed by widening privileges.
The second factory line is the service account shortcut.
Someone creates a single account named something like SVC Automation and uses it everywhere
because it avoids the pain of proper app registration and non-human identity life cycle.
This feels operationally mature.
It is not.
You've just created one identity with broad, long-lived access that becomes the execution
substrate for multiple agents, flows, and connectors.
When anything goes wrong, you can't isolate without collateral damage.
That service account becomes the tenant's anonymous root for automation, except it's not anonymous.
It's worse.
It's attributable to everyone and therefore to no one.
The third factory line is delegated permissions and implicit graph reach.
People talk about the agent respects permissions and they mean user access controls for reading
content.
That's not the whole story.
Tool calls and connectors often run through delegated permissions, connection references,
and consent grants that create reach far beyond what the business thinks it approved.
If is the big one once you allow a toolpath that can call graph under a delegated or application
context, you've effectively handed the agent a programmable interface to the tenant.
The agent doesn't need access to everything.
It needs access to the right pivot points, group membership, mailbox actions, teams messages,
share point sites, user profiles.
That is the graph and that reach doesn't feel real until you discover it during an incident.
Now add environments sprawl.
Every enterprise says it has dev test prod.
When the power platform is state evolves like all estates do, people create environments for
a business unit, for a project, for a proof of concept, for a partner demo, for a crisis.
DLP policies differ, connector allowances differ, who can create connections differs.
And when an agent built in a permissive environment becomes popular, it gets cloned or exported
or rebuilt elsewhere with slightly different identity and permission behavior.
That's how drift becomes permanent.
The same agent exists as five similar implementations, each with different runtime identity
and tool wiring.
And nobody can say which one is authoritative.
Then you get agent to agent chains.
This is where attribution dies quietly.
In a multi-step interaction, an initiating user triggers agent A, agent A calls agent B,
agent B calls a tool, the tool triggers a flow, the flow writes to a system of record.
Logs existed each hop, but the initiating identity often doesn't survive across hops
as a clean, queryable chain.
You can find the conversation transcript, you can find the tool call, you can find the
flow run.
What you can't always prove is the end-to-end actor lineage.
This human intent caused this specific state change under this specific non-human identity
with these permissions.
In other words, you have telemetry, you don't have accountability.
And the runs as ambiguity makes it worse.
Power automate, connector execution and tool invocation can look like it ran as the connection,
it ran as the owner, it ran as the maker, it ran as the environment or it ran as the service
principle depending on how the solution was built.
Operators know this pain.
The system offers multiple valid pathways and each pathway has different audit semantics.
The logs will faithfully record what happened, but not in the narrative structure auditors
demand.
So when security asks, can we contain one agent?
The honest answer becomes not reliably because you can't isolate the identity, you can't
scope the permissions and you can't guarantee the kill switch won't take down other automations
that reuse the same credential.
That's why more logging is not the fix.
Logging tells you what burned down.
It doesn't stop the fire.
The first thing you do is you just have to do the same thing.
And the first thing you do is you just have to do the same thing.
And the second thing you do is you just have to do the same thing.
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.
Over time, the estate stops being an architecture, it becomes an accident.
The sprawl usually looks harmless because it hides behind familiar words, connector, flow, integration, skill, tool.
Those are comforting nouns.
In reality, they are decision paths and decision paths accumulate.
The first sprawl vector is duplication.
Two teams both need create service now ticket, so they each build a separate flow.
One uses delegated credentials.
One uses a service account. One includes an approval step.
One doesn't. One writes back a ticket number.
One fails silently when the API throttles.
Same outcome on the whiteboard.
Completely different operational behavior in the tenant.
Then comes variation.
Team A adds a connector to just read from a SharePoint site for grounding.
Team B adds a different connector to read from team's messages because it's faster.
Team C adds graph because they couldn't get the connector to behave.
Each one expands the agent's reachable universe in a slightly different way.
And because no one is tracking tool contracts centrally, nobody can say how many ways your tenant can now create a ticket,
update a record, or grant access.
The second sprawl vector is chaining agents call tools that trigger flows, that call other tools that trigger other agents.
This is where helpful automation becomes distributed transaction behavior.
Without any of the discipline of distributed transactions.
No explicit failure domains. No consistent rollback.
No idem potency guarantees.
No single place to see the full path of an action.
So a small change becomes a wide blast radius.
Someone updates a tool to add a new field.
Another agent that reuses the tool interprets the new output differently.
A downstream flow fails and retries.
The agency's a retries a new instruction.
The ticket gets created twice.
Then the cleanup automation closes the wrong one.
Then the human gets blamed for not using the system correctly.
Conditional chaos.
And this is where enterprises make the foundational mistake.
They try to govern tools like the govern apps.
Apps have bounded surfaces.
Tools don't. Tools are composable authority.
A tool can be called by any agent that can see it.
In any sequence under pressure with partial context.
So if you allow tools to proliferate, you don't scale productivity.
You scale side effects.
And side effects are what turn executive enthusiasm into executive risk aversion.
Because once sprawl sets in, nobody can answer the core operational questions with confidence.
How many tools exist?
Which ones are duplicates?
Which ones write to systems of record?
Which ones can change permissions?
Which ones can send messages externally?
Which ones can trigger irreversible actions?
If the answer is we're not sure, the organization is already operating a probabilistic security model.
And the worst part is that sprawl makes containment politically impossible.
Security can see an issue and want to disable a connector, restrict a tool, or block an agent.
But they also know that tool might be used by five other teams.
Nobody owns the dependency graph. Nobody can guarantee what will break.
So the safe operational decision becomes the dumb one.
Paws publishing frees the program into a tenant-wide inventory.
sprawl turns incident response into paralysis.
That's why it's unbounded authority.
Not because one tool is powerful.
Because the system has no enforced limit on how many tool pathways can exist, how they compose, or how they drift.
So when people say agents are just co-pilot with plugins, that's the lie they tell themselves to stay comfortable.
Architecturally, they're building a distributed integration platform where every team can mint authority.
And there is no stable equilibrium for that.
Next, the pattern everyone recognizes, the service desk agent that worked and then multiplied until it became operational noise.
Pattern case, the service desk, success that triggered sprawl.
This pattern always starts with a win, because that's how enterprise entropy earns funding.
A service desk team ships a triage agent, nothing fancy.
It reads an incoming request, summarizes it, suggests a category, drafts a response, and, because someone wanted real value,
it can also open a ticket and update the status.
It reduces first response time, it makes the dashboard look better.
Leadership sees a demo where the agent turns a messy paragraph into a clean incident record with one click.
And the organization concludes the wrong thing.
We should scale this.
Not we should standardize it.
Scale comes first.
Discipline comes later.
Discipline never arrives.
Week one, the agent lives in one place with one set of connectors and one informal owner who remembers how it works.
The blast radius is small, everyone feels safe.
Week two, another team asks for the same thing, but for HR tickets.
Someone clones the agent because cloning is easier than negotiating requirements.
They reuse most of the tool chain, but swap one connector and add one approval step.
Now there are two agents that do triage, and they are already different in behavior, permissions and logging.
Week three, the infrastructure team wants it for access requests.
They don't like the approval step because it slows them down.
They remove it, they add graph calls because the connector didn't return the group membership data they wanted.
The agent now has a new toolpath that can touch identity objects.
Nobody calls that a security event because it's just service desk automation.
Week four, original IT team wants the same agent, but their environment has different DLP rules,
so they can't use the same connector.
The workaround flow, it runs as a service account because their makers don't have the right permissions.
Now the same business outcome, create, categorize and update tickets.
Exists through multiple identity and toolpathways across multiple environments.
And then comes the optimization phase, which is the polite word for divergence.
Each team tweaks prompts, they tweak categories, they tweak routing logic.
They add their own small enhancements because they have local knowledge and local pain.
They do not coordinate changes because coordination is slower than building.
Publish changes as versioned contracts because nobody framed tools as contracts.
They're thinking like app makers, not like operators of a distributed decision engine.
Now the collisions start.
Agent A, routes to network incident when it sees VPN keywords.
Agent B, routes to security incident because it learned from a different set of examples.
Agent C creates two tickets because it retreats on time out and nobody made the operation idempotent.
Agent D closes tickets automatically if the user hasn't responded in 24 hours
and someone wanted to reduce backlog metrics.
Those automations now overlap. They touch the same objects.
They produce different outcomes for the same input.
So service desk staff start seeing nonsense.
Tickets bounce between cues because routing logic disagrees.
Approvals arrive for tickets that were already handled by another agent.
Users get two different responses to the same question depending on which teams channel they asked in.
And because agents can trigger actions, not just suggest them, these inconsistencies aren't just confusing.
They pay the operational state, wrong category, wrong assignment group, wrong SLA clock, wrong closure notes, wrong escalation.
Then leadership asks the question that always shows up once the mirage collapses.
Why do we have five different answers?
Nobody has a clean answer because the system doesn't have a control plane.
There is no canonical agent, there is no canonical tool chain, there is no standard contract,
there is no enforced approval boundary for irreversible actions.
There is only a growing set of helpful implementations that share a name, not a behavior.
And here is the hidden cost, credibility loss.
Service desk teams stop trusting the agent because it behaves differently week to week.
Users stop trusting the service desk because outcomes are inconsistent.
The program loses political capital which matters more than the first month's productivity gain.
So now the organization does what organizations always do when automation creates ambiguity.
They add manual steps.
Someone says, "We'll keep the agent but only for drafting."
Someone else says, "We'll keep it but disable auto-rooting."
Someone else says, "We'll keep it but only in one region."
That sounds like risk management, it's actually architectural retreat.
Because the organization didn't reduce risk, it reduced scope after deploying uncontrolled authority.
And the artifacts remain, duplicated tools, often flows, shared accounts, inconsistent DLP exceptions,
and agents nobody remembers to decommission.
This is why toolsprall is not an inconvenience, it's an authority multiplication problem.
The initial win creates demand, demand creates replication, replication creates divergence, divergence creates collisions, collisions create incidents, incidents.
Created governance theatre and governance theatre eventually becomes a freeze.
Next comes the uncomfortable part.
Sprall is inevitable unless tools are treated as contracts, designed once,
reused everywhere and governed like the execution interfaces they actually are.
Safeguard 2, standardised tool contracts, MCP discipline.
Toolsprall only happens because the organization treats tools like accessories, they are not.
A tool is an executable interface into something that matters.
A system of record, a system of action, a mailbox, a permission surface, a ledger, a ticketing queue.
Once an agent can call a tool, the agent stops being AI and becomes automation with a language model as the dispatcher.
So the safeguard isn't approved connectors.
The safeguard is to standardise tool contracts.
A tool contract is the same idea as an API contract, just dragged into the copilot era.
What actions exist, what inputs are allowed, what outputs look like, what identity executes the call, what data gets touched,
what auditing must exist, and what approval gates sit in front of irreversible steps.
And yes, MCP discipline is the right mental model here.
Tools as contracts, not as a "bring your own connector" buffet.
The simple version is this, you want fewer tools, reused everywhere.
Enterprises do the opposite by default, they let every team wire a slightly different create ticket flow because autonomy feels faster.
Then they wake up with five variations, none of which can be changed safely because no one knows who depends on what.
So you invert the model.
You build a small centrally governed catalog of tools that represent common enterprise actions and you force reuse.
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.
That distinction matters because governance doesn't care that an agent can read a document.
Governance cares when an agent can change state.
Now a standardized tool contract has three properties.
First, structured outputs.
Chatty blobs are useless for automation.
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.
Tool outputs must be machine readable.
Ticket ID, system action taken, approval state, and an explicit status.
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.
Second, provenance.
Every tool call needs to produce evidence, not for the humans in the moment, but for incident response later.
What tool was called, what parameters were passed, what identity executed, and what system responded.
If an agent can't cite its tool calls, then you can't prove why a state change occurred.
And if you can't prove that, you don't have governance, you have optimism.
Third, separation of recommend from act.
This is where most organizations accidentally convert assistive AI into agentic AI without meaning to.
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,
updating a financial record, deleting content, changing policy.
These aren't steps, they're commitments.
So the contract must encode approvals, not as an afterthought.
As a required parameter, approval token, approval ID, and a reason code.
If the approval isn't present, the tool must refuse to act.
That is what enforcement looks like.
The tool itself becomes the policy boundary.
Now, versioning enterprises change tools constantly and pretend nothing downstream will break.
In an agentic estate, a tool change is a breaking change unless proven otherwise.
You need contract versioning, deprecation, and change control.
Not because governance loves paperwork, because a tool is a shared dependency across a fleet.
If a tool signature changes, and five agents interpret the output differently, you've created distributed failure.
So treat tool changes like code releases, review, test, staged rollout, rollback plan.
The tool catalog is a product, it has life cycle.
If you don't run it like a product, the estate will run you.
And here's the uncomfortable truth for citizen development narratives.
Local creativity is not a strategy for shared execution surfaces.
Let people build agents. Let them iterate.
But don't let them mint new tool pathways into critical systems without contract review.
That's the minimum line between innovation and entropy.
Everything else is theater, so the safeguard is not no tools.
It's controlled tools.
Fewer, standardized, versioned with structured outputs, provenance, and approval gates for irreversible actions.
Once you do that, sprawl doesn't disappear, but it stops being unbounded.
Toolpaths become known, dependencies become discoverable, change becomes survivable, and containment becomes possible
because you can revoke one tool grant or disable one tool version without guessing what else collapses.
Identity gave you who.
Tool contracts give you what and how.
And now you hit the third accelerant, data.
Because once tools are constrained, the next thing that silently expands in agents blast radius is what it can read,
and what it treats as truths.
Failure mode 3.
Obidient data leakage.
Governance theatre.
Tool contracts constrain what an agent can do.
Data access decides what the agent will do, and this is where most enterprises accidentally build the perfect compliance incident.
An agent that leaks, not because it's malicious, but because it's obedient.
They ground the agent on everything it can read, then act surprised when it reads the wrong thing.
This failure mode doesn't look like a breach at first.
It looks like a helpful answer.
The agent finds a document, it quotes it, it sounds confident, the user takes action, everyone feels productive.
Then compliance shows up weeks later and asks the question nobody designed for.
Was that answer sourced from an authoritative location and can you prove it?
Silence, because the agent didn't leak secrets in the Hollywood sense, it leaked trust.
It gave a correct looking answer sourced from an ungoverned corpus.
Draft policies.
Stale SharePoint copies.
Duplicated PDFs.
Someone's one drive export from two years ago.
And the final V7 really final docs graveyard that every tenant accumulates and the enterprise learns the wrong lesson.
It says the model hallucinated, no, the model didn't hallucinate, the system hallucinated governance.
The foundational mistake is this.
Allowed for humans is treated as allowed for agents.
Humans can have broad read access and still behave safely because humans have judgment, context and fear of consequences.
Humans know when a policy doc looks outdated. Humans can spot that the footer says draft.
Humans can ask is this the latest version?
Agents do none of that unless you forced it into the design.
Agents will happily ground on whatever is reachable and they will do it at machine speed consistently and at scale.
That means every overshared site, every often team, every temporary external share link, every library, with broken inheritance becomes an accelerant.
Not because the agent is clever.
Because it is compliant with your permissions and your permissions are a mess.
Now here is the part that really annoys security teams.
You can have perfect model accuracy and still trigger a compliance incident.
Because compliance doesn't care that the answer was plausible. Compliance cares that the answer was sourced from the wrong place.
So you get situations like this. The agent answers a question about retention, exports, HR procedure, access approvals or financial controls.
It sights something. It might even cite the right thing.
But you can't prove it consistently because the agent's retrieval surface was never constrained to authoritative sources only.
In the moment you can't prove authoritative sourcing, you've converted co-pilot from a productivity feature into governance theatre.
A system that produces outputs that look legitimate without the evidence chain that makes them legitimate.
This is also why we'll just clean up SharePoint is not a strategy.
Content cleanup is infinite. Every day someone creates a new copy. Every project spins up a new team.
Every merger imports a new file share. The backlog never ends.
And as long as agents are allowed to roam the same way humans roam, they will exploit that entropy automatically.
The result is institutional oversharing, not a single catastrophic leak but a thousand small exposures that add up to systemic risk.
The agent answers the wrong user with the right data or the right user with the wrong version.
Or it summarizes something that was never meant to be operational guidance.
And because it's grounded it looks safe. It's not.
Grounding on everything you can read is not safety. It's amplification.
Now add one more twist. Agents don't just read. They can act.
So obedient data leakage doesn't stop at wrong answer. It becomes wrong action based on wrong source.
A stale policy says approvals aren't required. The agent recommends skipping the approval gate.
A draft procedure says a system owner is IT operations but that changed last quarter.
The agent routes access request to the wrong group. A duplicate spreadsheet lists an old vendor bank account.
The agent files the payment update, nothing in that chain required hallucination. Only reach.
And when the incident happens the business will ask for the simplest assurance.
Why was the agent allowed to see that?
If your answer is because the user could you've just admitted you didn't design agent boundaries at all.
This is why obedient leakage is worse than people think. It's not an AI failure. It's a boundary failure.
It exposes that your governance model assumed human judgment then delegated the same access to a non-human actor.
So the core symptom of failure mode number three is this.
The enterprise can't differentiate between data that is merely accessible and data that is operational authoritative for agents.
And without that distinction the program will collapse under its own credibility gap.
User stop trusting answers, leader stop trusting the risk posture, security stops trusting containment.
And everyone returns to the safest system of record in the enterprise meetings.
Next, the pattern case that proves the point.
The policy agent that was right and still failed because right is not the same as governed pattern case.
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.
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.
Can I expense this? What's the retention rule for customer data?
It's framed as assistive, it's just answers, no actions, low risk, everyone relaxes, then they ground it.
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.
And a lot of it respects permissions confidence.
The agent can read what the user can read, therefore it's safe, that comforting assumption breaks immediately.
Because in the real tenant, what the user can read includes drafts, duplicates, stale PDFs and migration artifacts.
It includes the policy wiki someone copied into a project team two years ago.
It includes the temporary share point site created during a merger that nobody cleaned up.
It includes the PowerPoint deck, someone used for training that contains policy summaries that were never formally approved.
The agent is asked a simple question, do we need manager approval for international travel over X-days?
Or can we share customer data with vendor Y? Or what's the retention period for these records?
The agent returns an answer, and the answer is plausible.
It's well written, it's consistent with something in the tenant, sometimes it's even technically accurate in the abstract.
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.
The agent did not hallucinate, it retrieved, it grounded, it answered like it was trained to.
The user trusts it because it sounds authoritative, and because it's delivered with the implied legitimacy of, "This is the company's copilot."
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.
This failure mode doesn't give you a dramatic security alert, it gives you delayed consequences.
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?"
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.
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?"
And that's where the program dies, quietly.
Because the honest answer is, "We don't know, or worse, it's one of the copies."
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.
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.
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.
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.
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.
That's intent without enforcement again. The Fix is to define authoritative domains and deny everything else by default.
Policy agents can only ground on a curated corpus.
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.
And unless you enforce that boundary technically, you will replay this incident forever just with different topics.
That's why this pattern matters. It proves that accurate is not the bar. Govend is the bar.
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.
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.
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.
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?
Humans exploit oversharing occasionally. Agents exploit it deterministically. That distinction matters.
When people hear data boundary, they think classification projects and content labeling campaigns that take a year, produce a scorecard and change nothing operationally.
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.
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.
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.
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.
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.
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.
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.
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.
That lets you remediate with intent, not clean everything, but fix the specific exposures that will predictably become agent outputs.
And that's the operational posture shift. Remediation becomes risk driven, not hygiene driven, hygiene driven remediation never finishes, risk driven remediation ships.
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.
Identify the high risk locations, overshared sites, unlabeled repositories with regulated content and the everyone has access libraries that were created for convenience.
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.
Third, use labels and purview controls to make those boundaries enforceable and reviewable.
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.
Fourth, iterate based on actual exposure discovery, not governance backlog fantasies. If DSPM shows you 10 sites that will predictably leak, fix those 10.
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.
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?
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.
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.
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.
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.
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.
Under that pressure, people don't break governance maliciously. They eroded incrementally. One exception, one widen scope, one connector added, temporarily.
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.
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.
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.
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.
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.
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.
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.
Defender for AI gives you behavior-based signals that map to the real attack and failure patterns enterprises actually see with agents.
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.
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.
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.
And with agents frequency matters. Tools can be invoked thousands of times. A human making a mistake is one event.
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.
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.
And the incident will expand while people debate blast radius. But if the agent has a dedicated, entra identity, containment is mechanical.
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.
Now the part enterprises under invest in is response playbooks. They turn on telemetry and call it done. Telemetry isn't response.
Response is a pre-decided set of actions that the on call team can execute without improvising policy during an incident.
Defender for AI matters because it can feed those playbooks with reliable triggers. Tool abuse detected, abnormal access, suspicious prompt patterns, unexpected data interaction.
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.
Defender becomes the place where security teams can treat agents as a new hunting surface, correlate activity to identities, tool usage and data exposure.
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.
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.
Defender when tied to agent identities and tool contracts gives security something they almost never get with new platforms. The ability to act surgically.
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.
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.
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.
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.
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.
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.
Here's how it breaks in the real world. An agent receives a request that crosses the line from assistance into action.
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.
Request summary, target, maybe a risk hint and then approve. Someone approves. Everyone feels good. Then the action executes.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Because once approvals float free of identity and tool execution, you don't just get incidents, you get paralysis.
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.
Minimal viable agent control plane, MVACP, the only sane starting point, enterprises keep asking for a framework like this is a maturity model problem.
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.
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.
It has four pillars and they match the failure modes because the platform will drift directly into those failures unless you stop it.
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.
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.
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.
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.
Tools are authority, authority is what creates incidents. So you don't let authority proliferate without a registry, versioning and a refusal mode.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The control surfaces, policies that bind identities to conditions, signals that detect drift and playbooks that contain it. Security also owns the kill decision.
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.
So security owns the containment lever, disable the agent identity, revoke tool grants and freeze publishing for that one actor.
If security can't act surgically, security will act broadly. That's how programs die. Then comes data and compliance.
This group defines authoritative sources and the policy boundaries for what agents are allowed to treat as truth.
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.
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.
So compliance owns the decision of what counts as authoritative and they own the remediation priorities that follow from DSPM findings.
Fix the overshared sites that agents will exploit, not the ones that look bad on a hygiene report. Now the business sponsor.
This is the role enterprises keep trying to delete because it forces uncomfortable accountability. The sponsor owns outcomes and risk acceptance.
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.
Productivity in exchange for a new kind of operational risk surface.
Without a sponsor, every incident becomes a debate about whether the agent should have been allowed to do the thing it did.
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.
Then the technical owner. They own build quality, tool wiring, permission scoping, structured outputs, provenance, test coverage and release discipline.
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.
And here's the part that stops the fantasy. One admin cannot hold this control plane alone.
If your organization's model is the power platform admin will govern agents. You are building a bottleneck and calling it a strategy.
That person will either rubber stamp everything to avoid being hated or block everything to avoid being blamed.
Both outcomes produce the same result architectural erosion. So the operating model rule is separate powers.
Platform sets defaults and gates, security detects and contains. Data compliance defines authoritative boundaries.
Business sponsors accept risk, owners implement and maintain.
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.
That registry becomes the only place an agent is allowed to be real. Everything else is just code someone wrote.
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.
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.
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.
The fleet doesn't collapse because the model is weak. It collapses because the organization tries to scale outcomes without scaling the control plane.
So the scaling path has one rule, prove containment and attribution at each step then expand.
Anything else is just multiplying uncertainty. Start with a single agent that fits inside MVICP, not a showcase agent, a real one.
Something that touches a system of action uses a tool contract and grounds on an authoritative domain.
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.
Remember this detail because it's going to matter later. Fleet governance is not a policy document, it is defaults.
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.
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.
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.
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.
That request becomes the intake gate you defined earlier. New authority requires review. Now multi agent orchestration.
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.
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.
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.
You also define failure domains. Which actions can fail without cascading into other systems? And which actions must stop the chain immediately?
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.
Change management is the other scaling trap. Agents don't just run. They evolve. Tools get updated. Apis change. Permissions drift. Data domains expand.
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.
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.
One, you can isolate and disable a single agent identity without collateral damage. Not in theory, in practice during a test incident.
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.
So the scaling path is boring by design. Registry identity contracts boundaries detection, defaults applied automatically and expansion gated on operational evidence.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Environments, DLP, solution boundaries, connection references and publishing controls are the only way to stop dev shortcuts from becoming production habits.
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.
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.
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.
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.
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.
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.
Now runtime drift defender for AI is your detection and hunting surface. The point isn't to prove the agent is secure.
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.
Detection only matters if containment is real. That means defender alerts must map to action security can take.
Quarantine the agent identity, revoke tool permissions, freeze publishing and block data domain access.
If the alert can't trigger a surgical response, you'll get the predictable outcome. A meeting, a delay and then a broad shutdown.
Now the awkward one, power platform DLP will save us. It won't. DLP is necessary, but it's not a tool contract.
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.
So tool contracts live above connectors. Whether you implement them through MCP style tools, custom connectors, API management or standardized flows doesn't matter.
What matters is that they behave like contracts. Version, reused, refusal modes baked in, provenance emitted every time and approvals required for irreversible actions.
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.
What prevents entropy is defaults. One agent identity, curated tool paths, bounded data domains, runtime detection and containment that can execute in minutes.
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.
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.
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.
And the trick is this, the questions must be binary. They must produce an answer that is either provable or it isn't.
If the response is a narrative, you already failed. Start with identity because identities where accountability either exists or dissolves.
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.
A named sponsor who accepts the risk of the outcome and a named technical owner who maintains the implementation.
If the sponsor role doesn't exist, the agent is a shadow project and shadow projects don't survive the first incident review.
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.
And when collateral damage is the only containment option, the organization will choose the safest move every time. Freeze the program.
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?
These were the sources, these were the labels, this was the authoritative domain and this was the tool called chain for actions.
Which tool was called with what parameters under which identity and with which approval token.
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.
Now shift to the sprawl questions because sprawl is what turns small success into systemic ambiguity.
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.
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.
Next, do we have standardized tool contracts for irreversible actions?
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?
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.
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?
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.
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?
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?
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.
And finally the question that exposes whether you're scaling responsibly or just shipping faster. What is our not ready to scale yet criteria?
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.
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.
Answer these questions honestly and you'll know whether you're operating a control plane or just watching entropy accumulate with better marketing.
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.
Here they are, non-negotiable number one, identity per agent, no exceptions.
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.
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.
And the identity must be containable, that means a kill switch you can pull without disabling, copilot for everyone.
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.
Standardized tool contracts, reused everywhere. You stop treating tools as whatever connector someone found.
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.
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.
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.
Non-negotiable number three, enforced data boundaries with an authoritative sources model. This is where most programs pretend permissions equal governance.
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.
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.
Per view, DSPM for AI becomes the posture lens that tells you where the boundary will fail in real life.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!