How Dormant Copilot Studio Agents Create Cost and Security Risk

In this blog post How Dormant Copilot Studio Agents Create Cost and Security Risk we will explain how to find forgotten agents, decide which ones still have value and retire the rest without disrupting important business processes.

Agent sprawl usually starts innocently. One team builds an HR assistant, another tests a sales agent and several employees create proofs of concept. Six months later, nobody has a complete list of what exists, who owns it or which company systems each agent can access.

That is agent sprawl. It creates unnecessary administration, hidden security exposure and confusion over which agents employees should trust.

What is a Copilot Studio agent?

Microsoft Copilot Studio is a platform for building AI agents that answer questions, complete tasks and interact with business systems. An agent can use company documents as a knowledge source, respond inside Microsoft Teams or Copilot, and connect to services such as SharePoint, Outlook, Dynamics 365 and third-party applications.

Behind the friendly chat window are instructions, data connections, user permissions and automated actions. Some agents wait for an employee to ask a question, while autonomous agents can start work when an event occurs, such as a new email, support request or updated record.

This means a forgotten agent is not simply an old file. It may still have access to sensitive information, active connections or automated triggers that can perform work without someone watching closely.

Dormant does not always mean harmless

An unused agent does not necessarily generate a direct charge. If nobody uses it and it has no active triggers, its consumption-based costs may be close to zero.

The larger concern is unmanaged access. An old agent may retain permissions to customer records, internal policies, employee information or operational systems. Its instructions and knowledge sources may also become inaccurate as the business changes.

There is also an indirect cost. IT teams must investigate old agents during security reviews, platform changes and compliance audits. Employees may waste time testing several similarly named agents because nobody knows which version is current.

This risk becomes more serious when an autonomous agent has a trigger that still runs. As discussed in our guide to preventing AI agents from getting stuck in costly loops, automated work needs clear limits and monitoring even when the original project appears complete.

Start with a complete agent inventory

You cannot govern agents you cannot see. Microsoft now provides central inventory capabilities through the Power Platform admin centre, where authorised administrators can search, filter and export information about agents across business environments.

An environment is simply a controlled area where Microsoft stores agents, applications, workflows and their permissions. Separate environments are commonly used for experiments, testing and live business services.

Your inventory should capture more than the agent name. At a minimum, record:

• The agent owner and responsible business department
• When it was created, modified and last published
• Whether it is a draft, test or production agent
• Where employees or customers can access it
• Its recent sessions, events and automated activity
• The data sources and business systems connected to it
• Whether the owner still works for the organisation
• The business outcome the agent is expected to deliver

Copilot Studio monitoring can retain high-level agent analytics for an extended period, although detailed transcripts are available for a shorter window. This is why regular reviews are more reliable than trying to reconstruct activity once a problem appears.

Use more than one signal to identify dormant agents

A simple rule such as “delete anything unused for 90 days” sounds efficient, but it can remove legitimate seasonal agents. A finance agent may only be needed at year-end, while an emergency response agent should remain available even if it is rarely used.

A better approach combines several signals:

1. No recent usage. The agent has had no meaningful user sessions or automated activity during an agreed review period.
2. No recent maintenance. Its instructions, knowledge sources and actions have not been reviewed or updated.
3. No confirmed owner. The listed owner has left, changed roles or cannot explain the agent’s purpose.
4. No measurable outcome. The business cannot identify time saved, work completed, service improved or risk reduced.
5. Duplicated capability. Another supported agent now performs the same job more effectively.

We commonly recommend treating 90 days as a review trigger rather than an automatic deletion point. Higher-risk agents, including those connected to customer, financial or employee data, should be reviewed more frequently.

Classify agents before removing anything

Once potential dormant agents are identified, place each one into a practical category. This prevents IT from treating a harmless experiment and a business-critical automation in the same way.

• Keep and monitor for agents that remain useful and have a confirmed owner.
• Improve for agents with value but poor adoption, outdated information or unclear instructions.
• Consolidate where several agents solve the same problem.
• Quarantine when ownership, permissions or business impact need investigation.
• Retire when there is no valid purpose, accountable owner or continuing usage.

This classification should form part of the wider AI agent lifecycle from onboarding to offboarding. Retirement is much easier when ownership and review dates were established before the agent went live.

Retire dormant agents without creating disruption

Deletion should be the final step, not the first. Begin by contacting the owner and relevant department, then check whether the agent supports a seasonal process, another automation or an external customer channel.

A sensible retirement process is:

1. Confirm the decision. Obtain approval from the business owner, IT and security where appropriate.
2. Record dependencies. Document connected systems, knowledge sources, channels, automated triggers and service identities.
3. Stop new activity. Remove sharing, disable triggers or unpublish the agent where the agent type and business process allow it.
4. Observe a holding period. Keep the agent unavailable for 30 days and monitor for support requests or failed dependent processes.
5. Preserve required records. Retain configuration, approval and audit information according to company and legal requirements.
6. Remove access and connections. Revoke credentials, permissions and system connections that are no longer needed.
7. Delete and verify. Remove the agent through the appropriate Microsoft administration process and confirm that associated access has been closed.

The exact controls can vary between Copilot Studio agents, Agent Builder agents and older chatbot technologies. Administrators should verify the agent type rather than assuming one bulk deletion method will handle everything safely.

A practical example for a 200-person business

Consider a 200-person professional services company that allows several departments to experiment with Copilot Studio. Its first review identifies 42 agents across development, testing and production environments.

Only 11 have recent usage and confirmed owners. Nine are duplicates, seven belong to former employees and six were demonstration agents connected to outdated SharePoint folders. The remainder support seasonal or low-volume processes and need business confirmation.

After a structured review, the company consolidates the duplicates, assigns new owners to two useful agents and retires 19 obsolete agents. The immediate benefit is not simply lower AI consumption. IT now has fewer access paths to monitor, employees know which agents are approved and future security reviews take less time.

Make agent cleanup part of normal governance

A one-off cleanup will not prevent sprawl from returning. Every production agent should have a named business owner, an IT contact, a review date and a clear statement of the outcome it is meant to achieve.

Organisations should also separate experimentation from production. Test agents can live in restricted environments, while agents that handle important business data should follow stronger approval, monitoring and change controls.

This supports the intent of the Essential Eight, the Australian government’s cybersecurity framework used by many organisations to reduce common security risks. The Essential Eight does not provide a specific checklist for AI agents, but its focus on controlled access, system hardening and administrative discipline is highly relevant. Privacy obligations must also be considered when agents can reach personal information.

As a Microsoft Partner and Wiz Security Integrator, CloudProInc combines more than 20 years of enterprise IT experience with hands-on expertise across Copilot Studio, Microsoft 365, Azure, Intune, Microsoft Defender and cloud security. Our focus is practical governance that reduces risk without stopping useful experimentation.

Dormant agents are rarely the biggest item on an IT budget, but they are a warning that ownership and control are slipping. If you are unsure how many Copilot Studio agents exist in your organisation or whether they are still safe and useful, CloudProInc is happy to help you review the environment and build a sensible retirement process with no unnecessary disruption.