Updated 19 October 2026: Microsoft has blocked new enablement of Restricted SharePoint Search (retiring 31 January 2027), so this post now points to Restricted Content Discovery and SharePoint Advanced Management instead, and the Copilot Control System references now point to the 2026 release waves rather than a single update.
What agent sprawl looks like in a real Australian tenant
Most Australian tenants that deployed Microsoft 365 Copilot in late 2024 or through 2025 now have a substantial and growing inventory of custom agents published in Copilot Studio. Very few have a current inventory of them. This is the operational definition of agent sprawl: agents exist, agents connect to enterprise data, and no one can produce an authoritative list with owners, connectors used, and last activity.
The risk is rarely malicious. It is configuration drift. An agent built six months ago to summarise a shared mailbox keeps running after the owner changes role. An agent connected to a SharePoint site still has access after the site's audience has been narrowed. An agent built in a sandbox environment got promoted to production without a connector review. None of these are unusual. All of them are agent sprawl.
The good news is that Microsoft introduced the Copilot Control System through its 2026 release waves (Microsoft Learn — Copilot Control System reference, accessed 19 October 2026). The agent inventory dashboard is the system of record. The playbook below uses it.
Step 1 — Export the inventory and add owner metadata
Open the Copilot Control System agent inventory and export the full list. According to the Microsoft Learn Copilot Control System reference, the inventory includes agent name, environment, owner, connectors used, publish state, and last activity timestamp. Filter to published agents first; draft agents are a smaller risk and can be handled in a second pass.
For each agent, capture three pieces of metadata that the inventory may not surface directly:
- Business owner — not the technical builder, but the function that depends on the agent
- Data classification of the connectors used — Public, Internal, Confidential, or Highly Confidential
- Whether the agent processes personal information that would trigger APP 8 if routed offshore
This metadata is the input to all subsequent decisions. Without it, the inventory is a list, not an asset register.
Step 2 — Classify by connector usage
Group the inventory by connector. Connectors are the bridge between an agent and enterprise data, and they are the highest-leverage governance surface. According to the Microsoft Learn Copilot Studio admin governance documentation (Microsoft Learn — Copilot Studio admin governance, accessed 19 October 2026), connectors can be allowed or blocked at the environment level through DLP policy.
Three categories of connector usage emerge consistently in Australian tenants:
- Microsoft Graph and first-party connectors — generally low risk if the agent's grounding data is correctly scoped through SharePoint permissions, with Restricted Content Discovery used only as a temporary measure while access is reviewed
- Approved third-party connectors — services on a documented allow-list, usually CRM, HR information systems, and ticketing platforms
- Unapproved or shadow connectors — services connected by an individual builder without a procurement review; these are the highest-risk subset
Treat unapproved connectors as the retirement candidates list. Either bring the connector onto the allow-list through proper procurement, or retire the agent and rebuild on an approved connector.
Step 3 — Review environment placement
Copilot Studio agents live in environments. Environments are the unit of DLP policy. An agent in a Finance environment with a strict allow-list cannot connect to services that are not on that list, even if the builder tries to add them. An agent in the default environment usually has no such restriction.
Review which environments each published agent is in, and whether the placement makes sense. Common mis-placements observed in 2026 audits:
- Production agents in the default environment because that was the only environment available when the builder started
- Sandbox agents promoted to production without environment migration
- Agents in business-unit environments that should be in a shared service environment for tenant-wide audiences
Document the target environment for each agent and schedule the migration. Environment migration is the single action that locks in connector governance.
Step 4 — Apply build-and-publish controls
The Copilot Control System introduced explicit build-and-publish approval. This is not a permission model that exists by default — it is configured through admin policy. Per the Microsoft Learn Copilot Control System reference, administrators can require publish approval for agents in specified environments, and can restrict who can build agents in those environments.
A pragmatic baseline:
- Default environment — open to build, requires admin approval to publish
- Business-unit environments — open to build for that unit's identified builders, requires unit owner approval to publish
- Shared service environment — restricted to a small group of platform builders, requires platform owner approval to publish
This baseline is enough to stop net-new sprawl while the existing inventory is remediated.
Step 5 — Review post-publish telemetry
The agent inventory now includes telemetry on how published agents are actually used. According to the Microsoft Learn Copilot Control System reference, post-publish telemetry covers invocation counts, unique users, and recent activity windows. Agents with zero invocations in the last sixty days are retirement candidates. Agents with a single invoking user are review candidates — they may be experimental rather than production.
Treat the telemetry as the prioritisation engine. Remediate high-traffic agents first, retire low-traffic agents first. This pattern is the inverse of alphabetical or by-creation-date sorting, which is what most first-pass audits default to.
Step 6 — Document the cadence and the responsible owner
The single most common reason an agent audit produces no lasting improvement is that no one owns the next audit. Document the cadence — quarterly is the practitioner default until the tenant reaches L4 maturity, monthly thereafter — and document the owning role. This is usually the Microsoft 365 administrator or a designated Copilot platform owner.
The audit output is a living document. The inventory itself is recorded in the Copilot Control System, but the metadata layer — business owner, data classification, APP 8 trigger — sits in the tenant's governance documentation. Update it whenever a new agent is published or an existing agent's connector list changes.
How this fits the Copilot Governance Maturity model
This playbook moves an organisation up the agent governance pillar of the L1 to L5 Copilot Governance Maturity model. A tenant with no inventory is L1. A tenant with a manual inventory is L2. A tenant using the Copilot Control System dashboard with documented build-and-publish controls is L3. A tenant reviewing post-publish telemetry monthly with environment DLP per business unit is L4. A tenant with automated retirement workflows is L5.
For Australian organisations specifically, the agent governance pillar interacts with APP 8 obligations through connector choice. An agent that connects to an offshore service may route personal information offshore, and that is a cross-border disclosure under APP 8 of the Privacy Act 1988 (OAIC — Privacy Act 1988, accessed 19 October 2026). According to the OAIC guidance on cross-border disclosure (OAIC — APP 8 cross-border disclosure (Chapter 8), accessed 19 October 2026), organisations remain accountable for personal information disclosed overseas unless a narrow exception applies. The agent connector list is therefore part of the APP 8 analysis, not separate from it.
Score your governance maturity in five minutes with the free Copilot Governance Maturity audit, or at /copilot-governance. For a practitioner-led deep dive across all three pillars, book the Copilot Governance Maturity Assessment at /assessments/copilot-governance-maturity-assessment.
Sources referenced in this article: Microsoft Learn Copilot Control System reference, Microsoft Learn Copilot Studio admin governance, OAIC APP 8 cross-border disclosure guidance (Chapter 8), Privacy Act 1988, ACSC Essential Eight.
