Series: Governing AI Agents in Microsoft 365 — Part 4 of 5. This post covers the process governance layer — the human decisions that tooling alone doesn't resolve. Part 5 covers governability by design — the design and ALM decisions that determine how governable an agent is before it reaches the approval process.
The previous three posts in this series have covered the technical governance controls available for Copilot Studio agents: Power Platform DLP policies, Microsoft Purview, and Microsoft Agent 365. Together they represent a substantial set of tools — connector controls, sensitivity label enforcement, a centralised registry, security integration with Entra, Purview, and Defender.
What they don't cover is the layer that determines whether those tools are used effectively: who owns an agent, who is accountable when it behaves unexpectedly, who decides when it should be retired, and who approved it in the first place.
This is the process governance gap. It exists not because tooling is absent, but because tooling still can't fully make organisational decisions about ownership, accountability, and acceptable risk. That requires a framework — and most organisations haven't built one yet.
The Proliferation Problem
Copilot Studio makes building agents genuinely accessible. A business analyst, a project manager, a department coordinator — many users with the right licences and permissions can build a functional agent quickly. That accessibility is the point, and it's what makes agents valuable at scale.
But it creates a governance challenge that didn't exist when agent development required a developer and a formal project lifecycle. Without a framework in place, agents get built for specific tasks, work well initially, and then quietly degrade. The SharePoint site they draw knowledge from gets reorganised. The process they were built around changes. The person who built them moves to a different role. Nobody else knows the agent exists, let alone how it was configured or whether it's still fit for purpose.
Microsoft Agent 365 provides the technical inventory — a centralised registry of agents across the tenant. But the registry doesn't tell you why an agent exists, who sponsors it, whether it was ever formally approved, or when it can be safely retired. That business context has to come from the organisation, not the platform.
Organisations should also decide whether all licensed users can create agents or whether agent creation should be restricted to defined maker groups. The proliferation problem is significantly easier to manage when the pool of makers is intentional rather than open by default.
The Org Catalog as a Forcing Function
The ability to submit agents directly to the organisational catalog from Copilot Agent Builder is a meaningful governance checkpoint in the approval workflow, not just a feature. When an agent is submitted for org-wide availability, someone has to decide whether it should be approved. That decision creates accountability that informal agent sharing doesn't.
The question most organisations haven't answered is who sits in that approver role. In many organisations, IT or operations teams will likely become the default approvers because they control governance and risk configuration. But default is not the same as decided. The approver role needs to be defined explicitly, and the people in it need to understand what they're actually approving.
Approving an agent for the org catalog should mean more than confirming it works. It should mean confirming that someone owns it, that its knowledge sources are appropriate and current, that its scope is understood, and that there is a plan for what happens when it needs to be updated or retired.
Defining Ownership Upfront
Ownership is much easier to establish at the point of creation than to retroactively assign. Once an agent is in production and being used, nobody wants to put their hand up for something they didn't build and don't fully understand.
An agent owner should be:
- The person accountable for the agent's accuracy and behaviour
- The point of contact if users report problems or unexpected outputs
- Responsible for reviewing the agent when its underlying content or process changes
- Responsible for confirming the agent continues to serve a valid business purpose
- Named in the agent register and in the Entra Agent ID sponsor field where applicable
In practice, the owner is usually the person who built the agent or the business lead for the process it supports. The key is that ownership is explicit — recorded, not assumed — and that it transfers formally if the original owner moves on. Ownership is continuous; review is periodic validation of that ownership.
Where Entra Agent ID sponsorship is available, the governance framework should require it to be populated as part of the approval process, connecting the technical identity record to the business accountability record.
What an Agent Register Looks Like
An agent register doesn't need to be complex. A SharePoint list works well. Agent 365 provides the technical inventory; the register provides the business context layer that sits on top of it.
The minimum useful fields:
| Field | Notes |
|---|---|
| Agent name | As it appears in the catalog |
| Description | What it does and why, in plain language |
| Owner | Named individual — not a team or department |
| Environment | Which Power Platform environment |
| Knowledge sources | Which SharePoint sites, documents, or external sources |
| Published channels | Teams, SharePoint, web, other |
| Data risk profile | Internal only / External data / Cross-system / Sensitive process |
| Business criticality | Low / Medium / High — distinct from risk; reflects importance to operations |
| Approval date | When approved for the catalog |
| Review date | When next due for review |
| Status | Active / Under review / Deprecated |
Two fields are worth calling out specifically. The data risk profile classifies agents by their data exposure — an agent that only accesses public web content is a different governance proposition from one that accesses HR or finance systems. Business criticality is distinct: a low-risk agent can still be business-critical, and a high-risk agent may have limited operational importance. Both dimensions together give you a proportionate basis for review frequency and scrutiny level.
The register serves two purposes. First, it gives governance and compliance teams the business context that the technical inventory alone doesn't provide. Second, it creates the audit trail that data protection teams will eventually ask for — who approved this agent, when, and on what basis.
Maintenance and Review Cycles
An agent approved today is not necessarily fit for purpose in six months. Knowledge sources change. Processes evolve. Organisational structures shift. An agent built around a specific SharePoint library structure may silently start returning poor results if that library is reorganised without anyone notifying the agent owner.
A review cycle tied to the agent register gives you a systematic way to catch this before users lose confidence. The appropriate frequency depends on how dynamic the underlying content and process are. Quarterly is a reasonable default for most agents. Agents drawing on content that changes regularly, or those operating in sensitive process areas, warrant a more frequent cycle. Higher-risk or business-critical agents should follow shorter review cycles than standard agents — the register fields for data risk profile and business criticality provide the basis for that tiering.
The review itself doesn't need to be extensive. The key questions are: is the agent still being used, are its knowledge sources current and correctly scoped, has the process it supports changed in any way that affects its behaviour, does it still serve a valid business purpose, and is the owner still the right person?
Consumption data from the Copilot Studio usage reports and Agent 365 provides a useful input to the review process. An agent with declining usage over several review cycles may be a candidate for deprecation rather than continued maintenance.
Retirement and Deprecation
Retiring an agent is as important as approving one. Agents that are no longer fit for purpose but remain available in the catalog — or worse, remain deployed in Teams or SharePoint — create risk. Users may continue to rely on them, receiving outputs based on outdated or reorganised content without any indication that the agent has been abandoned.
A deprecation process should be part of the governance framework from the start. When an agent is retired:
- Users who have interacted with it recently should be notified
- The catalog entry should be disabled, removed from active use, or marked as deprecated depending on governance requirements
- The agent should be disabled or unpublished, not simply ignored
- The agent register entry should be updated to Deprecated with the retirement date and reason
The monitoring available through signals from Agent 365, SharePoint Agent Insights, and Copilot usage reports provides the data to identify agents that have gone inactive or whose usage has dropped significantly — a practical prompt for the deprecation conversation before it becomes a governance liability.
Building the Framework
The technical controls across the previous three posts provide the enforcement and visibility layer. This process layer sits on top of them. Together they cover the full governance picture.
The practical starting point for most organisations:
- Decide who can create agents — open to all licensed users or restricted to defined maker groups
- Define the approver role — who reviews agents before org catalog submission, and what does approval mean?
- Require ownership at approval — ownership must be recorded before an agent goes live, not assigned later
- Create the agent register — a SharePoint list is enough to start; align it with Agent 365 identifiers rather than duplicating inventory data
- Set a default review cycle — quarterly for most agents; make the owner responsible for initiating it
- Define deprecation — what triggers it, what the process is, who signs it off
- Classify by data risk and business criticality — use both dimensions to calibrate scrutiny and review frequency proportionately
None of this requires significant investment. It requires a conversation — ideally before your agent count reaches the point where a retrospective audit becomes the only option.
The org catalog submission process provides a natural governance checkpoint to introduce these controls before scale makes them harder to enforce.
Part 5 of this series covers governability by design — the design and ALM decisions that determine how easy an agent is to govern, audit, and retire before it ever reaches the approval process.