👉 Why AI governance is becoming less about what an agent can access – and more about what it can do with what it’s allowed to access
Here’s an uncomfortable thought.
Your AI agent might not be doing anything wrong.
It might be following every permission you’ve given it, it might be operating exactly as designed. It might even be accessing information that the user is legitimately allowed to access.
And yet…
you could still have a serious governance problem.
That’s because we’re entering a world where traditional access control isn’t enough.
For years, we’ve asked:
“Can this person access this information?”
With AI agents, we increasingly need to ask:
“What can an agent do with everything this person is allowed to access?”
That’s a very different question.
And I think it’s one of the most important questions in AI governance right now.
👉 The permission problem
Let’s imagine a fairly normal Microsoft 365 environment.
A user has access to:
- SharePoint sites
- OneDrive
- Teams
- business documents
- project information
- HR information relevant to his role
- financial information relevant to their role
Nothing is necessarily wrong with that.
Their permissions might be perfectly legitimate.
Now give the user an AI agent. The agent can potentially search across the information available to the user, understand it, connect information from different sources and produce an answer.
Suddenly, something changes. The user might never have manually opened 50 documents.
The agent can.
The user might never have thought to connect information from five different SharePoint sites.
The agent can.
The user might never have noticed that three pieces of information, individually harmless, become highly sensitive when combined. The agent can potentially make that connection.
The agent hasn’t necessarily bypassed security.
It may simply have used the access it was given – and that’s the uncomfortable bit.
👉 Access control answers one question
Traditional access control is incredibly important.
It answers:
Can you access this?
That’s still fundamental.
Sensitivity labels, permissions, groups, Conditional Access, DLP and other controls all contribute to protecting information.
But AI introduces another question:
What can you do with what you’re allowed to access?
And when “you” is an autonomous or semi-autonomous agent, that question becomes considerably more complicated. Because an agent doesn’t necessarily consume information in the same way a human does.
A human might read three documents.
An agent can potentially search thousands.
A human might make one decision.
An agent can potentially execute a multi-step workflow.
A human might copy information into an email.
An agent can potentially retrieve information, combine it, transform it and pass it to another tool.
That is the shift.
👉 AI didn’t create the data governance problem
This is where I think organisations need to be honest with themselves. AI hasn’t suddenly created all these information governance problems.
It’s exposing them.
Think about the Microsoft 365 environment that has accumulated over the last decade. You’ve probably got:
- old SharePoint sites
- inherited permissions
- former employees’ content
- documents nobody owns
- stale information
- broadly shared files
- “Everyone except external users” permissions
- anonymous or “Anyone” links
- sensitive information without labels
- inconsistent retention
- duplicate documents
- project sites that were never closed
A human user may never have found some of that information.
An AI agent might.
Microsoft’s current guidance for securing and governing Microsoft 365 Copilot agents specifically recommends discovering oversharing risks, identifying sensitive information in grounding data and addressing stale information before deploying agents broadly.
That’s a really important message.
Your AI governance programme starts with your data governance programme.
👉 Grounding data is now part of the security boundary
The term grounding data is becoming increasingly important. It’s the information an AI system can use to formulate its response.
For Microsoft 365 Copilot agents, this can include information from places such as SharePoint and Microsoft Dataverse.
Microsoft’s deployment guidance explicitly treats protection of grounding data as a separate stage of securing agents. It recommends applying sensitivity labels, reducing stale data, restricting sensitive files from Copilot processing and addressing oversharing.
That changes how I think about SharePoint. For years, we could say:
“This is a SharePoint permissions problem.”
Increasingly, I’d say: “This is an AI security boundary.”
Because the permissions and data quality decisions you make today can directly influence what an agent can discover tomorrow.
👉 Sensitivity labels become even more important
This is where Microsoft Purview starts to become particularly interesting. Sensitivity labels aren’t simply about putting a classification on a document.
They can provide protection that travels with the content. Microsoft’s current agent guidance states that sensitivity labels applied to SharePoint and Dataverse grounding data are respected by Microsoft 365 Copilot agents, with responses limited to content the user has appropriate permissions to access.
That gives us an important control layer. But there’s another question.
What if the user is allowed to access the document?
This is where DLP becomes interesting. Microsoft’s current guidance says Purview DLP can restrict Microsoft 365 Copilot from processing sensitive files, including files with particular sensitivity labels, even where the user has access to the file.
That is a subtle but important distinction.
Permission doesn’t automatically mean “AI should process this.”
👉 That’s a new governance conversation
Imagine: A user can open the document.
That’s one decision.
Now:
Should Copilot use that document to answer the user’s question?
That’s another. And:
Should an agent use that information as part of an automated workflow?
That’s potentially another. And:
Should the agent send the resulting information to another system?
That’s another again.
We are moving from a simple permission model towards a chain of decisions.
I’d represent it like this: DATA → IDENTITY → AGENT → ACTION → OUTCOME
At each stage we should be asking:
What data?
Whose identity?
Which agent?
What action?
What happened as a result?
That’s the governance model I think we need to start developing.
👉 Then agents start acting
And this is where things get really interesting. An AI that reads information and produces a summary is one thing.
An AI agent that can take action is something else. Microsoft’s security research describes this transition from AI systems that primarily read and respond towards agents that can plan multi-step tasks, decide which tools to invoke and execute actions.
That could mean:
- sending an email
- creating a document
- updating a record
- querying a database
- calling an API
- interacting with a business application
- sharing information
- initiating a workflow
- invoking another agent
The risk profile changes. A prompt injection against a summarisation tool might produce a bad answer.
A prompt injection against an agent with access to tools could potentially cause an action.
Microsoft’s recent research highlights exactly this problem, including MCP tool poisoning, where malicious instructions can be embedded in tool metadata and influence agent behaviour.
And that’s where I think the phrase “least privilege” isn’t enough anymore.
👉 We need least agency
We’ve spent years talking about Least privilege
Give users and applications only the permissions they need. That’s still essential. But agents introduce another dimension:
Least agency
Give an agent only the ability to perform the actions it actually needs. An agent might legitimately need access to a customer record.
That doesn’t mean it should be allowed to:
- delete that record
- email the customer
- export the entire database
- call any external API
- share the information externally
Access isn’t the same as authority to act. That’s a distinction I think we’re going to hear a lot more about.
👉 What about MCP?
This becomes even more relevant as organisations connect agents to tools through mechanisms such as Model Context Protocol (MCP).
MCP can give agents access to external tools and systems. That’s incredibly powerful. It’s also another trust boundary.
Microsoft’s recent security research describes MCP tool poisoning as a supply-chain risk and recommends treating MCP servers as production dependencies, maintaining approved tool inventories, reviewing tool descriptions, limiting tool access and using human approval for high-impact actions.
That means your AI governance programme now needs to consider more than:
What data can the agent see?
It also needs to consider:
What tools can the agent call?
And:
What can those tools do?
And:
Who approved them?
And:
What happens when the tool changes?
That’s not traditional information governance, but it’s becoming part of AI governance.
👉 Where does Microsoft Purview fit?
This is where I think Purview becomes much more than a compliance portal.
Microsoft’s current deployment model for securing and governing Microsoft 365 Copilot agents breaks the approach into four stages:
1. Discover risks and gaps
Understand:
- what agents are being used
- where sensitive information exists
- where oversharing exists
- what risky AI activity is happening
- where governance gaps exist
Purview Audit, data risk assessments, DSPM for AI and Compliance Manager all have roles here.
2. Protect grounding data
Use:
- sensitivity labels
- DLP
- Data Lifecycle Management
- Dataverse data policies
- oversharing controls
The goal is to make sure sensitive or inappropriate information doesn’t simply become AI knowledge because it happens to be accessible.
3. Protect interactions
Now look at the conversation itself.
Microsoft’s guidance includes sensitivity label inheritance, DLP restrictions on sensitive files referenced during interactions and Insider Risk Management for risky AI usage.
4. Govern interactions
And finally:
- retain
- investigate
- discover
- apply compliance controls
- manage the lifecycle of AI interactions
Purview’s guidance explicitly includes Data Lifecycle Management, Communication Compliance, eDiscovery and Data Security Investigations in this stage.
That is a much broader model than:
“Let’s put a DLP policy on Copilot.”
👉 Don’t forget the data lifecycle
Here’s another area I think is going to become increasingly important.
Stale data.
Microsoft’s agent guidance specifically recommends using Data Lifecycle Management to reduce stale information in SharePoint and OneDrive because outdated information can affect agent response accuracy.
This is fascinating. Retention isn’t just about: “Are we keeping this information for the legally required period?”
It can increasingly become: “Should this information still be available as AI grounding data?”
That’s a different conversation. An old document may still be legally retained, but that doesn’t necessarily mean you want an agent treating it as current business knowledge.
And that brings us back to the distinction between:
Retention and AI relevance.
They’re related, they’re not the same thing.
👉 AI governance is becoming information governance
This is probably the biggest point I’d take away from all of this. We sometimes talk about:
AI Governance and Information Governance
as though they’re separate programmes. I don’t think they can remain completely separate. If your AI uses enterprise information, then:
data quality matters.
permissions matter.
classification matters.
retention matters.
ownership matters.
DLP matters.
audit matters.
eDiscovery matters.
lifecycle management matters.
AI hasn’t replaced information governance.
It’s made it more important.
👉 And now we have AI agents governing AI
There’s another interesting twist. Microsoft is already introducing AI-powered agents inside Purview itself.
Microsoft Purview currently provides Security Copilot agents for tasks including DLP and Insider Risk Management alert triage, with posture and investigation agents also available in preview.
So we’re getting to a fascinating situation.
AI agents are being used to govern AI agents.
Which means the governance chain becomes:
Human → Governance → AI Agent → Data → Tools → Action
and potentially:
Human → Purview Agent → Investigation → AI Activity → Decision
That’s going to create a whole new set of questions around agent identity, accountability, auditability and human oversight.
👉 So what should organisations actually do?
I wouldn’t start by building hundreds of policies. I’d start with five questions.
- What agents do we actually have?
You can’t govern what you can’t see. Build an inventory.
Microsoft Agent 365 and Microsoft’s broader agent security tooling are increasingly focused on central visibility of agents, their identities, permissions, activity and security posture.
2. What data can those agents access?
Start with:
SharePoint.
OneDrive.
Dataverse.
Email.
Teams.
Find the oversharing.
Find the sensitive data.
Find the stale data.
Find the orphaned data.
3. What controls apply?
Ask:
- Are sensitivity labels applied?
- Are permissions appropriate?
- Are DLP policies covering the agent scenario?
- Are sensitive files excluded from processing where necessary?
- Are risky interactions monitored?
- Are retention policies appropriate?
- Is audit enabled?
Don’t assume that because you have a policy for humans, it automatically covers every agent scenario.
Microsoft’s current training guidance explicitly warns that coverage varies across agent types and that some agents behave differently from users, potentially creating policy coverage and enforcement gaps.
4. What can the agent actually do?
This is the new question. Don’t stop at “What can it read?”, ask:
“What can it change?”
“What can it send?”
“What tools can it invoke?”
“What systems can it reach?”
“What happens without human approval?”
5. Can we prove what happened?
If something goes wrong, can you reconstruct:
Who → Agent → Data → Tool → Action → Outcome
If you can’t, you’ve got a governance problem. Auditability isn’t an optional extra. It’s part of trust.
👉 A simple agent governance model
Here’s the model I’d recommend organisations start thinking about:
| Layer | Governance question |
| Data | What information can be accessed? |
| Identity | Whose authority is the agent operating under? |
| Agent | What is the agent allowed to do? |
| Tools | Which tools and systems can it invoke? |
| Action | Which actions require approval? |
| Outcome | Can we audit and investigate what happened? |
And sitting across all of it:
Purview + Entra + Defender + Sentinel + governance processes
Because this isn’t just a compliance problem. It’s an identity problem. It’s a security problem. It’s a data problem. It’s an architecture problem. And ultimately, it’s a governance problem.
💡 The Jim Talks takeaway
Here’s the thought I want people to leave with. Your AI agent might not be breaking the rules.
It might be following them perfectly.
The problem could be that the rules were designed for humans. We gave a person access to a SharePoint site because they needed it.
We didn’t necessarily design those permissions around an autonomous system that can search, correlate, summarise and act at machine speed.
We gave an agent permission to call a tool because the business process required it. We didn’t necessarily consider what happens if that tool’s instructions change.
We gave an agent access to information because the user was authorised. We didn’t necessarily ask whether that information should be used as AI grounding.
That’s the governance gap.
👉 We spent 20 years governing what humans could access
Now we need to govern something different.
What AI can do with everything humans can access.
That’s the next chapter of information governance.
And I think the organisations that get this right won’t be the ones with the most AI policies.
They’ll be the ones that understand the relationship between:
Data.
Identity.
Agents.
Tools.
Actions.
Outcomes.
Because AI governance isn’t about teaching the agent the rules.
It’s about making sure the rules, permissions and data we’ve given the agent are worth following in the first place.
Leave a Reply